We're here, we're going to hear about the state of the cephalopod, so give him a hand,
you can take a drink of water and then we'll sew it.
So much, is this too loud? Is it just right?
Okay.
Okay, so, unfortunately, and I couldn't join me here today, so I have to pretend to be an
as well as myself. So we'll cherry pick a few things here and try to cover where we are
from variety of sources. Usually, when I do state of the cephalopod, I cover the more
vendor-E IBM stuff and Joshua and I have covers the community side, but I'll try to
go about, let's see, let's see how I do.
Instead of looking at road map so much, we wanted to look at progress.
So, no, this one is not. We had a few metrics that we shared at cephalopod,
we're worth repeating. So, these are the latest in terms of where we are after 20 years of
cephalopod, 1400 contributors, 700,000 lines more than 700,000 of code change,
and 156,000 commits. So, the community has been going really well.
As a Linux Foundation project, we also have the LF stats, let's see if I can zoom in a
little bit more. The contrast on the screen is not doing good service, but while they're
up and up into the right, if you can see, 10,300 stars, 140,000 commits.
Sorry? That's not letting me do. That is not letting me do.
Let me see. That's a little bit better, but it's really the contrast.
It's the problem because the line is really, but you can kind of see it.
Not a lot of data there. It's really a line. So, apparently we're very predictable.
And this is the community telemetry. Since it started a few years ago, now it's been
already five years, well. So, we're approaching two exabytes when I have made this chart.
Also looking great, but this is a massive underestimate. These are the clusters that sign up
to report their existence to the community server. There is a heck of a lot more
cephalo there and I'll give you some numbers that I do internally for IBM that I always
promise to release and never get wrong to. And obviously we have been doing great
in terms of releases. We keep the pace. There has been a little bit of pain and suffering
in the upstream lab as we moved it from the right-hat data center to the IBM data center.
Actually, the move is not done yet, but a lot of people are suffering from that.
So, thanks to those doing that. Hopefully, the critical infrastructure has come back online
on the IBM lab already, but there is still quite a bit of work to do there.
Unfortunately, despite being the same company, we couldn't just leave our lab at
head. They told us to move it. I guess it's a good opportunity to clean up house
and throw away the old servers and put in new switches and stuff like that.
These were the metrics that Josh, Neha, and Dan show that cephalocon.
I wanted to show you.
So, this is a much bigger presentation that I usually do internally at IBM to show where we
think the market is going. You don't need all of this crap to be honest.
But I have one caveat that I'll say that it's an IBM analysis, so it's a built-in
suspenders analysis. Usually, when you make a guess, a market estimate, you say,
here is the pessimistic estimate, here is the W-A-G, wild, something guess,
and then you take the midpoint between the two as something reasonable.
When you do an estimate for IBM, you use a conservative estimate, a more conservative estimate,
an even more conservative estimate, and you take the midpoint between the three.
So, that is to say that this is the 2025 estimate there in the corner.
It was March of 2025 when I made this. It was between 6.9 and 7.8 exabytes.
And this is using three conservative estimate methods.
If we were using Gardner, I'd see you or any kind of aggressive analyst method,
we would be talking about 20 exabytes.
So, this is pretty much guaranteed to be there.
In fact, one of these metrics is me counting clusters that I personally know exist.
So, that's the most conservative estimate that you can possibly use.
So, in terms of deployments out there, we're doing absolutely great.
As I said, there is quite a bit of strategy stuff in here,
but I think the trend is interesting between my different internal estimates over the years.
So, the gap between the different methods is closing,
maybe it's because I do all the work, so I'm consistent with myself, but I don't know.
The trend is if anything, increasing even faster, so that's great.
I don't think I want to spend my time on the rest of this.
I promise to write a blog with this at some point, but you have seen the important bits.
What else is there?
There are heads sorted out that I wanted to show you.
Okay, so I wanted to do the roadmap bits from the IBM perspective before that.
There is this other slide that I usually show internally.
This is very unusual for me because I never quote analysts.
In fact, I usually consider industrialists a negative signal in my analysis.
But first of all, Coldago research is an analyst that IBM doesn't pay.
So that's a good sign.
Secondly, for some reason, the side that IBM is leading the object storage market, which is great.
But the reason why I'm flagging this is that IBM has two object products,
cause which used to be clever safe and safe.
And so that statement that IBM is leading the storage market is mostly about safe.
The rest are analyst quotes and customer quotes you don't need those.
But this is interesting because if you know anything about storage market,
object is about a tenth of the size of block and file, so it's a smaller market.
But that bullet there that says IBM really should say so.
So that's a good sign too.
Now, let's look at roadmap bits for IBM.
And obviously, whatever we do also goes into the community, so it's largely the same thing.
Sorry, somehow something here is not lined correctly, but oh well.
This is Seth Nine, which is part of the contrast is killing it.
Ah, that's why.
Is that why is it dead?
Oh, and now, of course, to say that I'm not on the VPN.
Come on, should have never pressed refresh.
Okay, so the old ones, you don't need to know because they're old hat.
But this one is tentacle effectively.
This is nine zero is what nine, actually more than nine zero is what IBM calls tentacle.
It's PowerPoint, don't blame me.
Right hat uses Google, that's all I have to say.
Anyway, my main PowerPoint is not as bad as it used to be, but it can still be fun.
So these are, no, these are the tentacle items that we highlight to IBM customers.
And obviously, I think nearly everything of this is upstream.
One thing that is near and dear to me is the arm support is finally there.
We've been working towards this for quite some time.
Big item, the one that we want to be loud about in terms of commercial is that we're going to support your coding for block and file, which,
commercially, we didn't do before.
There are plenty of community users using the previous implementation of a racial coding with RDD, especially, but also it's a FS.
And like the latency variance there.
Now, the new implementation, the fasty scene, smooth that out very nicely.
So now we're supporting that for everybody that's the big item that our marketing will highlight for nine.
We have a project for a big customer that I cannot name that wants to deploy a cluster with nine thousand OSDs.
So far we've been comfortable supporting clusters of 5,000 OSDs.
We're moving the number up and we have been doing data path enhancements.
Those were in the release and the squid base release that we did mid last year, which was labeled 8.1.
It was one of the point releases of squid from the upstream point of view.
But now with nine we have done the control path so that mostly survey the M and the bash word will take that kind of scale without healing over.
And we're getting to the point where we're actually going to test at the customers site and let's see if it works.
We should be really close to be able to claim that 10,000 OSDs in a single cluster.
There is the new tech preview of Crimson and it keeps moving forward.
We aren't seeing, we aren't seeing a VA date for Crimson yet, but we keep working on it.
Intel keeps working on it.
It's working progress.
There is, there are a bunch of enhancements in management.
The one that, the ones that are more interesting are the multi-tenancy enhancements and the ability to manage multiple clusters.
There is an external provisioner which is an IBM tool to deploy on bare metal.
And there are some multi-name space workflows that the dashboard supports for NVME of F.
I think everything here is being contributed back to the community, except the provisioner.
And I think probably the ones of you that have been watching will have noticed that the Vsphere plugin is not open source.
And that's a problem with VMware. It's not a problem with us.
There is a licensing problem with headers in VMware. I think you know the story.
Essentially, all that it does is it enables Vsphere to manage a self-cluster.
Let's see. On file, there is right limiting per share on Samba, which mirrors what we have already had for,
I don't know how many years in Libver, while in Libver first, but then in LibRVD.
We then added that to NFS and RVW. Samba is the new target.
And these are throttles where you can essentially, it's not really QOS if you want to be a computer science precise.
But because you can cap how many apps a certain volume class can do, if you combine some capacity planning with that,
basically what AWS gives you when you provision volumes.
You have a certain number of IOPS per volume based on the class that's coming.
And that the volume is coming from.
Which is a convenient way to make QOS easy to understand for the user.
So we like that model and we're being putting that all over the place.
On the block side, most of the work is going on the NVMe of F gateway.
This is an interesting one because the NVMe of F gateway is quite complete.
In fact, if you look at those things there, I would say that they are starting to deal with things that are not really problems.
Right? Who needs a export?
OEL is more interesting, but the big problem here with US is that actually X is nice because it has the driver and supports it.
Windows doesn't. OEL is getting there right now.
Right hat is there and the MW is there.
So the big ones, RL and VMware are capable of doing NVMe of F.
Microsoft hasn't gotten there yet. Oracle Linux is kind of depends on the kernel you're running getting there.
So we expect to see a lot more NVMe of F use.
Once there are enough client operating systems to consume it.
But the reason why this is interesting is that it's not open source leading in terms of creating something new,
which is the place where we usually see open source leading.
This is open source leading in the sense that we have the product complete before the market is ready to consume it.
So hopefully, I don't see frankly any alternative to blocking NVMe of F.
It is the standard unless you want to fall back to 30 years ago, Ice Cazzy.
So that's got to happen. Either you use LibRBD directly or it's that.
So it's really nice to see how complete this has become.
The CSI driver is an interesting extension. Now it's going to be in tech preview right now,
but it's going to iterate rather quickly.
This is interesting for services that are providing as a service,
kind of the deployments because they don't want to expose the Seth protocol.
They want to expose something external.
They want to expose a three for object and this gives them the way to expose NVMe of F as the block protocol outside.
Of the Seth cluster. Without having to expose the OSD and the Seth protocol itself.
So for certain type of as a service vendor, that's quite interesting.
Object has been doing a lot more stuff than that,
but those are the things that we're called out on our roadmap slide.
There are enhancements for the eternal quest for resharding.
Some things for the duplication of large objects and.
Well, you can read as well as I can.
This is the stuff that is in tentacle and tentacle released in December.
We released this at the end of January.
So it's unprecedented that we managed to actually ship the enterprise product in less than two months from the upstream one.
Of course, there were reasons because the upstream one was super late.
But still, let's take the upside. This was this is quite nice.
We managed to finally close the gap.
If you're an IBM or a red head customer, it has always been an issue that you had to wait kind of like six months before you could get the enterprise product.
So it's nice that we're closing that gap.
Now, this is, as you can see from this, because I haven't written that yet.
A working progress slide from my team where we're trying to figure out what we're going to do for this year.
Now, we actually have a plan that's quite complete.
The part that we're trying to figure out is what goes in Q2, what goes in Q3 and what goes in Q4.
And we're in the middle of that negotiation and moving things around.
So I'm not going to say that this is going to be Q2, but these are the things that folks are calling out.
And since I tend to fill half of block and core, you see that I haven't filled in yet because I want to know when I'm filling it for.
The other leads that decided to stay Q2 and this is the stuff that they think they can do by Q2.
We'll see. The official plan will be ready in a couple of weeks, so you can ask me again at the next set day.
On the management side, the big push is for multi-cluster management because there are customers that deploy a lot of self-clusters.
We have a customer that has close to 30 on the western side of Europe.
We have a customer that has 26 on the eastern side of Europe.
And these are new scenarios. In the past, it used to be that you would deploy as big as a self-cluster as you can,
because you would get a performance advantage to manage one single thing advantage and all that.
These fleet type customers are going there because they want to separate blast radius or because they have edge use cases.
Or most interesting one is because they are very tightly locked with Kubernetes.
And so they put their workload on Kubernetes and consequently on the self-storage that attach to that Kubernetes.
They want to keep the individual Kubernetes cluster small in terms of workloads so that they can try to eventually upgrade it.
Because the big problem with upgrading Kubernetes cluster turns out is not Kubernetes.
It's the workloads that are running in there.
And if you have a sprawl of workloads, it becomes a very difficult problem to preach.
So fleet of clusters tends to be what some customers are going for, which gives an angle to multi-cluster management.
We now have a designer at IBM.
So again, we haven't had it for a few years.
So there is new work on the dashboard to try to improve the UX and simplify things.
The dashboard sometimes suffers from being a straight cut of being too close to the UI.
You reproduce what's in the UI in the dashboard that's not what design should be.
That's something that had tends to do badly actually.
I'll see if we can step up a little bit there.
This mysterious FCM deployment support and data.
FCM is flash core modules.
It's a flash storage module from IBM.
It's what the flash system arrays have.
They're cool technology, but it only matters if you have an array made by IBM.
We have now set in 14 products, branded IBM, right-hat or another company that I should name.
That all come from my team.
It's the same build of FCF with different support scopes and different selections.
So we're working on number 15 and hopefully number 16 after that.
So we're putting the technology a little bit everywhere in the companies that we can reach and quite successfully I would say.
I am not the expert on file systems, but you can see what's in there.
NFS over TLS. This is for one cloud deployment.
There are now cloud deployments using CFFS backing NFS and soon SMB.
So we have a security hardening campaign going on there.
I don't want to tell you what cloud it is because it's not my job to make announcements for that cloud.
But you can guess.
There are performance enhancements for SMB and NFS that are being targeted and improvements to CFFS.
So CFFS has been slow to improve but it's moving forward and we're continuing to invest in it.
We are definitely not willing to give up on making CFFS the first class citizen.
The thing is business wise we have products that use CFFS but we don't sell CFFS as a product.
So that complicates things and also it complicates things because file systems are hard as products.
The customer can do anything with the file system.
So that's wonderful and it's also terrible.
But if you have some limitations then it simplifies things because it gives you the customer will try to do these three use cases.
Let's start from there.
That will be a point release of Tentacle.
The question is is 9-1 going to be based on you?
No, that is going to be a point release of Tentacle.
We use Rook in several of the products.
The ones that are branded data foundation open shift data foundation fusion data foundation and there are three or four more.
Those are Rook managed.
And we're also targeting what would be an IBM storage release 10 at the end of the year and that will be the start of you.
Okay, I think we're two more minutes.
All right.
But I think I'm done.
Did I show you everything?
Yes.
Let's, since as I told you, 9-1 is very much in flux.
I don't think I want to talk about 10.
And this is two vendor.
We certify with any backup vendor out there.
Yeah.
All right.
Happy.
Any questions?
Yes.
Big numbers are great.
What about small clusters?
How small?
And the question is about small clusters.
Let's call it sub 15 nodes, so essentially just a couple of terabytes.
Yeah.
Not everything is an except bytes mentioned.
Okay, so the question is less than 15 nodes a couple of terabytes.
So commercially, I usually dismiss it with, if it's less than, where is it now?
If it's less than 250 terabytes, I don't want to hear about it.
But commercially, you make decisions in terms of where you spend your money trying to make a sale, right?
Technically, there is a different point of view here, which is,
Seth is Seth's claim to fame obviously scale and more scale and even more scale.
But with things like the OpenShift integration or in general the Kubernetes integration,
those deployments are not about scale.
They are usually 100 terabytes or less because containers are not that space hunger.
This will change as cube work becomes more common.
Then you will see those deployments go to a couple of petabytes probably.
But right now there are 100 terabytes usual.
And the vast majority of the clusters we support in that scenario are three nodes,
also it's state.
They have to be also in state because with three nodes, you wouldn't be able to do the failover if it wasn't really fast.
So there is quite a bit of success in small scale, either in Kubernetes or at the edge in OpenStack,
they tend to have small clusters like that, or at some telcos.
I think the data foundation and generally the work has made Seth a lot more interesting at small scale.
And usually the reason to consume that is because we have the APIs and interfaces worked out.
So you don't need the storage, but you want all those interfaces.
So there are those scenarios, but I would say we have made progress.
I wouldn't say that it's the perfect product for small things.
In general there is always the question of why don't you buy a couple of hard drives, right?
We're out of time, so I'm going to take the questions at the back.
And whoever is next should come up to Sarah.
Thank you.