Esegui il deployment e gestisci i lavoratori

Questo documento spiega come eseguire il deployment, scalare, dismettere e monitorare i worker Spanner Omni su macchine virtuali (VM) e Kubernetes.

I worker sono nodi di computing dedicati e stateless progettati per scaricare le operazioni in background e ad alta intensità di risorse dai server Spanner Omni. I worker non ospitano dati utente né partecipano a elezioni di leader, transazioni o altre attività principali del database. A differenza dei server, i worker non sono associati a una zona specifica. I lavoratori si registrano in una località e possono eseguire attività per qualsiasi zona di quella località. L'aggiunta e la rimozione di worker è semplice e istantanea perché i worker sono stateless e non richiedono spostamento o ribilanciamento dei dati.

I worker devono creare indici vettoriali su tabelle di grandi dimensioni (più di 1 milione di righe) per le query di ricerca del vicino più prossimo approssimato (ANN). Per saperne di più, consulta la panoramica della ricerca vettoriale di Spanner Omni.

I worker sono disponibili solo nella versione commerciale di Spanner Omni; la versione Developer non supporta i worker. Il calcolo dei worker viene fatturato alla stessa tariffa dei server nel deployment (per vCPU). Per ulteriori informazioni, consulta la panoramica delle edizioni di Spanner Omni.

Prima di iniziare

Prima di aggiungere worker a un deployment Spanner Omni esistente, assicurati che il tuo ambiente soddisfi i seguenti requisiti:

  • Scarica e configura il programma binario Spanner Omni.

  • Deployment esistente: verifica di avere un deployment Spanner Omni in esecuzione (non un deployment a server singolo) nello stato READY, configurato con la versione Commercial. La versione Developer non supporta i worker. Il calcolo dei worker viene fatturato alla stessa tariffa dei server nel deployment. Per ulteriori informazioni, consulta la panoramica delle edizioni di Spanner Omni. Assicurati di disporre delle seguenti informazioni:

    • Il nome della località di destinazione (ad esempio, us-central1) come definito nella configurazione della distribuzione.
    • L'endpoint di deployment (HOST:PORT, ad esempio my-spanner-deployment:15003) o un elenco di indirizzi dei server radice (ROOT_HOST_1:PORT, ROOT_HOST_2:PORT, ad esempio root-server-1:15000, root-server-2:15000) per l'individuazione del cluster.

  • Risorse di sistema e hardware: assicurati che le risorse di calcolo che allochi al worker siano sufficienti per eseguire le operazioni richieste in un periodo di tempo accettabile.

  • Configurazione vSphere: se esegui Spanner Omni sulla piattaforma di virtualizzazione vSphere, disattiva la virtualizzazione del contatore del timestamp (TSC). Aggiungi monitor_control.virtual_rdtsc = FALSE al file di configurazione .vmx della macchina virtuale.

  • Configurazione di rete e firewall: i worker utilizzano la porta 15027 oltre alle porte di comunicazione del server standard (da 15000 a 15025). Assicurati che la configurazione di rete consenta la comunicazione sulle porte da 15000 a 15027.

Deployment dei worker sulle VM

Per eseguire il deployment dei worker su una macchina virtuale (VM), avvia il processo worker utilizzando l'endpoint di deployment o un elenco di server radice.

Opzione A: inizia a utilizzare l'endpoint di deployment

Per avviare un worker utilizzando l'endpoint di deployment, esegui il comando 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

Sostituisci quanto segue:

  • LOCATION_NAME: il nome della località di destinazione, ad esempio us-central1.
  • WORKER_HOSTNAME: Il nome host o l'indirizzo IP risolvibile della VM worker.
  • WORKER_PORT_BASE: la porta di base su cui viene avviato il worker, ad esempio 15000 o 20000.
  • DEPLOYMENT_ENDPOINT: l'host e la porta dell'endpoint di deployment, ad esempio my-spanner-deployment:15003.
  • BASE_DIR: la directory di base per i dati e i log dei worker, ad esempio /var/spanner.
  • LICENSE_FILE_PATH: il percorso del file di licenza Spanner Omni.

Opzione B: inizia a utilizzare un elenco di server radice

Per avviare un worker utilizzando un elenco di server radice, esegui il comando 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

Sostituisci quanto segue:

  • LOCATION_NAME: il nome della località di destinazione, ad esempio us-central1.
  • WORKER_HOSTNAME: Il nome host o l'indirizzo IP risolvibile della VM worker.
  • WORKER_PORT_BASE: la porta di base su cui viene avviato il worker, ad esempio 15000 o 20000.
  • ROOT_SERVER_1_HOST, ROOT_SERVER_2_HOST: i nomi host o gli indirizzi IP dei server radice nel tuo deployment.
  • ROOT_SERVER_PORT_BASE: La porta di base dei server root, ad esempio 15000.
  • BASE_DIR: la directory di base per i dati e i log dei worker, ad esempio /var/spanner.
  • LICENSE_FILE_PATH: il percorso del file di licenza Spanner Omni.

Configura la crittografia

Se il deployment di Spanner Omni utilizza la crittografia TLS o mTLS, configura la crittografia per ogni worker:

  1. Aggiorna il certificato server in modo da includere i nomi host dei worker, se non li hai già inclusi.
  2. Copia la directory dei certificati contenente ca.crt, server.crt e server.key nella VM worker.

  3. Aggiungi il flag --certificate-directory quando esegui 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

    Sostituisci CERTIFICATE_DIRECTORY con la directory contenente ca.crt, server.crt e server.key.

Per saperne di più sulla configurazione dei certificati e sui deployment sicuri, vedi Crea un deployment sicuro sulle VM.

Esegui il deployment dei worker su Kubernetes

Negli ambienti Kubernetes come Google Kubernetes Engine (GKE) o Amazon Elastic Kubernetes Service (Amazon EKS), esegui il deployment dei worker nell'ambito della release Helm di Spanner Omni esistente nello stesso spazio dei nomi del cluster. Il grafico Helm esegue il deployment dei worker come StatefulSet Kubernetes con un servizio headless, fornendo a ogni pod worker un'identità di rete stabile e PersistentVolumeClaims (PVC), che consente ai server root di comunicare in modo affidabile con ogni worker.

Per impostazione predefinita, il grafico Helm pianifica i pod worker solo sui nodi etichettati spanner-role=workers, tollera il taint spanner-role=workers:NoSchedule ed esegue al massimo un pod worker per nodo. Prima di abilitare i worker, aggiungi un pool di nodi con questa etichetta e questo taint che abbia almeno tanti nodi quanti workers.replicas. Ogni nodo ha bisogno di CPU e memoria allocabili sufficienti per un pod worker, come impostato da workers.resources.cpu e workers.resources.memory. Kubernetes riserva parte della capacità di ogni nodo per i componenti di sistema, quindi scegli nodi più grandi di questi valori. Per utilizzare un'etichetta diversa, imposta workers.nodeLabelKey e workers.nodeLabelValue. Per rimuovere il requisito dell'etichetta, imposta workers.nodeLabelKey="". Per sostituire le regole di pianificazione predefinite, imposta workers.affinity.

Per abilitare i worker nel deployment esistente, esegui il comando helm upgrade:

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

Sostituisci quanto segue:

  • HELM_CHART_PATH: il percorso del grafico Helm di Spanner Omni.
  • NAMESPACE: lo spazio dei nomi Kubernetes in cui viene eseguito il deployment del cluster Spanner Omni, ad esempio spanner-ns.

Per consentire ai worker di essere eseguiti su qualsiasi nodo con CPU e memoria allocabili sufficienti, imposta workers.nodeLabelKey su una stringa vuota. In questo modo vengono rimossi sia il requisito dell'etichetta del nodo sia la tolleranza del taint:

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

Le impostazioni di configurazione facoltative includono:

  • --set workers.replicas=WORKER_REPLICAS: il numero di repliche del worker da implementare. Il valore predefinito è 1.

  • --set workers.resources.cpu=CPU_CORES: il limite e la richiesta di CPU per ogni worker. Il valore predefinito è 6.

  • --set workers.resources.memory=MEMORY_LIMIT: il limite e la richiesta di memoria per ogni worker. Il valore predefinito è 24Gi.

  • --set workers.storage.size=STORAGE_SIZE: La capacità di archiviazione per ogni worker. Il valore predefinito è 20Gi.

  • --set workers.storage.storageClassName=STORAGE_CLASS: La classe di archiviazione da utilizzare per l'archiviazione dei worker, ad esempio hyperdisk-balanced-rwo su GKE o aws-gp3 su Amazon EKS. Il valore predefinito è una stringa vuota, che eredita la classe di archiviazione predefinita del cluster.

  • --set workers.port=WORKER_PORT: la porta di rete su cui il worker è in ascolto. Il valore predefinito è deployment.basePort, ovvero 15000.

  • --set workers.joinServers={ROOT_HOST_1:PORT,ROOT_HOST_2:PORT}: Un elenco esplicito separato da virgole di indirizzi dei server root a cui connettersi. Il valore predefinito è un elenco vuoto ([]), che rileva tutti i server radice attivi dalla topologia di deployment.

  • --set workers.nodeLabelKey=NODE_LABEL_KEY: la chiave di etichetta del nodo Kubernetes utilizzata per l'affinità e le tolleranze dei nodi per isolare i worker in un pool di nodi dedicato. Il valore predefinito è spanner-role. Imposta su stringa vuota "" per disattivare l'affinità e le tolleranze dei nodi.

  • --set workers.nodeLabelValue=NODE_LABEL_VALUE: il valore dell'etichetta del nodo Kubernetes utilizzato per l'affinità e le tolleranze dei nodi. Il valore predefinito è workers.

  • --set workers.pdbMaxUnavailable=MAX_UNAVAILABLE: il numero massimo di pod worker che possono non essere disponibili durante le interruzioni volontarie in PodDisruptionBudget. Il valore predefinito è 1.

  • workers.affinity: Regole di affinità Kubernetes personalizzate per i pod worker. Se non specificato, vengono applicate l'affinità dei nodi predefinita (utilizzando workers.nodeLabelKey e workers.nodeLabelValue) e l'anti-affinità dei pod tra i nomi host (kubernetes.io/hostname). Poiché si tratta di un oggetto nidificato, specificalo in un file values.yaml utilizzando il flag -f.

Verifica il deployment del worker

Per verificare che i pod worker siano in esecuzione e pronti, esegui questo comando:

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

Scalare e dismettere i worker

I worker non archiviano dati utente né partecipano al consenso del database. Lo scaling e il ritiro dei worker sono istantanei. Puoi avviare un worker prima o dopo aver avviato la creazione dell'indice vettoriale e dismettere il worker immediatamente dopo il completamento della creazione dell'indice.

Automatizzare la scalabilità dei worker

Per automatizzare la creazione e la scalabilità dei worker, monitora la metrica spanner_box_compute_heavy_workers_required. Quando il valore della metrica è maggiore di 0, il deployment richiede uno o più worker per completare le operazioni in background in attesa, ad esempio la creazione di un indice vettoriale su una tabella di grandi dimensioni. Quando il valore della metrica torna a 0, tutte le operazioni in attesa sono completate e puoi dismettere i worker.

Dismettere un worker VM

Per arrestare un processo worker in esecuzione su una VM, premi Controllo+C nel terminale in cui è in esecuzione il processo worker oppure arresta il processo utilizzando il relativo ID processo (PID):

kill -TERM PID

Sostituisci PID con l'ID processo del processo spanner workers. In alternativa, arresta la VM worker.

Dismettere un worker Kubernetes

Per dismettere i worker su Kubernetes, disabilitali nella release Helm o fare lo scale down delle repliche dei worker direttamente utilizzando kubectl:

  • Disattiva i worker: per rimuovere il worker StatefulSet e il servizio dal cluster mantenendo il resto del deployment, esegui il comando helm upgrade con workers.enabled=false:

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

    Sostituisci quanto segue:

    • HELM_CHART_PATH: il percorso del grafico Helm di Spanner Omni.
    • NAMESPACE: lo spazio dei nomi Kubernetes in cui viene eseguito il deployment del cluster Spanner Omni, ad esempio spanner-ns.

  • Fare lo scale down delle repliche dei worker: per fare lo scale down dei pod worker a zero repliche mantenendo attiva la configurazione dei worker nel cluster, esegui il comando kubectl scale:

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

    Sostituisci NAMESPACE con lo spazio dei nomi Kubernetes in cui è stato eseguito il deployment del cluster Spanner Omni, ad esempio spanner-ns.

Monitorare e risolvere i problemi relativi ai worker

Se il deployment ha il monitoraggio abilitato, puoi monitorare i worker utilizzando le dashboard di Prometheus o Grafana. I worker espongono metriche simili ai server Spanner Omni. Le dashboard Grafana includono una dashboard Worker Insights che ti consente di monitorare l'utilizzo delle risorse di ogni worker.

I worker scrivono i file di log nella sottodirectory logs all'interno della directory di base specificata da --base-dir:

BASE_DIR/logs

Il comando spanner admin diagnostics create non raccoglie log o diagnostica dai worker. Per esaminare i log dei worker, visualizza i file in BASE_DIR/logs direttamente sulla macchina o sul pod worker oppure esegui kubectl logs per i pod worker Kubernetes.

Per ulteriori informazioni sul monitoraggio e sulla configurazione delle dashboard, consulta Panoramica di Monitoring e Monitora utilizzando le dashboard Grafana.

La creazione dell'indice vettoriale non procede

Se crei un indice vettoriale su una tabella di grandi dimensioni e la creazione dell'indice rimane in attesa senza progressi, verifica che almeno un worker sia in esecuzione e connesso al deployment.

Spanner Omni ti consente di creare un indice vettoriale anche quando non sono attivi worker, in modo da poter eseguire il deployment dei worker solo quando necessario. Se nessun worker è attivo, l'operazione di creazione dell'indice viene sospesa a tempo indeterminato finché non viene deployato un worker. Una volta che un worker viene avviato e registrato con il deployment, la creazione dell'indice riprende automaticamente.