Here I am again on the start of another vendor blogging day.  As the title of this post suggests, this will be a trip to see Hitachi, or HDS (Hitachi Data Systems) if you prefer.  The Bloggers Day is taking place over two days and is located in San Jose, just south of San Francisco in California.  I’ve previously posted a list of the attendees, both from the blogging community and the Hitachi itself.

The IT world has changed since I first encountered Hitachi 7700E, 9900 and the recent USP/USP V ranges of Enterprise storage arrays that typify Hitachi’s hardware portfolio.  Enterprise and Modular storage now take equal billing and many of the features that were once Enterprise-only have migrated to the modular products, blurring the lines between the two platforms.  In addition Hitachi have offerings for NAS and object store.  They also sell servers (believe it or not).

Is this a scenario that has occurred because of customer demand?  Is it more likely that reliability and the virtualisation of everything means that the original premise of the enterprise array is no longer valid?  I believe that we are seeing a gradual move from the network-centric data centre, via the storage-centric data centre to what will become the hypervisor-centric data centre and eventually application-centric cloud.  Storage devices are no longer the place where data functionality is focused and it will be less so as time goes on.  The logical place for data mobility will be in the hypervisor (at least the hypervisor will be the controlling entity) and storage will become a feature as networks are today.  If this is right, then the concept of and need to differentiate Enterprise and Modular arrays will cease to exist.

The “simplification” of storage (and I say it in quotes deliberately, as storage remains complex) means vendors are having to stretch out into other technology areas.  EMC set the trend by demonstrating great foresight in buying VMware.  Cisco & HP have joined the unified computing club.  So now has Hitachi, selling their own servers and promising us their view of unified computing.

This shift away from storage is the interesting highlight of HDS Bloggers Day.  What exactly is the Hitachi offering in Unified Computing?  How have they integrated their server hardware and storage lines?  Most important, how is this all being managed through a harmonised management suite of tools?

Here’s a final thought.  Is the acronym Hitachi Data Systems still valid?  Perhaps the rebranding to just Hitachi is all part of a big plan.

I’m looking forward to catching up with people today (well, much later today) and will post more later.

• 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.

Well, I truly hope not.  Let me just explain what I’m talking about and things may become a bit clearer.

HDS have started their viral marketing for an announcement being made on 27th May.  Claus Mikkelsen’s latest blog entry asks us to guess what the announcement will be, based on an acronym of REGRADES OUR CLASSY TREAT.

So, I think the answer being searched for is STORAGE ARRAYS CLUSTERED or CLUSTERED STORAGE ARRAYS,, depending how you want to put it – however the title of this post is my favourite alternative…

So let’s try and guess what HDS are going to announce.  Looking back to when the USP was originally released, it was (and still is) sold on the concept of virtualising external storage, turning the USP, NSC55, USP-V and USP-VM into a storage controller, presenting cheaper storage products if they resided in the USP.  Whilst this was great (and HDS extolled the virtues of how UVM could fix all our migration problems) there was one flaw – once you’ve virtualised using the USP, how to you non-disruptively get the USP out?  I heard talk about ways in which multiple USPs could be clustered together to overcome this, but never saw it in practice.  So, with this new release, is HDS finally solving the problem?

There are only two enterprise/monolithic products worth discussing, Symmetrix/DMX and USP/XP.  The USP is running behind the latest EMC release, the V-Max, on a number of fronts:

• Scalability – the V-Max now offers up to 8 nodes and 2400 drives.  USP still sits at 1152.
• Tiering – DMX and V-Max offer larger SSD drives – 200 & 400GB.
• Performance – V-Max will offer FAST for better dynamic data placement.
• Replication – V-Max implements new replication devices for disk-less three site replication.

So I’m really hoping HDS will give EMC something to worry about including:

• Better Scalability – let’s have more than 1152 drives, we’ve been needing more than this for a while.  Let’s have flexible clusters to grow arrays as required.
• Dynamic Data Placement - let’s have something better than Volume Migrator.  Start thinking of data at the sub-LUN level.
• Dynamic Array Replacement – make it easy to remove one array, migrate external storage to another without impact.

Even better, announce something I’ve not even thought of and surprise us all.

Anyone got a suggestion as to what it should be called?  USP-VC, USP-C?

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!!

There’s no doubting that storage virtualisation will prove to be a key component of IT architecture in the future. The overall benefit is to abstract the physical storage layer from servers either in the fabric, or through the use of a dedicated appliance or even in the array itself.

Over time, storage resources can be upgraded and replaced, potentially without any impact to the host. In fact, products such as USP from HDS are sold on the virtues of their migration features.

However at some stage the virtualisation platform itself needs to be replaced. So how do we do that?

The essential concept of virtual storage is the presentation of a virtual world wide name (WWN). Each WWN then provides virtual LUNs to the host. The virtualisation appliance manages the redirection of I/O to the physical device, which also includes responding to SCSI LUN information queries (like the size of the LUN).

Ultimately, the host believes the virtual WWN is the physical device and any change to the underlying storage is achieved without affecting this configuration. If the virtualisation appliance must be replaced, then the virtual WWN could change and this means host changes, negating the benefit of deploying a virtual infrastructure.

As an example, HDS and HP allow USP/XP arrays to re-present externally connected storage as if it is part of the array itself. LUNs can be moved between either physical storage medium (internal or external) without impact to the host. However, the WWN used by the host to access the storage is a WWN directly associated with the USP/XP array (and in fact decoding the WWN shows it is based on the WWN serial number). If the USP is to be replaced, then some method of moving the data to another physical array is needed. At the same time, the host->WWN relationship has to change. This is not easy to achieve without (a) an outage (b) host reconfiguration (c) using the host as the data mover.

There isn’t an easy solution to the issue of replacing the virtualisation tool. Stealing an idea from networking, it could be possible to provide a DNS style reference for the WWN with a “name server” to look up the actual physical WWN from the “DNS WWN”. Unfortunately whilst this would be relatively easy to implement (a name server already exists in Fibre Channel) the major problem would be maintaining data integrity as a DNS WWN entry is changed and reads/writes start occurring from a new device. What we’d need is a universal synchronous replicator to ensure all I/Os written to an array are also written to any other planned target WWN, so as the WWN DNS entry is changed, it can’t become live until a guaranteed synchronous mirror exists. I can’t see many vendors agreeing to open up their replication technology to enable this; perhaps they could offer an API for “replication lite” which was used solely for migration purposes while the main replication product does the big replication features.

In the short term, we’re going to have to accept that replacing the virtualisation engine is going to have some impact and just learn to work around it.

Does anyone use CU Free? Here’s the reason for my question.

I’ve just implemented a migration from a pair of 9980V and 9970Vs to a single USP in one site and a 9970V and 9980V remaining in the other site. All of the MCU->RCU relationships (4 of them) are being used between the USP and the 99XXV boxes.

If I implement another USP in the site with the 9900’s I want to replicate from the existing USP. Will CU Free let me exceed the MCU->RCU restriction or is it just a helpful way of saving me having to enter all the paths for all the CU relationships I want to use? i.e. is the restriction of 4 still there regardless?

Thanks to everyone who commented on the previous post relating to using virtualisation for DR. I’m looking forward to Barry’s more contemporaneous explanation of the way SVC works.

I guess I should have said I understand Invista is stateless – but I didn’t – so thank’s to ‘zilla for pointing it out.

So here’s another issue. If SVC and USP cache the data (which I knew they did) then what happens if the virtualisation appliance fails? I’m not just thinking about a total failure but a partial failure or another issue which compromises the data in cache?

I was always worried that a problem with a USP virtualising solution was understanding what would happen if a failure occurred in the data path. Where is the data? What is the consistency position? A datacentre power down could be a good example. What is the data status as the equipment is powered back up?

It’s good to see virtualisation and the various products being discussed again at length. Here’s an idea I had some time ago for implementing remote replication by using virtualisation. I’d be interested to know whether it is possible (so far no-one from HDS can answer the question on whether USP/UVM can do this, but read on).

The virtualisation products make a virtue out of allowing heterogenous environments to be presented as a unified storage infrastructure. This even means carving LUNs/LDEVs presented from an array into consituent parts to make logical virtual volumes at the virtualisation level. Whilst this can be done, it isn’t a requirement and in fact HDS sell the USP virtualisation on the basis that you can virtualise an existing array through the USP without destroying the data, then use the USP to move the data to another physical LUN. Presumably the 1:1 mapping can be achieved on Invista and SVC (I see no reason why this wouldn’t be the case). Now, as the virtualisation layer simply acts as a host (in USP’s case a Windows one – not sure what the others emulate) then it is possible (but not usually desirable) to present storage which is being virtualised to both the virtual device and a local host, by using multiple paths from the external array.

If the virtualisation engine is placed in one site and the external storage in another, then the external storage could be configured to be accessed in the remote site by a DR server. See example 1.

Obviously this doesn’t gain much over a standard solution using TC/SRDF other than perhaps the ability to asynchronously write to the remote storage, making use of the cache in the virtualisation engine to provide good response times. So, the second picture shows using a USP as an example, a 3 datacentre configuration where there are two local USP’s providing replication between each other but the secondary LUNs in the “local DR site” are actually located on external storage in a remote datacentre. This configuration gives failover between the local site pair and also access to a third copy of data in a remote site (although technically, the third copy doesn’t actually exist).

Why do this? Well, if you have two closely sited locations with existing USPs where you want to retain synchronous replication and don’t want to pay for a 3rd copy of data then you get a poor man’s 3DC solution without paying for that third data copy.

Clearly there are some drawbacks; you are dependent on comms links to access the secondary copy of data and in a DR scenario performance may be poor. In addition, as the DR USP has to cache writes, it may not be able to destage them to the external storage in a timely fashion to prevent cache overrun due to the latency on writing to the remote external copy.

I think there’s one technical question which determines whether this solution is technically feasible and that is; how do virtualisation devices destage cached I/O to their external disks? There are two options I see; firstly they destage using an algorithm which minimises the amount of disk activity or they destage in order to ensure integrity of data on the external disk in case of a failure of the virtualisation hardware itself. I would hope the answer would be the latter rather than the former here, as if the virtualisation engine suffered some kind of hardware failure, I would want the data on disk to still have write order integrity. If this is the case then my designs presented here should mean that the remote copy of data would still be valid in case of loss of both local sites, albeit as an async copy slightly out of date.

Can IBM/HDS/EMC answer the question of integrity?

There’s been a few references to Invista over the last couple of weeks, notably from Barry discussing the “stealth announcement”.

I commented on Barry’s blog that I felt Invista had been a failure, due to the number of sales. I’m not quite sure why this is so, as I think that virtualisation in the fabric is utimately the right place for the technology. Virtualisation can be implemented at each point in the I/O path – the host, fabric and array (I’ll exclude application virtualisation as most storage managers don’t manage the application stack). We already see this today; hosts use LVMs to virtualise the LUNs they are presented; Invista virtualises in the fabric; SVC from IBM sits in that middle ground between the fabric and the array and HDS and others enable virtualisation at the array level.

But why do I think fabric is best? Well, host-based virtualisation is dependent on the O/S and LVM version. Issues of support will exist as the HBAs and host software will have supported levels to match the connected arrays. It becomes complex to match multiple O/S, vendor, driver, firmware and fabric levels across many hosts and even more complex when multiple arrays are presented to the same host. For this reason and for issues of manageability, host-based virtualisation is not a scalable option. As an example, migration from an existing to a new array would require work to be completed on every server to add, lay out and migrate data.

Array-based replication provides a convenient stop-gap in the marketplace today. Using HDS’s USP as an example, storage can be virtualised through the USP, appearing just as internal storage within the array would. This provides a number of benefits. Firstly driver levels for the external storage are now irrelevant (only requiring USP support, regardless of the connected host), the USP can be used to improve/smooth performance to the external storage, the USP can be used for migration tasks from older hardware and external storage can be used to store lower tiers of data, such as backups or PIT copies.

Array-based replication does have drawbacks; all externalised storage becomes dependent on the virtualising array. This makes replacement potentially complex. To date, HDS have not provided tools to seamlessly migrate away from one USP to another (as far as I am aware). In addition, there’s the problem of “all your eggs in one basket”; any issue with the array (e.g. physical intervention like fire, loss of power, microcode bug etc) could result in loss of access to all of your data. Consider the upgrade scenario of moving to a higher level of code; if all data was virtualised through one array, you would want to be darn sure that both the upgrade process and the new code are going to work seamlessly…

The final option is to use fabric-based virtualisation and at the moment this means Invista and SVC. SVC is an interesting one as it isn’t an array and it isn’t a fabric switch, but it does effectively provide switching capabilities. Although I think SVC is a good product, there are inevitably going to be some drawbacks, most notably those similar issues to array-based virtualisation (Barry/Tony, feel free to correct me if SVC has a non-disruptive replacement path).

Invista uses a “split path” architecture to implement virtualisation. This means SCSI read/write requests are handled directly by the fabric switch, which performs the necessary changes to the fibre channel headers in order to redirect I/O to the underlying target physical device. This is achieved by the switch creating virtual initiators (for the storage to connect to) and virtual targets for the host to be mapped to. Because the virtual devices are implemented within the fabric, if should be possible to make the virtual devices accessible from any other fabric connected switch. This poses the possibility of placing the virtualised storage anywhere within a storage environment and then using the fabric to replicate data (presumably removing the need for SRDF/TrueCopy).

Other SCSI commands which inquire on the status of LUNs are handled by the Invista controller “out of band” by an IP connection from the switch to the controller. Obviously this is a slower access path but not as important in performance terms as the actual read/write activity.

I found a copy of the release notes for Invista 2.0 on Powerlink. Probably about the most significant improvement was that of clustered controllers. Other than that, the 1.0->2.0 upgrade was disappointing.

So why isn’t Invista selling? Well, I’ve never seen any EMC salespeople mention the product never mind pushing it. Perhaps customers just don’t get the benefits or expect the technology to be too complex, causing issues of support and making DR an absolute minefield.

If EMC are serious about the product you’d have expected them to be shoving it at us all the time. Maybe Barry could do for Invista what he’s been doing in his recent posts for DMX-4?

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;

1. There’s an inescapable power draw per drive which can’t be avoided; this equates to about 20W per drive.
2. The controller frame needs about 6KVA and this varies only slightly depending on the number of controllers and cache.
3. The HDS controller is slightly more efficient than the EMC.
4. 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…