Worker bereitstellen und verwalten

In diesem Dokument wird beschrieben, wie Sie Spanner Omni-Worker auf virtuellen Maschinen (VMs) und in Kubernetes bereitstellen, skalieren, außer Betrieb nehmen und überwachen.

Worker sind dedizierte, zustandslose Rechenknoten, die Hintergrund- und ressourcenintensive Vorgänge von Spanner Omni-Servern auslagern. Worker hosten keine Nutzerdaten und sind nicht an Leader-Wahlen, Transaktionen oder anderen wichtigen Datenbankaktivitäten beteiligt. Im Gegensatz zu Servern sind Worker nicht mit einer bestimmten Zone verknüpft. Stattdessen registrieren sich Worker an einem Standort und können Aufgaben für jede Zone an diesem Standort ausführen. Das Hinzufügen und Entfernen von Workern ist einfach und erfolgt sofort, da Worker zustandslos sind und keine Datenübertragung oder Neuausrichtung erforderlich ist.

Worker sind erforderlich, um Vektorindexe für große Tabellen (mehr als 1 Million Zeilen) für ANN-Suchanfragen (Approximate Nearest Neighbor) zu erstellen. Weitere Informationen finden Sie unter Übersicht über die Vektorsuche in Spanner Omni.

Workers sind nur in der kommerziellen Version von Spanner Omni verfügbar. Die Developer-Version unterstützt keine Workers. Die Berechnung von Workern wird zum selben Preis wie Server in der Bereitstellung abgerechnet (pro vCPU). Weitere Informationen finden Sie in der Übersicht über Spanner Omni-Versionen.

Hinweis

Bevor Sie einer vorhandenen Spanner Omni-Bereitstellung Worker hinzufügen, muss Ihre Umgebung die folgenden Anforderungen erfüllen:

  • Spanner Omni-Binärdatei herunterladen und einrichten

  • Vorhandene Bereitstellung: Prüfen Sie, ob Sie eine Spanner Omni-Bereitstellung (keine Einzelserverbereitstellung) im Status READY haben, die mit der Commercial Edition konfiguriert ist. Die Developer-Version unterstützt keine Worker. Die Berechnung der Worker wird zum gleichen Preis wie die Server in der Bereitstellung abgerechnet. Weitere Informationen finden Sie in der Übersicht über Spanner Omni-Versionen. Sie benötigen die folgenden Informationen:

    • Der Name des Zielstandorts (z. B. us-central1), wie in Ihrer Bereitstellungskonfiguration definiert.
    • Entweder der Deployment-Endpunkt (HOST:PORT, z. B. my-spanner-deployment:15003) oder eine Liste von Root-Serveradressen (ROOT_HOST_1:PORT, ROOT_HOST_2:PORT, z. B. root-server-1:15000, root-server-2:15000) für die Clustererkennung.

  • System- und Hardwareressourcen: Achten Sie darauf, dass die Rechenressourcen, die Sie dem Worker zuweisen, ausreichen, um die erforderlichen Vorgänge in einer angemessenen Zeit auszuführen.

  • vSphere-Konfiguration: Wenn Sie Spanner Omni auf der vSphere-Virtualisierungsplattform ausführen, deaktivieren Sie die Virtualisierung des Zeitstempelzählers (Time Stamp Counter, TSC). Fügen Sie der Konfigurationsdatei .vmx der VM monitor_control.virtual_rdtsc = FALSE hinzu.

  • Netzwerk- und Firewallkonfiguration: Worker verwenden zusätzlich zu den Standardports für die Serverkommunikation (15000 bis 15025) den Port 15027. Achten Sie darauf, dass Ihre Netzwerkkonfiguration die Kommunikation über die Ports 15000 bis 15027 zulässt.

Worker auf VMs bereitstellen

Wenn Sie Worker auf einer virtuellen Maschine (VM) bereitstellen möchten, starten Sie den Worker-Prozess entweder über den Bereitstellungsendpunkt oder über eine Liste von Stammservern.

Option A: Bereitstellungsendpunkt verwenden

Führen Sie den Befehl spanner workers start aus, um einen Worker über den Deployment-Endpunkt zu starten:

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

Ersetzen Sie Folgendes:

  • LOCATION_NAME: Der Name des Zielstandorts, z. B. us-central1.
  • WORKER_HOSTNAME: Der auflösbare Hostname oder die IP-Adresse der Worker-VM.
  • WORKER_PORT_BASE: Der Basisport, auf dem der Worker gestartet wird, z. B. 15000 oder 20000.
  • DEPLOYMENT_ENDPOINT: Der Host und Port des Bereitstellungsendpunkts, z. B. my-spanner-deployment:15003.
  • BASE_DIR: Das Basisverzeichnis für Worker-Daten und ‑Logs, z. B. /var/spanner.
  • LICENSE_FILE_PATH: Der Pfad zu Ihrer Spanner Omni-Lizenzdatei.

Option B: Liste mit Root-Servern verwenden

Führen Sie den Befehl spanner workers start aus, um einen Worker mit einer Liste von Stammservern zu starten:

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

Ersetzen Sie Folgendes:

  • LOCATION_NAME: Der Name des Zielstandorts, z. B. us-central1.
  • WORKER_HOSTNAME: Der auflösbare Hostname oder die IP-Adresse der Worker-VM.
  • WORKER_PORT_BASE: Der Basisport, auf dem der Worker gestartet wird, z. B. 15000 oder 20000.
  • ROOT_SERVER_1_HOST, ROOT_SERVER_2_HOST: Die Hostnamen oder IP-Adressen von Root-Servern in Ihrer Bereitstellung.
  • ROOT_SERVER_PORT_BASE: Der Basisport der Stammserver, z. B. 15000.
  • BASE_DIR: Das Basisverzeichnis für Worker-Daten und ‑Logs, z. B. /var/spanner.
  • LICENSE_FILE_PATH: Der Pfad zu Ihrer Spanner Omni-Lizenzdatei.

Verschlüsselung konfigurieren

Wenn für Ihre Spanner Omni-Bereitstellung TLS- oder mTLS-Verschlüsselung verwendet wird, konfigurieren Sie die Verschlüsselung für jeden Worker:

  1. Aktualisieren Sie Ihr Serverzertifikat, um Worker-Hostnamen einzuschließen, falls Sie dies noch nicht getan haben.
  2. Kopieren Sie das Zertifikatsverzeichnis mit ca.crt, server.crt und server.key auf die Worker-VM.

  3. Fügen Sie beim Ausführen von spanner workers start das Flag --certificate-directory hinzu:

    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

    Ersetzen Sie CERTIFICATE_DIRECTORY durch das Verzeichnis, das ca.crt, server.crt und server.key enthält.

Weitere Informationen zum Konfigurieren von Zertifikaten und sicheren Bereitstellungen finden Sie unter Sichere Bereitstellung auf VMs erstellen.

Worker in Kubernetes bereitstellen

In Kubernetes-Umgebungen wie Google Kubernetes Engine (GKE) oder Amazon Elastic Kubernetes Service (Amazon EKS) stellen Sie Worker als Teil Ihres vorhandenen Spanner Omni Helm-Release im selben Namespace wie Ihr Cluster bereit. Das Helm-Chart stellt Worker als Kubernetes-StatefulSet mit einem Headless-Service bereit. Dadurch erhält jeder Worker-Pod eine stabile Netzwerkidentität und PersistentVolumeClaims (PVCs), sodass Root-Server zuverlässig mit jedem Worker kommunizieren können.

Standardmäßig plant das Helm-Chart Worker-Pods nur auf Knoten mit dem Label spanner-role=workers, toleriert den Taint spanner-role=workers:NoSchedule und führt maximal einen Worker-Pod pro Knoten aus. Bevor Sie Worker aktivieren, fügen Sie einen Knotenpool mit diesem Label und dieser Markierung hinzu, der mindestens so viele Knoten wie workers.replicas hat. Jeder Knoten benötigt genügend zuweisbare CPU- und Arbeitsspeicherressourcen für einen Worker-Pod, wie durch workers.resources.cpu und workers.resources.memory festgelegt. Kubernetes reserviert einen Teil der Kapazität jedes Knotens für Systemkomponenten. Wählen Sie daher Knoten aus, die größer als diese Werte sind. Wenn Sie ein anderes Label verwenden möchten, legen Sie workers.nodeLabelKey und workers.nodeLabelValue fest. Wenn Sie die Labelanforderung entfernen möchten, legen Sie workers.nodeLabelKey="" fest. Wenn Sie die standardmäßigen Planungsregeln ersetzen möchten, legen Sie workers.affinity fest.

Führen Sie den Befehl helm upgrade aus, um Worker in Ihrem vorhandenen Deployment zu aktivieren:

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

Ersetzen Sie Folgendes:

  • HELM_CHART_PATH: Der Pfad zu Ihrem Spanner Omni-Helm-Diagramm.
  • NAMESPACE: Der Kubernetes-Namespace, in dem Ihr Spanner Omni-Cluster bereitgestellt wird, z. B. spanner-ns.

Damit Worker auf jedem Knoten ausgeführt werden können, der über genügend zuweisbare CPU- und Arbeitsspeicherressourcen verfügt, setzen Sie workers.nodeLabelKey auf einen leeren String. Dadurch werden sowohl die Anforderung für das Knotenlabel als auch die Toleranz für Taints entfernt:

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

Optionale Konfigurationseinstellungen:

  • --set workers.replicas=WORKER_REPLICAS: Die Anzahl der bereitzustellenden Worker-Replikate. Der Standardwert ist 1.

  • --set workers.resources.cpu=CPU_CORES: Das CPU-Limit und die Anfrage für jeden Worker. Der Standardwert ist 6.

  • --set workers.resources.memory=MEMORY_LIMIT: Das Arbeitsspeicherlimit und die Anfrage für jeden Worker. Der Standardwert ist 24Gi.

  • --set workers.storage.size=STORAGE_SIZE: Die Speicherkapazität für jeden Worker. Der Standardwert ist 20Gi.

  • --set workers.storage.storageClassName=STORAGE_CLASS: Die Speicherklasse, die für den Arbeitsspeicherspeicher verwendet werden soll, z. B. hyperdisk-balanced-rwo in GKE oder aws-gp3 in Amazon EKS. Der Standardwert ist ein leerer String, der die Standardspeicherklasse des Clusters übernimmt.

  • --set workers.port=WORKER_PORT: Der Netzwerkport, an dem der Worker auf Anfragen wartet. Der Standardwert ist deployment.basePort, also 15000.

  • --set workers.joinServers={ROOT_HOST_1:PORT,ROOT_HOST_2:PORT}: Eine explizite, durch Kommas getrennte Liste der Root-Serveradressen, denen beigetreten werden soll. Der Standardwert ist eine leere Liste ([]), in der alle aktiven Root-Server aus der Bereitstellungstopologie ermittelt werden.

  • --set workers.nodeLabelKey=NODE_LABEL_KEY: Der Kubernetes-Knotenlabel-Schlüssel, der für die Knotenaffinität und Toleranzen verwendet wird, um Worker in einem dedizierten Knotenpool zu isolieren. Der Standardwert ist spanner-role. Legen Sie einen leeren String "" fest, um Knotenaffinität und Toleranzen zu deaktivieren.

  • --set workers.nodeLabelValue=NODE_LABEL_VALUE: Der Kubernetes-Knotenlabelwert, der für Knotenaffinität und Toleranzen verwendet wird. Der Standardwert ist workers.

  • --set workers.pdbMaxUnavailable=MAX_UNAVAILABLE: Die maximale Anzahl von Worker-Pods, die während freiwilliger Unterbrechungen in der PodDisruptionBudget nicht verfügbar sein können. Der Standardwert ist 1.

  • workers.affinity: Benutzerdefinierte Kubernetes-Affinitätsregeln für Worker-Pods. Wenn keine Angabe erfolgt, werden die Standard-Node-Affinität (mit workers.nodeLabelKey und workers.nodeLabelValue) und die Pod-Anti-Affinität für Hostnamen (kubernetes.io/hostname) angewendet. Da es sich um ein verschachteltes Objekt handelt, müssen Sie es in einer values.yaml-Datei mit dem Flag -f angeben.

Worker-Bereitstellung prüfen

Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Worker-Pods ausgeführt werden und bereit sind:

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

Mitarbeiter skalieren und außer Betrieb nehmen

Worker speichern keine Nutzerdaten und sind nicht am Datenbankkonsens beteiligt. Das Skalieren und Deaktivieren von Worker-Instanzen erfolgt sofort. Sie können einen Worker vor oder nach dem Starten der Vektorindex-Erstellung starten und ihn sofort nach Abschluss der Indexerstellung außer Betrieb nehmen.

Worker-Skalierung automatisieren

Wenn Sie das Erstellen und Skalieren von Workern automatisieren möchten, beobachten Sie den Messwert spanner_box_compute_heavy_workers_required. Wenn der Messwert größer als 0 ist, sind für die Bereitstellung ein oder mehrere Worker erforderlich, um ausstehende Hintergrundvorgänge abzuschließen, z. B. das Erstellen eines Vektorindex für eine große Tabelle. Wenn der Messwert wieder 0 ist, sind alle ausstehenden Vorgänge abgeschlossen und Sie können die Worker außer Betrieb nehmen.

VM-Worker außer Betrieb nehmen

Um einen Worker-Prozess zu beenden, der auf einer VM ausgeführt wird, drücken Sie im Terminal, in dem der Worker-Prozess ausgeführt wird, Strg + C oder beenden Sie den Prozess anhand seiner Prozess-ID (PID):

kill -TERM PID

Ersetzen Sie PID durch die Prozess-ID des spanner workers-Prozesses. Alternativ können Sie die Worker-VM herunterfahren.

Kubernetes-Worker außer Betrieb nehmen

Wenn Sie Worker in Kubernetes außer Betrieb nehmen möchten, deaktivieren Sie sie in Ihrer Helm-Version oder skalieren Sie Worker-Replikate direkt mit kubectl herunter:

  • Worker deaktivieren: Wenn Sie den Worker StatefulSet und den Dienst aus Ihrem Cluster entfernen möchten, während der Rest Ihres Deployments erhalten bleibt, führen Sie den Befehl helm upgrade mit workers.enabled=false aus:

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

    Ersetzen Sie Folgendes:

    • HELM_CHART_PATH: Der Pfad zu Ihrem Spanner Omni-Helm-Diagramm.
    • NAMESPACE: Der Kubernetes-Namespace, in dem Ihr Spanner Omni-Cluster bereitgestellt wird, z. B. spanner-ns.

  • Worker-Replikate herunterskalieren: Wenn Sie Worker-Pods auf null Replikate herunterskalieren und die Worker-Konfiguration in Ihrem Cluster aktiv lassen möchten, führen Sie den Befehl kubectl scale aus:

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

    Ersetzen Sie NAMESPACE durch den Kubernetes-Namespace, in dem Ihr Spanner Omni-Cluster bereitgestellt wird, z. B. spanner-ns.

Worker überwachen und Fehler beheben

Wenn für Ihre Bereitstellung die Überwachung aktiviert ist, können Sie Worker mit Prometheus- oder Grafana-Dashboards überwachen. Worker stellen Messwerte bereit, die denen von Spanner Omni-Servern ähneln. Grafana-Dashboards enthalten ein Worker Insights-Dashboard, mit dem Sie die Ressourcennutzung der einzelnen Worker überwachen können.

Worker schreiben Logdateien in das Unterverzeichnis logs im Basisverzeichnis, das durch --base-dir angegeben wird:

BASE_DIR/logs

Mit dem Befehl spanner admin diagnostics create werden keine Logs oder Diagnosedaten von Workern erfasst. Wenn Sie Worker-Logs prüfen möchten, rufen Sie die Dateien in BASE_DIR/logs direkt auf der Worker-Maschine oder im Worker-Pod auf oder führen Sie kubectl logs für Kubernetes-Worker-Pods aus.

Weitere Informationen zum Monitoring und zum Konfigurieren von Dashboards finden Sie unter Monitoring – Übersicht und Mit Grafana-Dashboards überwachen.

Die Erstellung des Vektorindex kommt nicht voran

Wenn Sie einen Vektorindex für eine große Tabelle erstellen und die Indexerstellung aussteht, ohne dass Fortschritte erzielt werden, prüfen Sie, ob mindestens ein Worker ausgeführt wird und mit der Bereitstellung verbunden ist.

Mit Spanner Omni können Sie einen Vektorindex erstellen, auch wenn keine Worker aktiv sind. So können Sie Worker nur bei Bedarf bereitstellen. Wenn kein Worker aktiv ist, wird die Indexerstellung auf unbestimmte Zeit pausiert, bis ein Worker bereitgestellt wird. Sobald ein Worker gestartet und bei der Bereitstellung registriert wird, wird die Indexerstellung automatisch fortgesetzt.