Auf dieser Seite werden Best Practices für eine hohe Verfügbarkeit Ihrer Google Distributed Cloud-Installation beschrieben. Für Distributed Cloud wird kein Service Level Agreement (SLA) angeboten. Es gilt nur das auf dieser Seite beschriebene Service Level Objective (SLO).
Verfügbarkeitsstufe auswählen und implementieren
Sie müssen die Verfügbarkeitsstufe für Ihre Distributed Cloud-Arbeitslasten auswählen, die Ihren geschäftlichen Anforderungen am besten entspricht. Beispielsweise ist das Verfügbarkeitsrisiko einer Self-Checkout-Anwendung in einem Einzelhandelsgeschäft viel geringer als das einer Edge-RAN-Bereitstellung eines Mobilfunknetzbetreibers.
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 berücksichtigen nicht die Ausfallzeiten, die mit einem Wartungsfenster geplant sind.
Die Software von Distributed Cloud Connected verbraucht auf jeder physischen Maschine einige Ressourcen. Die Menge variiert je nach der spezifischen Konfiguration Ihrer mit Distributed Cloud verbundenen Bereitstellung. Google empfiehlt, die mit Distributed Cloud verbundene Bereitstellung zu benchmarken, um diesen Betrag zu messen und bei der Planung der Arbeitslastverteilung zu berücksichtigen.
| Genutzte Kapazität | Reservierte Kapazität | Verfügbarkeit von Zielen |
|---|---|---|
| 83,33% | 16,67% | 99,9 % |
| 100 % | 0 % | 93,5% |
Aufgrund eines Hardwarefehlers oder eines Knotens, der neu gestartet werden muss, kann es zu einem plötzlichen Kapazitätsverlust kommen. Dazu müssen Sie Ihre Arbeitslasten so konzipieren, dass die Ressourcenkontingente berücksichtigt werden. So haben Sie auf jedem Distributed Cloud-Knoten immer verfügbare Kapazität, die dem von Ihnen gewählten Verfügbarkeitsniveau entspricht.
Um beispielsweise eine Zielverfügbarkeit von 99,9% zu erreichen, müssen Sie Ihre Arbeitslasten so konfigurieren, dass eine der sechs physischen Maschinen in jedem Distributed Cloud-Cluster als Backup verfügbar ist.
Überlebensmodus verwenden
Mit Distributed Cloud können Sie Cluster erstellen, die eine lokale Steuerungsebene verwenden, die auf Ihrer Distributed Cloud-Hardware ausgeführt wird. In solchen Clustern können Arbeitslasten weiter ausgeführt werden, wenn die Verbindung zu Google Cloud unterbrochen wird. Weitere Informationen finden Sie unter Distributed Cloud-Überlebensmodus.
Softwareupdates und Wartungsfenster
Google aktualisiert die Distributed Cloud-Software regelmäßig. Diese Softwareupdates sind obligatorisch und können nicht deaktiviert werden. Mit Distributed Cloud können Sie für jeden Ihrer Distributed Cloud-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.
Neben automatischen Upgrades muss Google gelegentlich weitere Wartungsaufgaben ausführen. In diesen Fällen wird das Wartungsfenster eines Clusters nach Möglichkeit berücksichtigt.
Wenn Aufgaben länger dauern als das Wartungsfenster geöffnet ist, versucht Distributed Cloud, die Aufgaben zu pausieren. Anschließend wird versucht, diese Aufgaben während des nächsten Wartungsfensters fortzusetzen.
Distributed Cloud 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.
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 zum Konfigurieren eines Wartungsfensters verwenden, 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 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 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 können Sie für jeden Ihrer Distributed Cloud-Cluster ein Wartungsfenster festlegen. In diesem Zeitraum aktualisiert Google die Distributed Cloud-Software nur zu den von Ihnen angegebenen Zeiten und in der von Ihnen angegebenen Häufigkeit.
Für Wartungszeiträume für Distributed Cloud-Cluster gelten die folgenden Regeln:
- Wenn Sie ein Wartungsfenster für einen Distributed Cloud-Cluster angeben, aktualisiert Google Ihre Distributed Cloud-Software 48 Stunden nach der Ankündigung des Updates in den Versionshinweisen zu Distributed Cloud. Auf der Seite mit den Versionshinweisen können Sie den RSS-Feed für die Versionshinweise zu Distributed Cloud abonnieren, um über Softwareupdates informiert zu werden, sobald sie veröffentlicht werden.
- Die Mindestdauer eines Wartungsfensters beträgt sechs Stunden. Sie können je nach Komplexität Ihrer Distributed Cloud-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 Wartungsfensterplan für einen Cluster 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 ausgefallener Hardware
Wenn Google einen Hardwarefehler in Distributed Cloud erkennt, wird versucht, innerhalb von drei Arbeitstagen einen Termin für einen Besuch vor Ort zu vereinbaren. Damit ein von Google autorisierter Techniker die erforderlichen Diagnosen und Reparaturen durchführen kann, müssen Sie ihm Zugriff auf die Distributed Cloud-Hardware gewähren.
Wenn ein Fehler in der Distributed Cloud-Hardware auftritt und Google Reparaturen vor Ort durchführt, werden alle Speichermedien aus dem zu wartenden Distributed Cloud-Computer entfernt und für die Dauer der Reparatur in Ihre Obhut gegeben.
Andere 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 auswirken können:
- Alle Daten, die Sie auf Distributed Cloud-Hardware speichern. Dazu gehören funktionierende redundante Back-ups und der Export Ihrer Daten, bevor Sie Ihre Distributed Cloud-Hardware an Google zurücksenden.
- Stromversorgung:
- Umgebungstemperatur, Luftfeuchtigkeit und Kühlung.
- Physische Hardwaresicherheit:
- Sicherheit des lokalen Netzwerks
- Lokales Netzwerk und Internetverbindung. Distributed Cloud erfordert eine ständige Verbindung zu Google Cloud und kann ohne diese nicht funktionieren.