Pages

Thursday, February 18, 2010

Cost per $metric - Part 2

Previously, I discussed storage costs and that, while cost per usable GB is perfectly fine in capacity driven tiers, it has less use in IOPS constrained tiers.  There were a few aspects of storage costing that were not covered in that post.

First off, most arrays come with additional management software that is often licensed per TB threshold; you only incur additional license costs at certain points of capacity (20TB, then again at 40TB for example).  You would need to work with the vendor to ensure that these upgrades are rated into the flat cost per GB for it to be a true "total cost."

Similarly, Storagewonk (Xiotech) had a post discussing the sometimes prohibitive cost of the next TB after a customer has reached the capacity of the current array.  It is a very valid point.  Even with a good cost per GB pricing model, it is doubtful that it covers cost of the next array simply due to the substantial initial implementation costs and lack of guarantee of future growth.  Xiotech's spin on this is that since they're such a modular platform, the ramp up cost for additional footprints is substantially lower.  Since I have no idea what an ISE costs, I'm not going to comment on how much of an expense advantage this is (I assume that it is pretty substantial).  But it did get me thinking... what are other aspects can impact TCO and storage costs?  For some of these, I'll use Xiotech's ISE as an example since it really is a unique solution that demonstrates the necessity of thinking through the impacts of decisions.
  • Xiotech's ISEs are all attached to the FC fabric.  This could potentially increase the number of fabric ports that are used servicing array requests and should be accounted for - make sure to consider the density of the director blade that you use for storage ports.
  • If hosts need storage from 2 distinct ISEs, I assume that they'll need zoned to each ISE which increases administration time.
  • If a host is spanned across multiple ISEs, how does that affect replication?  Is there a method to guarantee consistency across the ISEs?
  • Many up-and-coming solutions leverage host-level software to accomplish what used to be handled at the array (compression, replication, etc).  How does that affect VMware consolidation ratios?  Does it affect IO latency?  Make sure that you understand the cost of placing yet-another-host-agent on SAN attached hosts.  David Merrill (HDS) goes into this a little more on his blog.
  • Similarly, are there any per-host costs (such as management or MPIO software) that affect a solution's TCO?
  • What does migration look if you have a lot of smaller footprint arrays to replace in 3-5 years?
Any good IT architect will look at the total impact of implementing new technology into the environment.  In a lot of cases (and I'd pick on Exchange on DAS here), short term cost savings can be quickly eroded by long-term sustainability issues... especially in shared environments.

No comments: