Hello, welcome.
My name is Peter Sabini from Canonical.
I'm a software engineer there.
I work on various CEP stuff and I'm very excited to present Microsoft with the tagline
Get CEP up and running in minutes, unlike my slideshow.
So problem statement.
Microsoft packages CEP.
This is a big complex system with distributed configuration, distributed components,
complex bootstrapping, procedure and complex operations.
It also has non-trivial hardware requirements.
It's not just like you can download a package, install it on my notebook and be ready to go.
It also has impact uptake and adoption among users.
So if you're, for example, a famous physics research organization with thousands of nodes in your storage cluster,
you probably have trained staff on hand 24-7.
So you're good, you don't need Microsoft.
If not, if you don't have a team of trained experts on hand, maybe Microsoft is something for you.
So what is Microsoft?
Microsoft is a single package staff cluster.
Everything is in one file.
We're designed it to be a simple setup so you can get a running staff cluster for command lines.
And it runs on your notebook.
You just need one node with obviously one hard disk.
So simple possible staff cluster you can do is install Microsoft,
putstrap the cluster, add some simulated OSDs, disk drives.
So this is loop files in this case.
No extra block devices required.
And then wait a few minutes and your staff cluster should be ready to go.
How did you do this?
Microsoft is a snap package, as you might have guessed.
Snap packages have the benefit that you're completely isolated from the host system.
All the user land is in separate namespace.
You just need a kernel, network devices, block devices, hardware, etc. to get up and running.
This gives you a good isolation from the host system and gives a consistent environment across different operating systems.
Some other goodies, it's isolation from the host system also means its access is isolated.
The snap package just cannot do anything it wants on the host system,
which is good for safety, security and robustness reasons.
And you have standardized risk levels.
So if you want to install release candidates, etc., there's a standardized way to do this.
A little bit of overview of the Microsoft architecture.
You have a service management demon that manages the standard CEP components
and has a distributed database, a DITS proposal for storing configuration and no topology.
Also included in the snap package is a CLI that talks to the service management demon via an API.
All this is just a standard Ubuntu devian packages, no special binaries here involved.
I mentioned the service API, so everything in Microsoft happens via this service API.
Things you can do with the API, like listing block devices, adding or removing nodes, adding and removing disks.
Everything works via the API and the included CLI is just another client for this API.
So this is obviously great for integrating it in other systems.
Some more internals. Microsoft is built on the micro cluster library,
which provides this distributed configuration database, which is using RAVT for consensus.
It also provides cluster membership and API framework.
I already talked a little bit about scaling down, so single node systems work.
One important component here is that we automatically manage the crush rules from CEP.
So this means that as you start up with a single node, you get a failure domain of OSD,
so in effect your single node clusters work out of the box,
but if you add more nodes, your resiliency and your failure domain gets scaled up automatically.
It's also possible to provide custom crush rules.
This is important, for instance, if you go for larger failure domains,
for instance, if you have a failure domain of rooms or racks, you can implement this.
Microsoft itself doesn't know about your rooms or racks,
but it won't step on your toes if you provide a custom crush rule set.
Microsoft is famously scalable to thousands of nodes.
Microsoft's scalability upwards is primarily bound by the RAVT algorithm used in the VQLite database.
For performance, I would like to note that we're not sitting in the data path anywhere for CEP operations.
You get the standard CEP performance behavior, also with Microsoft.
Some integrations. Microsoft is the back storage back end for a number of projects in Canonical,
for instance Sunbeam, MicroCades, MicroCloud and LXT.
There's also, if you're running Juju models, there's a charm available currently in beta to integrate Microsoft into your Juju Clouds.
Last but not least, there's a nice little GitHub action that we provide to integrate Microsoft into your GitHub CI workflow.
So if you need, for instance, a S3 endpoint for your testing pipeline, this is an action that would help you with that.
Okay, on for demos.
I prerecorded these demos for time reasons and also because I'm very bad at talking and typing at the same time.
So let's see how this goes.
So this is the single node setup we talked about before.
I'm going to install the single node.
Microsoft Cluster gives it some simulated disks and enable a Rata's gateway,
which would give you an S3 endpoint.
Yeah, installation.
We have the standard stable risk level here set.
So this is what you get by default.
You see my capital DSL connection here.
Yeah, so we bootstrap the cluster.
This is done pretty quickly.
We can see now that we have a few services running already, but no disks.
Then we add some simulated disks.
These are just loop files.
This is useful for lab environment or for testing.
Don't use it for production.
For production, you would use separate block devices, obviously.
But if you want to get going on your laptop, that's the way to do it.
We enable Rata's gateway.
You can see it is active here now.
We create a Rata's gateway user.
This is just a standard safe way to do it.
It's a little ugly command line here.
And yeah, and we're done.
We can use our favorite S3 client to access our new Rata's gateway endpoint.
So just to prove that it works, we are creating a bucket here
and put some image up in this bucket.
Yeah, so that's for this demo.
So this is the simplest possible case.
Let's do something a little bit more complicated.
Say we have got a few extra nodes now.
We want to in an expander cluster and provide it with real block devices.
This is the way we will do it.
I'm now using the candidate risk level because I want to use some features from Microsoft
that didn't make it to the stable risk level yet.
So to cluster Microsoft, you need to get the token from the bootstrap node.
So the first node that we provided, like this.
Name the node you want to add and get the token for it
and provide that token to the node that you want to add here.
So, and yeah, small typo.
These have happened as well.
And yeah, and now all our nodes are clustered.
Let's check Microsoft status.
We can see all our new services here, but all the new nodes don't have any disks yet.
So let's add some disks.
So what I'm going to do here is add a user feature that comes from the release candidate
that is automatically pro for empty block devices.
So anything that's not mounted is clean.
We take as a block device here with this switch.
Let the thing settle a little.
You can see there's lots of virtual disks from Kime.
And we have a lot of disks in our cluster.
So the safe cluster is still setting a little bit,
but we suddenly have a lot more space available.
So one thing we can do is provide a second radius gateway endpoint.
Now we can see that the data we put in before is still here.
So that's reassuring.
And what we'll try to do now is we put in another OSD on the first node,
but this time we want to make it encrypted.
So full disk encryption is something we provide here.
It relies on the dmcrypt kernel module.
Not all kernels have that, so that's a little bit of a gotcha.
You need to make sure it does.
And also, this goes by so fast,
also this is something that the snap is not allowed by default to do.
You need to connect the dmcrypt module explicitly to make this happen.
But once you do, it will give you an encrypted OSD device.
That's the one up there now.
Just to prove that this is a dmcrypt device,
there's a setup here.
Well, we all have the loop file for OSDs from the first node that we originally installed.
Let's remove that.
We have plenty of block devices now, so that our cluster has real disks.
So as a last step for our production cluster,
something that snaps to by default is auto refresh.
This is something you don't typically want for your self cluster.
You want to control updates for your self cluster.
And that is a step you do, is hold all the snaps and prevent auto refresh
so that you can refresh or update your software to your own leisure.
So, yeah, so that's what's for the demos.
Short outlook, what comes next.
We want to make the clustering experience a little smoother still.
No passing around of tokens.
So one thing we could do with this or we planned to do is on the local network
use MDNS to determine new nodes.
Another thing that we want to do in the near future is provide built-in
HAA and load balancing for other gateway endpoints and also RBD mirroring support.
So that was it for the demos and for the...
Thank you.
Any questions?
I don't know if we have time for questions.
One question maybe.
Otherwise, I'll be outside.
Just talk to me and I'll be happy to answer your questions.
Oh, sorry.
Here you go.
What architecture do you support with CPL architecture?
Can you repeat the question please?
What CPL architecture do you support?
So snaps are pretty flexible.
We develop on AMD64, but ARM is tested.
I don't know if the top of my heart had...
But ARM, AMD64, power, PT and risk, I believe...