Vor dem Aufbau einer ausfallsicheren Server-Infrastruktur ist zu klären, ob Hardware-Server oder virtuelle Server (Virtual Machine, VM) zum Einsatz kommen sollen. Einer der großen Vorteile der Server-Virtualisierung besteht darin, dass sich virtuelle Server beim Ausfall des physischen Hypervisor-Hosts sofort auf einem anderen Hypervisor neu starten lassen. Wenn zudem das Speichersystem, auf dem die VM-Dateien liegen, auf zwei Standorte gespiegelt ist, lassen sich im Katastrophenfall die ausgefallenen VMs am anderen Standort direkt wieder hochfahren. Anstelle einer relativ kostspieligen Spiegelung der Speichersysteme ist es auch möglich, die VMs mit Hilfe einer Replikationslösung an den anderen Standort zu übertragen. Das gewählte Replikationsintervall bestimmt dabei, für welche Zeitspanne bei einem Desaster Daten verloren gehen, weil sie noch nicht auf die Zielsysteme repliziert sind. Eine nahe an die 100 Prozent heranreichende HA-Lösung ist aber nur mit mindestens doppelt ausgelegten Failover-Server-Systemen möglich. In der virtuellen Welt bedient zum Beispiel VMware dieses Marktsegment mit der Fault-Tolerance-Funktion (FT). FT dupliziert eine VM als sekundäre Instanz und behält bei einem Ausfall der VM auch deren RAM-Inhalte, sodass keine Daten verloren gehen.
In der Welt der Hardware-Server ist eine sehr hohe Verfügbarkeit in der Regel durch Failover-Cluster erzielt, die aus mindestens zwei Nodes bestehen und sich je nach Hersteller auf bis zu 64 oder mehr Server pro Verbund ausbauen lassen. Failover-Cluster, die unter Windows oder Linux laufen, unterstützen sowohl einen Active-Active- als auch eine Active-Passive-Betrieb.
Bei Failover-Clustern stellt das Split-Brain-Problem eine Herausforderung dar. Es tritt auf, wenn zum Beispiel die LAN-Verbindungen zwischen zwei Servern gestört sind, beide Nodes aber nach wie vor über das SAN Zugriff auf den Datenspeicher haben. Beide Server „denken“ in diesem Fall, dass der andere Node ausgefallen ist und sie deshalb der einzige überlebende Knoten sind. Ohne zusätzliche Mechanismen würde dies dazu führen, dass beide Nodes gleichzeitig auf dieselben Datenbestände zugreifen und dadurch über kurz oder lang Datenkonflikte entstehen.
Bei Windows-Clustern lässt sich dieses Szenario vermeiden, indem man eine Quorum-Disk oder ein Quorum-Fileshare konfiguriert und einem der beiden Nodes zuweist. In dem beschriebenen Split-Brain-Szenario würde nur der Node aktiv bleiben, der über das Quorum verfügt. Der andere Node würde seine Cluster-Dienste offline nehmen.
Für Linux-Cluster gibt es einen Fencing-Mechanismus, der bei einer Split-Brain-Situation einen der beiden Nodes deaktiviert. Diese auch „Stonith“ (Shoot the other node in the head) genannte Funktion lässt sich über eine spezielle Steckerleiste steuern, die die Stromzufuhr für einen Node kappt. Es steht auch ein Softwaremechanismus zur Verfügung, der auf einem der zwei Linux-Server eine Kernel Panic auslöst und das System damit anhält.
Microsoft hat für MSSQL-Server mit dem sogenannten Always-on-Cluster eine neue HA-Technik entwickelt, bei der die SQL-Datenbanken nicht mehr auf vom Cluster verwalteten Shared-Laufwerken eines zentralen SAN-Storage-Systems liegen. Stattdessen speichert jeder Node die SQL-Datenbankdateien auf lokalen Laufwerken und die DB-Inhalte lassen sich zwischen den Servern mit Hilfe von SQL-Mechanismen aktuell halten. Eine weitere HA-Technik ist das Load Balancing (LB), das insbesondere bei Web-Server-Farmen häufig zum Einsatz kommt. Die LB-Komponente verteilt die Anwendungszugriffe gleichmäßig auf alle Server. Fällt ein System aus, übernehmen die anderen Nodes des LB-Verbundes automatisch die betroffenen Sessions.