SCI Lab Test Validation Report: NetApp Storage Efficiency

SCI Lab Test Validation Report:
NetApp Storage Efficiency

Silverton Consulting, Inc.

StorInt™ Briefing

Written by: Ray Lucchesi
Published: July 2012

SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Executive
Summary

Silverton
Consulting
tested
a
number
of

Table
of
Contents

NetApp’s
widely
used
software
storage

efficiency
features
on
a
FAS3240
storage
Executive
Summary

system
using
a
mix
of
data
types.
The
testing
Introduction

was
designed
to
measure
the
cumulative
Test
Step
1:
Baseline

impact
of
multiple
efficiency
technologies
Cumulative
storage
efficiency

when
used
together,
and
as
a
result,
several
Test
Step
2:
Thin
provisioning

test
phases
were
required.
Test
Step
3:
Data
deduplication

Test
Step
4:
Data
compression

The
first
phase
tested
three
NetApp
storage
Copy
services

efficiency
features.

Specifically,
the
storage
Test
Step
5:
Snapshot
copy

system
was
thick
provisioned
to
create
a
Test
Step
6:
FlexClone
copy

baseline
and
then
cumulatively
thin
Performance

provisioned,
deduplicated
and
compressed,
Test
Step
7:
Performance

all
using
the
same
data.

Storage
capacity
Summary

requirements
were
assessed
after
each
step
Appendices

to
measure
any
savings
that
occurred.

At
the

end
of
this
phase,
the
thinly
provisioned,
deduplicated
and
compressed
storage

saved
an
impressive
79%
when
compared
with
the
baseline
capacity
requirements.

The
second
phase
examined
two
NetApp
copy
services:
Snapshot™
and
FlexClone™.

During
this
phase,
the
storage
at
the
end
of
the
prior
phase
was
first
Snapshot

copied
and
then
FlexClone
copied.

Capacity
requirements
were
again
evaluated

after
each
NetApp
copy
had
completed
to
compare
against
the
baseline.
Once
again,

storage
capacity
requirements
for
both
copies
were
substantially
less
than
baseline.

The
final
phase
ran
a
mixed
workload
against
the
FlexClone
copies
of
the
previous

phase
to
determine
how
capacity
efficiency
and
copy
services
impacted

performance
for
the
storage
system
under
test.

In
the
first
phase
above,
after

creating
the
storage
baseline,
a
set
of
database,
email
and
file
system
workloads

were
run.

For
this
phase
those
workloads
were
run
once
more,
only
this
time

against
the
deduplicated,
compressed,
and
FlexClone
copied
data.

This
final
step

showed
little
to
no
performance
degradation
when
using
deduplicated,
compressed

and
cloned
data
as
compared
against
baseline
performance.

©
2012
Silverton
Consulting,
Inc.
Page
1

twitter.com/RayLucchesi|RayOnStorage.com

All
Rights
Reserved

+1-720-221-7270|SilvertonConsulting.com

SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

SUMMARY:
Cumulative
Effect
of
NetApp
Storage
Efficiency
Features

SUMMARY:
Savings
from
NetApp
Space
Efficient
Copy
Features

©
2012
Silverton
Consulting,
Inc.
Page
2


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Introduction

NetApp
recently
contracted
with
Silverton
Consulting
Inc.
(SCI)
to
independently

validate
the
substantial
storage
capacity
savings
attainable
with
NetApp
systems.

The
three
storage
efficiency
features
rigorously
tested
included
thin
provisioning,

data
deduplication
and
data
compression.

NetApp
further
engaged
SCI
to
verify
the

storage
copy
efficiency
capabilities
of
NetApp’s
Snapshot
and
FlexClone
features.1

In
a
final
corollary
phase
of
testing,
SCI
was
asked
to
independently
authenticate
the

I/O
performance
of
the
storage
system
with
data
already
subjected
to
the
efficiency

features
under
trial.

NetApp
storage
system
test
environment

One
NetApp
FAS3240
storage
system
running
Data
ONTAP
8.1
operating
in
7-‐Mode,

with
~20TB
of
SAS
disk
and
10GbE
interfaces
was
installed
at
SCI’s
lab.

The
storage

was
arranged
as
a
RAID-‐DP
configuration
(19-‐data
and
2-‐parity,
using
450
GB
SAS

disk
drives)
with
two
(2TB)
aggregates
and
five
user
volumes:

• One
volume
with
629GB
of
storage
for
a
file
system,

• Two
volumes
configured
as
a
629GB
iSCSI
LUN
for
SQL
Server
database

tables
and
the
second
as
a
SQL
log
volume
of
~105GB
iSCSI
LUN,

• Two
more
volumes
to
hold
iSCSI
LUNs,
one
configured
with
629GB
for
a

Microsoft
Exchange
database
and
the
other
LUN
with
~42GB
for
an
Exchange

log
file.

The
storage
system
was
equipped
with
8GB
of
system
RAM/cache
and
was

connected
to
lab
servers
using
three
separate
10GbE
interfaces,
one
for
the
file

workload
and
two
for
the
SQL
database
and
email.

No
FlashCache
or
Fibre
Channel

interfaces
were
used
during
the
testing.

The
specific
NetApp
system
options

employed
to
store
this
data
were
as
follows:

• Volume
Space
Guarantee
=
volume

• LUN
Set
Reservation
=
enable

• Fractional
Reserve
=
100%

• Snapshot
Reserve
(Aggregate
and
Volume)
=
5%.

These
system
storage
parameters
were
selected
to
establish
a
thickly
provisioned

baseline
and
insure
that
any
space
savings
or
consumption
afforded
by
the
storage

efficiency
features
under
further
evaluation
would
be
more
accurately
assessed.

That
is,
the
performance
and
capacity
results
experienced
would
be
due
solely
to
the

storage
efficiency
feature
under
test.

1
For
a
customer
case
study
on
NetApp
storage
efficiency
features
see
our
report
on

Achieving
Exceptional
Storage
Efficiency
with
NetApp
Storage
available
at

http://media.netapp.com/documents/ar-‐exceptional-‐data-‐density.pdf

©
2012
Silverton
Consulting,
Inc.
Page
3


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Actual
test
process

The
actual
test
was
a
multi-‐step
task
where
data
was
loaded
to
the
storage
then

capacity
measurements
using
NetApp/Windows
facilities
were
taken
initially
to

establish
baseline.
The
same
measurements
were
then
taken
again
after
thin

provisioning,
data
deduplication
and
data
compression
were
progressively
enabled

and
the
resulting
transformation
process
was
complete.
Additionally,
capacity

measurements
were
taken
after
the
workload
was
run
to
isolate
and
identify
the

data
growth
due
solely
to
the
workload
process.

The
actual
workload
mixture
used
in
the
testing
process
was
specifically
designed
to

more
closely
emulate
and
approximate
realistic
operating
conditions
for
a
storage

system.

In
addition,
the
three
types
of
workloads
were
run
simultaneously
to
better

mirror
real
shared
storage
use
operations;
running
any
one
of
these
workloads
in

isolation
would
have
generated
significantly
different
throughput.

For
performance,
measurements
were
taken
only
after
the
baseline
data
was
loaded

and
then
again
after
all
storage
efficiency
features
were
enabled.

The

measurements
were
reported
on
minutely
over
the
concurrently
working
simulated

file,
SQL
database
and
email
workload
runs.

These
measurements
were
derived
by

using
Window’s
Perfmon,
running
on
each
of
the
three
VMs,
executing
the
different

workloads.

Using
this
approach,
individual
performance
measurements
for
each
of

the
three
workloads
was
determined.

Because
of
the
realistic
workload
design,
high
variability
of
performance

measurements
was
expected
and
in
fact,
experienced
during
evaluation.

As
such,

average
performance
was
used
to
compare
throughput
operations
between
the

baseline
and
final
all
features
test
step.

Test
Step
1:
Baseline

To
measure
subsequent
capacity

savings
and
performance,
the

measurement
tools
were
used
to

establish
both
baseline
numbers

after
the
data
had
been
loaded
onto

the
storage
as
well
as
after
a

simulated
workload
run.
That
is,
the

data
was
initially
loaded
and
a

workload
processed
with
no
storage

efficiency
features
enabled;
the

resulting
measurements
were
the

baseline
numbers
for
subsequent

comparisons.

Figure
1
Baseline
capacity
requirements
summary
chart

©
2012
Silverton
Consulting,
Inc.
Page
4


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Baseline
capacity
parameters

After
the
initial
data
was
loaded
but
before
any
storage
efficiency
features
were

enabled,
the
capacity
measurements
reported
by
the
Windows
host
validated
the

NetApp
storage
system
measurements.

In
fact,
the
reported
measurements
were

identical
and
as
follows:

• File
system
storage

-‐
629.1GB

• SQL
DB
storage
–
629.1GB

• SQL
Log
storage
–
104.9GB

• Email
DB
storage
–
629.1GB

• Email
log
storage
–
41.9GB

• Total
baseline
storage
capacity
–
2.0TB.

Baseline
performance

Figure
2
Baseline
performance
run

Figure
2
graphs
the
performance
achieved
by
the
NetApp
storage
without
enabling

any
capacity
efficiency
features.

As
can
be
seen,
each
type
of
workload,
experienced

wide
variability
as
follows:

©
2012
Silverton
Consulting,
Inc.
Page
5


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

• The
file
workload
varied
between
a
high
of
~70
MB/sec.
to
a
low
of
~3

MB/sec.,

• The
SQL
Server
workload
varied
between
~134
and
~54
MB/sec.,
and

• The
email
workload
varied
between
~37
and
~28
MB/sec.

However,
average
baseline
performance,
also
depicted
in
Figure
2,
showed
mean

throughput
as
follows:

• File
services
average
performance
was

~25
MB/sec.

• SQL
Server
DB
average
performance
was

~97
MB/sec.

• Email
average
performance
was

~33MB/sec.

Cumulative
storage
efficiency
tests

During
this
phase
of
the
testing,
we
enabled
NetApp
thin
provisioning,
data

deduplication
and
data
compression
features
against
the
test
data
created
during

the
baseline
test
step
above.

The
intent
of
this
phase
of
the
testing
was
to
determine

what
if
any
storage
capacity
requirements
could
be
saved
by
an
aggressive
use
of

these
features.

Test
Step
2:
Thin
provisioning

Although
not
required
to
apply
thin
provisioning,
the
data
was
reloaded
in
order
to

start
from
the
same
conditions,
then
thin
provisioning
was
enabled
in
the
next
trial

iteration
by
setting
“Vol
options
guarantee=none”
and
“LUN
set

reservation=disable”
for
each
volume
and
LUN.
The
thin
provisioning
feature

saved
capacity
by
freeing
up
unused
space
in
partially
used
volumes
and
LUNs.

Thin

provisioning
also
allowed
the
creation
of
many
more
file
systems
and
LUNs
on
the

storage
system

(‘oversubscription’).

Substantial
savings
were
anticipated
but
were

dependent
on
how
much
empty,
yet

reserved
space
had
been
allocated

to
each
volume
as
a
result
of
using

thick
provisioning.

Thin
provisioning
capacity

requirement
savings

Figure
3
clearly
shows
the
dramatic

reduction
in
storage
capacity

requirements
that
enabling
thin

provisioning
afforded.

However,

this
savings
was
entirely
dependent

on
the
amount
of
allocated
and

never
written
space
available.

Figure
3
Thin
provisioning
capacity
requirements

Comparing
the
baseline
capacity
to

©
2012
Silverton
Consulting,
Inc.
Page
6


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

the
pre-‐workload
capacity
requirements
using
thin
provisioning,
the
following

available
storage
capacity
requirements
savings
percentages
were
derived
on
this

pass
of
the
test:

• File
system
storage:
211.7GB,
a
substantial
66%
savings
over
baseline

capacity.

With
thin
provisioning,
the
file
system
reserved
only
as
much
space

as
data
written,
releasing
significant
storage
capacity
for
other
use.

• SQL
DB
storage:
473.6GB,
a
moderate
savings
of
25%
over
baseline

capacity.

Thin
provisioning
freed
up
all
of
the
SQL
DB
LUN’s
reserved
space

that
had
yet
to
be
written.

• SQL
log
storage:
1.2GB,
an
outstanding
savings
of
99%
over
baseline

capacity.

Much
if
not
all
of
the
log
space
had
never
been
written.

• Email
database
storage:
414.0GB,
a
significant
savings
of
34%
over

baseline
capacity.

Similarly,
thin
provisioning
freed
up
all
email
database

reserved
space.

• Email
log
storage:
0.1GB,
another
outstanding
savings
of
over
99%
from

baseline
capacity.

Again,
the
same
as
that
described
above.

Overall,
thin
provisioning
saved
a
remarkable
45+
percent
of
the
capacity
used
in

the
baseline
step.

It
should
be
noted
that
actual
storage
efficiency
measurements
for
this
and
all

remaining
steps
was
calculated
solely
from
internal
NetApp
storage
commands.

The

Windows
command
that
normally
displays
storage
capacity
does
not
recognize
thin

provisioning,
deduplication
or
compression
and
thus,
does
not
report
on
capacity

savings
or
any
measurement
to
derive
capacity
savings.

In
this
step,
the
NetApp
CLI

“df
-‐k”
command
was
used.

Test
Step
3:
Data
deduplication

The
next
storage
efficiency
feature
enabled
in
the
trial
was
data
deduplication
on

top
of
the
already
thinly
provisioned
storage.

This
feature
was
enabled
and
then

run
by
issuing

“sis
on”
and
“sis
start
–s”
commands
at
the
volume
level.

NetApp’s

deduplication
feature
was
expected
to
reduce
storage
used
by
eliminating
duplicate

4KB
data
blocks
within
a
volume.

However,
the
anticipated
savings
were
expected

to
vary
significantly
depending
on
the
amount
of
duplicate
blocks
present
from

volume-‐to-‐volume.

Storage
efficiency
was
calculated
using
the
NetApp
CLI
“df
–S”

command.2

Data
deduplication
capacity
requirement
savings

As
shown
in
Figure
4
below,
data
deduplication
resulted
in
additional
storage

capacity
savings.

The
significant
reduction
in
used
storage
space
was
realized

2
NetApp
has
written
a
guide
to
implementing
deduplication
that
can
be
found
at

http://media.netapp.com/documents/tr-‐3958.pdf

©
2012
Silverton
Consulting,
Inc.
Page
7


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

almost
entirely
due
to
the
email
and

file
system
data
being
responsive
to

the
dedupe
process.

Actual
capacity

savings
after
data
deduplication

were
as
follows:

• File
system
storage:

118.3GB
of
data
stored,
a

44%
incremental
savings

over
thin
provisioning

capacity
requirements.

• SQL
DB
storage:
452.4GB
of

data
stored,
a
slight,
4%

incremental
savings
over

Figure
4
Data
deduplication
capacity
requirements

thin
provisioning
capacity.

• SQL
log
storage:
18MB
of
data
stored,
a
99%
incremental
savings
over
thin

provisioning
capacity.

• Email
database
storage:
87.0GB
of
data
stored,
an
impressive
79%

incremental
savings
over
thin
provisioning
capacity.

• Email
log
storage:
2MB
of
data
stored,
a
97%
incremental
savings
over
thin

provisioning
capacity.

Overall,
data
deduplication
saved
an
additional
40+
percent
of
the
capacity
used
in

the
thin
provisioning
step.

Test
Step
4:
Data
compression

Data
compression,
a
compute
intensive
efficiency
feature,
was
enabled
for
the
thinly

provisioned
and
deduplicated
storage
for
the
fourth
pass
by
issuing
a
“sis
config
–C

TRUE”
command
followed
by
initiating
compression
using
the
“sis
start
–S
–C”

command
at
the
volume
level.

This
command
scanned
all
current
volume
and
LUN

data
and
automatically
compressed
it.

This
compression
activity
of
the
original
data

was
completed
prior
to
any
further
testing
steps.

However,
by
not
using
the
“-‐I”

option
in
the
command
above,
offline
compression
was
activated.

NetApp
does
offer

inline
compression
but
offline
was
used
to
more
closely
emulate
a
customer
that

wanted
the
space
savings
of
compression
but
executed
off
hours
to
minimize
the

impact
on
daily
IO
activity.

The
data
compression
feature
was
expected
to
increase

free
capacity
by
reducing
repeating
patterns
of
data
within
the
volume.
Storage

efficiency
was
calculated
using
the
NetApp
CLI
“df
–S”
command.

Data
compression
capacity
requirement
savings

As
shown
below
in
Figure
5,
storage
savings
were
moderate
using
the
data

compression
feature
against
previously
deduplicated
and
thinly
provisioned
data.

However,
these
realized
savings
were
only
modest
due
to
the
inherent

compressibility
of
the
data.

That
is,
image
and
zipped
or
archive
(already

compressed)
files
did
not
further
compress
well
whereas
Microsoft
Office
files
were

©
2012
Silverton
Consulting,
Inc.
Page
8


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

compressed
by
50
percent
or
more.

Database
and
email
compressibility
rates
also

varied
considerably.

In
this
step,
actual
capacity

savings
after
data

compression
were
as

follows:

• File
system
storage:

106.1GB
of
data

stored,
a
10%

incremental
savings

over
capacity
present

for
the
data

deduplication
step.

This
only
modest

savings
was
primarily

Figure
5
Data
compression
capacity
requirements

due
to
the
nature
of

the
test
file
data,
which
consisted
of
email
and
incompressible,
image
data.

• SQL
DB
storage:229.2GB
of
data
stored,
a
49%
incremental
savings
over

data
deduplication
capacity,
primarily
due
to
the
amount
of
text
and
web
log

data
present
in
the
tables.

• SQL
log
storage:
17.8MB
of
data
stored,
a
slight
2%
incremental
savings

over
data
deduplication
capacity.

• Email
database
storage:
87.0GB
of
data
stored,
a
minimal
<1%
incremental

savings
over
data
deduplication
capacity
due
to
the
nature
of
the
test
data

used
for
email
data.

• Email
log
storage:
1.8MB
of
data
stored,
a
13%
incremental
savings
over

data
deduplication
capacity.

Overall,
compression
saved
an
additional
36
percent
of
the
capacity
used
in
the

deduplication
step.

Copy
services
tests

After
storage
capacity
measurements
for
thin
provisioning,
data
deduplication
and

data
compression
were
established,
a
single
set
of
Snapshot
and
FlexClone
copies

were
taken
of
the
test
data.

This
was
done
to
ascertain
capacity
requirement

savings
provided
by
NetApp’s
point-‐in-‐time
volume
and
LUN
storage
copies,
i.e.

read-‐only
Snapshot
copies
and
read-‐write
FlexClone
copies.
Then
the
workload
was

run
against
the
FlexClone
copies.

Both
Snapshot
and
FlexClone
copy
capacity
requirements
were
expected
to
be

significantly
smaller
than
source
data
capacity
requirements.

However,
this

presented
a
significant
dilemma
as
to
when
to
measure
Snapshot
and
FlexClone

©
2012
Silverton
Consulting,
Inc.
Page
9


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

capacity
requirements.

There
are
at
least
two
very
different
alternatives:
1)

Measure
copy
capacity
requirements
before
a
performance
workload
was
run

against
the
source
data
and
2)
Measure
copy
capacity
requirements
after
a

performance
workload
was
run
against
the
source
data.

Pre-‐workload
Snapshot

and
FlexClone
copies
only
store
meta-‐data
to
describe
the
data
being
copied
and

points
to
the
original
source
data.

In
contrast,
a
post-‐workload
Snapshot
and

FlexClone
copies
must
store
this
meta-‐data
plus
any
original
data
that
was
modified,

thus
consuming
more
storage
capacity.

As
a
result,
post-‐workload
copy
capacity

requirements
were
measured
and
compared
with
the
post-‐workload
baseline

capacity
measured
in
Test
Step
1
(see
p.
4).

Test
Step
5:
Snapshot
copy

In
this
step,
Snapshot
copies
were
taken
of
the
data
by
using
the
“snap
create”

NetApp
command.

In
Figure
6
below,
post-‐workload
Snapshot
copies
capacity

requirements
were
measured
and
compared
against
the
baseline
capacity
after
the

workload
was
run.

The
Snapshot
copies
were
expected
to
be
significantly
smaller

than
source
data
as
any
storage
capacity
consumed
should
only
represent
data

modified
from
the
original.

Snapshot
copy
capacity
requirement
savings

Figure
6
clearly
shows
that
the
capacity
requirements
for
the
post-‐workload
set
of

Snapshot
copies
were
significantly
smaller
than
the
post-‐workload
baseline
source

data.

The
capacity
consumed
by
Snapshot
copies
only
slightly
registered
on
the

chart
as
it
represented
the
incremental
space
required
to
store
any
changes
to
the

source
data.

Actual
post-‐workload
capacity
measurements
for
the
Snapshot
copies

were
as
follows:

• File
system
Snapshot
storage:
6.8GB
of
data
stored,
an
outstanding
99%

savings
over
the
capacity

present
for
the
baseline
data

file
system.

• SQL
DB
Snapshot
storage:

90.1GB
of
data
stored,
an

86%
savings
over
the

capacity
present
in
the

baseline
SQL
data.

• SQL
log
Snapshot
storage:

7MB
of
data
stored,
a
100%

savings
over
the
capacity

present
in
the
baseline
email

log
data.

• Email
database
Snapshot

Figure
6
Snapshot
copy
capacity
requirements

storage:
7.5GB
of
data

stored,
a
99%
savings
over

©
2012
Silverton
Consulting,
Inc.
Page
10


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

the
capacity
present
in
the
baseline
email
database.

• Email
log
Snapshot
storage:
<1MB
of
data
stored,
a
100%
savings
over
the

capacity
present
in
the
baseline
email
log
data.

Of
note,
NetApp
Snapshot
capacity
is
entirely
contingent
upon
the
amount
of
data

modified
since
the
original
Snapshot
copies
were
taken.

Thus,
heavily
modified
data

will
consume
more
Snapshot
space
and
may
grow
over
time
as
the
source
data
is

updated.

Test
Step
6:
FlexClone
copy

As
the
next
step
in
the
rigorous
testing
of
NetApp’s
storage
features,
measurements

were
derived
after
taking
NetApp
FlexClone
copies,
another
type
of
space
efficient,

point-‐in-‐time
copy
of
source
data.

These
copies
differed
from
NetApp
Snapshot

copies
because
they
could
be
written
as
well
as
read.

Once
again
post-‐workload

FlexClone
capacity
requirement
measurements
were
measured
and
compared
to

post-‐workload
baseline
numbers
to
determine
the
capacity
requirement
savings.

Once
more,
significant
storage
capacity
requirement
savings
were
anticipated
for

these
copies
of
the
source
data.

FlexClone
copy
capacity
requirement
savings

As
expected,
the
numbers
generated
in
the
trial
and
depicted
in
Figure
7,
shows
the

significant
storage
capacity
requirement
savings
available
by
taking
a
FlexClone

copy
of
the
source
data.

In
this
step,
actual
post-‐workload
FlexClone
capacities
were

as
follows:

• File
system
FlexClone
storage:
66.6GB,
an
89%
savings
over
the
capacity

present
in
the
baseline
data.

• SQL
DB
FlexClone
storage:

200.9GB,
a
68%
savings

over
the
capacity
present
in

baseline
SQL
data.

• SQL
log
FlexClone
storage:

65.2GB,
a
34%
savings
over

the
capacity
present
in
the

baseline
SQL
log
data.

• Email
database
FlexClone

storage:
115.8GB,
an
82%

savings
over
the
capacity

present
in
the
baseline

email
data.

• Email
log
FlexClone
Figure
7
FlexClone
copy
capacity
requirements

storage:
349MB,
an
89%

savings
over
the
capacity
present
in
the
baseline
email
log
data.

©
2012
Silverton
Consulting,
Inc.
Page
11


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Similar
to
Snapshot
copies,
space
savings
from
FlexClone
copies
depended
on
the

amount
of
data
modified
from
the
original
source
storage.

However,
calculating
the

space
used
by
FlexClone
copies
was
more
complex.
In
this
case,
the
NetApp
“vol

clone
split
estimate”
command
was
relied
on
to
provide
the
amount
of
space

shared
between
the
source
data
and
its
clone.

The
space
consumed
by
the
clones

was
then
calculated
as
the
difference
between
the
capacity
used
by
the
FlexClone

data
and
the
estimate
of
shared
storage.

Performance
testing

Test
step
7:
Thin
provisioning,
deduplication,
compression,
Snapshot
and

FlexClone
performance
results

After
all
capacity
efficiency
features
and
copy
services
discussed
above
were

enabled,
baseline
workloads
were
rerun
to
determine
their
impact
on
storage

system
performance.

As
discussed
above,
all
the
workloads
were
run
against

FlexClone
copies
with
thin
provisioning,
deduplication,
compression
and
Snapshot

copy
enabled
and
compared
against
a
similar
workload
run
against
the
original

baseline
data
to
test
how
these
features
and
copy
services
would
impact
storage

performance.

System
capacity
requirements
did
not
change
from
previous
steps

and
have
thus,
not
been
reported
on
again
(see
pp.
9,
10
&
11).

Performance
results
after
capacity
efficiency
and
copy
services
were
enabled

In
Figure
8
below
both
the
baseline
and
the
capacity
efficiency
and
copy
services

run
results
were
shown
side-‐by-‐side
to
facilitate
easy
comparison.

Some
impact

from
all
the
storage
features
was
expected,
but
system
performance
significantly

exceeded
predictions.

©
2012
Silverton
Consulting,
Inc.
Page
12


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Figure
8
Baseline
vs.
all
features
performance
comparison
chart

In
fact,
enabling
NetApp’s
space
saving
features
of
thin
provisioning,
data

deduplication,
compression
along
with
Snapshot
and
FlexClone
copy
actually
had
a

positive
effect
on
storage
performance
during
some
of
our
testing.
Specifically,
no

negative
performance
was
seen.

Performance
of
the
all
features
enabled
workloads

were
as
follows:

• Average
SQL
DB
performance:
118
MB/sec.,
an
improvement
of
22%

versus
the
baseline
performance.

• Average
email
performance:
40
MB/sec.,
an
improvement
of
24%
over

baseline
performance.

• Average
file
system
performance:
only
a
slight
negative
performance

impact,
24
MB/sec.,
for
only
a
minor,
<1%
degradation
over
baseline

performance,
which
could
arguably
be
considered
noise
in
the
performance

run.

Overall,
total
median
performance
also
improved
incrementally
when
all
of
the

storage
efficiency
features
were
enabled.

Also
evident
in
Figure
8
is
the
increased
variability
of
the
all
features
run,
i.e.,
the

peak
minus
the
minimum
performance
for
each
workload
increased.

However,

most
of
this
range
difference
was
attributable
to
the
higher
performance
of
each

workload.

©
2012
Silverton
Consulting,
Inc.
Page
13


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Summary

Figure
9
Overall
capacity
requirements

In
conclusion,
the
storage
capacity
savings
gained
from
NetApp’s
thin
provisioning,

data
deduplication
and
data
compression
were
truly
remarkable.

As
shown
in

Figure
9,
thin
provisioning
alone
provided
a
sizable
46
percent
capacity
savings.

…
when
all
tested
features
were
activated,
the
size
of
the

original
storage
was
reduced
by
an

impressive
79
percent

But
enabling
data
deduplication
provided
even
more
overall,
a
68
percent
savings
as

compared
to
baseline
capacity
used.

Data
compression
added
still
more,
such
that

when
all
tested
features
were
activated,
the
size
of
the
original
storage
was
reduced

by
an
impressive
79
percent.

©
2012
Silverton
Consulting,
Inc.
Page
14


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Figure
10
Capacity
savings
for
data
copy
facilities
chart

In
comparison,
NetApp
Snapshot
and
FlexClone
copies
did
not
have
any
impact
on

capacity
requirements
for
source
data.

As
both
are
only
point-‐in-‐time
copies,
their

post-‐workload
capacity
was
compared
simply
with
the
baseline
capacity
in
the

above
chart.
Thus,
as
seen
in
Figure
10,
both
facilities
provided
impressive
point-‐in-‐
time
copies
greater
than
95
and
78
percent
smaller
for
Snapshot
and
FlexClone

copies
respectively
than
baseline
data.

©
2012
Silverton
Consulting,
Inc.
Page
15


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Figure
11
Baseline
vs.
all
tested
features
performance
comparison
chart

Besides
the
tremendous
capacity
savings
achieved
using
thin
provisioning,

deduplication
and
compression,
enabling
these
storage
efficiencies
had
no
negative

impact
on
the
overall
performance
of
the
NetApp
storage
system.

Moreover,
when

comparing
overall
median
performance,
NetApp’s
operational
throughput
also

exhibited
no
negative
impact.

The
ultimate
decision
to
use
any
or
all
of
vendor’s
storage
capacity
saving
features

or
their
point-‐in-‐time
copy
capabilities
can
be
a
complex
decision
and
often
involves

a
tradeoff
with
performance.

However,
NetApp
thin
provisioning,
data

deduplication
and
compression
can
potentially
provide
overwhelming
storage

capacity
savings
with
little,
if
any,
overall
performance
degradation
and
thus,

deserve
strong
consideration
for
any
data
center
environment.

Silverton Consulting, Inc. is a Storage, Strategy & Systems consulting
services company, based in the USA offering products and services to
the data storage community.

©
2012
Silverton
Consulting,
Inc.
Page
16


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Appendix
1
SCI
Lab
resources
and
workload
details

SCI’s
lab
uses
enterprise-‐class
server
and
networking
resources
to
support

hardware
and
software
validation
activities
including:

• One
Westmere
class,
dual
processor,
six-‐core
server
with
144GB
of
memory

and
an
SSD
for
internal
storage

• One
Nehalem
class,
dual
processor,
quad-‐core
server,
with
48GB
of
memory

and
an
SSD
for
internal
storage

• One
SandyBridge
class,
single
processor,
quad-‐core
server,
with
32GB

DRAM
and
an
SSD
for
internal
storage

• Six
Xeon
class,
dual
processor,
quad
core
servers
with
five
having
48GB
of

DRAM,
using
internal
SAS
drives
for
local
storage

• Three
FC
SAN
switched
fabrics
supporting
2GFC,
4GFC,
and
8GFC,
and

• Two
Ethernet
fabrics
supporting
both
1GigE
as
well
as
10GbE,
providing

FCoE,
iSCSI
and
normal
LAN
traffic.

Although
all
the
above
were
available
for
testing,
the
Nehalem
class
server
running

VMware
with
3
virtual
machines
(VMs)
each
having
16GB
of
DRAM
was
utilized
for

this
test.

All
the
data
was
accessed
over
10Gb/sec
Ethernet
(10GbE)
interfaces.

The

server
had
two
standard
Intel
10GbE
XF
SR
NICs
teamed
together
used
for
iSCSI
and

a
single
Emulex
11101
NIC
used
for
CIFS
traffic.

No
attempts
were
made
to
optimize

system
or
storage
performance
but
rather
to
establish
a
baseline
level
of

performance
for
comparison
purposes.

Workloads
used
to
measure
performance

To
measure
system
performance,
a
typical
workload
was
generated
against
the

previously
acquired
data
using
the
SCI
lab
server.

One
VM
was
dedicated
to
each

workload
as
follows:

• File
system
workload:
A
CIFS
file
share
was
created
and
accessed
by
one

VM.

Then,
a
simulated
file
workload
was
constructed
which
wrote
and
read

data
concurrently
using
an
automated
copy
script.

• SQL
DB
workload:
A
SQL
Server
was
configured
and
a
simulated
workload

was
created
consisting
of
changing
and
modifying
column
values
in
the

relational
tables.

• Email
workload:
Microsoft’s
Exchange
2010
Jetstress
tool
was
run
for
1150

mailboxes
producing
~0.18
I/O
per
mailbox
per
second,
i.e.
a
normal
email

workload.

Data
used
in
test

Test
data
was
taken
from
a
number
of
sources
including
publicly
available
email

data,
internal
file
data
from
SCI’s
lab
and
office
environment
and
text/image/PDF

data
obtained
from
the
web.

Specifically,

©
2012
Silverton
Consulting,
Inc.
Page
17


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

• File
system:
~211GB
consisting
of
48%
email
data
(.pst
files/email
data),

21%
Perfmon
data,
15%
text,
7%
image
data,
5%
Office/PDF
data,
and
4%

DB/SQL
data.

• SQL
database
(DB)
data:
~474GB
of
data
spread
across
18
tables
containing

text
and
web
server
log
data.

• Email
data:
~414GB
of
email
with
88MB
of
log
data
created
by
the

Microsoft
Jetstress
tool.

The
testing
used
a
variety
of
data
types
to
simulate
the
diversity
of
data
found
in

many
customer
environments
and
to
reduce
the
potential
for
non-‐standard
results

based
on
“artificial”
data.
However,
the
testing
is
not
intended
to
represent
best

practice
guidelines
for
any
specific
application
or
environment.

Readers
are

encouraged
to
consult
NetApp
documentation
and
personnel
directly
for
the
best

practice
recommendations
for
their
specific
application
requirements.

Additionally,
the
performance
testing
was
designed
to
measure
before
and
after

results
to
assess
any
potential
impact
of
implementing
multiple
storage
efficiency

and
copy
technologies.
These
results
are
not
intended
to
be
used
for
performance

sizing
and
do
not
reflect
possible
throughput
results
outside
of
the
specific
test

environment.
Readers
are
encouraged
to
consult
NetApp
documentation
and

personnel
directly
for
performance
recommendations
for
their
specific

requirements.

©
2012
Silverton
Consulting,
Inc.
Page
18


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Appendix
2
NetApp
CLI
commands
used
and
results
summary

Feature Commands to enable Commands to measure Savings
savings
Baseline df –k
Thin lun set reservation path disable; df –k; Moderate
provisioning vol options volname df -A
guarantee=none
Data sis on path; df –k; Moderate
deduplication sis start –S path; df –S

Data sis config –C TRUE path; df –k; Moderate
compression sis start –S -C path; df –S

Snapshot snap create volname df –k; Outstanding3
snapvolname snap list
FlexClone Vol clone create clonename –s df –k; Significant4
volume volname vol clone split estimate
clonename;
snap list;
All features (As indicated above) (As indicated above) Substantial
Table
1
Command
and
results
summary
table

3
For
original
source
data
there
were
no
savings
but
for
snapshot
copies
there
were

outstanding
savings

4
For
original
source
data
there
were
no
savings
but
for
FlexClones
there
were

significant
savings

©
2012
Silverton
Consulting,
Inc.
Page
19


All
Rights
Reserved


SCI
Lab
Validation
Report:
NetApp
Storage
Efficiency

Appendix
3
Summary
of
Capacity
Test
Results

Cumulative
Storage
Efficiency
Test
Results
(GB)

Test
Step
1
Test
Step
2
Test
Step
3
Test
Step
4

Net
After
Thin

Net
After
Thin

Post-‐workload

Net
After
Thin
Provisioning,

Provisioning
&

Baseline

Provisioning
Deduplication
&

Deduplication

Compression

File
System
Storage
629.15
211.72
118.27
106.12

SQL
DB
Storage
629.15
473.60
452.42
229.20

SQL
Log
Storage
104.86
1.20
0.02
0.02

Email
DB
Storage
629.15
414.03
87.04
87.03

Email
Log
Storage
41.94
0.09
0.00
0.00

Total
Capacity
2,034.24
1,100.64
657.76
422.37

Table
2
Cumulative
storage
efficiency
test
results

Copy
Services
Test
Results
(GB)

Test
Step
1
Test
Step
5
Test
Step
6

Post-‐workload

Net
After

Net
After

Baseline

Snapshot
Copy
FlexClone
Copy

File
System
Storage
629.15
6.81
66.63

SQL
DB
Storage
629.15
90.07
200.87

SQL
Log
Storage
104.86
0.01
65.15

Email
DB
Storage
629.15
7.48
115.80

Email
Log
Storage
41.94
0.00
0.35

Total
Capacity
2,034.24
104.37
448.80

Table
3
Copy
services
test
results

©
2012
Silverton
Consulting,
Inc.
Page
20


All
Rights
Reserved


SCI Lab Test Validation Report: NetApp Storage Efficiency

More Related Content

Viewers also liked (10)

Similar to SCI Lab Test Validation Report: NetApp Storage Efficiency (20)

More from NetApp (20)

Recently uploaded (20)

SCI Lab Test Validation Report: NetApp Storage Efficiency