Servers optimize

10 things to remember when upgrading servers

You can avoid problems and gain peak efficiencies by following certain practices when upgrading a server. Erik Eckel offers this field-tested list.

Servers are almost always deployed, at least initially, with specific objectives in mind. Regardless of whether the server is deployed in a small business or large enterprise, frequently the server's role changes over time. Due to growth, budget cuts, rack limitations, or other factors, servers deployed for one purpose must often begin fulfilling additional services and responsibilities.

That's why it's important to periodically audit systems. Reviewing a server's resource load helps ensure the organization optimizes performance and prevents downtime. However, system administrators can't just break a case and drop in more RAM here or upgrade disks there. Server upgrades always require planning. Here are 10 things to remember when upgrading servers to ensure systems perform at peak efficiencies.

Note: This article is also available as a PDF download.

1: Always start with a verified data backup

Never make any changes to a server, even minor upgrades, before confirming a verified data backup exists. Whenever a server is powered down, there is no guarantee the server will come back online. While rare, I've seen servers that were shut down simply to install Windows performance and security patches fail to restart.

2: Consider creating an image backup

Several manufacturers offer IT professionals disk cloning technologies that simplify recovering servers when failures occur. Some, including Acronis Inc. and StorageCraft Technology Corp., provide a universal restore option that enables recovering a failed server even to a different bare metal chassis. Downtime is drastically reduced. When upgrades go south, disk images can help recover not only data but a server's complex configuration in a hurry.

3:    Don't make multiple simultaneous changes

Most every IT professional understands the importance of minimizing server restarts, so novices are tempted to complete multiple simultaneous upgrades using a single shutdown. But adding disks, replacing memory, installing additional cards, and other tasks should all be performed separately. Why? When things go wrong a day or two later, the process of isolating the change responsible for the error is exponentially more difficult when multiple simultaneous changes were made. If only a single change is introduced, it's much easier to track the potential culprit.

4: Monitor logs closely after making changes

Following server upgrades, never assume all is well just because the server booted back into its OS without displaying errors. Monitor log files, error reports, backup operations, and other critical events more closely than ever. Leverage Windows' internal performance reports or third-party monitoring utilities, such as those from GFI Software's HoundDog or Quest Software's PacketTrap, to ensure all is performing as intended whenever changes or upgrades are completed.

5: Confirm the OS

It's easy to forget the operating system a server is running. This is especially true when a server room isn't standardized and multiple boxes sport a collection of operating systems. Even veteran administrators, caught within the whirlwind confusion that marks many enterprise IS departments' days, have tried installing 8GB of RAM on a 32-bit Windows Server 2003 machine. Only by first performing a quick audit (including a quick 32-bit versus 64-bit check) of the system to be upgraded can you confirm the OS is compatible and will be able to use the additional RAM (or other resources) being installed.

6: Confirm the chassis supports the upgrade

Server hardware is famously inconsistent. Manufacturers frequently change model numbers and product configurations. Whenever installing additional disk controllers, disks, memory, or other components, you can review the manufacturer's technical specifications online before ordering upgrades. But only by opening the case can you be 100% confident that the actual server deployed within the organization will accommodate the upgrade.

7: Don't assume plug-and-play

Whenever installing new hardware, don't assume the device will plug-and-play well with the server's operating system (even if the manufacturer states the component is compatible). Before you order upgrades, perform a Google search to learn the experiences other technology professionals encountered when deploying that same component using the same OS. Since the upgrade is being completed on a server, confirm the component is listed on the OS vendor's hardware compatibility list. It doesn't hurt to check the server manufacturer's forums, too, to learn of issues other techs encountered when installing the same device on the same server.

8: Optimize performance

Be sure to follow up on any upgrades requiring associated software adjustments. For example, just adding memory to Windows servers doesn't automatically optimize Windows' performance using the additional RAM. System administrators must also update a server's virtual memory settings to optimize Windows' operation following a memory upgrade. Further, when new disks are introduced, the page file may need to be moved to the new disk to gain performance advantages.

9: You get what you pay for

Certainly, less expensive disks, RAM, power supplies, and other components are always available. But when it comes to servers, it doesn't pay to cut corners. Only high quality, high availability components should be deployed in servers. While these items may cost marginally more than other (lesser quality) alternatives, the performance and uptime benefits more than offset the additional expense.

10: Document changes

Surely you're maintaining log files for each server. Within the documentation for the server just upgraded, update the documentation to note the component that was upgraded, the manufacturer, the vendor and even the order number and serial numbers, if possible. Include warranty and support information as well. The more documentation you have on hand, the easier it will be to isolate and repair issues that arise later.


Check out 10 Things... the newsletter

Get the key facts on a wide range of technologies, techniques, strategies, and skills with the help of the concise need-to-know lists featured in TechRepublic's 10 Things newsletter, delivered every Friday. Automatically sign up today.

About

Erik Eckel owns and operates two technology companies. As a managing partner with Louisville Geek, he works daily as an IT consultant to assist small businesses in overcoming technology challenges and maximizing IT investments. He is also president o...

14 comments
ziba17
ziba17

Very Nice Article.

m_ruse
m_ruse

When it comes to disk upgrades Google did some interesting research and found that the make/model/price or hard drives had absolutely no bearing on whether the hard drive would fail or not. They found that when hard drives failed they ysually failed very soon after installation (probably caused by manufacturing defects) - otherwise the mean time between failure was not affected by make/model/price (and even temperature).

Realvdude
Realvdude

As another post pointed out, good backups are a given and should be SOP. Granted doing a backup just before the upgrade may not be deemed required by everyone, particularly with upgrades that do not involve hard drives. I absoultely agree with one upgrade component at a time; at the very least with a power up between each. While I agree with quality components, I do not agree that everything has to be server grade. Case in point, I have been running a Dell PowerEdge 600SC server for over 6 years, the OEM power supply failed after 2 years, the used OEM desktop power supply that replaced it has been running since. The ECC memory has also started being an issue after about 1.5 years. Last year it got chronic enough it had to be replaced. In contrast, most our clients run desktop computers as servers 10x5, and beyond OEM defect parts and external causes, the have been very few issues (usually tape drives). There are a few that run these 24x7x365.

reisen55
reisen55

I dealt with a franchise firm in early 2010 that upgraded a server in Mt. Kisco NY for a firm that was enormously oversized and over-spec'd. Turns out the Dell sales rep was very good at making profit for Dell. Period. The thing could handle 900 users, had 3 terabytes of drive available when only 20 gb of rotational data was needed. OS came in Spanish too. Horror show. I properly sized a Windows 2008 server for a client at the same time, worked with the client closely to create a good box, with easy expansion capability and cost perhaps 1/4 of whatever Mt. Kisco cost. My rules: Work through and with your client, let your client in on all major and minor decisions. This relationship ensures that you work together on a mutually advantageous solution and removes your work as a possible threat if something goes wrong. The client can and should purchase directly. I try to avoid selling my clients anything through my dollars if at all possible. System images are good not only for upgrade for also for Disaster Recovery testing. DO IT!!!!! GOOD BACKUPS SHOULD BE A NO-BRAINER AT ANY TIME DAY OR NIGHT. Document everything.

mrubis
mrubis

well not always related to servers,I keep an image backup of all my machines,,, some i don't have anymore but could recreate if needed.

kmdennis
kmdennis

Agreed! Especially creating the image. I have advocated that at any company that I work for, for the same reason that you mentioned. You get to reproduce the system in a much shorter time. I like the list.

l7ightshade
l7ightshade

At my last job I was told a story about a competitor. We had taken over a contract with a local prison to maintain there network. I was talking to the warden about why they had dropped their last contract (Me trying not to make the same mistake) And she went on about how the last IT guy while trying to upgrade the processor on the server had fried the motherboard. I didn't think anything of it at first but then she went on to tell me that his mistake was that the server was STILL ON. I proceeded to ask why he would do suck a folly thing. As he explained to her "I though all the information would be stored on the cashe." never the less i never made that mistake there lmao

eclypse
eclypse

We have never had good reliability from Dell server equipment. We had a sister company that switched from Compaq to Dell right about the time that HP acquired Compaq. Every single server they bought (about 20 in all) had something wrong with it out of the box. Many of them had recurring problems. They bought a Dell storage array that had a bad habit of just shutting down when it wanted to. I think they eventually solved all of their issues, but I would never buy a Dell server unless it was going to be part of a VMware cluster or something. We are an IBM shop now and have had very few issues from them and almost all of those are on the x86 hardware. The System p/Power Systems (formerly known as RS/6000) stuff just works - even the entry level servers - especially out of the box.

yattwood
yattwood

Server upgrades are only a _dream_ in certain cases for me....one of the systems I support is a very large (1.6TB) Oracle 8.1.7.4 database on a HP-UX RISC system (which is not even manufactured anymore) Why, you ask, am I supporting such an ancient version of Oracle? Because it runs PeopleSoft 7.5, and there is much FOUP (Fear Of Upgrading PeopleSoft) in my company. The HP RP7420's that support the Oracle 8i database are needing to be moved, and there is much wailing and lamentation, because there is very real concern about not being able to replace said servers (even from the aftermarket), the condition of the servers, etc. Fortunately, the Oracle datafiles reside on a relatively new Network Appliance, so I could do SnapMirror and FlexCloning to another NetApp, but the host server for the Oracle binaries and PeopleSoft executables is a sticky problem......

mudpuppy1
mudpuppy1

I work for a software development lab. We have lots of test servers. I always suggest that I take an image before any upgrades. Apparently, the engineers are even more paranoid because they always heartily agree. It's saved me on more than one occasion.

jmbrasfield
jmbrasfield

I also agree with the list. As to the imaging, I've recommended it every time, and every time I've been shot down by higher ups claiming it takes to much time. I was actually told by one that I had 15 min. to shut it down, replace the component, and get it back on line. "Time is money." I don't work there any more. Machines sometimes just won't work, even though everything is just fine. It is ALWAYS best to CYA every way you can and then some. S--- just happens!

grumpy bug
grumpy bug

Here's a similar story but with a happy ending. Back in the days before Y2K we were busy upgrading the BIOS on every server we had. Anyway things go one of the upgrades went south and we couldn't boot the server. Solution: We removed the BIOS chip from the dead server, found an identical server, booted it up into the BIOS upgrade program. Then while the server was ON. pried the BIOS chip of it and replaced with the dead one. Then completed the upgrade process and it worked. We were stunned, Sure we risked another server in doing so but that was in the good ole days before SLAs and uptime agreements. In the end all servers were up and running. Sometimes it pays to be a ballsy :-)

Erik Eckel
Erik Eckel

Nobody ever got fired for buying IBM...