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.
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.
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.
Kommt hingegen eine asynchrone Replikation zum Einsatz, werden die Daten immer auf System A geschrieben und erst zeitlich verzögert auf System B übertragen. Dies hat den Vorteil, dass die VM aus unserem Beispiel nicht auf beide Storage-Systeme warten muss, sondern nur auf System A. Die Latenz zwischen den beiden Storage-Systemen beeinflusst somit die Geschwindigkeit der VM nicht. Der Nachteil eines solchen Aufbaus ist, dass die Daten auf System B immer veraltet sind und nicht den Live-Stand enthalten. Abhängig von der zeitlichen Differenz gegenüber System A sind hier unter Umständen wichtige Daten (noch) nicht übertragen worden, falls System A einmal ausfällt.
Die Möglichkeiten und Funktionen, die Sie mit Stretched Storage erhalten, unterscheiden sich enorm voneinander. Manche Systeme können bei einem Ausfall den Partner automatisch online und in den Betriebsmodus schalten, andere brauchen für diesen Vorgang einen manuellen Eingriff. Manche Storage-Systeme, die über zwei oder mehr Räume verteilt werden, sind aus Hypervisor-Sicht nur ein einziges logisches System. Solche Systeme sind unserer Erfahrung nach einfacher einzubinden, da der Cluster nur ein Storage-System kennt und dieses zur Speicherung der VM-Daten nutzt.
Manchmal arbeiten die Hersteller hier auch kleine Optimierungen ein, sodass zum Beispiel durch einen Treiber die Latenzen zu den physischen Einheiten gemessen werden und der Hypervisor immer mit dem Storage-System spricht, das eine kleinere Latenz hat. Durch diese Technik sollen die Systeme stets mit dem Storage-Kopf am lokalen Standort sprechen und es soll keine Kommunikation eines Servers in Raum A zum Storage-System in Raum B geben, da häufig die Bandbreite in einem Raum höher ist als zwischen den Räumen. Kommt es zum Ausfall des Storage-Systems in Raum A, wird erst dann auf den Speicher in Raum B zugegriffen, sofern dies noch möglich ist. Häufig führen solche Features allerdings auch dazu, dass sich der Preis für solch eine Lösung deutlich erhöht.
Egal für welche Lösung Sie sich entscheiden, Sie sollten gerade bei Ihrem Storage-System genau definieren, welche Anforderungen Sie haben und ob sich diese mit Ihrem Budget vereinbaren lassen. Der Betrieb über zwei Räume führt eigentlich immer dazu, dass sich die Kosten für solch ein Projekt nicht nur verdoppeln, sondern vervielfachen.
Redundanz im Netzwerk
Das Netzwerk in Ihrem Datacenter ist eine der Kernkomponenten, die am besten niemals ausfällt. Um dieses Ziel zu erreichen, lässt sich auch hier mit einer Redundanz arbeiten. Zwei und mehr Enterprise-Geräte lassen sich über unterschiedliche Technologien zu einem logischen Verbund zusammensetzen. Die genaue technische Lösung hängt häufig davon ab, welcher Hersteller zum Einsatz kommt.
Sie sollten bei der Planung und dem Aufbau Ihres Backbone-Netzwerks einige Dinge berücksichtigen. Dies beginnt damit, dass Sie die Bandbreite der Geräte betrachten. 10 GBit/s im Backend ist aktueller Standard. In den letzten 18 Monaten gab es allerdings eine ziemlich große Bewegung in diesem Bereich, Switches mit 25, 50 und 100 GBit/s pro Port sind preislich so attraktiv geworden, dass einige Unternehmen das Core-Netzwerk oder Teile davon auf 100 GBit/s aufrüsten. Diese Bandbreite ist in den meisten Umgebungen für die nächsten Jahre vollkommen ausreichend und bietet nebenbei auch noch den Vorteil, dass sich ein 100 GBit/s-Port mit Breakout-Kabeln auf zwei 50-GBit/s- oder vier 25-GBit/s-Ports splitten lässt. Mit Hilfe dieser Technik wird aus einem Switch mit 16 Ports, die mit 100 GBit/s arbeiten, ein Gerät mit bis zu 64 Ports mit jeweils 25 GBit/s. Falls Sie nun direkt an extrem hohe Preise für solches Equipment denken: Enterprise-Geräte mit diesen Eigenschaften liegen teilweise im vierstelligen Preissegment.
Zwei dieser Geräte sorgen dafür, dass vor Ort eine Redundanz besteht. So können Sie Server mit einem NIC-Team in jeweils einen Switch stecken. Damit sind die Systeme auch dann noch online, wenn im Netzwerk ein Gerät ausfällt oder durch ein Update temporär nicht zur Verfügung steht. Achten Sie vor der Anschaffung darauf, wie und mit welchen Abhängigkeiten Sie solch ein Update machen können. Denn uns sind auch Switch-Modelle bekannt, bei denen im Stack-Modus ein Update nur gleichzeitig für alle Stack-Mitglieder möglich ist.
Dies führt zwangsläufig zu einer Downtime und somit zu einem Wartungsfenster, in dem nicht nur der Switch-Stack ein Update erhält, sondern vermutlich auch alle VMs herunterfahren müssen, da die Verbindung untereinander und (bei der Nutzung von iSCSI oder SMB3) zum Storage unterbrochen wird. Dieser große Aufwand führt daher in vielen Fällen dazu, dass weniger Updates eingespielt und unter Umständen Sicherheitslücken oder Fehler in der Firmware nicht gefixt werden.
Betreiben Sie mehrere Serverräume, sollten Sie die Netzwerkkomponenten über die Räume hinweg ebenfalls redundant anbinden. Zwei Geräte, jeweils eins in jedem Raum, sind keine Redundanz. Pro Standort sollten mindestens zwei Geräte im Einsatz sein, damit auch hier jeweils eins in Wartung genommen werden oder ausfallen kann. Lässt es die Lage der Standorte zu, sollten Sie zwei unterschiedliche Wege für die Verbindung untereinander nutzen (sodass quasi ein Ring betrieben wird). Dies führt bei der Unterbrechung eines Kabels nicht zwangsläufig zu einem Abbruch der gesamten Verbindung zwischen Raum A und Raum B.
Betreiben Sie neben internen Systemen und Applikationen auch Systeme in einem Rechenzentrum oder bei einem Cloudanbieter, ergibt eine Betrachtung der Internetanbindung ebenfalls Sinn. Haben Sie nur eine Leitung und diese fällt aus, sind sofort sämtliche Dienste außerhalb Ihrer Firma nicht mehr nutzbar. Sie sollten auch hier auf Redundanz setzen, je nach Verfügbarkeit am besten über zwei unterschiedliche Anbieter und im besten Fall über zwei unterschiedliche Wege. Zwei Internetanschlüsse, die über den gleichen Anschluss in Ihr Gebäude gelangen, bringen Ihnen beim Ausfall dieser einer Zuleitung auch nichts.
Im zweiten Teil des Workshops gehen wir darauf ein, warum USV-Systeme Pflicht sind, wie Sie beim Storage auf IOPs und Latenz achten und warum Sie beim Monitoring auch Temperatur und Wasser erfassen sollten. Im dritten Teil erklären wir, wie Sie mit einem Backupplan für stufenweisen Schutz der Daten sorgen, warum Replikation nicht gleich Backup ist und wie Sie ein effizientes Desaster-Recovery vorbereiten.
Autor: Jan Kappen