Wartung und Aktualisierungen der privaten Cloud
Private Cloud-Umgebungen sind so konzipiert, dass es keinen Single Point of Failure gibt:
- ESXi-Cluster sind mit vSphere HA (Hochverfügbarkeit) konfiguriert. Die Cluster haben eine Größe, die zur Gewährleistung der Ausfallsicherheit mindestens einen freien Knoten bietet.
- vSAN bietet redundanten primären Speicher, wobei mindestens drei Knoten erforderlich sind, um Schutz vor einem einzelnen Ausfall zu bieten. Bei größeren Clustern können Sie vSAN so konfigurieren, dass eine höhere Stabilität ermöglicht wird.
- Virtuelle Maschinen (vCenter, PSC und NSX Manager) werden mit RAID-10-Speicher konfiguriert, um Speicherfehler zu verhindern. Die VMs werden zusätzlich durch vSphere HA vor Knoten- und Netzwerkausfällen geschützt.
- ESXi-Hosts haben redundante Lüfter und NICs.
- TOR- und Spine-Switches sind in HA-Paaren konfiguriert, um für Ausfallsicherheit zu sorgen.
VMware Engine überwacht kontinuierlich die Betriebszeit, die Verfügbarkeit und bietet SLAs für die folgenden Arten von VMs:
- ESXi-Hosts
- vCenter
- PSC
- NSX Manager
VMware Engine überwacht kontinuierlich Folgendes auf Ausfälle:
- Festplatten
- Ports der physischen Netzwerkkarte
- Server
- Lüfter
- Stromversorgung
- Schalter
- Switch-Ports
Wenn ein Laufwerk oder ein Knoten ausfällt, fügt VMware Engine sofort einen entsprechenden Knoten zum betroffenen VMware-Cluster hinzu, um den Dienst wiederherzustellen. Die folgenden Prozesse finden in Ihrer privaten Cloud statt:
- Automatisiertes Monitoring und Benachrichtigungen: Unser Überwachungssystem verfolgt ständig den Zustand Ihrer Knoten. Wenn ein Problem erkannt wird, das auf einen potenziellen Hardwarefehler hinweist, wird eine Benachrichtigung ausgelöst.
- Manuelle Überprüfung zur Diagnose: Das System ist zwar für den automatischen Austausch konzipiert, unsere Techniker überprüfen diese Benachrichtigungen jedoch, um die Ursache schnell zu ermitteln. So können wir das richtige Problem beheben und unnötige Knotenaustausche vermeiden, wenn eine einfachere Lösung (z. B. ein Neustart) empfohlen wird. Beispielsweise können vorübergehende Netzwerkprobleme oder Softwarefehler ähnliche Benachrichtigungen wie Hardwarefehler auslösen. Wir möchten vermeiden, dass Ihr Cluster durch den Austausch von Knoten beeinträchtigt wird, wenn dies möglicherweise nicht die empfohlene Maßnahme ist. Ein unnötiger Knotenaustausch löst eine vollständige vSAN-Resynchronisierung aus, die einen hohen Speicher-E/A-Aufwand verursacht.
- Automatischer Knotenaustausch bei Hardwarefehlern: Wenn unsere Techniker einen Hardwarefehler bestätigen, beginnt sofort der automatische Knotenaustausch. Dem Cluster wird ein neuer Knoten hinzugefügt und vSAN initiiert die Datensynchronisierung auf diesem Knoten.
Die folgenden VMware-Elemente in den privaten Clouds werden gesichert, verwaltet und aktualisiert:
- ESXi
- vCenter Platform Services Controller
- vSAN
- NSX
Sichern und wiederherstellen
Sicherungen umfassen Folgendes:
- Nächtliche inkrementelle Sicherungen von vCenter-, PSC- und DVS-Regeln
- Integrierte vCenter-APIs zum Sichern von Komponenten auf Anwendungsebene
- Automatische Sicherung vor der Aktualisierung oder vor Upgrades der VMware-Verwaltungssoftware
Wartung
Es gibt folgende Arten von geplanten Wartungsarbeiten:
Back-End und interne Wartung
Für das Back-End und die interne Wartung müssen physische Assets neu konfiguriert oder Softwarepatches installiert werden. Das hat keinen Einfluss auf die normale Nutzung der gewarteten Assets. Bei redundanten NICs zu jedem physischen Rack sind der normale Netzwerktraffic und die privaten Cloud-Vorgänge nicht betroffen. Die Leistung wird möglicherweise nur beeinträchtigt, wenn Ihre Organisation im Wartungszeitraum die volle redundante Bandbreite nutzen will.
Portalwartung
Wenn die Steuerungsebene oder Infrastruktur aktualisiert wird, ist eine Dienstausfallzeit für eine begrenzte Zeit unvermeidlich. Die Wartungen können einmal pro Monat erfolgen und werden voraussichtlich im Laufe der Zeit abnehmen. VMware Engine informiert Sie über bevorstehende Portalwartungen und versucht, das Wartungsintervall so kurz wie möglich zu halten. Während einer Portalwartung funktionieren die folgenden Dienste weiter ohne Beeinträchtigung:
- VMware-Verwaltungsebene und -Anwendungen
- vCenter-Zugriff
- Alle Netzwerke und Speicher
VMware-Infrastruktur warten
Gelegentlich ist es erforderlich, Änderungen an der Konfiguration der VMware-Infrastruktur vorzunehmen. Diese Intervalle können alle ein bis zwei Monate auftreten, aber mit der Zeit wird es voraussichtlich länger werden. Google kann diese Art der Wartung, einschließlich Zertifikatsaktualisierungen, in der Regel durchführen, ohne die normale Nutzung der privaten Cloud zu unterbrechen. Während eines VMware-Wartungsintervalls funktionieren die folgenden Dienste weiter ohne Beeinträchtigung:
- VMware-Verwaltungsebene und -Anwendungen
- vCenter-Zugriff
- Alle Netzwerke und Speicher
Aktualisierungen und Upgrades
VMware Engine ist für die Lebenszyklusverwaltung von VMware-Software (ESXi, vCenter, PSC und NSX) in privaten Clouds verantwortlich.
Softwareupdates umfassen Folgendes:
- Patches:von VMware veröffentlichte Sicherheitspatches oder Fehlerkorrekturen
- Updates: geringfügige Versionsänderung einer VMware-Stack-Komponente
- Upgrades: Hauptversion einer VMware-Stack-Komponente
VMware Engine testet kritische Sicherheitspatches, sobald diese von VMware zur Verfügung gestellt werden. Google wird versuchen, die Rollouts relevanter kritischer Patches für private Cloud-Umgebungen innerhalb einer Woche nach ihrer Verfügbarkeit zu starten. Der tatsächliche Zeitrahmen für den Abschluss des Patchens variiert je nach Verfügbarkeit und der Notwendigkeit, das Patchen so zu planen, dass Ausfallzeiten für Kundenarbeitslasten vermieden werden.
Wenn eine neue Hauptversion der VMware-Software verfügbar ist, koordiniert VMware Engine gemeinsam mit Kunden ein geeignetes Wartungsfenster für die Durchführung des Upgrades. VMware Engine führt Hauptversions-Upgrades mindestens sechs Monate nach der Veröffentlichung der Hauptversion durch und benachrichtigt Kunden einen Monat im Voraus über die Durchführung von Hauptversions-Upgrades.
VMware Engine arbeitet auch mit wichtigen Branchenanbietern zusammen, um sicherzustellen, dass sie die neueste VMware-Softwareversion unterstützen, bevor ein Upgrade auf eine Hauptversion durchgeführt wird. Informationen zum Support für bestimmte Anbieter erhalten Sie von Cloud Customer Care.
Verantwortlichkeit für die Zertifikatsaktualisierung
Zertifikatsaktualisierungen liegen in der Verantwortung von Google. Wenn Sie einen Zertifikatsaktualisierungsfehler erhalten, müssen Sie nichts unternehmen. Das Zertifikat wird vor Ablauf verlängert. Wenn LDAPS jedoch in Ihrer privaten Cloud konfiguriert ist, sind Sie allein für das spezifische Zertifikat verantwortlich, das mit diesem Fehler verknüpft ist. Zertifikatsupdates können während der Wartung der VMware-Infrastruktur erfolgen.
Vorbereitung
Google empfiehlt, vor dem Start eines Updates oder Upgrades die folgenden Vorbereitungen zu treffen:
- Speicherkapazität prüfen:Die Nutzung des Speicherplatzes Ihres vSphere-Clusters muss unter 80% liegen, um das SLA erfüllen zu können. Wenn die Nutzung 80 % übersteigt, kann das Upgrade länger als gewöhnlich dauern oder komplett fehlschlagen. Wenn Ihre Speichernutzung mehr als 70 % beträgt, fügen Sie einen Knoten hinzu, um den Cluster zu erweitern und so Ausfallzeiten während des Upgrades zu vermeiden.
- vSAN-Speicherrichtlinien auf FTT von 0 ändern:Ändern Sie VMs, die mit einer vSAN-Speicherrichtlinie für einen FTT-Wert von 0 konfiguriert sind, in eine vSAN-Speicherrichtlinie mit einem FTT-Wert von 1, um das SLA erfüllen zu können.
- VM-CD-Bereitstellungen entfernen: Entfernen Sie alle CDs, die auf Ihren Arbeitslast-VMs bereitgestellt sind und nicht mit vMotion kompatibel sind.
- VMware-Tool-Installationen abschließen:Schließen Sie alle Installationen oder Upgrades von VMware-Tools ab, bevor Sie das geplante Upgrade starten.
- SCSI-Bus-Freigabe auf VMs entfernen: Entfernen Sie die SCSI-Bus-Freigabe auf VMs, wenn die VMs nicht deaktiviert werden sollen.
- Unzugängliche VMs und Datenspeicher entfernen:Entfernen Sie nicht verwendete und nicht zugängliche VMs aus dem vCenter-Bestand. Entfernen Sie alle nicht zugänglichen externen Datenspeicher.
- DRS-Regeln (Distributed Resource Scheduler) deaktivieren:DRS-Regeln, die eine VM an einen Host anheften, verhindern, dass ein Knoten in den Wartungsmodus wechselt. Sie können die DRS-Regeln vor dem Upgrade deaktivieren und nach Abschluss des Upgrades wieder aktivieren.
- VMware-Add-ons und Lösungen von Drittanbietern aktualisieren:Prüfen Sie, ob VMware-Add-ons und Drittanbieterlösungen, die in Ihrem Private Cloud-vCenter bereitgestellt werden, mit den oben genannten Versionen nach dem Upgrade kompatibel sind. Beispiele für Tools sind Tools für Sicherung, Monitoring, Orchestrierung der Notfallwiederherstellung und ähnliche Funktionen. Um eine Kompatibilität nach dem Upgrade zu gewährleisten, kontaktieren Sie den Anbieter der jeweiligen Lösung und aktualisieren Sie diese vorab, falls nötig.
Dauer des Upgrades und Hintergrundprozesse
Die folgenden Faktoren können sich auf die Dauer des Upgrades auswirken:
- vSAN-Neusynchronisierungen: Die Dauer des Upgradeprozesses, insbesondere das Entfernen temporärer Knoten, hängt von den Anforderungen an die vSAN-Datenneusynchronisierung ab. vSAN-Neusynchronisierungs- und Cluster-Neuausgleichsaufgaben können über das vorgesehene Wartungsfenster hinausgehen. Das sind erwartete Hintergrundprozesse, die die Verfügbarkeit von Arbeitslasten nicht beeinträchtigen.
- Probleme mit der zugrunde liegenden Hardware: In seltenen Fällen können Hostneustarts während des Upgrades zugrunde liegende Hardwarefehler aufdecken. Um das SLA und den Clusterstatus aufrechtzuerhalten, hat das System Priorität, die fehlerhafte Hardware zu ersetzen, bevor es fortfährt. Dieser erforderliche Eingriff kann die Gesamtdauer des Upgrades verlängern.
Konfigurationen, die sich auf Wartungsprozesse auswirken können
VMware Engine nutzt den Wartungsmodus von VMware, um Upgrades, Updates und die Knotenwartung durchzuführen. So wird der kontinuierliche Betrieb Ihrer Private Cloud-Arbeitslasten sichergestellt. Für die folgenden Konfigurationen sind jedoch möglicherweise zusätzliche Schritte erforderlich, bevor ein Knoten in den Wartungsmodus wechseln kann:
- DRS-Regeln:MUST-Regeln, die VMs zwingen, auf einem bestimmten Knoten zu bleiben.
- SCSI-Bus-Freigabe:VMs, die für die Freigabe von SCSI-Bussen konfiguriert sind.
- CD-ROM-Bereitstellungen:VMs mit angehängten CD-ROMs, insbesondere wenn diese CD-ROMs nicht mit vMotion auf einen anderen Knoten verschoben werden können.
- Verbindungen über den seriellen Port:VMs, die Verbindungen über den seriellen Port verwenden, können nicht mit vMotion auf einen anderen Knoten verschoben werden.
- Raw Device Mappings (RDM): VMs, die direkt auf physische Speichergeräte zugreifen.
Wenn eine Aktion erforderlich ist
Wenn eine dieser Konfigurationen auf einem Knoten vorhanden ist, werden Sie von Cloud Customer Care mindestens 24 Stunden vor den erforderlichen Maßnahmen zur Aufrechterhaltung der Verfügbarkeit Ihrer privaten Cloud benachrichtigt. In einigen Fällen können Schritte wie das Herunterfahren einer VM, das Verschieben mit vMotion und das anschließende Hochfahren oder das Entfernen von CD-ROMs Ihre Arbeitslast kurz unterbrechen.
Nächste Schritte
- Weitere Informationen zur Sicherheit von VMware Engine.