Technology terms get dropped into conversations in the storage industry, with perhaps little explanation of where they come from. Forklift Upgrade is one example.  What does it mean and what’s the context behind it?

Legacy Storage

If you look back 10-15 years ago, the process of replacing storage was pretty arduous.  Although Fibre Channel as a platform is good, it hard-codes a link between the host HBA (host bus adaptor) and the virtual LUN on a storage array.  Fibre Channel storage devices have physical addresses akin to MAC addresses, so when a relationship between a host and logical LUN is established, the definition is enforced at the hardware level.  Similar issues exist for IP-based storage networking.

Moving a LUN to another storage array is tricky.  Either the array has to manage the process by replication or the host has to do the data movement.  If the array moves the data, the host needs to know where the new LUN is and how to get to it.  The result is potentially a small interruption to operations.  If the host moves the data, the process is slightly easier, although some kind of volume manager helps at the host level.  Boot disks represent a nightmare to move if they’re on a SAN.  Anyway, that’s a discussion for another time.

Virtualisation

Server virtualisation was a godsend for data mobility, in particular features like vMotion on VMware vSphere.  Now, the LUN associated with a virtual host simply becomes a file on an NFS share or LUN formatted with VMFS (VMware’s Virtual Machine File System).  The application/guest and volume relationship is managed by the hypervisor, not the storage.  The storage becomes a pool of resource onto which VMs can be created.  With vMotion (and in particular storage vMotion), virtual machines can be moved between pools of storage across multiple hardware platforms without taking the application down.

Abstraction

Virtualisation was great and broke the abstraction for LUN-based applications, but what about object and file?  File storage has always proved tricky to migrate because users hard-code IP addresses and DNS names into other content (e.g. embedding into Word or Excel documents).  Outside of this, the challenge is to move data and preserve file-based permissions.  Object storage has similar challenges because the access point is simply an IP address or DNS name.  Both file and object can be abstracted and the endpoint obfuscated to remove the physical dependency.

Forklift

How does this get us further with the “forklift” discussion?  The term “forklift upgrade” refers to the cumbersome process of moving data from one storage array to another.  Historically the migration process was time consuming and expensive, with lots of dependencies if applications used features like snapshots and remote replication.  Whole projects were dedicated to the swapping of one array out for another and the timescales could run into months of work.  Avoiding the forklift upgrade is desirable because it removes risk, reduces cost and simplifies operations.

Avoidance

How can forklift upgrades be avoided?  Abstraction is one option, using techniques like server virtualisation.  Some scale-out solutions, especially SDS ones, allow new hardware/storage to be added to a configuration and old resources to be removed without lots of manual intervention.  For file and object, building an infrastructure that abstracts the endpoint away from the user will allow migrations to be done more easily.

With block-based storage, some vendors like Pure Storage and NetApp, offer controller replacements without replacing the back-end disks.  This is one way of resolving capacity problems with controller performance when the disks themselves are not the problem.

The Architect’s View

Avoiding forklift upgrades is a good thing.  Where possible, infrastructure should be designed to abstract from the hardware itself.  Bear in mind that cloud service providers rarely mention having outages to move data.  If they can do it, shouldn’t the same be done on-premises too?

Comments are always welcome; please read our Comments Policy.  If you have any related links of interest, please feel free to add them as a comment for consideration.  

Copyright (c) 2007-2018 – Post #AAE5 – Chris M Evans, first published on https://blog.architecting.it, do not reproduce without permission. 

Written by Chris Evans