Monitoring, Backup und Recovery in virtualisierten Umgebungen (1)

Lesezeit
3 Minuten
Bis jetzt gelesen

Monitoring, Backup und Recovery in virtualisierten Umgebungen (1)

05.04.2021 - 00:00
Veröffentlicht in:
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.
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 >>


jp/ln/Jan Kappen

Ähnliche Beiträge

Azure mit lokalen Netzen verbinden (3)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im dritten und letzten Teil der Workshopserie zeigen wir, wie Sie virtuelle Firewalls hochziehen.

Azure mit lokalen Netzen verbinden (2)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im zweiten Teil binden wir den Connection Broker an und erklären, was es mit dem Cloud Witness auf sich hat.

Azure mit lokalen Netzen verbinden (1)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im ersten Teil der Workshopserie schildern wir das Prinzip virtueller Netzwerke.