Keep your application running when one server fails

Everything sits on one server. The online store, the database, the planning, the order portal your customers log in to. As long as that machine runs, nobody notices there is only one. Until a disk breaks, a memory module fails, or an update leaves everything hanging, and the whole company suddenly waits for a technician and a restore that takes hours.

What high availability does and does not solve

High availability means that every part that can break has a second one, and that the takeover happens automatically. If a server drops out, the other picks up the traffic. If a disk drops out, the storage keeps running on the rest. If a network port drops out, it goes over the second. What you end up with is not an immortal system, but a system in which a single defect is no longer a business outage.

Just as important is what it does not do. A bug in your own code is neatly replicated to both servers. A wrong command that empties a table goes to the copy within a second. A vendor who changes their integration is out on both. Redundancy protects against broken equipment, not against human mistakes, and for those you still need a tested backup. We say that at the start, not after the invoice is signed.

Two servers, replicated data, and a switch

The setup almost always consists of three parts. Two or more servers running the same application, usually two virtual machines or two Dedicated servers in separate racks. Behind them your data, replicated synchronously so the second machine has the same rows as the first; if a heavy database runs underneath, we set it up separately as Managed databases. And in front, something that sends the visitor to the healthy server, with a health check that looks every few seconds whether the other side still answers.

How far you take that depends on what you want to catch. Two servers side by side in the same data center catch broken hardware. Two locations also catch a power failure or a network problem in that one building, but the distance costs you milliseconds on every write, and you notice that in your application. If your software already runs in containers, the step to Kubernetes and containers is often more logical than two separate machines. We choose the setup on what your application needs, and the place in our managed environments that fits it.

Test the failover before you need it

A failover that has never been tried is an assumption. In practice we see a switch that gets stuck halfway more often than one that works neatly: a certificate that only sits on the first server, a background task that starts running on both machines at once, a connection to the accounting system that had the old server's address hardcoded. You find those things by pulling the plug, not by reading the design again.

So before delivery we deliberately turn off a server while you watch, and you time for yourself how long it takes before the application responds again. Then we practice switching back, because that is the moment data can drift apart. The playbook that comes out of that you get on paper. The monitoring then watches not only whether the website works, but also whether you really still have two working halves, because a cluster that stands on one leg for months is just an expensive single server.

When it is not worth the trouble

A double setup is more complex than a single one. More machines to maintain, replication that can lag, updates that have to go in the right order. That complexity is worth it when downtime costs you money or trust directly: an online store that sells day and night, a portal where customers keep their own records, a system tied to production or planning. For an internal office package that can wait a morning, a well-managed machine with Managed hosting and a backup that has really been restored is the wiser choice.

So in the free intake we first do the sober math: what stands still, for how long, and what happens in that time. If it turns out faster hardware, a second internet connection, or a tightly arranged Backup and disaster recovery is enough, we do not build a cluster. If it turns out you do need it, we build it and make sure you understand it yourself. The servers are in your own organization's name, the setup is documented, and you are the owner, even if you place the management elsewhere later.