►
Description
Oct 22 2019 OpenShift Commons Briefing hosted by Diane Mueller
Building Cloud Native Apps that Scale with NuoDB on OpenShift
Guest Speaker: Joe Leslie (NuoDB)
OpenShift Commons Briefing
hosted by Diane Mueller
In this briefing, Joe Leslie, Senior Product Manager for NuoDB and Tom Gates (lead Operator developer) gives us an update/overview on Nuodb’s recently developed NuoDB Operator for OpenShift developed in Go. Joe walks us thru building cloud-native applications with a container-native SQL database leveraging OpenShift and NuoDB.
He demos the NuoDB Operator, deploy a NuoDB database, a SQL workload, and on-cluster NuoDB Insights visual monitoring. He shows how to scale the database using OpenShift and create failure events to demonstrate auto-recovery.
A
Well,
hello,
everybody
and
welcome
again
to
another
OpenShift
Commons
briefing.
Today
we
have
one
of
our
new
ODB
folks,
Joe,
Leslie
and
Tom
gates
here
to
talk
about
deploying
their
new
ODB
database
using
their
new
ODB
operator
and
I'm
gonna.
Let
them
introduce
themselves
and
then
there'll
be
live
Q&A
at
the
end.
These
are
some
of
my
favorite
things
to
talk
about
operators
and
the
new
ODB
stuff
and
all
the
work
we're
doing
so.
There'll
be
I,
assume
a
lively
conversation
at
the
end
as
well,
so
Joe.
B
C
B
B
So
I
know
many
of
you
probably
are
not
familiar
with
nuodb
or
maybe
have
some
familiarity
so
I'm,
just
gonna
spend
five
to
ten
minutes
talking
a
little
bit
about
who
nuodb
is
kind
of
what
our
mission
is,
what
we're
all
about,
and
really
some
of
the
benefits
of
running
new
VPN
anokhin
shift
cloud
native
environment.
Most
of
the
time
we're
gonna
spend
in
a
demo.
We're
gonna
demonstrate
some
of
our
latest
advancements
with
our
new
ODB
cooperator.
B
Today
we
have
a
new
DD
helm
operator,
which
is
published
up
on
the
openshift
operator
hub,
so
it's
easily
accessible
for
everyone,
who's
running,
open,
shift4
and
greater.
We
always
encourage
everyone
to
go
ahead
and
give
that
a
try.
It's
a
it's!
A
good
and
fun
experience.
In
fact,
we're
gonna
do
that
today.
We're
gonna
run
through
the
same
experience
with
the
go
operator
and
we're
gonna,
deploy
a
new
DB
database
and
we're
gonna,
deploy
new
DB
insights,
our
visual
workload
monitoring
tool
and
we're
going
to
start
up
a
sequel
application.
B
Much
like
our
customers
to
to
run
a
sequel
load
against
our
database
and
we're
gonna
demonstrate
a
database
scale
out
using
openshift,
as
well
as
we're
going
to
demonstrate
how
openshift
and
kubernetes
and
nuodb
work
together
to
orchestrate
auto
recovery,
and
then
we'll
have
plenty
of
time
for
Q&A
also
feel
free
to
ask
questions
if
you
like
during
that,
as
we
go
also,
that's
that's
fine.
If
Diane
are
the
lines
open
or
will
be
people
be
typing
in
the
chat
box,
people.
A
B
Good
with
that,
okay,
great
thanks,
Diane
all
right,
so
let's
go
ahead
and
get
started
so
just
come
to
a
glace.
A
brief
introduction
to
nuodb
nuodb
is
a
modern
cloud
native.
We
also
describe
ourselves
as
cloud
agnostic.
We
do
run
up
in
all
of
the
common
clouds
we
run
on
Prem
as
well,
so
you
can
run
us
in
Amazon
or
Google,
whichever
you
like.
We
are
a
distributed
sequel
database
so
out
there
there's,
no
sequel
and
there's
sequel
databases.
B
So
some
of
the
trends
that
we
have
just
looked
too
far,
some
of
the
trends
that
we
just
wanted
to
share
as
we're
seeing
organizations
increasingly
move
to
the
cloud
they
they
they
realize
the
benefit
of
moving
to
the
cloud
we're
seeing
a
large
movement
there.
Likewise,
many
of
us
realize
that
kubernetes
is
the
de
facto
standard.
B
Now,
when
running
a
containerized
workloads
in
the
cloud
and
and
lastly,
red-hats
openshift
product
is
just
leading
the
market
in
container
management
platforms
and
that's
what
we'll
be
demonstrating
today
is
nuodb
running
in
a
Red
Hat
open
shift
environment
I
also
wanted
to
quickly
share
why
we
like
operators
young
today
we're
going
to
be
demonstrating
the
new
operator.
Well,
why
do
we
like
operation?
B
Why
are
so
many
vendors
building
operators
well
they're,
really
easy
to
use
and
very
accessible
they're
easy
to
use
in
that
you're
deploying
via
a
managed
package,
as
opposed
to
something
like
where
we
used
to
edit
yamo
files
and
edit
scripts
and
and
run
them,
and
that
was
always
error-prone
today.
Now
operators
are
built
to
run
tasks
every
the
same
way.
Every
time
and
I
say
you
know,
accessibility
simply
because
now
you
can
just
pick
and
click
right.
B
You
just
pick
and
click
the
application
and
want
from
operator
hub
and
you
you
can
literally
deploy
from
catalog
to
cluster
in
under
a
minute.
So
it's
a
fantastic
user
experience
when
working
with
operators.
Next
security
reasons
right
once
you
publish
once
a
vendor,
publishes
an
operator
to
a
marketplace.
You
know
like
operator
hub
customers
can
be
assured
that
they've
been
scanned
for
security,
vulnerabilities,
they've
been
tested,
verified
and
they're
ready
for
it
for
your
use,
so
security
is
another
benefit
of
operators.
They
also
add
operational
support.
B
You
know
specifically
I'm,
referring
to
you
know
like
ansible
playbook
or
go
type
operators
where
they
automate
beyond
provisioning
and
they
allow
vendors.
You
know
like
ourselves
to
provide
fully
managed
a
to
operational
tasks
all
from
within
the
operator,
and
then
you
know,
operators
being
a
you
know,
kubernetes
thing
it's
it's
kind
of
like
a
build
once
and
deploy
many,
so
it's
a
portable
code
for
for
vendors
to
run
across
kubernetes
distributions.
B
So
those
are
some
of
the
main
reasons
why
we
like
braiders
this
screenshot
included.
This
is
really
what
we're
going
to
kind
of
demonstrate
today
during
the
demo,
but
this
is
nuodb.
The
cloud
native
database
and
towards
the
left
is
a
more
traditional
way.
You
might
run
a
database
in
a
cloud
environment
where
you
see
the
the
software
components
are
tightly
coupled
together
as
opposed
to
the
new
VB
architecture,
where
you
see
that
the
components
are
in
separate
bubbles,
we
have
transaction
engine
layer
and
a
Storage
Manager
layer
engine
and
those
two
layers
scale
independently.
B
The
transaction
engine
is
running
the
sequel
statements
on
behalf
of
the
clients,
while
the
storage
managers
are
then
making
any
DML
statements,
any
insert,
update
or
delete
statements
durable
to
disk.
So
this
is
a
good
slide.
You
know
it's
great
one
to
screen
capture.
If
you
like,
and
as
well
just
these
slides
will
be
available
after
the
presentation,
so
this
is
a
good
one
that
just
shows
the
the
architecture
a
little
bit.
Okay.
B
B
Database
and
we're
gonna
deploy
the
new
DB
on
cluster
insights.
Visual,
monitor
we'll
talk
more
about
that
as
we
get
there
and
then
we're
going
to
go
ahead
and
run
some
sequel
occations
much
like
our
cluster.
Our
customers
do
and
demonstrate
some
of
the
nice.
You
know
cloud
capabilities
like
you
know,
easy
scale
out
and
auto
recovering
after
failure.
Events,
okay,
so
I'll
just
go
ahead
and
switch
over
now
to
our
demo,
environment,
okay,
and
so
what
we're
seeing
here
is
on
the
left
is
an
open,
shift4
environment.
This
is
the
web
UI.
B
B
You
know
once
it's
running
to
you
know,
do
certain
things
like
give
us
a
new
ODB
database
and
and
and
so
on.
Now,
as
I
mentioned,
it's
the
helm
operator
today,
that
is
up
on
operator
hub.
So
why
don't
we
go
ahead
and
show
off
operator
hub
just
a
little
bit,
it's
very
easy
to
get
to
I'm
going
to
go
ahead
and
show
you.
You
know
how
you
would
deploy
the
new
ODB
operator
today.
You
go
ahead
and
select
operator
hub
and
I
called
it
sort
of
this
nice.
B
You
know
click
and
pick
type
of
interface.
Where
you
know
you
would
you
would
go
and
find
your
tile
or
your
application
and
say:
oh
there,
it
is
nobody,
the
operator
go
ahead
and
click
on
that,
and
then
you
would
click
install
ok,
and
this
would
go
ahead
and
install
the
operator
that
the
helm
operator
into
your
OpenShift
selected
cluster
will
go
ahead
and
pretend
right
we're
gonna.
B
So,
like
I
said,
that's
a
very
automated
step.
Many
of
you
have
probably
already
done
that
with
maybe
some
other
products,
but
so
our
NGO
operator
is
not
yet
up
on
operator
hub.
It
will
be
in
several
weeks
in
time
for
the
cube
con
event
out
in
San
Diego.
Hopefully
many
of
you
are
gonna.
Go
out
there.
We'd
love
to
meet
you
at
booth.
B
53
feel
three,
you
know
feel
free
to
stop
by,
for
you
know
a
more
in-depth
demo,
but
at
that
time
the
go
operator
will
be
at
will
be
up
on
operator
hub,
so
it
would
be
completely
automated
experience.
So
what
I'm
gonna
do
today,
since
it's
not
on
a
operator
hub,
I'm
gonna,
deploy
the
go
operator
using
a
little
script.
Okay
and
all
it's
going
to
do-
is
it's
just
going
to
create
a
whole
bunch
of
kubernetes
objects
to
deploy
the
operator,
and
you
can
kind
of
see
immediately
off
to
the
right.
B
Excuse
me
to
the
left:
is
the
operator
deployed
so
I'm
just
going
to
screen
a
little
bigger
and
sure
enough?
We
see
the
new
DB
operator
and
it's
already
running
one
of
one
pods
okay,
so
we
now
have
an
operator
deployed
and
it's
that
quick
right.
It
literally
is
from
from
catalogue
to
cluster,
and
this
in
this
case,
from
CLI
to
cluster
in
less
than
a
minute.
Now,
one
of
the
things
we
like
to
show
is
how
you
can
provision
a
a
custom
database.
B
So
there
is
I'm
going
to
show
you
a
new
ODB,
er
gamal
file,
and
this
this
just
gives
you
an
idea
of
some
of
the
things
that
you
would
have
control
over.
You
know
you
can
you
can
create
a
persistent
store
database
or
an
ephemeral.
We
always
recommend
persistent,
so
in
the
event
of
any
fail
or
failure,
events
that
you
know
you
know
that
your
storage
will
is
reliably
there
with
women
when
a
pod
recovers
insights,
I
mentioned
the
insights
insights
is
our
visual
monitoring
tool.
You'll
notice
here,
I?
B
Have
it
set
as
enabled
true
I'm,
gonna
start
3.
Admin
processes
at
Edmonds
is
what
creates
a
domain
suitable
for
running
a
new
DB
database.
Logically,
across
multiple
zones,
multiple
hosts,
so
it's
an
important
part
of
a
distributed
system,
and
then
you
can
start
to
see
all
the
other
little
details
right,
like
storage
sizes,
what
what
storage
classes
I'm
just
going
to
be
using
the
standard,
a
AWS,
elastic
block,
storage,
I
decided
to
call
my
database
DB
and
my
users
DBA
and
oh,
my
password
is
secret.
B
So
don't
tell
anyone-
and
you
know
you
have
a
lot
of
control,
right
memory
and
some
counts
of
processes,
and
so
on.
So
you
know
before
you
start
your
database.
You
would
just
edit
this
file
right
and,
and
then
that's
how
you
would
you
know,
create
a
custom
database,
so
I'm
just
gonna
run
a
little
command
here
called.
Give
me
a
new
ODB
database
and
what
it's
gonna
do.
Is
it's
going
to
start
the
database,
but
it's
also
gonna
start
the
insights,
visual
monitoring
tool.
Why?
B
B
Okay,
so
we're
going
to
start
that
the
visual
monitoring
tool,
as
well
as
a
little
sample
app,
so
go
ahead
and
run
that
command,
and
you
can
see
that
the
database
just
leave
sprite
out
of
the
operator,
move
this
over
a
little
bit
more
here,
and
so,
while
it's
some
basically
bringing
up
the
insights
monitoring
tool,
we'll
explain
a
little
bit
about
what
we
see
here.
So
we
see
these
three
process
types
that
sort
of
leaked
out
of
the
operator.
We
talked
about
them
a
little
bit
earlier.
B
There's
the
admin
and
you
may
recall
we
asked
for
three
of
them.
So
it's
off
starting
those
three.
It
has
one
three
already
started
so
that
that's
great,
but
we
can
see
that
the
Storage
Manager
is
already
running
one
of
one
pods
and
the
transaction
engine
is
also
running
one
of
one
pods.
So
as
long
as
you
have
a
one
admin,
one
transaction
engine
and
one
storage
manager,
you
have
a
new
database.
It's
fully
up
and
running
it's
not
redundant.
Yet
right.
B
B
So
while
it's
doing
that,
I'm
gonna
explain
a
little
bit
about
insights
and
and
what
it's
doing
and
what
the
options
are.
So
with
with
our
monitoring
tool,
you
can
choose
to
either
use
our
new
ODP
hosted
monitoring
tool
up
up
in
the
awr
portal.
It
would
be
you
sending
your
performance
stats
to
our
portal
and
then
we
would
give
you
a
subscriber
ID,
where
you
could
then
connect
and
see
privately
you're
monitoring
day.
However,
with
the
go
operator,
we
have
implemented
what
we
call
on
cluster
insights.
B
That
means
all
of
the
visual
monitoring
can
also
be
hosted
within
your
openshift
cluster.
This
is
great
because
this
allows
you
to
fully
manage
your
data,
is
privately
held
within
your
cluster
and
you
know
again,
you're
not
connecting
to
any
sort
of
remote
or
public
cloud
to
go
gather
up
your
performance
data.
B
So
that's
what
the
young
cluster
of
visual
monitoring
is
all
about,
and
you
know
it
looks
like
it's
it's
pretty
well
started.
You
can
see
a
whole
bunch
of
components,
core
fauna,
Kabana
and
all
these
pieces
that
are
there
server.
You
know,
servers
that
are
starting.
One
way
to
check
is
if
we
go
over
to
our
Griffon
in
interface
and
I,
refresh
oh
yeah,
there's
our
little
cliff
on
a
bouncing
ball
and
you
know
we
can
see
that
we're
now
connecting
we
don't
have
data
yet,
but
we
will.
B
We
actually
haven't
run
much
of
the
workload
yet
and
we
are
gathering
data
in
30-second
intervals,
but
displaying
in
10-second
interval.
So
pretty
soon
we're
gonna
start
to
see
some
activity,
as
I
refresh
the
screen
and
so
yeah
I
can
see
over
here
to
the
right
is
now
our
our
start.
Up
process
has
fully
completed
again.
All
of
that
will
be
done
via
operator
hub.
B
You
know,
once
we've
published
to
the
to
the
hobbits
it'll
be
a
you
know,
a
pick
in
and
click
and
all
this
will
happen
and
and
then
you
will
have
the
opportunity
to
create
that
custom
database
as
I
showed
by
editing
the
CRE
mo
file.
Ok,
so
now
that
our
database
is
up
and
running
and
I
can
start
to
see
now,
some
workload
is
coming
in.
You
can
see
over
here
there's
little
lines
coming
in
still
very
early
as
those
Y
CSB
processes
are
starting
up.
That's
our
application.
B
You
can
see
more
data
coming
into
the
screen.
It's
indicating
that
we
have
one
trend.
This
screen
just
a
little
bit,
so
we
can
see
a
little
more.
We
can
see.
We
have
one
transaction
engine,
one
storage
manager
and
a
workload
is
starting
up.
If
we
look
in
the
lower
aggregate
panel,
where
we
see
aggregate
transactions
per
second,
we
can
see
that
we're
starting
to
hit
this
database
with
a
good
amount
of
sequel,
we're
running
approximately
4000
sequel
statements
per
second
okay,
with
this
little
sequel:
application
that
we're
running
okay.
B
This
will
stabilize
somewhere
around
4000
for
this
single
single
app
okay.
But
what
we
also
want
to
demonstrate
is
how
easy
it
would
be
to
scale
out
a
new
ODB
database
inside
of
open
ship.
So
you
know
if
we,
if
we
look
now
at
the
screen
again
for
the
database,
we
have
one
transaction
engine
and
if
I
was
to
go,
find
my
application
I
could
look
under
workloads
and
go
to
replication
controllers
there.
It
is
the
Weisse
ESB
load
and
we're
only
running
one,
so
yeah.
B
We
could
pretend
a
little
bit
that
maybe
we're
a
bank-
and
this
is
a
banking
application
and
we've
just
brought
this
banking
application
online
for
one
department.
But
it's
been
running
very
successfully
and
it's
servicing.
You
know
about
500
users
and
now
we're
about
to
roll
this
application
out
to
other
departments
within
the
bank
or
we've
higher.
We've
acquired
a
new,
you
know
subsidiary
and
we're
gonna
roll
this
application
out
to
our
subsidiaries
right.
These
are
all
common
things
that
companies
do.
B
B
Okay.
So
again,
we're
we're
capturing
data
in
30-second
intervals,
and
these
processes
are
now
just
starting
up
that
you
can
start
to
see
them
here
towards
the
left.
We
can
see
that
initially
we
had
just
the
one
transaction
engine
outlined
here
in
blue
and
you
know
by
the
way,
we're
tracking
the
memory
usage
for
each
pod
each
container
for
the
tes
and
storage
managers,
as
well
as
the
the
CPU
utilization
for
each.
B
B
It
was
processing
just
over
3,000
transactions
up
to
approximately
5,000
and
now
as
I
curse
over
here,
I
have
three
active
transaction
engines,
all
working
in
chorus
and
usin
here
together
to
process
more
right,
and
this
lower
panel
indicates
that
we
see
here
that
we
were
chugging
along
somewhere
around
four
thousand
equals
per
second
at
one
transaction
engine.
We
added
three
transaction
engines
and
with
that
increased
load,
we're
now
processing
over
8,000
sequel
statements
per
second
on
this
cluster
again,
this
is
just
a
five
node
cluster
running
in
a
AWS
running
OpenShift
4.1,
okay.
B
So
it's
literally
really
that
easy
to
scale
out
or
increase
database
throughput
to
match
a
an
application
workload
right.
We
can
also
scale
down
to
right,
like
if
we
were
to
take
some
of
those
applications.
Offline
I
could
just
as
easily
scale
down
my
database
and
use
less
resources
now
that
this
is
really
hard
to
do
with
any
other
legacy
tool.
You
know
again
those
tools
there,
they
don't
scale
out
independently
with
the
transaction
and
the
storage
layers
separately.
B
Nuodb
makes
it
very
easy
to
scale
either
independently.
So
we've
scaled
our
transaction
engines
to
three
with
the
Community
Edition.
We
do
allow
only
one,
but
we
would
love
to
be
able
to
work
with
you
on
a
proof
of
concept
and
provides
you
our
Enterprise
Edition.
So
you
can
also
scale
out
the
storage
layer
when
you
scale
out
the
storage
layer
you're
effectively,
creating
multiple
copies
of
your
databases.
Therefore,
if
you
were
to
lose
one
of
the
storage
managers,
your
database
would
continue
to
run.
B
It
would
be
your
applications
would
would
not
be
impact
at
all.
In
fact,
we
can
start
to
demonstrate
some
of
that
capability.
Now
that
we
have
three
transaction
engines
right.
We
have
redundancy
built
into
the
system
if
we
go
back
to
openshift.
You'll
recall
here
are
those
three
transaction
edges
that
are
running.
B
So
if
we
were
to
demonstrate
a
failure
event
again,
that's
why
so
many
customers
want
to
move
their
workloads
to
the
cloud
is:
if
there
is
a
failure,
there
are
built-in
systems
to
autocorrect
auto
recovery,
so
the
applications
run
unimpeded.
You
know
unimpacted,
so
we
are
redundant
here
right.
We
have
three
transaction
engines
Diane.
Could
you
do
us
a
favor?
Could
you
just
choose
one
of
these
transaction
engines
to
simulate
a
failure
event?
You
go
ahead
and
pick
one
and
we'll
go
ahead
and
and
kill
that
all
right
kill.
B
So
so
sorry,
here
for
write
this,
this
k9r
LZ,
so
we're
gonna
simulate
a
failure
event
now
failure
events
are
common
right.
In
fact,
our
software
is
built
for
failure
events.
We
expect
either
hardware
software
or
network
failures
to
occur
in
the
common
world,
which
they
do
so
we're
going
to
go
ahead
and
delete
this
pod.
Okay,
so
so
sorry,
but
there
you
go,
we're
gonna
delete
it
now
as
soon
as
we
delete
it.
Open
shifting
kubernetes
are
orchestrating
together.
B
Let's
you
see
this
one
terminating,
but
you
see
the
one
on
the
bottom
here
creating
and
it's
in
fact
already
running
so
in
about
four
or
five
seconds.
The
whole
system
has
identified
the
the
failure
event
and
it
has
replaced
this
transaction
pod
with
a
brand
new
one
mg
d
do
F,
okay!
Well,
that
was
pretty
cool
that
all
could
have
happened
in
my
sleep
right.
I
didn't
have
to
be
here
for
that
that
to
happen,
there's
no
manual
in
travail
intervention
to
restart
these
pots.
B
So
if
we
go
back
to
our
visual
monitoring
tool,
let's
see
what
that
might
look
like
now.
We
know
we
had
three
transaction
engines
and
they
were
all
processing
about
the
same
amount
of
transactions.
So
I
would
fully
expect
for
that
three
or
four
seconds
that
our
transaction
per
second
would
drop
and
we're
actually
starting
to
see
that
now.
I'm
gonna
demonstrate
this
by
choosing
the
last
five
minutes,
because
it
will
really
help
Joe
how
we
were
just
chugging
along
at
about
8,000
transactions
per
second
quite
nicely
and
then
whack
right.
B
We
had
this
little
failure
event,
so
you
see
on
the
Green
Line
that
the
transactions
per
second
drop
just
for
a
very
brief
moment
and
the
yellow
line
is
indicating
the
nuodb
behavior
right
that
we
were
at
three
transaction
engines
and
then
up.
We
fell
to
just
two
for
a
brief
period
of
time
and
then
look
what's
happening.
We're
fully
recovering
right
in
really
just
a
blip.
B
The
the
system
we're
seeing
that
the
system
self
healed
right,
while
one
transaction
engine
was
going
down,
the
other
one
was
coming
up
and
we
look
at
some
of
the
other
panels.
You
can
actually
see
that
if
you
follow
where
my
cursor
is
you'll
see
this
little
orange
one
here,
you
can
see
where
it
stopped
right.
That's
where
so,
that's
the
one
that
that
Diane
chose
to
to
kind
of
knock
knock
off
right
and
then,
if
we
follow
the
colors,
we'll
see
a
brand
new
one.
I
can
see
it
here.
B
It's
the
green
color
one
right,
starting
up
so
for
a
brief
moment,
I'm
we
just
had
the
two
running
right
and
then
here
now
we
have
three
running
again.
Okay,
so
it's
really
a
quite
you
know,
nice.
You
know
automated
system
and
really
built
for
enterprise
applications
right.
Many
customers
love
all
of
the
capabilities
of
nuodb
as
far
as
running
and
sequel
and
asset
transaction
compliant
and
all-out,
easy
and
scales.
But
in
the
end,
what
they
of
to
see
is
that
this
green
line
never
went
kerplunk
to
the
bottom
right.
That
would
be
application
impact.
B
That's
when
the
cuff
somebody
at
a
terminal
would
go
what
happens.
I
was
running
some
transactions
and
or
I'm.
Seeing
now
a
delay
in
my
screen
right
here,
there's
no
very
little
impact,
because
no
one's
gonna
notice,
the
difference
between
running
8,000
transactions
and
5,000
transactions
for
about
three
or
four
seconds.
Okay,
so
that's
gonna
kind
of
a
nice
demonstration.
B
You
know
so
far
of
of
how
we
can
you
know,
deploy
the
the
nuodb
operator
right
and
today
we
showed
it
from
the
command
line
and,
as
I
mentioned
earlier,
it'll
be
on
operator
HUD
soon
and
then
what
we
demonstrated
is
is
how
you
can
create
a
custom
database
by
editing
some
files
right.
We
did
Morneau
DB
CR
yah
mo,
and
we
saw
all
these
nice
little
parameters
that
you
can
edit
to
to
build
a
custom
database
and
then
what
we
did
is
we.
B
We
demonstrated
how
easy
it
was
to
scale
our
database
right,
we
added
more
applications,
and
then
we
added
right
here
right
three
of
three
transaction
engines
to
match
that
load
and
then
finally,
what
we
did
is
we
we
chose
to
show
the
resiliency
of
the
database
by
killing
one
of
the
transaction
engines
simulating
a
failure
event,
and
we
saw
how
OpenShift
and
and
and
kubernetes
worked
together
to
quickly
heal
the
system.
Now
again,
I
mentioned
that
we
are
using
the
Community
Edition,
the
Community
Edition
allows
for
three
transaction
engines
and
one
storage
manager.
B
So
we
could
do
the
same
thing.
If
we
were
to
deploy
the
Enterprise
Edition,
we
could
add
a
storage
manager
and
then
also
kill
one
of
those
off.
Likewise,
with
the
admin
layer,
we
have
three
admins,
so
we
could
go
ahead
and
kill
an
admin
and
and
also
see
that
the
applications
run.
Unimpacted
I
think
it's
also
interesting
to
which,
so
far
we
have
showed
you
how
you
can
completely
manage
and
monitor
the
ODB
from
open
ship.
So
far,
no
one
has
had
the
feel
of
learning
a
new
database
product
right.
B
You
haven't
needed
to
manage
nuodb
using
nuodb
commands
well
just
for
fun,
I'm,
going
to
show
you
the
new
DB
commands.
Ok,
if
we
connect
to
one
of
the
admins
but
I'm
going
to
connect
to
a
terminal
window.
Just
so
you
can
kind
of
get
the
feel
of
nuodb.
You
know
under
under
the
hood
and
that
there
you
know
there
is
a
running
domain
and
database
processes.
I'm
gonna
run
the
new
OC
MD
domain
command.
Ok
and
you'll
see
our
little
database.
We
know
together
right.
We
were
running
three
admins
right.
B
We
asked
for
three
admins,
so
you
know
so
here
they
are.
We
see
admin,
0,
1,
2,
1,
&,
2,
running
they're,
all
connected
to
the
system
and
then
down
below.
We
can
see
that
we
have
the
one
Storage
Manager
or
hard
for
me
to
actually
see
my
cursor
on
with
the
black
screen,
1
Storage
Manager
and
the
3
transaction
engines.
Ok,
and
we
can
see
that
they're
all
being
monitored
and
they're
all
in
a
running
State.
Ok.
B
So
there
is
a
new
DB
management
interface
that
you
can
connect
to
to
to
show
and
investigate
certain
things,
but
by
and
large
the
whole
system
is
designed
to
run
from
it's.
It's
hosted
kubernetes
management
tool
in
this
case
openshift
right.
So
we
have
seen
a
lot
I've
been
you
know
chatting
and
talking
through.
Everything
now
is
probably
a
good
time
to
take
a
little
pause
and
see
if
we
have
some
questions.
A
B
C
B
Great
great
yeah,
so
as
far
as
the
storage,
persistent
storage
options
yeah,
when
I
was
showing
the
file
earlier,
it's
kind
of
showing
how
you
can
choose
between
persistent
or
ephemeral.
We
pretty
much
always
go
with
persistent
as
a
database
should
always
be
viewed
as
a
stateful
application.
We
do
support
many
options
for
persistent
storage,
and
you
know
some
of
it
depends
on
your
application
right.
If
your
application
doesn't
have
a
high
I/o
kind
of
write
workload,
then
you
could
choose
to
do
something
you
know
similar
to
maybe
what
I
did
in
your
cloud
provider?
B
You
could
just
use,
like
you
know,
standard
storage
right
in
this
case
I'm
using
elastic
block
storage,
I'm
referencing
it
with
a
storage
class
called
GP,
2
right
and,
if
you're
running
in
Google,
you
would
change
that
to
standard,
and
if
you
were
using
this,
your
is
you'd
use
the
Azure
George.
But
if
you
want
to
use
some
other
storage
components,
you
certainly
can
we
have
tested
and
certified
with
several.
For
example,
port
works,
open
EBS
Lin
bit
some
of
the
more
common
ones
we
have
tested
with.
B
We
have
never
found
issues
using
these
tools.
I
can
make
some
recommendations
with
those
products
they
they
do
like
to
some
of
them
by
default
will
spin
up
a
replica
count
equal
to
three:
that's
really
not
necessary
with
nuodb,
because
our
Storage
Manager
effectively
is
creating
a
cop
the
database.
Now
here
we
had
just
the
one
storage
manager,
but
if
we
were
running
in
an
enterprise
environment
across
multiple
zones
or
regions,
we
would
start
up
more
storage
managers
and
that
would
create
persistence
across
a
geography.
B
Well,
I.
Don't
really
need
my
port
works
or
OpenShift
to
create
multiple
copies.
For
me
right,
for
example,
if
I
had
three
storage
managers
and
I
was
running,
port
works
with
replicas
equal
to
three
I.
Have
nine
copies
of
my
database?
Do
I
really
need
nine
copies,
probably
not
okay,
so
a
lot
of
times.
What
we
do
is
we
when
working
with
some
of
these,
you
know
high
throughput
third
party
storage
tools,
we
just
set
replicas
count
equal
to
1,
and
then
we
manage
replicas
through
our
storage
managers.
Okay.
B
Now,
as
far
as
the
DR
component
and
backup
and
recovery,
yes,
we
do
support
backup
and
recovery.
We
have
Yambol
templates
for
backup
and
recovery,
helm,
charts
for
backup
and
recovery.
We
support
full
incremental
and
journal
based
recovery
methods,
and
you
know
you
could
choose
to
run
either
in
an
active-active.
We
recommend
that
or
an
active/passive,
depending
on
your
kind
of
distance
between
remote
locations,
but
active-active
is
great
right
because
you
could
throw
storage
managers
live
in
each
region
and
if
you
lose
one,
your
applications
run
unimpacted,
you
don't
have
to
go
through
some.
B
You
know,
active-passive
trying
to
you
know,
bring
up
a
passive
node
which
can
always
be
you
know,
difficult
tenuous
procedure,
there's
always
some
time
associated
with
it
with
nuodb
running
across.
You
know,
clusters
and
nodes.
If
you
lose
any
one
of
the
processes
as
long
as
you
have
redundancy
in
that
process
type,
your
your
applications
will
continue
to
run.
Ok,
so
you,
in
other
words
you
don't
necessarily
have
a
dr
event
right.
In
fact,
in
our
documentation,
you
won't
find
disaster
recovery
because
we
we
use
a
different
model.
B
It's
what
we
we
tend
to
think
of
it
as
disaster
avoidance,
but
if
you
do
want
to
run
an
active/passive
for
any
reasons,
you
certainly
could
do
that
and
keep
a
live,
or
you
know,
frequently
refreshed
copy
on
a
remote
site
which
you
could
then
activate.
Okay,
so
hopefully
that
covers
you
know
both
parts
of
your
questions.
Do
you
have
any
follow-ups
there?
Oh
no.
C
Thanks
Joe,
so
I
was
wondering
you
know
the
the
backup
and
recovery
and
the
storage
options.
You
talked
about,
it's
perfectly
fine
in
a
cloud
environment,
but
when
it
comes
to
you
know,
on-premise
deployments
I
mean.
Is
there
any
recommendations
or
you
know,
options
for
these
type
of
scenarios
just
for
on
premised,
yeah.
B
I
mean
we
recommend
setting
up
a
you,
know,
a
backup
volume
right,
so
you're
gonna
set
up
volumes
typically
for
your
admin
layer,
your
storage
layer
and
then
your
backup
layers
so
and
they
could
be
of
different.
You
know,
speeds
and
feeds,
and
so
on.
So
yes,
we
recommend,
you
know
kind
of
like
a
backup
volume
and
and
that's
where
you
could
then
write
your
backups
to.
You
would
then
schedule
your
backups
through
the
new
ODB
interface.
B
You
know
the
template
and
Hellman
chart
model
that
we
have
and,
and
then
your
you
know,
you're
kind
of
good
to
go
you're,
keeping
a
regular
copy
of
your
database
tom.
Is
there
anything
that
you
would
like
to
add
about
kind
of
the
storage
persistence
or
you
know,
running
the
backups
again.
Tom
is
our
kind
of
chief
operator
and
kubernetes
developer.
So
you
know
he
may
also
have
some
inputs
to
add
there.
B
Ok,
great
and
yeah,
you
know,
as
I
mentioned
in
the
back
up
and
recover
3.
It's
we
have
home
church
for
that
today.
By
cube
con,
you
know
we'll
be
at
Luke.
53
stop
on
by
will
likely
have
our
back
in
recovery
working
from
our
operator
again.
The
whole
idea
of
the
operator
is,
is
you
know
when
you're
running
the
operator?
If
I
just
go
back
to
that
page,
you
know,
or
you
know,
from
the
the
command
line.
B
You
know
you
would
send
signals
to
the
operator
to
basically
do
things
right,
and
you
know
what
we
demonstrated
today.
It
really
is
a
level
four
operator.
You
know
if
you
look
at
the
operator
levels
right
level,
one
provisioning
level,
two
rolling
upgrade
level,
three
back
the
memory
level.
Four
is
a
workload,
metrics
collection
and
analytics,
so
we've
basically
demonstrated
our
level
four
operator
with
this
insights,
visual
monitoring
tool-
and
you
know
again
this
all
be
available
for
you
to
either
play
with.
If
you
would
like
today,
you
can
play
with
this
now.
B
If
we
just
jumping
back
quickly
to
our
slide
presentation,
the
last
slide
was
I
wanted
to
leave
a
link
where
you
can
go
and
try
and
play
with
this
yourself
to
try
the
new
DB
operator
yourself
just
go
out
to
our
new
ODB
github.
There's
a
new
ODB
golang
operator,
page
or
operator
page
now,
the
goal
angle
be
there
shortly
publicly
and
give
it
a
try
yourself,
like
I,
said
the
helm
operator.
Is
there
either
the
operator
hub
or
via
these
directions
on
the
github
Diane?
Do
we
have
any
other
questions?
I
think.
A
That
that
I
think
he
covered
most
of
the
questions
that
were
there
in
the
chat
and
I
think
he
actually
did
an
amazing
job
covering
out
all
the
features
and
functionality
and
I'm
really
looking
forward
to
seeing
the
golang
operator
up
there
and
operator
hub
I
can't
think
of
any
other
questions.
To
actually
ask
you,
because
you
did
such
a
wonderful
job.
There
I'm.
C
A
B
A
A
B
Bet
that's
right,
I'd
probably
be
about
two
or
three
weeks
away
and
and
Diane,
Tom
and
I
will
both
look
for
you
on
the
Monday
day,
zero
event
at
cube
Con,
so
you
and
I
have
already
met.
Of
course,
I
don't
think
you've
met
Tom,
so
Tom
and
I
are
all
signed
up
to
be
out
on
the
boat.
So
we're
looking
forward
to
that
and
I
would
see
these
these
days.
Zero
I've
attended
these
before
these
are
awesome.
Events
I
would
encourage
anyone
to
come
and
learn.
B
A
So
what
is
that?
What
Joe
is
referring
to,
if
you
don't
know,
is
we're
having
an
open
ship
Commons
gathering
on
November
18th,
which
at
koukin
is
considered
day
zero
and
we
have
rented
the
largest
yacht
I
could
find
with
a
540
person
auditorium
on
it.
It
will
be
tied
up
to
the
dock
in
San
Diego
right
near
the
Convention
Center,
where
coop
con
is,
and
we
are
going
to
navigate
through
a
whole
lot
of
very
interesting,
open
ship
use
cases.
A
Con
they'll
they'll
they'll
be
easy
to
find
on
the
vendor
floor,
and
this
is,
you
know,
it's
a
great
opportunity,
the
gatherings
to
really
get
to
know
and
meet
your
peers
and
make
those
connections
so
I'd
encourage
everybody
to
join
us
in
San
Diego
for
the
open
ship,
Commons
gathering
and
yeah
join
us
on
the
boat.
It's
going
to
be
fun,
we'll.
A
All
right
well,
thank
you
all
for
taking
the
time
today
to
join
us
and
thank
you,
Joe
and
Tom,
for
putting
this
together
and,
as
I
said,
we'll
be
uploading.
This
to
our
YouTube
channel
and
I
will
link
in
the
slides
and
you
can
find
the
the
video
links
and
everything
on
openshift
com,
the
blog
as
opposed
probably
tomorrow
afternoon,
and
we
will
make
sure
we
schedule
a
follow
up
soon.