►
Description
Running highly-resilient, highly-available applications in the world of multicluster, cross-region, multicloud compute is a challenge in itself, but what happens when your application needs persistent data? What does a live, cross-cluster application look like with persistent data? What about backup and disaster recovery? John Strunk and Tesshu Flower join the Cloud Multiplier to talk about VolSync’s story. VolSync provides Kubernetes-native data mobility for data distribution, application migration, and disaster recovery. Join us as we learn about VolSync and scale databases, persisted applications, and more across clusters securely, quickly, and seamlessly!
A
A
A
A
C
Yeah
sure
thanks
Gurney,
so
yeah
I'm,
I'm,
John
Strong
I've,
been
at
red
hat
for
about
five
years
and
pretty
much
all
that
time.
I've
kind
of
been
working
at
the
intersection
between
containers
and
Storage
and
ballsync
is
kind
of
the
the
latest
project
that
I've
been
working
on,
and
you
know
it's
something.
A
D
Thanks
Kenny
I'm
tashu
flower
and
prior
to
joining
red
hat
I
I
was
at
IBM
working
on
operators
and
policy
kind
of
operator
work,
but
I've
been
at
Red,
Hat
I
just
realized.
It
was
just
over
a
year
now
I
joined
last
October,
beginning
of
last
October,
so
I've
been
working
with
the
ACM
team
and
and
John
as
well,
and
it's
been
really
cool
to
to
learn
ballsync
as
they
go.
It's
a
really
cool
project
and
I'm
still
just
getting
started
with
contributing
to
it.
A
Yeah,
that's
awesome
a
little
bit
of
background
here
myself,
especially
because
I
was
working
through
the
connection.
Issues
was
asking
so
many
good
questions
about
fall.
Sync,
so,
hopefully
Jody.
If
you
remembered
all
of
those
for
the
show
today,
but
I
think
to
hit
the
stage
all
I
know
about
is
that
we
were
scheming
to
run
a
multi-cluster,
multi-availability
Zone
I
think
it
was
a
Minecraft
server
a
while
ago,
with
a
leg.
C
Yeah
there
is
there's,
definitely
some
work
going
on
there.
So
you
know,
odf
has
been
busy
putting
in
Disaster
Recovery
capabilities
for
the
the
storage
that
they
provide.
With
that
I
know,
you
know,
teshu
has
been
very
involved
sort
of
going
between,
you
know,
fall,
sync
and
and
the
odf
engineering
teams
and
yeah
so
right
now.
C
Well
so
the
the
ramen
operator,
an
orchestrator,
is
something
that
we're
going
to
mention
a
little
bit
later,
but
that
largely
comes
out
of
the
the
odf
team
and
yeah
we're
we're
working
on
a
collaboration
right
now
to
provide
disaster
recovery
for
CFS
right,
which
is
part
of
the
the
odf
suite
and
to
use
falsync
to
do
that.
Wow,
and
you
know
that's
something
that
teshu
can
probably
provide
some
more
detail
on,
because
I
know
he's
really
been
working
with
them.
A
A
A
C
And
yeah,
so
you
know
getting
the
moving
applications
around
is,
you
know,
is
fairly
easy
right
across
clusters
and
stuff
like
that,
because
you
know
it's
kind
of
a
handful
of
of
yamls
and
and
you
can
bring
it
up
right,
but
once
you've
got
the
data
involved,
it
really
becomes
difficult
to
to
kind
of
orchestrate
all
that
awesome.
Well,
I.
C
C
So
before
I
get
really
into
the
details
of
you
know:
Evol
sync:
what
really
drove
this
is.
You
know
this
notion
of
application
migration
right.
So
you
know
a
lot
of
organizations
have
multiple
clusters
now
right,
whether
it's
you
know
just
different
regions
in
the
same
cloud
or
you
know,
they're
actually
multi-cloud,
where
you
know
they're
trying
to
spread
their.
You
know
spread
their
eggs
across
multiple
different
Cloud
providers
and
then
you
know
bringing
in
their
their
on-prem
data
centers.
C
You
know
in
addition
to
that
right
and
they
need
it
to
all
really
work
together
and
they
need
to
be
able
to
move
their
applications
around
between
those
clusters,
and
you
know
there's
multiple
reasons
for
that
right.
It
may
just
be
simply
a
case
of
of
Trying
to
minimize
cost
right
or
they
want
to
deploy
their
application
near
where
the
customers
are.
So
they
can
optimize.
C
You
know
the
delivery
of
of
that
application,
the
service
that
they're
actually
providing
and
then
there's
sort
of
the
more
traditional
case
where
they're
just
after
you
know,
simple
Disaster,
Recovery
right
I've
got
two
sites
and
I
need
to
make
sure
that
if
something
happens
to
my
primary
site,
I
can
get.
You
know
my
application
back
up
at
the
secondary,
and
you
know
whenever
you
start
to
look
at
at
this
sort
of
application
movement.
C
You
know
it's
it's
reasonably
easy
with
stateless
apps
right,
you
know
in
in
sort
of
a
kubernetes
or
openshift
environment.
You
know
your
app
is
largely
just
defined
by
a
handful
of
yaml
and
we've
got
these
great
get
Ops
workflows,
and
so
it's
pretty
easy
to.
You
know
like
in
advance
cluster
management,
just
sort
of
tag,
my
app
and
tag,
my
cluster
and
hey
everything
moves
right,
but
as
soon
as
we
start
and
introduce
data-
and
you
know
have
that
sort
of
persistence
tied
to
the
application.
C
And
if
what
we
do
is
you
know
sort
of
look
at
how
data
is
you
know,
kind
of
moved
today
or
or
you
know
how
we've
traditionally
done
the
data
movement?
What
we've
really
done
is
relied
on
the
storage
system
and
storage
system
vendors
to
provide
support
for
that
data.
Mobility-
and
you
know
that's
sort
of
comes
about
because
of
historical
reasons
right,
because
you
know
kind
of
how
we
wanted
to
do
in
the
past.
C
You
know
on-prem
and
so
saying.
Well,
you
know
you've
got
to
use
the
same
storage
provider
in
both
places.
That
just
doesn't
make
sense
right,
because
it's
not
going
to
be
it's
not
going
to
be
the
right
solution
in
all
those
different
locations
and
as
well.
You
know
we've
got
sort
of
this
expanded
set
of
use
cases
right.
Traditionally
it
was
just
Dr
right.
That
was
why
we
cared
about
moving
data
tradition,
but
you
know
now
we
want
to
be
able
to
move
it.
C
C
But
let's
say
you
want
to
go
and
and
replicate
your
data
from,
like
a
you
know,
a
a
main
data
center
out
to
a
bunch
of
edge
locations
right.
That's
probably
not
the
data
mover
for
you.
Maybe
you
want
to
look
at
the
our
clone
based
data
mover
all
right.
So
what
that
one
does
is
it'll,
take
the
data
in
your
Source
volume
and
send
it
to
a
an
object
store
and
then
your
destinations
will
pull
the
data
down
from
that
Object
Store,
and
so
this
works
great
for
this.
C
We've
got
a
third
data
mover,
that's
based
on
restic,
that's
just
for
simple
PV
data.
Backup
right
so
you
know
imagine:
you've
got
your
git
Ops
workflow!
That's
graded
at
deploying
your
application
right.
So
your
application,
it's
inversion
control!
You
know
all
defined
with
your
yamls,
but
you
need
an
answer
for
you
know
the
data.
That's
actually
in
your
persistent
volumes-
and
this
is
really
where
valsync's
rustic
based
mover
shines,
because
it's
not
worried
about
all
those
other
yamls.
B
B
One
statement
is
that
we,
yes,
we
do
know
today
that
customers
are
going
multi-cloud,
not
only
multi-cluster,
they're
going
multi-cloud
and
avoiding
vendor
lock-in
is
one
of
the
big
priorities.
There
are
several
others,
that's
true,
and
so
this
technology
is
helping
them
even
more.
You
know
you
are
not
getting
locked
into
a
storage
provider,
so
this
this
is
giving
them
even
more
flexibility.
C
B
C
Is
absolutely
right,
so
you
know
the
the
capabilities
that
valsync
is
built
on.
It's
all
standard,
kubernetes
functionality
right,
so
you
know
we.
We
replicate
data,
that's
in
persistent
volumes
and
whenever
the
the
CSI
interface,
the
container
storage
interface,
came
in
I,
don't
know
a
year
or
two
ago,
probably
two
years
at
least
ago.
C
You
know
that
brought
in
sort
of
a
standard
way
of
cloning
data
volumes
and
taking
snapshots,
and
that's
really
what
valsync
Builds
on.
And
so
you
know,
if
your
storage
provider
has
a
CSI
plug-in
for
kubernetes,
you
know
you
can
run
ball
sync
on
top
of
that,
okay,
and
so
it
really,
it
really
is
independent
of
the
underlying
storage.
Okay,.
B
A
B
C
Because
really
you
know
vaal
sync,
is
you
know
it's
going
to
replicate
whatever
you
choose
to
put
into
your
kubernetes
persistent
volume
right,
whether
you're,
you
know
deploying
a
simple
app
that
writes
a
bunch
of
text
files
into
a
PVC
or
whether
you're
running
something
like
you
know,
MySQL,
that's
you
know
putting
its
database
into
the
PVC
right.
Volsync
doesn't
care
it's
just
going
to
replicate.
You
know
from
point
A
to
point
B,
fantastic
yeah,.
A
So
what
it
ends
up
being
is
a
truly
hybrid
solution
to
a
truly
hybrid
and
multi-cloud
solution
by
being
fully
agnostic
to
both
the
workload
and
the
platform,
and
it
gives
you
an
entire
toolbox
that
you
have
in
this
really
great
slide
of
different
ways
that
you
can
sync
or
backup
data.
I
can
imagine
the
same
thing
in
a
lot
of
ways.
It's
almost
like
you're,
eventually
a
true
databases.
A
C
C
What
I'm
going
to
do
here
is
Show
an
example
of
you
know
how
you
would
use
vaal
sync
with
the
rsync
Mover
to
make
that
happen
right
so
imagine
we
have
an
application
deployed
here,
that's
storing
its
data
into
a
PVC
on
our
primary
site
and
we're
going
to
replicate
that
right.
So
what
we
do
is
we
run
the
vulsing
operator
on
both
clusters
and
it's
going
to
coordinate
the
movement
of
the
data.
C
So
what
we
do
to
to
configure
it.
We
create
a
replication
destination
object
over
on
that
secondary
cluster
and
when
the
valsync
operator
sees
that
what
it
does
is
it
sets
up
the
resources
over
on
that
secondary
site
to
receive
the
incoming
data
transfers
right.
So
that
amounts
to
a
volume
to
to
receive
the
data
as
well,
as
you
know,
a
receiving
data
mover
and
then
a
network
endpoint
to
take
the
incoming
transfers
over
on
the
source
side.
What
we
do
is
we
create.
We
create
a
replication,
Source
object
and
point
it
at
that.
C
Then,
once
that
transfer
is
complete
on
the
destination
side,
valsync
takes
a
a
snapshot
over
there
to
preserve
that
point
in
time.
Image
right
and
this
this
sequence
can
happen
based
on
a
schedule
or
manually,
depending
upon
how
you
configure
the
The
Source
object,
and
so
we're
we're
constantly
updating
that
consistent
snapshot
over
there
on
the
destination.
So
it's
ready,
you
know
whenever
we
want
to
use
it,
and
so
then
what
that
means
is
whenever
we
want
to
move
the
application
over
to
to
that
secondary
cluster.
C
We
can
just
take
the
most
recent
consistent
snapshot,
turn
it
back
into
a
volume
and
bring
up
our
application
now.
One
thing
I
do
want
to
mention.
Is
you
know
this
slide
and
most
of
the
talk
so
far
has
really
been
focused
on
the
data
movement
itself
right,
but
that's
not
really
what
folks
are
after
right.
What
folks
are
really
interested
in
is
being
able
to
move
their
application
right,
which
is
more
than
just
the
data
right,
because
there's
some
coordination
involved,
and
so
that's
really
where
this
full
stack.
C
You
know,
as
we
talked
about
at
the
beginning
of
the
show,
we're
the
full
stack
of
advanced
cluster
management
plus
Raman
plus
false
sync
comes
in
because
you
know
ACM.
It
gives
you
that
multi-cluster
view
to
help
you
figure
out.
You
know
where
you
want
to
run
your
applications
and
keep
track
of
all
that
stuff,
and
then
the
ramen
orchestrator
is
really
there
to
manage
the
application
Level
movement
right.
C
So,
for
example,
whenever
you
go
and
deploy
your
your
app,
it's
Ramen,
that's
responsible
for
you
know,
as
the
app
comes
up
setting
up
the
replication
relationship
between
that
source
and
the
destination
right.
So
it
goes
in
and
it
creates
that
replication,
Source
object
and
the
replication
destination
object
for
you,
so
the
so
the
replication
gets
started
and
it
runs
in
the
background
and
then,
whenever
it
comes
time
to
actually
relocate
your
app
from
you
know
your
primary
to
your
secondary
cluster.
C
It's
Ramen
that
then
kicks
in
and
shuts
down
the
application
on
the
source
side
right,
assuming
that
you're
doing
a
a
controlled
movement
of
your
app
it
shuts
it
down
on
the
source
side,
then
it
triggers
ball
sync
to
take
sort
of
one
last
final,
Sink
of
the
data,
so
that
we're
sure
that
you
know
all
of
the
data
gets
propagated
over
to
the
other
side.
And
then
once
that
has
completed
it
spins
up
the
application
on
the
new
site
right,
and
so
it's
really
that
that
whole
stack.
C
That
gives
you
the
you
know
the
the
experience
that
you're
looking
for.
So
you
know
that's
kind
of
that's
the
end
of
my
slides
and
so
I
think
you
know.
What's
really
next,
we
can
pause
for
some
more
questions,
but
what's
next
is
going
to
be
I'm,
going
to
turn
it
over
to
teshu
and
he's
going
to
run
through
a
demo
showing
how
this
thing
actually
works.
B
So,
by
the
way,
gardening
is
very
much
connected.
He
is
he's
just
not
turned
on
his
video,
so
John.
This
is
a
active.
Passive
migration
right
and
I
might
use
that,
for
various
reasons
like
you
said
it
might
be
for
hrd
or
it
might
be
because
I
want
the
load
was
running
in
maybe
in
Amazon,
I
want
to
move
it
to
Azure
for
whatever
reason,
or
vice
versa.
Okay,
and
do
we
have
any
any
benchmarks
on
how
much
time
it
takes
related
to
the
data
volume?
C
You
know:
data
movement
applications
out
there
right
rsync,
our
clone
rustic,
and
so
you
know
if,
if
those
applications
sort
of
fit
your
your
workload,
you
know
you're
likely
to
have
a
good
experience
with
valsync
as
well.
You
know
and
sort
of
the
same,
the
same
kind
of
caveats
you
know
and
at
benefits
apply
right
so
like.
If
you
look
at
rsync,
you
know
in
order
to
to
do
a
transfer,
it
has
to
analyze
the
file
system
and
figure
out
what
has
changed
right.
C
So
if
you've,
you
know
if
you've
got
like
five
million
objects
in
your
in
your
volume,
that's
probably
going
to
take
a
little
while,
on
the
other
hand,
if
only
a
little
bit
of
data
changes,
you
know
one
of
the
benefits
of
rsync
is
that
it
it
calculates.
You
know
diffs
and
only
sends
you
know
a
little
bit
of
data
right,
and
so
you
know
you
kind
of
that's
one
of
the
one
of
the
nice
things
about
getting
to
choose
the
different
movers
you
can.
You
know
you
can
choose
the
ones
that
fit
your
data.
B
C
D
C
So
you
can
say,
you
know,
run
a
run,
an
iteration
every
10
minutes
every
15
minutes.
You
know
whatever
it
is
that
that
works
for
you,
and
then
you
know
whenever
you,
whenever
you
trigger
that
final
movement,
you
know
with
ACM
and
and
ramen
it.
It
just
goes,
and
you
know
it'll
kind
of
be
an
an
immediate
out
of
cycle
sink,
but
you're
only
sending
that
you
know
what
has
changed
since
that
last
scheduled
movement
right
or
that
that
last
scheduled
iteration,
and
so
you
know
that
part
can
actually
be
pretty
quick.
B
D
D
The
ramen
scenario,
which
is
you
know,
Ramen
again,
is
like
a
collaboration,
it's
done
by
the
odf
team,
but
we've
been
collaborating
with
them
to
integrate
with
full
sync.
So
they
have
this
Ramen
solution
that
could
do
self
storage,
for
example,
but
ceph
is
managing
the
replication
between
sites
to
do
things
like
CFS
or
you
know,
other
CSI
storage,
that's
what
volsync
brings
in
so
essentially,
Ramen
is
leveraging
ACM
in
terms
of
the
application.
So
it's
an
application
deployed
by
ACM,
but
Ramen
can
insert
itself
and
control
the
placement
of
the
application.
D
So
what
we
do
is
you
set
up
Ramen
to
say
you
know:
I
have
a
primary
cluster
and
I
have
a
fallback
cluster
and
now
I.
It
can
set
up,
in
this
case,
we'll
sync
to
create
the
replication
source
and
destination
on
both
sides
and
I'll.
Show
that
and
like
John
was
saying
I'm
going
to
show
a
replica
relocation
here.
D
So
that's
a
planned
failover
and
the
idea
behind
that
is
I
can
show
you
know
inserting
some
data
in
the
PVC,
then
I
can
do
a
relocate
which
will
Quest
the
app
do
a
final
sync
and
then
we
should
be
able
to
see
the
app
come
up
on
the
other
side,
with
the
data
that
I
just
wrote.
So
I
have
a
basic,
docu
Wiki
app
here.
So
this
is
the
ACM
view
of
the
application.
We
can
see
it's
deployed
from
get
it
if
we
look
at
the
application
topology
here.
D
D
D
If
I
save
this
so
again,
if
we
had
just
run
a
failover,
what
would
happen
is
we
would
cut
over
immediately
and
we
would
get
whatever
was
in
the
the
latest
snapshot
that
was
sent
to
the
destination
side
since
I'm
going
to
do
a
relocate,
it'll
take
a
bit
longer,
but
it'll
quiesce,
the
app
first
take
a
final
backup.
So
we
have
a
you
know,
a
good,
clean,
final
backup
of
all
the
data
and
then
move
the
app
over
because
then
to
relocate
the
time
isn't
the
utmost
concern.
It's.
D
We
want
to
get
a
final
copy
of
the
data
I'm
going
to
show
console
again,
while
I
do
this
too.
Hopefully,
this
is
readable,
but
we
have,
for
example,
that
the
top
is
my
local
cluster,
where
I'm
running
the
app
I
should
show
you
that
in
here
too.
Actually
so
we
can
see
here.
The
app
is
running
on
my
local
cluster,
so
I
have
a
local
cluster
and
I.
Have
another
cluster
called
managed
one
okay,
so
the
the
top
console
is
my
my
local
cluster,
where
I
can
see
the
Pod.
D
This
is
my
docu
Wiki
POD
at
the
top
here.
In
the
deployment
we
can
see
a
PVC,
the
PVC
is
just
called
docu
Wiki,
but
we
can
also
see
Ramen
set
up
a
replication
source,
so
this
is
using
rsync.
So
it's
the
one-to-one
replication
we've
got
a
replication
Source
set
up
for
this
docu
Wiki
PVC
and
on
the
other
side.
So
this
is
my
my
other
cluster.
We
can
see
it's
running
a
replication
destination,
so
we
can
see
there's
already
a
previous
Snapshot
from
the
last
sync.
D
D
So
I'm
just
gonna,
this
is
essentially
I'm.
Gonna
update
the
vrpc,
which
is
a
Dr
placement
control.
So
that's
a
crd
for
ramen.
That's
governing
this
whole
application,
I'm
going
to
tell
it
to
relocate,
and
so
it's
going
to
start
relocating
to
the
managed
one
cluster.
So
the
first
thing
it
does,
though
you
can
see
it's
already
happened-
is
that
the
highlight
this
the
app
has
gone
away
on
the
source.
So
it's
quies
the
app
at
this
point.
You
should
be
able
to
see
that
here.
D
So
we
can
see
the
placement's
been
updated,
ramen's
updated
the
placement
to
not
place
it
anymore,
which
is
undeploying
the
application
and
then,
when
it's
going
to
start
to
do
is
once
it's
decided.
The
app
is
down
I'm,
going
to
run
a
final
sync
using
vulsync
here.
So
it's
actually
running
right
now.
If
these
are
some
of
the
intermediate
containers,
John
was
talking
about
so
it's
created.
This
is
created
by
the
replication
source
and
we
can
see
it's
going
to
start
replicating
to
the
other
side.
D
So
we
just
need
to
give
this
a
sec,
but
this
pod
here
is
essentially
a
pod.
That's
going
to
run
our
sink
from
the
source
side
to
the
destination,
to
give
us
a
final
sink
and
like
John
was
saying
it's
not
sending
the
entire
data
over
it's
just
sending
over.
You
know:
here's
the
change
between
our
last
cycle,
so
that
should
just
be
essentially
the
text
I
wrote
into
docu
Wiki.
So
it's
already
started
happening
here.
D
It
will
have
done
completed
the
final
sync,
because
it's
cleaning
up
on
on
local
cluster
already
so
the
next
step
is
it
will
restore
the
PVC
on
managed
one.
So
this
is
my
other
cluster.
We
should
see
it
restore
the
the
docu
wiki
PVC
from
the
snapshot,
and
this
would
be
the
latest
snapshot,
so
we're
just
gonna
have
to
give
that
a
minute
you
can
see
in
the
in
the
UI
that
the
at
the
moment
the
application
is
not
placed
anywhere.
D
The
other
thing
I
can
show
you
is
so
so
because
the
app
is
down
this
old
Route
is
down
okay,
so
actually
we
can
see
the
docu
wiki
PVC
has
come
up
now,
so
this
is
a
PVC
that
Ramen
is
restored
from
the
snapshot.
So
this
will
be
the
latest
copy
it'll
be
in
pending
state
in
this
particular
case,
because
the
storage
class
has
a
weight
for
first
consumer,
but
now
it's
starting
the
app.
D
D
D
This
UI
might
take
a
sec
to
refresh,
but
I
can
probably
access
it
anyway.
So
we
can
see
that
you
know
the
the
data
was
copied
over
and
my
updates
made
it
over
to
the
other
side.
The
other
thing
I
should
mention
so
essentially
that
the
relocate
is
essentially
done
at
this
point.
But
now
what
Robin's
going
to
do
is
reverse
the
flow.
D
So
it's
going
to
say
you
know
what
manage
one
is
my
primary
I'm
going
to
start
creating
a
replication
Source
on
this
side
now
and
a
replication
destination
on
the
other
side,
so
that
I'll
be
able
to
fail
over
the
other
way.
So,
essentially,
that's
that's.
What's
still
happening
here,
We've
created
a
new
replication
source
and
a
new
replication
destination.
So
we've
reversed
the
flow
here,
fantastic,
that's
about
it.
I
mean
we
could
wait
for
that
to
finish,
but
it
shouldn't
take
too
long.
D
B
Have
a
indirect
question-
and
hopefully
it's
just
my
ignorance,
but
you
know
this
is
a
show
and
we
have
users
who
might
be
a
little
shy
and
not
asking
the
question
so
what
kind
of
network
communication
do
we
need
between
the
two
clouds?
So
it's
our
sync.
So
our
sync
is
on
the
TCP
layer.
What
kind
of
firewall
Sports
things
we
need
to
open.
D
So
in
this
particular
case,
what
Ramen
is
also
leveraging
Submariner
in
this
case,
so
rather
than
you
know,
you
can
set
up
ballsync
on
its
own.
You
know
you
can
set
it
up.
The
service
is
configurable.
You
can
set
it
up
as
a
load
balancer,
which
would
be
external
externally
accessible
on
your
cluster,
so
that
the
two
clusters
can
communicate
over
that
external
load.
Balancer
I,
don't
know
if
I
assist
that
router
load
balancer,
but
it's
a
load
balancer,
but
in
this
case
ramen's
leveraging
Submariner
on
the
on
the
system.
B
B
C
Yeah,
so
whenever
you
configure
vaal
sync
one
of
the
options
that
you
choose
is
like
on
the
source.
You
know
how
we
get
that
consistent
point
in
time,
image
to
serve
as
the
source
for
the
replication,
and
then
there
is
another
Choice
over
on
the
destination.
For
you
know
how
do
we?
How
do
we
preserve
the
results
of
each
iteration?
C
And
you
know
whenever
you're
using
a
CSI
driver
that
supports
either
snapshotting
or
clones
on
the
source
side?
You
know
you
can
you
can
use
those
right.
So
you
know
the
sort
of
the
recommended
choices.
If
your
CSI
driver
supports
clones
that
is
directly
going
from
PVC
to
PVC,
you
should
use
that
because
that
tends
to
be
the
the
fastest
and
most
efficient,
but
certain
CSI
drivers
don't
support
volume
cloning
so,
for
example,
the
AWS
CSI
drivers
for
you
know
for
EBS.
C
You
know
in
the
case
that
you
know
you're
you're,
using
a
storage
provider
that
doesn't
that
doesn't
do
that.
You
know
you
can
still
use
vaal.
Sync,
the
you
know,
sort
of
the
guarantees
that
you
get
aren't
quite
as
good,
because
you
know
you're
essentially
copying
data
out
of
a
volume
that
could
be
changing
underneath
you,
but
you
know
you
can
still
get
the
you
know
you
can
still
get
some
of
the
benefits.
C
Likewise,
on
the
destination
side,
you
know,
you've
got
the
choice
of
you,
know,
copy
method
of
snapshot
or
copy
method
direct
or
none
is
kind
of
a
synonym
there,
and
that's
just
you
know
at
the
end
of
an
iteration.
Do
we
try
and
take
a
snapshot
or
do
we
just
you
know
have
that
that
volume
there
for
use?
C
B
Fantastic,
okay,
I
hope
that
answers
your
question
and
thanks
Gurney
for
posting
the
link
to
the
episode
that
we
had
a
few
weeks
back
on
the
Submariner.
So
that's
the
ready
link
how
the
connection
is
being
made
between
these
two
clusters.
Looking
at
the
watch,
it's
probably
time
to
bid
goodbye
and
play
our
outro
and
before
we
go
first
of
all,
thanks
to
you
guys
both
this
was
awesome,
John
and
tesho,
and
before
we
go
out,
we
will
see
you
in
the
next
two
weeks.