Showing posts with label throughput. Show all posts
Showing posts with label throughput. Show all posts

Tuesday, September 13, 2011

FlashCache Pros and Cons

Ran across a brilliant article over at The Missing Shade of Blue that brought up something I'd never considered: latency is the real way to measure speed.  Throughput is a vital statistic to be sure, but if your throughput comes at the cost of latency you really have to consider that trade off.

Bit of background for noobs: obviously, fast data storage is more expensive than slow data storage.  Data tiering is pretty much the same idea as storing things in your closet: the stuff you use more often are in the front (fast, expensive storage like Flash memory), the stuff you never take out can be hidden deep in the back (slow, cheap storage like SATA).

Some companies, like Compellant, run algorithms to see what data is being read/written to infrequently and move that data to SATA, while the frequently-used data is moved to your faster SAS drives.  NetApp (and EMC after they saw the success NetApp achieved) short circuit this a bit by just adding a single, super-fast tier of cache.

NetApp FlashCache is 512GB of super-fast flash memory. EMC FAST Cache are actually SSD's. Frequently accessed data is kept here so that the system doesn't have to go all the way to the drives, which increases the amount of data packets per second (IOPS) you are able to write or read.

The point that really struck me is that some Cache products, which create a super high tier for your data, can kill you on write latency.  It turns out that EMC FAST Cache either increases write latency because of how it's implemented or opens the spigot for max IOPS so wide that the rest of the system can't keep up, exposing other bottlenecks.  I'm sure that at some point if you throttle down the IOPS you'll see the write latency settle down.  You'll still get a marked increase in IOPS, without the write latency.

This doesn't by any means settle that Cache products have no place in your SAN (it's still a fantastic performance boost for the money), but it does mean you have to factor in this effect when making the decision.  

Tuesday, May 24, 2011

NetApp Training Brain Dump: SnapMirror/SyncMirror (Data Replication)

In project planning, it's well known that there are three competing constraints: time, money, and scope.  You constantly negotiate with stakeholders to squeeze as much as you can out of each, but in the end you're dealing with a reality that most of your job is navigating those constraints.  Engineers are extremely familiar with this reality, even if they've never heard of the Triple Constraint Triangle:
Credit: Wikipedia
SnapMirror is Netapp's software that handles data replication from one system to another, giving you another copy of your information.  This can be done for DR, for backup, to provide quick access, to spread out CPU utilization, to minimize traffic across distances, or for any number of reasons.  Businesses find this service invaluable, and the data replication industry is expected to grow from $2.7B in 2007 to $4.4B in 2011.  SnapMirror comes in synchronous, semi-synchronous (CP Forwarding), and asynchronous modes.

SyncMirror vs Sync Snapmirror: there are a couple important distinctions here.  For one, SyncMirror is only used as the replication between two FAS systems in a MetroCluster.  Also, SyncMirror works at the aggregate level, whereas Sync Snapmirror operates with volumes and qtrees.

In data replication, a big advantage of SnapMirror is NetApp's implementation of network compression (only available in async mode), which allows you to speed up the transfer while reducing bandwidth utilization by compressing the data before transmission on the source side and decompressing it before write on the destination.  In this, you find another constraint triangle: bandwidth utilization, speed of transfer of compressed data, and CPU utilization.  In order to compress data that is being transferred at high rates, the CPU has to increase the number of calculation operations per Gb transferred.  If you keep transfer rate low and steady, the CPU utilization will stay correspondingly low.

Credit: Me!
(Please note that this graph demonstrates a
relationship, and is not accurate to actual system
statistics)
Obviously, you want to keep transfer rate high as possible but the other two as low as possible.  The effect of this is for every increase in transfer rate, there is either a corresponding increase in CPU or bandwidth utilization, or both.

Quick hits:
  • SnapMirror can replicate at the volume and qtree level.
  • Consider using a WAN compression device (e.g. RiverBed SteelHead) instead of SnapMirror to compress ALL SAN traffic (don't use both).  SnapMirror compression obviously just compresses SnapMirror traffic.  WAN compression devices handle latency/packet loss more efficiently, as well.
  • NetApp advertises compression rates of 3.5:1 for Oracle, 2.7:1 for home directory, and 1.5:1 for Exchange.  YMMV.
  • Checkpoints are once per 5 minutes.  If the transfer is aborted/interrupted, it will begin replication again at the last checkpoint.
  • In sync mode, writes to the source NVRAM are immediately transferred to the dest NVRAM.  This is called NVLOG forwarding.  After a 25s NVLOG Forwading timeout, the process is relegated to semi-sync status.
  • Consistency Points are when the contents of NVRAM are flushed to the local disk, which occurs  in certain situations, e.g. the NVRAM of the source is half full.  CP's are also generated every 10s.  These cache dumps are forwarded to the dest: a 1 min timeout in this process will relegate the replication to async status.
  • You can obviously transition back into sync from async.
  • Initial SnapMirror replication is very disk and CPU intensive, partially due to the amount of data, partially due to background processes like deswizzling.  Subsequent mirroring of the same data has a drastically lower impact.
  • Considerations for sizing of volumes are important.  Flexclones/snapshots introduce complications for this process.
  • Things you need to be careful of:
    • Changing source/dest volume names
    • Changing source/dest volume sizes
    • Change hostnames
    • Changing ONTAP versions
    • Deleting/creating luns/snapshots/etc on either side
    Sources:
    Async: http://www.netapp.com/us/library/technical-reports/tr-3446.html
    Sync and Semi: http://media.netapp.com/documents/tr-3326.pdf