Leading Space Agency’s Long-Term Scientific Storage at Scale with Scality

Hello. Nice to meet you everyone. I'm, uh, Nick Sayer.

I'm the product director for Ring. Uh, I'm gonna speak to you about a spatial use case, spatial, uh, use case, uh, that we, uh, developed and deployed for Nest, uh, part of the, uh, European Safe Space Agency, uh, here in, uh, Europe. Um, nest, uh, had problems.

C is capturing data and information from, uh, from multiple satellites, about 200 satellites over the world, and getting that information live, feed directly into storage and needs to analyze that data to, I was reading on the news yesterday, Bob, the smoke that's coming from Canada and hitting, hitting the coast of France. All of this dive live data needs to come super quickly. Uh, about 10 to 12, uh, petabytes per year coming live.

These are satellites going around the Earth, the earth. This data is very live and very useful in the first six months. They do analysis, try to understand patterns on how the earth is behaving, what those satellites are capturing.

Once that's done, this data is not really live and useful anymore. You need it, need to keep it, uh, but you don't need to actively use it. So they wanted a, a cheap way to put that data aside to eventually go look at it, uh, at a later time for further analysis, try new algorithms to try to understand the sea levels, for example, and how these are, are involving this cold data.

This data that's less useful is hundreds of petabytes. Those satellites have been going around, uh, since the sixties around the earth, as I said, about 200. So you can imagine the quantity of information they need to store and keep available, uh, for people that want to look at this.

Uh, this older imaging. Um, the other challenge they had, they had multiple storage solutions based on NFS on file on Sam, some that were actually attached to some satellite technologies and very difficult to manage and aging. Uh, they wanted to go S3 everywhere, a single protocol for all usage of all of their data.

That's perfectly standard, cheap to use. We have libraries all over us and developers, uh, available widely, uh, to develop on S3. So that was also, uh, a big move for them.

They're conscious of cost, they're conscious of energy. One thing they said on the first day, having drives thin with data that is 20 years old that I'm eventually gonna have to look at in a few years, it seems, uh, not optimal in terms of, uh, well using your energy and, and getting things moving. So that's something that we're really attached to.

Going back to the core requirements, security of data. This is public data, but it's super important that it's not tampered with reducing cost, uh, space usage of, of space of the infrastructure, energy consumption, essentially trying to have the as small as possible infrastructure for the most capacity and leveraging this cold and hot, uh, and be sure that we have the proper technical solution for the type of data. And of course, the single protocol and really a single namespace.

They didn't want to their users, their applications, their public to have to understand, oh, that data is in that gear, and I have accessed it like this. They wanted a single namespace, uh, to be able to get the data 20 years ago or a few minutes ago in the exact same way. Um, how did we, uh, address this?

Um, we built forecast a ring on three sites. As a, as Paul was, uh, was, uh, referring to, uh, allowing you to lose an entire data center and still keep access and security on your data. And this ring serves the hot and warm data.

That's where the satellites actually write every day, 24 7. This data is act, uh, is actively consumed by compute engines that analyze that data, enhance the imaging to make it consumable by weather agencies, by military, of course, as you can imagine, uh, even the public. I can go see me's data the day after and see, uh, my house and see, uh, what I need to fix in my garden, for example.

It's really high definition. Um, then this data after six months is fairly stale. That's where we transition into tape to actually two tape libraries in two locations.

So we have this duplication of information and we remove it from the hot tier. Mm-hmm. This transparently, again, from the users and the applic, the pressure here.

Um, Go ahead. So, uh, you keep everything in the object, right? In, uh, this single name space, and then when you move it to the tape drives, what kind of software do you use?

So we built, uh, our own solution, which I'll, uh, describe in a, in a bit. Basically, we don't manage tapes. That's not our business.

So we rely on third parties that have HSMs that have managed tape for years. So we work with DMF from h HP with a tempo. We work also with other cloud vendors, uh, IBM Spectra for example, so that they manage tape and the ability to have a, an arm move the tape from one derive to the other.

We pilot, uh, the actual HSM to tell and stash and tell them to stash that object back on tape to retrieve that object and put it back on ring. This is completely transparent for users. Exactly.

From a user point of view, you're using a glacier, API and just putting and restoring objects. So, so you build your kind of middleware, right, that it's, uh, communicating with API of the tape, uh, controller. Exactly.

And I'll mention it in a couple of slides. We call it TLP. It is public in the sense that we build it for a first integration that we did with, uh, our partner hp.

And that API is gaining traction. We build it for a, with another company here in Europe called, uh, a Tempo. And we're actively working with new partners to integrate this, uh, uh, uh, cold management.

API, essentially it's an API to manage the access to asynchronous access to data. Data that you cannot retrieve on the get that you ask to retrieve and get notified when that data is retrieved. 'cause you need to move the tape or do whatever you do, Right?

So, uh, and then you leave like kind of a, like it was during the NFS times to like a stop file, but in the object that, uh, the user is connecting to, and then it's restored automatically from the tapes, right? You access your bucket, you list your bucket, you see what's hot and what's cold in that bucket, you have a, an S3 attribute that will tell you, oh, that data is cold, or that data is hot, so that you could, uh, know what you could get immediately. And if you try to get an object that we don't have anymore that's been put on tape, uh, you'll get a, a specific message back from the A-W-S-A-P-I, uh, telling you that you need to restore that object.

You trigger the restore, then the tapes move around. You can get a notification on that restore. So you don't have to pull, uh, every minute try to see if the object is here.

You just wait for the notification. And when that object or multiple objects or bucket has been restored, your application is informed and can consume that data directly on rain and it re expires, uh, after a certain and predefined amount of time is you don't want to keep it in two locations. Essentially, it's all data.

So that restoration principle is temporary. That's completely aligned with, uh, how, uh, AWS Glacier behaves in terms of API. Thank you.

Thanks. Um, so what's our value proposition here? We have managed cold storage for a few years already.

Essentially working with the Asia archive, for example, with Glacier. Uh, the big evolution is actually, uh, directly managing hardware, managing tape through those partners I was speaking about, uh, a bit earlier, and that integration we did for them in a way, again, that's completely transparent for the user. Of course, the people at Nest had to set up a tape library, had to prepare all of that infrastructure.

Their users, their applications have no clue that there are tape drives, that there are multiple locations or whatnot. They see buckets, they see stored locations for their objects in their buckets. They can ask Restore, they could put lifecycle policies for them.

It's exactly as if it was a, an AWS glacier with a cost of on-premise, local way cheaper in terms of a cost to, uh, to, uh, to petabyte and a way cheaper, because you don't have to pay to actually get the data out of, uh, of your own ring a single reference to data. I think that's super powerful. It means you can build very complex, multi-tiered infrastructure in the back of your customers.

They don't see it. They only see a single reference. And, uh, and, and always access an object, an image with the same, um, the same, um, the same, uh, URL, um, resiliency integrated, and especially for Nest.

Again, it's public data, but it's super valuable data. That's how we see how our planet evolves. Three sides stretch over three data center.

You can lose one of them, you can burn down one of them. The data stays available, and those objects stashed on libraries are put on two different libraries in two locations. Again, to ensure that if an event, uh, uh, occurs, you don't lose anything.

We also added the security that comes from Core five that Paul was mentioning, a strong S3 Im, um, uh, model to ensure that no one can actually tamper or access the data, that he does not have the right to answer object lock to ensure that those objects stay immutable and to not be changed over an infinite course of time. There's no expiration of data at Nest, unlike, uh, what, uh, Ben mentioned on, uh, on that bank here. The data is kept forever and ever.

Um, what's the state today of the deployment? We have a question, sorry. Yeah.

Is there a distinction here between a stretch ring and a replicated ring? Uh, there is a, there is a distinct, there is a distinction, yes. Um, a stretch ring.

All of your data will be on all of the site in an absolutely synchronous manner when you write with your application and you get the acknowledged of that, right? Your data is fully secured on all of the sites, meaning you can lose A's it's kind a synchronous manner. Is that what you said?

It's Synchronous replication. It's fully synchronous when you're on stretch, when you're going into asynchronous rings as a bed was presenting earlier, there is a delay between the time your data is written on the first ring, and it's available on the second ring delay that can be in milliseconds, seconds for sure. Uh, maybe a bit longer if you have a, uh, a big push in terms of data ingest.

But essentially it's the, it's asynchronous. We acknowledge the right once we get the data on the first site, and then in the background send it to the second site. And The cold data in this configuration for ESA is also replicated across multiple tape libraries.

It is actually sent to two tape libraries, and to be precise, some of the lesser important data, some of the data that ness did not capture themselves, but comes from satellites that are British. Maybe this is only sent to one library because the British people have another copy of that data and the ness and the data that's purely ness. All of our own satellites, those 200 satellites, those are written in y on the two, uh, tape libraries.

Uh, and only when we have that right on the two tape libraries, we acknowledge this on the ring side and we see reference, uh, we remove that local data and just keep a reference on it. Okay. Thanks.

Welcome. Um, yeah, summing up a bit, what's the status today? Uh, we have, uh, about 50 53 petabyte hot, uh, at just short of a hundred servers that are deployed, uh, out there.

And that's how you access your data in 10 milliseconds or less, depending on the size of the object. Then we move it to tape. They have about 150 petabyte tape.

Uh, this will grow organically as we have more, we have higher definitions, images also, uh, so for a skeleton fee, a source of revenue that's going to keep on going. Uh, for example, latency is a few minutes. Uh, sometimes due to via specifics of tapes, uh, it could be a bit more.

Uh, there are looking for example, uh, starting to take tapes out of the library and put them in on shelves. And in that case, we need this human intervention to get the, the tape back. This, uh, homegrown API, which we, uh, built and invented, adopted by, uh, uh, two partners today with developments ongoing for other partners.

Uh, this is, we really powerful for a product like us to integrate supportive tape like this. Uh, it's really a big gain for our product. Uh, when I started working in the industry, uh, I was, I was told, uh, ha tape is dead.

You shouldn't even look at it. It's still here and it's actually growing. I'm not quite sure why.

The density, the cheap, uh, storage cost of tape for sure. The fact that it does not consume, uh, any energy when it's not in used, uh, also probably, uh, probably helps. And last, but not, not least third time I'm mentioning it, but it's super powerful.

We hide that tape complexity, everything behind that glacier, API, that's where a nest is up. And, uh, multiple other customers we're working with today, uh, are really adoring that solution is that, uh, it's completely transparent to their users.