Auf dieser Seite werden Best Practices für eine hohe Verfügbarkeit Ihrer Google Distributed Cloud Connected-Installation beschrieben. Für Distributed Cloud Connected wird kein Service Level Agreement (SLA) angeboten. Es wird nur die auf dieser Seite beschriebene Anleitung bereitgestellt.
Verfügbarkeitsstufe auswählen und implementieren
Sie müssen die Verfügbarkeitsstufe für Ihre mit Distributed Cloud verbundenen Arbeitslasten auswählen, die Ihren geschäftlichen Anforderungen am besten entspricht. Beispielsweise hat eine Self-Checkout-Anwendung in einem Einzelhandelsgeschäft ein viel geringeres Verfügbarkeitsrisiko als eine Edge-RAN-Bereitstellung eines Mobilfunknetzbetreibers.
Die Distributed Cloud Connected-Software verbraucht auf jeder physischen Maschine einige Ressourcen. Die Menge variiert je nach der spezifischen Konfiguration Ihrer mit Distributed Cloud verbundenen Bereitstellung. Die Arbeitslastresilienz hängt von der zusätzlichen Rechen- und Speicherkapazität ab, die Sie auf Ihren Knoten reservieren, um Hardwareneustarts und Knotenausfälle zu kompensieren. Google empfiehlt, Arbeitslasten mit Ressourcenkontingenten zu konzipieren, damit die verbleibenden Knoten während der Wartung oder bei Komponentenfehlern genügend Spielraum haben. Die Zielverfügbarkeit ist direkt proportional zur Kapazität der Distributed Cloud Connected-Ersatzressourcen, die Sie für Notfälle reservieren. Diese Schätzungen berücksichtigen keine Ausfallzeiten, die für ein Wartungsfenster geplant sind.
Es kann zu einem plötzlichen Kapazitätsverlust kommen, z. B. aufgrund eines Hardwarefehlers oder eines Knotens, der neu gestartet werden muss. Dazu müssen Sie Ihre Arbeitslasten unter Berücksichtigung der Ressourcenkontingente entwerfen, damit Sie auf jedem mit Distributed Cloud verbundenen Knoten immer verfügbare Kapazität haben, die dem von Ihnen gewählten Verfügbarkeitsniveau entspricht.
Distributed Cloud-Zonen geografisch diversifizieren
Um die Auswirkungen potenzieller Fehler in der Steuerungsebene zu minimieren, empfehlen wir dringend, Ihre Distributed Cloud-Zonen auf mehrere benachbarte Regionen zu verteilen.
Webhook-Hochverfügbarkeit
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 Ihre 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 mit Distributed Cloud verbundenen Hardware ausgeführt wird. Ihre Arbeitslasten werden weiterhin ausgeführt, wenn die Verbindung zu Google Cloud unterbrochen wird. Weitere Informationen finden Sie unter Überlebensmodus für Distributed Cloud Connected.
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 mit Distributed Cloud verbundenen Cluster individuelle Wartungszeiträume 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 Wartungszeiträumen:
- Wartungsfenster Gibt ein Zeitfenster an, in dem Google Wartungsarbeiten und Software-Upgrades für Ihren mit Distributed Cloud verbundenen Cluster durchführen kann.
- Wartungsausschlussfenster: Gibt ein Zeitfenster an, in dem Google keine Wartungsarbeiten oder Softwareupgrades für Ihren mit Distributed Cloud verbundenen 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 Software-Upgrade oder eine Wartungsaufgabe nicht vor dem Ende eines Wartungsfensters abgeschlossen wird, pausiert Distributed Cloud Connected das Upgrade oder die Aufgabe und setzt es im nächsten geplanten Wartungsfenster fort. Wenn ein Software-Upgrade fehlschlägt, wird das Upgrade von Distributed Cloud Connected angehalten. 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 Ihren 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 finden Sie unter Wartungsfenster konfigurieren.
Gestaffelte Softwareupdates
Um Ausfallzeiten von Arbeitslasten zu reduzieren, werden Softwareupdates für Distributed Cloud-Verbindungen gestaffelt. Mit anderen Worten: Google führt Upgrades für Worker-Knoten in jedem mit Distributed Cloud verbundenen Cluster stufenweise durch. Alle Worker-Knoten in einer Software-Upgrade-Phase werden gleichzeitig heruntergefahren.
Sie haben auch die Möglichkeit, die Größe der einzelnen Phasen selbst festzulegen. Mit anderen Worten: Sie können die Anzahl der Knoten angeben, die in einem Distributed Cloud Connect-Cluster gleichzeitig für ein Software-Upgrade ausfallen können. Eine Anleitung finden Sie unter Knotenausfallzeiten 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 allgemeiner gehaltene 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 derGoogle Cloud -Konsole werden Zeiten in der lokalen Zeitzone angezeigt.
Bei Verwendung detaillierterer Flags wie --maintenance-window-start können Sie die Zeitzone als Teil des Werts 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 Informationen zu Ihrem Cluster in der Google Cloud Console abrufen, werden die Zeiten immer entsprechend Ihrer lokalen Zeitzone angegeben.
- Wenn Sie Informationen zu Ihrem 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 angeben. In diesem Zeitfenster wird Google angewiesen, die Distributed Cloud-Software nur zu der von Ihnen angegebenen Zeit und Häufigkeit zu aktualisieren.
Für Wartungszeiträume für verbundene Cluster von Distributed Cloud gelten die folgenden Regeln:
- Wenn Sie ein Wartungsfenster für einen mit Distributed Cloud verbundenen Cluster angeben, aktualisiert Google Ihre mit Distributed Cloud verbundene Software 48 Stunden nach der Ankündigung des Updates über die Versionshinweise für mit Distributed Cloud verbundene Cluster. Auf der Seite mit den Versionshinweisen können Sie den RSS-Feed für 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. Sie können je nach Komplexität Ihrer Distributed Cloud Connected-Installation und Ihren Geschäftsanforderungen einen längeren Zeitraum angeben.
- Die Mindesthäufigkeit von Software-Updates beträgt einmal pro Woche. Sie können entweder wöchentliche oder tägliche Wartungsfenster angeben. Sie können bestimmte Tage ein- und ausschließen.
- Sie können den Zeitplan für das Wartungsfenster eines Clusters jederzeit ändern, es sei denn, ein Wartungsfenster wurde bereits geplant oder ist gerade aktiv.
- 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 defekter Hardware
Wenn eine mit Distributed Cloud verbundene Maschine ausfällt, sind Sie für den Austausch der gesamten Maschine im Rahmen Ihrer Hardwaregarantie oder Ihres SI-Wartungsvertrags verantwortlich. Google überwacht die mit Distributed Cloud verbundene Software und den Knotenstatus. Wenn wir ein Hardwareproblem erkennen, werden Sie über Cloud Monitoring benachrichtigt. Bevor die Maschine von Ihrem Standort entfernt wird, versucht Google, die Daten von allen Festplatten sicher zu löschen. Sie sind für zusätzliche Schritte zur Bereinigung der Festplatte gemäß der Servicevereinbarung mit Ihrem von Google zertifizierten SI verantwortlich.
Weitere Fehlerquellen
Sie sind für die folgenden Aspekte Ihrer Distributed Cloud-Installation verantwortlich, die außerhalb der Kontrolle von Google liegen und sich auf die Verfügbarkeit von Distributed Cloud Connected auswirken können:
- Alle Daten, die Sie auf mit Distributed Cloud verbundener Hardware speichern. Dazu gehören funktionierende redundante Sicherungen und der Export Ihrer Daten, bevor Sie Ihre mit Distributed Cloud verbundene Hardware an Google zurücksenden.
- Stromversorgung
- Umgebungstemperatur, Luftfeuchtigkeit und Kühlung.
- Physische Hardwaresicherheit:
- Sicherheit des lokalen Netzwerks
- Lokales Netzwerk und Internetverbindung. Distributed Cloud Connected muss alle 7 Tage eine neue Verbindung zu Google Cloud herstellen, um Sicherheitstokens und Verschlüsselungsschlüssel zu aktualisieren und Protokollierungs- und Verwaltungsdaten zu synchronisieren.