Eliminating the Forklift Upgrade
Welcome to part two in the Why Scale Matters blog series. In my previous post (click here to catch-up), I shared some enlightening statistics showing why customers chose SolidFire all-flash storage for their production environment versus all other all-flash vendors in the market. Our ability to scale out beat out all other features and capabilities. So now let’s explore one of the many conundrums storage administrators face every three to five years: the forklift upgrade.
To help set the stage, we start by dissecting the term forklift upgrade. The folks over at TechTarget (a great source of IT technology insight, I might add) have a great explanation for this term:
“A forklift upgrade often involves ripping out and replacing outdated technologies. The term forklift upgrade has its roots in the early days of computing, when mainframe computers and public branch exchange (PBX) telecommunication switchboards were so big and heavy that it literally took a forklift to move them when they needed to be replaced.”
The article goes on to say: “The term forklift upgrade often has a negative connotation; projects that involve incremental improvements are usually less disruptive and less expensive than rip-and-replace projects, so most administrators try to avoid forklift upgrades whenever possible.”
So, naturally, I could not help but provide a visual example of this process to really drive the concept home.
Now where does this come into play in this day and age? Since I am a fan of scenarios, let’s explore a common one that occurs regularly in the data center.
It’s been three semi-good years with your current storage array. There was a short period where it ran low on space, so you added another disk shelf to the system but other than that, nothing major.
Now at the end of year three, the storage vendor drops in to update you on the latest version of your array. Version 2.0 has all the bells and whistles, along with advertising improved performance. So based on the needs of the business, you fork out a chunk of change for Version 2.0.
It’s install day, and Version 2.0 arrives on pallet. The vendor consultants get to work installing the new system. You’ve planned for this; you alerted the ops and applications teams that a new storage system is going in during the maintenance window so there should be no surprises. Once the system is in, the process of configuring volumes and adding hosts begins.
After a few days, the new storage system is online, but now … how do you move the data?
Solving for a harsh storage reality
Moving from one controller-based storage system to a new generation one after a three to five year service cycle is the bane of a storage administrator’s existence. It can often take six months or more of planning, testing, and execution to complete, along with application downtime. As environments get larger and larger, the cost and time required continues to increase.
By utilizing a scale-out architecture that allows mixing of hardware generations, such as SolidFire, hardware upgrades become a trivial process. For the scenario above, a SolidFire customer would simply add new generation nodes to the existing cluster, and remove the old ones.
There’s no data migration, no detailed coordinated planning with ops and application owners, and no giving up your weekends because there is no downtime. Once you’re done, put the old nodes in a lab, resell, or recycle them, and get back to productive work.
The ability to mix generations also means you can add in new storage nodes that offer higher capacity and performance (and lower cost) as you grow, rather than being stuck with old technology for three to five years.
I hope this scenario has opened your eyes to what is truly possible when you select the right storage platform. As always, if you want to find out more about SolidFire’s scale-out storage visit http://www.solidfire.com/storage-system/scale-out/.
Stay tuned for part three in this series, where I’ll cover the value of storage reshaping.
| 0 comments
Posted in Next Generation Data Center.