Fachartikel

Monitoring, Backup und Recovery in virtualisierten Umgebungen (1)

Beim Betrieb einer Virtualisierungsinfrastruktur müssen IT-Verantwortliche auch dafür sorgen, dass die Umgebung verfügbar ist und im Fehlerfall schnell und ohne Datenverluste wieder anläuft. Hier kommen Monitoring, Backup, Ausfallsicherheit und Desaster-Recovery-Strategien ins Spiel. Im ersten Teil beschäftigen wir uns mit der Ausfallsicherheit von Servern, der Hochverfügbarkeit von Storage-Systemen und der Redundanz im Netzwerk.
Nie ohne Sprungtuch – auch in virtualisierten Umgebungen sollten Sie für alle Fälle gewappnet sein.
Ab einer gewissen Unternehmensgröße beginnen IT-Verantwortliche, an das Thema Hochverfügbarkeit zu denken. Ziel dieser Überlegung ist es in den meisten Fällen, den Ausfall einer Komponente, eines Servers oder eines ganzen Raums zu kompensieren, damit der Betrieb entweder vollständig ausfallfrei oder nur mit einer geringen Downtime handlungsfähig bleibt.

Der Aufbau einer Hochverfügbarkeit erstreckt sich nicht nur auf die virtuellen Server, sondern auch auf einige weitere Komponenten des IT-Betriebs, weshalb wir zunächst die gesamte Infrastruktur diesbezüglich betrachten. Dies wird zeigen, dass Hochverfügbarkeit nicht einfach durch einen zweiten Server erreicht wird, sondern dass zum Teil noch deutlich mehr dahintersteckt.

Ausfallsicherheit der Server
Der Aufbau eines Failover-Clusters beziehungsweise eines HA-Verbunds beginnt damit, dass Sie mehrere Server gleichzeitig betreiben. Diese Systeme sollten möglichst identisch sein, um die Administration und Pflege zu erleichtern. Alle Systeme in einem Cluster kümmern sich gemeinsam um den Betrieb von virtuellen Maschinen, dies können entweder Server- oder Clientsysteme sein – je nach Anforderungen. Betreiben Sie neben der Server- auch eine Clientvirtualisierung, kann es für Sie sinnvoll sein, einen zweiten Failover-Cluster aufzubauen, in dem nur die virtuellen Desktops laufen. Ab einer zweistelligen Anzahl an Hardwareknoten kann es ebenfalls von Vorteil sein, mehrere Cluster parallel zu betreiben. Dies erhöht zwar den administrativen Aufwand ein wenig, allerdings haben Sie bei einer Wartung oder einem Ausfall den Vorteil, dass nur ein Teil der Ressourcen nicht mehr zur Verfügung steht, und nicht der gesamte Cluster.

Alle Server in einem Failover-Cluster müssen mit einem gemeinsamen Storage kommunizieren können, auf dem die Daten der virtuellen Systeme abgelegt sind. Diese gemeinsame Verbindung sorgt dafür, dass bei einem Ausfall eines Cluster-Knotens ein anderes System die ausgefallenen VMs sofort wieder starten kann, sodass diese nach kurzer Zeit wieder betriebsbereit sind. Damit dieser Vorgang überhaupt möglich ist, müssen auf den verbleibenden Knoten noch ausreichend Ressourcen in Form von CPU und RAM zur Verfügung stehen.

Sie müssen daher definieren, wie viele Systeme gleichzeitig ausfallen dürfen. Haben Sie zwei Server, muss ein System allein den gesamten Workload betreiben können. Da jeder Knoten in gewissen Abständen nicht zur Verfügung steht (nämlich bei der Installation von Updates, je nach Hersteller einmal im Monat oder mehrmals im Jahr), muss das Partnersystem alle virtuellen Systeme in dieser Zeit betreiben können. Planen Sie mit mehr als zwei Systemen, kann sich theoretisch auch mehr als ein Server gleichzeitig in Wartung befinden. Sie sollten genau definieren, wie viele Server Sie benötigen, um die erforderliche Last inklusive des Wachstums in den kommenden Jahren zu bewältigen.

Sind die Server über mehrere Räume, Brandbereiche oder Gebäude verteilt, müssen Sie den Ausfall eines ganzen Bereichs abfangen können. Lassen Sie dies in Ihre Planung einfließen, ansonsten fällt Ihnen beim Ausfall von Bereich A auf, dass Bereich B überhaupt nicht in der Lage ist, den gesamten Workload alleine zu betreiben. Bei der Überwachung solcher Umgebungen helfen Ihnen professionelle Monitoringtools, auf die wir im weiteren Verlauf dieses Artikels noch zu sprechen kommen.
Hochverfügbare Storage-Systeme
Viele Storage-Systeme bieten ab Werk eine Redundanz der Hardware: Zwei oder mehr Netzteile, redundante Controller oder sogar zwei und mehr Geräte, die zu einem Storage-Cluster zusammengesetzt werden. Unabhängig von Ihrem Storage-System sollten Sie während des Aufbaus und der Konfiguration des Systems diese Redundanz auch wirklich testen. Es kommt unserer Erfahrung nach viel häufiger vor als angenommen, dass eine aufgebaute und versprochene Redundanz im Ernstfall nicht funktioniert. Der Umfang eines solchen Tests erstreckt sich vom Entfernen einer Netzwerkverbindung bis hin zum geplanten Stromausfall – dies hängt immer davon ab, welche Redundanz das System bietet.

Um Ihren Speicher über mehr als einen Raum zu betreiben (sogenannter "Stretched Storage"), stehen einige Lösungen zur Verfügung, die solch einen Aufbau ermöglichen. Häufig lassen sich die Hersteller diese Funktion allerdings teuer bezahlen. Auch gibt es hierbei unterschiedliche Ansätze: Ein Teil der Lösungen spiegelt auf Volume- beziehungsweise LUN-Basis die Daten von einem primären auf ein sekundäres System – entweder synchron oder asynchron.


Bild 1: Replikation zwischen Hosts sorgt durch identische Datenbestände für Sicherheit beim Ausfall eines Systems.

Bei einer synchronen Replikation wird auf System A ein Block geschrieben. Nehmen wir für dieses Beispiel an, dass eine VM diesen Block auf ihre virtuelle Festplatte geschrieben hat, dann kommuniziert, nachdem dieser Block angenommen wurde, System A mit System B und teilt ihm mit, welcher Block geändert wurde. Erst nachdem System A und System B die erfolgreiche Annahme des neuen oder geänderten Blocks bestätigt haben, bekommt die VM die Bestätigung, dass der Block erfolgreich geschrieben wurde. Bei diesem Aufbau ist es sehr wichtig, dass die Latenz zwischen den beiden Storage-Systemen extrem gering ist. Je länger es dauert, die Daten zu übertragen, desto länger muss die VM warten, bis sie neue Blöcke schreiben kann.



Seite 1 von 2 Nächste Seite >>
5.04.2021/jp/ln/Jan Kappen

Nachrichten

Mehr Durchblick bei AWS-Konten [22.06.2021]

Um die Verwaltung von Anmeldeinformationen für das AWS-Stamm- und Abrechnungskonto zu vereinfachen, hat ThycoticCentrify eine Cloud-Provider-Lösung auf Basis seiner Centrify-Plattform veröffentlicht. Unter anderem lässt dich damit das Management privilegierter Passwörter und Identitäten automatisieren. [mehr]

Neues Migration Toolkit für Cloud-native Migrationen [16.06.2021]

Red Hat möchte Unternehmen bei der Umsetzung von Open-Hybrid-Cloud-Strategien mit dem neuen Migration Toolkit for Virtualization unterstützen. Es bietet die Möglichkeit, unternehmenskritische Anwendungen, die auf virtuellen Maschinen basieren, auf Red Hat OpenShift zu migrieren und dabei gleichzeitig potenzielle Risiken und Ausfallzeiten zu minimieren. [mehr]

Tipps & Tools

EGroupware 21.1 erschienen [4.06.2021]

Die EGroupware GmbH veröffentlicht Version 21.1 ihrer gleichnamigen Open-Source-Groupware. Diese verfügt über neue Kompenten wie ein Kanban-Modul oder eine Firewall und eine verbesserte Telefonie-Integration. [mehr]

Stehhilfe fürs Smartphone [23.05.2021]

Es dominiert den Berufsalltag immer mehr und gibt auch äußerlich keinen Anlass, es am Arbeitsplatz zu verstecken: Das Smartphone sollten Sie jederzeit bestens greif- und sichtbar am Schreibtisch positionieren und mit ihm quasi auf Augenhöhe agieren! [mehr]

Buchbesprechung

Noch analog oder lebst du schon?

von Rolf Drechsler und Jannis Stoppe

Anzeigen