Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SCI Lab Test Validation Report: NetApp Storage Efficiency


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

SCI Lab Test Validation Report: NetApp Storage Efficiency

  1. 1.                    SCI Lab Test Validation Report:NetApp Storage Efficiency     Silverton Consulting, Inc.     StorInt™ Briefing           Written by: Ray Lucchesi Published: July 2012    
  2. 2.   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|   All  Rights  Reserved   +1-720-221-7270|
  3. 3.   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   +1-720-221-7270|
  4. 4.   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­‐exceptional-­‐data-­‐density.pdf     ©  2012  Silverton  Consulting,  Inc.   Page  3|   All  Rights  Reserved   +1-720-221-7270|
  5. 5.   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   +1-720-221-7270|
  6. 6.   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   +1-720-221-7270|
  7. 7.   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   +1-720-221-7270|
  8. 8.   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­‐3958.pdf     ©  2012  Silverton  Consulting,  Inc.   Page  7|   All  Rights  Reserved   +1-720-221-7270|
  9. 9.   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   +1-720-221-7270|
  10. 10.   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   +1-720-221-7270|
  11. 11.   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   +1-720-221-7270|
  12. 12.   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   +1-720-221-7270|
  13. 13.   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   +1-720-221-7270|
  14. 14.   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   +1-720-221-7270|
  15. 15.   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   +1-720-221-7270|
  16. 16.   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   +1-720-221-7270|
  17. 17.   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   +1-720-221-7270|
  18. 18.   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   +1-720-221-7270|
  19. 19.   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   +1-720-221-7270|
  20. 20.   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   +1-720-221-7270|
  21. 21.   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   +1-720-221-7270|