Hold fire on the euthanasia
If you decided to make the move to a hybrid world because some of the gear was creaking badly and ready to be taken on a one-way trip to the technology vet, you can simply call in the recycling company and shove it in a van (you did book the secure destruction service for the disks and router flash cards, didn’t you?). But even if some of the stuff is getting on a bit, that doesn’t mean it’s completely useless.
There are two downsides with legacy storage – it takes power, and it’s slow. But that’s not the end of the world. It’s free (you probably depreciated it a while back) and you’ll have to pay to have it securely destroyed, so why not see if you can inject a bit of life into it?
Cloud providers such as Amazon have tiered storage offerings for a reason. People want to be able to choose more than one option of cost against speed. Amazon’s slow Glacier storage costs less than a fifth per gigabyte than its standard S3 storage, which is perfect if you’re not using it a great deal and don’t need mega response.
So why not take the same approach for reusing the old storage you just made redundant? You can offload work to your legacy disks from your faster storage and let the latter get on with its high-performance tasks. You could even decide that now you have several terabytes of slow storage, it’s time to throw away the old tape backup system and move to disk-to-disk.
Given that your servers became obsolete just as you headed to the pub post-install, it would be easy to assume that they’re no good any more. But that’s not necessarily the case – particularly in these days of virtualization. Four old machines in a VMware ESXi cluster may serve you just as well as two new ones, and who is to say you shouldn’t just run the old kit up to host virtual servers supporting development, test or staging systems.
I’ve been surprised over the years at how many companies don’t have test or staging platforms to offset the risk of deploying new and upgraded applications. The reasons are generally the same: it’s usually money, but very occasionally it’s a lack of space or available power.
But as with the legacy storage this kit is free, probably neglected by the beancounters, and already housed in your premises – so none of these constraints exist. Add to this the fact that you can make a very convincing job of cloning your production machines – even doing physical-to-virtual transformations if they’re on non-virtualized tin – and running convincing, valid test environments on a hypervisor platform. OK, you will have some differences (the virtual LAN adaptors will need different drivers, for instance) but in most cases the approach will be viable and you’ll have a convincing virtual world.
Oh, and don’t be afraid – ironically – to consider system upgrades on these disused boxes. Older kit generally means cheap, commoditised RAM and perhaps even inexpensive expansion CPUs – so you can breathe even more life into a middle-aged server cluster for the sake of a few hundred quid.
It’s not uncommon to have legacy network hardware as well, and so you can look to reuse what you have. You may just have one socking big chassis-based switch (or maybe a redundant pair) in which case there may not be anything you can do. But if you have separate stackables there may well be something you can do.
The usual one is to reuse spare equipment – particularly if it’s very old and not even up to carrying Gigabit Ethernet connections – for the dedicated management LAN that connects the lights-out adaptors in your servers and the management ports in your network devices.
But if it’s Gigabit-capable you can think about using it for dedicated Ethernet SAN traffic, or as the carrier for a dedicated LAN for backup streams. Even relatively old network kit may well be Gigabit-equipped and capable of trunking multiple interconnects via LACP or EtherChannel, and you can even run it up without disturbing the karma of the production switch because the only changes you’re making are to the old devices.
But don’t forget
A note of caution: some things aren’t free and plentiful with legacy equipment.
Longevity is one limitation. As stuff gets older, it dies more – so do your homework on the ongoing availability of spares. Also its operating software starts to rust: just as I can’t run the latest operating system on my first-edition iPad, similarly you may not be able to run the most recent versions of firmware on your legacy switches and routers through lack of compatibility. This may be an issue regarding your patching and update policy – though of course with due consideration it may be perfectly acceptable to take on the risk by, say, confining it to the test network.
But the easy one to forget is software licensing. When you’re running up new virtual servers and spanky new test versions of your apps you must be cautious about licensing, particularly if some of the application licences you used previously are now languishing in the cloud element of your hybrid infrastructure.
Make it feel loved
As you’ve just gained a bunch of value on your legacy equipment, spend a bit of time on it when you reuse it. Reformat everything. Flash every last bit of firmware up to the latest compatible version. Reinstall the operating system from scratch (which is a breeze anyway if you’ve gone virtual and templated it).
Reinstall the apps from the ground up where it is practical to do so. Make it comply with all the corporate policies (patching, security, log analysis and the like) because it’s still part of the family. And don’t get tempted to start shuffling it around in racks: if a properly packed six-month-old switch can die in a five-mile trip across Munich in my car, I don’t fancy the chances for your five-year-old storage array as you cart it over a tiled data centre floor on a square-wheeled trolley.
Oh, and… when you’re recabling it, use fresh patch cords. Reusing five-year-old network string is a flogging offence. ®