Abhängig von der Leistungsfähigkeit unserer Ausrüstung und den notwendigen Ressourcen für unsere Systeme werden wir ein durchschnittliches Verhältnis von virtuellen Maschinen pro Server haben.
Nehmen Sie zum Beispiel die geplante Wartung eines Servers im Rechenzentrum. Wäre dies vor einigen Jahren nicht Teil eines Clusters, wäre das in den Geräten enthaltene System vom Netz genommen worden, folglich wären auch die Benutzer betroffen und / oder das an der Wartung beteiligte Personal musste in reduzierten Zeitfenstern arbeiten (für nicht sagen unbequem).
Im Falle einer virtualisierten Umgebung können virtuelle Maschinen einfach auf ein anderes Mitglied eines Clusters „verschoben oder migriert“ werden und die Geräte können heruntergefahren werden, um daran zu arbeiten. Problem gelöst.
Beginnen wir mit Situationen, in denen der Mangel an Service nicht programmiert ist.
Überwachung virtueller Maschinen und Anwendungen
Jedes Mal, wenn wir eine virtuelle Maschine erstellen, wird empfohlen, ein Kompendium von Anwendungen und Treibern zu installieren, die das Verhalten der virtuellen Hardware insgesamt optimieren (verfügbar für Windows, Mac OS, Linux und andere Betriebssysteme). Diese Tools, VMTools genannt, beinhalten unter anderem die Möglichkeit für den Host, die virtuelle Maschine zu überwachen (durch Heartbeats, wie in Clustern). Wenn es innerhalb eines bestimmten Zeitraums nicht reagiert, startet es Ihr Betriebssystem neu.
Ein ähnlicher Fall tritt bei der Anwendungsüberwachung auf, aber zuerst müssen Sie das entsprechende SDK erwerben (oder eine Anwendung verwenden, die VMware Application Monitoring unterstützt).
Aber … was passiert, wenn der Fehler in der Hardware liegt?
Der oben erwähnte Cluster ist die erste Schicht der Lösung.
Geteiltes LagerWo alle Mitglieder des Clusters Zugriff auf virtuelle Maschinen haben.
Netzwerk-TeamingAngesichts des Ausfalls eines Boards verwalten die verbleibenden weiterhin den Verkehr.
Mehrere Pfade (Multipathing)Für die Speicherung optimieren sie nicht nur den Zugriff, sondern sorgen auch für Redundanz.
Im Großen und Ganzen verkürzen diese drei Technologien die Zeit, in der unsere Informationen nicht zugänglich sind. Nun können wir je nach Lizenzierung auch zwei sehr interessante Features haben: High Availability (HA) und Fault Tolerance (FT).
In beiden Fällen benötigen wir einen Cluster mit Shared Storage. Ohne dass zusätzliche Software installiert werden muss, kann HA so aktiviert und konfiguriert werden, dass bei Ausfall eines Servers oder einer virtuellen Maschine im Cluster automatisch auf einem anderen Mitglied des Clusters gestartet wird. Es sollte klargestellt werden, dass HA nicht für geschäftskritische VMs (virtuelle Maschinen) gedacht ist. Die geschätzte Zeit ohne Dienst lautet also: "Starten des Betriebssystems + Starten der Dienste".
Anzahl der vom Cluster unterstützten Hostfehler
Wir haben X virtuelle Maschinen, die auf Y Servern in einem Cluster verteilt sind.
Wie viele Hosts können ausfallen, ohne die Verfügbarkeit und Leistung unserer virtuellen Umgebung zu beeinträchtigen?
HA kann so konfiguriert werden, dass eine bestimmte Anzahl von Serverausfällen unterstützt wird, um sicherzustellen, dass für die Wiederherstellung genügend Ressourcen verbleiben.
HA teilt die verfügbaren Ressourcen eines Clusters unter Berücksichtigung der von unseren virtuellen Maschinen konfigurierten und verbrauchten CPU und RAM auf sehr konservative Weise auf. Es nimmt die größte konfigurierte CPU-Reservierung einer beliebigen VM auf jedem Host im Cluster und dann die größte Speicherreservierung und deren Überschuss. Wenn keine Reservierung konfiguriert ist, werden mindestens 32 MHz pro VM für die CPU und 0 MB RAM + der Überschuss benötigt.
Bei diesen Zahlen wird davon ausgegangen, dass jede verwendete virtuelle Maschine diese CPU und diesen Arbeitsspeicher verbraucht, und generiert dann einen Wert namens Slot-Größe. Mit diesem Wert wird festgelegt, wie viele Slots von jedem Host verfügbar / verwendet werden.
Das Problem tritt auf, wenn wir beispielsweise eine einzelne Maschine mit einer großen CPU- und Speicherreserve haben. Durch die Verwendung konfigurierter Reservierungen ist es sehr wahrscheinlich, dass der Rest unserer virtuellen Maschinen diese Ressourcen nicht wirklich benötigt, was zu weniger Slots für unseren Cluster führt.
Prozentsatz der Clusterressourcen als Kapazität für Fehler
Im Gegensatz zur vorherigen Option funktioniert diese sehr gut, wenn Sie VMs mit stark variablen CPU- und Speicherkonfigurationen haben.
Es ist möglich, Prozentwerte von CPU und Speicher getrennt zu konfigurieren, um so noch flexibler zu sein und somit Ressourcen zu sparen. Dies ist im Allgemeinen die bevorzugte Methode zum Konfigurieren von HA.
Hosts für Failover
Dies ist die typische Standby-Cluster-Konfiguration. Diese Option wird hauptsächlich angeboten, da einige Organisationen Richtlinien anwenden, die angeben, dass Server im Notfall im Standby-Modus sein müssen. Da VMware ein gutes Fehlertoleranzmanagement bietet, wäre dies vielleicht die Option, wenn die Ressourcen reichlich vorhanden sind… aber definitiv nicht die beste.
vBewegung: Live-Migrationen
Die Live-Migration ermöglicht es Ihnen, funktionierende virtuelle Maschinen von einem physischen Server auf einen anderen zu verschieben, während Sie Ihre Netzwerkverbindung und Identität beibehalten. Aktiver Speicher (laufende Prozesse) wird über das Hochgeschwindigkeitsnetzwerk übertragen. Der gesamte Vorgang dauert in einem Gigabit-Netzwerk weniger als 5 Sekunden.
Es ist möglich, die VM, die von ihr verwendeten Dateien oder beides zu verschieben, und der Vorgang kann mit ein- oder ausgeschaltetem Computer durchgeführt werden. Im letzteren Fall nennen wir es "kalte Migration" und wenn die Maschine läuft, nennen wir es vMotion.
Einsatzmöglichkeiten und Vorteile von vMotion
- VM-Reorganisation, wodurch die Ressourcen optimiert werden. Entfernen Sie sie von Servern, die fehleranfällig oder übersättigt sind.
- Automatische Optimierung der verfügbaren Ressourcen (Ich arbeite in Verbindung mit Dynamic Resource Scheduler oder DRS).
- Tun Wartung der zugrunde liegenden Infrastruktur keine Wartungsplanung oder Betriebsunterbrechung erforderlich.
Jede Komponente des VM-Zustands wird während der Migration unterschiedlich behandelt. Die allgemeine Konfiguration ist die einfachste, sie wird nicht verschoben, sondern auf dem Zielcomputer neu erstellt.
Da die Festplatte nicht in so kurzer Zeit neu erstellt werden kann, ist ein gemeinsamer Speicher erforderlich. Der aktuelle Zustand des Speichers wird nach und nach auf den Ziel-Host kopiert, am Ende der Kopie werden die bestehenden Unterschiede, die während der Migration entstanden sind, verglichen, der Zustand der Quell-VM eingefroren und das Betriebssystem auf der Ziel-VM aktiviert .
Da in einigen Fällen die Option zum Neustarten der Maschine nicht ideal ist, haben wir für geschäftskritische Fälle die Fehlertoleranz. Was in diesen Fällen gewünscht wird, hört zu keiner Zeit auf zu funktionieren, auch wenn sein Host ausfällt. Dies ist nur möglich, wenn die VM an zwei Orten gleichzeitig ausgeführt wird. Es wird auf der Ebene der virtuellen Maschine konfiguriert und erstellt eine exakte Kopie der VM, wobei diese jederzeit zu 100% auf einem anderen Server repliziert wird bei einem Hardwareausfall funktioniert sein Zwilling einfach ohne Informationsverlust weiter. Interessant, oder?
Wenn es nur um Ressourcen ginge, würden wir FT in allen virtuellen Maschinen in unserem Rechenzentrum aktivieren, aber in früheren Versionen von vSphere stießen wir auf einige Einschränkungen, die wichtigste: Es war nicht möglich, FT in Maschinen zu aktivieren, die mehr als eine virtuelle Maschine verwendet haben Prozessor. Glücklicherweise unterstützt die neueste Version des Produkts bis zu 4 virtuelle Prozessoren gleichzeitig pro geschützter Maschine, jedoch muss die Lizenzierung berücksichtigt werden:
Die Anzahl der vCPUs, die von einer FT-fähigen VM unterstützt werden, ist durch die für vSphere erworbene Lizenzstufe begrenzt.
Fehlertoleranz wird wie folgt unterstützt:
- vSphere Standard und Enterprise. Erlaubt bis zu 2 vCPUs.
- vSphere Enterprise Plus. Erlaubt bis zu 4 vCPUs.
Das ist nicht die einzige Anforderung des Systems.
LagerungVMs müssen über freigegebenen Speicher verfügen. Es ist nicht möglich, physisches RDM (Raw Devide Mapping) zu verwenden.
NetzEs sind mindestens zwei virtuelle Karten (vmnics) erforderlich, eine für vMotion und die andere (10 Gbit/s) für FT Logging. Es ist eine neue Anforderung von Version 6 (bisher wurden 1-Gbit/s-Platten benötigt)
ProzessorProzessoren und Betriebssysteme müssen mit FT (und untereinander) kompatibel sein.
Einschränkungen
- Es ist nicht möglich, Snapshots der mit FT zu schützenden VMs zu erstellen und diese müssen vor der Aktivierung dieser Funktion gelöscht werden.
- Virtuelle Festplatten (VMDK) größer als 2 TB.
- Eine Liste bestimmter Geräte und Funktionen finden Sie in der VMware-Dokumentation.
Auch die Anzahl der VMs pro Server ist begrenzt: maximal 4 geschützte Maschinen pro Host oder 8 geschützte vCPUs (je nachdem, was zuerst eintritt). Diese Maximalwerte umfassen die primäre und sekundäre Maschine (und vCPUs)
Unterschiede zwischen FT-Legacy (vorher) und aktuell
IPv6
Legacy FT = Nicht von Netzwerkkarten unterstützt, die für FT-Logging konfiguriert sind FT = Unterstützt
VStorage-APIs – Backup mit Datenschutz
Legacy FT = Nicht unterstützt FT = Unterstützt
Virtuelle Festplatte
Legacy FT = EZT (Eager Zeroed Thick) FT = Alle Typen, einschließlich dick und dünn
Vmdk-Redundanz (virtuelle Festplatte)
Legacy FT = Single copy FT = Die primären und sekundären Maschinen behalten unabhängige Kopien, dies ermöglicht die Speicherung in verschiedenen Datenspeichern und erhöht die Redundanz
Bandbreite der Netzwerkplatte
Legacy FT = Dedizierte 1-Gb-NIC empfohlen FT = Dedizierte 10-Gb-NIC empfohlen
CPU- und Host-Kompatibilität
Legacy FT = Erfordert das gleiche CPU-Modell und die gleiche Familie. Nahezu identische vSphere-Versionen FT = CPUs müssen mit vSphere vMotion oder EVC kompatibel sein. Die VSphere-Version muss mit vSphere vMotion kompatibel sein
FT bei laufender Maschine aktivieren / deaktivieren
Legacy FT = Nicht immer unterstützt FT = Unterstützt
Denken Sie daran, dass FT vor Serverhardwarefehlern schützt, nicht vor Betriebssystem- oder Anwendungsfehlern.
vCenter Server Watchdog es ist eine eingebettete Funktionalität der Version 6.x. Es überprüft regelmäßig den Status der Dienste, aus denen vCenter besteht, und startet bei Bedarf die Verwaltungsprozesse oder die VM neu.
