Review: Sun Storage 7000 Unified Storage System – Part I

]]> This is the last in a four-part series of posts on the Sun Storage 7000 USS storage arrays.  Previous posts in this series can be found here:

Review: Sun Storage 7000 Unified Storage System – Part I

Review: Sun Storage 7000 Unified Storage System – Part II

Review: Sun Storage 7000 Unified Storage System – Part III

Previous posts have discussed the physical hardware and what you can do with it.  Sun also do a simulator version of the 7000 series array, which can be used to evaluate the technology.  The Simulator is available for both VirtualBox and VMware.  I chose the VMware version and deployed it on VMware Fusion on my MacBook.

Installation

The installation process is remarkably simple.  Download and unzip the simulator (link here) and for Fusion, simply use File -> Open to open the file “SunStorage.vmwarevm”.  The configuration process then asks for some simple details – IP address, default gateway, password and so on.  Once this is complete, the simulator starts up and can be accessed via the standard web interface on port 215.  I’ve included a few screenshots at the end of this post that highlight the configuration process.

Configuration

Once logged into the simulator, a disclaimer is presented to the user indicating that this deployment isn’t for production usage or performance measurement. This is pretty obvious; the simulator shows functionally how things work but will never provide the same performance as a dedicated device.

The simulator provides 15x 2GB drives, which although not ‘real’ are more than enough to do evaluation with.  As far as I can tell, the simulator appears to be fully functional.

Summary

Sun have provided a simulator package that appears to pretty much mirror a real USS 7000 array.  Having a fully functional system like this enables new users to gain confidence with it; although not much training is needed, making the mistakes on a simulator is much more preferable to making them on the real thing.  In addition, it’s easy for any potential purchaser to get a real feel for how easy configuring the 7000 Series can be.

The 7000 simulator is probably equal or better than the Netapp simulator, which I’ve raved (and probably ranted) about many times.  It’s a shame that Netapp don’t choose to make their simulator open to all users, but that’s another discussion entirely.  The Sun 7000 simulator simply rounds out what to me is a great product, offering storage and simplicity in a single device.

Disclaimer: Sun Microsystems provided a USS 7000 series array on loan in order for me to evaluate this technology.  The unit has since been returned.  I have not been paid by Sun to write this series of posts or received any other benefit or inducement of any kind from Sun Microsystems.

Barrons also wrote the day before on the STEC [...] ]]> Have a look at this news report from Barrons.com on their Tech Trader site.  STEC shares lost a whopping 36% as quoted in the article and in fact were down almost 39% for the day.  So have solid state drives lost their sparkle?

Barrons also wrote the day before on the STEC earnings call.  The interesting parts are (a) EMC, who take 90% of all STEC drives, aren’t selling as many as they expected (b) other vendors (notably IBM and Sun) aren’t doing well with SSD either.  So what’s the problem here?

For STEC the problem is clear – reduced demand and increased competition,  but that doesn’t answer the question of what’s going on with the wider market.

Opinion

SSDs are expensive.  SSD integration in most arrays is clunky, being a simple substitute for a standard drive.  I also believe that many customers are struggling to identify use cases for solid state drives and have no easy way to measure and justify the potential performance improvements – other than to install the drives and see what happens.  “Buy and Try” isn’t exactly a scientific approach.

Although it will eventually happen, I think the death of the fibre channel drive isn’t about to happen for some time.

Review: Sun Storage 7000 Unified Storage System – Part I

So in the first post in this series I discussed the USS and gave a basic overview of the hardware.  In [...] ]]> This is the second in a series of articles on Sun Microsystem’s Unified Storage System, also known as Amber Road.  Previous post(s):

Review: Sun Storage 7000 Unified Storage System – Part I

So in the first post in this series I discussed the USS and gave a basic overview of the hardware.  In this post I’ll discuss the disk components of the hardware in more detail and look at the use of flash (SSD) drives and ZFS to produce a commodity storage device.

Traditional storage arrays permit the configuration of multiple disk types within a single array.  This can range from solid state disks (SSDs), through to fast fibre channel drives and slower high capacity SATA drives.  USS operates a slightly different model – all drives in the USS array are high capacity SATA.  SSD drives are then used to ameliorate performance on read and write activity in combination with the ZFS file system, by using the SSDs for read caching and write logging.

How ZFS & SSD Are Used

OK, I’m not going to post a long diatribe about ZFS (although I may in the future), however it’s worth just having a look at the basic concepts in order to understand how ZFS impacts USS performance.  So, ZFS (originally called “Zettabyte File System”) is a high performance, high capacity filesystem introduced into Solaris about three years ago.  It is more resilient than UFS, not requiring filesystems checks after a system crash.  It also integrates the features of a standard filesystem and volume manager, pooling physical disks into groups from which filesystems can then be created.  ZFS supports RAID protection, including RAID-1 and RAID-Z, a proprietary implementation of RAID-5.  RAID-Z doesn’t suffer the same performance penalty as traditional RAID-5 as ZFS uses a Copy-on-Write (COW) methodology to write data into new locations rather than overwriting the original position.

ZFS uses two features (which relate to USS) to improve performance.  Firstly, disk reads are held in cache (called ARC  - Adaptive Replacement Cache).  Second, disk writes are journalled  (or logged) into the ZIL (ZFS Intent Log).  The ZIL provides resilience in the event of a system crash, however it also offers the opportunity for increased filesystem write performance.  Have a look at the graphic on the right, which is heavily used in the Sun documentation on USS.  This shows how traditional storage pools would be allocated with RAM and disk.  The USS model implements ARC for cached reads (which is stored in RAM), L2ARC, a level 2 ARC which extends ARC and is stored on read-biased SSDs and the ZIL, which is stored on write-biased SSDs.

L2ARC allows cache reads to be improved by creating an intermediate tier of read cache between disk and main memory.  ZIL improves writes by logging them to SSD and periodically flushing them to physical disk.  In the event of a system crash, integrity is still maintained as the ZIL is non-volatile.

In the USS, SATA drives are used in the main disk pool.  STEC SSD drives are used for the L2ARC and ZIL.  The model I reviewed had 36GB of ZIL cache, deployed as two 18GB SSD modules in standard disk enclosures.  The current implementation of USS only allows for a single disk pool, which means all data has to be protected with the same RAID level.  This is an annoying restriction, but I expect it will change in a future release as creating separate pools is simply a ZFS feature.

Why SSD and SATA?

It’s worth touching on why the USS is different to a traditional storage device.  In a typical general storage array there will be LUNs presented to hosts which are very active, some moderately active and some totally inactive.  If the LUN activity is plotted on a graph with the busiest LUNs on the left, the least active on the right and the Y-axis showing the degree of activity on each LUN in IOPS, the profile of a normal system will follow the “Long Tail” model.  This variation in activity is why savings can be made from operating a tiered model in a large storage array , placing LUNs on the appropriate tier of storage based on their activity level.

However, the trouble with taking I/O profile snapshots is that they’re just that – a snapshot.  They represent the I/O activity at that point in time.  Take a sample at another time of day or day of the week and another profile results.  This may show a very different set of busy LUNs compared to those highlighted previously.  One option is to average out the profiles over a suitable interval – say a day, a week or a month.  Whilst this will show on average the busiest LUNs, it will also mask any potential peaks in I/O demand as they will be averaged out over the period.  The shorter these peaks are, the less likely they will be noticed.

Deployment of tiering has one other problem and that is determining the amount of storage required in each tier.  It may well be that the ratios of each storage tier required changes over time as an array grows in size.  Perhaps the consumers of storage on the array realise that tier-1 storage is expensive and ask for more tier-2 or a new project comes along that needs a large volume of tier-0 SSD.  Typically, traditional arrays are inflexible at physically swapping tiers of storage on demand.

The USS provides one option to the Long Tail model.  By accepting all writes into SSD and destaging later to SATA, it ensures that high performance non-volatile storage is available at the time of the write and for multiple successive reads.  Fronting disk access with SSD ensures that high performance is dynamically provided to LUNs as it is needed.

Now it would be possible to compromise the SSD write cache by flooding a USS array with writes and this would be true for any array.  The question is at what point the USS would fail.   Unfortunately with my testing, I wasn’t able to generate sufficient  workload to overwhelm the 7210 I tested.  However I can say that in the testing I performed, the array coped easily with the workload I threw at it.  Clearly there’s still a requirement to manage the ratio of SSD to SATA based on the workload profile of the array.

Value Proposition

So what’s the value of using SATA and SSD in combination as the USS does?  There are a number:

• All data is stored on cheap, high capacity SATA drives, reducing the overall cost of the solution.
• I/O performance demands are managed by a small incremental cost in SDD.
• Variations in I/O workload performance is dynamically managed, removing the need to implement multiple storage tiers, significantly reducing management overhead.
• Array expansion is simplified – there’s no need to spend time planning how additional storage should be assigned to an array by tier.

Next time I’ll look at the analytics provided by the USS and how it allows detailed device reporting.

Now I only saw the news a few minutes ago but already my mind is racing.  Firstly, Oracle doesn’t strike [...] ]]> So all the debate about IBM buying Sun Microsystems has counted for nothing.  Oracle have stepped in and acquired the company for $9.50 a share in cash.  Here’s the press release.

Now I only saw the news a few minutes ago but already my mind is racing.  Firstly, Oracle doesn’t strike me as a company that gives things away for free.  I don’t see how their strategy would stack up against Sun’s free+support model.  Perhaps OpenSolaris will cease to exist.  What about MySQL?  My first thought is be that Oracle would simply kill it, but that would reduce future opportunities from potentially lucrative customers who use it today.

What about the storage business? Would Oracle roll Pillar into the Oracle/Sun/StorageTek storage fold?  Interesting times indeed.  

Looks like Larry is making his very own bid for the datacentre.

First, Cisco announced their Unified Computing System – blade servers to you and me. UCS integrates blade servers with management functionality and the Unified Fabric.  What’s interesting is that Fibre Channel gets pushed out at this point [...] ]]> It’s certainly been a busy week in the world of enterprise computing.

First, Cisco announced their Unified Computing System – blade servers to you and me. UCS integrates blade servers with management functionality and the Unified Fabric.  What’s interesting is that Fibre Channel gets pushed out at this point in favour of either iSCSI or FCoE.  Whilst there’s plenty of commentary in the blogsphere on the server implications to this announcement, I’m more interested in the trend it sets for storage and in particular the movement away from Fibre Channel connected devices.  

I’ve commented before that I didn’t see a great need to shift to FCoE as it introduced additional cost and unnecessary technology change.  Clearly if you’re re-architecting a datacentre based on Cisco UCS, then FCoE will likely be the protocol of choice.  I’m not aware of any vendors actually shipping storage arrays that support FCoE (I know Netapp and EMC have stated they will support it – they did that last October).

Perhaps this indicates even further the move to commoditisation of storage components.

Next there’s the rumour that IBM are looking at acquiring Sun Microsystems.  There’s no doubt that Sun are cheap; at the height of the dot-com boom they were trading at $257.25 a share (1 September 2000).  By October 2007 they were less than a tenth of that figure ($24.92) and earlier this week, they were less than a quarter of that, making Sun worth less than they paid to acquire StorageTek in 2005.

What would IBM get?  There’s the obvious MySQL and Java components from the “classic” Sun business, but what about storage?  Well, there’s the StorageTek libraries – but IBM already have a business selling ATLs and multiple (and competing) drive formats – and tape doesn’t have a long-term strategic future in anyone’s business.  Then there’s enterprise storage arrays – rebadged Hitachi boxes.  Could this be the opportunity for IBM to finally shelve the DS8000 dinosaurs or would Hitachi run a mile from IBM? Just think how EMC would react if HP, IBM and HDS were all selling the competition to DMX.  The rest of the range is pretty generic modular stuff but does include the 7000 series,which IBM could use in replacement of their Netapp N-series relationship.  

Finally, EMC announced upgraded capacities to their Enterprise Flash Drives.  These come in at 200GB and 400GB models, keeping pace with existing traditional HDDs.  If anyone is prepared to say, I’d be interested to know how much EFD prices have dropped (per GB) since their introduction.  Hopefully DMX-5 (DMX-V) will provide granular access to these devices.