Best Practices für die Verfügbarkeit

Auf dieser Seite werden Best Practices beschrieben, mit denen Sie eine Hochverfügbarkeit für Ihre Google Distributed Cloud Connected-Installation gewährleisten können. Für Distributed Cloud Connected wird kein Service Level Agreement (SLA) angeboten. Es gilt nur das Service Level Objective (SLO), das auf dieser Seite beschrieben wird.

Verfügbarkeitsstufe auswählen und implementieren

Sie müssen die Verfügbarkeitsstufe für Ihre Distributed Cloud Connected-Arbeitslasten auswählen, die am besten zu Ihren geschäftlichen Anforderungen passt. Beispielsweise ist das Verfügbarkeitsrisiko bei einer Self-Checkout-Anwendung in einem Einzelhandelsgeschäft viel geringer als bei einer Edge-RAN-Bereitstellung eines Mobilfunkanbieters.

Die Zielverfügbarkeit ist direkt proportional zur Distributed Cloud-Ersatzressourcenkapazität, die Sie für Notfälle reservieren. In der folgenden Tabelle wird diese Beziehung beschrieben. Diese Schätzungen enthalten nicht die Ausfallzeiten, die mit einem Wartungsfenstergeplant wurden.

Die Distributed Cloud Connected-Software verbraucht auf jeder physischen Maschine einige Ressourcen. Die Menge variiert je nach der spezifischen Konfiguration Ihrer Distributed Cloud Connected-Bereitstellung. Google empfiehlt, Ihre Distributed Cloud Connected-Bereitstellung zu benchmarken, um diese Menge zu messen und sie bei der Planung der Arbeitslastverteilung zu berücksichtigen.

Verwendete Kapazität Reservierte Kapazität Zielverfügbarkeit
66,6% 33,3% 99,9%

Aufgrund eines Hardwarefehlers oder eines Knotens, der neu gestartet werden muss, kann es zu einem plötzlichen Kapazitätsverlust kommen. Um sich darauf vorzubereiten, müssen Sie Ihre Arbeitslasten mit Ressourcenkontingenten planen, damit Sie auf jedem Distributed Cloud Connected-Knoten immer verfügbare Kapazität haben, die der von Ihnen gewählten Verfügbarkeitsstufe entspricht.

Distributed Cloud-Zonen geografisch diversifizieren

Um die Auswirkungen potenzieller Fehler auf der Verwaltungsebene, empfehlen wir dringend, Ihre Distributed Cloud-Zonen auf mehrere benachbarte Regionen zu verteilen.

Hochverfügbarkeit von Webhooks

Behandeln Sie Webhooks als geschäftskritische Dienste. Wir empfehlen folgende Best Practices für die Hochverfügbarkeit von Webhooks:

  • Führen Sie mindestens zwei Replikate des Webhook-Pods aus.
  • Verwenden Sie topologySpreadConstraints, um Webhook-Pod-Replikate auf verschiedene physische Knoten zu verteilen.
  • Legen Sie die CPU- und Arbeitsspeicherlimits sorgfältig fest, um zu verhindern, dass Ihre Webhook-Pods entfernt werden, wenn der Cluster stark ausgelastet ist.

Überlebensmodus verwenden

Distributed Cloud-Cluster verwenden eine lokale Steuerungsebene, die auf Ihrer Distributed Cloud Connected-Hardware ausgeführt wird. Ihre Arbeitslasten werden weiterhin ausgeführt wenn die Verbindung zu Google Cloud unterbrochen wird. Weitere Informationen finden Sie unter Überlebensmodus von Distributed Cloud Connected mode.

Softwareupdates und Wartungsfenster

Google aktualisiert die Distributed Cloud Connected-Software regelmäßig. Diese Softwareupdates sind obligatorisch und können nicht deaktiviert werden. Mit Distributed Cloud Connected können Sie für jeden Ihrer Distributed Cloud Connected-Cluster individuelle Wartungsfenster festlegen.

Mit Wartungsfenstern können Sie steuern, wann automatische Upgrades von Steuerungsebenen und Knoten stattfinden dürfen, um potenzielle vorübergehende Unterbrechungen Ihrer Arbeitslasten zu minimieren. Wartungsfenster sind unter anderem für die folgenden Szenarios hilfreich:

  • Außerhalb der Hauptbetriebszeiten: Sie möchten die Wahrscheinlichkeit von Ausfallzeiten minimieren und automatische Upgrades außerhalb der Hauptbetriebszeiten planen, wenn der Traffic reduziert ist.
  • Auf Abruf: Sie möchten, dass Upgrades während der Geschäftszeiten stattfinden, damit die Prozesse überwacht und unerwartete Probleme sofort behoben werden können.
  • Multi-Cluster-Upgrades:Sie möchten Upgrades in mehreren Clustern in verschiedenen Regionen nacheinander und in bestimmten Intervallen durchführen.

Distributed Cloud Connected unterstützt die folgenden Arten von Wartungsfenstern:

  • Wartungsfenster Gibt ein Zeitfenster an, in dem Google Wartungsarbeiten und Softwareupgrades für Ihren Distributed Cloud Connected-Cluster durchführen kann.
  • Wartungsausschlussfenster Gibt ein Zeitfenster an, in dem Google keine Wartungsarbeiten oder Softwareupgrades für Ihren Distributed Cloud Connected-Cluster durchführen kann. Wenn Sie ein Wartungsausschlussfenster konfigurieren möchten, müssen Sie zuerst ein Wartungsfenster konfigurieren. Ein Wartungsausschlussfenster hat Vorrang vor dem Wartungsfenster des Clusters.

Neben automatischen Upgrades muss Google gelegentlich weitere Wartungsaufgaben ausführen. In diesen Fällen wird nach Möglichkeit das Wartungsfenster eines Clusters berücksichtigt.

Wenn ein Softwareupgrade oder eine Wartungsaufgabe nicht vor dem Ende eines Wartungsfensters abgeschlossen wird, pausiert Distributed Cloud Connected das Upgrade oder die Aufgabe und setzt es während des nächsten geplanten Wartungsfensters fort. Wenn ein Softwareupgrade fehlschlägt, beendet Distributed Cloud Connected das Upgrade. In solchen Fällen müssen Sie sich an den Google-Support wenden, um Ihre Softwareinstallation zu reparieren.

Distributed Cloud Connected behält sich das Recht vor, ungeplante Notfallupgrades außerhalb von Wartungsfenstern durchzuführen. Außerdem können obligatorische Upgrades von eingestellter oder veralteter Software automatisch außerhalb von Wartungsfenstern erfolgen.

Sie können Cluster auch jederzeit manuell aktualisieren. Manuell initiierte Upgrades werden unmittelbar und unabhängig von Wartungsfenstern ausgeführt.

Informationen zum Einrichten eines Wartungsfensters für einen neuen oder vorhandenen Cluster, siehe Wartungsfenster konfigurieren.

Gestaffelte Softwareupdates

Um die Ausfallzeiten von Arbeitslasten zu reduzieren, werden Softwareupdates für Distributed Cloud Connected gestaffelt. Das bedeutet, dass Google Worker-Knoten in jedem Distributed Cloud Connected-Cluster in Phasen aktualisiert. Alle Worker-Knoten in einer Softwareupgradephase werden gleichzeitig heruntergefahren.

Sie können auch die Größe Ihrer eigenen Softwareupgradephase festlegen. Mit anderen Worten: Sie können die Anzahl der Knoten angeben, die gleichzeitig für ein Softwareupgrade in einem Distributed Cloud Connected-Cluster heruntergefahren werden können. Eine Anleitung finden Sie unter Ausfallzeiten von Knoten bei Softwareupgrades verwalten.

Beschränkungen

Für Wartungsfenster gelten die folgenden Einschränkungen:

  • Ein Wartungsfenster pro Cluster Sie können nur ein einziges Wartungsfenster pro Cluster konfigurieren. Durch die Konfiguration eines neuen Wartungsfensters wird das vorangegangene außer Kraft gesetzt.

  • Zeitzonen für Wartungsfenster Wenn Wartungsfenster konfiguriert und eingesehen werden, werden die Zeiten je nach verwendetem Tool unterschiedlich angezeigt, wie in den folgenden Abschnitten beschrieben.

Bei der Konfiguration von Wartungsfenstern

Wenn Sie das allgemeinere Flag --maintenance-window verwenden, um ein Wartungsfenster zu konfigurieren, können Sie keine Zeitzone angeben. Wenn Sie die Google Cloud CLI oder die API verwenden, werden Zeiten in UTC angezeigt. In der Google Cloud Console werden Zeiten in der lokalen Zeitzone angezeigt.

Bei Verwendung detaillierterer Flags wie --maintenance-window-start können Sie die Zeitzone als Teil des Wertes angeben. Wenn Sie die Zeitzone weglassen, wird Ihre lokale Zeitzone verwendet. Uhrzeiten werden immer in UTC gespeichert.

Bei der Ansicht von Wartungsfenstern

Wenn Sie Informationen zu Ihrem Cluster ansehen, werden Zeitstempel für Wartungsfenster möglicherweise in UTC oder in Ihrer lokalen Zeitzone angezeigt. Dies ist davon abhängig, auf welche Weise Sie die Informationen anzeigen lassen:

  • Wenn Sie die Google Cloud Console verwenden, um Informationen zu Ihrem Cluster einzusehen, werden die Zeiten immer in Ihrer lokalen Zeitzone angezeigt.
  • Wenn Sie Informationen zum Cluster mit der gcloud CLI abrufen, werden die Zeiten immer in UTC angegeben.

In beiden Fällen ist die RRULE immer in UTC. Das heißt, wenn Sie beispielsweise Tage der Woche angeben, sind diese Tage in UTC angegeben.

Wartungsfenster für Cluster konfigurieren

Mit Distributed Cloud Connected können Sie für jeden Ihrer Distributed Cloud Connected-Cluster ein Wartungsfenster festlegen. In diesem Fenster wird Google angewiesen, die Distributed Cloud-Software nur zu der von Ihnen angegebenen Zeit und Häufigkeit zu aktualisieren.

Für Wartungsfenster für Distributed Cloud Connected-Cluster gelten die folgenden Regeln:

  • Wenn Sie ein Wartungsfenster für einen Distributed Cloud Connected-Cluster angeben, aktualisiert Google Ihre Distributed Cloud Connected-Software 48 Stunden nach der Ankündigung des Updates in den Versionshinweisen zu Distributed Cloud Connected. Auf der Seite mit den Versionshinweisen können Sie den RSS-Feed für die Versionshinweise zu Distributed Cloud Connected abonnieren, um über Softwareupdates informiert zu werden, sobald sie veröffentlicht werden.
  • Die Mindestdauer eines Wartungsfensters beträgt fünf Stunden. Je nach Komplexität Ihrer Distributed Cloud Connected-Installation und Ihren geschäftlichen Anforderungen können Sie ein längeres Fenster angeben.
  • Die Mindesthäufigkeit von Softwareupdates beträgt einmal pro Woche. Sie können wöchentliche oder tägliche Wartungsfenster angeben. Sie können bestimmte Tage ein- und ausschließen.
  • Sie können den Wartungsfensterplan für einen Cluster jederzeit ändern, es sei denn, ein Wartungsfenster wurde bereits geplant oder ist in Bearbeitung.
  • Wenn das Softwareupdate nicht innerhalb des angegebenen Zeitfensters abgeschlossen wird, wird es pausiert und dann während des nächsten geplanten Wartungsfensters fortgesetzt.

Eine ausführliche Anleitung finden Sie unter Wartungsfenster für einen Cluster konfigurieren.

Reparatur von ausgefallener Hardware

Wenn Google einen Fehler an der Distributed Cloud Connected-Hardware feststellt, führen wir einen der folgenden Schritte aus:

  • Bei Google-eigener Distributed Cloud-Hardware versucht Google, innerhalb von drei Werktagen einen Vor-Ort-Termin zu vereinbaren. Damit ein von Google autorisierter Techniker die erforderliche Diagnose und Reparaturen durchführen kann, müssen Sie ihm Zugriff auf die Distributed Cloud Connected-Hardware gewähren.

  • Bei Distributed Cloud-Hardware im Besitz des Kunden benachrichtigt Google Sie und den von Google zertifizierten Systemintegrator über das Problem. Sie müssen mit dem Systemintegrator zusammenarbeiten, der Ihre Distributed Cloud Connected-Hardware geliefert hat, um einen Termin mit einem Techniker zu vereinbaren und die erforderliche Diagnose und Reparaturen durchzuführen.

Wenn ein Fehler an der Distributed Cloud Connected-Hardware auftritt, ersetzt Google oder ein von Google zertifizierter Systemintegrator die gesamte Maschine. Bevor die Maschine von Ihrem Standort entfernt wird, sorgt Google dafür, dass Ihre Daten sicher von allen Laufwerken gelöscht wurden.

Weitere Fehlerquellen

Sie sind für die folgenden Aspekte Ihrer Distributed Cloud-Installation verantwortlich, die außerhalb der Kontrolle von Google liegen und die Verfügbarkeit von Distributed Cloud Connected beeinträchtigen können:

  • Alle Daten, die Sie auf der Distributed Cloud Connected-Hardware speichern. Dazu gehören funktionierende redundante Back-ups und der Export Ihrer Daten, bevor Sie Ihre Distributed Cloud Connected-Hardware an Google zurücksenden.
  • Stromversorgung
  • Umgebungstemperatur, Luftfeuchtigkeit und Kühlung.
  • Physische Hardwaresicherheit.
  • Lokale Netzwerksicherheit.
  • Lokale Netzwerk- und Internetverbindung Distributed Cloud Connected muss alle 7 Tage eine Verbindung zu Google Cloud herstellen, um Sicherheitstokens und Verschlüsselungsschlüssel zu aktualisieren und Logging- und Verwaltungsdaten zu synchronisieren.

Nächste Schritte