Regionale Ansichten für stabile Lesevorgänge der Steuerungsebene verwenden

Abhängigkeiten der Steuerungsebene sind die APIs und Metadatendienste, mit denen Ressourcendefinitionen in Ihren Anwendungen verwaltet werden. Um hochverfügbare, robuste Anwendungen zu erstellen und Bereitstellungsabläufe in Compute Engine zu automatisieren, ist es entscheidend, diese Abhängigkeiten zu isolieren. Globale API-Endpunkte bieten zwar strikte Konsistenz in allen Regionen, aber jeder vorübergehende Latenzspitzen oder jede Unterbrechung in der globalen Steuerungsebene oder in einer Remote-Region kann lokale Dienste verzögern oder blockieren.

Um zuverlässige Anwendungen zu erstellen, die globale API-Unterbrechungen überstehen und unabhängig in jeder Region funktionieren können, können Sie Ihre Dienste so konfigurieren, dass regionale Ansichten globaler Ressourcen abgefragt werden. Wenn Sie regionalisierte schreibgeschützte API-Endpunkte zum Lesen von Ressourcendefinitionen verwenden, kommuniziert Ihre Anwendung ausschließlich mit der Steuerungsebene für eine bestimmte Region. Diese regionale Fehlerisolation sorgt dafür, dass Ihre Dienste auch bei globalen Unterbrechungen hochverfügbar und reaktionsschnell bleiben.

Unterstützte Ressourcentypen

Endpunkte für regionale Ansichten sind für die folgenden globalen Ressourcen verfügbar:

  • Projekte: Der Endpunkt projectViews bietet regionalen schreibgeschützten Zugriff auf die globale Projektressource.
  • Betriebssystem-Images: Der Endpunkt imageViews bietet regionalen Lesezugriff auf globale Betriebssystem-Image-Ressourcen.

Beschränkungen

Metadaten für alle globalen Ressourcen werden in einer zentralen globalen Datenbank gespeichert. Wenn Sie eine Ressource mit standardmäßigen globalen API-Endpunkten erstellen, lesen, aktualisieren oder löschen, fordert Compute Engine Lesevorgänge aus der zentralen globalen Datenbank an und schreibt direkt in diese Datenbank, wodurch eine strikte Konsistenz gewährleistet wird.

Endpunkte für regionale Ansichten lesen Ressourcenmetadaten aus regionalen Lesezugriff-Replikaten der zentralen globalen Datenbank. Da Änderungen asynchron in diese regionalen Replikate kopiert werden, kann es beim Abfragen regionaler Ansichten zu den folgenden Verhaltensweisen kommen:

  • Geringe Verzögerungen: Wenn Sie eine Ressource global erstellen, aktualisieren oder löschen, kann es bis zu 60 Sekunden dauern, bis diese Änderung in alle regionalen Ansichtsendpunkte kopiert wurde. Während dieses kurzen Zeitraums können beim Lesen aus einer regionalen Ansicht etwas ältere Daten zurückgegeben werden.
  • Automatisches Fallback: Wenn Sie eine Ressource aus einer regionalen Ansicht anfordern bevor sie in diese Region kopiert wurde, liest Compute Engine automatisch direkt aus der zentralen globalen Datenbank, damit Ihre Anfrage trotzdem erfolgreich ist.

Unterschiede zwischen regionaler Ansicht und globaler API

Auf den folgenden Tabs werden die Unterschiede zwischen Endpunkten für regionale Ansichten und standardmäßigen globalen API-Endpunkten für jeden Ressourcentyp zusammengefasst:

Projekte

In den folgenden Tabellen werden die Unterschiede zwischen Endpunkten für regionale Ansichten und standardmäßigen globalen API-Endpunkten für die Projektressource zusammengefasst:

Funktion Globale API Regionale Ansichts-API
Endpunkt Global Regional
Ressourcen-URL /projects/PROJECT_ID /projects/PROJECT_ID/regions/REGION/projectViews
Fehlerhafte Domain Global Auf die angegebene Region beschränkt
Unterstützte Methoden Lese- und Schreibzugriff Nur Lesezugriff (Get)
API-Kontingent Verbraucht globale API-Kontingent-Buckets für Lese- und Schreibvorgänge Verbraucht regionale API-Kontingent-Buckets für Lesevorgänge
Read-after-write Consistency Strikt konsistent (Lesevorgänge aus der zentralen globalen Datenbank) Eventual Consistency (Lesevorgänge aus dem regionalen Replikat)
Verhalten des Kontingentfelds Gibt das Array quota zurück und verwendet regionenübergreifende Fanouts, um Echtzeitdaten zur Kontingentnutzung in allen Regionen und Zonen bereitzustellen. Das quota Array ist aus dem zurückgegebenen Project Objekt ausgeschlossen. Da der projectViews Endpunkt ausschließlich aus einem regionalen Replikat liest und keine regionenübergreifenden Fanouts ausführt, um Kontingentmesswerte zu erfassen, wird das quota Array überhaupt nicht zurückgegeben. Informationen zu Kontingentkonfiguration limits und genauen Echtzeit-Nutzungsmesswerten erhalten Sie durch Abfragen des globalen projects.get Endpunkts.

Betriebssystem-Images

In den folgenden Tabellen werden die Unterschiede zwischen Endpunkten für regionale Ansichten und standardmäßigen globalen API-Endpunkten für die Betriebssystem-Image-Ressource zusammengefasst:

Funktion Globale API Regionale Ansichts-API
Endpunkt Global Regional
Ressourcen-URL /projects/PROJECT_ID/global/images /projects/PROJECT_ID/regions/REGION/imageViews
Fehlerhafte Domain Global Auf die angegebene Region beschränkt
Unterstützte Methoden Lese- und Schreibzugriff Nur Lesezugriff (Get und List)
API-Kontingent Verbraucht globale API-Kontingent-Buckets für Lese- und Schreibvorgänge Verbraucht regionale API-Kontingent-Buckets für Lesevorgänge
Read-after-write Consistency Strikt konsistent (Lesevorgänge aus der zentralen globalen Datenbank) Eventual Consistency (Lesevorgänge aus dem regionalen Replikat)

Preise

Der Zugriff auf regionale Ansichten über regionale Lesezugriff-API-Endpunkte verursacht keine zusätzlichen Kosten. Wie bei standardmäßigen globalen Compute Engine API-Anfragen werden bei Anfragen an Endpunkte für regionale Ansichten die standardmäßigen API-Kontingente Ihres Projekts verbraucht, insbesondere regionale API-Lesekontingente, aber es fallen keine zusätzlichen Gebühren an.

Best Practices für Hochverfügbarkeit

Um die Anwendungsstabilität zu maximieren, eine übermäßige Belastung der Steuerungsebene zu verhindern und Hotspots in einzelnen Regionen zu vermeiden, sollten Sie beim Konfigurieren automatisierter Systeme und Clientarbeitslasten die folgenden Best Practices für die Zuverlässigkeit beachten:

  • Lokale Regionen abfragen, um den betroffenen Bereich zu reduzieren: Senden Sie projectViews und imageViews API-Anfragen an die genaue Region, in der Ihre Clientarbeitslast oder Ihr Bereitstellungscluster ausgeführt wird. Verwenden Sie für zonale Arbeitslasten die übergeordnete Region. Durch das Lokalisieren von Lesevorgängen wird sichergestellt, dass eine Netzwerkunterbrechung oder ein Ausfall in einer anderen Region keine Auswirkungen auf Ihren lokalen Dienst hat.
  • Regionsstrings dynamisch erkennen: Verwenden Sie keine fest codierten Standardregion strings in gemeinsam genutzten Clientbibliotheken oder Bereitstellungsvorlagen. Erkennen Sie stattdessen die aktuelle Ausführungsregion der Arbeitslast dynamisch aus der lokalen Laufzeitumgebung, damit multiregionale Failover transparent funktionieren.
  • Regionale Kontingentisolation gegen konkurrierende Arbeitslasten verwenden: Compute Engine erzwingt API-Ratenbegrenzungen pro Region. Trafficspitzen oder fehlerhafte Skripts in einer Region verbrauchen Lesekontingent aus dem Bucket dieser bestimmten Region, ohne die API-Verfügbarkeit zu beeinträchtigen oder Ratenlimits (429 Too Many Requests) in Ihren anderen kritischen Regionen auszulösen.

Nächste Schritte