Technische Details zur Failover-Loesung

In Planung ist nun also ein zweiter Rootserver, diesmal gehostet bei manitu, also im AS9063/St. Wendel. Der derzeitige Server steht bei NGZ im AS13301/Coburg. Die beiden haben abgesehen vom DE-CIX relativ unterschiedliche Peerings, so dass eine erhoehte Ausfallsicherheit gewaehrleistet wird. Natuerlich koennte man auch einen Server im Ausland platzieren, das macht dann aber mehr Probleme beim abrechnen mit der Steuer. Failover wird ueber DNS mit niedrigen TTLs(~15min) gemacht, dazu werden alle Domains auf eigenem BIND Nameserver gehostet. Wenn der Hauptserver ausfaellt gibt der Backup nur noch “seine” IPs heraus. Poor man’s Solution. Damit Datenbankapplikationen auf dem Backup transparent, also ohne Modifikation, weiterlaufen ist ein MySQL Multi-Master vorgesehen. Fuer das Dateisystem gibt es eine einseitige Synchronisation via Rsync (Aenderungen auf dem Backup werden vom Hauptserver nicht beruecksichtigt), das betrifft auch die Email. Der Backup-Server wird auch als Secondary MX eingesetzt und die, waehrend der Downtime eingehende Mail fuer den Hauptserver entgegen nehmen. Derzeit ist nicht vorgesehen, die Mail auch noch auf dem Backup zuzustellen. Mailzugriff(IMAP) wird auf dem Backup natuerlich weiterhin funktionieren, wenn auch read-only. Die Shell-Accounts werden auf dem Backup nicht aktiviert.

2 Kommentare zu “Technische Details zur Failover-Loesung”

  1. Ralf Eisenreich

    Klingt nach einem guten (und günstigen) Konzept! Wenn der Backup-Server anspringt und dort Änderungen in der DB vorgenommen worden sind, werden diese dann später auf dem Hautpserver automatisch reflektiert?

  2. chrono

    Ja, das ist der Sinn hinter dem MySQL Multi-Master Setup. Im Gegensatz zur reinen Replikation sind die beiden Sqlserver dann gleichberechtigt.

Einen Kommentar schreiben:

Bitte schreib' in das folgende Feld die Zahl 123: