Déployer et gérer des nœuds de calcul

Ce document explique comment déployer, mettre à l'échelle, mettre hors service et surveiller les nœuds de calcul Spanner Omni sur des machines virtuelles (VM) et Kubernetes.

Les workers sont des nœuds de calcul dédiés et sans état conçus pour décharger les opérations en arrière-plan et gourmandes en ressources des serveurs Spanner Omni. Les nœuds de calcul n'hébergent pas de données utilisateur et ne participent pas aux élections de leader, aux transactions ni à d'autres activités de base de données. Contrairement aux serveurs, les nœuds de calcul ne sont pas associés à une zone spécifique. Au lieu de cela, les nœuds de calcul s'enregistrent avec un emplacement et peuvent exécuter des tâches pour n'importe quelle zone de cet emplacement. L'ajout et la suppression de nœuds de calcul sont simples et instantanés, car les nœuds de calcul sont sans état et ne nécessitent pas de déplacement ni de rééquilibrage des données.

Les nœuds de calcul sont nécessaires pour créer des index vectoriels sur les grandes tables (plus d'un million de lignes) pour les requêtes de recherche du voisin le plus proche approximatif (ANN). Pour en savoir plus, consultez la présentation de la recherche vectorielle Spanner Omni.

Les workers ne sont disponibles que dans l'édition commerciale de Spanner Omni. L'édition Developer n'est pas compatible avec les workers. Le calcul des nœuds de calcul est facturé au même tarif que les serveurs du déploiement (par processeur virtuel). Pour en savoir plus, consultez la présentation des éditions Spanner Omni.

Avant de commencer

Avant d'ajouter des nœuds de calcul à un déploiement Spanner Omni existant, assurez-vous que votre environnement répond aux exigences suivantes :

  • Téléchargez et configurez le binaire Spanner Omni.

  • Déploiement existant : vérifiez que vous disposez d'un déploiement Spanner Omni en cours d'exécution (et non d'un déploiement à serveur unique) à l'état READY, configuré avec l'édition Commercial. L'édition Developer n'est pas compatible avec les workers. Le calcul des nœuds de calcul est facturé au même tarif que les serveurs du déploiement. Pour en savoir plus, consultez la présentation des éditions Spanner Omni. Assurez-vous de disposer des informations suivantes :

    • Nom de l'emplacement cible (par exemple, us-central1) tel que défini dans votre configuration de déploiement.
    • Point de terminaison du déploiement (HOST:PORT, par exemple my-spanner-deployment:15003) ou liste d'adresses de serveurs racine (ROOT_HOST_1:PORT, ROOT_HOST_2:PORT, par exemple root-server-1:15000, root-server-2:15000) pour la découverte du cluster.

  • Ressources système et matérielles : assurez-vous que les ressources de calcul que vous allouez au nœud de calcul sont suffisantes pour effectuer les opérations requises dans un délai acceptable.

  • Configuration vSphere : si vous exécutez Spanner Omni sur la plate-forme de virtualisation vSphere, désactivez la virtualisation du compteur Time Stamp Counter (TSC). Ajoutez monitor_control.virtual_rdtsc = FALSE au fichier de configuration .vmx de la machine virtuelle.

  • Configuration du réseau et du pare-feu : les nœuds de calcul utilisent le port 15027 en plus des ports de communication serveur standards (de 15000 à 15025). Assurez-vous que la configuration de votre réseau autorise la communication sur les ports de 15000 à 15027.

Déployer des nœuds de calcul sur des VM

Pour déployer des nœuds de calcul sur une machine virtuelle (VM), démarrez le processus de nœud de calcul à l'aide du point de terminaison de déploiement ou d'une liste de serveurs racine.

Option A : Commencer à utiliser le point de terminaison de déploiement

Pour démarrer un nœud de calcul à l'aide du point de terminaison de déploiement, exécutez la commande spanner workers start :

spanner workers start \
  --location=LOCATION_NAME \
  --address=WORKER_HOSTNAME:WORKER_PORT_BASE \
  --deployment=DEPLOYMENT_ENDPOINT \
  --base-dir=BASE_DIR \
  --license-file-path=LICENSE_FILE_PATH

Remplacez les éléments suivants :

  • LOCATION_NAME : nom de l'emplacement cible (par exemple, us-central1).
  • WORKER_HOSTNAME : nom d'hôte ou adresse IP résolvable de la VM de nœud de calcul.
  • WORKER_PORT_BASE : port de base sur lequel le nœud de calcul est démarré (par exemple, 15000 ou 20000).
  • DEPLOYMENT_ENDPOINT : hôte et port du point de terminaison de déploiement, par exemple my-spanner-deployment:15003.
  • BASE_DIR : répertoire de base pour les données et les journaux des nœuds de calcul (par exemple, /var/spanner).
  • LICENSE_FILE_PATH : chemin d'accès à votre fichier de licence Spanner Omni.

Option B : Commencer à utiliser une liste de serveurs racine

Pour démarrer un nœud de calcul à l'aide d'une liste de serveurs racine, exécutez la commande spanner workers start :

spanner workers start \
  --location=LOCATION_NAME \
  --address=WORKER_HOSTNAME:WORKER_PORT_BASE \
  --join-servers=ROOT_SERVER_1_HOST:ROOT_SERVER_PORT_BASE,\
ROOT_SERVER_2_HOST:ROOT_SERVER_PORT_BASE \
  --base-dir=BASE_DIR \
  --license-file-path=LICENSE_FILE_PATH

Remplacez les éléments suivants :

  • LOCATION_NAME : nom de l'emplacement cible (par exemple, us-central1).
  • WORKER_HOSTNAME : nom d'hôte ou adresse IP résolvable de la VM de nœud de calcul.
  • WORKER_PORT_BASE : port de base sur lequel le nœud de calcul est démarré (par exemple, 15000 ou 20000).
  • ROOT_SERVER_1_HOST, ROOT_SERVER_2_HOST : noms d'hôte ou adresses IP des serveurs racine de votre déploiement.
  • ROOT_SERVER_PORT_BASE : port de base des serveurs racine, par exemple 15000.
  • BASE_DIR : répertoire de base pour les données et les journaux des nœuds de calcul (par exemple, /var/spanner).
  • LICENSE_FILE_PATH : chemin d'accès à votre fichier de licence Spanner Omni.

Configurer le chiffrement

Si votre déploiement Spanner Omni utilise le chiffrement TLS ou mTLS, configurez le chiffrement pour chaque nœud de calcul :

  1. Mettez à jour le certificat de votre serveur pour inclure les noms d'hôte des nœuds de calcul si vous ne l'avez pas déjà fait.
  2. Copiez le répertoire de certificats contenant ca.crt, server.crt et server.key sur la VM de nœud de calcul.

  3. Ajoutez le flag --certificate-directory lorsque vous exécutez spanner workers start :

    spanner workers start \
  --location=LOCATION_NAME \
  --address=WORKER_HOSTNAME:WORKER_PORT_BASE \
  --deployment=DEPLOYMENT_ENDPOINT \
  --base-dir=BASE_DIR \
  --certificate-directory=CERTIFICATE_DIRECTORY \
  --license-file-path=LICENSE_FILE_PATH

    Remplacez CERTIFICATE_DIRECTORY par le répertoire contenant ca.crt, server.crt et server.key.

Pour en savoir plus sur la configuration des certificats et des déploiements sécurisés, consultez Créer un déploiement sécurisé sur des VM.

Déployer des nœuds de calcul sur Kubernetes

Dans les environnements Kubernetes tels que Google Kubernetes Engine (GKE) ou Amazon Elastic Kubernetes Service (Amazon EKS), vous déployez des nœuds de calcul dans le cadre de votre version Helm Spanner Omni existante, dans le même espace de noms que votre cluster. Le graphique Helm déploie les nœuds de calcul en tant que StatefulSet Kubernetes avec un service sans interface graphique, ce qui donne à chaque pod de nœud de calcul une identité réseau stable et des PersistentVolumeClaims (PVC). Cela permet aux serveurs racine de communiquer de manière fiable avec chaque nœud de calcul.

Par défaut, le graphique Helm ne planifie les pods de nœud de calcul que sur les nœuds portant le libellé spanner-role=workers, tolère le taint spanner-role=workers:NoSchedule et exécute au maximum un pod de nœud de calcul par nœud. Avant d'activer les nœuds de calcul, ajoutez un pool de nœuds avec ce libellé et cette contamination qui comporte au moins autant de nœuds que workers.replicas. Chaque nœud a besoin de suffisamment de processeur et de mémoire pouvant être alloués pour un pod de nœud de calcul, comme défini par workers.resources.cpu et workers.resources.memory. Kubernetes réserve une partie de la capacité de chaque nœud aux composants système. Choisissez donc des nœuds dont la capacité est supérieure à ces valeurs. Pour utiliser un autre libellé, définissez workers.nodeLabelKey et workers.nodeLabelValue. Pour supprimer l'obligation d'ajouter un libellé, définissez workers.nodeLabelKey="". Pour remplacer les règles de planification par défaut, définissez workers.affinity.

Pour activer les nœuds de calcul dans votre déploiement existant, exécutez la commande helm upgrade :

helm upgrade spanner-omni HELM_CHART_PATH \
  --reuse-values \
  --set workers.enabled=true \
  --namespace NAMESPACE

Remplacez les éléments suivants :

  • HELM_CHART_PATH : chemin d'accès à votre chart Helm Spanner Omni.
  • NAMESPACE : espace de noms Kubernetes dans lequel votre cluster Spanner Omni est déployé (par exemple, spanner-ns).

Pour permettre aux nœuds de calcul de s'exécuter sur n'importe quel nœud disposant de suffisamment de mémoire et de processeur pouvant être alloués, définissez workers.nodeLabelKey sur une chaîne vide. Cela supprime à la fois l'exigence de libellé de nœud et la tolérance aux taints :

helm upgrade spanner-omni HELM_CHART_PATH \
  --reuse-values \
  --set workers.enabled=true \
  --set workers.nodeLabelKey="" \
  --namespace NAMESPACE

Voici quelques exemples de paramètres de configuration facultatifs :

  • --set workers.replicas=WORKER_REPLICAS : nombre d'instances répliquées de nœuds de calcul à déployer. La valeur par défaut est 1.

  • --set workers.resources.cpu=CPU_CORES : limite et demande de ressources processeur pour chaque nœud de calcul. La valeur par défaut est 6.

  • --set workers.resources.memory=MEMORY_LIMIT : limite et demande de mémoire pour chaque nœud de calcul. La valeur par défaut est 24Gi.

  • --set workers.storage.size=STORAGE_SIZE : capacité de stockage de chaque nœud de calcul. La valeur par défaut est 20Gi.

  • --set workers.storage.storageClassName=STORAGE_CLASS : classe de stockage à utiliser pour le stockage des nœuds de calcul (par exemple, hyperdisk-balanced-rwo sur GKE ou aws-gp3 sur Amazon EKS). La valeur par défaut est une chaîne vide, qui hérite de la classe de stockage par défaut du cluster.

  • --set workers.port=WORKER_PORT : port réseau sur lequel le nœud de calcul écoute. La valeur par défaut est deployment.basePort, qui correspond à 15000.

  • --set workers.joinServers={ROOT_HOST_1:PORT,ROOT_HOST_2:PORT} : liste explicite d'adresses de serveurs racine à rejoindre, séparées par une virgule. La valeur par défaut est une liste vide ([]), qui détecte tous les serveurs racine actifs à partir de la topologie de déploiement.

  • --set workers.nodeLabelKey=NODE_LABEL_KEY : clé de libellé de nœud Kubernetes utilisée pour l'affinité et les tolérances de nœud afin d'isoler les nœuds de calcul dans un pool de nœuds dédié. La valeur par défaut est spanner-role. Définissez sur une chaîne vide "" pour désactiver l'affinité et les tolérances des nœuds.

  • --set workers.nodeLabelValue=NODE_LABEL_VALUE : valeur du libellé de nœud Kubernetes utilisée pour l'affinité et les tolérances de nœud. La valeur par défaut est workers.

  • --set workers.pdbMaxUnavailable=MAX_UNAVAILABLE : nombre maximal de pods de nœuds de calcul pouvant être indisponibles lors d'interruptions volontaires dans PodDisruptionBudget. La valeur par défaut est 1.

  • workers.affinity : règles d'affinité Kubernetes personnalisées pour les pods de nœud de calcul. Si aucune valeur n'est spécifiée, l'affinité de nœud par défaut (avec workers.nodeLabelKey et workers.nodeLabelValue) et l'anti-affinité de pod sur les noms d'hôte (kubernetes.io/hostname) sont appliquées. Comme il s'agit d'un objet imbriqué, spécifiez-le dans un fichier values.yaml à l'aide du flag -f.

Vérifier le déploiement du nœud de calcul

Pour vérifier que les pods de nœud de calcul sont en cours d'exécution et prêts, exécutez la commande suivante :

kubectl get pods --namespace NAMESPACE -l app.kubernetes.io/component=spanner-worker

Faire évoluer et mettre hors service les nœuds de calcul

Les nœuds de calcul ne stockent pas de données utilisateur et ne participent pas au consensus de la base de données. La mise à l'échelle et l'arrêt des nœuds de calcul sont instantanés. Vous pouvez démarrer un nœud de calcul avant ou après avoir commencé à créer l'index vectoriel, et le mettre hors service immédiatement après la création de l'index.

Automatiser le scaling des nœuds de calcul

Pour automatiser la création et le scaling des nœuds de calcul, surveillez la métrique spanner_box_compute_heavy_workers_required. Lorsque la valeur de la métrique est supérieure à 0, le déploiement nécessite un ou plusieurs nœuds de calcul pour effectuer les opérations en arrière-plan en attente, comme la création d'un index vectoriel sur une grande table. Lorsque la valeur de la métrique revient à 0, toutes les opérations en attente sont terminées et vous pouvez désactiver les nœuds de calcul.

Mettre hors service un nœud de calcul de VM

Pour arrêter un processus de nœud de calcul en cours d'exécution sur une VM, appuyez sur Ctrl+C dans le terminal exécutant le processus de nœud de calcul, ou arrêtez le processus à l'aide de son ID de processus (PID) :

kill -TERM PID

Remplacez PID par l'ID de processus du processus spanner workers. Vous pouvez également éteindre la VM de nœud de calcul.

Mettre hors service un nœud de calcul Kubernetes

Pour mettre hors service des nœuds de calcul sur Kubernetes, désactivez-les dans votre version Helm ou réduisez directement le nombre de répliques de nœuds de calcul à l'aide de kubectl :

  • Désactiver les nœuds de calcul : pour supprimer le nœud de calcul StatefulSet et le service de votre cluster tout en conservant le reste de votre déploiement, exécutez la commande helm upgrade avec workers.enabled=false :

    helm upgrade spanner-omni HELM_CHART_PATH \
  --reuse-values \
  --set workers.enabled=false \
  --namespace NAMESPACE

    Remplacez les éléments suivants :

    • HELM_CHART_PATH : chemin d'accès à votre chart Helm Spanner Omni.
    • NAMESPACE : espace de noms Kubernetes dans lequel votre cluster Spanner Omni est déployé (par exemple, spanner-ns).

  • Réduire le nombre de répliques de nœuds de calcul : pour réduire le nombre de répliques de pods de nœuds de calcul à zéro tout en conservant la configuration des nœuds de calcul active dans votre cluster, exécutez la commande kubectl scale :

    kubectl scale statefulset spanner-worker \
  --replicas=0 \
  --namespace NAMESPACE

    Remplacez NAMESPACE par l'espace de noms Kubernetes dans lequel votre cluster Spanner Omni est déployé (par exemple, spanner-ns).

Surveiller et dépanner les workers

Si la surveillance est activée pour votre déploiement, vous pouvez surveiller les nœuds de calcul à l'aide des tableaux de bord Prometheus ou Grafana. Les nœuds de calcul exposent des métriques semblables à celles des serveurs Spanner Omni. Les tableaux de bord Grafana incluent un tableau de bord Insights sur les nœuds de calcul qui vous permet de surveiller l'utilisation des ressources de chaque nœud de calcul.

Les workers écrivent les fichiers journaux dans le sous-répertoire logs du répertoire de base spécifié par --base-dir :

BASE_DIR/logs

La commande spanner admin diagnostics create ne collecte pas les journaux ni les diagnostics des nœuds de calcul. Pour inspecter les journaux des nœuds de calcul, affichez les fichiers dans BASE_DIR/logs directement sur la machine ou le pod du nœud de calcul, ou exécutez kubectl logs pour les pods de nœud de calcul Kubernetes.

Pour en savoir plus sur la surveillance et la configuration des tableaux de bord, consultez Présentation de la surveillance et Surveiller à l'aide des tableaux de bord Grafana.

La création de l'index vectoriel ne progresse pas

Si vous créez un index vectoriel sur une grande table et que la création de l'index reste en attente sans progresser, vérifiez qu'au moins un worker est en cours d'exécution et connecté au déploiement.

Spanner Omni vous permet de créer un index vectoriel même lorsqu'aucun worker n'est actif, ce qui vous permet de déployer des workers uniquement lorsque cela est nécessaire. Si aucun nœud de calcul n'est actif, l'opération de création d'index est mise en veille indéfiniment jusqu'à ce qu'un nœud de calcul soit déployé. Une fois qu'un nœud de calcul démarre et s'enregistre auprès du déploiement, la création de l'index reprend automatiquement.