►
From YouTube: Configuring Ceph Deployments with an Easy to Use Calculator - Karl Vietmeier, Intel Corporation
Description
Configuring Ceph Deployments with an Easy to Use Calculator - Karl Vietmeier, Intel Corporation
When deploying a Ceph cluster, some of the most common questions include: How much RAM do I need? What is the recommended ratio of OSD storage size to the RocksDB size? Which CPU is the best? How many disks should I include per node? In this presentation, attendees will be shown, step by step, how to use an Excel template to properly answer the above questions and configure a Ceph cluster to meet end-user needs. Attendees will also be given the Excel template to use for their own deployments or in the field when working with end users.
About Karl Vietmeier
Senior Solution Architect, Intel Corporation
I am a Cloud Architect at Intel with a focus on Storage Solutions. | Talk to me about: | NVMe | Object Storage | Linux
A
All
right
are
we
ready
so
I'm,
I,
guess,
I
think
it
didn't
get
introduced.
I'm
Carl,
via
amara
I'm,
one
of
the
cloud
solutions,
architects
at
Intel
in
our
data
center
organization,
so
I
got
about
five
minutes
today
and
we're
gonna
talk
about
something
we
get
a
lot
of
questions
on,
which
is
how
big
should
my
wall
and
DB
partitions
be
and
how
much
space
do
I
need.
A
So
what
we
decided
to
do
is
since
there's
since
there's
quite
a
bit
of
speculation
and
and
back
and
forth,
and
also
the
docs
would
give
a
recommendation
particular
recommendation
that
ends
up
fairly
large
fairly
the
four
percent
and
which
ends
up
you
start
comparing
and
looking
at
sizing
and
pricing
of
Flash
that
maybe
that's
maybe
we
need
a
little
bit
less
than
what
the
docs
say.
So
what
we
decided
to
do
is
rather
than
guess,
we
decided
to
actually
go
and
empirically
test
it.
So
we
have.
A
We
already
have
some
benchmark
servers
and
benchmark
clusters
set
up,
so
we
just
took
one
of
those.
Our
existing
clusters,
which
looks
like
this
pretty
standard
benchmarking
configuration.
We
did
use
one
generation
older,
so
you'll
notice.
Those
are
the
Broadwell
processors
in
there,
but
it
is
is
using
our
4500
and
the
octane
for
the
wall
in
DB.
So
it's
a
again
pretty
standard
set
of
pretty
standard
set
of
servers
that
we
would
benchmark
against.
A
Then
what
we
did
is
it
is
because
it
is
blue
store.
We
did
two
OSD.
As
per
nvm,
you
drive
3x
replication,
we
use
CBT
and
grow
fauna,
so
you'll
see
the
graph
is
from
Griffin
ax
and
we
use
for
a
4
KB
to
start,
but
we
did
test
a
range
of
Iowa
sizes
and
it
is
luminous
our
mimic
I'm.
Sorry,
so
pretty
pretty
reflective
of
what
you
might
actually
be
using.
So
this
is
a
chart.
What
this
shows
is
the
the
wall.
A
Size
is
really
a
function
of
the
metadata
and
how
much
metadata
is
being
processed
and
how
fast.
So
what
we
did
is
we
took
that
same
back.
Configuration
with
a
standard
for
Meg
object,
size
in
Seth
RBD,
and
then
we
just
you'll
notice,
there's
a
lot
of
lines
on
there.
What
those
are
is
we
just
went
ahead
and
wanted
to
see
from
4k
8
K,
16,
K
32k
up
to
one
megabyte
of
I/o
size,
just
ran
the
iyo
test
through
CBT
to
get
a
range
and
see
what
it
like.
A
Well,
it
turns
out
that
about
the
largest-
and
we
don't
have
it
on
here,
but
if
you
look
at
the
max
was
around
18
something
really
18.5
KB.
So
we
just
you
know.
We
said:
okay,
we're
gonna,
take
a
worst
case
and,
let's
set
it
at
20
K,
let's
just
set
a
ceiling
at
a
20
K
of
metadata
per
object
figure
want
to
be
a
little
bit
conservative.
A
So
then,
what
we
did
is
we,
starting
from
that
for
the
rocks
DB
with
the
standard
for
mega
object,
size,
20,
K
Tet,
the
20
K
of
metadata
size
turns
out
based
on
measurements,
actual
measurements,
that
it
looks
like
around
5
gigabytes
of
metadata
of
metadata
per
OSD.
One
terabyte
of
OSD
looks
looks
like
enough
to
be
enough,
and
this
is
based
on
those
tests
that
you
saw
before
now.
If
you
compare
and
the
little
chart
I
have
there,
if
you
make
a
comparison,
the
documentation
says
to
use
4
percent.
A
Now,
if
you
choose
that,
if
you
take
that
number
and
a
40
terabyte,
so
a
40
terabyte
is
denote,
which
would
be
a
reasonable
size
for
an
all
flash
and
remember.
These
are
focused
around
all
flash
staff
configurations,
so
40
60,
80
terabytes,
is
pretty
reasonable
for
say,
six
six
drives
twelve
OSDs
1.6
gigabytes.
So
that's
1.7,
terabytes
of
rocks
DB
that
you
need.
But
if
you
use
that,
if
based
on
the
empirical
testing,
we
did,
it
looks
more
in
the
range
of
2
to
3
to
400
gigabytes.
A
Now,
you're
gonna
want
to
test
that
yourself.
Maybe
you
want
to
recreate,
replicate
the
testing
that
we
did,
but
we've
found
a
pretty
significant
size
difference
based
between
the
documentation
and
our
and
our
testing
and
the
wall
turns
out.
Well,
you
don't
need
much
space
at
all
for
the
wall
and
the
wall
is
more
a
function
of
the
rate
of
change.
So
if
the,
if
the
rocks
DV
is
a
function
of
how
much
metadata
is
being
run
through
the
cache,
the
wall
size
is
a
function
more
of
the
rate
of
change.
How
quickly?
A
How
much
do
we
need
to
buffer?
So
again,
we
thought
we'd,
be
pretty
conservative
put
in
an
80
second
buffer,
so
you
got
about
80
seconds
of
buffer
cache.
Kinda
hundred
mega
get
gigabits
per
second
network.
Now
you
know
for
us,
for
maybe
an
s3
object
store,
something
like
that.
Hundred
gigabytes
is
more
probably
than
enough,
but
we
found
in
our
benchmark
testing
in
with
all
flash
configurations
that
we
can.
A
So
you
would
take
that
5
gigabyte
it
by
an
arc
in
this
case
I
think
we
had
six
drives
so
five
gig
divided
by
six,
and
then
that
would
be
how
the
partition
you
would
want
to
create
on
your
obtain
drive,
I'm,
not
sure
how
I'm
doing
for
time.
It
seems,
like
five
minutes
seems
short,
but
it
ends
up
being
long
when
you're
up
here
and
I
think
that's
about
it
really
I
mean
we
didn't
want
to
take
up
too
much
time.
A
But
this
is
a
question
we
get
a
lot,
and
so
we
want
to
just
make
sure
we
had
a
good
quantitative
answer
for
that
question
because
we
didn't
want
to
guess
and
it
seemed
it
did
seem
that
the
numbers
it
seemed
they
were
a
bit
larger
than
what
maybe
we
needed
when
we're
talking
to
customers
and
we're
looking
at
sizing
and
figuring
out
what
drives
to
use.
You
know.