Wartung und Aktualisierungen der privaten Cloud

Private Cloud-Umgebungen sind so konzipiert, dass sie keinen Single Point of Failure haben:

  • 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 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
  • Native 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 Asseta 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 die Häufigkeit voraussichtlich abnehmen. Diese Art der Wartung kann in der Regel durchgeführt werden, 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 der VMware-Software (ESXi, vCenter, PSC und NSX) in privaten Clouds verantwortlich.

Zu den Softwareupdates gehören:

  • Patches:von VMware veröffentlichte Sicherheitspatches oder Fehlerkorrekturen
  • Updates: geringfügige Versionsänderung einer VMware-Stack-Komponente
  • Upgrades: Hauptversion einer VMware-Stack-Komponente

Die VMware Engine testet kritische Sicherheitspatches, sobald sie von VMware verfügbar sind. Gemäß SLA wird ein Roll-out von Sicherheitspatches innerhalb einer Woche nach Verfügbarkeit in privaten Cloud-Umgebungen durchgeführt.

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 wendet Hauptversions-Upgrades mindestens sechs Monate nach der Veröffentlichung der Hauptversion an und benachrichtigt Kunden einen Monat vor der Anwendung von Hauptversions-Upgrades.

VMware Engine arbeitet auch mit wichtigen Anbietern aus der Branche zusammen, um sicherzustellen, dass sie die neueste VMware-Softwareversion unterstützen, bevor ein Upgrade auf eine Hauptversion eingeführt wird. Informationen zum Support für bestimmte Anbieter erhältst du vom Google Cloud-Kundenservice.

Verantwortung für die Aktualisierung von Zertifikaten

Die Aktualisierung von Zertifikaten liegt in der Verantwortung von Google. Wenn Sie einen Fehler beim Aktualisieren des Zertifikats erhalten, müssen Sie nichts weiter tun. Das Zertifikat wird vor Ablauf verlängert. Wenn LDAPS jedoch in Ihrer privaten Cloud konfiguriert ist, sind Sie allein für das mit diesem Fehler verknüpfte Zertifikat verantwortlich.

Vorbereitung

Google empfiehlt, vor dem Starten 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 Auslastung über 80 % liegt, 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 mit 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 zu erfüllen.
  • 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.
  • Nicht zugängliche VMs und Datenspeicher entfernen:Entfernen Sie nicht verwendete und nicht zugängliche VMs aus dem vCenter-Inventar. 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.
  • 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.

Konfigurationen, die sich auf Wartungsabläufe auswirken können

VMware Engine nutzt den Wartungsmodus von VMware, um Upgrades, Updates und Knotenwartungen durchzuführen. So wird der reibungslose Betrieb Ihrer Arbeitslasten in der Private Cloud sichergestellt. Bei den folgenden Konfigurationen sind jedoch möglicherweise zusätzliche Schritte erforderlich, bevor ein Knoten in den Wartungsmodus wechseln kann:

  • DRS-Regeln: MUST-Regeln, die VMs dazu 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.
  • Serielle Portverbindungen:VMs mit seriellen Portverbindungen, die verhindern, dass sie mit vMotion zu einem anderen Knoten verschoben werden.
  • Raw Device Mappings (RDM): VMs, die direkt auf physische Speichergeräte zugreifen.

Wenn Maßnahmen erforderlich sind

Wenn eine dieser Konfigurationen auf einem Knoten vorhanden ist, werden Sie von Cloud Customer Care mindestens 24 Stunden vor der Behebung benachrichtigt, die erforderlich ist, um die Verfügbarkeit Ihrer privaten Cloud aufrechtzuerhalten. In einigen Fällen kann es zu kurzen Unterbrechungen Ihrer Arbeitslast kommen, wenn Sie z. B. eine VM ausschalten, sie mit vMotion verschieben und dann wieder einschalten oder CD-ROMs entfernen.

Nächste Schritte