Bereitstellungskonfigurationen

In diesem Dokument werden Bereitstellungskonfigurationen für Spanner Omni auf VMs oder Bare-Metal-Servern beschrieben. Darin werden die Struktur und die Konfigurationsoptionen für die YAML-Bereitstellungskonfigurationsdatei (deployment.yaml) erläutert, die zum Definieren von VM-Bereitstellungstopologien und Laufzeitparametern bei Verwendung der Spanner Omni CLI verwendet wird.

Informationen zum Erstellen eines Deployments finden Sie in einem der folgenden Artikel:

Übersicht über die Bereitstellungskonfiguration

Wenn Sie eine Bereitstellung auf VMs oder Bare-Metal-Servern erstellen, übergeben Sie diese Konfigurationsdatei an den Befehl spanner deployment create in der Spanner Omni-Befehlszeile:

spanner deployment create --config-file=deployment.yaml

Die Bereitstellungskonfiguration definiert die folgenden Schlüsselelemente:

  • Einzelservermodus: Optimierungsmodus, der die gesamte Bereitstellung auf einen einzelnen Server für Entwicklung und Tests beschränkt.
  • Standorte: Physische Standorte oder Cloud-Regionen, in denen sich Ihre Server befinden.
  • Entfernungen zwischen Standorten: Netzwerklatenzen zwischen Standortpaaren.
  • Zonen: Logische Gruppierungen von Servern, die Paxos-Replikate darstellen.
  • Root-Server: Dedizierte Server, die für Zonenmetadaten und das Mitgliedschaftsquorum verantwortlich sind.
  • Replikattypen: Rollen für jede Zone (nicht schreibgeschützt, Zeuge oder schreibgeschützt).
  • SLA für die Synchronisierung: TrueTime-Synchronisierungsparameter, einschließlich Takt-Jitter und Drift-Rate-Fehler.
  • Bereitstellungseinstellungen: Globale Einstellungen wie bevorzugte Leader-Standorte und Authentifizierungssicherheitseinstellungen.

Struktur einer Konfigurationsdatei

Das folgende Beispiel zeigt die Struktur einer Bereitstellungskonfigurationsdatei auf oberster Ebene:

# Deployment name
name: regional-deployment

# Restrict the entire deployment to a single server (optional, default: false)
single_server: false

# Physical or logical locations (regions)
location:
  - name: us-central1

# Network distances between locations (optional)
location_distance:
  - src: us-central1
    dest: us-east1
    latency_ms: 30

# Zones and root servers in the deployment
zone:
  - name: us-central1-a
    location: us-central1
    single_server: false
    replica_type: READ_WRITE
    root_server:
      - host: rootserver1.example.internal
        port_base: 15000

# Clock synchronization SLA parameters (optional)
clock_sla:
  jitter_in_s: 0.005
  rate_error_in_ppm: 200

# Deployment settings (optional)
deployment_settings:
  preferred_leader_location: us-central1
  security_settings:
    insecure_mode: true

Felder der obersten Ebene

Die Bereitstellungskonfiguration unterstützt die folgenden Felder der obersten Ebene:

Feld Typ Beschreibung
name String Der Name der Bereitstellung, z. B. prod, staging oder regional-deployment.
single_server Boolesch Optional. Wenn auf true festgelegt, gibt dies an, dass die gesamte Bereitstellung eine Einzelserverbereitstellung ist, die auf eine Zone und einen Server beschränkt ist. Bei Bereitstellungen, die mit single_server: true erstellt wurden, können nach der Erstellung keine Zonen oder Server hinzugefügt werden. Wenn Sie Spanner Omni im Einzelservermodus ausführen möchten, müssen Sie diese Konfiguration nicht manuell erstellen, da Spanner Omni sie automatisch generiert, wenn Sie den Befehl spanner start-single-server ausführen. Der Standardwert ist false.
location Liste der Objekte Die physischen oder logischen Standorte (Regionen) in der Bereitstellung.
location_distance Liste der Objekte Optional. Die Netzwerklatenz zwischen Paaren von Standorten.
zone Liste der Objekte Erforderlich. Die Zonen, aus denen die Bereitstellung besteht. Sie müssen mindestens eine Zone angeben.
clock_sla Objekt Optional. Die Parameter des Service Level Agreement (SLA) für die Uhrzeitsynchronisierung für die Software TrueTime.
deployment_settings Objekt Optional. Laufzeiteinstellungen für die bevorzugte Platzierung des Leaders und die Sicherheitsauthentifizierung.

Bereitstellungsname

Im Feld name wird ein vom Nutzer ausgewählter Name für das Deployment angegeben. Sie können einen beliebigen String verwenden, der das Deployment identifiziert, z. B. prod, staging oder regional-deployment.

Einzelservermodus

Das single_server-Feld der obersten Ebene gibt an, dass die gesamte Bereitstellung eine Einzelserverbereitstellung ist. Wenn diese Einstellung auf true festgelegt ist, wird die Bereitstellung auf eine Zone und einen Server beschränkt. Dadurch wird der Ressourcenaufwand für lokale Entwicklungs- und Testumgebungen reduziert. Bei Bereitstellungen, die mit single_server:true erstellt wurden, können nach der Erstellung keine Zonen oder Server hinzugefügt werden.

Wenn Sie Spanner Omni im Einzelservermodus ausführen möchten, müssen Sie diese Konfiguration nicht manuell erstellen. Wenn Sie den Befehl spanner start-single-server ausführen, wird diese Konfiguration automatisch von Spanner Omni generiert. Weitere Informationen finden Sie unter Option A: Bereitstellung auf einem einzelnen Server.

Das Feld single_server auf oberster Ebene unterscheidet sich vom Feld single_server auf Zonen-Ebene:

  • Das Feld top-level single_server gilt für die gesamte Bereitstellung.
  • Das Feld zone-level single_server gilt nur für eine einzelne Zone innerhalb einer Bereitstellung. Weitere Informationen finden Sie unter Zonen mit einem einzelnen Server.

Standorte

Ein Standort steht für ein physisches Rechenzentrum oder eine Cloud-Region, in der sich Maschinen befinden (entspricht einer Region in Google Cloud).

Sie definieren Standorte in der Liste location:

location:
  - name: us-central1
  - name: europe-west2

Standortnamen müssen die folgenden Anforderungen erfüllen:

  • Muss mit einem Buchstaben beginnen und mit einem Buchstaben oder einer Ziffer enden.
  • Darf nur Buchstaben, Ziffern, Unterstriche (_) und Bindestriche (-) enthalten.
  • Kann optional ein Domainpräfix gefolgt von einem Doppelpunkt enthalten (z. B. cloud.google.com:us-east1 oder onprem:datacenter1).
  • Der reservierte Name default kann nicht verwendet werden.
  • Muss für die Bereitstellung eindeutig sein.

Entfernungen zwischen Standorten

In der Liste location_distance wird die Netzwerklatenz zwischen Paaren von Standorten angegeben. Spanner Omni verwendet diese Informationen, um die Replikation und das Abfragerouting zu optimieren.

location_distance:
  - src: us-central1
    dest: europe-west2
    latency_ms: 105
  - src: europe-west2
    dest: us-central1
    latency_ms: 110

Jedes Objekt für die Entfernung zwischen Standorten enthält die folgenden Felder:

  • src: Erforderlich. Der Name des Quellstandorts. Muss mit einem definierten Standort in der Liste location übereinstimmen.
  • dest: Erforderlich. Der Name des Zielorts. Muss mit einem definierten Standort übereinstimmen und darf nicht mit src identisch sein.
  • latency_ms: Die Netzwerklatenz in Millisekunden. Muss eine nicht negative Ganzzahl sein. Wenn dieser Parameter weggelassen wird, geht Spanner Omni davon aus, dass die Latenz vernachlässigbar ist (unter einer Millisekunde).

Die Netzwerklatenz in physischen Netzwerken ist nicht immer symmetrisch. Wenn Sie sowohl (src, dest) als auch (dest, src) angeben, werden beide Messungen in Spanner Omni berücksichtigt. Wenn Sie nur eine Richtung angeben, geht Spanner Omni davon aus, dass die umgekehrte Richtung dieselbe Latenz hat.

Zonen

Eine Zone ist eine logische Gruppierung von einem oder mehreren Servern an einem Standort. Bei der Datenreplikation stellt jede Zone ein Paxos-Replikat dar. Eine Bereitstellung muss mindestens eine Zone haben.

zone:
  - name: us-central1-a
    location: us-central1
    single_server: false
    replica_type: READ_WRITE
    root_server:
      - host: rootserver1.example.internal
        port_base: 15000
      - host: rootserver2.example.internal
        port_base: 15000
      - host: rootserver3.example.internal
        port_base: 15000

Jedes Zonenobjekt unterstützt die folgenden Felder:

Feld Typ Beschreibung
name String Erforderlich. Der Name der Zone. Es gelten dieselben Benennungsregeln wie für Ortsnamen. Muss für die Bereitstellung eindeutig sein.
location String Der Name des Standorts, an dem sich die Zone befindet. Muss mit einem definierten Standort in der Liste location übereinstimmen. Wenn nichts angegeben ist, weist Spanner Omni die Zone dem Standort default zu.
single_server Boolesch Optional. Wenn auf true gesetzt, gibt dies an, dass diese Zone nur einen einzelnen Server hat (kann nur einen Root-Server und keine anderen Server haben). Dadurch wird der Aufwand für die Replikation von Zonenmetadaten innerhalb der Zone reduziert. Bei einer Bereitstellung in mehreren Zonen können Sie diesen Wert für bestimmte Zonen auf true festlegen, z. B. für eine WITNESS-Replikat-Zone, in der keine Nutzerdaten gespeichert werden, während andere Zonen mehrere Server haben. Der Standardwert ist false.
replica_type Enum-String Die Replikatrolle der Zone in Paxos-Quoren. Unterstützte Werte sind READ_WRITE, WITNESS und READ_ONLY. Der Standardwert ist READ_WRITE.
root_server Liste der Objekte Erforderlich. Die Liste der Root-Server in der Zone.

Replikattypen

Spanner Omni unterstützt drei Replikattypen für Zonen:

  • READ_WRITE: Speichert eine vollständige Kopie der Nutzerdaten, verarbeitet Leseanfragen und stimmt in Paxos-Quoren ab. Replikate mit Lese-/Schreibzugriff können Paxos-Leader werden, um Schreibvorgänge vorzuschlagen.
  • WITNESS: Stimmen in Paxos-Quoren ab, um einen Konsens zu erzielen, können aber nicht zum Leader werden. In Witness-Replikaten werden keine Nutzerdaten gespeichert und sie können keine Leseanfragen bearbeiten. Sie tragen dazu bei, ein Quorum zu erreichen, ohne dass der Speicher-Aufwand oder die Schreiblatenz einer vollständigen Replik an entfernten Standorten entsteht.
  • READ_ONLY: Speichert eine vollständige Kopie der Nutzerdaten, die asynchron von den Leadern repliziert werden. Schreibgeschützte Replikate können nicht zu Leadern werden und stimmen nicht in Paxos-Quoren ab. Sie entlasten Replikate mit Lese-/Schreibzugriff von Lesezugriffen.

Achten Sie beim Konfigurieren von Replikatyptypen darauf, dass Ihr Deployment die folgenden Regeln erfüllt:

  • Die Bereitstellung muss mindestens eine READ_WRITE-Zone enthalten.
  • Die Anzahl der READ_WRITE-Zonen muss streng größer sein als die Anzahl der WITNESS-Zonen.

Root-Server

Root-Server haben in Spanner Omni besondere Aufgaben. Sie speichern Zonenmetadaten und verwalten die Mitgliedschaft für andere Server in der Zone. Wenn ein Quorum von Root-Servern nicht mehr verfügbar ist, ist die gesamte Zone nicht mehr verfügbar.

Beachten Sie beim Konfigurieren von Stammservern in deployment.yaml die folgenden Richtlinien:

  • Die Anzahl der Root-Server pro Zone muss eine ungerade Zahl zwischen 1 und 9 (einschließlich) sein, um die Konsistenz zu gewährleisten. Wenn die Anzahl der Server eine gerade Zahl ist, können Bereitstellungen fehlschlagen. Weisen Sie beim Konfigurieren Ihrer Zonen Server als Stammserver zu. Wir empfehlen, eine für die Entwicklung oder das Testen und drei für hochverfügbare Produktionszonen zu verwenden.
  • Geben Sie nur Root-Server in der Datei deployment.yaml an, wenn Sie die Erstellung der Ersteinrichtung vornehmen. Nicht-Root-Server können später hinzugefügt werden, um die Rechen- und Speicherkapazität zu skalieren.

Jedes Stammserverobjekt unterstützt die folgenden Felder:

  • host: Erforderlich. Der Hostname oder die IP-Adresse des Computers, auf dem der Server ausgeführt wird.
  • port_base: Optional. Die Startportnummer für den Server. Der Standardwert ist 15000. Dieser Port wird zum öffentlichen gRPC-Port für Clientverbindungen. Sie müssen Ports im Bereich [port_base + 1, port_base + 31] (z. B. 15001 bis 15031) für interne Spanner Omni-Prozesse reservieren.

Einzelserverzonen

Das Feld single_server auf Zonenebene gibt an, dass eine einzelne Zone nur einen Server enthält. Eine Einzelserverzone kann nur einen Root-Server haben und es können später keine zusätzlichen Server hinzugefügt werden. Diese Einstellung eliminiert den Aufwand für die Replikation von Zonenmetadaten innerhalb dieser Zone.

Im Gegensatz zum single_server-Feld der obersten Ebene, das angibt, dass die gesamte Bereitstellung aus einem einzelnen Server besteht, gilt das single_server-Feld auf Zonenebene nur für die jeweilige Zone.

In einem Multi-Zonen-Deployment können Sie einzelne Zonen als Einzelserverzonen konfigurieren, während andere Zonen mehrere Server enthalten. Angenommen, Sie haben eine Bereitstellung mit zwei READ_WRITE-Replikatzonen und einer WITNESS-Replikatzone:

  • Die beiden READ_WRITE-Zonen enthalten mehrere Server (single_server: false), um eine Hochverfügbarkeit zu gewährleisten und die Rechen- und Speicherkapazität für Nutzerdaten zu skalieren.
  • Sie können die WITNESS-Zone je nach Paxos-Abstimmungsvolumen als Einzelserverzone oder als Mehrserverzone konfigurieren:
    • Kleine bis mittelgroße Arbeitslasten: Wenn eine einzelne VM oder ein einzelner Server ausreichend Kapazität hat, um den gesamten Paxos-Abstimmungs-Traffic für die Bereitstellung zu verarbeiten, legen Sie single_server: true fest. Da Zeugenreplikate nur abstimmen und keine Nutzerdaten speichern, entfällt durch die Verwendung eines einzelnen Servers der Aufwand für die Metadatenreplikation innerhalb der Zone.
    • Bereitstellungen im großen Maßstab: Wenn Sie einen hohen Schreibdurchsatz oder viele Server in jeder READ_WRITE-Zone haben (z. B. Dutzende oder Hunderte von Knoten), kann ein einzelner Server überlastet werden und Paxos-Konsensfehler verursachen. Konfigurieren Sie die WITNESS-Zone mit mehreren Servern (single_server: false), um die Arbeitslast für die Abstimmung zu verteilen.

Ein Konfigurationsbeispiel finden Sie unter Bereitstellung an mehreren Standorten mit Witness-Replikat.

SLA für die Uhr

Spanner Omni verwendet Software-TrueTime, um externe Konsistenz zu gewährleisten, ohne dass spezielle GPS-Hardware oder Atomuhren erforderlich sind. Das Objekt clock_sla definiert die erwarteten Synchronisationsgrenzen für Serveruhren im gesamten Deployment:

clock_sla:
  jitter_in_s: 0.005
  rate_error_in_ppm: 200

Die clock_sla-Konfiguration enthält die folgenden Felder:

  • jitter_in_s: Der maximal erwartete Takt-Jitter in Sekunden. Muss eine nicht negative Gleitkommazahl (>= 0) sein.
  • rate_error_in_ppm: Der maximale Fehler bei der Taktabweichungsrate in Teilen pro Million (ppm). Muss ein Wert zwischen 0 und 10000 sein.

Weitere Informationen zur Zeitsynchronisierung finden Sie unter TrueTime und externe Konsistenz.

Bereitstellungseinstellungen

Mit dem deployment_settings-Objekt wird das globale Bereitstellungsverhalten konfiguriert, einschließlich der bevorzugten Leader-Position und der Netzwerksicherheit:

deployment_settings:
  preferred_leader_location: us-central1
  security_settings:
    insecure_mode: false
    authentication_methods:
      - AUTHENTICATION_METHOD_PASSWORD
      - AUTHENTICATION_METHOD_CLIENT_CERTIFICATE
    password_authentication_protocol: PASSWORD_AUTHENTICATION_PROTOCOL_OPAQUE

Bevorzugter Standort des Moderators

Das Feld preferred_leader_location gibt einen Ort an, an dem Paxos-Leader bevorzugt platziert werden. Wenn Sie Leader in der Nähe Ihrer primären Anwendungsworkload auswählen, wird die Schreiblatenz reduziert, da zusätzliche Netzwerk-Roundtrips vermieden werden.

Achten Sie bei der Konfiguration von preferred_leader_location auf Folgendes:

  • Der angegebene Standort muss mit einem definierten Standort in der Liste location (oder default) übereinstimmen.
  • Der angegebene Standort muss mindestens eine READ_WRITE-Zone enthalten.

Sicherheitseinstellungen

Mit dem security_settings-Objekt werden Authentifizierungs- und Verschlüsselungsmodi konfiguriert:

  • insecure_mode: Boolesch. Wenn auf true festgelegt, werden Authentifizierung und Autorisierung für eingehende Verbindungen deaktiviert. Dieser Modus ist nur für Prototypen und Tests vorgesehen. Der Standardwert ist false.
  • authentication_methods: Liste der aktivierten Authentifizierungsmethoden. Erforderlich, wenn insecure_mode false ist. Unterstützte Werte:
    • AUTHENTICATION_METHOD_PASSWORD: Aktiviert die Authentifizierung mit Nutzername und Passwort.
    • AUTHENTICATION_METHOD_CLIENT_CERTIFICATE: Aktiviert die gegenseitige TLS-Authentifizierung (mTLS) mit Clientzertifikaten.
  • password_authentication_protocol: Das für die Passwortbestätigung verwendete Protokoll. Erforderlich, wenn AUTHENTICATION_METHOD_PASSWORD in authentication_methods enthalten ist. Unterstützter Wert:
    • PASSWORD_AUTHENTICATION_PROTOCOL_OPAQUE: Verwendet das asymmetrische OPAQUE-Protokoll für den passwortauthentifizierten Schlüsselaustausch.

Weitere Informationen zum Einrichten von Verschlüsselung und Anmeldedaten finden Sie unter Bereitstellung mit TLS-Verschlüsselung auf VMs erstellen.

Beispiele für die Bereitstellungskonfiguration

Die folgenden Beispiele veranschaulichen gängige Bereitstellungsmuster.

Regionale Bereitstellung in mehreren Zonen

Mit der folgenden Konfiguration wird eine regionale Bereitstellung mit Hochverfügbarkeit in drei Zonen an einem einzigen Standort erstellt:

name: regional-prod
location:
  - name: us-central1
zone:
  - name: us-central1-a
    location: us-central1
    replica_type: READ_WRITE
    root_server:
      - host: root-a1.example.internal
      - host: root-a2.example.internal
      - host: root-a3.example.internal
  - name: us-central1-b
    location: us-central1
    replica_type: READ_WRITE
    root_server:
      - host: root-b1.example.internal
      - host: root-b2.example.internal
      - host: root-b3.example.internal
  - name: us-central1-c
    location: us-central1
    replica_type: READ_WRITE
    root_server:
      - host: root-c1.example.internal
      - host: root-c2.example.internal
      - host: root-c3.example.internal

Bereitstellung an mehreren Standorten mit Zeugenreplikat

Mit der folgenden Konfiguration wird eine Bereitstellung an mehreren Standorten erstellt, die sich über zwei Rechenzentren und einen Zeugenstandort erstreckt. Außerdem wird die bevorzugte Platzierung des Leaders festgelegt. In der Liste location_distance werden realistische, asymmetrische Netzwerklatenzen zwischen den einzelnen Standorten angegeben. In den beiden READ_WRITE-Zonen werden jeweils drei Root-Server für Hochverfügbarkeit verwendet, während in der WITNESS-Zone single_server: true mit einem einzelnen Root-Server verwendet wird, da in Zeugenreplikaten keine Nutzerdaten gespeichert werden:

name: multi-site-deployment
location:
  - name: datacenter-east
  - name: datacenter-west
  - name: datacenter-central
location_distance:
  - src: datacenter-east
    dest: datacenter-central
    latency_ms: 25
  - src: datacenter-central
    dest: datacenter-east
    latency_ms: 27
  - src: datacenter-central
    dest: datacenter-west
    latency_ms: 30
  - src: datacenter-west
    dest: datacenter-central
    latency_ms: 32
  - src: datacenter-east
    dest: datacenter-west
    latency_ms: 55
  - src: datacenter-west
    dest: datacenter-east
    latency_ms: 58
zone:
  - name: east-zone-1
    location: datacenter-east
    replica_type: READ_WRITE
    root_server:
      - host: east-root-1.example.internal
      - host: east-root-2.example.internal
      - host: east-root-3.example.internal
  - name: west-zone-1
    location: datacenter-west
    replica_type: READ_WRITE
    root_server:
      - host: west-root-1.example.internal
      - host: west-root-2.example.internal
      - host: west-root-3.example.internal
  - name: central-witness-zone
    location: datacenter-central
    single_server: true
    replica_type: WITNESS
    root_server:
      - host: witness-root-1.example.internal
deployment_settings:
  preferred_leader_location: datacenter-east

Sichere Bereitstellung mit TLS und Authentifizierung

Die folgende Konfiguration definiert eine Bereitstellung mit aktiviertem mTLS und aktivierter Passwortauthentifizierung:

name: secure-deployment
location:
  - name: us-central1
zone:
  - name: us-central1-a
    location: us-central1
    replica_type: READ_WRITE
    root_server:
      - host: server-1.example.internal
        port_base: 15000
      - host: server-2.example.internal
        port_base: 15000
      - host: server-3.example.internal
        port_base: 15000
deployment_settings:
  security_settings:
    insecure_mode: false
    authentication_methods:
      - AUTHENTICATION_METHOD_PASSWORD
      - AUTHENTICATION_METHOD_CLIENT_CERTIFICATE
    password_authentication_protocol: PASSWORD_AUTHENTICATION_PROTOCOL_OPAQUE

Nächste Schritte