The Storage Economist

Given the expanse of this topic, I’ve broken it down into four parts. Today’s focus is on leveraging storage virtualization to reduce overall IT costs.

We see trends of activities and investments that can and will produce positive, short term savings. With the increase in company layoffs and negative earning reports that dominate the news, IT planners need a couple of short-term tactics to reduce storage costs in 2009. I will outline my top 4 observations. Several analyst papers substantiate my recommendations as well.

# 1 – Use virtualization technology to reduce the cost of migration

Here is the premise:

• Storage arrays have gotten much larger over the past few years
• Tech refresh is a function of depreciation schedules or lease arrangements
• Typically, it takes 4-8 months to migrate off an old array and move all the data to the new one
• Disruption in this process is not very popular
• With a ramp-up time of 2-4 months and a ramp-off-time of 4-6 months, the effective useful life of the asset is reduced by critical months, often 30% of the asset life
• Companies with 250+ TB of storage are very probably in a “constant state of migration”
• My conservative calculations have resulted in a $7-10K per-TB cost of array migration. This includes:
• The more often-than-not post warranty maintenance cost required on the old array
• Small army of people (internal staff or contractors) required to do the migrations
• Migration tools, devices
• Overtime, since much of this work is on weekends
• Power, space and cooling costs related to have 2 arrays side-by side for many months
• Your CFO will not be happy with a useful life of an asset in the 60-70% range

By the way, this $7-10K per TB is very conservative. I have meet several clients in Canada this month that tell me their rates are closer to $30K/TB.

My observation and recommendation is to consider storage virtualization as a method for array-based migration (often called remastering), even if you are not ready to make virtualization part of your core storage infrastructure, it needs to be considered as a way to deliver rapid migration capability. I often see customer results where migrations that once took 5-6 months get done now in a few weekends.

The cost of virtualization based migration is not free. An outage is required (can be scheduled as part of a maintenance window) to redirect the storage paths, there is HW and software, training and operational practices etc., but the savings of using this technology is very significant.

Clients that use virtualization (appliances) for migration come back and tell me that the cost-per-TB is sub-$1K. This is a very significant cost impact on an annual or monthly basis, not to mention you get a better ROA on your storage assets.

Here are some links to how HDS uses (diskless) USP V and USP VM to accomplish this task. Consider these devices as migration appliances if you are not ready to jump into this proven technology for your storage core.

Tweet

Posted in Uncategorized

Comments (3 )

Post Comment

Hi David, I’ve a couple of points to add to this - interested in your thoughts.

My experience of migrations is that looking at costs from a per-TB perspective is not all that helpful. Actually, the majority of the costs stem from host-end work and in particular, the effort involved in the following (not exhaustive) list:

Gaining effective sponsorship for migrations
Gathering information for interoperability reviews
Doing interoperability reviews
Developing upgrade ‘work-packages’ for hosts
Scheduling ‘upgrade’ work and downtime to upgrade software, drivers, firmware and hardware as per storage vendor interop. lists
Scheduling migration work and downtime to actually run the migration
Having host teams on-site to perform final switchover

The actual storage work then is a comparatively minor component of the overall costs:

Configuring migration appliances or software
Copying data
Re-zoning\cabling as part of scheduled migration work and downtime
De-commissioning legacy equipment

When I look at the effort involved in the migrations I’ve been a part of (and there have been many, sadly), there’s little question that the lion’s share of effort is expended per host, which makes per-host cost a much more useful metric than per-TB. The big benefit of virtualisation-based approaches to migration is that it can remove the need to employ host-based technologies such as volume manager mirroring and can hide a lot of the complexity of migration from the host. Ultimately though, the cost to migrate a host with 100Gb attached is likely to be identical to that of a host with 1TB attached (in either scenario). From an economics perspective within the broader IT department budget, it surely then makes more sense to think in terms of per-host costs.

It’s also important not to forget the organisational and process aspects of migration. For storage teams embarking on a migration project, one of the biggest challenges can be convincing other areas of IT of the need to invest their time in the migration. Further, in terms of ‘PR’, the downtime and inconvenience caused to application owners by a migration can be a greater ‘cost’ to the storage team than the all-in $ costs of technology and effort. The only way these impacts can be managed effectively is through good project management, senior management sponsorship and strong and effective governance - including, ideally, SLAs and OLAs to enable maintenance work like migrations.

Matt
You bring up good points and details related to the cost on the host side of migrations. Still, taking all these costs that you mention and adding in non-host costs….. taking this all in total, and then dividing by total TB is still a meaningful metric. The balance of costs can change from environment to environment, but managers and planners get a better perspective if we can reflect these costs as a fn of total capacity.

[...] of the 33 types of costs outlined in storage economics is the cost of migration, or the cost of remastering. Last week, colleagues in Australia asked me the difference between the [...]

Post a Comment