►
From YouTube: Storage Wars - Seán C McCord, Sidero Labs
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Storage Wars - Seán C McCord, Sidero Labs
Speakers: Seán McCord
Storage is always a sticky topic in Kubernetes, and all the more so when you have choices to make. When you are not using a cloud-provider's block storage, there are quite a number of options available to you. Which system should you use? In this talk, we will examine a number of the storage systems available to Kubernetes and give you tools to evaluate when it makes sense for you to use which. We look at performance, reliability, sustainability, cost, and many other factors to arm you with enough information to make the choice for yourself.
A
A
A
A
So,
specifically,
we
are
not
going
to
talk
about
any
cloud
provider
systems
and
comparisons
thereof.
If
you're
in
a
cloud
provider
you're
just
going
to
use
that
cloud,
provider's
storage
system
enough
said
end
of
story.
Likewise
we're
not
going
to
talk
about
the
vast
majority
of
the
csis
out
there.
By
the
way
there
are
over
150
of
the
things
which
are
mostly
just
vendor,
csis
adapter
layers,
which
let
you
use,
for
instance,
a
Synology
Nas
with
kubernetes
freely.
A
There's
no
point
in
talking
about
these:
if
you
have
those
systems
and
that's
all
you
want
out
of
them-
you'll
use
those
csis
and
that's
it.
So
what
we
will
try
and
discuss
is
an
overview
of
the
main,
open
source
storage
solutions
that
are
available
for
use
in
kubernetes,
open
source,
because
others
are
the
ones
which
can
be
analyzed.
A
So
in
general,
plan
of
attack
we'll
talk
about
the
types
of
storage,
the
three
of
them
location
and
quiet
matters
and
the
characteristics
related
to
it.
The
characteristics
of
storage
itself,
the
storage
interfaces
that
are
available
and,
finally,
the
contenders.
Those
projects
which
are
available
for
use
and
which
we're
here
to
evaluate
so
first,
the
types
of
storage,
mostly
these
coalesce
into
three
main
categories-
object,
stores,
block
stores
and
shared
file
systems.
A
Some
vendors
use
different
names
for
these,
but
functionally.
These
are
the
three
major
sets
of
storage
object.
Stores
are
basically
big
key
value
databases,
but
instead
of,
for
instance,
at
CD
designed
to
store
small
bits
of
data
they're
designed
to
store
arbitrarily
large
Blobs
of
data
files
and
the
like
media,
whatever.
What
have
you
they're,
based
generally
on
webtech,
which
lends
themselves
really
well
to
expansion?
For
read,
like
processes,
think
web
proxies
think
caching
systems
and
various
standardized
methods
in
webtech
to
be
able
to
scale
up
your
system
and
readability.
A
There
are
also
Network
native.
This
is
a
big
deal,
because
many
of
the
other
Solutions
try
to
adapt
some
level
of
local
storage
Concepts
to
their
Solutions.
Instead
object
stores
take
a
web,
focused
network-only
approach
to
all
of
their
interfaces,
so
they
have
no
Legacy
components
integrated
to
them,
as
I
said,
they're
easily
integrated
and
layered,
integrating,
for
instance,
an
authentication
system
of
your
own
or
using
one
of
the
third-party
authentication
systems,
easy
built-in
easy
to
integrate
with
the
rest
of
it.
A
Also
like
the
web.
However,
rights
are
more
difficult.
You
can't
just
simply
write
out
to
a
file
and
expect
it
to
be
stored
in
in
your
Object
Store.
Instead,
you
generally
have
to
use
some
kind
of
API
or
CLI
tool
to
get
it
there,
and
that
is
where
the
most
difficult
aspect
of
using
an
object
store
in
your
applications
are
very
few
of
them
exist
which
can
write
directly
to
those
object.
Stores.
A
The
main
downside
of
them
is
that
in
general
they
only
allow
a
single
attachment
to
a
pod
for
each
volume
at
any
given
time.
So
if
you
have
multiple
containers
that
need
to
read
and
write
to
a
block
store,
you
generally
need
to
bind
them
into
the
same
pod,
which
thankfully
kubernetes
or
allows
very
easily,
but
that
limits
your
articulation
and
scaling
between
those
containers
to
the
Pod
level.
A
They
can
also
be
made
to
offer
the
other
two
types
of
storage
keep
in
mind,
so
they
can
view
be
used
as
the
lowest
common
denominator
for
any
need.
Mineo,
for
instance,
is
able
to
provide
object,
storage
on
top
of
a
block
storage
and
likewise
their
various
NFS
providers,
which
can
provide
a
shared
file
system
on
top
of
a
block
store.
A
Finally,
shared
file
systems,
these
present
files
and
directories
across
a
number
of
nodes
as
a
file
system.
These
are
the
most
adaptive
and
the
most
constrained
to
Legacy
operations,
because
they
go
deep
into
posix
file
system
mechanics.
They
have
a
lot
of
assumptions
that
don't
map
well
to
the
network,
World
least
of
all
the
container
World.
There
are
always
locking
problems,
bottlenecks,
contention,
locks
and
slow
General
performance.
A
Nfs
is
you
has
been
used
for
decades,
it's
the
old
dinosaur.
It
will
work
when
nothing
else
works,
but
you
don't
ever
want
to
use
it
unless
you
absolutely
have
to
they
are.
These.
Are
the
easiest
possible
things
to
implement
and
that's
unfortunately,
usually
why
they're
chosen,
not
because
you
have
so
many
workloads
that
actually
need
active,
shared
files
in
sequence?
A
Location,
so
if
you're
in
a
cloud
as
I
said
before
you're
likely
to
be
using
the
cloud
provider
storage,
but
that's
only
for
single
Cloud
providers,
if
you,
for
instance,
have
systems
in
gcp
and
AWS
and
Azure,
you
might
appreciate
having
a
common
system
overlaid
on
their
storage
platforms,
that
you
can
then
modularly
stamp
out
to
other
systems,
and
that
is
a
possible
use
for
another
storage
system
on
top
of
it
in
cluster
and
out
of
cluster.
So
in
cluster
storage
systems
have
an
advantage
in
operational
consistency.
A
A
Finally,
keep
in
mind
that
storage
eats
up
a
lot
of
resources,
not
only
just
this
guy,
oh,
which
is
clear.
You
need
to
write
data
to
disks,
so
it
takes
some
of
your
disk.
I
o,
but
also
frequently
we'll
we'll,
take
CPU
usage,
RAM
usage.
You
have
contention
over
disk
IO,
and
this
is
one
of
the
big
Killers.
That's
often
invisible,
if
you're
not
very
careful,
taking
away
performance
over
your
applications,
so
the
there
is
an
advantage
to
keeping
data
storage
outside
your
cluster
to
be
able
to
more
easily
diagnose
performance
conditions,
characteristics
of
storage.
A
There
are
tons
of
these,
but
I've
tried
to
boil
these
down
into
three
main
categories:
Loosely
grouped
scalability
performance
and
cost,
so
scalability
is
represented
a
lot
by
the
architecture
of
the
storage
systems
themselves.
Traditionally,
the
best
we
had
was
something
like
a
traditional
raid
system.
You
had
RAID
0
raid,
one
raid
5
and,
if
you're
really
really
lucky
raid
6,
so
you
can
handle
two
discs
going
down
at
any
time.
A
Obviously,
as
the
systems
get
larger
and
larger
handling
single
points
of
failure
like
that
across
dozens
of
disks
and
the
likelihood
of
you
being
able
to
repair
those
within
the
cons
within
the
time
failure
zone
of
disks,
particularly
if
they're
the
same
skew,
is
really
daunting.
The
number
of
disks
that
you
have
that
I
have
personally
had
put
out
into
the
field
in
the
same
skew
all
failing
within
two
days
of
each
other
is
very,
very
common.
A
So,
yes,
there
are
ways
to
mitigate
this.
You
can
buy
from
different
batches
by
different
brands
of
drives,
etc,
etc.
But
fundamentally
the
system
is
limited.
Luckily,
we
don't
have
to
deal
with
traditional
raid
anymore.
There
are
many
other
options,
so
the
current
standard,
if
you
want
to
call
it
that
is
the
idea
of
a
SAS
system
with
perhaps
multi-tiered
SAS
expenders
to
extend
them
out.
These
are
typically
viewed
as
big
Bays
of
drives.
Just
a
bunch
of
disks.
A
You
can't
really
get
a
standard
SAS
system
larger
than
about
four,
a
few
petabytes
with
today's
technology,
today's
largest
drives
and
those
are
hard
drives
when
you
go
into
solid-state,
drives
it's
much
more
restrictive
both
on
the
interface
and
the
expansion.
So,
finally,
that
leaves
us
with
storage
clusters.
This
is
where
the
biggest
interesting
stuff
is
happening
in
the
storage
World.
A
These
try
to
eliminate
single
points
of
failure
so
that
you're
horizontally
scalable
all
tiers
of
the
system,
whether
it
be
the
controllers,
whether
it
be
the
block
Distributors,
whether
it
be
the
block
stores,
are
all
as
distributed
as
possible
and
in
many
cases
the
larger
the
cluster
becomes.
The
faster
it
goes
rather
than
constraining
the
same
resources.
A
A
You
frequently
have
highly
different
performance
characteristics
between,
say,
sequential,
reads,
sequential
rights,
random
reads:
random
rights,
mixed
loads,
where
you
have
sequential
and
random
reads
and
or
rights
and
finally
contentious
access.
Multiple
access,
older
Technologies,
for
instance,
really
don't
handle
multiple,
read
requests.
Etc
newer
systems
do
a
better
job,
but
it's
inherently
wildly
different
and
highly
workload
dependent,
so
benchmarks,
basically
can
be
manipulated
to
say
whatever
you
want
them
to
say,
unfortunately,
and
even
unintentionally,
so
so
that
you
can
easily
get
down
the
wrong
side.
A
That
said,
there
are
some
architectural
choices
that
do
matter
so,
as
I
said
before,
some
systems
speed
up
as
they
scale,
but
correspondingly
they're
slow
at
low
scale.
Some
systems
slow
down
as
they
scale
but
in
in
within
their
frame
of
reference,
can
be
much
faster
because
they're
highly
tuned
cost
I'm
using
in
a
very
liberal
term,
cost.
Yes,
disks
controllers
Hardware
they
have
a
real
dollar
value.
A
Cost,
but
when
you're
talking
about
storage,
these
systems
can
get
complex
very
quickly
and
the
complexity
of
the
system
itself
is
its
own
cost
administratively,
whether
you're
paying
that
directly
to
you
with
your
own
tax
or
whether
you're
paying
somebody
else
to
do
it.
The
complexity
of
each
system
has
its
own
cost
to
it.
Therefore,
of
course,
with
everything
we
want
to
keep
complexity
down
next
hard
drives
disk
drives.
Ssds
hard
drives
in
particular,
are
going
to
fail.
They
are
the
lowest
M
meeting
time
to
failure
of
any
component
in
the
modern
system,
including
fans.
A
They
will
frequently
fail
as
batches
as
I
said
before
they
can
fail
at
any
time.
If
you
get
scale
high
enough
drives
are
going
to
fail
every
day
or
every
week
you
have
to
have
a
plan
and
you
have
to
have
a
system
to
handle
Drive,
Replacements,
Within
These
systems
and,
lastly,
growth
and
scalability
the
more
centralized
the
more
fixed,
the
more
infrastructure
contained
and
less
horizontally
scalable.
A
Your
system
is
the
more
likely
you're
going
to
expand
to
a
point
at
which
your
infrastructure
can
no
longer
take
it,
and
you
suddenly
have
to
spend
tens
of
thousands
hundreds
of
thousands
of
dollars
to
completely
replace
that
system.
That's
otherwise
perfectly
happy
and
content
with
a
larger
system
for
more
capacity.
The
benefit
of
horizontal
scaling
is
huge
in
terms
of
cost.
A
So
the
storage
interfaces
mentioned
these
briefly
before
iSCSI.
It's
the
old
standard,
it's
kind
of
slow,
but
it's
also
somewhat
the
least
common
denominator:
lots
and
lots
of
vendors
use
it,
and
it's
generally.
Okay,
given
its
constraints
of
the
old
scuzzy.
However,
the
Linux
implementation
in
particular
open
iSCSI,
which
most
of
the
kubernetes
users
have
to
use.
A
A
There
are
several
that
we're
looking
at
several
that
that
use
nvmf,
nvmeof
they're
in
general,
like
nvme,
is
to
scuzzy
and
Sarah
cleaner,
simpler,
faster,
eliminating
a
lot
of
the
old
overhead
that
is
no
longer
necessary
and
it's
a
fairly
clean
approach
to
use
with
containers
and
thus
with
kubernetes
Seth,
has
its
own
set
of
internal
drivers,
adapter
layers,
so
RBD,
they're,
block
storage
and
cffs
their
file
storage
file
system
offering
are
both
in
kernel
and
relatively
easy
to
use
and
standardized.
Likewise,
NFS
used
to
have
all
the
problems
of
open
iSCSI.
A
It's
been
in
the
kernel,
however,
for
years
as
a
client,
it's
fairly
easy,
you
don't
need
anything
particular
to
manage
it
and
it's
well
integrated
directly
into
kubernetes
as
well.
Finally,
that
brings
us
to
the
contenders,
so
a
few
these
are
try.
These
are
attempted
to
group
by
category
roughly
so
that
we
can
think
of
these
in
the
ways
that
top
down.
We
might
want
to
consider,
first
of
all,
a
couple
categories
that
we
mostly
throw
out,
because
they
don't
matter
or
they
don't
have
enough
information,
one
huge,
the
largest
category
of
CSI
providers.
A
Sorry
I
haven't
defined
CSI
CSI
is
the
storage
container
storage
interface.
It
is
the
standardized
system
by
which
kubernetes
and
containers
interact
with
storage,
so
the
CSI
providers
provide
access
to
the
storage
and
using
a
standardized
interface.
So
these
vendor
adapters
are
basically
used
to
adopt
specific,
Hardware
or
specific,
hosted
services,
two
kubernetes
to
be
used
as
CSI
providers
for
the
storage.
It's
just
an
adapter
in
general.
A
You
they
don't
do
anything
they
don't
all
they
do
is
map
a
kubernetes
storage
volume
to
whatever
the
service
provider
or
Hardware
vendor
has
as
their
own
native
volume.
Hence
it's
not
particularly
interesting
to
talk
about
so
I've
probably
already
spent
too
much
time
talking
about
it.
Let's
move
on
proprietary
options,
so
proprietary
options,
as
I
said,
are
mostly
black
boxes.
There's
not
a
whole
lot
that
we
can
say
infrastructurally
what
they
are.
There's
no
easy
way
to
evaluate,
so
there's
not
really
a
whole
lot
of
mention
to
them.
A
I've
listed
a
few
here,
just
those
that
caught
my
eye
or
those
which
are
popular
enough
to
have
been
of
interest,
but
realistically
there's
no
way
for
me
to
fit
them
into
this.
Talk
so
bye,
local
storage,
so
local
storage
is
really
common
for
small
kubernetes
clusters
or
for
systems
that
really
just
need
to
throw
up
kubernetes,
Dev
environments
and
and
whatnot.
This
is
the
easiest
way
to
get
storage
in
kubernetes
and
thankfully,
now,
while
there
used
to
be
a
number
of
third-party
vendors,
persistent
local
volumes
are
built
into
kubernetes.
A
The
only
big
thing
to
know
about
local
storage
is,
of
course,
it's
node.
Local,
therefore
pods,
which
need
access
to
that
storage
have
to
be
scheduled
to
the
nodes
which
provide
it
again.
Kubernetes
now
handles
all
of
this.
You
don't
have
to
worry
about
it,
but
clearly
that's
not
a
scalable
solution.
You
have
pods
that
are
directly
bound
to
nodes,
so
you
want
to
avoid
that,
but
it
is
here.
It
is
available
as
a
simple
storage
solution
that
does
still
work
with
the
rest
of
the
kubernetes
semantics
for
accessing
storage.
A
There's
another
one
here
worth
mentioning
called
Topo
lvm,
which
allows
you
to
map
directly
lvm
volumes
into
kubernetes
fairly
easily
so
worth
knowing
about
shared
file
systems.
Nfs,
as
we
mentioned,
the
old
dog
that
has
never
learned
new
tricks,
we
have
glusterfs,
which
used
to
maintain
their
own
CSI,
but
now
is
just
provided
by
a
third
party
system
called
karalu.
If
I'm
pronouncing
that
correctly,
who
knows
this
is
an
in-cluster
operator
for
gluster
FS,
Sometimes
gluster,
some
gluster
FS.
A
It's
an
aggregating
shared
file
system
that
is,
it
Aggregates,
a
number
of
different
back-end
storage
units
into
a
common
Point.
That's
then
exported
as
a
as
a
shared
file
system.
It's
reasonably
simple.
There
aren't
a
whole
lot
of
guard
rails.
You
can
do
the
wrong
thing.
It's
very
common,
even
in
the
docs,
for
them
to
recommend,
for
instance,
that
two
node
system,
which
is
in
cluster's
crazy.
It's
like
running
a
two
node
SCD
cluster,
it's
worse
than
running
a
single
node,
except
for
your
data.
A
Integrity
availability
is
a
takes
a
down
spiral
with
only
two,
but
regardless
you
can
do
it
correctly
and
in
general,
it's
fairly
easy
to
use.
Cefs
is
the
shared
file
system
of
ceph,
which
I'll
talk
about
later,
when
we
talk
about
storage
clusters,
pooling
and
aggregating
systems.
So
these
are
relatively
simple.
All
they
really
do
is
group
underlying
storage
providers
into
a
common
face
that
can
be
presented
to
kubernetes,
either
as
block
devices
or
as
object
stores
or
as
shared
file
systems.
A
Three
worth
mentioning
here:
the
virtual
disk
array,
which
is
a
fairly
low
level
system
based
on
nvmeof,
which
just
takes
a
number
of
different
storage
providers
and
repackages
them
up
as
virtual
disks
that
kubernetes
can
use
directly.
However,
there's
not
a
whole
lot
of
tooling
here,
so,
if
you're
the
kind
of
person
who
likes
to
build
their
own
tooling,
these
make
com
good
tools
to
start
with,
but
there's
no
operator,
there's
no
provisioning
system.
You'd
have
to
build.
All
of
that
yourself.
A
Mineo
is
like
I
said
the
object
store
engine
it
can.
It
has
a
huge
variety
of
underlying
stores,
both
physical
and
service
oriented
that
can
be
tied
into
their
system.
It
Aggregates
and
re-exports
as
a
standard,
Object
Store,
which
speaks
S3
linstore,
is
a
really
popular
one,
because
it
is
relatively
simple
for
as
many
moving
Parts
as
it
has
it's
highly
plugable,
with
lots
of
different
providers
at
each
level
of
its
offering,
and
it's
somewhat
aggregative.
It's
somewhat
replicative.
A
It's
based
on
the
same
people
that
made
drdb,
which,
if
you
know
from
decades
ago,
was
a
Master
failover
System
for
replication
of
storage.
It
goes
beyond
that
now
and,
like
I
say
there
are
various
providers
for
a
number
of
systems.
They
support
nvmeoe,
they
support
iSCSI
and
they
even
support
NFS
I
believe
they
do
a
lot
of
things
in
a
lot
of
plugability.
So
it's
a
very
flexible
solution,
but
still
primarily
not
really
a
horizontally
scalable
storage
cluster.
A
It's
more
a
pooling
and
aggregating
system
that
leads
us
to
the
first
storage
clusters,
so
the
base
the
most
basic
of
these
is
probably
the
family
of
providers.
Loosely
grouped
under
the
EBS,
the
open,
ABS
name.
Openabs
says
the
name
might
imply,
is
built
to
be
modeled
after
Amazon's
elastic
block
storage,
and
these
are
just
block
stores.
They
are
mostly
limited
to
just
replication
and
not
really
a
whole
lot
of
topology
awareness,
topology
controls
to
them.
C-Store
is
the
oldest
engine
available
the
original
engine
for
open
ABS.
A
It
is
I,
understand
the
ZFS
based
it's
an
iSCSI
standard.
Pardon
me,
sorry,
a
nice
guzzy
standard,
so
that
means
you've
got
to
deal
with
all
the
open
iSCSI
junk,
but
it
is
rugged
it's
well
tested
and
it's
relatively
slow.
Jiva
is
somewhat
of
a
step
side.
A
stepchild
I've
never
actually
seen
any
reason
to
run
it.
It
was
intended
to
be
a
modernization
of
c-store.
It
mostly
just
replaces
the
client
interface
for
iSCSI,
with
a
newer
go
based
one,
but
still
requires
open
iSCSI
on
the
server
side.
A
So
it's
hard
to
see
what
the
point
there
is
some
performance
Advantage,
but
it
is.
It
is
the
second
generation
that
was
kind
of
lost
in
the
move
to
Maya
store.
There
is
also
a
longhorn.
It
looks
like
it
cut
off
that
slide,
I
apologize.
This
is
ranchers
offering
that
was
originally
based
on
open
EPS,
but
it's
kind
of
been
Rewritten
in
various
phases,
its
by
Rancher.
It's
basically
for
rancher.
A
If
you're
running
wrencher,
it
makes
probably
some
sense
to
use
Longhorn
I'm,
not
a
Rancher
user,
so
I
can't
really
speak
a
whole
lot
to
it.
I've
never
been
able
to
get
it
up
and
working
on
anything
else.
It's
again
for
some
reason,
despite
them
talking
about
it
for
a
long
time
getting
off
and
off
off
of
iSCSI,
they
didn't
they're
still
iSCSI,
so
I,
don't
really
think
much
about.
Oh
there's,
the
longhorn
I
just
clipped
it
on
the
other
one
anyway.
A
Lastly,
in
open
EPS
Maya
store
it's
the
shiny
new
thing:
it's
written
in
Rust.
It
has
NVM
eof
native
support.
It
even
has
Nick's
development
files,
which
makes
working
with
it
on
certain
operating
systems
like
makes
really
nice
and
pleasant.
It's
also
very
new
1.0
was
only
released
this
year
and
along
with
it,
a
bunch
of
breaking
changes.
They
have
had
many
of
those
and
actually
running.
These
in
production
has
been
difficult,
but
not
impossible.
A
A
Their
docs
have
historically
had
a
lot
of
problems.
It's
made
installation
difficult
and
some
point
along
the
line
in
their
development.
They
decided
that
you
know
it's
easier
if
people
just
use
external
hcd,
which
unfortunately
has
the
problem
of
well.
Okay,
if
I
have
an
external
LCD.
That
means
I
need
external
storage.
How
I'm
going
to
store
storage
to
get
my
storage
system
up
their
answers?
You
can
use
local
storage
and
then
you're
back
to
being
bound
by
nodes
at
whatsoever,
but
anyway,
open
EPS
is
really
common.
A
And
this
I
haven't
had
much
time
to
play
with
it
called
seaweed
FS,
which
is
curiously
based
on
radus,
which
is
the
same
thing
that
ceph
is
based
on
for
its
object
storage,
but
it's
designed
to
be
simpler
and
more
focused
specifically
to
Containers
it's
it's
like
a
re-envisionment
of
ceph
in
a
modernization
and
simplification.
I
haven't
had
a
whole
lot
of
time
to
play
with
it.
It
looks
interesting.
It's
got
a
very
diverse
set
of
people
working
on
it,
I'm
intrigued,
but
not
a
whole
lot
of
data.
A
I,
don't
know
anybody
yet
who's
used
it,
but
it
is
interesting.
Finally,
there's
Seth
Seth
is
the
big
everything
it's
complex
to
start.
There
are
a
lot
of
moving
pieces
to
it.
There
are
a
lot
of
tunable
parameters.
It's
highly
topology
aware
it's
very
rugged.
It's
well
tested
it's
very
old,
but
it's
also
kept
in
update.
There
have
been
numerous
updates
to
make
it
work
much
better,
with
nvme
drives
and
take
advantage
of
various
systems.
A
A
Lastly,
we
have
the
Rook
packagement
of
Seth,
so
running,
Seth
directly
can
be
pretty
heavy
load.
Rook
allows
you
to
package
that
up
into
an
operator
that
you
can
run
directly
on
kubernetes.
It
generally
makes
self-administration
very
easy.
You
trade
some
control
in
exchange
for
that
automation,
though
so
running
out
of
time,
so
trying
to
get
down
to
the
comparison
table
here.
To
give
you
an
idea
of
how
scientifically
and
mathematically
based
this
is
I've
used
some
Emoji
to
make
it
a
little
better
anyway,
there's
a
lot
here.
A
We
don't
really
have
time
to
cover
a
whole
lot,
but
this
will
be
available
on
the
slides
after
the
session,
if
I
can
just
end
with
what
I'd
call
an
executive
summary.
If
you
just
want
to
pay
somebody
else
to
handle
it,
and
you
don't
want
to
deal
with
it.
In-House
Port
Works
seems
to
be
about
the
most
popular
purely
commercial
solution.
A
A
A
Stability
over
everything
else
runs
Seth
on
its
own
bear
on
an
outside
the
kubernetes
cluster
set
of
machines,
and
you
will
be
great
otherwise,
and
this
is
what
I
do,
despite
having
used
ceph
for
more
than
a
decade,
use
Rook
to
package
up
yourself
and
run
it
in
cluster
and
just
be
done
with
it
all
right.
Well,
thanks
for
attending
again,
Sean
McCord,
if
I
have
any
time
at
all,
I
will
try
to
get
to
questions.
A
How
does
gluster
compare
to
luster
luster
luster?
Yes,
sorry
yeah,
so
luster
luster
is
an
old
story.
Luster
is
a
is
so
luster
and
Intermezzo
I
used
or
tried
to
use
back
in
the
90s
and
2000s.
So
as
far
as
I
know,
I'm
not
aware
of
any
kubernetes
adapters
for
luster,
there
may
be
I
just
haven't
run
across
any
of
them.
I
mean
it
is
mostly
old
old
tech.