This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
A server is parts you can name when it fails
CPU choice is cores, clock, and whether the workload is one thread or many. A comparison table helps you stop buying a high core count for a process that uses one core. RAM choice is capacity and the layout the board expects: the number of DIMMs, the generation, and the error-correcting type a server board wants. The calculators on this site compare those numbers. They do not see your chassis.
Disks and RAID belong to the storage guide. Power supplies and fans belong in the ticket because a single supply is a plan to be down when it fails. Out-of-band management, the lights-out controller, is how you reboot a host whose operating system is gone. It is on a management prefix, with its own password, not on the same public address as the website.
Firmware and BIOS updates are changes. They have a console, a rollback the vendor actually provides or a spare board, and a window. You do not apply one because a dashboard said the version was old, in the same hour as a production incident, on the only host.
Record the serial, the role, the CPU, the RAM layout, the storage, and the out-of-band address in one inventory line. A later performance problem will ask for that line. A later patch will ask whether this hardware is still supported.
An inventory line before you buy or upgrade
Write the workload in one sentence: a file server for fifty people, a lab hypervisor for four small guests, a single application that peaks one core. Then write the CPU and RAM you think match it, and run them through the comparison and the RAM calculator. If the board cannot take that DIMM layout, the calculator's nicer number is not a purchase order.
The out-of-band address in the lab is 192.0.2.20 on the management prefix, as a documentation example. Production uses the real management prefix from the network desk. The password is prompt-for-this in any note and a real secret in the password store. You do not put the lights-out controller on the user VLAN because the cable was short.
A firmware change on the lab, if you must practise, is one host, vendor image from the vendor, console open, and a note of the version before and after. If the vendor has no rollback, the practise is reading the release note, not discovering that on the production pair.
When the machine arrives, the serial on the chassis matches the serial in the inventory before you rack it. The storage guide then owns the disks. The virtualization guide owns the guests.
A change you can finish
A hardware change is scheduled, with console or out-of-band confirmed before you pull a cable. Adding RAM is power off, matching DIMMs, power on, and the operating system seeing the new total. If it does not, you stop. You do not also update firmware because the chassis is already open.
Rollback of a RAM change is the previous DIMMs, which you did not throw away in the same window. Rollback of firmware is the vendor's method, confirmed before you start.
- Write the workload sentence.
- Match CPU and RAM to the board, not only to the calculator.
- Record serial, role, and out-of-band address.
- Put out-of-band on the management prefix with a real password that is not in the ticket.
- Confirm console access before a firmware or RAM window.
- Change one class of part.
- Confirm the OS sees the result, then stop.
Mistakes that outlive the command
server hardware fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- A single power supply on a host people will call a production server.
- Out-of-band on the public website address.
- Firmware plus RAM plus a disk swap in one window.
- DIMMs the board will not run, because the capacity number looked right.
- Throwing away the old DIMMs before the new ones post.
- A password for the lights-out controller written on the ticket.
- Buying core count for a one-thread application.
- No serial in inventory, so the failed disk and the spare cannot be matched.
Decisions to write down before the window
One decision for server hardware: The workload sentence exists before the purchase. RAM layout matches the board. The calculator result was checked against that layout. Out-of-band is on the management prefix. The password is not in the ticket. Two supplies, or an accepted single point of failure written in the ticket. Firmware is its own window with a console and a vendor rollback story. One hardware change at a time. The serial on the metal matches the inventory line. Disks are handed to the storage guide. Guests are handed to the virtualization guide. Old parts stay until the new parts are proven. The performance guide's measurement, not a feeling, justifies a bigger CPU. And a second person read the out-of-band address and confirmed it is not the public site address.
Hardware checks before the chassis is called ready
Confirm this before you call the change done: Serial, role, CPU, and RAM are on one inventory line. The OS reports the RAM total you installed. Out-of-band answers on the management prefix. The out-of-band password is not in the ticket. Power supplies match the failure story you accepted. No second class of part was changed in the same window. Firmware version before and after are recorded if firmware changed. Console worked before you started. Old DIMMs or the previous part are still available. Disks were not initialised as a side effect. A second person saw the serial. The public address and the management address are different. The next guide, storage or virtualization, has the handoff in the ticket. The hostname in the prompt matches the hostname in the ticket for server hardware. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for server hardware happened, and the next host is not started early. If one of those fails, stop.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar.