The shifting SANs of enterprise IT: You may have been burned in the past, but live migration is and will be your friend

Comment If you mention Storage Area Network and Logical Unit Numbers to IT professionals of a certain vintage, you are likely to encounter eye rolling and invective. The least unprintable of the epithets you'll hear may include "outdated," "pain to manage," and "an impediment to getting real work done."

Are they, though? SANs are often the storage infrastructure underpinning critical business applications. You'll find them serving data to e-commerce web apps, accounting software, CRM systems, and other vital tools. SANs are flexible, resilient, and clearly not disappearing any time soon, so why do some IT practitioners loathe them?

Individual explanations will vary, but outside of gripes about management software, a lot of SAN pain is, dollars to donuts, related to a bad migration experience in the past. A study [PDF] published in 2010 claimed that data migration expenses at the time amounted to, on average, 200 per cent of the original storage acquisition cost, according to organizations surveyed anyway.

A lot has changed in the almost decade since. With that in mind, allow us to give you a gentle overview of today's tech to help you avoid similar nightmares in future.

Enter Logical Unit Numbers

Meet Logical Units, a hidden building block of your organisation's data architecture. Most IT chiefs are probably unfamiliar with Logical Units, so they may want to think of them as virtual hard disks that are assigned to servers, clusters, or individual workloads by specifying – we got there, eventually – a Logical Unit Number (LUN). When IT pros talk about LUNs they are not just talking about this number, they also referring to the Logical Unit assigned to the number.

LUNs offer block storage so operating systems consume LUNs in a way akin to how they consume Direct Attached Storage: LUNs are formatted, and a file system installed. An enterprise storage array might consist of thousands or tens of thousands of LUNs, so ease of use becomes a vital consideration in selecting LUN management tools, to put it mildly.

Now, no enterprise wants to endure the cost and effort or a storage migration. Historically, this involved IT staff waiting until after business hours, backing up the old array, and performing a restoration from the backup on the new array. During this process, servers and applications were unavailable and – to the outside world – your business stopped operating. You can’t do that now, and, thankfully, today's arrays can do live LUN migration. The really good ones combine scalability with live LUN migration to create a sort of "perpetual storage system." Each vendor has their own nomenclature, though the basic premise is that when you need more, or faster, storage, you add it. When older array hardware is out of support, or no longer economical to operate, you remove it. All data is live migrated between physical arrays in the pool so that apps never have to be taken down.

Live migration meets devops

Live migration has some additional side benefits, the most important being you can keep extend the life of your existing arrays. It lets you add new arrays to the pool, move demanding workloads to the new array, and allows your colder data to occupy the older arrays. How far you can go with live LUN migration is vendor dependent.

The other major benefit live LUN migration gives us is "agility." Don't make that face: it's a word you can't avoid in these days of devops and automation. In today’s world, cloud-native apps can be created and destroyed at will, though even these animals tend to have some form of persistent storage that gets passed from instance to instance. Container after container is recycled every time new code is pushed to production, though the data persists.

That data can be needed anywhere that the next instance of a container is created. And I mean anywhere. Container instantiation can be on-premises, or in any of the public clouds, or in a colocation, or an edge data center, or what-have-you. A single container may experience a demand spike and shard into a thousand copies, with its data cloned, all thanks to the lovely API goodness of modern SANs.

Take a storage pool with multiple generations of storage, throw in automation, and suddenly you can move workloads between different tiers of storage based on whatever triggers or criteria you define. If you can move workloads to capacity arrays when they aren't under load, for example, you'll save money by buying fewer performance arrays.

Reach in the cloud

SANs are increasingly able to replicate between sites, and across metro-area distances you can even build stretch clusters that span multiple data centers. If you can move (or at least clone) workloads between sites, or clouds, or what-have-you, then your one workload can become thousands, all around the world, in exactly as much time as it takes to transmit the underlying storage data, or at least the last update to the image. This isn't pie-in-the-sky thinking, as SAN vendors are gaining ground in the cloud era.

This is important because it’s been clear for some time that while a great deal of new application development would be done in and for the cloud, producing so-called “cloud native” apps, on-premises data centers will continue to exist. This is changing, but much more slowly than was predicted a few years ago.

Far from the public cloud massacring on-premises data centers, the transition from on- to off-premises has been gradual, and largely tied to changes in who owns the IT budget within organizations. IDC puts the split between Line Of Business (LOB) IT spend, which is predominantly public-cloud based, and spend by traditional IT departments, which is predominantly on-premises, at about 50/50.

Not only will public cloud and on-premises continue to exist side by side, but the definition of each will become nebulous. Colocation is sort of "on-premises" while also sort of being "in the cloud." Amazon Outposts, Azure Stack, and so forth, will put the public cloud in your data center.

That means enterprise computing is getting messy. Which is where SANs – and LUNs – come in. Love them or hate them, SANs just work. With the right management software, SANs provide storage to bare-metal servers, virtual machines, and containers, and they can do this on-premises or in the public cloud.

As organisations continue welding blobs of data center infrastructure, from on-prem servers and clouds, together, SANs – and the live migration of LUNs – will persist and even thrive. SANs provide storage to the messy middle of IT. They are the workhorses of your organization's information storage. ®