However, the VNX is still a CLARiiON at heart (with all the legacy baggage that entails), so one wonders what additional capabilites the VNX5500-F has to cope with this huge I/O workload and of course, to manage the finite lifetime of SSD devices.  More important is the ability to cope with the fickle performance of I/O spikes that are associated with SSD garbage collection.  There’s no mention of how (or even if) EMC have added technology to cater for these issues.  Bearing in mind what an all-flash array will cost, then 100% guaranteed low latency of every I/O will be expected.

The new market startups (Violin, Pure, SolidFire & others) will have to compete against EMC’s marketing machine but to be fair this is a technology that already offers a wide range of features, including connectivity via all the common protocols in use today.  EMC will be able to sell simply on feature, functionality and support.

The VNX5500-F may seem like putting a Rolls Royce engine in a mini compared to the competition, who are more like thoroughbred Ferraris and Lamborghinis, however as usual, cost will be the ultimate decider.  EMC don’t quote price, but simply indicate that cost per TPM is vastly reduced.  I’d like to see some real world list costs from EMC (which won’t happen) plus some statements on how this dedicated VNX deals with the particular issues of SSD drives.  If you are considering an all flash array, then these questions need to be on your list.

My answer was 47, which quite surprised me.  It’s comprised of:

• Drobo Devices; 5 + 4 + 3 = 12
• iX4 Devices; 4 + 4 = 8
• NS4600 Device; 3
• Backup HDD (SafePro); 1
• CLARiiON; 15
• Home Lab PCs; 2 + 2 + 3
• Desktop Mac; 1

That totals 47.  This didn’t include other home devices that weren’t powered up at the time.

Probably a more interesting question would be to ask how much useful data is on those devices; I suspect I have a lot of duplication; copies of the same O/S, backups of backups of data and duplicates of data I’ve not noticed.  With a glut of capacity, even in a home environment, it’s easy to become lazy when keeping data in order.  While it may seem pointless to waste time keeping data ordered, when a device fails, the critical issue becomes one of determining where the most current copy of information is stored.

If you’ve committed to using a home storage device, ask yourself the following;

• What happens if the storage device fails?
• What happens if one of the HDDs in the device fails?
• What happens if someone steals the device (home breakin)?
• What happens if I have fire at home?
• How long would it take me to copy my data to another device/location?

We’re becoming more dependent on home storage and the impact of failure of these devices will become more of a problem.  I’m sure there are many people who have lost precious photographs or video as most of this data is now digital.

Take some time and think about the value you have in your home storage device and I’m sure most people will see the value of spending a few more pounds and investing in an extra drive for backup.

• Monolithic – this architecture is characterised by Hitachi USP, HP XP & EMC DMX and consists of a shared memory architecture and multiple redundant components.
• Multi-Node – these devices use loosely coupled storage “nodes” with a high-speed interconnect providing scalability by adding extra nodes to the storage “cluster”.  Products in this category include EMC VMAX and 3Par InServ.
• Closely Coupled Dual Controller – this is the typical “modular” storage architecture characterised by IBM DS8000, EMC CLARiiON, Hitachi AMS and HP EVA.
• Loosely Coupled Dual Controller - this category describes technology that are capable of device failover but aren’t closely coupled to enable individual LUN failover as the Closely Coupled model permits.  This category is characterised by arrays such as Netapp FAS filers and Compellent Storage Center.
• Single Controller – this category covers devices that act as standalone products, including SOHO storage devices such as the Iomega IX4 & Data Robotics Drobo series.

The above list isn’t exhaustive and it’s my own personal categorisation.  There are many more vendors of technology than I’ve listed here.  In addition, none of these lists qualify as “Enterprise” in their own right.  The use of this term is a hotly debated subject.

Monolithic Architectures

EMC DMX High Level Architecture

Monolithic arrays use a shared cache architecture to connect front-end storage ports to back-end disk.  This is shown clearly in the architecture diagrams shown here, representing the internal connectivity of the EMC DMX  and Hitachi USP storage arrays.  Each of the memory units is connected to each of the front-end directors and the back-end disk directors.  Hitachi divide their cache into two halves for Clusters 1 & 2 in the array; EMC have up to eight cache modules.  This architecture has positive and negative benefits; firstly having director connections connecting to all cache modules ensures resources aren’t fragmented;  unless cache becomes completely exhausted there’s always connectivity to another cache module to process a user request.  It also doesn’t matter on which port that request comes in; the cache module can process any request from any port to any back-end disk.  This connectivity is also beneficial in terms of failure.  If a cache module fails, for example, only the cache on that module is lost; in a fully deployed architecture the total cache would drop (by 1/8th in EMC’s case), but front and back-end connectivity would remain the same.  With this model it is possible pair up storage ports and have a single LUN presented from 1 or more ports with no performance impact; the path length between a storage port and disk adaptor will always be the same.

This any-to-any model also has disadvantages.  The connectivity is complex and therefore becomes expensive and requires overhead to manage and control the interaction between the various components.  In addition, there’s a limit to the practical scalability of this architecture.  With eight FE, BE and cache modules, there are 128 connections in place; (8x8x2).  Adding a single cache module requires an additional 16 connections; similarly, adding more front or back-end directors requires more connectivity.  Also monolithic arrays are based on custom components and custom design, increasing the ongoing maintenance and development costs for the hardware.

One other point to remember; front and back-end directors have their own processors.  It is possible for the traffic across the directors to be unbalanced and for some processors to be more heavily utilised than others.  I’ve seen a number of configurations where USP V FED ports are running at 100% processor utilisation due to to small block sizes.  This means manual load balancing is required both in initial host placement and subsequently as traffic load increases.  This fact is worth bearing in mind as we move to more highly virtualised environments as it is likely host port utilisation will start low and rise over time as more virtual machines are created.

Hitachi USP High Level Architecture

Now that the DMX platform has been put out to pasture in place of VMAX, it appears Hitachi are the only vendor continuing down the monolithic route.  Next time I’ll discuss Multi-Node arrays and why they may (or may not) be a replacement for today’s monolithic devices.

520 Byte Sectors

It’s pretty well known that the CLARiiON array disks are low level formatted with a 520-byte sector size compared to the standard 512-bytes on most drives and on the disks you would install into your PC at home.  The additional 8 bytes are used for error checking and other additional information and are collectively known as DIBs – see Steve Todd’s informative post on the subject here.  This increased sector size effectively reduces the capacity of the drive by approximately 1.5%.

Low level formatting does, however offer another potential benefit; the drives don’t have to be reformatted to the original size specified by the manufacturer.  In fact, EMC choose standard sizes for each of their drive types, which are referenced by generic names, such as CLAR320, CLAR300 and so on.  The numeric part of the name represents the nominal size of the drive.  Having generic names enables EMC to substitute a range of drives from different manufacturers and so not be tied to taking disks from a single supplier.  It also means that the drives have been reformatted to a consistent capacity, usually lower than the manufacturer recommends – but not always.

Unlocking Free Space

Take for example the CLAR320 model.  This is typically a standard Maxtor ATA 320GB drive.  Navisphere commands indicate that these drives have a usable capacity of 304,169MB.  Based on the 520-byte sector, this represents an actual capacity of 308,922MB.  Now, a standard 320GB drive, which is quoted by the manufacturer as having decimal GB (1000x1000x1000) has a binary capacity (using 1K = 1024 bytes) of 305,176MB.  Magically the CLAR320 drive has an additional 3746MB or nearly 3.7GB of extra storage space!

Now compare to the CLAR300 drive.  A typical 300GB drive has a capacity of 286,106MB.  The CLARiiON model has a usable capacity of 274,845GB or taking into consideration the 520/512-byte blocks, 279,139MB.  This represents a shortfall of nearly 7GB on the capacity of the drive!

The obvious question is; how can there be more capacity on a drive than the manufacturer quotes?  Well, with the CLAR320 drives, that’s pretty easy to work out.  From the Seagate specification manual, the drive is configured with 2 platters and 4 heads, so 80GB per head (or recording surface).  In the same family, the 250GB model uses only 3 heads or 83.3GB per head.  Clearly the drives can achieve higher areal density and this is not fully utilised in the 320GB model.  Reformatting the drive at the low-level must unlock this reserve potential, resulting in a slightly higher capacity.

OK, in reality, although I said considerable, the potential capacity improvements aren’t huge and I’m not advocating that everyone go out and buy 320GB drives for their CLARiiONs.  However, what is interesting is how vendors will sell capacity of one size and the actual usable value can be less than you expect.  In this instance the difference between two similar drive capacities was 10GB.  Over thousands of drives, that can add up to a discrepancy which is difficult to explain to management.  At Storage Fusion, we’re working on ensuring we can help customers identify every scrap of their storage usage.

So, perhaps when you order that next EMC, HDS, IBM, HP array, you should ask exactly what the expected mileage will be…