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.

Die VMware Engine überwacht kontinuierlich die Verfügbarkeit, und bietet SLAs zur Verfügbarkeit für die folgenden VM-Typen:

  • 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, mit der Zeit ab. 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

Die VMware Engine ist für die Lebenszyklusverwaltung von VMware verantwortlich (ESXi, vCenter, PSC und NSX) in privaten Clouds.

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, VMware Engine koordiniert gemeinsam mit Kunden ein geeignetes Wartungsfenster zum Anwenden des Upgrades. VMware Engine Upgrades der Hauptversion mindestens sechs Monate nach Veröffentlichung der Hauptversion und informiert Kunden einen Monat vor der Anwendung von Hauptversionsupgrades.

Die VMware Engine arbeitet auch mit den wichtigsten Branchenanbietern zusammen, um sicherzustellen, unterstützen sie die neueste VMware-Softwareversion, bevor eine größere Versionsupgrade. Informationen zum Support für bestimmte Anbieter erhalten Sie hier: Cloud Customer Care.

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, die folgenden Vorbereitungen zu treffen, bevor Sie ein Update starten oder Upgrade:

  • Speicherkapazität prüfen: Speicherplatz des vSphere-Clusters prüfen liegt die Auslastung bei unter 80 %, damit das SLA eingehalten wird. 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 erfüllen zu können.
  • VM-CD-Bereitstellungen entfernen:Entfernen Sie alle CDs, die auf Ihren Arbeitslast-VMs bereitgestellt sind, sind nicht mit vMotion kompatibel.
  • 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-Inventar. Entfernen Sie alle nicht zugänglichen externen Datenspeicher.
  • DRS-Regeln (Distributed Resource Scheduler) deaktivieren: DRS-Regeln, VM zu einem Host verhindert, dass ein Knoten in den Wartungsmodus wechselt. Sie können Folgendes deaktivieren: DRS-Regeln vor dem Upgrade und aktivieren Sie sie nach dem Upgrade abgeschlossen ist.
  • 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. Kontaktieren Sie den Lösungsanbieter und informieren Sie sich im Voraus. wenn nötig, um die Kompatibilität nach dem Upgrade sicherzustellen.

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 privaten Cloud sichergestellt. Bei den folgenden Konfigurationen sind jedoch möglicherweise zusätzliche Schritte erforderlich, bevor ein Knoten in den Wartungsmodus wechseln kann:

  • DRS-Regeln: MÜSSEN-Regeln, die VMs dazu zwingen, auf einem bestimmten Knoten zu bleiben.
  • SCSI-Bus-Freigabe: VMs, die für die gemeinsame Nutzung von SCSI-Bussen konfiguriert sind.
  • CD-ROM-Bereitstellungen:VMs mit angeschlossenen CD-ROMs, insbesondere wenn diese CD-ROMs verwendet werden können mit vMotion nicht auf einen anderen Knoten verschoben werden.
  • Verbindungen mit seriellen Ports:VMs mit Verbindungen zu seriellen Ports, die verhindern, dass sie mithilfe von vMotion nicht auf einen 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 vom Cloud-Kundenservice 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, mit vMotion verschieben und dann wieder einschalten oder CD-ROMs entfernen.

Nächste Schritte