There’s money in SAN complexity…and it’s YOURS!
Have you ever tried to decipher a SAN pricing proposal from one of the “big” guys? There are more part numbers than I would expect when building the space shuttle. It is not enough to have the basic hardware broken down into dozens of pieces but then you have to select a dizzying array of software licensing options for both the array and any hosts using array features.

Here’s a sample SKU list from a major NAS/SAN vendor for a simple storage array:

FAS6200HA-IB-BASE-1 GF-RAS56200HA,IB,1B CF,OS,R5 2
X70015A-ESH2-R5-C DS14MK2 SHLF, ACPS,14x144GB,15K,HDD 5
X6524-R6-C CBL, 2M, Optical, Pair, LC/C,-C,R6 2
X6530-R6-C CBL,0.5M,PATCH,FC SFPTO SFP-C,R6 6
X1941A-R6-C CBL,5M,CLUSTER4X,CU-C,R6 2
X871A-R6-C 20A Storace Equipment Cabinet,-C,R6 1
X875A-R6-C 20A PWR CORD (4),CABINET, NEMA-S,R6 1
X800-42U-R6-C Cabinet Component Power Cable, R6 14
X5517-R6-C Storage cabinet, Rail Set,42U,-C,R6 1
X6529-R6-C SFP, Optical, Pair, LC/LC, -6, R6 4
X8773-R6-C Multiple Product Tie-Down Bracket,- 2
DOC-3XXX-C Documents, 3XXX,-C 1
Software (Base Unit)
SW-T4C-CIFS-C CIFS CIFS Software, T4C-C 2
SW-T4C-ISCSI-C iSCSI iSCSI Software, T4C-C 2
SW-T4C-NFS-C NFS NFS Software, T4C-C 2
SW-T4C-SRESTORE-C SnapRestore Software,T4C,-C 2
SW-T4C-SME-C SnapManager Software, Exchange, T4C 2
SW-T4C-SMSVS-C SnapMirro-SnapVault Software Bndl, 2
Software (Host Side)
SW-SDR-WIN SnapDrive, Windows 10
SW-SSP-SDR-WINDOW SW Subs SnapDrive for Windows 3.0 10
SW-SMBR-1000PK Single Mbox Recovery, 1000pk 1
SW-SSPVN-SMBR-1000PKendor SW Sub SMBR, 1000pk 1
SW-SDR-SOL-TIER1 SnapDrive, Solaris, Tier 1 10
1-2CPU
SW-SSP-SDR-SOL-TIER1SW Subs, SDR Solaris Support, Tier 10
SW-SDU-CPU SW, SnapDrive UNIX, CPU 5
SW-SMO-CPU SW, SnapManager Oracle, CPU 5
SW-SSP-SMO-CPU SW, SUB, SnapManager Oracle 5
Services and Support
CS-S-INST Initial Installation-DS14 1
CS-A SupportEdge Standard-FAS270 Mths: 3 2

Wow!

All we wanted was a high-performing storage array. Instead, we got a dissertation on what the sales person thinks we need. Notice that this proposal contains base hardware, base software, host software, installation services and support. Although this would be considered a “simple” configuration, it is still complex and a potential customer would be hesitant to make any changes or delete any proposed features.

What’s worse is if the customer proceeds with this proposal thinking they have “covered all their bases” for the future. However, since many projects increase in complexity over time, new features may be needed but this a la carte model requires the customer to re-budget and purchase additional options in the future…more money.

Nimble Storage’s approach eliminates complexity

Compare this nightmare configuration with how Nimble Storage sells their arrays. Nimble Storage has a single part number for everything including every option. Here is an Nimble Storage configuration for a fault-tolerant (no single point of failure) 6TB system with SAS drives.

I like to call this the single most important business feature of Nimble Storage; all inclusive pricing. Everything you will need, now and in the future, is included at no additional charge. When you install the unit and fire up the GUI you will notice that there are no features “greyed out”. This is fantastic for projects that evolve because when you need a feature, say Offsite Replication, its available. Simply configure it!

Want to save money? Consider eliminating complexity.

Nimble Storage’s recipe for converging primary and backup storage is simple and has two parts.

1. Capacity optimization: Storing backups for 30–90 days needs lots of capacity. In a system not designed to store backups, they can easily use 10–20x the space used in primary storage. Nimble handles this problem as follows:

• Store all data on high-capacity disk drives. These disks have over 3x the capacity and 1/6x the cost per GB of high-performance disks. They also have only 1/3x the performance of high-performance disks, but we deal with that separately. (The high-capacity disks have often been called SATA disks, but that is quickly becoming a misnomer as high-capacity SAS drives enter the market.)
• Use data reduction techniques such as compression and block sharing. These techniques can reduce the space used by backups by 10–20x. Block sharing can take many forms, e.g., snapshots and dedupe, and it is important to pick judiciously based on the context. I will write further about this in the next article.

2. Performance optimization: Especially random IO performance. Common business applications such as Exchange and SQL Server generate lots of random IO. Hard disks are generally bad at random IO. High-capacity disks are particularly bad. We use two techniques that more than make up for this slowness:

• Accelerate random reads using flash as a large cache. Most storage vendors have a story around using flash. However, flash has some peculiar characteristics, and how a system uses flash is more important than whether it uses flash. In particular, flash is not a performance cure-all; e.g., it might not be cost effective in accelerating random writes.
• Accelerate random writes by sequentializing them on disk. This technology has been known for some time as log-structured file systems, but it has become more interesting recently because of new enabling technologies.