Swapping blade servers: What to do about vendor lock-in

Vendor lock-in leaves organizations with few options if they are unhappy with the performance of blade servers.

A lot of organizations initially choose to adopt blade servers because blades make it possible to cram a lot of computing power into a small amount of space at a relatively low cost. Like any other type of server however, blades do have their disadvantages. The primary disadvantage to using blade servers is vendor lock-in. Blade server chassis can only accommodate servers made by the same vendor who manufactured the chassis, leaving...

organizations with few options if those servers don’t perform as expected or computing needs change. Let’s look at the options available when yesterday’s blade server decision becomes tomorrow’s blade server headache.

Choosing a change
Obviously replacing server hardware is not a decision to be taken lightly. After all, you will probably end up having to explain why you got rid of “perfectly good” and relatively new hardware, as well as why the blade hardware was purchased in the first place. But there are perfectly valid situations in which server replacement may be justified. For instance, if your blade servers are constantly failing and the vendor cannot correct the issue then it may be time to switch servers. Likewise, if the vendor suddenly decides to phase out and stop supporting the line of blade servers that you have purchased then you might be wise to invest in something else.

Since an organization can’t simply fill a chassis made by one vendor with server hardware made by another, it is worth considering what it would take for an organization to abandon the investment that it has made in a vendor’s hardware so it can use blade servers from another vendor. Keep in mind that even when switching platforms, vendor lock-in is still a concern when choosing blade servers–you’re just taking a chance on another vendor.

Obviously, one of the biggest considerations is cost. Most organizations aren’t willing to abandon their investment just so that they can go with another vendor. So what is an organization to do if they are not happy with their blade server platform?

Consider the importance of switching vendors
Before you even begin shopping for another vendor, it is important to carefully consider your reason for switching vendors and to think about whether or not that reason is sufficient to justify the cost of the switch. If the hardware is unreliable and the vendor has not been able to correct the problem to your satisfaction, then you may be better off going ahead and investing another vendor’s hardware. On the other hand, if the hardware isn’t as fast as you might like or if it doesn’t play well with your management software, then you might be able to avoid completely abandoning the hardware. Ultimately, the best “business decision” might be to work around problems for a time until you can make a solid case for switching vendors.

Consider a less important workload
If you determine that the problem driving the organization to consider a different vendor is not critical, then you may be able to gradually phase out your blades. The idea is to go ahead and purchase a new blade chassis (or even a rack) and a minimal number of servers from a new vendor. It’s important to note that the choice of new blades versus a new rack will depend on your specific computing needs. For this discussion, either choice would be appropriate. After deploying some new hardware, you can move your most critical workloads to the new hardware while continuing to run less important workloads on your old hardware. Over time, you can gradually add blades (or rack servers if that’s your choice) until you eventually get everything moved over.

Wait for natural obsolescence
Another option for dealing with non-critical blade server issues is to wait for your existing blades to become obsolete. Servers generally only have a useful life of three to five years (although high-end servers may have a longer life). As such, a prudent option may be to gradually replace server hardware with hardware from a different vendor as aging servers become obsolete. In effect, the swap would be handled as part of the regular technology refresh cycle. The older blades could be reallocated to test and development or other non-production tasks in the enterprise.

Don’t forget about logistical issues
If you do decide to go ahead and replace your blade servers, there are a number of logistical issues that must be taken into account. One such consideration is what to do with your old hardware. You could sell the old servers, but it would be inadvisable to include the server’s hard drives in the sale. Since there are ways of recovering data from a hard drive that has been blanked, you are better off destroying unwanted hard drives rather than selling them.

An equally important consideration is server uptime. Regardless of whether the servers you are replacing are subject to a binding service level agreement, you probably can’t get away with taking the existing blade servers down at will. As such, you will have to plan for how you will migrate each workload from the old blades to new blade or rack hardware with a minimal amount of disruption.

Virtualization can certainly help streamline the workload migration process, but easy migration can often lead to oversubscribed servers. Technologies, such as vMotion and Hyper-V’s Live Migration, have made it possible to move a virtual machine (VM) from one host to another with no downtime. However, you must make sure that your virtualization infrastructure does not become oversubscribed in the process. Advance planning is an essential part of such hardware platform migration.

For example, I recently spoke to someone who wanted to add more powerful hardware to a virtualization infrastructure. The plan was to make the new server a member of the existing Hyper-V cluster and then move VMs to the new hardware. However, the cluster already contained the maximum number of nodes, so this approach could not be used. Instead, the administrator had to move all of the VMs off the node being replaced and onto the remaining nodes, remove the empty node from the cluster, replace it with the new server, and then move the virtual machines to the new hardware. Although this technique worked, it put a tremendous strain on each node in the cluster because the nodes had to temporarily host more VMs than they normally would.

Another thing to watch out for is architectural differences. Some virtualization platforms won’t allow you to use servers with dissimilar CPUs (such as a mixture of CPUs from Intel Corp. and Advanced Micro Devices Inc.) within a cluster. This will impact the server choices – particularly if the existing servers less established processors.

It takes a rather extreme set of circumstances to justify the complete abandonment of server hardware. In most cases, bringing in hardware from another vendor is likely to be a gradual process. In either case however, it is important to plan for the migration to the new hardware before you actually go shopping. Finally, remember that if you use blade servers, then vendor lock-in will always be an issue. If that concerns you, then you might consider rack servers or tower servers instead.

About the author: Brien Posey is a seven-time Microsoft MVP with two decades of IT experience. During that time, Posey published thousands of articles and wrote or contributed to dozens of IT books. Prior to becoming a freelance writer, Posey served as chief information officer for a national chain of hospitals and healthcare facilities. He also worked as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.

This was first published in December 2011

Dig deeper on Blade servers

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseLinux

SearchServerVirtualization

SearchCloudComputing

Close