23
Oct

Linux Software-Defined Storage (SDS) Explained, LINBIT Q&A Series, Episode 4


my name is David Hay I’m a cluster
engineer with LINBIT a clustering and disaster recovery company today we’ll be talking about
software-defined storage so as we often start what is software-defined storage
software-defined storage is virtualized storage with the service management
interface so there’s a couple definitions to think of there first of
all what is virtualized storage virtualized storage is something we’ve
been doing for a while and that is the ability to abstract away hardware
devices like disks into some sort of consumable dynamic device we want to be
able to do things like not care about the disks we put in the system when I
want more storage I don’t want to say the words
can you put another hard drive in there and give me the hard drive no I just
want to say make a block device of a particular size please done and that’s
virtualized storage the ability to make abstractions arbitrary wants block
devices or any other kind of storage but we’re going to focus on block devices so
since we have that virtualized storage that’s all fine and good we have the
ability to have what we can call volume groups make volumes but that’s all by
hand so far it’s not so much by hand we’re a little farther removed from
hands touching things but not by that much so we need some way to control this
mechanism we need some way to control it automatically rather than having to ask
a storage administrator or a systems administrator to go give me the storage
I need for my application that I’m trying to deploy we want to reduce the
amount of communication we have to do for on a day-to-day basis between teams
to get things done so a service management interface allows us to
control that virtualized storage through programmatic means and what is that
that’s a software-defined storage system that control plane and that data plane
so we at LINBIT made a few pretty important decisions first of all that
data plane in that storage plane should be separated if the
stored if the storage plane goes down the control plane should be up and it
should be aware of it if the control plane goes down storage planes should
just keep going the way that it’s going you should even be able to replace the
control plane if you really need to should be able to turn off your data
should still exist and that way you can scale them independently if your storage
capacity has to scale differently than your control then you should be able to
do that very easily there’s a lot of different reasons why we want to keep
those things separate so we should have a separate data and control plane we
should be able to interface with that control plane we should be able to do it
in ways that we consider modern and standard and the way to do that that is
modern standard is the rest api rest to rest communication and cloud systems
and data centers is a very easy and elegant way to have a very accessible
command set over a very well-known protocol that is easy to interact with
just about any tool even just a browser and it’s very easy to filter very easy
to understand we don’t have to worry about this COI interface and that
product and making middleware to glue this and that together
no we just do it through rest all that is over we’re just doing it with rest so
we have a client that uses the rest interface we have a controller that uses
the rest interface and what we’re using here is LINSTOR the LINSTOR
controller this is what we talk to when we want that service management
interface and this controller talks to what we call satellites a satellite we
can think of it as a node but what it really is is an agent running on a node
and that agent controls existing storage mechanisms and Linux there’s a few ways
that we can do this and a few reasons why we did this
first of all storage mechanisms and Linux are very mature they’re very
predictable and they’re not going to eat your data we know this they work
extremely well they’ve had a huge amount of testing and we don’t need to reinvent
the wheel we should use the things that work well
and these work extremely well they’re already as scalable as we need them to
be they already have very understandable
interfaces so our agents control things like for example LVM the logical volume
manager in Linux this is a virtual storage system this allows us to pool
mini disks together into a single logical volume group cut them up into
arbitrarily sized logical volumes and then present those as block devices just
like you would interact with a disk but it can be many disks at the same time
and since we’re using that and ZFS is very similar it has a few extra features
we can use either whichever one you’re more familiar with is usually the answer
to which one you will use we also have the ability to control other storage
objects in Linux we have the ability to control caching mechanisms such as B
cache we can add optional features as layered block devices we can say we want
volume management we want caching we want data replication we want nvm uof
transport and we want to put all of that into a stack maybe we want encryption
somewhere in there and all of these things are optional you can choose your
own adventure as to what your block stack should look like and you can do it
on a per node basis you can move from one implementation to another very
easily using DRBD DRBD is how a lot of these connections in fact by default how
these connections are terminated when you make your block stack on a node
it’ll usually end in DRBD and yes it’s replication software but that’s also
block transport software not only can we use DRBD to replicate data
between one node and another we can also use it to make that same data accessible
to a remote node that doesn’t even have a disk so we can use it like an iSCSI
target we have the functionality now now we have an SDS that can work over a
network and that is the kind of requirement that we need for something
like kubernetes that’s what we need to make persistent volume claims for pods
and expect that storage to be accessible across your cluster we want to have a
storage class that has a set amount of replicas maybe we want that storage class
to have some of these optional block abstractions that we can use here we can
define that with lens store this is what makes LINSTOR so friendly with kubernetes
DRBD makes LINSTOR friendly with kubernetes and NVMeOF’ makes LINSTOR friendly with kubernetes so we can make this data available across the
cluster we can give it resiliency by replicating it we can also give that
data continuous availability so if we lose one of the replicas there’s no
failover process we just simply start accessing data from a different node we
also have the ability to migrate data if we have a replica here and here and a
diskless replica here it’s actually quite simple to add local storage to
that once diskless node and give it a local replica and if it has a local
replica then the application that you’re using has local access to a disk which
will always be less latent than accessing data over a network for
machine learning workloads for databases for anything that requires very low
latency access to data this can be extremely powerful for making your data
less latent to that workload we want a local copy in a lot of cases that’s
idealism and a lot of infrastructure but with LINSTOR and DRBD it becomes a
readily available possibility we also can manage an NVMeOF target and
initiator connections and that’s a big deal in a lot of cases for NVMeOF we
need to be able to discover targets we need to be able to connect targets to
initiators and this isn’t necessarily simple we can’t just walk up to a
workload in a lot of cases and say hey this is what your target is this is what
your initiator is and expect the two to connect not in a system like kubernetes
not at any scalable system we can’t be putting that thing in by hand we
actually have to have something that orchestrates that connection for us in a
lot of cases we need discovery mechanisms from things like Fiber
Channel and fin a band or swordfish but with with LINSTOR we actually don’t
need that LINSTOR already has agents called satellites on these nodes
that totally aware of the storage on those
nodes so we can know where a target is because we set it up we can know where
target is because we have an agent on there that’s aware of it having already
been set up and we can use that information to connect initiators so we
actually have a discovery fabric now so and that’s available over rest so you
can have your orchestration system talk to that too you can have kubernetes very
easily get impost to LINSTOR you can have OpenStack use LINSTOR
you can use LINSTOR by hand with a command line client if you so desire
it’s scalable to very large deployments it’s still practical to use in very
small deployments and can go from very small things to very large things we’re
able to make decisions on the fly and we can keep making decisions we can make
mistakes and not have to just live with them they can change the way our storage
is designed on the fly so because we can manage these things because we can
manage nvme volumes all these various disk abstractions make them available
over the network we have a virtualized storage system that works extremely well
a network-attached virtualized storage system and we have a service management
interface that will scale it will scale independently of your storage and exists
independently of your storage and that is what the LINSTOR SDS is that is
what makes us friendly with kubernetes and that is how you use Linux storage in
the modern age thank you and don’t forget to like and comment and subscribe
we’re always happy to reply and watch our other videos I’ll see you next time

Tags: , , , , , , , , ,

There are no comments yet

Why not be the first

Leave a Reply

Your email address will not be published. Required fields are marked *