Colocation Power Redundancy Testing for New Racks

Why you should test power redundancy before moving production gear

Colocation power redundancy testing shows you whether a rack can handle a feed loss, an A/B mismatch, or a failed PDU before production depends on it. In a Hostperl colocation workflow, this is where you verify dual-corded servers, remote hands access, carrier-room power paths, and your own shutdown plan while the risk is still low.

This tutorial uses a RHEL-family test path because power validation often happens on hardware running RHEL, Oracle Linux, or Fedora Server in colocation. The process still helps on other Linux systems, but the commands below follow this less-covered OS track so you can work through a realistic, production-style check from start to finish.

If you are planning a move into dedicated server hosting or colocating owned hardware beside it, this is the kind of pre-cutover check that prevents avoidable downtime. It also pairs well with colocation migration planning and the first rack power-up checklist.

What you need before you begin

• A colocated server with dual PSUs, or a clear note that the server is single-corded.
• Access to the rack A and rack B power feeds, or the equivalent PDU ports.
• Console access through IPMI, iDRAC, iLO, or a remote KVM.
• Root SSH access to the operating system.
• Permission to schedule a brief maintenance window if you plan to remove one feed.

Do not pull a power cord on production hardware until you know which cable feeds which PSU. This test depends on labeling and sequencing.

Connect to the server and confirm the OS

On your local computer, start with the standard SSH connection.

ssh root@203.0.113.10

The address 203.0.113.10 is a documentation example. Replace it with the real public IP assigned to your server by the colocation provider.

If your facility uses a non-root admin account first, use the same IP with your account name instead.

ssh deploy@203.0.113.10

On the VPS as root, confirm the operating system before you touch services or logs.

cat /etc/os-release

You should see a RHEL-compatible release such as RHEL, Oracle Linux, or Fedora Server. If you are on a different Linux distribution, adjust package commands later in the tutorial.

Create a safe admin account if you still work as root

If you logged in as root, create a non-root administrator first. Keep the root session open until the new login is proven.

On the VPS as root, create the account, set its password, and add it to wheel.

useradd -m -G wheel deploy
passwd deploy

That creates deploy with a home directory and sudo access through the wheel group. On Fedora Server and RHEL-compatible systems, this is the usual admin path.

Now create the SSH directory and install your key safely.

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

If your key is not already in /root/.ssh/authorized_keys, append it manually with vi or nano and keep the permissions strict.

On your local computer, open a second terminal and test the new account.

ssh deploy@203.0.113.10

Then confirm sudo works.

sudo -v

If that succeeds, keep using deploy for the rest of the tutorial. Only after this point should you consider locking down root SSH or password login.

Check the current power path from the server side

Power redundancy is physical, but you still want OS evidence before you test anything. On RHEL-family systems, install the tools you need to inspect logs and hardware events.

On the VPS as the non-root sudo user, update packages and install the basic utilities.

sudo dnf -y update
sudo dnf -y install smartmontools lm_sensors util-linux pciutils

You are not tuning performance here. You are making sure the box is fully updated and ready to report a clean state before a power test.

Check current uptime and recent boot history.

uptime
who -b

Confirm whether the server is dual-corded at the operating system level by checking UPS, PSU, or chassis messages in the journal.

journalctl -b | egrep -i 'power|psu|ac loss|redund|ups|ipmi|iLO|iDRAC|thermal'

If your hardware exposes IPMI sensors, this is also the time to inspect them.

sudo ipmitool sensor

You should see PSU and temperature readings if the server supports IPMI and the package is available. If ipmitool is missing, install it first with sudo dnf -y install ipmitool.

Map the power cords before you unplug anything

Label each feed before the cutover window. In a real colocation room, remote hands usually helps here, especially when the rack is already populated.

On the VPS as the non-root sudo user, note what you expect to test and save the plan locally.

mkdir -p ~/colocation-power-test
cat > ~/colocation-power-test/plan.txt <<'EOF'
Server: 203.0.113.10
Goal: verify A/B power redundancy
Expected result: server stays online on one feed, then recovers cleanly when the second feed returns
EOF
cat ~/colocation-power-test/plan.txt

That gives you a simple audit trail for the maintenance window. If something goes wrong, you can compare the observed behavior with the expected one.

Run the first redundancy test

This step belongs in a scheduled maintenance window. If the server is single-corded, stop here; you cannot test A/B redundancy that does not exist.

On the rack side, have remote hands or your own on-site staff remove power feed A from PSU A only. Leave feed B connected. Do not touch both at once.

On the VPS as the non-root sudo user, watch for any boot, thermal, or service interruption while the first feed is removed.

journalctl -f

In another shell, continuously ping the server from your local computer or a monitoring host.

On your local computer, run:

ping 203.0.113.10

Replace the example IP with the live server address if you are testing a different node. A healthy dual-feed system should keep responding while one PSU loses input. If the server drops, you may have a bad PSU, a single-corded device, or both feeds on the same upstream path.

Restore the first feed and test the second side

Once the server remains stable on one feed, reconnect power feed A and then remove power feed B from the other PSU. You are looking for the same result in reverse.

On the VPS as the non-root sudo user, check whether the machine logged any AC-loss or PSU events.

journalctl -b | egrep -i 'AC loss|PSU|power supply|redundant|failover|input lost'

If your hardware exposes a BMC, confirm that both PSUs are healthy after the swap.

sudo ipmitool sdr elist | egrep -i 'psu|power|volt|fan|temp'

If you see a sensor fault, stop and involve the colocation provider before repeating the test. Continuing with unstable power hardware is how small issues become emergency replacements.

Check OS services after each feed swap

Servers sometimes survive the loss of one feed but still suffer a brief controller reset, NIC blip, or storage warning. That is why you check services instead of trusting only the ping.

On the VPS as the non-root sudo user, review the active services and recent errors.

systemctl --failed
systemctl status sshd --no-pager
systemctl status systemd-journald --no-pager

Expect all three commands to show normal service health. If any unit failed, inspect the exact failure record.

journalctl -u sshd -b --no-pager

If your application stack is already live on the server, run its own status checks too. For example, if you host a web service behind Nginx, confirm the process and port still exist before closing the test window.

ss -tulpn | grep -E ':80|:443|:8000'

A working colocation test ends with power stability and service stability together. One without the other is not enough for production approval.

Branch notes for Fedora Server and RHEL-compatible systems

RHEL, Oracle Linux, and Fedora Server all support the workflow above, but lifecycle expectations differ. Fedora Server moves faster, so firmware and kernel behavior may change sooner. RHEL and Oracle Linux are usually steadier for long-lived colocated deployments.

If you plan to place a business workload in colocation and want provider support around migrations, hardware readiness, and incident response, dedicated servers and dedicated server hosting are the natural comparison point. Hostperl also publishes operational guides like dedicated server monitoring and firmware lifecycle planning that fit the same maintenance mindset.

Rollback and recovery if the server fails the test

If the machine powers off or reboots when one feed is removed, put both feeds back immediately. Then move to the recovery path below.

1. Reconnect both PSUs to known-good power feeds.
2. Check the BMC or IPMI event log for PSU alarms.
3. Confirm the server boots cleanly and all mounts come back.
4. Open a provider ticket or remote-hands request with the exact test result.

On the VPS as the non-root sudo user, save the evidence you will need for support.

sudo journalctl -b --no-pager > ~/colocation-power-test/journal-current-boot.txt
sudo ipmitool sel list > ~/colocation-power-test/ipmi-sel.txt
ls -lh ~/colocation-power-test

Those files give support a clean trail. They help distinguish an upstream rack issue from a local PSU failure.

Final verification from server and client

Close the window only after you verify four things: uptime survived the feed swap, the OS saw no critical hardware fault, your services stayed up, and the rack now has a documented power map.

On the VPS as the non-root sudo user, run:

uptime
systemctl --failed
sudo ipmitool sel list | tail -n 20
ss -tulpn

On your local computer, confirm the host still answers over the network.

ping 203.0.113.10
ssh deploy@203.0.113.10

If both feeds are healthy and SSH still works, the power path is ready for production use. That is the point where a colocation move feels boring, which is exactly what you want.

FAQ

Can I test redundancy on a single-corded server?

No. A single-corded server can only prove that one feed works. It cannot prove failover. For true redundancy, you need separate PSUs and separate upstream feeds.

What if the server reboots when one feed is removed?

Reconnect both feeds, capture journalctl and ipmitool sel list, and open a support ticket. The cause is usually a bad PSU, a miswired cord, or both cords landing on the same power path.

Should I do this test during business hours?

No. Schedule it inside a maintenance window, even if the test is brief. You want time to restore power, check logs, and confirm application health before traffic depends on the rack.

Do I need remote hands for this procedure?

If you are not in the data center, yes. Remote hands can trace feeds, swap cords, and confirm the labels while you watch the logs from your desk.

What is the most common mistake during power testing?

Unlabeled cords. The second most common mistake is pulling both feeds at once. Label everything first, then remove one feed at a time.