Configurations de déploiement

Ce document décrit les configurations de déploiement pour Spanner Omni sur des machines virtuelles (VM) ou des serveurs Bare Metal. Il explique la structure et les options de configuration du fichier de configuration de déploiement YAML (deployment.yaml) utilisé pour définir les topologies de déploiement de VM et les paramètres d'exécution lorsque vous utilisez la CLI Spanner Omni.

Pour savoir comment créer un déploiement, consultez l'une des ressources suivantes :

• Créer un déploiement sur des VM
• Créer un déploiement sécurisé sur des VM
• Créer un déploiement sur Kubernetes
• Créer un déploiement sécurisé sur Kubernetes

Présentation de la configuration du déploiement

Lorsque vous créez un déploiement sur des VM ou des serveurs Bare Metal, vous transmettez ce fichier de configuration à la commande spanner deployment create dans la CLI Spanner Omni :

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

La configuration du déploiement définit les éléments clés suivants :

• Mode à serveur unique : mode d'optimisation qui limite l'ensemble du déploiement à un seul serveur pour le développement et les tests.
• Emplacements : sites physiques ou régions cloud où résident vos serveurs.
• Distances entre les lieux : latences réseau entre des paires de lieux.
• Zones : regroupements logiques de serveurs qui représentent des répliques Paxos.
• Serveurs racine : serveurs dédiés responsables des métadonnées de zone et du quorum d'appartenance.
• Types d'instances répliquées : rôles pour chaque zone (lecture/écriture, témoin ou lecture seule).
• SLA de l'horloge : paramètres de synchronisation TrueTime, y compris le jitter de l'horloge et le taux d'erreur de dérive.
• Paramètres de déploiement : paramètres généraux tels que les emplacements de leader préférés et les paramètres de sécurité de l'authentification.

Structure d'un fichier de configuration

L'exemple suivant montre la structure de premier niveau d'un fichier de configuration de déploiement :

# 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

Champs de premier niveau

La configuration du déploiement accepte les champs de premier niveau suivants :

Champ	Type	Description
name	Chaîne	Nom du déploiement, tel que prod, staging ou regional-deployment.
single_server	Booléen	Facultatif. Si la valeur est définie sur true, cela indique que l'ensemble du déploiement est un déploiement à serveur unique, ce qui le limite à une zone et à un serveur. Les déploiements créés avec single_server: true ne peuvent pas ajouter de zones ni de serveurs après leur création. Si vous souhaitez exécuter Spanner Omni en mode serveur unique, vous n'avez pas besoin de créer manuellement cette configuration, car Spanner Omni la génère automatiquement lorsque vous exécutez la commande spanner start-single-server. La valeur par défaut est false.
location	Liste des objets	Emplacements physiques ou logiques (régions) dans le déploiement.
location_distance	Liste des objets	Facultatif. Latence réseau entre des paires de lieux.
zone	Liste des objets	Obligatoire. Zones qui composent le déploiement. Vous devez spécifier au moins une zone.
clock_sla	Objet	Facultatif. Paramètres du contrat de niveau de service (SLA) de synchronisation de l'horloge pour le logiciel TrueTime.
deployment_settings	Objet	Facultatif. Paramètres d'exécution pour le placement du leader préféré et l'authentification de sécurité.

Nom du déploiement

Le champ name spécifie un nom choisi par l'utilisateur pour le déploiement. Vous pouvez utiliser n'importe quelle chaîne identifiant le déploiement, comme prod, staging ou regional-deployment.

Mode à serveur unique

Le champ single_server de premier niveau indique que l'ensemble du déploiement est un déploiement à serveur unique. Lorsqu'il est défini sur true, ce paramètre limite le déploiement à une zone et un serveur, ce qui réduit la surcharge de ressources pour les environnements de développement et de test locaux. Les déploiements créés avec single_server:true ne peuvent pas ajouter de zones ni de serveurs après leur création.

Si vous souhaitez exécuter Spanner Omni en mode serveur unique, vous n'avez pas besoin de créer manuellement cette configuration. Lorsque vous exécutez la commande spanner start-single-server, Spanner Omni génère automatiquement cette configuration pour vous. Pour en savoir plus, consultez Option A : Déploiement sur un seul serveur.

Le champ single_server de premier niveau est différent du champ single_server au niveau de la zone :

• Le champ top-level single_server s'applique à l'ensemble du déploiement.
• Le champ single_server au niveau de la zone ne s'applique qu'à une zone individuelle au sein d'un déploiement. Pour en savoir plus, consultez Zones à serveur unique.

Emplacements

Un emplacement représente un centre de données physique ou une région cloud où se trouvent les machines (équivalent à une région dans Google Cloud).

Vous définissez les emplacements dans la liste location :

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

Les noms de lieux doivent répondre aux exigences suivantes :

• Doit commencer par une lettre et se terminer par une lettre ou un chiffre.
• Il ne peut contenir que des lettres, des chiffres, des traits de soulignement (_) et des tirets (-).
• Peut éventuellement inclure un préfixe de domaine suivi de deux-points (par exemple, cloud.google.com:us-east1 ou onprem:datacenter1).
• Impossible d'utiliser le nom réservé default.
• Le nom doit être unique dans le déploiement.

Distances des établissements

La liste location_distance spécifie la latence réseau entre les paires de lieux. Spanner Omni utilise ces informations pour optimiser la réplication et le routage des requêtes.

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

Chaque objet de distance de lieu contient les champs suivants :

• src : obligatoire. Nom de l'emplacement source. Doit correspondre à un lieu défini dans la liste location.
• dest : obligatoire. Nom de l'établissement de destination. Doit correspondre à un emplacement défini et ne peut pas être identique à src.
• latency_ms : latence du réseau en millisecondes. Doit être un nombre entier non négatif. Si ce paramètre est omis, Spanner Omni suppose que la latence est négligeable (inférieure à une milliseconde).

La latence réseau dans les réseaux physiques n'est pas toujours symétrique. Si vous fournissez à la fois (src, dest) et (dest, src), Spanner Omni respecte les deux mesures. Si vous ne fournissez qu'une seule direction, Spanner Omni suppose que la direction inverse a la même latence.

Zones

Une zone est un regroupement logique d'un ou plusieurs serveurs dans un emplacement. Pour la réplication des données, chaque zone représente une instance répliquée Paxos. Un déploiement doit comporter au moins une zone.

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

Chaque objet de zone accepte les champs suivants :

Champ	Type	Description
name	Chaîne	Obligatoire. Nom de la zone. Respecte les mêmes règles de dénomination que les noms de lieux. Le nom doit être unique dans le déploiement.
location	Chaîne	Nom de l'emplacement où réside la zone. Doit correspondre à un emplacement défini dans la liste location. Si elle est omise, Spanner Omni attribue la zone à l'emplacement default.
single_server	Booléen	Facultatif. Si la valeur est définie sur true, cela signifie que cette zone ne comporte qu'un seul serveur (elle ne peut avoir qu'un seul serveur racine et aucun autre serveur). Élimine la surcharge de réplication des métadonnées de zone dans la zone. Dans un déploiement multizone, vous pouvez définir cette valeur sur true pour des zones spécifiques, telles qu'une zone de réplique WITNESS qui ne stocke pas de données utilisateur, tandis que d'autres zones comportent plusieurs serveurs. La valeur par défaut est false.
replica_type	Chaîne Enum	Rôle de réplique de la zone dans les quorums Paxos. Les valeurs acceptées sont READ_WRITE, WITNESS et READ_ONLY. La valeur par défaut est READ_WRITE.
root_server	Liste des objets	Obligatoire. Liste des serveurs racine de la zone.

Types d'instances répliquées

Spanner Omni accepte trois types de répliques pour les zones :

• READ_WRITE : stocke une copie complète des données utilisateur, traite les demandes de lecture et vote dans les quorums Paxos. Les répliques en lecture/écriture peuvent devenir des instances principales Paxos pour proposer des écritures.
• WITNESS : vote dans les quorums Paxos pour aider à parvenir à un consensus, mais ne peut pas devenir un leader. Les répliques témoins ne stockent pas de données utilisateur et ne peuvent pas répondre aux requêtes de lecture. Ils permettent d'atteindre le quorum sans la surcharge de stockage ni la latence d'écriture d'un réplica complet dans des emplacements distants.
• READ_ONLY : stocke une copie complète des données utilisateur qui est répliquée de manière asynchrone à partir des leaders. Les répliques en lecture seule ne peuvent pas devenir des leaders et ne votent pas dans les quorums Paxos. Elles déchargent le trafic de lecture des répliques en lecture-écriture.

Lorsque vous configurez des types de répliques, assurez-vous que votre déploiement respecte les règles suivantes :

• Le déploiement doit contenir au moins une zone READ_WRITE.
• Le nombre de zones READ_WRITE doit être strictement supérieur au nombre de zones WITNESS.

Serveurs racine

Les serveurs racine ont des responsabilités spécifiques dans Spanner Omni. Ils stockent les métadonnées de zone et gèrent l'appartenance des autres serveurs de la zone. Si un quorum de serveurs racine devient indisponible, l'ensemble de la zone le devient également.

Lorsque vous configurez des serveurs racines dans deployment.yaml, tenez compte des consignes suivantes :

• Le nombre de serveurs racine par zone doit être un nombre impair compris entre 1 et 9 (inclus) pour assurer le quorum et la cohérence. Si le nombre de serveurs est pair, les déploiements peuvent échouer. Lorsque vous configurez vos zones, désignez des serveurs comme serveurs racine. Nous vous recommandons d'en utiliser un pour le développement ou les tests, et trois pour les zones de production à disponibilité élevée.
• Ne spécifiez les serveurs racine dans le fichier deployment.yaml que lors de la création du déploiement initial. Vous pourrez ajouter des serveurs non racine ultérieurement pour faire évoluer la capacité de calcul et de stockage.

Chaque objet de serveur racine accepte les champs suivants :

• host : obligatoire. Nom d'hôte ou adresse IP de la machine exécutant le serveur.
• port_base : facultatif. Numéro de port de départ pour le serveur. La valeur par défaut est 15000. Ce port devient le port gRPC public pour les connexions client. Vous devez réserver des ports dans la plage [port_base + 1, port_base + 31] (par exemple, de 15001 à 15031) pour les processus Spanner Omni internes.

Zones à serveur unique

Le champ single_server au niveau de la zone indique qu'une zone individuelle ne contient qu'un seul serveur. Une zone à serveur unique ne peut comporter qu'un seul serveur racine et ne peut pas être complétée par d'autres serveurs ultérieurement. Ce paramètre élimine la surcharge liée à la réplication des métadonnées de zone dans cette zone.

Contrairement au champ single_server de premier niveau, qui indique que l'ensemble du déploiement se compose d'un seul serveur, le champ single_server au niveau de la zone ne s'applique qu'à cette zone spécifique.

Dans un déploiement multizone, vous pouvez configurer des zones individuelles en tant que zones à serveur unique, tandis que d'autres zones contiennent plusieurs serveurs. Par exemple, prenons l'exemple d'un déploiement avec deux zones de répliques READ_WRITE et une zone de répliques WITNESS :

• Les deux zones READ_WRITE contiennent plusieurs serveurs (single_server: false) pour assurer une haute disponibilité et adapter la capacité de calcul et de stockage des données utilisateur.
• Vous pouvez configurer la zone WITNESS comme zone à serveur unique ou à plusieurs serveurs, en fonction du volume de votes Paxos :
  • Charges de travail de petite à moyenne taille : si une seule VM ou un seul serveur dispose d'une capacité suffisante pour traiter tout le trafic de vote Paxos pour le déploiement, définissez single_server: true. Étant donné que les répliques de témoin ne font que voter et ne stockent pas de données utilisateur, l'utilisation d'un seul serveur élimine la surcharge de réplication des métadonnées intra-zone.
  • Déploiements à grande échelle : si vous avez un débit d'écriture élevé ou de nombreux serveurs dans chaque zone READ_WRITE (par exemple, des dizaines ou des centaines de nœuds), un seul serveur peut être surchargé et entraîner des échecs de consensus Paxos. Configurez la zone WITNESS avec plusieurs serveurs (single_server: false) pour répartir la charge de travail de vote.

Pour obtenir un exemple de configuration, consultez Déploiement multisite avec réplica témoin.

SLA de l'horloge

Spanner Omni s'appuie sur le logiciel TrueTime pour assurer la cohérence externe sans nécessiter de matériel GPS spécialisé ni d'horloges atomiques. L'objet clock_sla définit les limites de synchronisation attendues pour les horloges du serveur dans le déploiement :

clock_sla:
  jitter_in_s: 0.005
  rate_error_in_ppm: 200

La configuration clock_sla inclut les champs suivants :

• jitter_in_s : gigue d'horloge maximale attendue en secondes. Doit être un nombre à virgule flottante non négatif (>= 0).
• rate_error_in_ppm : taux d'erreur maximal de dérive d'horloge en parties par million (ppm). La valeur doit être comprise entre 0 et 10000.

Pour en savoir plus sur la synchronisation de l'heure, consultez TrueTime et cohérence externe.

Paramètres de déploiement

L'objet deployment_settings configure le comportement de déploiement global, y compris la préférence d'emplacement du leader et la sécurité du réseau :

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

Emplacement principal préféré

Le champ preferred_leader_location désigne un emplacement où les leaders Paxos sont placés de préférence. Le fait de choisir des leaders à proximité de votre charge de travail d'application principale réduit la latence d'écriture en évitant les allers-retours réseau supplémentaires.

Lorsque vous configurez preferred_leader_location, assurez-vous des points suivants :

• L'emplacement spécifié doit correspondre à un emplacement défini dans la liste location (ou default).
• L'emplacement désigné doit contenir au moins une zone READ_WRITE.

Paramètres de sécurité

L'objet security_settings configure les modes d'authentification et de chiffrement :

• insecure_mode : booléen. Si la valeur est définie sur true, l'authentification et l'autorisation sont désactivées pour les connexions entrantes. Ce mode est destiné au prototypage et à l'évaluation uniquement. La valeur par défaut est false.
• authentication_methods : liste des méthodes d'authentification activées. Obligatoire si insecure_mode est défini sur false. Valeurs acceptées :
  • AUTHENTICATION_METHOD_PASSWORD : active l'authentification par nom d'utilisateur et mot de passe.
  • AUTHENTICATION_METHOD_CLIENT_CERTIFICATE : active l'authentification par certificat client TLS mutuel (mTLS).
• password_authentication_protocol : protocole utilisé pour la validation du mot de passe. Obligatoire si AUTHENTICATION_METHOD_PASSWORD est inclus dans authentication_methods. Valeur acceptée :
  • PASSWORD_AUTHENTICATION_PROTOCOL_OPAQUE : utilise le protocole d'échange de clés asymétrique OPAQUE authentifié par mot de passe.

Pour en savoir plus sur la configuration du chiffrement et des identifiants, consultez Créer un déploiement avec chiffrement TLS sur des VM.

Exemples de configuration de déploiement

Les exemples suivants illustrent des schémas de déploiement courants.

Déploiement multizone régional

La configuration suivante crée un déploiement régional à haute disponibilité dans trois zones d'un même emplacement :

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

Déploiement multisite avec instance répliquée témoin

La configuration suivante crée un déploiement multizone couvrant deux centres de données et un site témoin, avec un emplacement de leader préféré. La liste location_distance spécifie des latences réseau asymétriques réalistes entre chaque paire d'emplacements. Les deux zones READ_WRITE utilisent chacune trois serveurs racine pour assurer une haute disponibilité, tandis que la zone WITNESS en utilise single_server: true avec un seul serveur racine, car les répliques de témoin ne stockent pas de données utilisateur :

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

Déploiement sécurisé avec TLS et authentification

La configuration suivante définit un déploiement avec l'authentification mTLS et par mot de passe activée :

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

Étapes suivantes

• Créer un déploiement sur des VM
• Créer un déploiement avec chiffrement TLS sur des VM
• Faire évoluer un déploiement de VM
• Gérer un déploiement