520 Byte Sectors

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

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

Unlocking Free Space

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

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

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

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

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

Symmetrix Virtual Provisioning Space Reclamation reduces capacity requirements and total cost of ownership by automatically reclaiming chunks (768 KB track groups) that contain all zeros. This is most effective when used on volumes after thick-to-thin migration or replication.

So, it seems that V-Max now supports features previously only seen on 3Par InServ, HDS USP V and HP XP – that is the ability to reclaim empty “zeros” of data from LUNs – otherwise known as Zero Block Reclaim.

I don’t remember EMC mentioning this little fact as part of their big FAST announcement.  In fact, looking back over Barry B’s posts, here’s a link to a post from July in which Barry indicates (quoting again);

I cannot confirm nor deny that VP will support one or more unused space reclamation approaches in the future.

So do EMC just see ongoing space reclamation as a BAU activity, not worthy of an announcement?  I’m surprised that this would be the case.  Reclamation of “empty” storage is incredibly important when migrating from thick->thin storage environments.  Hitachi quote around 40% savings from using ZPR after a migration to thin provisioning on USP V.

Perhaps EMC don’t want us to know that migrating to V-Max can actually reduce the amount of storage in use.  After all, its not good for hardware sales, is it?

By the way, EMC, please feel free to comment on this new feature and how easy it is to use.  I’d be interested to discover how it is implemented.

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.

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.

http://thestoragearchitect.com/2009/12/01/review-drobopro-part-i/

Previously I discussed a few frustrations with connecting my new DroboPro to ESXi, the target environment for my new device.  I’ve now managed to get the ‘Pro connected and visible within ESXi.  See the attached screenshot image taken from my production ESXi server.

So far, I’ve configured eight 2TB LUNs (although the DroboPro itself only has a capacity of 5TB, 2x 2TB and a single 1TB drive) which are numbered 0-7; the LUN column on the screenshot.  Compare this to the LUNs presented from my ix4-200d, which has three LUNs all numbered ’0′.  The difference is in the way the DroboPro is choosing to present iSCSI devices and the Runtime Name column gives a clue.  In standard Controller/Target/LUN or CxTyLz/CxTyDz methodology, the ix4 disks are using separate targets to map out each iSCSI LUN, with the LUN number always ’0′.  The Target setting is analagous to a storage port, typically a physical port on large fibre channel arrays.  The LUNs are then numbered on that port.  The DroboPro presents all its iSCSI LUNs on the same target (in this instance number 3) and so the LUNs are numbered from 0.

This method of presentation doesn’t necessarily cause a problem, but is just a different way of presenting the LUNs.  Presumably with the Drobo Elite the multi-user functionality is achieved by enabling multiple targets per Drobo, each mapped to a separate user.  In any case, I now have visibility of my DroboPro within ESXi.  Time, to write some data.

In summary, I run a “production” Windows AD domain, Exchange, IIS and file services. This is a typical scenario for many small businesses, with perhaps a few variations thrown in for good measure, such as SharePoint. I’m moving to a virtual environment that is built on ESXi v4.0, a custom design Intel-based server with 2x Quad Core Intel 5420 processors and 16GB of memory. Local hard drives include 2x SAS 7.2K 500GB drives and 2x 73GB SAS 15K drives.

Storage Choices

The first question I posed for my infrastructure is to decide on a storage platform. As this is a SOHO type deployment, I don’t have the luxury of a fibre channel SAN environment. I expect that many SMBs will feel the same and not want to commit to fibre channel deployments when the alternative options out there are low cost and probably more suitable. Therefore here are my choices:

• Internal drives. I have over a terabyte of internal storage but unfortunately its not RAID protected. The disks are deployed on SAS connectors on the motherboard rather than through a dedicated RAID card. Although I could change the configuration and include a card, there are a number of issues; (a) increased cost (b) downtime to replace failed drives (c) physical intervention and downtime on the server to replace drives. My goal is to deploy this infrastructure to run 24×7, so having to take the system down to replace a drive is not an option. I also think that internal drives wouldn’t give me the scalability I might need.
• iSCSI. In this environment, iSCSI is a great solution; there are lots of SMB iSCSI solutions on the marketplace today, offering low cost storage with simple operations. iSCSI is definitely a possibility.
• NAS. Using NAS (more specifically NFS) for storage on VMware provides lots of flexibility. The management of the filesystem itself moves to the NAS hardware and so any VMware host files appear as standard files on the NAS device. When people see this, they usually get the “light bulb moment” as they realise the possibilities this kind of deployment offers. Whole virtual machines can be cloned, backed up or even simply copied as files around the infrastructure. NAS offers easy access to log and configuration files too.

So, for me the choice is NAS. I have iSCSI deployed, but for my production environments, NAS will be used to store my VMware hosts. This is for a variety of reasons, however there’s one additional benefit I haven’t discussed and that’s portability. Placing my vmdk’s on NAS means I can move them around at will. I can replicate them, I can back them up and I can move them easily to another NAS device without using ESXi as the data mover.

Stay tuned for more discussions as I evolve my setup.

The device itself is very different.  First of all, the DroboPro accomodates up to 8 drives and so is orientated horizontally (otherwise it would fall over).  At the back, the cabling supports Ethernet, USB and Firewire.  Unfortunately the plugs are recessed and consequently removing the Ethernet cable is a pain as you can’t easily squeeze the retaining lug that releases the cable.  The power supply is now integrated into the unit and there’s no separate PSU brick.  This could present a problem if the power supply fails, as it isn’t obvious how (or even if) the integrated power supply could be replaced.  I expect that power is now integrated to make the DroboPro more datacentre friendly.  One last comment; the device is considerably more more noisy than its smaller brother, presumably because it has to cool twice as many hard drives.

• USB and iSCSI Configuration – it isn’t clear whether the Drobo Dashboard can configure the DroboPro over either the USB connection or the iSCSI connection or whether USB connectivity needs to be retained for future configuration tasks.  Be aware – unplugging the USB cable seems to cause the Drobo to immediately reboot.
• Reduced Management – if the DroboPro is to be connected to an ESX server, then the documentation indicates the USB cable should be removed.  What’s then not clear is how the  ongoing status of the device can be managed.  For example, at this point, where should the Drobo Dashboard be run from?  The lack of a permanent management console means downtime to check the status of the device, to see the current occupancy levels and the effect of adding in additional capacity.
• Lack of detailed Information – As yet, I haven’t managed to work out where or whether there are details provided on the utilisation of each configured LUN.  The DroboPro allows for up to 16x 16TB LUNs, which is a huge volume of data (although ESX only allows iSCSI LUNs up to 2TB).  I’d like to be able to work out which of those 16 volumes consumes the most physical compared to logical space, especially with ESX where the Drobo’s intelligent file system aware technology currently doesn’t apply.
• Multi-Drobo Management.  I have more than one Drobo device now (DroboPro, DroboShare & Drobo).  The dashboard doesn’t appear to cater for multiple devices managed from the same machine.

• Network versus Storage.  There’s no doubt, Network and Storage teams get on about as well as cats and dogs.  Although both support networking technologies, they are implemented fundamentally differently.  In fact the only organisation I’ve seen that had the Network team managing fibre channel had implemented it like an IP network and it was a mess.  As the iSCSI protocol means handing control of the physical transport layer to the network team, then the simpler option is to avoid using iSCSI in the first place.
• It’s Too Easy.  This may seem like a contradiction, but running a fibre channel network usually means managing a controlled environment.  Nobody connects without permission, nobody gets access without being zoned in.  Implementing iSCSI is simple and so inherently means less control.
• There are no Standards.  Fibre channel networks are great because you have to use expensive components and match everything against approved matrices or you don’t get support.  iSCSI can be implemented using the cheapest NIC and virtual iSCSI targets.  However, this ease of use also means there’s no vendor certification in the way there is with fibre channel.  Who are you going to blame when things go wrong?
• FCoE will Rule The World.  Yes, Fibre Channel over Ethernet will be the One Storage Protocol to Rule Them All and replace fibre channel, iSCSI, AoE, NFS, CIFS, and any other protocol you care to name.  OK, I’m being slightly sarcastic, but FCoE is set to harmonise the physical connect, leaving iSCSI redundant.

So what’s the future for iSCSI?  We’ve seen the rise in popularity of home storage devices in recent years (think Iomega and Drobo).  We’re now seeing these devices sporting Ethernet connectivity that supports iSCSI.  With iSCSI Initiators (like the one in Windows) being totally ubiquitous, it’s a no-brainer to deploy iSCSI in home and small office environments.  Maybe there is still a future for iSCSI after all in providing low-cost block storage for the consumer masses.

Why Bother?

Ian’s post goes into more detail than the scope I intend to cover here.  In fact, all I’m concerned with is LUN size.  I don’t mind if it’s 1GB or 100Gb as a standard (well, I do, but that’s another post), all I care about is keeping a consistent LUN size across vendor technologies.  Here’s why.

Host Based Migration

None standard LUN sizes mean host-based replication.  It means using tools at the host level (like Veritas Storage Foundation) to restructure the data onto new LUNs.  Worse, it could mean simply bulk copying of data at the host level, with outages to boot. 

Good Advice

Here’s my advice.  Pick a consistent LUN size.  Choose one that works across all of your storage platforms at the block level, so when you want to move data by virtualisation or other vendor tools, you can achieve it without having to restructure the data.

I’m involved again with a client/customer I left about 3 years ago.  At the time, I recommended taking the hit and migrating their disparate infrastructures to a consistent LUN size.  They didn’t take my advice and they still have the same LUN size pain points they did 3 years ago.  It means the migration process to move off old technology is more complex and expensive than it needs to be. 

It’s amazing how such as simple change can be so impactful and how many organisations choose to ignore it.