Tape has been part of the discussion on the twitterverse and despite everyone’s best attempts, is not dead yet.  Tape and backup may not be seen as cool [...] ]]> It’s been an interesting day of contrasts in the world of storage, one that shows storage is a diverse and wide ranging segment of IT.

The Old

Tape has been part of the discussion on the twitterverse and despite everyone’s best attempts, is not dead yet.  Tape and backup may not be seen as cool  - but data protection is an essential requirement of sustainable data management and tape still provides the one of the most cost effective methods of data protection and of course archive.  This has happened because tape continues to innovate.  Tape drive speeds and media capacities continue to push upwards to meet demand, driving the effective cost per GB down and so keeping tape a player in the long term data retention market.  Tape will be around for a long time to come.

The New

Flash storage is all the rage and today Pure Storage announced they have finally gone GA with their all-flash storage arrays.  They have also produced pretty funny video, taking a side swipe at traditional storage arrays using spinning disk.

Click here to view the embedded video.

Whilst this was a clever piece of marketing, it’s more useful to understand how this technology is implemented and why flash in a traditional array was only a stopgap.  At the recent Storage Field Day, Pure Storage presented a technical deep dive of their architecture, explaining some of the thoughts that led to their second generation array – available from today.  There was some pretty amazing detail presented, including a discussion on maintaining I/O latency when an SSD decides to falter.  The Pure Storage array can choose to recreate the data from parity rather than wait for the I/O to complete and so maintain low latency.  This is how solid state should be designed into storage arrays.  Here are the videos from the Pure Storage presentation.

Click here to view the embedded video.

Click here to view the embedded video.

Click here to view the embedded video.

Past Due

The Register carried two articles today discussing EMC VMAX, which is due for a refresh and expected to be announced at EMC World next week.  The first talks about EMC scaling VMAX to 4PB of storage and/or 3,200 drives.  This is a huge capacity to store in a single platform and represents a massive amount of information to keep in a single chassis.  Symmetrix will probably go down as one of the most successful and pivotal storage arrays in history, however I think it is coming close to the end of it’s useful life because:

• flash will be the dominant technology for high performance applications
• bulk capacity can be done cheaper and easier
• vendors are building technology towers, not centralising storage in the way they did 10 years ago
• intelligence is being pushed up to the hypervisor

First of all, let’s take a look at [...] ]]> Today Data Robotics (Drobo) are announcing a new range of storage devices specifically targeted at business customers.  However this is a market that already has many players; what are they offering and how will they fare in this already competitive market?

New Devices

First of all, let’s take a look at the new storage devices.  Nomenclature has been changed over previous models (business people like nice code names) and so we have the following new devices:

• B800fs – 8-bay NAS model
• B800i – 8-bay iSCSI SAN model
• B1200i – 12-bay iSCSI SAN model

It’s a pretty easy guess that the codes mean “B” for business, “fs” for file sharing “i” for iSCSI and the numbers designate the drive count in the chassis.  What’s new here from a hardware perspective is the 12-drive model, specifically designed as a rack-mount device.  Now business-class storage devices are very different from those used in an office environment by (for example) media developers or for local backup.  Consequently Drobo have had to step up to the mark and improve the resiliency of the existing hardware.  Therefore the new B1200i support all hot-swappable components (except the passive backplane) and additional power supplies and Ethernet connections have been added.  Note that the B800 models have not been upgraded in this way and still have a single power supply and dual Ethernet connections.  Images of the new devices are shown in this post.  It’s interesting to see that the B1200i rear view shows four expansion slots for connectivity, of which only two appear to be used.  Presumably the other two are for future expansion.

Software and Features

As mentioned earlier, the small device business market is a competitive place; EMC have just released their VNXe product, HP have the P2000 array; IBM recently released the StorWize v7000.  These storage appliances are fully specified devices offering advanced features for a low cost.  The features and software component could be an issue for Drobo.  The new models offer the excellent BeyondRAID functionality and only an additional tiering  option.

• BeyondRAID is Drobo’s thin provisioning and RAID technology combined.  In essence, data is laid out across the disks using RAID at the block level rather than replicating whole disks.  This methodology enables dis-similar disk capacities to be used in the device and for disks to be replaced or upgraded over time in order to increase capacity.  BeyondRAID provides the customers many advantages; disks can be purchased and added to the system as required, even though a greater logical capacity of storage has been configured.  This logical capacity doesn’t need to be changed as physical capacity increases.  Drives of greater capacity can be added over time, so customers can purchase the most effective price/capacity drive for their needs.  Also a single drive can be replaced without rebuilding the entire RAID set, only copying data that was on any removed drive.
• Data-aware Tiering.  The new Drobo model now support automated tiering of data across different device types, including SATA, SAS and SSD disks.  Tiering uses fixed algorithms to determine the best placement for data based on usage.  My first thoughts were that a fixed tiering algorithm might not be appropriate, however taking a step back and looking at the market this device is targeted for, many customers taking their first steps into SAN technology may not want or need to understand how things work under the covers.

However good the hardware is, ease of management is all about the software.  As a result, Drobo have released a new version of their dashboard, screenshots of which can be seen in the attached images.  Better management software for Drobo was always a requirement.  The existing dashboard doesn’t scale easily with multiple devices and there are a few major flaws within the software that would reduce the appeal to business.  It appears that the scalability issues have been addressed, but only a test-drive will tell how much better the software really is.

Summary

The entry-level SAN array market is becoming increasingly competitive.  There are many companies targeting this space, not including the big storage names I’ve mentioned earlier.  Data Robotics are pitching the new business models from £1409 ($2000) upwards, which presumably is for the B800i rather than the 12-bay model.  Although this does exclude disks, the price does seem competitive, as drives can be purchased by the customer at the lowest cost and added as required.  The competition will cite lack of features, but these are easily added with software releases and will be key to the success of the new devices.  In addition, the management software needs to be business-class or will be a major stumbling block.  Here are just a few features of the existing software that need to be improved:

• Pre-emptive hot-swap - currently a drive replacement is a recovery operation.  When a drive is removed, the Drobo rebuilds RAID from the remaining disks.  It would be better to allow this replacement process to happen pre-emptively, copying data off to a new disk (if slots are available) before the a disk is removed.  This also reduces the impact on performance as RAID rebuilds need to happen as quickly as possible, whereas planned data migrations can be run as background tasks.
• iSCSI Management - the existing iSCSI interface isn’t fully featured.  The dashboard only indicates when a single host has logged into an iSCSI target/LUN but doesn’t indicate the server name or IP address.  This can be frustrating in large environments where, for instance, an over-zealous VMware host acquires all LUNs on a device.  Sharing of LUNs is also not permitted today.
• Capacity Management - although the Drobo understands thin provisioning, it only reports utilised capacity for devices that have a recognised file system and are connected to a host running the Drobo dashboard.  However the device itself must know how much data is being used by each LUN, irrespective of the file format.  That data needs to be presented to the user, otherwise real capacity planning can’t be done.

Overall, I think Drobo are making an exciting move into the business space.  Price sensitivity is an issue in this market and the initial costs are low enough to be attractive to many new customers.  Data Robotics also offer a maintenance contract (DroboCare) for replacement parts, another key business feature.  Key success factors will be the improvement management interface and addition of new features to the device over time.  With 150,000 devices sold to date, Drobo appears to be a force to be reckoned with for the future.

Disclaimer: The organisers have paid for my flights and accommodation to attend this event, however I’m under no obligation to write anything; all views are my own.

It’s the first time I’ve [...] ]]> Today and tomorrow (Tuesday & Wednesday), I’m visiting Storage Networking World Europe (SNWE) in Frankfurt as an “editorial guest” of SNIA.

Disclaimer: The organisers have paid for my flights and accommodation to attend this event, however I’m under no obligation to write anything; all views are my own.

It’s the first time I’ve visited this event, which doesn’t seem as large as IP Expo in the UK last week, but does have all the major vendors present.  As an official member of the “press” I get access to the press lounge, which gives me a more comfortable environment to recharge batteries and blog about what I see as I wander around.

IBM Storwize v7000

Visiting the show floor earlier, I stopped by the IBM booth to check out the new IBM Storwize v7000 array, which looks a little like the old DS6000 devices.  It was interesting to see v7000 centre stage and the XIV displaced to another area off the actual stand.  Has XIV fallen out of favour so much it isn’t even allowed to be on the IBM stand?

I also managed to pop into the pNFS presentation by Alex McDonald (who took every opportunity to remind us that he’s Scottish, despite forgetting his kilt).  I can see pNFS starting the move towards a converged storage protocol, where access is objected based, with either block or file chosen depending on data characteristics and performance requirements.  Alex’s presumption on the death of SAN may be premature, but I think we should see convergence of data types as we move to an object world.

In the first post, I discussed the shared storage model architectures typified by what we sometimes think of as Enterprise arrays, but I’ve called monolithic.  This term harks back to the mainframe [...] ]]> This is a series of post discussing storage array architectures.  Previous posts:

• Choosing Between Monolithic and Modular Architectures – Part I

In the first post, I discussed the shared storage model architectures typified by what we sometimes think of as Enterprise arrays, but I’ve called monolithic.  This term harks back to the mainframe days of large single computers (see Wikipedia definition), hence it’s use to describe storage arrays with a large single cache.  In the last 10 years we have seen a move away from the single shared cache to a distributed cache architecture built from multiple storage engines or nodes, each with independent processing capability but sharing a fast network interconnect.  Probably the most well known implementations of this technology have come from 3Par (InServ), IBM (XIV) and EMC (VMAX).  Let’s have a look at these architectures in more detail.

EMC VMAX

The VMAX architecture consists of one to eight VMAX engines (storage nodes) connected together by what is described as the Virtual Matrix Architecture.  Each engine acts as a storage array in its own right, with front-end host port connectivity, back-end disk directors, cache (which presumably is mirrored internally) and processors.  The VMAX engines connect together using the Matrix Interface Board Enclosure (MIBE), which are duplicated for redundancy.  The virtual matrix enables inter-engine memory access, which is required to provide connectivity when the host access port isn’t on the same engine as the data.  There are two diagrams in the gallery at the end of this post, one showing the logical view of the interconnected engines and the second showing how back-end disk enclosures are dedicated to each engine.

What’s not clear from the documentation is how the virtual matrix architecture operates, other than being based on the RapidIO.  I’m not sure if VMAX engines have direct access to the cache in other engines or whether the processor of connected engines is required.  In addition, can an engine access cache in another engine purely to manage throughput of the local host and disk connections? I’m not entirely sure.

3Par InServ

3Par storage arrays consist of multiple storage nodes joined through a high-speed interconnect.  They describe this as their InSpire architecture.  From 2 to 8 nodes are connected (in pairs) to a passive backplane with up to 1.6Gb/s of bandwidth between each node.  3Par use the diagram shown here to demonstrate their architecture and with 8 nodes, the numbers of connections can easily be seen.  I’ve also shown how connectivity increases in 2, 4, 6 and 8 node implementations.  InServ arrays write cache data in pairs, so each node has a partner.  Should one of the node pairs fail, the cache of the surviving partner is immediately written to another node (if one is present), so protecting the cache data.

The InServ and VMAX architectures are very similar but differ from each other in one subtle but important way.  3Par InServ LUNs are divided into chunklets (256KB slices of disk) that are spread across all disks within the complex.  So as an array is deployed and created, all of the nodes in the array are involved in serving data.  VMAX uses the Symmetrix architecture of hypers – large slices of disk – to create LUNs, with four hypers used to create a 3+1 RAID-5 LUN, for example.  As new engines are added to a VMAX array, the data is not redistributed across the new physical spindles, so data access is unbalanced across the VMAX engines and physical disks.  In this way, InServ has better opportunities to optimise the use of nodes, although within VMAX the use of Virtual Provisioning can help to spread load across disks in a more even fashion.  In addition, a fully configured VMAX array has up to 128Gb/s of bandwidth across the VMA, exceeding InServ’s capacity.

In my opinion the tradeoff here comes down to increased scalability with dedicated nodes versus the latency introduced when data isn’t located on the local node.  In the 3Par model, data is always being accessed across nodes.  In the EMC model, nodes only exchange data when the LUN’s physical disks aren’t located on the local node.  This leads to two problems.  Firstly, as more nodes are added, the number of node<->node connections increases exponentially.  For an 8-node array, there are at least 28 node to node connections (not including additional connections for redundancy).  This increases to 120 for 16 nodes (nearly 6-fold increase in connectivity for double the nodes) and nearly 500 connections for 32 nodes, to which VMAX can theoretically scale.  The second issue is that of diminishing returns.  As more nodes are added, more overhead is required to service data not found on the local node.  This leads to a situation where the benefits of adding additional nodes are so small to make it not worth doing.

IBM XIV

The IBM XIV array takes a different approach to node configurations that are directly connected to the underlying data protection mechanism of the hardware.  XIV uses only RAID-1 style protection, based on 1MB chunks of data known as partitions.  Data is dispersed across nodes in an even and pseudo-random fashion, ensuring that for any LUN, data is written across all nodes.  The architecture is shown in the XIV picture in the gallery at the end of this post.  Nodes (known in XIV as modules) are divided into interface and data types.  Interface modules have cache, processors, data disks and host interfaces.  Data modules have no host interfaces but still have cache, processors and disk.  Each module has twelve (12) 1TB SATA drives.  As data is written to the array, the 1MB partitions are written across all drives and modules ensuring that the two mirror pairs of any single partition do not reside on the same module.  Sequential partitions for a LUN are also spread across modules.  The net effect is that all modules are involved in servicing all volumes and the loss of any single module does not cause data loss.

Whilst XIV might be tuned for performance, there is still the inherent risk (however small) that a double disk failure results in a significant data loss, as all LUNs are spread across all disks.  Additionally the XIV architecture requires that every write operation must go through the Ethernet switches as data is written to the cache on the primary and secondary modules before being confirmed to the host.  As a consequence, overall bandwidth of a single module will be limited to the available network capacity, which is 6Gb/s for interface nodes and 4Gb/s for data nodes.  This value halves if either of the Ethernet switches fails.

Summary

The multi-node storage arrays on the market today are all implemented in slightly different ways.  Each has positive and negative points that contribute to the overall decision on which platform to choose for your data.  Whether any of them are suitable for “Enterprise” class data is an open question that continues to be the subject of much debate.  From my perspective I would want a “tier 1″ storage array to provide high levels of availability and performance, something each of these devices are capable of achieving.

Next I’ll discuss modular arrays and the benefits of dual controller architecture.