So we'll round up a pause and we'll get started.
Okay, let's start.
Good afternoon, everyone.
My name is Greencee from Alibaba Cloud.
Today, I'm a set user.
You'll work on CSI-based terrorist plan.
This plan is M2 Bridge, the gap between the local block storage and cloud block storage.
Let's begin.
Today, we will start with the challenge of modern storage.
Then we will give a brief introduction to Kubernetes and the CSI to set the context.
After that, we will dive into the design of our character's storage plan.
And follow the parallel demo.
Then we will look at the benchmark results.
Finally, we will compare our approach with our alternatives and work-up with summary.
Okay, let's start the background.
Today, applications, let's data bases and a worked-load demands tracing simultaneously.
High performance in the press grid reliability and the operational reliability.
But current storage forces us to compromise.
On the one hand, we have a local MME SSD.
They provide the incredibly fast and millions of LPS.
But they are informal, because the host got filled.
They have in the data we will lose.
On the other hand, we got a cloud block storage.
They offer the incredibly durability and the future, like snapshots or clone or resizing.
But they are limited by network throughput.
So, what if we could take the durability of the cloud block storage
and inject the raw latency of local disks, all managed seamlessly within CSI and Kubernetes?
That is precisely what our plan aim to achieve.
We are talking about smart system.
You'll see a sector where the complexity providing a high performance boost
where it matters most without compromising data purchases.
Okay, let's take a...
Before we dive into the architecture of this third storage solution,
it's essential to build two concepts, which is Kubernetes and the container storage interface.
Kubernetes is basically two that have to run your apps in your containers.
It's starting and starting and make sure they are set up.
A lot of these apps also need somewhere to store their data.
And most honestly, most of them don't care how the storage work behind the scenes.
They just need it.
They just want it to be reliability and available when they need it.
So, how does Kubernetes actually connect to all these different kind of storage?
That's where the CSI comes in.
CSI provides a standardized set of interface that allows any storage window to integrate in with Kubernetes.
Once the hardware is implicated, user can easily consume the storage through the PVC
and PVS without ever need to know the details of the hardware.
As the show in the diagram, single port can clamp multi PVCs
and for device needs.
Additionally, single storage backend can be mapped to multiple PVs
to serve various claims across the cluster.
Now, let's look at how we actually build this third storage system.
This architectural diagram shows the interaction between the Kubernetes console and the Kubernetes node plan.
And that's what's through a technical provision in scenario.
First, when we create a PVC in a cluster,
and the CSI's error will trigger storage windows API to create a EBS in the storage cluster.
When it's successful, the Java suggests a PV within the Kubernetes.
It's then automatically bound to the PVCs,
and the transaction in this scan to be found that is making it ready for port usage.
Then, when user created a port, to consume this PVC,
the Kubernetes scheduler assigned the port to the specific node.
And at this point, CSI will demonstrate CSI's error will attach
also trigger the storage windows API,
and CSI's error will attach the EBS one to the specific node.
As you can see in the diagram, the device become visible in node plan in OS level.
So, as the precision foundation of our storage,
you will notice we have two types of nodes.
On node without local these application pods,
use the EBS one directly on the right, the node plan.
But on the node with the local disk,
we take extra steps to build our extension layer.
So, how we build this layer,
we initialize the local disk into a red zero array,
format is with TRIFS,
and mounted to the specific path.
This create a high speed cache that we will use later.
Here is the why, when we went to a win-win,
we went with this specific configuration.
First, with zero, we are empty at the main,
allow us to scale our bandwidth across all the global local disks.
Second, we took TRIFS for these location groups,
which we allow highly concurrence, higher across multiple CPU cores
while widening metadata conditions.
Then, let's move back to the container layer.
Once the sSN node detects the path,
has been scheduled,
it begins constructing the paired layer, a paired storage layer.
Using the file pass defined in the pv,
the jr creates two file, and then that pass.
On the local TRIFS system, we just initialize.
This file is a map called Meta and the data, this one.
This files are mapped into the block device using loop setup,
appearing as loop zero for metadata and loop one for data.
This two loop device, together with the EBS volume,
we just touched on this node,
formed the three components,
initialized to initialize the DM cache targets.
The final result is pushed to the application port,
is as dv, dev device map or zero,
this block device.
Yes, we can, for port perspective,
this is a standard block device.
You can use it with whatever you want.
Yeah, they can support any approach.
Now, let's look at the details of this mapping layer.
To manage local storage efficiently,
we use for locating commands to create a locating space to a file.
To make this file useful by Linux kernel,
we use loop setup command.
This map our files to dv looks device,
allowing the kernel to treat it as a low block device.
At this point, we have all the essential elements required by the M cache.
The remote EBS volume act as the origin,
the reliable source of tools.
Loop device one becomes the high speed cache layer.
We are at the loop zero,
storage the metadata of the terrestrial storage.
That's what the design of our terrestrial plan.
Now, let's look at the core capability,
this architecture towards.
First, we have our own demand impression.
You can resize your EBS volume online with zero on hand.
I will show you exactly how this works in the demo later.
We also fully support multi-touch,
which means you can attach one EBS volume to multiple calculates node.
Because we don't store any terrestrial metadata on EBS volume itself.
It's function, EBS volume itself,
it function exactly like standard EBS.
This is the same reason we can simultaneously support back up,
and scrolling, and fell over.
From a usability perspective, this output is standard block device,
so applications can use it without any change.
We just talk about that.
Finally, there is no additional background service
or diamonds to attend this whole plan.
So we can significantly reduce the operation over half.
To begin the demo, let's look at how easy it is to use this terrestrial plan.
First, we define a standard storage class in the cluster.
We define this storage class,
include the data cache class.
We have just initialized.
We also define the data cache size in 100 gigabytes.
It's defined.
It means we need to allocate pre-allocates the size for cache.
Next, we develop a stable set.
This is a stable set that we claim our storage class name
by one of the clamp templates.
We set two, we set a script,
we define a script in the stable set,
which contains two FIO benchmark tests.
You can see when the pot is running,
the results will show the significant performance boost.
This is the first rate.
This is around 150 MBB, but in the second,
it will be 1,000 and 60 MBB.
Next, we will show the online expansion.
the application port is running and we
we enter the port and the dev
commands so that the size of this
our block is 120 gigabytes
and mount down the data pass
and we do the standard Kubernetes operation
to patch the PVC storage request to 200 gigabytes
and we will see the device
in the port has become 200 gigabytes
yeah, that's our online expansion
the application don't need to have zero downtime
and by that look at the bottom picture
we don't experience the cash fell during this process
as you can see the cash fell is
remains as 100 gigabytes
in which we define in storage class
finally, let's look at the data continuity
at the top of the screen you can see we have a port running
at node number, sorry,
node number 244
and we can see the, we got a test fell under the pass
one point data
which is match to the device of our device
yeah, and we perform a node
we simulate node failure by delayed the port
and the Kubernetes will immediately schedule this port to another node
and the port becomes running
this node is number 245
and we enter into the new port
you can see we also have the exactly the same fell
but the month points of the data has become the virtual block device
now it's the device map
so as you can see the 232
gigabits file is perfect be intact
the application remain entirely unaware
that the underlying cash was swept out
and this simply is data and continuous running
this proofs that we have successfully integrate local disk performance
this is the cloud grid persistence
after that let's look at the numbers
first our test environment is consists of 120 gigabits cloud disk
and 100 gigabits local SSD
the benchmark commands we use is FIO
at least there here
and the baseline is on the left
we use this FIO command to test the EBS volume directly
we got 1,620 files
this is our starting point
in the middle you can see the performance during the very first rate
this is the code rate
and the reds you will see the
you will see the performance during the very
what the data is sitting in the local disk local dynamic cash
the performance schedules to 224,000 EBS
this is the random rate
and then the sequential rate
as in the sequence rate there is no significant improvement
this is because the cache was originated designed for HDD to SSD terry
this is packed as the long span
the default policy rules
the sequence rate is directly to the origin layers
bypass the cache to reduce sweat
and we have did some research
there is used to be parameters called the sequence rules
in the cache
the cache docs is no longer available
so for now we got no way to fix this in the sequence rate
so that is
next we see the red pass
by using the red back mode
we acknowledge the moment
to the local dynamic
the signal to the cloud happens synchronously
as you can see this takes our throughput from 132
to 3,500 EBS
this impacts on performance incredible
now we have seen the performance results
moving into the comparatively
the first one is LVAN
LVAN is more noble
compare with the DM cache
it is the main problem of LVAN
is that the metadata layouts
because the LVAN
are invented into the EBS volume
it is no longer function as the standard block device
that is the main reason we now use this LVAN
second there is a significant migration over has
Kubernetes is built for high speed port movements
but LVAN makes volumes heavy
this is because you have to
naturally clean the LVAN metadata before the EBS volume
can be safely attached to the new node
third, multi-attached port is extremely limited
standard LVAN is designed for single nodes
exclusive access
which means you can now safely attach the LVAN
manage volume to multiple nodes simultaneously
finally is the issue of capability
if you already have a existing EBS volume
fill with data
and you can adjust the turn on the EVAN
without a lot of complexity for mapping
so that is another alternative
why not just build a large storage
cluster like CF by using this local disk
where CF is powerful and is has
but is has four major drawbacks
that's our care storage plan
first is the reliability
all we call block radius
in large cluster a single network link
or metadata error can cause the
data that crashed the entire system
our solution keeps things isolated
if one part has an answer
it doesn't take down your whole storage wall
second, managing a self-built cluster is massive
operational headache
you need to specialize in renaming
who understand the complex components like OSDs
third, we bypass the network bottleneck
if for more storage
cluster, internal storage cluster are always limited
by network speed
usually 10 or 25 gigabytes
by using the local bus on the server
our care plan gets data to your apps much faster
than any network-based storage code
finally is the cloud integration
self-built storage often acts like storage island
it's so loaded and hard to connect to
with the cloud future
like instance EBS stem cells or original backup
our plan is cloud native means it works perfectly with the existing cloud ecosystem
in conclusion, we have demonstrates how
they set up based care storage plan
the primary tension in modern storage
this trade-off between the ultra high
and performance of the former local SSDs
and the lock solid durability of the cloud block storage
by implementing this architecture
we are no longer forcing the developers to compromise
we are providing a storage solution
that is as fast as local hardware
and as reliable as the cloud backbone
a quick so philosophy behind this is
this plan is cloud force
we want our customer to dedicate that company
to the cloud vendors
of loading the heavy scene
to infrastructure
so they can focus entirely on their own business logics
so if you are interested in this plan
for free to research where they have issues
and emails I will look forward to connect with you
yeah, that's all
and we have done a question
yeah, please
I think you're a quick question
I will give an example of
a quick question
I will give an example of still using accessor
I will explain which one
it's still using active events of the EDS
but using S3
because going out, yes it will perform
so there is a good idea
so instead of using a full search behind
an autistor option, the activities are going to be different
but what I will tell something is in there
do you have any advice?
I have a lot of advice
just a block story
you can see
in the story, I can't perfectly get to what you ask
maybe you can talk about this later
please
what is the context of the EDS
what is the, what is the, sorry
Fc
yeah
yeah, there are two modes of the data provided by the MPH
you got two modes
force is the red back, the second is the red through
we will set it with red back
the data will acknowledge
when the URL acknowledge
when data goes into the character storage layer
if you set it with red through
the data will go through the EDS volume
yes, it's by your choice, you can customize it
yeah
yeah, we use this in our internal scenario
but not for publics, this is the first time for publics
yeah, yeah
because usually when I try to use something at this
for example, the developers then you
oh, be your client policies support
you can use something that does not get the following support
we will not
control it
not for
yeah, for
we haven't received such a question
so I can't give you a conclusion, sorry
yeah, please
sorry, I can't get you a question
sorry
do you run virtual machines?
yeah, this is around virtual machines
to host virtual machines
virtual machines images
yeah, this is exactly
you mean something like image
like that, a multiple manifest
okay
thank you