The ongoing battle for 3Par by HP & Dell tells us much more about the state of the IT Industry than just the desires of two companies to acquire some interesting storage tech.  It signals an acceptance that storage is a key feature in the future direction of the IT industry – more important than networking and almost as important as the virtualisation platform itself.

This may seem like a bold statement to make, however we need to look forward to where the industry is headed.  First of all, vendors want us to buy their unified hardware stacks; it represents that move back to a consolidated architecture that kept one vendor dominant in the mainframe days – IBM.  “No-one gets fired for buying IBM” the saying goes (or used to go), demonstrating how IBM was seen as the data centre supplier for all things computing in the 70’s and 80’s.  Of course we know that politics within organisations and the cost of IBM hardware eventually broke the monopoly, but the status quo worked well for many companies for many years.

Now, Cisco, EMC, VMware, HP, Oracle and potentially many others want to own your data centre.  They want you bought into their computing stack.  Over time, I suspect many of those same companies want to move you to their cloud infrastructure offerings, even if they don’t offer them today.  This will be both directly and indirectly.  There will be the direct model, where the vendor offers cloud services to you under their name; there will be the indirect model where their technology powers the cloud provider, or is offered as a service.  It’s at this point the 3Par acquisition becomes much more interesting.

3Par already have many customers in the cloud services sector.  In fact they sell their hardware on the virtues of multi-tenancy, reduced cost through thin provisioning, tight integration with virtual hypervisors and so on.  In this growth sector of the industry, cost is a key driver and no end user or company will pay more than they need for storage.  This means Enterprise arrays like those from Hitachi and EMC won’t play a central role in this future, but rather storage devices which provide the highest efficiency will.  Where do all the major players stand?

• EMC have entered the market with a brand new platform – Atmos.  Although withdrawn as a direct service, Atmos continues to be available from partners.  EMC have chosen to use their own technology as the foundation for cloud.  In addition, VPLEX provides the ability to virtualise the storage layer, including federation features that fit well with VMware.
• HP have a strong blade server offering for their cloud infrastructure.  Matrix provides orchestration for the server, network and some parts of the storage layer, however this work is incomplete and doesn’t fit well with the high end XP arrays.  Slotting 3Par into the storage layer would provide a storage platform well suited to HPs unified computing infrastructure.  It means EVA can be quietly dropped and XP can be retained (in whatever future guise) for high end customers (including mainframe) and if required, gradually dropped.
• Cisco have chosen to partner with EMC rather than acquire storage technology itself.  In fact, looking and both EMC and Cisco, they need each other; EMC have no server platform, Cisco have no storage; it’s a mutually beneficial arrangement, a bit like Jack Sprat and his wife.  At this stage, Cisco could have purchased 3Par and provided and end-to-end solution, but clearly that would be a big step and would require kicking EMC to the kerb, something they obviously don’t want to do (yet).
• Hitachi have server and storage offerings, however Blade Symphony is mainly sold in domestic Japan and not widely advertised globally.  They do have the potential to provide an end-to-end offering as Hitachi also sell networking equipment.  Key for Hitachi will be credibility in a market they don’t currently play in.
• IBM should have all the components of a consolidated infrastructure but there doesn’t appear to be a lot of discussion about their offerings.  They appear to have two strategies – Dynamic Infrastructure and Cloud Computing but their offerings aren’t clear.
• Dell clearly wanted 3Par to fit into their medium to high-end storage offerings.  Today Equallogic has successfully met their SMB requirements, but they OEM technology from EMC (CLARiiON and Symmetrix) for the rest.  Acquiring 3Par would remove that dependency and allow Dell to offer end-to-end technology as their own products.
• Netapp have a self-proclaimed unified architecture that does fit well with virtualisation from VMware.  However they don’t own any other parts of the technology stack and so must partner to deliver unified offerings.  Netapp are covering all bases by offering solutions with VMware, Microsoft and Citrix, but none of these could be described as the unified stack other vendors have.
• Oracle already provide an integrated infrastructure based around their Exadata acquisitions and of course all of the Sun Microsystems technology, however I’m not sure many companies would see the Oracle offerings as other than tied directly to their database platform and not for virtualisation.

Overall, 3Par fit the requirements of HP & Dell to provide integrated technology offerings.  The move to the cloud will require leaner and efficient storage products, plus tight integration and orchestration.  It’s all about positioning today for bigger returns tomorrow.

© Chris for Gestalt IT, 2010. | 3Par Acquisition: The Future For The Storage Industry
Read more posts categorized as Featured, Server Virtualization, Storage

I’ve twice posted now on Data ONTAP 8.0 shortcomings and this evening I did a little more research with the IBM version of Netapp’s hardware, the N-Series products.  Fortunately, IBM are slightly more generous and informative in their documentation than Netapp and this document (freely available online) provides more background information on the “DOT8″ transition process.  So, I’ve tried to produce a more in-depth objective view of the steps to move to “DOT8″.  Firstly the following diagram provides a clue as to how Data ONTAP has migrated to the current release.

At the point of reaching DOT8, Data ONTAP has been re-written to run off FreeBSD as the original GX code did.  This is a departure from the original Berkeley Net/2 code as documented in this post from Dave Hitz.  I have no idea how much of this version of the code was a re-write, but presumably porting over WAFL with all the bells and whistles it now has wasn’t an easy task.  This may go towards explaining why the current release of ONTAP took so long to come out.

Although the diagram shows the code base as being a single product, it isn’t.  There are still two modes, 7-mode, emulating  7G and cluster-mode emulating the GX product line.  These modes are non-interchangeable; you choose the one you want to use at system installation time and it’s fixed; no chance to change in the future.  As the IBM document explains (quote) “If a customer decides to change from one mode to another, the change is a transition rather than an upgrade (or downgrade).  Dual boot capabilities are not present, so the transition requires total reconfiguration of the storage system.  This can include backup and restore of user data”.

I think it would have been fairer to draw two parallel lines here as it appears there are still to pretty separate versions of code masquerading as a single marketing version.  So, the remainder of this discussion focuses on 7-mode.

Upgradeability

What happens if you want to take an existing system and upgrade it?  Well, depending on your hardware, you may or may not be able to perform an upgrade.  Systems such as the 6xxx models, 3×70 & 3×40 models are upgradeable, devices such as the 2050 are not.  There are also restrictions on the disk shelves that can be used too.  Should you choose to upgrade from your current 7G release, you can only move to 7-mode or build a new 8.0 installation, presumably on new hardware as you wouldn’t want to trash your existing environment.  Be aware though, that upgrade actually removes certain features.  For instance, SMB 2.0, IPv6 & IPSec are not supported.  They will reappear in a future release.  Does this mean writing these features in the ported version of WAFL was too hard or was taking too long?  Why else would you remove features from an upgrade only to replace them later?  One final upgradeability gotcha – Performance Acceleration Modules (PAM) are not supported with the initial version of 8.0.

Aggregates

As mentioned in my previous post, aggregates move to 100TB in size.  However there are many restrictions.

• Volume SnapMirror will not replicate between unlike aggregate types; so you can’t replicated to/from 32-bit to 64-bit aggregates.
• aggr copy and vol copy commands will not work between different formats.
• Flexvol size for volumes using de-duplication in 64-bit aggregates is limited to 16TB
• System root volumes can only reside on 32-bit aggregates.

On the positive side, Qtree SnapMirror and SnapVault do work between aggregate formats.

Aggregate Migration

Here’s IBM’s statement on migration of data: “Currently there is no direct migration path or conversion from 32-bit to 64-bit aggregates.  The following options can be used to migrate the data: qtree SnapMirror, SnapVault, ndmpcopy”. Each of these options also has limitations, which I don’t have time to go into, but you can read in the referenced document.

Benefits

I’ve been trying to find any benefits of upgrading to DOT8 from the customer’s perspective. For new installations, the increased aggregate size is obviously a benefit, but does come with restrictions.  There are now interface groups rather than VIFs and it appears snapshots can now be named.  Excluding these, I can’t see that DOT8 is anything more than a positioning exercise as Netapp continue to get the real features they wanted in this version into future releases.  This has been hinted at by other commentators.

Whilst I can see the benefits to Netapp of this move, I fail to see the benefit to the customer, who will have to suffer major migration headaches to realise what are small improvements from a major version upgrade.  I suspect many customers will chose to wait for 8.0.1, 8.1 or whatever version actually integrates the real improvements.  During that time, it offers more opportunities for the competition to be snapping closer to Netapp’s heels.

© Chris for Gestalt IT, 2010. | Data ONTAP 8.0 – Part III
Read more posts categorized as Featured, Storage

In the previous article I discussed the subject of Billing and Chargeback.  This entry discusses some of the issues raised in that post as additional considerations.

Chargeback and Standards

Implementing efficient standards is a given in any IT organisation.  However inevitably what should be a single standard always turns out to be partial implementation of multiple standards as time progresses.  This occurs because standards change; companies acquire other companies and their technology; companies expand and so on.  Sometimes it is simply too cost prohibitive to retro-fit new standards especially when things like server names are intrinsic to the installation of a software product (like databases).

Irrespective of the issues, it is still necessary to adhere to standards in order to implement effective chargeback and billing.  After all, resources have to be attributed to owners at some stage.  This means maintaining an efficient CMDB (Configuration Management Database) relating IT resources to business owners/customers within the organisation.  Whether that is via a spreadsheet or custom DB doesn’t really matter; it’s the content and its accuracy that counts.

As storage resources are provisioned, then so these standards should be maintained.  I always strive to ensure any resources can be mapped back to a server or business unit.  For example, zoning names should contain the server name as a minimum.  On storage arrays, storage groups should be related to the host/owner as should WWN visible names.  The format of fields should be consistent too, in order to enable scripts to process the values; choose consistent separators between fields (like the ‘_’ symbol) for example.

Chargeback Measuring Tools

If the standards are right, then extracting the data for billing should be simple.  The process may be as basic as using scripts to collect data; it may mean using the reporting features of your provisioning software, as most tools have some kind of reporting mechanism.  It may mean using a bespoke reporting tool, like Storage Fusion’s SRA product.  However it is achieved, the requirements are simple; map configuration information to the service you are offering and assign costs to customers/owners on that basis.  For example, if your charging is based on tiers of storage, the reporting/measuring process needs to be able to identify the tier types.  Making the Service Catalogue too complex at the outset can be self defeating if billing can’t easily be implemented.

Chargeback Measuring Interval

How frequently should you measure and/or charge?  I always find this subject interesting as there are ways for customers to avoid paying if they are clever.  Imagine the following scenario; billing is run monthly on the last day of the month and charges are accrued on assigned storage on that date.  However the storage team are able to turn around requests for provisioning/decomissioning within 48 hours.  So, for your project, you request space on the 2nd day of the month, run all the analysis you need, back up your data and return the storage 3 days before the end of month, at which time the resources are returned to the free pool and when billing occurs, the customer pays nothing.

Whilst this example is an extreme case, and I doubt whether most users would be in a position to take advantage, it demonstrates that a badly designed service catalogue, delivery structure and billing mechanism can lose money.   Alternatively, measuring utilisation on a daily basis could be time consuming and expensive to operate, therefore a compromise has to be found and this will depend on your specific circumstances.  Some options could be:

• Bill monthly on a fixed date; assume customer inertia will mean very little “cheating” of the system will occur. Build that into the overall cost.
• Bill monthly and include any provisioning requests made that month – a minimum charge of one month regardless.
• Sample data daily or weekly and bill monthly based on average consumption.

There are no specific rules to abide by here.  What’s important is the way in which billing, product catalogue and operational management occur are all lined up and consistent.

© Chris for Gestalt IT, 2010. | Four Pillars – Service: More On Chargeback
Read more posts categorized as Featured, Storage

This post is the first in a series covering the DroboElite SMB storage device from Data Robotics Inc.

The DroboElite is the most fully featured storage array in the Data Robotics range of devices.  Regular readers will know I’ve posted frequently on these devices, from the first Drobo “Classic” to the DroboPro, both of which I own and have purchased myself.  Data Robotics have kindly loaned me a DroboElite for this series of posts.  As you will see, the top of the range model offers all the features the other models provide, plus the benefits of multi-user support.

Background

The original Data Robotics storage device was what is now referred to as the Drobo “Classic”.  This was a 4-bay storage device, connecting to a single host PC/server using USB or Firewire and later eSATA.  This model evolved into the Drobo S and was complemented with the 8-bay DroboPro.  Finally, the DroboElite was released in November 2009, using the same form factor as the ‘Pro but with additional connectivity and features.  Although the ‘Pro and ‘Elite models shared the same look and feel, they are actually different products and so there’s no upgrade process to remove drives from the ‘Pro and install into an ‘Elite shell.

Physical

The DroboElite is an 8-bay device, accommodating standard 3.5″ SATA form factor drives.  The drives are inserted vertically (rather than horizontally in the 4-bay models), with drive’s top side pointing to the right.  No caddy or additional support is required.  From the front, there’s nothing to separate the ‘Pro and the ‘Elite as they look identical.  In fact, the removable magnetic front bezel only says “Drobo” and has no other distinguishing markings.  One thought worth considering for the future is providing a method of identifying multiple Drobo’s that have been installed into a rack or cabinet.  The drive lights can be flashed on and off but this only lasts for a few seconds and wouldn’t help an engineer who’s alone in a data centre or machine room.  This is a particularly important point as the ‘Elite is a multi-user device and so aimed at SMBs with machine rooms and rack-based equipment (a rack mount  kit is available).

Turning to the back of the ‘Elite, we start to see the differences with previous models.  The major one here is the presence of two Ethernet ports, providing network redundancy and multi-pathing support for iSCSI.  The power supply is still built in (and not removable), plus there’s a power switch and a USB connector – that it.  I’m undecided as to whether an integrated PSU is a good or a bad thing and I flip back and forth between internal/external and multiple supplies each time I think about it.  On reflection, the consideration here should be that the Drobo is not a “high availability” storage array in the modular or enterprise class.  It doesn’t support mulitple controllers or other features like mirrored cache, so in reality, multiple power supplies is probably over-configuration.  Obviously dual Ethernet connections is essential in a device that will support multiple hosts; this feature provides redundancy from failures in network equipment or more likely, enables maintenance to be performed on the network infrastructure without impacting the storage.

The addition of a power switch is a positive move (and essential as the power supply is now integrated).  Personally I’d have preferred the power switch to be mounted behind the magnetic bezel on the front of the unit.  This would mean once plumbed in, the ‘Elite (and ‘Pro for that matter) would be managed purely from the front, for disk insertions/removals.

I’ve one final comment on the physical aspects of the ‘Elite and that covers the insertion and removal of drives.  I never like removing spinning active drives and unfortunately there’s still no way to either mark a drive for removal or spin it down.  The unique BeyondRAID feature of the Drobo series means that any drive can be removed from a unit and the device ’self heals’ to compensate for the loss of capacity, rebalancing blocks of data redundantly across the remaining drives.  Of course drive removal doesn’t have to be done after a failure; the whole benefit of the Drobos is the capacity increase functionality (I frequently swap drives in/out as part of testing).  I’d therefore like to be able to spin down or at least highlight a drive I intended to pull, via software, before I physically pull it.  It gives me more confidence that I’ve pulled the correct drive when managing multiple units.

Additional specifications can be found here: http://www.drobo.com/pdf/droboelite-datasheet.pdf

In the next post, I’ll look at connectivity protocol support.

© Chris for Gestalt IT, 2010. | Hardware Review: Drobo Elite – Part I
Read more posts categorized as Featured, Storage

In any system, resources are finite.  There is always a limitation to what is available.  However there’s also a truism that states if resources are free then they will be consumed at an infinite rate.  So it is with storage.  Someone has to pay for the storage resources that are placed on the floor.  If customers are not charged in some way for their consumption of storage, then they will continue to consume resources ad infinitum.  The solution is to implement chargeback or, to be more precise, billing.

Definition

It’s worth pausing for a moment and discussing the terms Chargeback and Billing.  When computing was first made available as timesharing, customers were billed for their usage of the shared system.  The billing unit may have been time, CPU resources or some combination of metrics that represented utilisation.  Mainframe resources were so expensive that there had to be an efficient charging mechanism.   The concept of billing is something that was intrisically built into the mainframe design and even to this day, resources can be tracked using records produced by SMF (System Management Facility) and reported on through RMF (Resource Measurement Facility).  So billing represented a method of charging for usage that wasn’t directly related to the underlying hardware.

Chargeback implies a different methodology where the direct cost of delivering the service is charged back to the customer.  This can include people costs, but typically hasn’t, only covering the hardware provided itself.  Chargeback has its place, but when looking to develop a service, isn’t as flexible as billing.  All too often, chargeback is tied to a poorly implemented service catalog (or non-existent one).  Whilst the customer may pay for their equipment, there isn’t any flexibility when it comes to hardware replacement as the customer is aware of the technlogy used to deliver their service (and may be unwilling to move to new, untried hardware).  Here are a few additional chargeback/billing combinations that could be implemented:

• No chargeback – IT has a budget and they provide the resources to the business.  When resources are exhausted, the business have to justify or provide additional funds.
• Consumption-based – customers are charged directly for their usage.
• Shared-usage – customers are charged a share of the costs, not directly related to their usage, but perhaps size of business unit.
• Dedicated – customers are charged the whole cost of acquiring the technology.  Ths doesn’t work well for shared environments.
• Service-based – customers are charged for a service provided; this isn’t directly related to the specific technology in use.

Rationale

Whether you are implementing chargeback or billing, there needs to be a good reason for implementing.  Here are a few for consideration.

• To Reduce Costs – If resources appear to be free they will be consumed inefficiently; charging for usage helps controls this.
• Improved Utilisation – Being charged in proportion to your usage makes customers validate whether they really need the storage they are using.
• Improved Efficiency – this goes hand in hand with utilisation, however charging customers for storage can enable tiering to be implemented more efficiently.
• Charging Fairly – there will always be sensible customers and abusers (the broadband market shows us that).
• Manage Demand – It is possible to make charges both time and planning dependent (more on that later).
• Manage Tech Refresh – Abstracting cost and service catalogue from the hardware means new/cheaper/efficient technology can be introduced more easily.

What’s clear from the above points is that chargeback/billing can be used to change customer behaviour; users can be incentivised to be more efficient or to use cheaper technology.  Structured correctly, the overall cost of delivery of storage can include refresh funding, so as old devices are decommissioned, the cost of data migration is part of the overall charge.  I see this as one of the major issues with the way customers pay for their technology; the overall costs in the lifecycle of deployment, operation and refresh simply aren’t considered.

Metrics

What’s the best way to charge?  Here are a few typical metrics:

• Per GB of storage used.
• Per port on the SAN fabric.
• By Tier of storage.
• By contention ratio of storage port (higher cost for fewer hosts on a shared port)
• Charge for replication (both local and remote)
• Charge for deduplication (which may be a lower cost)
• Charge for thin versus thick provisioned LUNs
• Charge for SAN network bandwidth
• Charge for multi-path software
• charge for online backup copies
• charge for offline backup copies

Whatever metrics are used, the key intent is to charge for customer use of a service.  This needs to be abstract enough to be disconnected from technology, so charging for fibre channel ports may be too prescriptive; the cost may be described as “to be connected to the SAN” in general, providing a blended charge that would cover iSCSI, Fibre Channel or FCoE connectivity.

Implementing a Chargeback Process

As part of the implementation process, it’s worth considering having billing/chargeback principles established.  These can be provided to the customer.  Here are some examples:

• The charging model will be based on resource consumption of each user independently (e.g. user changing their utilisation doesn’t affect another user)
• Charging costs will be reviewed and changed on an annual/bi-annual/quarterly basis from 1 Jan 200x
• Charging will be based on storage in use on 28th day of each month
• Charging will/will not be based on utilisation (rather than allocation)
• Charging will be attributed at the host/server/LUN/file level
• A target of 100% cost recovery is the target goal
• Charging may result in an IT surplus/deficit from year to year, but will be a non-profit business
• Billing charges will be based on the published “Storage Catalogue”
• Users of equipment classed as legacy will be notified 6 months in advance of technology acquiring legacy status
• IT/Storage Team will strive to deliver price stability and/or reductions year-on-year
• Chargeback will be implemented as evolution rather than revolution

The internal cost of delivery of storage will include:

• Hardware and software costs
• Additional feature licences
• Power/cooling/space (environmental costs)
• People costs
• Training
• Network costs
• DR costs

There may be more, depending on how your technology is delivered (for instance managed data centres), but what’s essential is to baseline what it takes to deliver the service.  Quite simply the process would be:

1. Identify service cost components (as above)
2. Identify consumption metrics (service charging units)
3. Measure use
4. Model costs based on consumption metrics
5. Bill customers.

Other considerations, which I’ll save for future posts are:

• Standards – how they are important to chargeback
• Measuring tools
• Measurement interval
• Incentivising customer behaviour in favour of technology refresh
• Outsourcing some components
• Determining the customer
• Forecasting/Capacity Planning

There’s lots more to come, feedback on the article so far is very welcome.

© Chris for Gestalt IT, 2010. | Four Pillars – Service: Chargeback
Read more posts categorized as Featured, Storage

I’m not a fan of making press releases on behalf of other companies however once in a while, a news item catches my interest.  So it is with the announcement of the Violin Memory Inc. 3200 series of all-memory storage arrays.  Why are these interesting?  Because I think they are moving and potentially blurring the boundaries between spinning drives and memory-based permanent data storage.

Background

Building arrays from pure memory isn’t new; Texas Memory Systems have had the RamSan series of products on the market for some time now (and there are others out there).  Of course, the problem for many large organisations is how to make use of such an expensive and relatively small device.  There are plenty of use cases where flash/SSD may be useful, however (a) it is difficult to target exactly which applications and (b) for those applications that can be identified, potentially only part of the data will benefit from acceleration.

One solution has been to follow the route of the traditional vendors and add SSD as an extra device within the same hardware chassis.  This isn’t a solution to using SSD but rather a sticking plaster over the problem; the SSD may give better read performance but it is unlikely that writes will be accelerated to the level justified by the additional costs of the SSD device itself.  In addition, the SSD is sitting behind a traditional storage array.  Vendors such as EMC, IBM and Hitachi have spent millions of man-hours and hundreds of millions of dollars on software developments to help smooth the impact and manage the unpredictable performance of hard drives.  Remember that when an I/O request is received, the storage array has no idea where a mechanical device like a hard drive is positioned and so cache, algorithms and that other clever intellectual property have been used to mask these physical inadequacies.

However, despite vendors’ best efforts, spikes and unpredictable response times do occur and there’s no way to remove them and guarantee completely consistent I/O responses.

The Violin Approach

So what happens if you can remove the cost issues and buy an SSD-based array for the same price as tier 1 storage?  This is the route Violin Memory are taking to market – make the SSD storage array as closely priced to tier 1 arrays as possible.  Remove the thought process and complications of determining what to place on SSD by making the price argument irrelevant.

In reality, Violin haven’t reached that price parity yet; prices are quoted around the $20/GB mark, which is around double what I’d expect to see for tier 1 storage (depending on volume).  However it is in the order of magnitude where organisations can look at those troublesome applications that decide that the cost of additional servers, disk spindles or re-writing the application is outweighed by simply moving the application to a Violin SSD device.

I think this is the ultimate tipping point for SSD use; where the cost of improving application performance is exceeded by the cost of moving to SSD, then SSD will win.  Where improving application performance is justified by increased business advantage, the business case is written.

Tech Specs

OK, let’s have a look at the technical specifications for the techies amongst you.  Firstly, today’s device capacity sits at 10TB in 3U and is expected to grow to 20TB in Q3.  I’ve also been told that this capacity is expected to be close to 5x greater by the end of 2010, which means 100TB of memory-based storage in a 3U unit.

The 3200 supports PCIe (x4 & x8)  as well as 4/8Gb Fibre Channel and 10Gb iSCSI and FCoE.  Latency is less than 100 microseconds.

Violin array use VIMMs (Violin’s name for their flash memory cards.  These are grouped together into 1TB units, using RAID-5 technology to manage failures.  Maintenance can be performed online periodically to replace failed VIMM devices.

There’s one major issue with Flash/memory-based arrays that Violin claim to have addressed.  That is the issue of degraded performance over time.  Have a look at the following graphic, showing saturated workload on the Crucial C300 versus X25M from Intel.  This graph and the associated review can be found on Anandtech’s website here.  Very quickly with heavy use, the performance for these devices drops off.  Violin claim their array doesn’t suffer similar issues and can deliver sustained performance.  Of course, we can believe that statement once we’ve seen a review of the product delivering the performance as promised.

Futures

A 10/20TB capacity in 3U isn’t huge by today’s standards.  If Violin Memory can deliver on their promises and bring a 3 to 5-fold increase in performance by year end (with a continual reduction in price) then things start to look interesting.  I’d like to see the results of some long-term stress tests on the 3200 series devices.  I have some more material to post in the coming days, once I can validate what’s open and not under NDA/embarbgo.  In the meantime, here are some questions to ponder:

• Do I have any I/O bound applications?
• Can I measure/determine my I/O bound applications?
• Is there direct businss advantage from increasing I/O throughput?

If you can start answering yes to the above questions, then perhaps SSD-based arrays are for you.

© Chris for Gestalt IT, 2010. | Violin Memory Inc Release New All-SSD Array
Read more posts categorized as Featured, Storage

As discussed previously, the Service Catalogue is a key component of delivering storage as a service.  In this post, I’ll explore some thoughts on developing a Service Catalogue and how its abstraction from technology allows the delivery of a more efficient operation.

What’s in a Name?

Some people call it Service Catalogue or Product Catalogue, even storage tiers.  The name isn’t too important, however what’s essential is that the Service Catalogue should exhibit a number of key components:

• It should be abstracted from technology.
• It should provide service metrics – explaining what you get for your money.
• It should be able to scale up or down to meet customers requirements.
• It should provide charging information based on simple billable units.

Technology Abstraction

For those familiar with delivering IT, the concept of offering a service that is abstracted from the technology itself may seem a little confusing.  However, by continually referring to technology, organisations tie themselves into being able to offer only that technology itself as part of their service catalogue.  For example, if your “tier 1″ storage offering consists of 15K 300GB FC drives in an EMC DMX-4 array, then customers will expect you to deliver tier 1 storage from that kind of box.  What happens if EMC can offer a lower cost alternative through their latest technology like V-Max?  What happens if 300GB drives reach EOL?  What happens if another vendor (e.g. HP or Hitachi) can offer the equivalent technology at 20% reduction in cost?

By retaining a connection between the service offering and storage, IT providers restrict their ability to introduce new technology that can reduce cost and improve service.  If however, service tiers or product offerings are suitably abstracted from technology, then costs can be reduced by taking opportunities to (a) implement new, cheaper technology or features (b) implement a competitive environment with multiple vendors.

Of course, it’s easy to talk about bringing in cheaper technology, either by using newer, cheaper hardware or by bringing in a new vendor who is prepared to take a beating on price just to get into a new account.  The implications of this kind of disruption may negate the potential savings because existing processes or architectural design can’t cope with the change.  In many organisations the process for storage deployment is based around the hardware product, as is reporting and billing.  The clear message here is that it’s essential to ensure both the operational and engineering functions will work across multiple varied technologies.  The subject of new technology adopotion and integration will be the subject of a future post.

Comparison with Other Industries

As mentioned in previous posts, the concept of delivering Storage Services is typically compared to utility companies.  Consider our functional requirements for service in comparison to say, an Electricity or Phone company.

• It should be abstract from Technology. This rings true for the delivery of say, electricity to a domestic dwelling.  In the UK, everyone expects to receive 240V at 50Hz as a standard.  Changing to another supplier doesn’t require a change in electricity standard; the process of electricity generation doesn’t affect the end delivery, whether it is generated from wind, wave, nuclear or coal.
• It should provide service metrics. Whether explicitly written into a contract or not, I think most electricity users would expect their service to be available on a 24×7 basis.  In addition, the supply should be guaranteed to remain within certain tolerances – e.g. 240V±10% and 50Hz±1% for example.  Deviation outside of these standards would have a seriously adverse effect on equipment using the supply.
• It should scale. Unless you’re a commercial user, most electricity companies would expect to be able to increase and decrease their electricity consumption without consideration of how that supply was provided and without contacting the provider.  In fact in the UK the National Grid are responsible for monitoring demand and bringing supply in and out of use to match requirements.  This is all part of the service and therefore included in the cost of supply.
• It should consist of Billable Units. Check your electricity bill; you’ll find your charge is based on a price per kWh, a standard unit of measurement of power.  Your charges are directly related to your consumption and not to how the power was generated.  It’s worth noting that some providers will offer multiple tariffs, for example providing cheaper electricity at night or tying consumption into green issues.  These tariffs are analagous to storage tiers.

Building a Service Catalogue

How do you go about designing and implementing a storage catalogue?  Here are a few pointers:

• Look to include functional requirements (availability, response times).
• Look for cost & service differentiation.  Some organisations implement many different tiers of storage or product offerings.   Implementing multiple tiers can become expensive and if they’re not all utilsed efficiently, then the potential cost benefit is lost.  Implementing multiple tiers offers the ability to reduce costs by placing less active or less demanding data on cheaper resources.
• Look to drive behaviour; implement services that penalise lack of adherence to standards and so on, but reward forward planning and utilising forecasted resources.

A Basic Template

Here’s a generic example of delivering a service catalogue for Enterprise SAN Storage.  It keeps things simple by offering only three tiers;.  each can include extra features such as local or remote replication.

• Gold - Availability – 99.999%; Response time: <10ms on 99.9% of I/Os sampled over a 5 minute period. Connectivity – FC – $10/GB/Month
• Silver - Availability – 99.999%: reponse time <15ms on 99.9% of I/Os sampled over a 5 minute period – conncetiivty – FC – $5/GB/month
• Bronze – Availability 99.9%; reponse time < 20ms – connectivity = iSCSI – $2/GB/month

Additional “bolt-ons” for each tier include:

• Local replication. Add a local replica for an additional tier price per month (gold replica for $10/month)
• Remote replication. Add a remote replica for the cost of the replica plus 10% (e.g total cost per GB for gold is 22$/GB/month

Additional comments: Billing is based on average configured storage over the course of a calendar month, measured at 00:01 each day.  Totals are based on the storage used per server, rounded to the nearest GB.  Costs assume no more than 1 allocation/deallocation per server per month; additional requests will incur an additional configuration charge.  Costs do not include and host software or hardware required to connect to the storage.

Every organisation will have their own specific requirements that determine the best way to structure a storage catalogue.  In future posts, I’ll discuss more about the process of developing the catalogue, how it integrates with product selection and operational management.

© Chris for Gestalt IT, 2010. | Four Pillars – Service: The Service Catalogue
Read more posts categorized as Featured, Storage

This is a series of posts covering the subject of Storage Management.  In this post, I’ll be discussing one of the four foundations, Service and what exactly that means.

My Four Pillars of Storage Management are defined in this initial post. To recap, I define Service as:

“Offering of services to business customers via a service catalog and measuring the ability to deliver to the business through KPIs and Service Level Agreements.”

If you look back to the early days of computing, the computer department was almost a law unto itself.  Access to the mainframe and other resources was at the whim of the Systems Programmer, a bearded, sandal-wearing, social skill-lacking individual who might just do what you ask him when he was ready.  Ricky Gervais parodied this character perfectly in The Office; the IT expert within the office was also expert at everything else including karting (”Oi, no professionals….”).  By the way, before everyone starts flaming me – I was a Systems Programmer on mainframe for a few years at the start of my career, so I speak from personal experience.

Fortunately IT has matured and we’ve mostly moved on to a service-orientated method for delivering computing (and in this case storage) resources.  To effectively deliver storage resources within an organisation, it is essential to move to a service-based model where storage is provided as a service offering that is planned and managed, rather than simply on-demand.

The typical example that is always quoted is to compare computing resources to utility companies providing electricity, gas and water.  Personally, I prefer in some respects to look at the telecoms market for better examples, in particular mobile ‘phone companies.  What all of these companies have in common is that they offer you a service and then charge you for your consumption.  On a periodic basis you are provided with statements and payment is taken.  Most critically, you have no real knowledge of how the service is delivered, what underlying technology was used e.g. Gas, Nuclear, Green, Coal forms of electricity generation.  To a certain degree you have no need to care unless of course the company can see some market advantage from promoting their use of a certain technology (for example, energy companies offering “Green” tariffs).

So it should be with storage.  The delivery of storage resources should be thought of as providing a service.  Moving to that model requires thinking of the following components.

In subsequent posts, I’ll discuss more on the Service details and explore how to achieve setting up service-based storage delivery.

© Chris for Gestalt IT, 2010. | Four Pillars – Service
Read more posts categorized as Featured, Storage

You may have assumed from my previous post on VPLEX that I am negative towards the concept of storage federation.  That couldn’t be further from the truth.  In fact, ever since I was involved in deploying ESX onto enterprise storage infrastructure (some 4 years ago), I’ve been waiting for the day true federation would arrive.  Here’s why.

Static Configurations

Think back to the time before server virtualisation (yes, there was one).  Physically static servers failed over to other physically static servers located in remote data centres.  Once deployed, servers very rarely moved unless there were major physical data centre issues or an upgrade was being performed.  In fact, even when server upgrades occurred, it was typical to acquire a new server and rebuild the application and data on that new hardware to remove any issues with new server drivers, hardware firmware and so on.

Mobility Rules

Server Virtualisation changed all those restrictions.  By abstracting the hardware to generic devices it was possible to place a VMware host on shared storage and have any connected VMware server run that guest.  Very quickly the toolset of features improved to make that host movement transparent and as simple as clicking a button.  This meant servers could be accommodated on any hardware and scaled within the hypervisor.

Storage Restrictions

Unfortunately storage wasn’t so quick to keep up.  The static model of a single physical server in two locations worked well with storage replication technologies that required only one copy of the data to be active at any one time.  Moving an application to another data centre was typically a disaster recovery process and consequently a small outage was acceptable as the storage arrays “failed over” their LUNs to the remote location.  Once the DR issue was solved, the data could be “failed back’ to the original location.  It wasn’t usual to move servers between data centres as a standard operational process.

Virtual Machine environments weren’t well catered for.  Failover of replicated storage wasn’t a transparent process; there was a tradeoff between LUN size and the maximum number of LUNs a hypervisor could support; this made it more complex to architect a Virtual Machine environment with enterprise storage.  Even with vMotion on VMware, where a VM host could be moved transparently across physical hypervisor servers, the storage couldn’t be moved easily.  In fact, the storage restrictions were solved by implementing storage vMotion, rather than have the array achieve the data migration itself.

Step in Federation

This is where storage federation comes in.  It enables any and all copies of a LUN to be updated from multiple locations at the same time.  This means that both the hypervisor and the storage can be load balanced across multiple locations and physical hardware without having to bulk copy the data all the time.  Here’s a simple example to demonstrate the process.

Imagine a 1TB LUN on a storage array acting as a single datastore and supporting 20 production virtual machines.  In the “old” model, moving that LUN to another location would require impacting all 20 virtual machines and making another location the primary target of I/O operations.  There was no ability to go “sub-LUN” and to move individual machines to another location.  Storage vMotion could be used, but that would require replicating the entire VM to another LUN/datastore.  Any attempt to load balance the VM guests would be constrained by the time required to continually move data around the infrastructure.  In addition, moving a replicated VM from one LUN/datastore to another would mean compromsing DR until that LUN had been fully replicated to another location.

Now under a federated environment, that 1TB LUN would be updatable from any location, meaning individual VM hosts on the datastore could be updated from multiple locations at the same time.  This means there is a massive increase in the flexibility of managing workloads across physical locations, offering the ability to workload balance for business and operational benefits.

Summary

Ultimately, federated storage environments will be the future. Products like VPLEX are only the start.  The ultimate goal will mean workloads can be run anywhere, any time.  That will be cool.

© Chris for Gestalt IT, 2010. | Why Storage Federation Is What We Need
Read more posts categorized as Featured, Storage

Those of you with relatively good memories will remember last year’s announcement from Hitachi/HDS, which at the time promised more than it delivered.  In fact, the anagram posed by Claus Mikkelsen on his blog and used as part of the press release was “REGRADES OUR CLASSY TREATS” and should have translated to “STORAGE ARRAYS CLUSTERED”  my tongue-in-cheek alternative was “A DREARY STORAGE CLUSTER” (who could have imagined such a serendipidous alternative).  With EMC’s new release of VPLEX, it’s deja-vu all over again….

With the usual EMC fanfare, VPLEX has been heralded as “a new storage platform“.  For a product that appears to contain no storage at all (and in fact writes through to the underlying virtualised arrays before confirming I/O to the host), I can’t quite see how the claim stacks up.

Background

OK, before we dive further in, let’s just summarise what VPLEX appears to be about.  In a nutshell, VPLEX offers “federation”, this year’s buzzword for shared or virtualised storage.  The product is currently offered in two flavours; VPLEX-Local, which basically adds a virtualisation layer into the host->fabric->storage stack and VPLEX-Metro, which creates a clustered storage environment, pretty much like the Hitachi HAM (High Availability Manager), announced 12 months ago.  VPLEX-Local is also remarkably similar to IBM’s SVC (SAN Volume Controller).

The Hype Factor

Of course VPLEX is different, or at least that’s what we’re lead to believe.  From the documentation I’ve read, VPLEX-Local is nothing more than a cluster of SVC-like devices.  This functionality is already there in USP V and SVC.

VPLEX-Metro looks slightly different and starts to get interesting.  Multiple VPLEX clusters can be connected together, enabling I/O for a single LUN to be shared across the VPLEX-Metro complex.  Distances of up to 100 miles can be achieved, the only downside being latency overheads.  I’m not aware of SVC offering this kind of functionality, however that is exactly what Hitachi HAM was designed to do.

Catch-up and Future

With the Local and Metro offerings, VPLEX seems to be simply catching up with the opposition.  In true EMC style, however we are being tempted by two future offerings, VPLEX-Geo and VPLEX-Global.

VPLEX-Geo will offer asynchronous federation over a wider distance (presumably infinite, if you’re happy to cope with the latency).  Asynchronous changes offer the possibility for a world of pain for data integrity.  I suspect the first implementations will be tightly controlled using EMC’s own VMware operating system (ESX).  VPLEX-Geo is slated for 2011.

VPLEX-Global is an anything, anywhere offering.  Let’s reserve judgement on that one until we see it – there’s no dated roadmap other than after 2011.

Unanswered Questions

Here’s what I don’t know:

• Will VPLEX pose the same restrictions on the host multipathing as USP-HAM does? HAM requires HDLM.
• Does the host still have to manage their own cluster configuration? (I expect so).
• Is VPLEX-Metro really updating both data copies or is data just being shunted between the clusters, then replicated back again?

And finally, as quoted in the documentation, VMax will offer VPLEX functionality this year, so you may want to consider holding off on that rash VPLEX purchase if you’re on the cusp of moving to VMax.

Final, finally, what happened to InVista?

© Chris for Gestalt IT, 2010. | EMC VPLEX – A Dreary Storage Cluster?
Read more posts categorized as Storage