►
From YouTube: Distributed Database DevOps Dilemmas? Kubernetes to the Rescue - Denis Magda, GridGain
Description
Distributed Database DevOps Dilemmas? Kubernetes to the Rescue - Denis Magda, GridGain
Distributed databases can make so many things easier for a developer... but not always for DevOps. OK, almost never for DevOps. Kubernetes has come to the rescue with an easy application orchestration!
It’s straightforward to do the orchestration leaning on relational databases as a data layer. However, it’s becoming a bit trickier to do the same when a distributed SQL database or other kind of distributed storage is used instead.
In this talk you will learn how Kubernetes can orchestrate distributed database like Apache Ignite, in particular:
Cluster Assembling - database nodes auto-discovery in Kubernetes.
Database Resilience - automated horizontal scalability.
Database Availability - what’s the role of Kubernetes and the database.
Utilizing both RAM and disk - set up Apache Ignite in a way to get in-memory performance with durability of disk.
About Denis Magda
Denis Magda is a Director of Product Management at GridGain Systems and Apache Ignite PMC Chair. He is an expert in distributed systems and platforms. Before joining GridGain and becoming a part of Apache Ignite community, he worked for Oracle where he led the Java ME Embedded Porting Team -- helping Java open cross new boundaries by entering the IoT market.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 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.
A
Hello
guys,
thanks
for
coming,
unfortunately,
today
we
are
going
to
enjoy
this
quality
of
the
slice.
We
couldn't
fix
the
hardware
issues,
but
anyway,
I
think
just
pay
attention
to
what
I'm
saying
and
you
will
get
some
useful
information
by
the
end
of
this
conversation.
Well,
so
a
couple
of
words
about
myself.
My
name
is
Dennis
Magnum
presently
I'm
taking
a
roll
over
director
of
product
management
at
great
gain
and,
at
the
same
time,
I'm
a
patch
ignite,
PMC
chair,
but
anyway,
so
don't
be
afraid
of
my
current
position.
A
You're
not
going
to
listen
about
of
the
marketing
stuff.
Throughout
this
conversation,
because
I
am
a
software
cat,
I
joined
the
company
and
as
a
software
engineer
and
I'm,
still
an
active
contributor
to
a
patch
ignite
community
and
the
patch
ignite
is
we're
going
to
talk
about
a
patch
ignite
in
relation
to
the
quick
burn
ages
during
this
presentation,
because
the
patch
ignite
is
basically
distributed.
A
That's
a
bison
computational
platform
that
we
are
developing
at
Apache,
Software,
Foundation
and
I'm,
going
to
share
with
you
my
personal
experience
on
how
you
could
stick
together,
kubernetes
with
our
distributed
database
and
even
more
throughout
this
conversation.
I
want
to
give
you
an
understanding
on.
Where
is
the
responsibility
over
distributed
database?
If
you
plan
to
deploy
one
in
kubernetes,
where
is
the
responsibility
of
all
communities
itself
and
what's
our
role?
What's
the
role
of
DevOps
and
what's
the
role
of
application
developers?
A
Well,
so,
considering
this
in
mind,
our
agenda
looks
like
this
way
for
today.
First,
as
I
said,
I'm
going
to
use
a
patch
ignite
as
an
example
for
this
conversation,
but
basically
the
concepts
and
the
solution
that
I'm
going
to
cover
today
can
be
and
basically
ease,
adapt
it
and
can
be
adopted
for
the
rest
of
the
distributed.
Databases
such
as
Cassandra
such
as
MySQL
such
as
Radiesse.
A
A
I
am
going
to
use
my
laptop
I'm,
going
to
run
quickly,
run
a
batch
ignite
cluster
in
mini
cube
environment,
and
we
will
try
to
scale
it
out
and
scale
it
down
to
see
how
we
can
use
a
patch
community's
facilities
to
maintain
our
question
that
is
already
deployed
in
cribben
edges.
So,
but
before
you
go
to
these
details,
just
three
minutes
of
the
high-level
overview
Apache
night.
So
how
many
of
you
have
heard
about
Apache
ignite?
A
Okay,
good
few
folks?
But
let's
then
it's
the
right
slide
to
show
so,
basically
in
short,
Apache
ignite
is
distributed
database
and
computational
platform
at
the
core
of
these
database.
We
have
the
distributed
storage
right
right.
So
these
distributors
storage
is
called
memory
center.
It
means
it's
called
memory
centric
because
it
stores
it
treats
RAM
as
a
primary
storage
for
your
data
and
your
indexes,
where
m
is
not
just
the
question
layer,
that's
you!
You
are
not
required
to
use
this
clear
and
ignite
it
in
general.
A
A
The
persistence
ignite
supports,
provides
its
own
native
persistence,
which
is
also
distributed
across
the
question
of
your
machines,
or
you
can
use
a
third
party
persistence
such
as
a
relational
database
or
no
SQL
database,
for
instance,
and
on
top
of
this
distributed
storage
on
top
of
this
distributed
database,
the
community
built
a
variety
of
different
components
such
as
key
value.
P
is
SQL
quiz,
computations
machine
learning,
algorithms
and
many
and
many
more.
But
our
goal
of
today
conversation
is
to
take
a
look
at
the
core
of
the
system.
A
We
have
two
type
two
types
of
question
nodes:
the
first
type
is
the
Kovan
server
nodes.
Server
nodes
are
actually
your
data
storage
and
they
store
the
data
they
store
in
Texas
and
they
process
all
the
queries
and
computations
data
coming
from
your
applications
and
applications
are
usually
connected
to
the
cluster
by
means
of
so-called
client
nodes
that
you
can
see
on
the
slide
to
the
right
and
this
client
knows,
provider
of
API
is
available
in
a
batch
ignite.
A
So
that's,
but
then,
when
we
know
about
server
nodes
and
cluster
nodes,
then
they
want
to
deploy
them
somehow,
and
ignite
can
be
literally
deployed
anywhere
you
like
so,
for
instance,
you
can
deploy
as
a
developer.
When
you
start
development
of
your
next
application,
you
can
deploy
the
first
question
on
a
local
laptop.
You
do
not
need
to
go
to
your
IT
department
and
negotiate
it
some
in
some
environment.
All
the
development
and
the
initial
testing
can
happen
on
on
your
personal
machine.
A
However,
when
it's
time
for
you
know
advanced
testing
or
the
time
for
the
production,
you
can
deploy
your
question
prints
or
you
can
deploy
it
on
cloud
and
what's
interesting
about
the
deployments,
the
cluster
deployment
and
life
cycle
can
be
orchestrated
and
provisioned
by
different
solutions
such
as
hibernators,
and
here
is
we're
going
to
take
to
talk
about
cutting
edges.
So
the
deployment
in
computing
edges
is
not
that
difficult
as
you'll
find
out.
Actually,
the
main
theme
of
the
class
student'
component
is
to
allow
it
all
the
cluster
nodes
to
discover
each
other.
A
Here
is
from
this
picture.
You
already
see
a
connected
cluster,
so
all
the
nodes
know
about
each
other.
They
can
communicate,
they
can
interchange
messages,
they
can
accept
different
queries
and
calculations.
But
before
this
cluster
is
united,
every
single
node
not
needs
to
discourage
other
and
join
the
classroom.
And
to
achieve
this
in
the
networking
component,
we
have
a
special
thing
called
IP
finder.
A
If
you
have
that
IP
address.
So
it's
pretty
simple
and
this
is
actually
how
it
works
and
there
is
a
variety
of
different
IP
finders
available
in
a
batch
ignite,
for
instance
the
basic
two
ones:
multicast
IP
finder
and
static
IP
finder.
So,
for
instance,
if
you
start-
let's
say
your
cluster
on
the
local
laptop
or
you
in
your
private
network,
then
you
can
use
multi
class
data
finder
because-
and
you
note,
will
each
little
broadcast
multicast
packages
into
the
network
and
if
there
is
any
other
node
in
this
network
that
is
over.
A
The
part
of
the
question
at
the
nodes
will
reply
to
this
new
node
with
their
own
IP
addresses
and
the
new
node
will
be
able
to
join
the
question
by
receiving
this
information,
but
probably
the
simplest
way
to
let
all
the
nodes
to
fit
all
the
addresses
to
the
nodes
is
by
providing
the
static
IP
a
finder,
static,
IP
finder
simply
includes
already
known
IP
addresses
of
your
machines,
where
you're
going
to
run
cluster
nodes.
Actually,
this
type
of
configuration
really
works
for
on
previous
deployments.
A
When
you
can
know
their
IP
addresses
in
advance,
and
you
just
prepare
the
configuration
for
your
cluster
nodes,
you
give
this
configuration
to
the
machines
and
that's
it.
But
when
you
decide
to
deploy
your
cluster
and
when
you
decide
to
deploy
your
distributed,
database
will
say
in
the
cloud
or
on
the
Kuban
nature
supervision,
neither
static,
IP,
finder,
no
multi
kept
a
multicast
that
if
I
under
live
work
for
you,
because
if
to
talk
about
creepers
niches,
we
all
know
about
this.
A
It's
unlikely
that
your
ignite
clyster
node
so
ignite,
but
we
know
even
its
own
IP
address
in
advance,
so
the
IP
addresses
unknown,
and
here
is.
We
are
going
to
the
orchestration
specificities
of
distributed
databases
such
as
Apache
night
in
Cuban
ages.
So
again,
so
there
are
two
things
that
are
related
to
the
networking
component
of
the
database.
The
first
one
is
classic
discovery.
A
This
is
what
I
am
just
talking
about,
and
here
is,
as
I
said,
nodes
cluster
nodes
do
not
know
IP
addresses
in
advance,
so
they
they
will
not
be
able
to
join
the
question
if
it
is,
if
the
addresses
are
unknown
and
also
the
IP
addresses
of
the
nodes
can
can
be
changed
over
the
time.
If
you
restart
your
question
machines
right,
so
it's
not
under
our
control.
It's
up
to
kubernetes
to
decide
what
would
be
the
next
IP
address
if
I
restart
it
one
of
my
cluster
nodes.
A
However,
once
you
find
the
way
how
to
provide
how
to
share
IP
addresses
among
all
your
cluster
nodes
that
represent
your
distributed
database
inside
of
the
kubernetes,
you
will
be
able
to
get
a
workable
self-contained
and
self-healing
cluster
specifically
if
to
talk
about
a
batch
ignite.
Once
all
the
nodes
are
interconnected,
they
will
take
care
of
the
rest
of
the
functionality
and
the
rest
of
the
tasks.
A
Only
at
the
time
when
the
new
node
joins
the
new
question
so
and
also
once
we
have
this
class
sure
all
the
notes,
at
least
the
notes
in
a
batch
ignite
database
will
be
able
to
autumn
peer-to-peer
connection
whenever
it's
needed
like
when
you
want
to
execute
in
you,
SQL
query
or
you
are
sending
some
computation
to
your
cluster
node.
One
node
will
be
able
to
open
a
direct
connection
to
the
other.
So
here
is
again,
we
don't
need
to
know.
A
We
don't
need
to
talk
to
kubernetes
environment
and
today
and
now,
let's
dive
into
the
first
paragraph
into
the
cluster
discovery,
because
but
this
is
actually
the
integration
point
between
the
distributed
database,
searches,
apache,
ignite
and
cuba
latest
environment
because
of
the
rest
is
usually
handled
by
a
database
vendor.
So.
A
What
are
the
specific
cities
or
the
communities
deployment
of
ignite
deployment
in
the
kubernetes?
So
first,
how
we
solve
solve
this
issue?
How
we
provided
you
know
the
IP
finder
implementation
for
patch
ignite.
We
all
know
that
in
communities
we
have
a
concept
of
services
and
we
just
decided
to
reuse
the
this
concept
for
the
nodes
out
of
the
auto
discovery
inside
of
the
kubernetes
environment.
A
Basically,
if
you
take
a
look
at
this
diagram
here,
is
I'm
trying
to
explain
the
process
of
when
a
new
node
shown
over
here
is
trying
to
join
a
class
through
machines.
These
machines
are
already
here,
they're
communicating
they
can
accept
and
they
might
accept.
You
queries
a
process
workloads
coming
from
your
application,
but
this
is
the
new
one
and
when
he,
when
this
node
is,
is
launched,
we
can
call
it
ignite
part
in
terms
of
kubernetes.
A
It
doesn't
know
IP
addresses
of
any
of
this
nodes,
but
it's
going
to
be
used.
It
will
be
using
a
special
IP,
find
a
representation
that
ap
finder
will
connect
to
a
previously
started
ignite
queue,
bernetta
service
and
that
ignite
kubernetes
is
keeping
a
list
of
all
the
P
addresses
of
all
the
ignite
parts
that
are
already
deployed
in
your
kubernetes
environment.
And
this
note
will
just
will
do
the
simplest
operation
possible.
It
will
open
a
psychic
connection
to
this
service.
A
So
basically,
the
only
one
mandatory
option
is
that
you
encourage
to
specify
the
name
of
your
ignite
question,
because
every
ignite
part
that
is
about
to
be
started
in
cuba
reneges
will
be
labeled
using
some
name,
and
here
is
a
user
name
ignite,
to
specify
that
this
ignite
service
should
track
IP
addresses
of
of
the
pads
that
are
labeled
with
this
name
and
then
we're
just
going
to
use
well-known
commands
to
start
this
service.
What
goes
next,
once
our
serious
incriminated
is
up
and
running,
we
are
ready
to
start.
A
We
are
ready
to
deploy
our
distributed
database
because
now
we
know
that
all
the
database
nodes
will
be
able
to
look
up
which
other
by
connecting
to
the
service
that
are
over,
that
is
already
up
and
running.
Unfortunately,
the
quality
is
poor,
but
anyway,
I'll
show
this
to
you
during
the
demo
section.
Here
is
what
I
am
doing
again.
I
just
specified
that
the
name
of
this
part
will
be
equal
to
ignite
and
then
here
is
I'm
providing
in
ignite
configuration.
A
I'll
show
this
configuration
in
a
minute
and
basically,
in
kind
of
this
configuration,
that's
Apache
net
configuration
that
is
used
by
Apache
night
node
and
inside
of
this
configuration
the
nodes
use.
You
burn
a
TCP
finder
that
connects
to
the
server,
gets
all
the
IP
addresses
from
this
server
service.
Sorry,
and
this
actually
allows
to
all
the
nodes
to
interconnect
with
each
other
and
finally,
so
that's
it.
So
actually
that's
a
reality.
That's
how
it's
simple
to
deploy
a
distributed
database
in
the
cluster.
A
For
instance,
you
can
like,
when
you
use
a
patch
ignite
deployment
you
can
use
the
same,
could
be
your
native
API
if
you
want
to
scale
out
your
cluster
or
if
you
want
to
shrink
the
size
of
your
cluster
depending
on
your
workloads
and
depending
on
the
memory,
consumption
and
and
other
characteristics.
So,
for
instance,
in
a
couple
of
minutes,
we
are
going
to
start
our
fuel
stop
by
check
net
cluster
in
cuban
edges,
using
mini
cube.
A
That
cluster
will
consists
just
of
two
cluster
nodes,
but
then,
if
we
use
we
can
use
this
well-known,
cube,
CTL
scale
command
to
scale
out
our
question
and
you
don't
need
to
know
anything
about
igniting
journals.
You
don't
need
to
know,
don't
need
to
use
any
management
facilities
provided
by
ignite.
If
your
goal
is
just
to
scale
out
the
question,
you
can
use
all
the
knowledge
about
cuban
ages,
you
already
have
so
that's
all
about
theoretical
part.
So
and
now,
let
me
quickly
show
you
how
we
can
deploy
our
cluster.
A
I've
started
the
mini
QP
environment
and
first
I
want
to
start,
as
we
not
already
already
know.
Now
we
need
to
start
a
batch
ignite
service
right,
the
kubernetes
service
that
is
going
to
provide
us
all
the
IP
addresses.
So
presently
we
don't
have
this
service
deployed,
but
I
have
a
configuration
of
this
service.
You
have
already
seen
it
on
the
previous
slides,
but
let
me
show
it
to
you
one
more
time
again.
So
it's
just
simple
frivolity
series
and
the
essential
thing
about
it.
A
A
A
We
are
going
to
start
to
cluster
nodes,
it's
enough,
at
least
for
my
local
laptop
and
then
I'm,
going
to
say
that
all
the
pads
will
be
labeled
with
ignite
name,
so
that
they're
somehow
related
to
that
ignite
service.
I'm
going
to
use
the
latest
version
of
a
batch
ignite,
docker
image-
and
here
is
interesting
thing-
that's
ignite
configuration
so
basically
here
is
this.
Configuration
will
be
passed
to
a
patch
ignite
process
when
it's
about
to
start
and
inside
of
this
configuration,
we
have
one
interesting
thing
that
is
related
to
our
conversation.
A
Here
is
that
configuration
it's
just
available
in
github?
It
contains
nothing
except
for
this
Cuban,
a
TCP
finder.
So
that's
the
only
thing
we
need
to
provide
in
the
configuration
of
our
database
nodes
if
you,
if
you
want
to
run
them
in
Cuba
with
this
question
and
that's
it
then,
when
we
are
going
to
start
to
first,
when
kubernetes
will
be
starting
to
first
nodes
using
our
deployment
configuration,
the
nodes
will
use
this
IP
finder
this
IP.
A
A
A
Let's
connector,
let's
see
the
looks
from
one
of
them:
I
just
want
to
be
sure
that
they
actually
belong
to
the
same
classroom:
okay,
let's
kind
of
Apache
ignite
logs.
We
see
that
the
note
is
started
and
this
topology
snapshot
says
that
we
have
to
cluster
machines
and
they
kind
of
can
use
two
gigabyte
of
Java
heap
and
much
more
memory
for
the
rest
of
the
data,
but
the
cluster
is
empty.
So
pretty
simple,
that's
it!
A
This
is
how
you
just
can
deploy
your
fuels
distributed
database
by
just
providing
the
way
or
for
all
the
discovery
of
your
classroom
machines.
And
now,
when
you
want
to
change
the
cluster
size
again,
you
can
use
some
facilities
provided
by
database
vendor
or
you
can
use
the
functionality
available
in
people
Nerys
and
let
me
just
quickly
go
to
the
slides
and
copy
and
paste
this
command
here
is
I'm
just
going
to
scale
out
my
cluster
to
five
nodes.
A
A
A
So
basically
the
deployment
and
maintenance
of
distributed
databases
is
not
that
different
from
regular
databases
you
as
an
application,
developer
or
dev
up
just
need
to
provide
the
valid
configuration
for
your
distributed
database,
but
the
rest
has
to
be
supported
by
database
vendor
today,
I
just
explained
you
what
we
did
specifically
at
the
Apache
ignite
community.
We
were
just
we
had
our
so-called
pluggable
and
expandable
networking
component
that
allowed
us.
A
You
know
just
to
provide
the
simplest
implementation
of
cuban
artists,
IP,
finder,
possible
and
now
kind
of
apache
ignite
users
and
customers
can
easily
deploy
ignite
cluster
without
limitation
and
the
same
technique
usually
applied
for
other
distributed
databases.
So
I
know
that
preaches
the
same
techniques
are
used
for
Cassandra
for
MongoDB,
for
radius
zone
with
no
any
difference,
and
then,
if,
when
today,
we
will
not
cover
in
their
applications.
A
So
with
this
type
of
deployment,
if
you
use
when
all
the
nodes
are
deployed
inside
of
your
kubernetes
environment,
this
type
of
IP
finder
implies
that
your
applications
will
be
deployed
in
communities
too,
so
that
they
can
connect
to
cue
latest
to
ignite
parts
to
the
question
using
internal
IP
addresses.
But
anyway.
So
if
you
want
to
deploy
your
applications
outside
of
the
Kuban
edges,
there
is
also
different
tips
and
tricks
on
how
you
can
do
this
wheel's
distributed
databases
with
ignite.
A
You
just
need
to
use
a
bit
different
version
of
the
IP
finder
or
you
just
need
to
assign
ignite
service
for
every
ignite
part
you
have
in
a
cluster
so
that
every
individual
ignite
class
or
not
can
be
visible
outside
of
your
kubernetes
environment.
So
that's
all,
and
we
have
five
minutes
for
your
questions,
guys
Thanks.
A
So
the
question
is:
is
there
any
volume
used
in
this
presentation
today?
I
just
showed
how
to
deploy
a
batch
ignite
with
a
memory
storage
only,
but
if
you
want
to
enable
the
persistence
right,
so
you
just
need
to
provide
volumes,
configuration
it's
not
that
different
and
but
the
specificity
of
distributed
databases
deployment.
Is
that
usually
you
want
to
assign
a
specific
volume
to
a
specific
cluster
node
so
that,
if
this
note
is
restarting,
it
will
be,
it
will
own
the
same
volume.
This
is,
and
this
is
pretty
it's.
A
It's
also
possible
it's
just
this
just
you
know
this
is
how
I
just
decided
to
show
and
how
to
explain
this
to
you
using
the
simplest
way
possible
to
show
you
help
me
actually
and
met
now
about
what
you
as
a
kind
of
what
it
a
distributed.
Database
vendor
has
to
do
and
the
simplest
thing
we'll
just
implement
and
provide
some
functionality
for
the
networking
component.
But
anyway,
yes,
you
can
rely
on
the
stateful
set
to
achieve
the
same
if
it
suits
more.
Your
needs.
A
Yeah
yeah
I
see
so
the
question
is
so.
The
question
is
basically
what's
the
reason
of
running
several
cluster
nodes
on
a
single
machine
right,
so
it
usually
kind
of
in
I
would
say
that
in
ninety
percent
of
the
deployments
at
least
the
patchak
net
users
dedicate
an
individual
physical
machine
or
the
a
machine
that
is
in
the
cloud
to
a
PI,
sig
net
node
process.
But
sometimes
machines
I
know
that
there
are
some
of
the
deployments
when
there
are,
you
know
dozens
of
different
CPUs
and
they
are
running
computing.
A
Intensive
computations
and
companies
might
run
several
ignite
nodes
or
the
same
hardware
just
to
be
able
to
utilize
all
the
resources.
At
least
this.
If
it
was
true
a
couple
of
years
ago,
but
nowadays,
speaking
about
apache
ignite,
all
the
data,
all
the
indexes
are
stored
in
the
manageable
memory
regions
or
which
is
not
visible
to
Java
heap.
So
you
will
not
get
any
stopped
the
world
pauses
and
actually
the
platform
itself
is
tries
to
chill
eyes
all
the
resources
you
have,
and
basically
all
the
China
to
talk
about
present
days.
A
I
see
I
couldn't
say
that
I
talk
to
any
user
or
customer
who
tries
to
launch
several
ignite
nodes
on
a
single
machine,
but
usually
it's
it's
good
for
the
development
like
I
is
a
developer.
I
just
start
my
cluster
on
locally
and
I.
Do
it
and
it's
good
for
Quality
Assurance,
because
you
can
start,
you
can
have
a
single
Java
process
and
you
can
start
several
a
batch
ignite
nodes
in
the
same
Java
process,
and
it
in
this
truly
simplifies
the
tasting
cycles
of
your
functionality.
For
instance,
in
the
ignited
Apache
ignite
community.
A
We
have
thousands
of
different
tests,
and
probably
the
majority
of
this
test
start
the
cluster
in
a
single
GBM
process
just
to
be
able
to
check.
You
know
some
functionality
that
the
queries
ritual
consistent
result
that
the
computer
executed
in
the
same
way
and
because,
if
you're,
if
you
were
doing
it
in
a
different
way
when
they
were
dedicating,
let's
say
if
we
would
dedicate
a
stipulated
machine
for
every
node
process.
That
testing
cycles
would
be
really
really
long.