►
From YouTube: OpenEBS 101: Hyperconverged Kubernetes Native Storage - Kiran Mova & Vishnu Itta, MayaData
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
OpenEBS 101: Hyperconverged Kubernetes Native Storage - Kiran Mova & Vishnu Itta, MayaData
OpenEBS provides horizontally scalable, highly available, persistent storage for Kubernetes stateful workloads. OpenEBS allows users to create a Hyper converged Kubernetes clusters, by pooling the storage available on the Kubernetes nodes. OpenEBS comes with a variety of storage engines that are highly composable to meet the demands of the different workloads. OpenEBS makes it easy to build managed data services. In this talk Kiran Mova and Vishnu Itta will discuss OpenEBS architecture, how to get started with OpenEBS, recent updates on the Day 2 Storage Operations support and the roadmap. OpenEBS is a CNCF sandbox project.
https://sched.co/ZevN
A
Hi
everyone
thanks
for
tuning
in
to
this
cncf
maintainer,
track
session
on
opendbs,
open
abs
joined
cncf
about
a
year
ago,
and
I
just
completed
its
annual
review
and
it's
on
its
way
to
clear
the
incubation
stage.
I'm
actually
delighted
to
present
this
talk
along
with
vishnu
here
today.
Both
of
us
are
available
on
slack
kubernetes,
slack
or
ids.
Are
there
you
can
reach
out
to
us
for
any
questions
related
to
the
session
as
well
as,
if
you
have
any
questions
related
to
state
or
running
stateful
applications
in
kubernetes.
A
We
are
really
excited
about
the
possibilities
that
kubernetes
offers
for
running
stateful
workloads
just
a
little
bit
of
my
data,
where
we,
you
know
which
actually
sponsors
both
of
us.
We
both
completely
work
in
open
source
and
with
the
community.
My
data
is
also
like
one
of
the
top
contributors
in
the
cncf.
A
It
has
donated
open
ebs
that
we
will
talk
a
little
bit
more
today
and
it
recently
also
founded
and
along
with
other
companies,
donated
litmus
as
another
project
electronics
is
used
for
enabling
chaos
engineering
in
a
kubernetes
native
way
in
kubernetes
clusters.
It's
actually
both
for
stateful
and
stateless
workloads,
apart
from
working
on
open
ebs
and
litmus
projects,
vishnu,
and
I
also
work
on
several
other
kubernetes
ecosystem
projects.
A
We'll
recap:
the
state
of
stateful
workloads
in
kubernetes
and
some
of
the
challenges
or
some
of
the
motivations
that
actually
drove
us
to
write
a
new
type
of
storage
that
we
call
as
container
attached
storage,
or
you
can
kind
of
call
it
as
hyper.
Convert
storage
in
fact,
hyper
converge.
Storage
is
the
category
that
cncf
white
paper
uses
to
include
open
abs
as
one
of
the
storage
options
that
are
available.
A
A
It's
been
a
journey
and
in
fact,
like
I,
I
talk
about
this.
A
little
more
in
the
rest
of
the
presentation,
but
conveys
law
is
something
that
keeps
popping
up.
Every
now
and
then
in
fact,
the
move
of,
like
you,
know
the
project
to
shift
all
the
entry
volumes
to
their
own
csi
drivers
and
the
evolution
of
the
csi
drivers
itself
is
a
manifestation
of
how
decoupled
storage
drivers
are.
A
Like
you
know,
splitting
the
storage
volume
code
from
the
kubernetes
mono
report
to
its
own
repos
is
increasing
the
agility
of
making
the
kubernetes
releases
and,
as
well
as
adding
more
drivers
as
we
move
along
csi,
has
become
a
de
facto
standard.
Now,
a
lot
of
people
use
it.
Both
vendors
and
users
are
getting
comfortable
with
it,
but
it
doesn't
end
there.
It's
just
in
its
ugly
stages
of
defining
the
spec.
A
A
You
basically
use
csi
to
connect
any
of
your,
like
externally
attached
storage,
but
there
are
a
few
challenges
with
this
architecture:
we'll
try
to
go
into
details
of
each
of
them,
but
it's
some.
It
suffices
to
say
that
the
kubernetes
enables
a
loosely
coupled
micro
services
architecture,
but
when
we
look
at
the
storage
that
is
serving
these
applications,
that
itself
is
actually
developed
using
monolithic
architecture
and
for
a
different
time
and
period.
A
The
the
loosely
coupled
and
the
agility
that
you
get
the
auto
scaling
capabilities
like
you
know
both
scaling
up
and
scaling
down
that
you
get
by
running
in
the
microservices
way.
You
kind
of
lose
it
when
you
go
down
and
try
to
put
everything
into
this
shade
storage-
and
you
know,
basically,
you
lose
your
agility
as
well
right.
One
of
the
things
that
happens
is
like
you
know.
The
shared
storage
will
have
to
mix
and
match
the
different
parameters
while
serving
the
different
workloads.
A
A
So
this
is
actually
a
slightly
older
survey
and
I
think
a
new
survey
is
probably
going
to
hit
around
the
around
the
corner,
maybe
like
in
this
event
that
we
are
speaking
as
well,
but
one
of
the
interesting
things
that
I
noticed
in
here
is
you
know,
even
though
kubernetes
was
developed
for
stateless
workloads,
state
is
quickly
becoming
very
popular
or,
like
you
know,
being
used
in
many
of
the
kubernetes
clusters.
This
shows
a
wide
range
of
different
storage
products
that
are
used.
A
You
can
kind
of
divide
this
into
a
couple
of
categories,
for
example
to
run
your
kubernetes
workers.
You
do
need
storage,
so
some
of
these
cloud
provider
volumes
could
be
that
kind
of
a
storage,
but
there
are
other
projects
here
like
open
abs
or
cluster
portworx.
These
are
the
projects
that
are
custom
made
to
provide
storage
to
your
stateful
workloads.
So
if
users
are
using
those
products
here
are
like
you
know,
they're
responding
that
they're
either
evaluating
or
put
into
production.
That
means
they're
definitely
running
stateful
workloads
in
kubernetes.
A
While
talking
about
the
storage
or,
like
you
know,
the
evolution
of
the
csi
drivers
itself,
so
just
to
recap
that
a
bit
it's
basically
a
cultural
shift
that
we
are
seeing
overall
in
the
industry
from
every
layer
at
the
you
know,
if
you
have
to
briefly
explain
what
this
is.
It's
about
the
way
we
compose
our
teams
is
the
way
we
develop
our
applications.
A
The
shift
from
having
specialized
teams
to
making
the
you
know,
functional
teams,
where
you
kind
of
put
experts
from
different
categories
so
that
you
can
actually
develop
independent
services
is
the
norm
right
now.
This
you
know
you
can
kind
of
call
this
as
a
devops
culture
or
like
it's.
The
convex
layered
play
the
diagrams
that
I'm
showing
here
are
from
a
very
good
thought
piece
from
thought
works.
So
do
please
check
it
out,
and
this
is
not
just
a
theory.
A
You
can
see
that
within
cncf
there
are
a
lot
of
end
user
stories
where
this
has
become
a
practice.
For
example,
this
is
again
like
from
the
previous
cube
con,
where
steven
provided
bloomberg
is
describing
how
they,
as
a
platform,
engineer,
he's
supporting
several
thousands
of
small
teams.
You
know,
sometimes
the
team
could
be
just
comprised
of
two
who
own
up
a
service
and
to
kind
of
enable
such
large
teams
with
a
small
platform
team.
A
So
this
is
the
kind
of
way
in
which
convex
law
applies
to
data
management
itself.
A
couple
of
things
to
note
here
is,
instead
of
using
a
monolithic
database
as
we
go
towards
more
specialized
teams.
Each
team
wants
to
have
its
own
type
of
database
instead
of
basically
like
the
database
that
really
suits
their
workload
or
engine
instead
of
trying
to
force
fit
their
application
to
use
an
infrastructure,
that's
already
available,
and
it
may
not
really
deliver
on
its
promises.
A
This
become
becoming
quite
common.
I,
in
fact,
like
talk
to
a
lot
of
community
members
where
olap
databases
themselves
are
getting
split.
I
think
one
of
the
main
challenges
that
they're
trying
to
solve
is
the
scaling
problem
and
within
kubernetes
you
have
this
promise
of
auto
scaling,
which
is
not
just
about
scaling
up
but
also
scaling
down,
and
that
can
only
happen
when
you
kind
of
break
down
these
monolithic
databases
into
smaller
databases.
A
So
one
of
the
use
case
that
we
are
currently
working
on
is
splitting
a
monolithic
database
that
stores
you
know
hundreds
and
thousands
of
user
data
into
a
single
database
with
a
100
db
volume
in
into
like,
basically,
a
micro
services
based
on
app
with
100
different
parts,
trying
to
write
to
a
1tb
volume
and
have
a
sharding
of
like
the
user
data
into
different
things.
So
you
can
kind
of
move
the
user
data
into
some
of
these
parts
and
you
can
kind
of
release
the
data
or
like
some
of
the
volumes.
A
If
you
are
scaling
down
as
well,
which
is
the
kind
of
a
humongous
task,
if
you
are
trying
to
do
with
the
traditional
way
of
like
having
a
monolithic
database
on
top
of
which
or
you're
basically
running
that
on
a
shared
storage
platform,
so
few
of
the
things
that
happen
with
the
shared
storage
platform
are
also
what
we
call
as
data
gravity.
Data
gravity.
Is
this
notion
where
the
storage
system
that
you
use
has
a
tendency
to
pull
in
all
the
applications
towards
it?
A
You
know
this
happens
initially,
probably
based
on
the
familiarity
with
that
system.
But
then,
as
you
put
in
more
data
and
for
latency
reasons,
you
have
to
be
closer
to
that
storage
system
and
it
kind
of
locks
you
in
into
a
technology
that
will
be
hard
to
kind
of
move
away
from,
and
you
know
it
takes
a
lot
of
operational
cost
as
well
to
think
of
something
else.
A
You
kind
of
get
logged
in
because
of
the
data
gravity,
and
you
end
up
spending
more
as
well.
So
you
know,
while
conway's
law
and
like
data
gravity
or
some
things
that
you
can
easily
relate
to
by
your
day-to-day
operations.
There
are
a
few
other
things
that
are
happening
as
well
in
terms
of
software
and
hardware.
A
But
the
thing
about
such
kind
of
high
powered
hardware
is
that
you
cannot
use
an
application
that
was
written
to
run
on
8
to
16
core
and
try
to
put
it
on
a
96
core
machine
and
expect
it
to
deliver
at
a
higher
performance.
You
do
need
to
change
the
way
you
write
the
application
or,
like
you
know,
the
way
you
architect
that
one
and
I'll
show
you
some
examples.
A
A
So
one
way
to
counter
that
would
be
go
towards
using
user
space
technologies
and
actually
like
the
languages,
are
now
support.
That,
for
example,
like
rust,
is
one
thing
that
we
use
for
developing
the
my
store:
it's
actually
a
storage
engine
that
you've
written
completely
in
user
space
that
makes
use
of
nvme
as
well
as
writing
in
the
user
space,
but
gets
the
same
same
performance
that
you
would
get
by
developing
it
in
the
kernel
right.
A
So
talking
about
the
kernel,
it's
not
just
about
the
physical
interfaces,
but
it's
also
about
the
algorithms
that
are
changing.
For
example,
pole
mode
driver
is
something
that's
kind
of
becoming
popular
to
scale,
up
the
applications,
fio
or
sorry
aio.
That
was
kind
of
pretty
common
kind
of
peaks.
When
you
go
around
the
eighth
course,
so
io
you
ring-
and
I
or
you're
in
pole
are
things
that
you
want
to
use
in
your
application
to
get
most
of
it.
This
is
not
just
about
storage.
A
We
see
that
this
kind
of
analysis
and
reworks
are
happening
in
other
stacks
as
well.
For
example,
crdb
and
vpp
from
the
network
domain
are
all
having
some
kind
of
rewrites
to
make
use
of
the
latest
technology
and
provide
higher
transactions
per
a
second,
and
we
think
that
the
same
thing
applies
to
storage
as
well,
and
that's
what
actually
motivated
us
to
come
up
with
the
container
attached
storage.
So
you
know
few
things
that
we
kind
of
considered.
We
are
anyway
trying
to
rewrite
the
applications.
Why
not
also
think
about?
A
How
do
we
do
the
control
plane
and
when
we
started
open
ebs?
A
few
years
ago,
kubernetes
was
just
on
the
race,
but
we
saw
the
potential
of
the
way
in
which
you
can
write.
The
control
plane
is
in
a
declarative
way,
so
we
have
decoupled
the
control
plane
of
the
storage
engines
to
be
handled
by
kubernetes
itself.
So
in
some
sense,
kubernetes
is
actually
your
orchestrator
for
the
storage
as
well,
especially
if
you're
using
open
ebs
and
it
comes
with
the
benefits
of
being
a
completely
declarative
way
of
operating
it.
A
A
One
of
the
interesting
thing
that
came
out
of
the
whole
thing
was
it's
the
ease
of
operations,
so
the
persona
of
folks
that
are
running
the
storage
now
is
also
changing.
There
are
no
longer
specialized
storage
administrators
who
are
going
to
run
stateful
workloads,
it's
going
to
be
the
kubernetes
sre
and
kubernetes
cesares
are,
will
be
more
comfortable
if
you
have
a
storage
that
speaks
the
kubernetes
native
language
so
just
like
how
they
get
comfortable
with
the
networking
concepts
and
the
scheduling
concepts
by
modifying
some
ml
files.
A
Instead
of
trying
to
put
the
storage
or
like
the
state
outside
of
the
kubernetes
cluster,
you
have
a
lot
of
power
available
with
your
kubernetes
worker
nodes,
so
you
can
make
use
of
the
storage
available
with
them
to
drive
your
stateful
workloads,
and
this
all
happens
in
a
microservices
way
where
each
application
gets
its
own
storage
controller
instead
of
having
like
some
shared
system.
So
even
in
case
you
want
to
move
one
workload
from
one
cluster
to
another
cluster.
A
It's
going
to
be
easy,
so
the
state
moves
along
with
the
application
to
another
cluster
and
we
kind
of
realized,
as
we
started
developing
that
one
storage
engine
does
not
meet
the
needs
of
all
the
applications
that
users
are
bringing
to
the
kubernetes
clusters.
In
fact,
the
applications
themselves
are
changing.
They
are
becoming
more
distributed
in
nature,
so
we
came
up
with
a
different
set
of
applications
that
we
want
right.
A
These
are
a
huge
list
of
adopters
that
have
already
started
using
open
ebs
just
want
to
highlight
a
couple
of
them.
The
first
one
is
the
optoro
which
actually
uses
this
hyper-converged
mode
of
storage,
and
the
main
reason
for
them
to
move
is
not
having
a
complicated
distributed
system
outside
of
the
kubernetes
cluster
to
manage
for
the
stateful
workloads
and
you,
as
you
can
see,
they
have
migrated
most
of
their
straightforward
stack
into
kubernetes
itself.
This
is
an
end
user
company.
B
I
mean
attached
to
the
nodes
itself
like
worknames,
have
a
couple
of
levers,
host
path,
block
device
and
local
cfs
in
the
next
slide.
I
will
be
trying.
I
will
explain
about
how
this
the
workloads
are
kind
of
having
the
sds
is
one
of
the
best
word,
and
it
has
multiple
replicas
of
the
micro
service
which
it
is
going
to
run
and
they
the
pods,
now
have
their
own
pvcs.
B
B
So
that's
what
we
have
the
pv
will
be
created
by
the
storage
provisioners,
so
the
three
couple
of
flavors
are
having
the
local
pve
is
the
one
where
the
opening
was
this
provisional
uses,
the
entire
disk
will
be
given
as
a
raw
device
to
the
pod
or
as
like,
as
like,
mounted
into
your
file
path
into
the
mount
path
as
a
file
system.
The
other
part
we
have
the
cfs
local
p,
which
is
the
you,
have
a
css
driver
which
allows
to
once
the
pools
are
created.
B
The
gfs
ports
are
created
on
the
nodes,
so
this
css
provisioner
will
carve
out
a
dead
wall
on
the
volume
or
the
the
the
cfs
data
set
and
mount
it
into
the
pod,
so
the
other
other
one
is
the
local
pv
in
this.
The
host
path
is
the
way
where
the
provisioner
creates
dynamically
on
the
demand,
the
directories
and
attach
it
to
the
port
and
also
on
the
deployment
time
it
takes
care
of
deleting
them
and
takes
care
of
for
deleting
the
data
as
well.
B
So
this
this
slide
is
about
with
apps
which
want
the
storage
features
from
the
engines
itself,
so
where
the
app
is
kind
of
having
using
the
storage
from
using
a
pvc
and
then
have
a
pv
target.
So
from
the
previous
slides,
we
saw
how
the
loosely
coupled
is
really
helps
in
building
these
micro
services
and
then
easy
to
manage
right.
So
the
open
abs
have
getting.
B
So
this
target
running
in
different
node
also
it
helps
to
get
the
storage
mounted
and
and
when
the
storage
is
available
on
three
nodes,
when
due
to
as
as
we
see
here,
the
three
copies
of
the
data
is
kept
in
three
different
nodes.
So
even
a
node
goes
down
where
I
did,
one
copy
is
there
if
it
once
it
comes
back,
the
target
takes
care
of
rebuilding
the
data
into
the
one
which
went
down
and
came
up,
so
one
of
the
engine
is
so
here
we
are
explaining
the
c
store
here.
B
If
you
see
the
towards
the
right
side,
there
are
like
set
of
disks,
which
are
the
admin,
use
them
and
create
a
c
store,
pool
and
increase
the
storage
classes.
So
now,
when
the
pv
is
the
pvc
request
comes
through
the
csa
driver,
the
request
comes,
the
css
driver,
comes
into
picture
and
creates
a
skz
target,
and
then-
and
then
this
will
be
attached
to
the
node,
where
the
application
port
is
running
through
ice
cuz.
It
is
a
protocol
and
then
it
gets
mounted
into
the.
B
Pod,
so
the
my
store
is
the
our
next
gen
open,
ebay,
storage
engine
which
provides
a
low
latency
and
provides
a
high,
which
is
a
pole
mode
driver
and
it's
flexible
to
work
with
any
any
kind
of
different,
even
nvme
or
this
scuzzy
disk.
And
if,
if
you
see
them
the
middle
one,
if
there
are
like
fio
providing
awesome
numbers
with
atk
for
each
fm
thread
here,.
B
Given
that
the
data
production,
the
data
in
terms
of
disaster
recovery,
is
how
we
protect
the
data,
how
we
recover
the
data,
so
opening
base
storage
engines
have
their
own
plugins
based
out
of
valero.
We
have
openbase,
has
all
the
row
plugins,
which
allows
to
take
copy
to
take
the
backup
of
the
product
application.
Ms,
along
with
the
data
and
and
also
this
works,
the
opening
based
volumes
can
be
actually
along.
B
B
A
Hi
everyone
we,
we
do
have
a
lot
of
questions
that
have
come
in
already,
so
we'll
try
to
take
them
up
thanks
for
joining
today
and
posting
the
questions.
One
question
has
repeated
multiple
times:
it's
about
the
slides.
Yes,
they
are
going
to
be
uploaded
on
the
schedule
in
a
moment
and
we
will
also
share
them
on
the
slack
channel
for
maintenance
track
sessions.
A
The
second
question
was
related
to
are
people
using
open
abs
in
production?
Is
it
good
to
put
critical
workloads?
The
answer
is
yes.
I
I
think
the
last
slide
talks
about
the
different
users
that
have
already
put
it
into
production.
Also,
there's
an
end
user
community.
That's
come
up.
It's
called
data
on
kubernetes.
Please
feel
free
to
join
there
and
learn
from
other
end
users.
It's
not
just
about
open
abs,
but
it's
generally
about
running
data
on
kubernetes
itself.
A
A
A
C
A
A
That
so,
while
he
settles
that
one,
I
can
probably
talk
about
a
couple
of
things
that
I
really
is
about
the
new
flavor
of
local
pv
that
we
have
just
released,
which
can
help
you
enforce
capacity,
restrictions
on
the
host
path
volumes
and
also
we
are
working
towards
a
csi
driver
for
host
path
volumes.
So
that's
a
great
thing
to
check
out.
It
also
has
fixes
for
the
jiva
volume
stability
fixes
in
terms
of
reclaiming
the
space
that
usually
jiva
takes
in
for
creating
internal
snapshots.
A
A
A
In
case
I'm
not
able
to
hear
him,
so
I
think
it's
through
valero
integration.
There
are
some.
You
can
also
use
csi
to
kind
of
take
the
snapshots
and
clone
them
for
taking
the
backups
within
the
cluster.
But
if
you
want
to
move
them
out
of
the
cluster,
we
use
valero,
which
is
great
for
helping
you
take
a
snapshot
of
the
data
along
with
the
applications
and
then
send
it
out
of
the
cluster
and
ability
to
restore
and
all
those
features
are
available.
You
can
even
schedule
the
backups.
A
I
think
I
got
most
of
the
questions
yeah,
so
there's
one
question
about:
when
should
we
use
local
storage
or
shared
storage
provided
by
open
abs,
local
storage
is
good
for
applications
that
can
do
the
that
can
handle
high
availability
or
failure
of
a
node?
This
is
a
good
example.
Like
say,
mongodb
is
a
great
example,
or
you
know,
cassandra
is
another
good
example.
They
cassandra
or
mongodb
are
capable
of
handling
the
node
failures,
so
local
pv
is
a
great
choice
for
these
distributed
applications.
A
A
So
there
are
some
manual
operations
required
to
kind
of
identify
that
the
pod
is
not
getting
scheduled
because
the
node
is
not
there
delete
the
pod
and
let
it
the
schedule,
but
at
the
same
time,
all
these
things
can
also
be
automated
by
operators.
For
example,
if
you
are
using
cassandra
operator
instead
of
using
a
cassandra
stateful
set,
that
can
take
care
of
this
for
you
easily
one
other
thing
that's
happening
within
the
kubernetes
community
is
to
enhance
the
support
for
stateful
sets
where
better
pv
pvc
management
is
coming
up.
A
A
Another
question
related
to
local
pvs
is
between
host
part
device
or
cfs
which
one
to
pick
up.
I
do
have
like
one
slide
that
I
didn't
present
here,
that
kind
of
talks
about
the
differences
but
to
quickly
provide
the
answer
to
that.
One
hostpath
is
when
you
have
a
lot
of
space
on
your
note,
coming
from
a
single
device
or,
like
you
know,
from
the
operating
system
disk
itself,
but
you
you
don't
have
a
choice
in
your
cloud
provider
or
your
environment,
maybe
like
you're,
creating
from
openstack
where
you
cannot
attach
external
devices.
A
Hostpath
is
a
great
choice.
Device
and
gfs
is
when,
if
you
have
devices
like,
for
example,
like
some
boxes,
come
with
eight
drives
or
like
nine
drives,
that
you
can
dedicate-
or
you
know,
by
the
partitioning
them
or
directly
to
a
workload,
that's
a
good
time
to
use
a
device.
Cfs
is
when
you
have,
let's
say
like
hard
disks
or
that
are
available
on
a
node,
and
you
want
to
have.
A
A
C
A
A
A
C
Yeah
right
so
yeah
we
we
used.
It
was
the
the
tool
open
source
tool
which
will
be
used
for
the
applications
along
with
the
data.
So
with
o
previous,
we
have
the
system
plugin
for
the
role
which
allows
us
to
take
incremental
snapshots
of
a
few
stored
volumes,
and
then
it
also
sends
it
down
and
during
restore
time,
the
entire
application.
A
C
B
A
Okay,
there's
a
question
here
about
like
2.0
features
and
will
be
get
into
the
internal
support
that
yes,
there
is
a
blog,
that's
going
to
be
soon
published
on
that
aspect,
I'll
reach
out
to
you.
Oliver
thanks
for
asking
this
question,
and
thanks
for
supporting
open
abs
as
an
end
user
and
also
contributing
to
the
helm
charts.
Thank
you.
A
So
this
a
question
about
comparison
between
open
ebs,
longhorn
and
rook.
In
fact,
as
part
of
the
annual
review,
we
have
compared
all
these
three
options.
I
can
share
that
richard.
If
you
could
reach
out
to
me
on
the
slack,
I
can
give
you
to
the
link
to
that
one.
That
will
be
thanks
for
asking
that
question.
A
A
A
A
A
So
the
question
is
from
praveen
here:
replicas
used
only
for
data
availability,
or
can
they
also
be
used
for
load
balancing
in
the
cache
architecture?
They
are
primarily
used
for
data
availability
at
the
moment,
but
we
are
thinking
of
some
or
solutions
where
they
can
be
used
for
load
balancing,
especially
for
providing
read,
write,
many
kind
of
use.
A
A
A
A
Maya
store
and
compare
it
with
c
store
in
terms
of
architecture.
The
deployment
it
is
similar.
My
store
also
has
something
called
as
nexus,
which
is
which
acts
like
a
target
and
takes
care
of
replicating
it
to
different
volumes.
But
the
differences
come
in
terms
of
the
performance
we
basically
use
tpdk,
as
well
as
ability
to
use
lockless
ring
mechanisms
to
provide
high
performance
there
for
the
ios.