Systemreiter: VMware Einstellungen

Dieser Artikel enthält folgende Inhalte:

Teil 1: Grundeinstellungen

Geschätzte Abschaltzeit

Dry-Run Installations-Testlauf

Was ein „Dry Run“ macht

Teil 2: Erweiterte Einstellungen

Teil 3: Auswahl „Hosts sind auch vSAN Knoten“ bei Sicheres Außerbetriebnehmen von vSAN Knoten

Die VMware Einstellungen steuern das gesamte Abschaltverhalten der Server und Hosts innerhalb von VMware. Abhängig von Ausbaustufe und Konfigurationsart sind unterschiedliche Konfigurationen erforderlich, um eine VMware basierte Infrastruktur zu verwalten. Zusätzlich zu den zwingend notwendigen Basisdaten wie IP-Adressen und Zugangsdaten werden unter anderem detailliertere Kenntnisse über das Abschaltverhalten Ihrer IT-Landschaft benötigt.

Beachten Sie, dass einige dieser Daten nicht statisch sind. Werte können sich ändern und sollten im Rahmen regelmäßiger Systemkontrollen angepasst werden.

RCCMD berechnet und zeigt die geschätzten Abschaltzeiten basierend auf den eingegebenen Daten an.

Teil 1: Grundeinstellungen

Die Grundeinstellungen gehen davon aus, dass Sie Hosts ohne vCenter betreiben. Sie können mit einer RCCMD Appliance beliebig viele Hosts herunterfahren:

Verwaltung virtueller Maschinen

Dieses Menü legt fest, ob die Hosts und virtuellen Maschinen von RCCMD oder von einem vCenter verwaltet werden. Wenn Sie die Hosts im Lockdown-Modus betreiben, sind Steuerbefehle ausschließlich über ein vCenter zulässig. Auch bei korrekt eingegebenen Zugangsdaten wird der Host in diesem Fall die Befehlsausführung verweigern.

In der Standardeinstellung ist „von RCCMD“ aktiv.

Verhalten der virtuellen Maschinen

Mit dieser Einstellung legen Sie fest, ob Sie vMotion nutzen oder Ihre Maschinen direkt herunterfahren möchten. Ein Shutdown der virtuellen Maschinen wird dabei direkt vom Host gesteuert:

Die virtuellen Maschinen werden regulär heruntergefahren, danach werden die Hosts ausgeschaltet.

Wenn Sie vMotion aktivieren, ist das lokale Herunterfahren virtueller Maschinen nur das Fallback-Protokoll. Zuerst versucht das vCenter, die virtuellen Maschinen auf einen anderen Host zu verschieben.

Die Standardeinstellung ist „Virtuelle Maschinen herunterfahren“.

Wenn Wartungsmodus ausgewählt ist, werden zusätzliche Informationen benötigt, etwa Zugangsdaten des vCenter sowie ein Zeitfenster, das dem vCenter zum Verschieben der virtuellen Maschinen auf andere Hosts zur Verfügung stehen soll.

vSAN Knoten sicher außer Betrieb nehmen oder kein vSAN in Verwendung

Diese Einstellung definiert das Abschaltverhalten, wenn ein vSAN verwendet wird. Das vCenter stellt an dieser Stelle verschiedene Grundeinstellungen zur Auswahl. Wenn Sie ein von RCCMD verwaltetes vSAN nutzen möchten, beachten Sie die zu erfüllenden Grundvoraussetzungen.

Die Standardeinstellung ist „Kein vSAN in Verwendung“.

VMware mit RCCMD

RCCMD muss den Namen der virtuellen Maschine kennen, auf der die RCCMD Appliance ausgeführt wird. Diese Einstellung verhindert, dass der RCCMD Client selbst heruntergefahren wird.

Teilen Sie RCCMD alle ESXi Hosts mit, die heruntergefahren werden sollen

Mit diesem Konfigurationsdialog legen Sie fest, welche ESXi Hosts von RCCMD heruntergefahren werden sollen:

Die Menüleiste bietet folgende Funktionen:

• Add: Einen weiteren Host hinzufügen.
• Remove: Host auswählen und mit Remove aus der aktuellen Liste entfernen.
• Edit: Host auswählen. Mit Edit können Sie die Zugangsdaten bearbeiten.
• Verify: Mit diesem Button wird die aktuelle Konfiguration gespeichert und die Login-Daten werden überprüft. Nach der Verifizierung zeigt RCCMD den Verbindungsversuch an.

Geschätzte Abschaltzeit

Nachdem die Konfiguration abgeschlossen ist, zeigt RCCMD eine geschätzte Abschaltzeit an:

Dies ist die aktuell durchschnittliche Abschaltzeit Ihrer IT-Infrastruktur. Beachten Sie, dass diese Abschaltzeit berechnet wird und zum Vergleich mit der von der USV bereitgestellten Notstromlaufzeit verwendet werden kann.

Da es sich hierbei um einen berechneten Wert handelt: 

Testen Sie Ihre Abschalteinstellungen unbedingt vor der Aktivierung!

Dry-Run Installations-Testlauf

Mit dem Dry Run bietet RCCMD eine einzigartige Funktion innerhalb der VMware Einstellungen:

Der Dry Run ist ein Simulationsmodus, in dem Ihre RCCMD Installationen das Verhalten durchlaufen, ohne es physisch auszuführen.

Diese Funktion ist besonders nützlich, wenn eine RCCMD Installation auf einem produktiven Server eingerichtet wird:

Ein unbeabsichtigter Shutdown wird so verhindert. Mit Save and Execute wird diese Funktion aktiviert und schützt Ihre zukünftige Konfiguration vor unbeabsichtigtem Herunterfahren.

Hinweis

Einige Konfigurationsmenüs sind während der Testphase gesperrt und können nicht „zwischendurch“ angepasst werden.

Was ein „Dry Run“ macht

Normalerweise ist ein CS141 der RCCMD Server, der einen gültigen RCCMD Befehl an einen RCCMD Client sendet, also an die RCCMD Software. Der Befehl und die damit verknüpfte Aktion hängen vom finalen Betriebsszenario ab. Da Sie das Event Handling des CS141 nutzen können, um individuelle Befehle zum Start sehr sensibler und komplexer Skripte zu senden, ist es möglich, einen Server über Skripte weitgehend zu automatisieren. Sie müssen mit RCCMD nicht zwingend nur einen Server herunterfahren.

In VMware Umgebungen unterscheidet sich die RCCMD Appliance von einer normalen Client-Installation:

Sie ist darauf ausgelegt, eine strukturierte Abschaltsequenz für alle Hosts innerhalb einer VMware Umgebung sicherzustellen.

Um diese Aufgabe zu erfüllen, benötigt RCCMD Zugangsdaten mit Systemrechten, die einen Shutdown erlauben. Das Problem ist, dass RCCMD nicht zwischen einem echten Notfall und einem Benutzer unterscheidet, der am CS141 den Testjob-Button betätigt. Während eines Tests kann das kritisch sein. Sobald RCCMD ein gültiges Signal akzeptiert, startet es die Abschaltprozedur. Das ist vergleichbar mit dem „OK“ Konsolenbefehl in einem üblichen „Sind Sie sicher“ Dialog eines Betriebssystems.

Selbstverständlich können Sie nicht einfach „alle Server“ im laufenden Betrieb herunterfahren, nur weil Sie Ihre Konfiguration testen möchten. Das Herunterfahren eines Echtzeitsystems mit 100 Prozent Verfügbarkeit ist ausschließlich realen Notfällen vorbehalten.

Der Dry Run ist ein integrierter, selbstablaufender Simulationsmodus

1. Alle konfigurierten Hosts werden kontaktiert.

2. Die Zugangsdaten für die Hosts werden getestet.

3. Ein Protokoll wird geschrieben, das Konfigurationsprobleme sowie erfolgreiche Login-Tests dokumentiert.

4. Das standardmäßige RCCMD Shutdown-Signal wird unterdrückt, solange der Simulationsmodus aktiv ist.

Solange der Dry Run aktiv ist, ist kein Notfallshutdown über ein gültiges RCCMD Servergerät möglich.

Hinweis:

Wenn Sie die mit der Standardinstallation ausgelieferten Skripte ändern oder neue Skripte hinzufügen, werden diese konsequent ausgeführt. Der Dry Run unterdrückt nur seine eigene standardisierte Abschaltsequenz und prüft nicht die von Ihnen manuell vorgenommenen Änderungen.

Dieses Verhalten hat Vorteile und Nachteile.

1. Da Ihre „scharfen“ Skripte kompromisslos ausgeführt würden, sollte der Dry Run Test vor deren Einsatz stattfinden.

2. Durch das Hinzufügen eigener Skripte, die harmlose Aktionen auslösen, können Sie prüfen, ob Ihre „scharfen“ Skripte funktionieren würden und alle administrativen Freigaben auf dem Zielsystem vorhanden sind.

Teil 2: Erweiterte Einstellungen

Wenn Wartungsmodus (vMotion) ausgewählt ist

zeigt RCCMD zwei zusätzliche Menüpunkte an:

Maintenance Mode Timeout in Seconds

Dieser Wert definiert das Zeitfenster, das RCCMD dem vCenter einräumt, um virtuelle Maschinen auf Hosts zu verschieben, die nicht in den Wartungsmodus wechseln.

Virtuelle Maschinen, die in diesem Zeitfenster nicht migriert werden konnten, verbleiben zum Herunterfahren beim ESXi Host.

vCenter Zugangsdaten

Für die Nutzung von vMotion benötigt RCCMD gültige vCenter Zugangsdaten. Beachten Sie, dass ein RCCMD Client viele Hosts herunterfahren kann, technisch aber nur ein vCenter verwalten kann. Wenn mehrere unterschiedliche Konfigurationstypen benötigt werden, kann der Einsatz von zwei zusammenarbeitenden RCCMD Appliances notwendig sein.

Werte prüfen

Testen Sie die vCenter Zugangsdaten. RCCMD versucht, sich am vCenter anzumelden und gibt eine Rückmeldung inklusive Grund bei einem fehlgeschlagenen Login-Versuch.

Teil 3: Auswahl „Hosts sind auch vSAN Knoten“ bei Sicheres Außerbetriebnehmen von vSAN Knoten

Diese Einstellung aktiviert mehrere Untermenüs sowie eine vSAN Timeout-Warnung.

Behalten Sie diese Warnmeldung im Blick.

Ein vSAN ist im Shutdown-Betrieb heikel, wenn es nicht korrekt außer Betrieb genommen wird. Eine falsch konfigurierte Abschaltsequenz kann zu Dateninkonsistenzen oder sogar zu vollständigem Datenverlust führen.

vSAN Abschaltoptionen

Keine Daten-Evakuierung

Dies ist die schnellste Methode, um einen Systemshutdown sicherzustellen. Die virtuellen Maschinen werden heruntergefahren, danach synchronisiert das vCenter alle Hosts innerhalb des vSAN. Es findet keine Datenmigration statt und es werden keine virtuellen Maschinen auf andere Hosts verschoben.

Alle Daten auf andere Hosts evakuieren

Im Prinzip entspricht dies der Funktion, die vMotion auslöst. Ein vSAN kann sich auch über verschiedene Standorte erstrecken, sodass virtuelle Maschinen auf externe Hosts ausgelagert werden können, die nicht Teil des vSAN Clusters sind, der heruntergefahren werden soll. Wenn Sie vMotion nutzen, wird dies zuerst ausgeführt. Dadurch kann es sein, dass Ihr vSAN Host keine virtuellen Maschinen mehr enthält, die migriert werden müssen. Sie können diese Option als „zweiten Versuch“ nutzen, um Maschinen aus dem vSAN zu verschieben.

Datenzugriff sicherstellen

Wenn größere vSAN Systeme ausreichend Redundanz bieten, werden keine Daten verschoben. Datenmigration erfolgt nur für Daten ohne Redundanz.

Hinweis

Mit den vSAN Erweiterungen bietet RCCMD eine Lösung, um einen Notfallshutdown des gesamten vSAN Systems so schnell wie möglich durchzuführen. Virtuelle Maschinen, die zuvor per vMotion an einen anderen Standort migriert wurden, sind davon nicht betroffen.

Da das Ziel in einem Notfall darin besteht, das vSAN schnell zu stoppen und herunterzufahren, ist „Keine Daten-Evakuierung“ hier die beste Wahl.

vSAN Resync Timeout in Seconds

Diese Einstellung definiert das grundsätzliche Zeitfenster, das RCCMD dem vCenter für die Synchronisation der Datenbanken zwischen den Hosts einräumt, bevor der nächste Schritt in der Abschaltsequenz gestartet wird. Dieses Zeitfenster ist anspruchsvoll zu bestimmen, da die Resync-Zeit stark variieren kann. Grundsätzlich gilt: sie dauert so lange, wie sie dauert. Das vCenter liefert keine geschätzte Resync-Zeit, daher müssen Sie diese im Rahmen eines manuellen Shutdowns testen. Wenn Ihr vCenter meldet, dass der Job abgeschlossen ist, haben Sie die minimale Zeitbasis für den Notfallshutdown. Rechnen Sie für dieses Zeitfenster zusätzliche Reserven ein, da die gemessene Zeit eines manuellen Shutdowns nur eine Momentaufnahme ist und keinen allgemeinen Wert darstellt.

Sekunden, bevor der Wartungsmodus für vSAN gesetzt wird

Sobald der Resync abgeschlossen ist, ist das vCenter die letzte verbleibende virtuelle Maschine, die heruntergefahren werden muss. Mit dieser Einstellung definieren Sie, wie lange das vCenter Zeit hat, sich selbst herunterzufahren, bevor RCCMD den nächsten Schritt der Abschaltsequenz einleitet.

Bestimmen, welche VM das vCenter ausführt

Innerhalb eines vSAN ist das vCenter mehr als nur eine Verwaltungsinstanz:

Das vCenter steuert den gesamten Datentransfer innerhalb eines vSAN und verwaltet die komplette Nachsynchronisation während eines vSAN Shutdowns. Das bedeutet:

Wenn das vCenter innerhalb eines vSAN läuft oder auf einem Host betrieben wird, der zu früh heruntergefahren wird, kann das gesamte vSAN ins Stocken geraten. Läuft das vCenter als virtuelle Maschine innerhalb des vSAN, muss RCCMD den Namen dieser virtuellen Maschine kennen, um sie vom Shutdown der virtuellen Maschinen auszuschließen.

Hinweis:

Das vCenter, das ein vSAN verwaltet, befindet sich nicht zwingend innerhalb dieses Clusters. Es kann an anderer Stelle installiert und separat verwaltet werden. Wenn sich die virtuelle Maschine mit dem vCenter nicht in der Liste der Hosts befindet, die heruntergefahren werden sollen, müssen Sie sie an dieser Stelle nicht eintragen. Sie müssen sie jedoch im Blick behalten, wenn mehrere RCCMD Appliances eingesetzt werden. Ohne sein vCenter kann ein vSAN nicht wie erwartet herunterfahren.