„Hochverfügbarkeit” – welches Szenario

[Tom (Gast)]

Hallo,

ich würde gern mal eure Meinungen zu folgendem Szenario hören.

Es geht um einen Server, auf dem eine Anzahl unkritischer, einige 
kritische und eine hochgradig kritische Site laufen.

(Datenvolumen (ca. 2 TB / Monat) und Rechenleistung sind easy von einem 
einzelnen Server zu bewältigen, kritisch meint die finanziellen Folgen 
im Falle eines Totalausfalles)

Im Wesentlichen handelt es sich um Typo3 und Magento Sites und ein paar 
Wordpress-Dinger.

Ich bin gerade dabei die Sites von diesem Server auf einen neuen zu 
migrieren und dabei diverse Updates durchzuführen und zu testen. Dabei 
ist mir aufgefallen, dass das ein guter Zeitpunkt ist um noch mal neu 
über Katastrophenfälle nachzudenken.

Im Moment läuft der Server mit einem Raid-1 und es wird drei Mal am Tag 
ein Backup erzeugt. Das Backup wird Nachts auf einen Backupserver an 
einem anderen Ort übertragen, der ansonsten nicht am Netz ist und auch 
wieder ein Raid als Massenspeicher hat. Der Hauptserver steht in einem 
regulären Rechenzentrum, der Backupserver in einem Bürogebäude.

Soweit ist das eigentlich ganz nett, das Problem ist, dass ich vor 
kurzem eine Wiederherstellung für eine unkritische Site aus diesem 
Backup machen musste und ich muss zugeben, dass mich der Aufwand dafür 
etwas unvorbereitet getroffen hat (Zeitaufwand). Eine Wiederherstellung 
der hochgradig kritischen Site würde vermutlich Tage dauern, dazu kommt 
ja noch, dass ein lauffähiger Server Voraussetzung ist, auf dem auch die 
ganze benötigte Software lauffähig und installiert ist.

Das merke ich im Moment: Da gibt es zwar im Grunde keine Probleme dabei 
einen entsprechenden Server aufzusetzen, aber es summiert sich ganz 
schön auf, die ganzen Tools zu installieren und wenn man irgendwo einen 
kleinen Fehler macht, kann es Stunden dauern, bis man den gefunden hat 
und weitermachen kann. Allein für die sehr trickreich konfigurierte 
LuaTeX Installation habe ich Stunden gebraucht.

Der langen Rede kurzer Sinn:

Vier Katastrophenfälle interessieren mich im Moment:
1. Hardwareschaden der mehr als eine Platte oder ein Netzteil betrifft.
2. Katastrophenfall im Rechenzentrum (Brand, Hochwasser, etc.)
3. Netzstörung
4. Hacker


Alternativ zum aktuellen Stand, könnte ich mir auch vorstellen:

Szenario 2: Ein zweiter Server wird aufgesetzt und in regelmäßigen 
Abständen werden die Applikationsdaten vom laufenden Server auf den 
slave runterkopiert. Über rsync bzw. MySQL Replication.

Bei dieser Variante dürfte auch die Verbindung zwischen den beiden 
Servern etwas langsamer sein, denke ich.

Der Vorteil wäre, dass ich auf diesem 2. Server alle Sites 
betriebsbereit habe, ich kann die Applikationen mit ihrem 
Backup-Datenbestand testen und im K-Fall kann ich einfach über den 
Naheserver auf diesen Server umschalten und habe nur einen Tag an Daten 
verloren. Das ist zwar nicht schön, aber der Betrieb geht recht zügig 
weiter.

Bis zur nächsten Synchronisation hätte ich außerdem einen Testserver, 
auf dem ich Anpassungen an der Konfiguration test kann. Nachts wäre dann 
wieder alles beim alten.

Meines Erachtens bietet mir dieses Szenario auch einen kurzfristigen 
Schutz vor Hackern, jedenfalls wenn sie nach „Erst zerstören dann 
denken” handeln.

Szenario 3: Replikation über DRBD
Vermutlich würde ich im Störungsfall keine Daten verlieren und die 
Applikationen würden praktisch ungestört weiterlaufen, aber wie stark 
bremst sowas aus? Brauche ich da 10 GB/s zwischen den beiden Servern?

Wenn ein Hacker eine Datei auf dem einen Server löscht, ist sie direkt 
auch auf dem anderen gelöscht, für diesen Fall also 0 Sicherheit, selbst 
bei einem unfähigen Hacker, oder?


Vielen Dank für eure Meinungen

Timm

[Max Nilp (Gast)]

Nicht vergessen. Ein neu aufgesetzter Server hat ein neueres 
Betriebssystem. Die Datenbank passt dann vielleicht nicht mehr. Eine 
neue Version der Datenbank ist nicht mehr zwingend kopatibel mit der 
Alten.
Die Server Applikation, welche auch immer, passt dann auch nicht mehr 
ganz. Das gibt alles sehr viel mehr arbeit als angenommen.

[ich_eben (Gast)]

Hallo,
warum virtualisierst du den server nicht mit vmware ESXi, machst ein 
Backup mit veeam und hältst einen zweiten esxi in bereitschaft, da 
reicht evtl auch ein normaler pc und / oder der zweite kann gleichzeitig 
der backupserver sein

[(prx) A. K. (prx)]

Weil ESXi+Veeam grad erwähnt wurde: Nakivo Backup (*) macht bis jetzt 
auch einen guten Eindruck. Die aktuelle Version kann ggf. ohne Restore 
direkt aus dem Backup booten (untested). In diesem Zusammenhang ist auch 
die Funktion der Replikation einer VM interessant.

Charme von ESXi: Die Hardwarebasis vom Host ist für die VM 
uninteressant. Ersatz des Hosts ändert nichts an der VM und das Ziel 
einer Replikation kann eine andere Hardware nutzen als die Quelle.

ESXi gegenüber anderen Virtualisierungslösungen: Ein Host ist in 15min 
neu aufgesetzt.

*: Mündliches Englisch ist nützlich, gut genug zum Abwimmeln. Denn wenn 
man beim Download seine Telno angibt, ruft baldigst totsicher jemand mit 
etwas russisch klingendem Englisch aus den USA an und nervt. Jedes 
einzelne Mal. Scheint branchentypisch zu sein, denn Veeam hat mindestens 
genauso genervt, dafür in Deutsch, nur klingt der Name "Veeam" am 
Telefon ziemlich bescheuert, so dass so ein Gespräch anfängt wie bei 
Comedy ("wiim" - "wer" - "wiim" - "wie" - "wiim" - "ich nix verstaan, 
bitte buchstabieren").

[Sven L. (sven_rvbg)]

Die Idee mit dem ESXi ist durchaus gut und auch so machbar.

Gute Erfahrungen habe ich schon mit https://www.trilead.com/de/ gemacht.

Zu beachten ist, das wenn der Backupserver in einem anderem 
Rechnenzentrum dieser dann mit sehr hoher wahrscheinlichkeit in einem 
anderem Netz liegt und somit der Server unter seiner ursprüngichen IP 
nicht mehr erreichbar ist.

Es gibt Sicherheitsrechenzentren mit mehreren Brandabschnitten, da 
müsste halt der zweite Server im anderem Brandabschnitt stehen.

Wenn es um viel Geld geht, sollte man vielleicht auch über eine 
Betriebsunterbrechungsversicherung nachdenken!

Wenn man nur die Daten syncen will, ist DRBD sehr interessant, bei DRBD 
gelten Daten erst dann als geschrieben, wenn sie auch auf dem 
Clusterpartner geschrieben wurden. Hier sollte man also die 
Geschwindigkeit zwischen beiden Clusterpartnern nicht außer acht lassen!

DRBD ist gut gegen Hardwareausfall, im Falle von Hackern werden 
eventuell veränderte Systemdateien unter Umständen auch syncronisiert.