Healthy servers are essential for smooth data center operations. But if you just install the hardware and let it run, you'll eventually face downtime or poor processing performance.
It can be tricky to determine when to upgrade a server, how long you want it in your data center, if it just needs troubleshooting or if it's time to completely replace it. These tips will help you develop a server lifecycle management strategy and become a preventative upkeep pro.
How often should I update server hardware?
Server health is divided into two main categories: hardware and software. These components can follow varying update cycles, and maintenance is especially time-consuming when you're dealing with a whole data center worth of resources.
Regardless of when you do server maintenance, it should be preventative in nature, instead of just doing it when something goes awry. If you're not sure how often you should run maintenance on server hardware, use its age as a guide. Older components should have more regular upkeep to remain compliant and functional.
From the software side, establish a regular update schedule. This allows you to notify users of downtime or to reallocate resources to available processing hardware. Be sure to read any software documentation to decide how major an update is and what support you need. Most vendors have at least one big update per year, so that should be your baseline for number of updates.
What's the life span of a server?
The average life span of a server is three to five years. Of course, this can be changed with upgrades and extended support. If you decide to refresh your hardware with midlife updates, first take a look at the processing and storage components.
These components are usually hot-swappable and are a quick way to expand resources. You can fill any empty dual in-line memory module (DIMM) slots with larger-capacity modules. When you perform server maintenance, be sure you match up DIMM types so you don't run into issues with processing speeds and memory performance.
Another option is to upgrade networking hardware, such as switches and adapters. This helps your servers support newer bandwidths and data transfer standards, and it ensures you don't have a growing gap between network speed and hardware performance when your organization adopts new options, such as 40 Gigabit Ethernet or 32 Gb Fibre Channel for improved server-to-server communication.
Is there protocol for hardware disposal?
There are a few hardware disposal steps to take if you want to avoid any legal troubles or reduce security measures. The top thing to do before you move any of your servers is backup. Depending on why you're getting rid of the hardware, you can back up to free memory resources or the cloud. A benefit of using server lifecycle management is it can help you determine when to start the decommissioning process.
After you securely back up and transfer your data, create a checklist to track all assets. Doing so helps you avoid accidental disposal or mishandling any data. Once you identify all the hardware and confirm all possible users, be sure to disable network and user permissions.
After everything is tracked and ready to go, use software to scrub the hardware and then physically dispose of it. If your organization doesn't have the resources or wants to properly dispose of computing components due to environmental concerns, you can use a third-party service to haul any old servers away.
What do I do for basic web server troubleshooting?
The first step is to check all of the physical connections. For a quick root cause analysis, you should look for any power outage notifications, connectivity issues, available management capabilities or large data imports.
Next, run the ping command on the LAN and see if that turns up any results. If it's a virtual server, ping the IP address, as well. If this doesn't work and you've confirmed a network connection, there are a few more avenues to pursue. Double-check that your network is DHCP-enabled and that the downed server is attached to the right DNS server.
If none of these options work, go through log entries to see if there are other incidents around the time of server failure. If you're sure the network is not the issue, you can also run a Wireshark capture to help any further troubleshooting.