Regionale und multiregionale Konfigurationen

Auf dieser Seite werden Instanzkonfigurationen und die beiden Arten von Instanzkonfigurationen beschrieben, die Cloud Spanner bietet: regionale Konfigurationen und multiregionale Konfigurationen. Außerdem werden die Vor- und Nachteile von regionalen und multiregionalen Konfigurationen beschrieben.

Instanzkonfigurationen

Über eine Instanzkonfiguration werden die geografische Platzierung und Replikation der Datenbanken in der jeweiligen Instanz definiert. Instanzen werden bei der Erstellung entweder als regional (alle Ressourcen befinden sich in nur einer Google Cloud-Region) oder als multiregional (die Ressourcen verteilen sich auf mehrere Regionen) konfiguriert. Sie treffen diese Auswahl, indem Sie eine Instanzkonfiguration auswählen, durch die bestimmt wird, wo die Daten für diese Instanz gespeichert werden.

Sie können die Instanzkonfiguration ändern. Folgen Sie dazu der Anleitung unter Schritte zum Verschieben einer Instanz. Allgemeine Informationen zum Verschieben einer Instanz finden Sie unter Instanzen in eine andere Konfiguration verschieben.

Regionale Konfigurationen

Google Cloud-Dienste sind an Standorten in Nordamerika, Südamerika, Europa, Asien und Australien verfügbar. Wenn sich Ihre Nutzer und Dienste in einer einzigen Region befinden, sollten Sie eine regionale Instanzkonfiguration wählen, um die Latenz bei Lese- und Schreibvorgängen möglichst gering zu halten.

Verfügbare Konfigurationen

Cloud Spanner bietet folgende regionale Instanzkonfigurationen:

Name der Region Beschreibung der Region
Amerika
northamerica-northeast1 Montreal Blattsymbol Niedriger CO2-Wert
northamerica-northeast2 Toronto Blattsymbol Niedriger CO2-Wert
southamerica-east1 São Paulo Blattsymbol Niedriger CO2-Wert
southamerica-west1 Santiago
us-central1 Iowa Blattsymbol Niedriger CO2-Wert
us-east1 South Carolina
us-east4 Northern Virginia
us-west1 Oregon Blattsymbol Niedriger CO2-Wert
us-west2 Los Angeles
us-west3 Salt Lake City
us-west4 Las Vegas
Europa
europe-central2 Warschau
europe-north1 Finnland Blattsymbol Niedriger CO2-Wert
europe-west1 Belgien Blattsymbol Niedriger CO2-Wert
europe-west2 London
europe-west3 Frankfurt
europe-west4 Niederlande
europe-west6 Zürich Blattsymbol Niedriger CO2-Wert
Asia Pacific
asia-east1 Taiwan
asia-east2 Hongkong
asia-northeast1 Tokio
asia-northeast2 Osaka
asia-northeast3 Seoul
asia-south1 Mumbai
asia-south2 Delhi
asia-southeast1 Singapur
asia-southeast2 Jakarta
australia-southeast1 Sydney
australia-southeast2 Melbourne

Für jede regionale Konfiguration verwaltet Cloud Spanner drei nicht schreibgeschützte Replikate, wobei sich jedes Replikat in der jeweiligen Region in einer anderen Zone von Google Cloud befindet. Jedes nicht schreibgeschützte Replikat enthält eine vollständige Kopie der operativen Datenbank, die Lese-Schreib-Anforderungen und schreibgeschützte Anforderungen verarbeiten kann. Cloud Spanner greift auf Replikate in verschiedenen Zonen zurück, damit die Datenbank auch dann verfügbar ist, wenn es in einer einzelnen Zone zu einem Ausfall kommt.

Replikation

Regionale Konfigurationen enthalten genau drei nicht schreibgeschützte Replikate. Wie im Artikel zum Thema Replikation beschrieben, ist für jede Cloud Spanner-Mutation ein Schreibquorum erforderlich, das sich aus einer Mehrheit der votierenden Replikate zusammensetzt. Schreibquoren werden aus zwei der drei in regionalen Konfigurationen vorhandenen Replikate gebildet.

Best Practices

Beachten Sie die folgenden Best Practices, um eine optimale Leistung zu erzielen:

  • Erstellen Sie ein Schema, das Hotspots und andere Leistungsprobleme verhindert.
  • Platzieren Sie wichtige Compute-Ressourcen in derselben Region wie die Cloud Spanner-Instanz.
  • Stellen Sie genügend Rechenkapazität bereit, um die Auslastung von CPUs mit hoher Priorität unter 65 % zu halten.

Leistung

Wenn Sie die oben beschriebenen Best Practices befolgen, kann 1 Knoten Rechenkapazität (1.000 Verarbeitungseinheiten) bis zu 10.000 Abfragen pro Sekunde (queries per second, QPS) für Lesevorgänge bzw. 2.000 Abfragen pro Sekunde für Schreibvorgänge bereitstellen (Schreiben einzelner Zeilen mit 1 KB Daten pro Zeile).

Multiregionale Konfigurationen

Wie oben beschrieben, werden bei regionalen Konfigurationen von Cloud Spanner Daten zwischen mehreren Zonen innerhalb einer Region repliziert. Wenn Ihre Anwendung jedoch häufig Daten aus mehreren geografischen Standorten lesen muss (z. B. um diese für Nutzer in Nordamerika und Asien verfügbar zu machen) oder wenn Ihre Schreibvorgänge einem anderen Standort entstammen als Ihre Lesevorgänge (z. B. bei umfangreichen Arbeitslasten an Schreibvorgängen in Nordamerika und Lesevorgängen in Europa), ist eine regionale Konfiguration möglicherweise nicht ideal.

Bei multiregionalen Konfigurationen können die Daten der Datenbank nicht nur in mehreren Zonen, sondern in mehreren Zonen, die auf mehrere Regionen verteilt sind, repliziert werden – so wie in der Instanzkonfiguration festgelegt. Mithilfe dieser zusätzlichen Replikate können Sie Daten mit geringer Latenz aus mehreren Standorten lesen, die sich in der Nähe oder innerhalb der Regionen der Konfiguration befinden. Hieraus ergeben sich sowohl Vor- als auch Nachteile. In einer multiregionalen Konfiguration sind die für ein Quorum benötigten (nicht schreibgeschützten) Replikate auf mehr als eine Region verteilt. Daher kann zusätzliche Netzwerklatenz auftreten, wenn diese Replikate miteinander kommunizieren, um über das Festschreiben von Schreibvorgängen abzustimmen. Dies bedeutet, dass Ihre Anwendung in multiregionalen Konfigurationen Lesevorgänge an mehr Orten schneller ausführen kann, was jedoch eine etwas höhere Schreiblatenz nach sich zieht.

Verfügbare Konfigurationen

Ein Kontinent

Name Ort Nicht schreibgeschützte Regionen Schreibgeschützte Regionen Zeugen-Region
asia1 Asien Tokyo: asia-northeast1 L,2R
Osaka: asia-northeast2 2R		 – Seoul: asia-northeast3
eur3 Europa Belgien: europe-west1 L,2R
Niederlande: europe-west4 2R		 – Finnland: europe-north1
eur5 Europa London: europe-west2 L,2R
Belgien: europe-west1 2R		 – Niederlande: europe-west4
eur6 Europa Niederlande: europe-west4 L,2R
Frankfurt: europe-west3 2R		 – Zürich: europe-west6
nam3 Nordamerika Northern Virginia: us-east4 L,2R
South Carolina: us-east1 2R		 – Iowa: us-central1
nam6 Nordamerika Iowa: us-central1 L,2R
South Carolina: us-east1 2R		 Oregon: us-west1 1R
Los Angeles: us-west2 1R		 Oklahoma: us-central2
nam7 Nordamerika Iowa: us-central1 L,2R
Northern Virginia: us-east4 2R		 – Oklahoma: us-central2
nam8 Nordamerika Los Angeles: us-west2 L,2R
Oregon: us-west1 2R		 – Salt Lake City: us-west3
nam9 Nordamerika Northern Virginia: us-east4 L,2R
Iowa: us-central1 2R		 Oregon: us-west1 2R South Carolina: us-east1
nam10 Nordamerika Iowa: us-central1 L,2R
Salt Lake City: us-west3 2R		 – Oklahoma: us-central2
nam11 Nordamerika Iowa: us-central1 L,2R
South Carolina: us-east1 2R		 – Oklahoma: us-central2
nam12 Nordamerika Iowa: us-central1 L,2R
Northern Virginia: us-east4 2R		 Oregon: us-west1 2R Oklahoma: us-central2

  • L: Standardmäßig führende Region

  • 1R: 1 Replikat in der Region

  • 2R: 2 Replikate in der Region

Drei Kontinente

Name Orte Nicht schreibgeschützte Regionen Schreibgeschützte Regionen Zeugen-Region
nam-eur-asia1 Nordamerika
Europa
Asien		 Iowa: us-central1 L,2R
Oklahoma: us-central2 2R		 Belgien: europe-west1 2R
Taiwan: asia-east1 2R		 South Carolina: us-east1

Vorteile

Multiregionale Instanzen bieten folgende große Vorteile:

  • Verfügbarkeit von 99,999 %: Dies übersteigt die Verfügbarkeit von 99,99 %, die regionale Konfigurationen von Cloud Spanner bieten.

  • Datenverteilung: Cloud Spanner repliziert die Daten automatisch zwischen Regionen, in denen hohe Konsistenz garantiert wird. So können Ihre Daten dort gespeichert werden, wo sie verwendet werden, wodurch die Latenz verringert werden kann.

  • Externe Konsistenz: Obwohl Cloud Spanner Daten in geografisch weit voneinander entfernten Standorten repliziert, können Sie Cloud Spanner wie eine auf nur einem Computer ausgeführten Datenbank verwenden. Für Transaktionen wird die Serialisierbarkeit garantiert. Außerdem gleicht die Reihenfolge der Transaktionen in der Datenbank der Reihenfolge, in der Clients feststellen, ob die Transaktionen festgeschrieben wurden. Durch externe Konsistenz wird dahingehend eine bessere Garantie geboten, als durch die Strong Consistency (hohe Konsistenz), welche von einigen anderen Produkten geboten wird. Weitere Informationen zu diesem Attribut erhalten Sie unter TrueTime und externe Konsistenz.

Replikation

Jede multiregionale Konfiguration enthält zwei Regionen, die als nicht schreibgeschützte Regionen festgelegt sind, von denen jede zwei nicht schreibgeschützte Replikate enthält. Eine dieser nicht schreibgeschützten Regionen wird als standardmäßig führende Region festgelegt. Dies bedeutet, dass sie die Leader-Replikate Ihrer Datenbank enthält. Cloud Spanner platziert außerdem ein Zeugenreplikat in einer dritten Region, die als Zeugenregion bezeichnet wird.

Jedes Mal, wenn ein Client eine Mutation für Ihre Datenbank ausgibt, bildet sich ein Schreibquorum, das aus einem der Replikate aus der standardmäßig führenden Region und zwei beliebigen der zusätzlichen vier abstimmenden Replikate besteht. (Das Quorum könnte aus Replikaten aus zwei oder drei der Regionen Ihrer Konfiguration gebildet werden, abhängig davon, welche anderen Replikate an der Abstimmung teilnehmen.) Zusätzlich zu diesen fünf votierenden Replikaten kann die Konfiguration auch schreibgeschützte Replikate zum Verarbeiten von Lesevorgängen mit niedriger Latenz enthalten. Die Regionen mit schreibgeschützten Replikaten werden als schreibgeschützte Regionen bezeichnet.

Im Allgemeinen werden in einer multiregionalen Konfiguration die votierenden Regionen geografisch nah beieinander platziert, d .h., weniger als 1.609 km voneinander entfernt, damit ein Quorum mit niedriger Latenz für schnelle Schreibvorgänge gebildet werden kann (weitere Informationen). Dennoch sind die Regionen weit genug voneinander entfernt – in der Regel mindestens einige hundert Meilen (ein Vielfaches von 161 km) – damit koordinierte Ausfälle vermieden werden können.

In den nächsten Abschnitten werden die einzelnen Regionstypen genauer beschrieben. Außerdem wird erläutert, wie Sie Ihre Auslastung an Schreib- und Lesevorgängen entsprechend am besten verteilen.

Regionstypen

Nicht schreibgeschützte Regionen

Wie oben beschrieben, enthält jede multiregionale Konfiguration zwei nicht schreibgeschützte Regionen, die jeweils zwei nicht schreibgeschützte Replikate enthalten. Eine dieser Regionen mit Lese- / Schreibzugriff wird als Standard-Leader-Region festgelegt. Für die Aufteilung wird bei den Replikaten in der standardmäßig führenden Region für jeden Split ein Leader ausgewählt. Wenn ein Leader-Replikatfehler ausfällt, geht das andere Replikat in der standardmäßig führenden Region automatisch nach Leader. Tatsächlich führen Leader Eigendiagnosen durch und können daher präventiv ihre Funktion als Leader abgeben, wenn sie feststellen, dass ihre Integrität kompromittiert wurde. Unter normalen Bedingungen, also wenn Replikate in der standardmäßig führenden Region verfügbar sind, enthält die standardmäßig führende Region die Leader. Schreibvorgänge werden daher im Normalfall dort zuerst verarbeitet.

Die zweite nicht schreibgeschützte Region enthält die zusätzlichen Replikate, die als Leader fungieren können. Für den unwahrscheinlichen Fall des Verlusts aller Replikate in der standardmäßig führenden Region werden aus der zweiten nicht schreibgeschützten Region neue Leader-Replikate ausgewählt.

Sie können die führende Region einer Datenbank konfigurieren. Folgen Sie dazu der Anleitung unter Führende Region einer Datenbank ändern. Allgemeine Informationen zum Konfigurieren der führenden Region finden Sie unter Standardmäßig führende Region konfigurieren.

Schreibgeschützte Regionen

Schreibgeschützte Regionen enthalten schreibgeschützte Replikate, die Lesevorgänge mit niedriger Latenz für Clients ausführen können, die sich außerhalb der nicht schreibgeschützten Regionen befinden.

Zeugenregionen

Eine Zeugenregion enthält ein Zeugenreplikat, welches zum Abstimmen über das Festschreiben von Schreibvorgängen verwendet wird. Zeugen werden in dem seltenen Fall wichtig, wenn die nicht schreibgeschützten Regionen nicht mehr verfügbar sind.

Best Practices

Beachten Sie die folgenden Best Practices, um eine optimale Leistung zu erzielen:

  • Erstellen Sie ein Schema, das Hotspots und andere Leistungsprobleme verhindert.
  • Zum Erzielen einer optimalen Schreiblatenz sollten Sie die Rechenressourcen für schreibintensive Arbeitslasten innerhalb oder in der Nähe der standardmäßig führenden Region platzieren.
  • Zum Erzielen einer optimalen Leseleistung außerhalb der standardmäßig führenden Region sollten Sie als Schwellwert für die Veralterung mindestens 15 Sekunden einstellen.
  • Platzieren Sie wichtige Compute-Ressourcen in mehreren Regionen, damit Sie vermeiden können, dass Arbeitslasten von einer einzigen Region abhängig sind. Eine gute Option ist, sie neben den beiden verschiedenen Regionen mit Lese-/Schreibzugriff zu platzieren, damit ein Ausfall einer Region nicht Ihre gesamte Anwendung beeinträchtigt.
  • Stellen Sie genügend Rechenkapazität bereit, um die Auslastung von CPUs mit hoher Priorität unter 45 % in jeder Region zu halten.

Leistung

Jede Cloud Spanner-Konfiguration weist auf Grundlage der Replikationstopologie etwas unterschiedliche Leistungseigenschaften auf.

Wenn die oben beschriebenen Best Practices eingehalten werden, kann jeweils 1 Knoten (1.000 Verarbeitungseinheiten) Rechenkapazität folgende ungefähre Leistung liefern:

Multiregionale Konfiguration Ungefährer Spitzenwert für Lesevorgänge (QPS pro Region) Ungefährer Spitzenwert für Schreibvorgänge (QPS insgesamt)
asia1 7.000 1.800
eur3 7.000 1.800
eur5 7.000 1.800
eur6 7.000 1.800
nam3 7.000 1.800
nam6 7.000 in us-central1 und us-east1
3.500 in us-west1 und us-west2 [1]		 1.800
nam7 7.000 1.800
nam8 7.000 1.800
nam9 7.000 1.800
nam10 7.000 1.800
nam11 7.000 1.800
nam12 7.000 1.800
nam-eur-asia1 7.000 1.000

  • [1]: us-west1 und us-west2 bieten nur die Hälfte der QPS-Leistung, da sie nur ein Replikat pro Region enthalten, nicht zwei.

Beachten Sie, dass die Orientierungswerte für Lesevorgänge für jede Region einzeln angegeben werden, da Lesevorgänge von überall aus bedient werden können, während sich die Orientierungswerte für Schreibvorgänge auf die gesamte Konfiguration beziehen. Bei den Orientierungswerten für Schreibvorgänge wird davon ausgegangen, dass einzelne Zeilen mit 1 KB Daten pro Zeile geschrieben werden.

Instanzen in eine andere Konfiguration verschieben

Sie können Ihre Instanz aus einer beliebigen Instanzkonfiguration in eine andere Instanzkonfiguration verschieben, auch zwischen regionalen und multiregionalen Konfigurationen.

Das Verschieben der Instanz verursacht keine Ausfallzeiten und Cloud Spanner bietet weiterhin die üblichen Transaktionsgarantien für eine Verschiebung, einschließlich strikter Konsistenz.

Schritte zum Verschieben einer Instanz

  1. Rufen Sie in der Cloud Console die Seite Spanner-Instanzen auf.

    Zur Seite "VM-Instanzen"

  2. Klicken Sie auf den Namen der Instanz, die Sie löschen möchten.

    In der Cloud Console wird die Seite Übersicht der Instanz angezeigt.

  3. Wenn Sie den Wechsel zu einer neuen Instanzkonfiguration planen möchten, klicken Sie auf Google kontaktieren und füllen das Cloud Spanner-Formular für Anfragen zur Live-Migration von Instanzen aus (Vorschau).

    • Sie benötigen die Berechtigung spanner.instances.update, um einen Wechsel zu einer neuen Instanzkonfiguration anzufragen.
    • Nachdem das Formular gesendet wurde, kontaktiert Google Sie, um die Änderung der Instanzkonfiguration zu planen.

Einschränkungen beim Verschieben einer Instanz

  • Sie können jeweils nur eine Instanz in einem Projekt verschieben.
  • Durch das Verschieben einer Instanz werden nicht der Name, die ID oder die Projekt-ID der Instanz geändert.
  • Während der Migration sollten Sie keine Änderungen an der Instanz vornehmen. Dies schließt das Ändern der Instanzknotenanzahl, das Ändern von Datenbankschemas, das Erstellen oder Löschen von Datenbanken oder das Erstellen oder Löschen von Sicherungen ein.
  • Cloud Spanner-Sicherungen sind für eine Instanzkonfiguration spezifisch und werden beim Verschieben einer Instanz nicht einbezogen. Nach dem Verschieben einer Instanz in die neue Instanzkonfiguration werden alle Sicherungen der alten Instanzkonfiguration gelöscht.
  • Sie können die Instanzkonfiguration einer Instanz mit CMEK-fähigen Datenbanken derzeit nicht ändern.

Leistungsaspekte beim Verschieben einer Instanz

Wenn eine Instanz verschoben wird, hat die Instanz höhere Lese-/Schreiblatenzen und eine höhere Transaktionsabbruchrate.

Die Migration sollte in der Regel innerhalb von zwölf Stunden abgeschlossen sein. Einige Migrationen können abhängig von der Größe und anderen Eigenschaften der Instanz länger dauern. Google informiert Sie dann darüber, wann die Instanz migriert werden kann.

Alle Datenbanken in der Instanz werden gleichzeitig migriert. Da Clientanwendungen mehrere sequenzielle Aufrufe an Cloud Spanner ausführen können, ist die Erhöhung der Extremwertlatenz möglicherweise höher als die Erhöhung der Cloud Spanner-Latenz.

Nach der Migration einer Instanz variiert die Leistung der Instanz abhängig von den Details der Instanzkonfiguration. So haben beispielsweise multiregionale Konfigurationen im Allgemeinen eine höhere Schreiblatenz und eine geringere Leselatenz als regionale Konfigurationen.

Standardmäßig führende Region konfigurieren

Sie können den Standort der Standard-Leader-Region für Ihre Datenbank ändern, um näher an den Clients zu arbeiten, um die Anwendungslatenz zu verringern.

Sie können die führende Region für jede Cloud Spanner-Instanz ändern, die eine Konfiguration mit mehreren Regionen verwendet. Eine Anleitung zum Ändern des Standorts der führenden Region finden Sie unter Führende Region einer Datenbank ändern. Die einzigen Regionen, die als standardmäßig führende Region für Ihre Datenbank verwendet werden können, sind die nicht schreibgeschützten Regionen in Ihrer multiregionalen Konfiguration.

Die Leader-Region ist für die Verarbeitung aller Datenbankschreibvorgänge verantwortlich. Wenn also der Großteil Ihres Traffics aus einer geografischen Region stammt, sollten Sie ihn in diese Region verschieben, um die Latenz zu reduzieren. Die Aktualisierung der Standard-Leader-Region ist günstig und umfasst keine Datenverschiebungen. Es kann einige Minuten dauern, bis der neue Wert wirksam wird.

Das Ändern der standardmäßigen Leader-Region ist eine Schemaänderung, bei der ein Vorgang mit langer Ausführungszeit verwendet wird. Bei Bedarf können Sie den Status des lang andauernden Vorgangs abrufen.

Vor- und Nachteile von regionalen und multiregionalen Konfigurationen

Konfiguration Verfügbarkeit Latenz Kosten Datenlokalität
Regionale Instanzen 99,99 % Geringere Schreiblatenzen innerhalb der Region Geringere Kosten; siehe Preise Aktiviert die geografische Datenverwaltung
Multiregionale Instanzen 99,999 % Geringere Leselatenzen für mehrere geografische Regionen Höhere Kosten; siehe Preise Daten werden auf mehrere Regionen innerhalb der Konfiguration repliziert

Nächste Schritte