Falk Dübbert ...

Failover-Konzept für den Webserver

| Keine Kommentare

Am Donnerstag hatte Hetzner auch mal erfahren, dass ein Notstromkonzept nur dann gut ist, wenn man es realistisch testet.

In der Regel werden die Notstromaggregate nur mit ihrer Führungslast getestet, das sind Heizwiderstände die 25% der berechneten Leistung aufnehmen. Eigentlich dienen diese dazu, dass die Stromerzeuger eine Last haben, die die Ausgangsgröße der Regelschleife dämpft und die Fenster für Frequenz und Spannung irgendwie über 10 Sekunden getroffen werden, so dass die Laderegler der USV wieder Strom in die Akkus füllen können.  

Irgendwie hat das alles nicht funktioniert und da es nun das sechste Rechenzentrum in meinem Dunstkreis ist, bei dem innerhalb eines halben Jahres das Notstromkonpzept versagt hat, habe ich mir ein paar Gedanken zu Redundanzen und Failover gemacht. 

Meine Server bei Hetzner sind Webserver und machen auch so etwas wie private Clouds. Die Clouds werden von ihren Anwendern als Backup- und Sync-Tool benutzt. Hier kann man ein paar Einschränkungen hinnehmen, aber einen Tag Business-Hours offline sein auf einer Homepage für einen Verein oder wie hier vier Vereine, löst zuverlässig Fragen nach der Zuverlässigkeit des Hosters aus, auch wenn die Server vorher 4 Jahre lang Tag und Nacht durchliefen. 

  1. Möglichkeit 1 wäre vom selbstbetriebenen Server zurück zu einem "Managed Hoster" zurückzukehren. Aber damit habe ich mir und im Vereinsumfeld einige andere sich schon öfter die Finger gebrochen. Apache-, Perl-, MySQL- und PHP-Upgrades ohne Vorwarnung oder Testmöglichkeit sind nicht das, was man in einem Wochenendprojekt haben will und waren der Grund den Server von der Hardware bis zum Joomla selbst in der Hand zu haben. 
    Aktuell kommt die Unsicherheit bei der Datenerfassung in Sachen DSGVO noch oben drauf. 
  2. Möglichkeit 2 wäre, im DNS einen C-NAME auf einen DDNS-Hostnamen einzutragen und von einem Failover-Host den ersten Host skriptbasiert zu pingen, wenn der Ping scheitert, zieht man den Hostnamen an sich und wäre wieder im Spiel. 
    Allerdings, muss ich zugeben, dass die Erhöhung des Abhängigkeiten-Baum doch recht abschreckend auf mich wirkt. Denn, damit dieses Konstrukt zuverlässig funktioniert, muss der DDNS-Dienstleister und mindestens einer der Webhosts funktionieren. Dazu müssen die Datenbanken der Foren- und Ticketsysteme synchronisiert werden. Für OTRS gibt es einige Beispiele die Server zu clustern, aber bei den Foren unterhalb von Joomla läuft das auf Datenbank-Matching hinaus. Das wäre mir schon von der Sicherheit her viel zu heiß.  
  3. Möglichkeit 3 wäre, einen Webserver "in der Cloud" einzurichten und auf den physischen Hosts nur die File-Clouds zu hosten, die in einer public Cloud zu teuer würden. Aber auch hier spricht die Mathematik dagegen. Bei Azure hatte ein DNS-Ausfall dieses Jahr für einen weltweiten Dienstausfall gesorgt. Bei AWS gibt es Regionen, deren AWS-Verfügbarkeit unter 99% liegen. Public Clouds sind in der Regel weniger leistungsfähig und weniger verfügbar als ein selbst betriebener Server - irgendwo muss die Einsparung ja herkommen -, aber das ist eine Erkenntnis, die bei COOs und CIOs nur sehr langsam durchsickert und selbst wenn, reicht ihnen als Argument die Verantwortung für die Wiederherstellung nicht mehr im eigenen Spielfeld zu haben. Daher pushen immer noch mehr Firmen in die Clouds als sich daraus zurückziehen. 

Mein aktueller Weg ist, den Backup-Server mit dem primären Host zu synchronisieren und beim nächsten Ausfall von Hand den DNS-Eintrag zu ändern. Eine Lösung, die einen manuellen Eingriff erfordert, wäre kommerziell nicht vermittelbar, aber so muss ich keine Status-Seite anbeten oder auf die Bearbeitung eines Ticket warten, sondern habe eine Handlungsoption.  

Keine Kommentare

    Kommentarfunktion für diesen Artikel geschlossen.