►
From YouTube: Cloud Native Storage: Storage TAG intro, Projects, Landscape & T... Alex Chircop & Raffaele Spazzoli
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
云原生存储：存储 TAG 介绍、项目、经管和技术 | Cloud Native Storage: Storage TAG intro, Projects, Landscape & Technology - Alex Chircop, StorageOS & Raffaele Spazzoli, RedHat
本此讨论将介绍 CNCF 的存储 TAG，并讨论 TAG 如何运作，我们如何运用存储 CNCF 项目展开工作，以及为生态系统构建指南和编写白皮书的项目。在此讨论中，我们将介绍：对 TAG 的概述，如何加入以及如何提供帮助——CNCF 中存储项目的概述——目前正在审查的项目。我们还将分享我们近期工作的最新进展，包括：CNCF 存储环境白皮书、业绩与基准测试白皮书、云原生灾难恢复白皮书
This talk will introduce the CNCF Storage TAG and discuss how the TAG operates, how we work with Storage CNCF projects as well as the projects to build guidance and write whitepapers for the ecosystem. During this session we will cover: - Overview of the TAG, how to join and how to help - Overview of storage projects in the CNCF - Projects that are currently being being reviewed. We will also share updates of our latest work including: - the CNCF Storage Landscape whitepaper - the Performance and Benchmarking whitepaper - the Cloud Native Disaster Recovery whitepaper
B
C
A
Brilliant
thanks
everyone.
So
thank
you
for
joining
this
storage
tag.
Presentation
we're
going
to
be
talking
today
to
cover
a
wide
variety
of
topics,
but
we
want
to
cover
what
the
tag
does
and
and
how
you
can
join
in
and
help.
We
work
a
lot
with
a
number
of
the
storage
projects
in
the
cncf,
so
we'll
cover
the
projects
that
we
work
with
and
the
and
the
ones
which
are
being
reviewed,
we'll
also
as
part
of
the
tag
where
we
also
prepare
a
number
of
different
documents.
A
A
A
A
So
what
do
we
do?
What's
the
key
purpose
of
the
tank?
The
tag
is
there
to
help
scale
the
the
the
toc
right,
so
so,
the
the
main
function
for
us
is
is
to
help
provide
education
to
our
end
users
in
the
form
of
white
papers
and
and
documents
and
work
on
the
projects
and
review
projects
and
provide
guidance
on
to
to
the
projects
for
the
for
the
toc
and
primarily
act
as
as
an
extension
of
the
toc
for
for
the
technical
subject
matter.
A
A
And
then
finally,
graduation
is
for
it's
for
the
most
mainstream
production
use
project
projects.
You
know
and
includes
things
like
kubernetes,
for
example,
and
and
prometheus
and
graduated
projects
also
benefit
from
additional
levels
of
maturity,
like
security
or
audits,
and
and
have
some
future
proofing
in
terms
of
making
sure
that
there
are
multiple
organizations
that
are
supporting
them.
And
so
you
know
as
part
of
the
as
part
of
the
toc
as
part
of
the
help
that
we
provided
the
toc.
A
So
some
of
some
of
the
time
we'll
be
just
doing
discovery
and
outreach
to
to
kind
of
the
projects
and
and
other
times
we're
specifically
helping
the
the
the
toc
and
working
with
the
member
of
the
toc,
a
sponsor
from
the
toc
to
to
actually
review
the
projects.
One
of
the
one
of
the
important
points
is
that
you
know
we
we
operate
in
a
consultative
mode
and,
and
ultimately
the
toc
have
the
have
the
final
say
in
in
every
decision
and
once
the
toc
has
voted
on
on
those
projects.
A
It
goes
to
a
public
vote
for
for
for
a
final
review.
Of
course,
you
know
the
other
thing
is.
We
would
be
nothing
without
the
end
users
and
the
community,
so
we
we
try
our
best
in
in
the
in
the
way
of
surveys,
but
also
you
know
reach
out
in
in
these
sort
of
virtual
events,
to
to
gather
your
input
and
feedback
and
and
understand,
try
and
understand.
A
I
talked
a
little
bit
about
about
the
the
sort
of
expert
advisor
status
that
we
hold
it
with
the
toc,
where
we
help
with
with
the
due
diligence
for
reviewing
projects,
but
we
also
periodically
check
in
with
with
some
of
those
projects
and
and
do
reviews
on
on
their
health,
etc.
But
again,
as
always
in
all
cases,
the
toc
will
make
the
final
decisions
on
those
on
those
projects.
B
B
Zhuk
supports
multiple
storage
solutions,
each
with
a
specialized
kubernetes
operator
to
automate
management.
It
has
a
stable
support
for
staff
and
alpha
support
for
cassandra
and
nfs
lettuce
is
a
graduated
project.
Vitas
is
a
database
clustering
system
for
horizon
horizontal
scaling
of
mysql
vitas
supports
mysql,
procurena
and
mariadb
databases.
B
Is
a
graduated
project?
It's
a
distributed
key
value
store
that
provides
a
reliable
way
to
store
data
across
a
cluster
of
machines.
All
kubernetes
clusters
use
etcd
as
their
primary
data
store.
It
handles
storing
and
replicating
data
for
kubernetes
cluster
state
and
uses
the
raft
consensus
algorithm
to
recover
from
hardware
failure
and
network
partitions
kv
is
a
graduated
project.
B
B
B
Cache
log
image
distributions
at
very
large
scales
for
dragonfly,
no
matter
how
many
clients
start
the
file
downloading
the
average
downloading
time
is
almost
stable
without
performance
penalties.
We
also
have
longhorn,
which
just
became
an
incubating
project.
Longhorn
is
a
distributed
block
storage
system
for
kubernetes.
It
is
built
using
kubernetes
and
container
primitives.
B
B
B
Next,
please
study
systems
have
several
storage
attributes,
availability,
scalability,
performance,
consistency
and
durability.
Availability
defines
the
ability
to
access
the
data
during
failure.
Conditions
scalability
can
be
measured
by
the
ability
to
scale
the
number
of
clients,
throughput
or
number
of
operations.
B
B
B
Next,
please,
there
are
several
storage
layers
that
can
impact
the
storage
attributes,
for
example,
rather
than
directly
access
resources,
a
hypervisor
can
provide
access
to
resources
which
could
add
access.
Overhead
storage
topology
describes
the
arrangement
of
storage
and
compute
resources
and
the
data
link
between
them.
These
include
centralized
distributed
sharded
and
hyper-converged
topologies
solid
systems,
uav
have
data
protection
layer
which
adds
redundancy.
B
This
refers
to
raid
erasure
coding
and
replicas.
3D
systems
usually
provide
data
services,
in
addition
to
the
core
storage
functions,
including
replication
snapshots,
clones
and
so
on.
So
this
system
ultimately
possesses
data
on
physical
storage
layer,
which
is
usually
number
of
tire.
It
has
impact
on
overall
performance
and
long
term
durability.
B
Next,
please,
in
this
diagram,
you
can
see
that
the
workloads
consume
storage
through
different
data
access
interfaces.
There
are
two
categories
of
data
access
interfaces
here
we
call
them
volumes
and
api
container
obstruction
system
has
interfaces
for
volumes
which
supports
both
blog
and
file
systems
in
kubernetes.
There
are
two
wording:
modes
file
system
and
block
first
system
mode
allows
workloads
to
consume
file
system
directly,
underneath
it
can
be
either
file
or
block
interface.
B
B
Note
that
there
is
a
kubernetes
seek
storage,
sub
project
called
cosy
container
object,
storage
interface,
which
introduces
kubernetes
apis
to
support
orchestration
of
object,
store
operations
for
kubernetes
workloads.
It
also
introduces
cozy
as
a
set
of
grpc
interfaces
so
that
a
object,
storage
vendor
can
write
a
driver
for
provisioning
accessing
object
source.
B
B
B
B
The
darker
green
box,
here
control,
plane
interfaces
refer
to
storage
interfaces
directly
supported
by
seos,
including
container
storage
interface,
csi
darker
volume,
driver
interface
and
so
on.
Csi
has
three
grpc
services,
controller,
node
and
identity
services,
identity
service
provides
info
and
capabilities
of
a
plugin
control.
Service
supports
functions
such
as
create
and
delete
volume
attach
and
detach
volume,
and
so
on.
B
The
orange
box
here
is
called
frameworks
and
tools.
This
is
an
extension
of
control,
plane
interfaces
for
application
api,
including
key
value,
store
and
databases.
Ceos
currently
don't
have
direct
interfaces
for
it
yet,
but
some
frameworks
and
tools
have
support
for
them.
For
example,
zhu
supports
cassandra.
A
Brilliant
thanksgiving,
so
we'll
talk
a
little
bit
about
the
performance
white
paper
when
we
were
looking
at
the
landscape
in
the
storage
space
and
we
categorize
those
different
those
different
attributes.
One
of
the
one
of
the
key
attributes
that
we
wanted
to
also
cover
in
further
detail
was
was
performance
and
then
later
on
things
like
data
protection
and
disaster
recovery
which
which
raphael
will
cover
next,
but
in
the
performance
white
paper.
A
But
right
now
we
focused
on
on
volumes
in
terms
of
you
know,
some
of
the
things
that
it
wants
to
look
at
like
the
latency
or
the
the
number
of
operations
or
the
the
number
of
the
the
throughput
for
those
volumes,
and
then
also
databases
in
terms
of
you
know
things
like
the
the
transaction
overheads.
But,
of
course,
also
the
the
functions
like
latency
and
and
other
benchmarks
related
to
transactional,
reads
and
and
and
rights
within
within
an
environment.
A
So
it's
we
actually
spent
quite
a
bit
of
time,
defining
some
of
the
common
pitfalls
and
and
other
considerations
that
are
that
are
important
in
understanding
their
impact
on
the
performance
of
the
system.
So
at
a
very
basic
level,
for
example,
differentiating
between
the
number
of
operations
versus
the
number
of
the
versus
the
the
throughput
based
on
you
know
other
other
factors
within
within
the
test.
A
So,
for
example,
if
your
test,
if
you
want
to
test
the
number
of
operations
for
lots
of
little
objects
or
smaller
block
sizes
versus,
for
example,
throughput
where
you
you
might
want
to
be
testing
with
larger
block
sizes
and
and
factors
like
and
and
and
factors
like
concurrency
too,
the
the
other.
The
other
aspect
that
which
is
which
is
really
important,
is
you
know
the
data
services
which
again
talks
on
in
in
those
different
layers
and
how
they
affect
the
the
performance.
A
But,
of
course
you
know
the
methods
which
are
used
for
data
protection,
whether
it's
things
like
erasure,
code
or
or
or
replicas,
for
example
the
compression
algorithms
that
might
be
used
in
data
reduction
and
things
like
thin
provisioning,
but
also
the
overheads
used
to
protect
the
data
like
in
encryption
and
in
all
of
these.
In
all
of
these
factors,
you
know
there
are
also
some
more
complicated
things
that
that
come
into
play
so,
for
example,
understanding
the
the
different
q
depths,
but
also
making
sure
that
the
bottlenecks
aren't
happening.
A
A
So,
for
example,
you
know,
we've
seen
many
many
times
benchmarks
revealing
numbers
where
the
the
the
results
far
exceeds
the
capabilities
of
the
storage
system
or
whether
that's
a
volume
or
a
database,
and
and
that's
typically,
because
the
workload
is
smaller
than
the
size
of
the
cache
and
therefore,
in
reality,
the
the
benchmark
is
really
only
testing
the
speed
of
the
cache
rather
than
the
speed
of
the
of
the
storage
system.
Of
course,
with
all
of
these
things,
managing
the
environment
and
understanding
the
headroom
in
your
environment
is
also
key.
A
So
in
summary,
the
the
important
takeaway
is:
don't
don't
use
published
results
because
they're
very
rarely
useful
for
for
making
comparisons.
It's
extremely
hard
to
compare
published
results
in
an
apples
to
apple's
way
without
a
deep
understanding
of
the
test
conditions,
and
we
would
always
recommend
that
you
run
your
own
tests
on
your
own
applications
within
your
own
environment,
because
that's
really
the
only
way
that
that
you're
going
to
be
able
to
get
a
real
life
representation
of
of
of
what
you
want
of
what
you'll
be
able
to
achieve
in
your
own
environment.
A
The
performance
document
is,
is
still
open
for
a
review
and
we'd
love
to
hear
your
input
on
this
and
and
maybe
have
any
suggestions.
Would
we
would
love
to
hear
from
you
and
now
I'll
hand
over
to
rafaele
who's
going
to
cover
clown
native
disaster
recovery,
which
is
the
latest
white
paper?
We've
been
working
on.
C
Thank
you
alex
and
thanks
everybody
for
coming
today.
This
white
paper
is
in
this
white
paper.
We
submit
to
your
attention
the
the
concept
of
clarinet
disaster
recovery,
it's
an
approach
to
organizing
your
disaster,
recovery
strategy
and
for
for
applications
for
your
applications,
and
we
think
it's
it's
it's
an
alternative
to
more
traditional
disaster
recovery
approaches,
it's
something
that
clown
native
clowning
best
practices
enable
today
and-
and
I
think
it's
something
you
should
consider.
I
think
it's
something
you
should
consider.
C
C
C
C
We
what
we
all
what
we
usually
find
is
an
active
passive
type
of
deployment.
Really
we
find
companies
that
have
the
ability
to
do
active,
active
across
data
centers
or
across
regions
with
cloud
native
disaster
recovery.
We
say
that
you
have
to
you,
you
do
active
activity,
we
we
do
activate
it
with
cloning
just
recover.
Another
difference
is:
how
do
we
detect
that
we
are
in
a
disaster
situation
with
disaster
recovery?
Traditional
disaster
recovery?
You?
Usually
the
decision
is
made
by
a
human.
It's
a
human
decision.
C
You
know
there
is
a
maybe
an
emergency
room
or
a
situation
room
where
many
people
are
are
meeting,
and
somebody
says:
okay,
we
are
really
not
disaster.
We
need
to
trigger
the
disaster
recovery
decision.
We
need
to
trigger
the
disaster
recovery
procedure,
inclinated
disaster
recovery.
The
software
needs
to
realize
that
there
is
a
problem
and
and
triggered
the
dr
procedure
automatically
or
autonomously,
and
then
the
procedure
itself
in
traditional
disaster
recovery
is
usually
a
mixer
manual
and
automated
tasks,
like
I
said,
the
trigger,
is
definitely
manual.
C
That
is
the
thing
that
you
that
actually,
this
com,
many
companies
test,
maybe
once
a
year
or
a
couple
of
times
a
year
right,
but
in
cloud
native
disaster
recovery
everything
must
be
absolutely
automated
and
then
the
two
main
metrics,
by
which
you
measure
your
sla
for
disaster
recovery,
which
are
rto,
recovery,
time,
objective
and
rpo.
They
respectively
measure
the
downtime
of
your
service
and
how?
Back
in
time
you
go
the
amount
of
data
loss,
the
amount
of
data
loss,
measured
in
time,
the
amount
of
transactions
that
were
lost
because
of
the
disaster.
C
So
for
for
the
downtime
in
traditional
disaster
recovery,
you
can
have
from
close
to
zero
two
hours,
depending
on
how
good
you
have
organized
how
well
you
organize
your
your
workloads
for
current
native
disaster
recovery
and
it's
gonna
be
close
to
zero
and
it
really.
We
cannot
have
zero
because
there
are
some
health
checks
that
need
to
trigger
and
traffic
needs
to
be
redirected
to
the
healthy
locations.
C
But
it's
really
we
measure
it
in
in
a
matter
of
seconds
and
for
rpo,
so
the
data
loss
in
traditional
disaster
recovery,
you
can
have
close
from
zero
to
hours
again,
depending
which
approach
you
adopt
and
in
cloud
native
disaster
recovery.
It's
going
to
be
zero
if
you
use
strongly
consistent
workloads
and
something
that
is
theoretically
unbounded,
but
on
in
normal
situations,
very
close
to
zero
for
eventual
consistent
deployments
and
then
moving
a
little
bit
out
of
the
technical
aspects
and
talking
about
organizations
and
ownership
concerns.
C
Disaster
recovery
is,
is
formally
owned
by
the
application
team,
but
in
reality,
in
many
traditional
many
traditional
enterprises.
What
this
application
team
do
they
turn
around
talk
to
the
storage
team
and
ask
what
kind
of
sla
can
you
provide
for
storage
and
then,
whatever
the
storage
team
answer?
That's
also
that
that's
what
also
is
adopted
by
the
application
team.
So
essentially
the
storage
team
drives
the
disaster
recovery
for
everybody.
C
For
for
all
the
applications
in
inclinative
disaster
code
in
clarinet,
we
just
recovered
the
the
application
team
is
clearly
the
owner
of
of
the
disaster
recovery
process
and
they
have
to
pick
the
right,
middleware,
the
right
storage
component
to
be
able
to
to
be
able
to
perform
the
disaster
recovery.
The
way
they
need
and
then
another
thing
that
we
found
actually
creating
this
cloud
native
business
recovery
infrastructure
is
that
for
traditional
vr.
C
The
capabilities
to
that
enable
us
to
build
these
disaster
recovery
procedures.
Architectures
and
procedures
are
coming
from
storage,
typically
in
the
form
of
the
cap
and
restore
or
volume
replication,
whether
synchronous
or
a
singles,
but
in
cloud
native
disaster
recovery.
The
capabilities
that
we
need
come
mostly
from
networking
and
if
they
are
in
the
form
of
east-west
communication,
by
which
we
mean
the
ability
of
our
data
centers
of
our
region,
to
communicate
horizontally
to
east
west
and
in
the
form
of
a
global
advancement.
C
C
C
And
then
we
talk
about
consensus
protocols,
which
is
what
allows
all
of
the
the
instances
of
these
distributed
workloads
to
coordinate
within
with
each
other
and
then
in
the
final
part
of
the
white
paper.
We
have
some
reference
architectures
on
on
this
cloud
native
disaster
recovery
approach.
In
particular,
we
have
two
architectures
for
strongly
consistent
workloads
and
all
deployments
and
events
are
consistent.
But
let's
slide
this.
C
C
So
so
maybe
I
should
is
that
not
all
of
the
workloads
state
of
workloads
can
be
used
this
this
way
right,
you
need
to
pick
the
right
middleware.
We
give
you
some
criteria
on
what
what
to
look
for
but,
and
then
this
there
is
this
list.
It's
not
meant
to
crown
kings,
it's
just
a
set
of
a
set
of
products
that
we
have
analyzed
and,
as
you
can
see
we
in
this
table,
we
show
what
is
the
replica
I
can.
C
The
concession
protocol
used
for
replicas
and
paxos
and
rafts
are
the
most
popular
and
then
what
is
the
consensus
protocol
used
for
synchronizing
inter
shard
transactions
next
slide,
and
this
is
an
example
of
the
reference
architecture
in
this
case
it's
a
reference
architecture
for
a
kubernetes
deployment
and
for
a
strongly
consistent
workload,
and
so
here,
if
you
can
see
my
point
there,
we
have
the
workload
the
safety
workload.
This
could
be
a
database
could
be
a
key
value
store.
It
could
be
a
cache
as
you
can.
As
you
can
see,
we
have
several
data
centers.
C
C
And
so
you
will
have
the
same
behavior
that
happens
when
there
is
a
disaster,
and
so
traffic
will
go
to
the
healthy
location
and
again,
the
the
clients
will
not
experience
an
interruption
of
service
or
a
an
inconsistent
behavior
because
of
the
the
state
is
never
never
drifts
into
inconsistent,
inconsistent,
split,
split,
brain
scenarios
and
I
think
that's
it
for
the
clowning
filter
white
paper.
So
back
to
you,
alex.
A
We
have
our
github
repo,
which
which
contains
all
the
links
to
our
meeting
requests
our
meeting
minute
signing
and
our
recordings
and
again
to
remind
you.
You
know,
if
you're
interested
at
all
in
how
you
manage
storage
things
like
block
stores,
file
systems,
object,
stores,
key
value
stores,
databases
and
all
the
topics
around
that
related
to
things
like
performance
and
disaster,
recovery
and
and
scalability
of
cloud
native
environments.
We'd
love
to
hear
from
you
and
everybody
is
welcome.
So
thanks
again
and
we're
happy
to
answer
your
questions
now,.