The Storage Architect » DMX

Choosing Between Monolithic and Modular Architectures – Part I

Chris M Evans — Tue, 24 Aug 2010 18:19:32 +0000

The recent proposed acquisition of 3Par by Dell and/or HP has made me think a little more about the direction the storage industry is taking in terms of their storage array design architecture. Since storage arrays became a category of devices in their own right, we’ve seen the growth of the monolithic, sometimes called Enterprise storage array. Hu Yoshida discusses the subject on one of his recent blog posts. Looking at the wide range of storage devices, I’ve categorised arrays into the following groups:

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.

Enterprise Computing: Netapp The $4Billion Product

Chris M Evans — Mon, 22 Feb 2010 15:54:23 +0000

I had a conversation last week with a PR company doing research for Netapp. This followed just after Netapp released their Q4 results, with revenue exceeding expectations at just over $1 billion. It’s amazing how in the space of less than 20 years they have developed from nothing to a company selling a single $4 billon product.

Lots of people will be quick to point out to me that Netapp sell lots of products. Well, yes they do and the majority of those relate to a single core product – Data ONTAP running on some kind of bespoke hardware. There are a few other bits and pieces out there – DataFort and SANScreen for example, but most software and hardware products still revolve around the core function of providing Networked Attached Storage.

Two thoughts intrigue me:

Despite Netapp’s “reputation”, people still continue to buy from them. By “reputation” I mean, complexity and price – I won’t even mention the sales culture.
Competition in the sector must surely mean that growth in the single NAS product can’t continue forever, when newer products that have been developed with the benefit of hindsight are available in the marketplace and those vendors become more established.

It’s the second of these points that probably concerns me most. Data ONTAP has some technical issues in performance and scalability. The time taken to develop Data ONTAP 8 has demonstrated that integrating new features into the existing code base is a time consuming and presumably expensive exercise. Netapp have no other product line to rely on and aren’t introducing new hardware/software as successors to the existing product line.

Compare Netapp to other vendors, specifically their arch-nemesis EMC. EMC have fundamentally re-invented storage array technology with the introduction of V-Max. Over the years they invested in technology other than their main Symmetrix range; CLARiiON, Centera, Celerra, Iomega, RecoverPoint are only a few that spring to mind. There are many more. The software portfolio of technology unrelated to Symmetrix is even greater. Netapp remain fixed on their core product platform and the Data ONTAP architecture, attempting to make one hardware device fit all flavours of storage.

Despite the apparent flaws in Netapp’s technology, customers continue to buy and that is reflected in continued growth. But surely it’s just a matter of time before their market share begins to erode. Perhaps rather than acquiring technology that further expands features of their current platform (like Data Domain) they should branch out and buy into technology in other areas by acquiring 3Par, Compellent or Pillar perhaps. Of course the only problem with following this direction is that it admits defeat in using the existing Data ONTAP platform as an all-protocol encompassing storage platform. When you’ve spend years criticising the competition, you’ve pretty much painted yourself into a corner that becomes very difficult to get out of.

Enterprise Computing: Is There Any Point Buying From EMC?

Chris M Evans — Wed, 09 Dec 2009 19:02:05 +0000

Yesterday, EMC announced Fully Automated Storage Tiering (FAST), their much hyped and much anticipated storage feature enabling the automated moving of data between tiers of storage on a policy basis. However the most notable missing feature in the EMC announcement was the lack of support for legacy DMX-3 and DMX-4 platforms. This to me sends a message loud and clear that despite continuing to sell it, the DMX3/4 legacy monolithic hardware is dead. If that’s the case, why bother buying from EMC any more?

Discounting EMC in the storage array market may seem like a naive and perhaps foolish comment to make. After all, recent IDC numbers show EMC top of the pile at nearly a quarter of all external storage arrays sold, depending on which figure you choose to use. However, take a moment to look at the EMC briefing pages on FAST (you can find them here). There you will see Intel co-branded with EMC, highlighting many previous messages that monolithic architectures are dead and commodity modular boxes are the way of the future. We’ve seen that this year already with the release of Atmos.

To my knowledge, FAST is the first “innovation” of the new V-Max product line, but it isn’t unique. In fact, I don’t think any features of V-Max are unique; the architecture is found in many other products. There’s a whole raft of mid-range storage arrays from IBM (XIV), 3Par, Compellent, Pillar, Dell/Equallogic and HP (Lefthand) with the last two being acquisitions of successful companies. I expect in the next 12 months we’ll see enterprise modular releases from Hitachi/HP and a revamped EVA. Most of the products mentioned here have been designed from scratch to remove the legacy encumberances of the past that products such as V-Max still retain.

So what’s my point? Well, simply this; EMC have legitimised the enterprise modular architecture characterised by V-Max. This accepts that the future is commodity-based hardware with differentiation in software. However, EMC are no longer the leaders in this field and are having to play catch up.

There’s never been a better time to look wider than the Big 4 (EMC/Hitachi/HP/IBM) and see if the features you need can be found elsewhere.

Enterprise Computing: Why Thin Provisioning Is Not The Holy Grail for Utilisation

Chris M Evans — Thu, 04 Jun 2009 11:02:10 +0000

Thin Provisioning (Dynamic Provisioning, Virtual Provisioning, or whatever you prefer to call it) is being heavily touted as a method of reducing storage costs. Whilst at the outset it seems to provide some significant storage savings, it isn’t the answer for all our storage ills.

What is it?

Thin Provisioning (TP) is a way of reducing storage allocations by virtualising the storage LUN. Only the sectors of the LUN which have been written to are actually placed on physical disk. This has the benefit of reducing wastage, in instances where more storage is provisioned to a host than is actually needed. Look a the following figure. It shows five typical 10GB LUNs, allocated from an array. In a “normal” storage configuration, those LUNs would be allocated to a host and configured with a file system. Invariably, the file systems will never be run at 100% utilisation (just try it!) as this doesn’t work operationally and also because users typically order more storage than they actually require, for a many reasons. Typically, host volumes can be anywhere from 30-50% utilised and in an environment where the entire LUN is reserved out for the host, this results in a 50-70% wastage.

Now, contrast this to a Thin Provisioned model. Instead of dedicating the physical LUNs to a host, they now form a storage pool; only the data which has actually been written is stored onto disk. This has two benefits; either the storage pool can be allocated smaller than the theoretical capacity of the now virtual LUNs, or more LUNs can be created from the same size storage pool. Either way, the physical storage can be used much more efficiently and with much less waste.

There are some obvious negatives to the TP model. It is possible to over-provision LUNs and as data is written to them, exhaust the shared storage pool. This is Not A Good Thing and clearly requires additional management techniques to ensure this scenario doesn’t happen and sensible standards for layout and design to ensure a rogue host writing lots of data can’t impact other storage users.

The next problem with TP in this representation is the apparent concentration of risk and performance of many virtual LUNs to a smaller number of physical devices. In my example, the five LUNs have been stored on only three physical LUNs. This may represent a potential performance bottleneck and consequently vendors have catered for this in their implementations of TP. Rather than there being large chunks of storage provided from fixed volumes, TP is implemented using smaller blocks (or chunks) which are distributed across all disks in the pool. The third image visualises this method of allocation.

So each vendor’s implementation of TP uses a different block size. HDS use 42MB on the USP, EMC use 768KB on DMX, IBM allow a variable size from 32KB to 256KB on the SVC and 3Par use blocks of just 16KB. The reasons for this are many and varied and for legacy hardware are a reflection of the underlying hardware architecture.

Unfortunately, the file systems that are created on thin provisioned LUNs typically don’t have a matching block size structure. Windows NTFS for example, will use a maximum block size of only 4KB for large disks unless explicitly overriden by the user. The mismatch between the TP block size and the file system block size causes a major problem as data is created, amended and deleted over time on these systems. To understand why, we need to examine how file systems are created on disk.

The fourth graphic shows a snapshot from one of the logical drives in my desktop PC. This volume hasn’t been defragmented for nearly 6 months and consequently many of the files are fragmented and not stored on disk in contiguous blocks. Fragmentation is seen as a problem for physical disks as the head needs to move about frequently to retrieve fragmented files and that adds a delay to the read and write times to and from the device. In a SAN environment, fragmentation is less of an issue as the data is typically read and written through cache, negating most of the physical issues of moving disk heads. However fragmentation and thin provisioning don’t get along very well and here’s why.

The Problem of Fragmentation and TP

When files are first created on disk, they will occupy contiguous sections of space. If this data resides on TP LUNs, then a new block will be assigned to a virtual TP LUN as soon as a single filesystem block is created. For a Windows system using 4KB blocks on USP storage, this means 42MB each time. This isn’t a problem as the file continues to be expanded, however it is unlikely this file will end neatly on a 42MB boundary. As more files are created and deleted, each 42MB block will become partially populated with 4KB filesystem blocks, leaving “holes” in the filesystem which represent unused storage. Over time, a TP LUN will experience storage utilisation “creep” as new blocks are “touched” and therefore written onto physical disk. Even if data is deleted from an entire 42MB chunk, it won’t be released by the array as data is usually ”logically deleted” by the operating system. De-fragmenting a volume makes the utilisation creep issue worse; it writes to unused space in order to consolidate files. Once written, these new areas of physical disk space are never reclaimed.

So what’s the solution?

Fixing the TP Problem

Making TP useful requires a feature that is already available in the USP arrays as Zero Page Reclaim and 3Par arrays as Thin Built In. When an entire “empty” TP chunk is detected, it is automatically released by the system (in HDS’s case at the touch of a button). So, for example as fat LUNs are migrated to thin LUNs, unused space can be released.

This feature doesn’t help however with traditional file systems that don’t overwrite deleted data with binary zeros. I’d suggest two possibilities to cure this problem:

Secure Defrag. As defragmentation products re-allocate blocks, they should write binary zeros to the released space. Although this is time consuming, it would ensure deleted space could be reclaimed by the array.
Freespace Consolidation. File system free space is usually tracked by maintaining a chain of freespace blocks. Some defragmentation tools can consolidate this chain. It would be an easy fix to simply write binary zeros over each block as it is consolidated up.

One alternative solution from Symantec is to use their Volume Manager software, which is now “Thin Aware”. I’m slightly skeptical about this as a solution as it places requirements on the operating system to deploy software or patches just to make storage operate efficiently. It takes me back to Iceberg and IXFP….

Summary

So in summary, Thin Provisioning can be a Good Thing, however over time, it will lose its shine. We need fixes that allow deleted blocks of data to be consolidated and returned to the storage array for re-use. Then TP will deliver on what it promises.

Footnote

Incidentally, I’m surprised HDS haven’t made more noise about Zero Page Reclaim. It’s a TP feature that to my knowledge EMC haven’t got on DMX or V-Max.

EMC World 2009: Day 1 – Is DMX The Last Monolithic Array?

Chris M Evans — Mon, 18 May 2009 20:51:29 +0000

As I sit here at the start of EMC World Day 1, I’m pondering over some of the conversations of last night. The direction EMC are taking with V-Max, the Atmos product and Clariion makes me wonder if DMX could be classed as the last of the (EMC) monolithic storage arrays.

So, here’s the thinking. DMX arrays started to use the DAE (Disk Array Enclosure), previously deployed on Clariion. Atmos uses this as well. So effectively these three devices all use a common disk shelf technology. With the release of V-Max, EMC have moved away from the monolithic design of DMX and to a more modular, node-based controller architecture using Intel processors. So other than software, doesn’t that make all three storage arrays effectively the same product?

It’s About The Software Stupid

Perhaps EMC are making good on their promise of being a software company. Make the hardware a commodity and put all the investment into the software. After all, there’s no margin in hardware any more, or so we’re told.

Here’s another thing to ponder. If V-Max is going to be node-based, do all of those nodes have to be running Enginuity? How easy would it be to flip some of them into Atmos mode, Clariion mode, or even turn them into a virtual tape library? Perhaps you wouldn’t do that within a local cluster, but the option is there (and the intention from what EMC are implying) to move to geographically dispersed clusters.

With the V-Max architecture, all of a sudden the opportunities open up.

Betamax

Chris M Evans — Thu, 04 Dec 2008 21:13:00 +0000

In case you don’t always go back and look at comments (and let’s face it, it’s not easy to track them), then have a look at Tony’s comment from my post yesterday. It’s good to see a bit of banter going on and that’s what HDS could do with.

HDS have hardly developed a good blogging prowess, it’s more a case of “oh well, better do that” than taking a lead in new media.

Look at EMC.

There’s geeky leaky Storagezilla with his uber-technical posts and sneaky advance notice of EMC technology.

Next The Storage Anarchist with his ascerbic character and product assassinations of the competition.

And who can forget Chuck, EMC’s futurologist with his head in the cloud.

There’s others of course, filling in the technical detail. Apologies if I haven’t mentioned you by name. EMC have certainly grabbed Web 2.0 and given it a good shake.

Sadly HDS don’t seem to have the same enthusiasm for marketing to their customers. Blog posts are few and far between from the small slew of bloggers they have to date. Content is shallow and that’s a big problem.

We *all* know USP is faster than DMX. Anyone who’s had the products in their lab know exactly what I’m talking about. Unfortunately unless HDS make a song and dance about it, they’re going to be the Betamax of the Enterprise storage world.

Tony, keep the posts coming! Give is some real substance to beat up the competition with!!

SPC

Chris M Evans — Wed, 03 Oct 2007 05:24:00 +0000

According to Wikipedia, lightning can travel at a speed of 100,000 MPH, however I think storage vendors are even faster than lightning when it comes to highlighting or dissing the competition.

Mere microseconds after reading Claus Mikkelsen’s blog on the USP-V SPC figures, there are posts from BarryW and BarryB, doing the highlighting and dissing respectively (I almost wrote respectfully there; that would have been a funny typo). BarryB must have no real work to do other than to write his blog, looking at the size of the posts he does!

Anyway. I’m not going to comment on the results because the others have done that enough already and I don’t think the details are that relevant. I think what’s more relevant is the stance EMC are taking in not providing figures for customers on the performance of their equipment. I can’t decide whether its a case of arrogance and therefore a feeling they don’t need to provide details because as BarryB says, the customer will buy anyway, or is it because the DMX will not match up to the performance of its competitors. I think it is a mixture of both.

EMC aren’t an array vendor any more and haven’t been for a long time. OK, it is the product they’re most remembered for historically, but their reach is now so wide and deep I think Symmetrix isn’t the focus of a lot of their attentions. If it was, DMX4 would not just scale by the GB, it would have more connectivity, more cache and EMC would have been the *leader* in the implementation of technology like thin provisioning, not the also ran.

On reflection, I think EMC should provide SPC figures. If DMX is better than the others and is “Simply the Best” prove it; bragging starts to sound hollow after a while.

DMX-4 Green or not?

Chris M Evans — Fri, 20 Jul 2007 21:28:00 +0000

After the recent EMC announcements on DMX-4, I promised I would look at the question of whether the new DMX-4 is really as green as it claims to be. I did some research and the results are quite interesting.

Firstly we need to set the boundaries. One of the hardest part of comparing hardware from different manufacturers is that they are intrinsically different (if they were too similar, the lawyers would be involved) and that makes it difficult to come up with a fair comparison. So, I’ve divided the comparisons into controller and disk array cabinets. Even this is difficult. The DMX has a central controller cabinet which contains only batteries, power supplies, interface boards and so on. The USP however uses half of the central controller for disks. The DMX has 240 drives per cabinet, however the USP has 256 disks per cabinet. This all needs to be taken into consideration when performing calculations.

Second, I want to explain my sources. I’ve tried to avoid the marketing figures for two reasons; firstly they usually refer to a fully configured system and secondly they don’t provide enough detail in order to break down power usage by cabinet and by component. This level of detail is necessary for a more exact comparison. So, for the USP and USP-V, I’m using HDS’s own power calculation spreadsheet. This is quite detailed, and allows each component in a configuration to be specified in the power calculation. For EMC, I’m using the DMX-3 Physical Planning Guide. I can’t find a DMX-4 Planning Guide yet, however the figures on the EMC website for DMX-4 are almost identical to those for DMX-3 and it’s as close as I can get.

DMX-3/4

The DMX figures are quite simple; the controller cabinet (fully loaded) takes 6.4KVA and a disk cabinet 6.1KVA. A fully configured controller cabinet has 24 controller slots, up to 8 global memory directors and 16 back and front-end director (FED) cards. A typical configuration would have eight 8-port FED cards and 8 BED cards connecting to all 4 disk quadrants. EMC quote the disk cabinet figures based on 10K drives. Looking at Seagate’s website and standard 10K 300GB FC drives, each requires 18W of power in “normal” operation, so 240 drives requires 4.32KVA. The difference between this figure and the EMC value will cover when drives are being driven harder and the power supplies and other components which need powering within a disk cabinet. We can therefore work on an assumption of 25.4W per drive on average.

Now the figures for the controller cabinet are interesting. Remember EMC have no drives in the controller cabinet so all the power is for controllers, charging batteries and cache. So all that 6.4KVA is dedicated to keeping the box running.

USP

The HDS power calculator spreadsheet is quite detailed. It allows specific details of cache, BEDS, FEDs and a mix of 73/144/300GB array groups. A full USP1100 configuration has 1152 drives, 6 FEDs, 4 BEDs and 256GB of cache. This full configuration draws 38.93KVA (slightly more than the quoted figure on the HDS website. Dropping off 64 array groups (an array cabinet) reduces the power requirement to 31.50 KVA or 7.43KVA for the whole cabinet. This means the controller cabinet draws 9.21KVA and in fact the spreadsheet shows that a full configuration minus disks draws 5.4KVA. The controller cabinet has up to 128 drives in it, which should translate to about 3.7KVA; this is consistent with the 9.21KVA drawn by a full controller cabinet. The 7.43KVA in a cabinet translates to 29W per drive, making the HDS “per drive” cost more expensive.

This is a lot of data, probably not well presented but it shows a number of things;

There’s an inescapable power draw per drive which can’t be avoided; this equates to about 20W per drive.
The controller frame needs about 6KVA and this varies only slightly depending on the number of controllers and cache.
The HDS controller is slightly more efficient than the EMC.
The HDS disk array is slightly less efficient than the EMC.

Neither vendor can really claim their product to be “green”. EMC are playing the green card by using their higher density drives. There’s no doubting that this does compute to a better capacity to power ratio, however these green power savings come at a cost; SATA drives are not fibre channel and not designed for 24/7 workloads. Whilst these drives provide increased capacity, they don’t provide the same level of performance and DMX systems are priced at a premium so you want to get the best bang for your buck. However, if EMC were to price a SATA-based DMX competitively, then the model is compelling, but surely that would take business away from Clariion. What’s more likely to happen is customers choosing to put some SATA drives into an array and therefore see only modest incremental power savings.

So what’s the future? Well, 2.5″ drives currently offer up to 146GB capacity at 10K and only half the power demands, which also translates into cooling savings. Is anyone using these in building arrays? Hybrid drives with more cache should allow drives to be spun down periodically, also saving power. Either way, these sorts of features shoudn’t come at the cost of the levels of performance and availability we see today.

One final note of interest…HDS are quoting figures for the USP-V. These show a 10% saving over the standard USP, despite the performance improvements…

What’s your favorite fruit? EMC versus HDS

Chris M Evans — Wed, 25 Apr 2007 20:45:00 +0000

Nigel has posted the age old question, which is best EMC or HDS? For those who watch Harry Hill - there’s only one way to sort it out – fiiiiight!

But seriously, I have been working with both EMC and HDS for the last 6 years on large scale deployments and you can bet I have my opinion – Nigel, more opinion than I can put on a comment on your site, so forgive me for hijacking your post.

Firstly, the USP and DMX have fundamentally the same architecture. Front end adaptor ports and processors, centralised and replicated cache and disks on back-end directors. All components are connected to each other providing a “shared everything” configuration. Both arrays use hard disk drives from the same manufacturers which have similar performance characteristics. Both offer multiple drive types, the DMX3 including 500GB drives.

From a scalability perspective the (current) USP scales to more front-end ports but can’t scale to the capacity of the DMX3. Personally, I think the DMX3 scaling is irrelevant. Who in their right mind would put 2400 drives into a single array (especially with only 64 FC ports)? The USP offers 4GB FC ports, I’m not sure if DMX3 offers that too. The USP scales to 192 ports, the DMX3 only 64 (or 80 if you lose some back-end directors).

The way DMX3 and USP disks are laid out is different. The USP groups disks into array groups depending on the RAID type – for instance a 6+2 RAID group has 8 drives. It’s then up to you how you carve out the LUNs – they’re completely customisable to your choice of size. Although a configuration file can be loaded (like an EMC binfile) its usually never used and LUNs are user-created through a web interface to the USP SVP called Storage Navigator. LUN numbering is also user configured, so it’s possible to carve all LUNs consecutively from the same RAID group – not desirable if you assign LUNs sequentially and put them on the same host. EMC split physical drives into hypers. Hypers are then recombined to create LUNs – two hypers for a RAID1 LUN, 4 hypers for a RAID5 LUN. The hypers are selected from different (and usually opposing) back-end FC loops to provide resiliency and performance. It is possible for users to create LUNs on EMC arrays (using Solutions Enabler), but usually not done. Customers tend to get EMC to create new LUNs via a binfile change which replaces the mapping of LUNs with a new configuration. This can be a pain as it has to go though EMC validation and the configuration has to be locked for new configurations until EMC implement the binfile.

For me, the main difference is how features such as synchronous replication are managed. With EMC, each LUN has a personality even before it is assigned to a host or storage port. This may be a source LUN for SRDF (an R1) or a target LUN (an R2). Replication is defined from LUN to LUN, irrespective of how the LUNs are then assigned out. HDS on the other hand, only allow replication for LUNs to be established once they are presented on a storage port and the pairing is based on the position of the LUN on the port. This isn’t easy to manage and I think prone to error.

Now we come to software. EMC wipe the floor with HDS at this point. Solutions Enabler, the tool used to interact with the DMX is slick, simple to operate and (usually) works with a consistent syntax. The logic to ensure replication and point-in-time commands don’t conflict or lose data is very good and it takes a certain amount of effort to screw data up. Solutions Enabler is a CLI and so quick to install and a “lite” application. There’s a GUI version (SMC) and then the full blown ECC.

HDS’s software still leaves a lot to be desired. Tools such as Tuning Manager and Device Manager are still cumbersome. There is CLIEX, which provides some functionality via the command line, but none of it is as slick as EMC. Anyone who uses CCI (especially earlier versions) will know how fraught with danger using CCI commands can be.

For reliability, I can only comment on my experiences. I’ve found HDS marginally more reliable than EMC, but that’s not to say DMX isn’t reliable.

Overall, I’d choose HDS for hardware. I can configure it more easily, it scales better, and – as Hu mentions almost weekly, it supports virtualisation (more on that in a moment). If I was dependent on a complex replication configuration, then I’d choose EMC.

One feature I’ve not mentioned earlier is virtualisation. HDS USP and NSC55 offer the ability to present externally connected arrays and present them as HDS storage. There are lots of benefits for this – migration, cost saving etc. I don’t need to list them all. It’s true that virtualisation is a great feature but it is *not* free and you have to look at the cost benefit of using it – or beat your HDS salesman up to give you it for free. Another useful HDS feature is partitioning. An array can be partitioned to look like up to 32 separate arrays. Great if you want to segment cache, ports and array groups to isolate for performance or security.

There are lots of other things I could talk about but I think if I go on much further I will start rambling…

Where are all the simulators

Chris M Evans — Wed, 11 Apr 2007 20:47:00 +0000

I love the Netapp simulator (well, apart from the annoying issues with creating and deleting disks) and I use it all the time. It is great for testing ideas, testing scripting and generally refreshing knowledge on commands before having to touch real equipment. I use it with VMware (as I have probably mentioned before) and I can knock up a new environment in a few minutes by cloning an existing machine. Netapp have got a huge advantage in offering the tool as it enables customers who can’t or won’t put in test equipment to do work and protect their production environments.

So, where are all the other simulators? Is it just that I don’t know they exist or do most vendors not provide them? For the same reasons as I mentioned above, if there were simulators for EMC DMX, HDS USP, Cisco and Brocade/McDATA switches, then there would be a huge opportunity for people to test and develop scripts, test upgrades and other useful work.

Would anyone else like a simulator? Can the vendors tell me why they don’t produce them?