Knowing how and when to replace data center hardware keeps business operations optimized. Read tips on how to establish an appropriate data center refresh cycle.
One of the oddities of working in technology is the obsolescence factor and how systems that were once top of the line and prohibitively expensive can devalue to the point you can’t give them away. Case in point: Servers which can cost tens of thousands of dollars and over time become nearly worthless due to age, mechanical difficulties and evolving hardware capacities.
Technology aging can happen rapidly, as evidenced by the fact many companies have on average a 3- to 5-year refresh cycle. However, it’s not enough.
SEE: How to become a network administrator: A cheat sheet (TechRepublic)
A Forrester Consulting report released by Dell last year found that “servers are not being refreshed quickly enough. On average, 40% of server hardware deployed at company data centers is more than three years old. Companies are adding storage capacity to support emerging workloads, but they retain aging hardware for four years on average, which is longer than ideal.”
Furthermore, the report said that delayed data refreshes result in, “a lack of agility and unmet business needs” and points out the “greater reliability, performance, speed, and scalability,” which new hardware can bring.
It’s important to streamline business operations by sticking to a sensible hardware refresh cycle. Every server has a finite lifespan, but it can be a challenge to determine how long that lifespan should be or recognizing when it is nearing its end. Here are ten tips to help you sort out the data center equipment upgrade process.
1. Establish current hardware specs and performance statistics
I’m assuming you have an existing set of systems in a data center performing various functions based on your company operations. Ensure you have all the current specs and performance statistics so you know how well these machines are running.
Are there some that are performing nearly at capacity? Those would probably rank high on the list for replacement (assuming you can’t reduce the workload on the boxes by removing unnecessary products or services, or redirecting these elsewhere).
Are there systems that are running fine with plenty of resources? Those would likely be low on the list for replacement unless the support or hardware was nearing the end of its life.
2. Establish and update business and user needs
Analyze your current systems and the associated business and user needs. Maybe they need file storage, collaboration software, virtualization hypervisors, alerting systems, and so forth. The needs for each should be fairly straightforward; 3 Tb of data storage for files, for instance, or a 200-user license for collaboration products.
Check to see if those needs have evolved (or perhaps decreased) before planning hardware and equipment replacements. Perhaps you now need 10 Tb of space for files, or perhaps that development server doesn’t need to be running or replaced.
3. Explore alternate options
Rather than just blindly upgrading all hardware and equipment, consider whether alternative options are available that might help cut costs and improve functionality. Ask questions such as these to determine the best path forward:
- Can you use a cloud provider or a hosting service?
- Can you use virtualization?
- Can you split redundant servers to have one onsite, and one in the cloud or hosted?
- Can you consolidate services onto fewer (or a single or pair of) systems?
- Would leasing or renting new hardware prove more economical than buying it?
Once you’ve got a handle on your environment, the involved requirements and possible alternatives to hardware upgrades you can start the actual planning process for the upgrade.
SEE: 63% of organizations face security breaches due to hardware vulnerabilities (TechRepublic)
4. Look at performance and functionality benefits
The primary reason for refreshing server hardware (other than because it is approaching end of life) should be to take advantage of increased performance and functionality. The ability to leverage scalability to improve available resources is also a key motivation here.
Focus on ensuring the data you gathered in Step 2 (business and user needs) applies here as you select replacement hardware so it will continue to meet those needs, with as much extra capacity as is feasible for your environment.
On the flip side, don’t waste money on unnecessary upgrades to turn low-level servers into high-end systems if they don’t require the additional performance or functions offered.
5. Consider infrastructural costs
Infrastructural costs–and the savings involved–can play a significant role when considering a server refresh project.
New systems might be more energy efficient, take up less space and require fewer repairs, for example, and this all factors into budgets and the investments pertaining thereto.
Analyze where the savings might apply and figure out how those can affect the project, such as better ROI to recoup some of the costs with a lowered electric bill, for instance.
Also, I would group support contracts under this category. Not every server needs a support contract; only the critical systems. I’ve worked for companies that opted against ANY support contracts period, as they were considered too expensive, and so they just chose to keep spare hardware components on hand. These organizations also leveraged solutions to quickly rebuild servers, such as utilizing kickstarting for Linux/images for Windows along with configuration management tools.
6. Consider repurposing retired servers
You don’t necessarily have to just drop your old equipment off at a recycling center (if you do, make sure to securely erase the hard drives first) and eat any potential value remaining in them. One element that can facilitate a data center hardware refresh endeavor is the ability to repurpose servers for other functions. In other words, execute a “hand me down” strategy where Server A is replaced with a new system and then becomes Server B after being rebuilt as such.
Of course, going to extremes so that Server A becomes Server B which becomes Server C which becomes Server D (and so forth) can be a convoluted and time-consuming process which backfires under the illusion of saving vast sums of money. Because after all, it’s important to…
7. Consider labor costs
The time your IT staff will spend on this refresh project should also be factored in when determining the projected costs. Let’s say it will take four weeks; that’s four weeks salary for each person involved. It also means four weeks of their lack of availability to handle other tasks, which might negatively impact company operations.
On the flip side, you should not only factor in the time spent on the proposed upgrades but also how staff will benefit by saving time not having to troubleshoot and support the old systems if they were prone to performance or operational problems.
SEE: Rural America an ideal fit for data centers (TechRepublic)
8. Ensure consistency across the board
I recommend vendor consistency to avoid an assortment of different systems with different support contracts and different components, drivers, etc. You should also map specific types of servers to a standard data center hardware footprint.
For instance, if you have ten application servers, ensure they receive the same specs (16 Gb RAM, 100 Gb hard drive, four quad-core CPUs, etc). If using database servers, set them all up either with local or SAN-based storage (don’t mix and match, if possible).
Keeping your replacement systems as predictable and standardized as possible will help to ensure uniform operations and streamline the maintenance/troubleshooting/replacement process.
9. Focus on standalone servers first
It may sound backward, but redundant servers, which are often used for critical functions, are less likely to produce a service failure seeing as how there are multiple instances of them. Replace standalone servers first (especially if teetering on the edge of mechanical failure) then move onto the redundant clusters or groups.
Of course, making sure to properly switch all functionality and processing from the servers to be decommissioned first to the remaining active systems should be carefully mapped out and executed properly.
10. Implement an orderly upgrade process
Where possible, upgrade from the direction of least critical to most critical servers. This will allow you to test everything first, back out any changes gone awry, and involve the least potentially negative impact upon business operations. Don’t forget to establish performance baselines as you implement new systems to know what to expect from them going forward.