Implementa y administra trabajadores

En este documento, se explica cómo implementar, escalar, dar de baja y supervisar los trabajadores de Spanner Omni en máquinas virtuales (VMs) y Kubernetes.

Los trabajadores son nodos de procesamiento sin estado y dedicados diseñados para descargar operaciones en segundo plano y con uso intensivo de recursos de los servidores de Spanner Omni. Los trabajadores no alojan datos del usuario ni participan en elecciones de líderes, transacciones ni otras actividades centrales de la base de datos. A diferencia de los servidores, los trabajadores no están asociados a una zona específica. En cambio, los trabajadores se registran con una ubicación y pueden ejecutar tareas para cualquier zona de esa ubicación. Agregar y quitar trabajadores es un proceso ligero y rápido porque los trabajadores no tienen estado y no requieren movimiento ni reequilibrio de datos.

Se requieren trabajadores para compilar índices de vectores en tablas grandes (más de 1 millón de filas) para las consultas de búsqueda de vecinos más cercanos aproximados (ANN). Para obtener más información, consulta la Descripción general de la búsqueda de vectores de Spanner Omni.

Los trabajadores solo están disponibles en la edición Comercial de Spanner Omni. La edición para desarrolladores no admite trabajadores. El procesamiento de los trabajadores se factura con la misma tarifa que los servidores de la implementación (por vCPU). Para obtener más información, consulta la descripción general de las ediciones de Spanner Omni.

Antes de comenzar

Antes de agregar trabajadores a una implementación existente de Spanner Omni, asegúrate de que tu entorno cumpla con los siguientes requisitos:

  • Descarga y configura el objeto binario de Spanner Omni.

  • Implementación existente: Verifica que tengas una implementación de Spanner Omni en ejecución (no una implementación de un solo servidor) en el estado READY, configurada con la edición comercial. La edición para desarrolladores no admite trabajadores. El procesamiento de los trabajadores se factura con la misma tarifa que los servidores de la implementación. Para obtener más información, consulta la descripción general de las ediciones de Spanner Omni. Asegúrate de tener la siguiente información:

    • Nombre de la ubicación de destino (por ejemplo, us-central1) según se define en la configuración de implementación.
    • Es el extremo de implementación (HOST:PORT, como my-spanner-deployment:15003) o una lista de direcciones de servidores raíz (ROOT_HOST_1:PORT, ROOT_HOST_2:PORT, como root-server-1:15000, root-server-2:15000) para el descubrimiento del clúster.

  • Recursos del sistema y hardware: Asegúrate de que los recursos de procesamiento que asignes al trabajador sean suficientes para realizar las operaciones requeridas en un tiempo aceptable.

  • Configuración de vSphere: Si ejecutas Spanner Omni en la plataforma de virtualización de vSphere, inhabilita la virtualización del contador de marcas de tiempo (TSC). Agrega monitor_control.virtual_rdtsc = FALSE al archivo de configuración .vmx de la máquina virtual.

  • Configuración de red y firewall: Los trabajadores usan el puerto 15027 además de los puertos de comunicación del servidor estándar (15000 a 15025). Asegúrate de que la configuración de tu red permita la comunicación en los puertos 15000 a 15027.

Implementa trabajadores en VMs

Para implementar trabajadores en una máquina virtual (VM), inicia el proceso del trabajador con el extremo de implementación o una lista de servidores raíz.

Opción A: Comienza a usar el extremo de implementación

Para iniciar un trabajador con el extremo de implementación, ejecuta el 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

Reemplaza lo siguiente:

  • LOCATION_NAME: Es el nombre de la ubicación de destino, por ejemplo, us-central1.
  • WORKER_HOSTNAME: Es el nombre de host o la dirección IP de la VM de trabajador que se puede resolver.
  • WORKER_PORT_BASE: Es el puerto base en el que se inicia el trabajador, por ejemplo, 15000 o 20000.
  • DEPLOYMENT_ENDPOINT: Es el host y el puerto del extremo de implementación, por ejemplo, my-spanner-deployment:15003.
  • BASE_DIR: Es el directorio base para los datos y los registros del trabajador, por ejemplo, /var/spanner.
  • LICENSE_FILE_PATH: Es la ruta de acceso a tu archivo de licencia de Spanner Omni.

Opción B: Comienza a usar una lista de servidores raíz

Para iniciar un trabajador con una lista de servidores raíz, ejecuta el 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

Reemplaza lo siguiente:

  • LOCATION_NAME: Es el nombre de la ubicación de destino, por ejemplo, us-central1.
  • WORKER_HOSTNAME: Es el nombre de host o la dirección IP de la VM de trabajador que se puede resolver.
  • WORKER_PORT_BASE: Es el puerto base en el que se inicia el trabajador, por ejemplo, 15000 o 20000.
  • ROOT_SERVER_1_HOST, ROOT_SERVER_2_HOST: Son los nombres de host o las direcciones IP de los servidores raíz en tu implementación.
  • ROOT_SERVER_PORT_BASE: Es el puerto base de los servidores raíz, por ejemplo, 15000.
  • BASE_DIR: Es el directorio base para los datos y los registros del trabajador, por ejemplo, /var/spanner.
  • LICENSE_FILE_PATH: Es la ruta de acceso a tu archivo de licencia de Spanner Omni.

Configura la encriptación

Si tu implementación de Spanner Omni usa encriptación TLS o mTLS, configura la encriptación para cada trabajador:

  1. Actualiza el certificado del servidor para incluir los nombres de host de los trabajadores si aún no los incluiste.
  2. Copia el directorio de certificados que contiene ca.crt, server.crt y server.key en la VM de trabajador.

  3. Agrega la marca --certificate-directory cuando ejecutes 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

    Reemplaza CERTIFICATE_DIRECTORY por el directorio que contiene ca.crt, server.crt y server.key.

Para obtener más información sobre la configuración de certificados y las implementaciones seguras, consulta Crea una implementación segura en VMs.

Implementa trabajadores en Kubernetes

En los entornos de Kubernetes, como Google Kubernetes Engine (GKE) o Amazon Elastic Kubernetes Service (Amazon EKS), implementas trabajadores como parte de tu versión existente de Spanner Omni Helm en el mismo espacio de nombres que tu clúster. El chart de Helm implementa trabajadores como un StatefulSet de Kubernetes con un servicio sin interfaz gráfica, lo que proporciona a cada Pod de trabajador una identidad de red estable y PersistentVolumeClaims (PVC), lo que permite que los servidores raíz se comuniquen de manera confiable con cada trabajador.

De forma predeterminada, el gráfico de Helm programa los Pods de trabajador solo en los nodos etiquetados como spanner-role=workers, tolera el aislamiento spanner-role=workers:NoSchedule y ejecuta como máximo un Pod de trabajador por nodo. Antes de habilitar los trabajadores, agrega un grupo de nodos con esta etiqueta y este taint que tenga al menos tantos nodos como workers.replicas. Cada nodo necesita suficiente CPU y memoria asignables para un Pod de trabajador, según lo establecen workers.resources.cpu y workers.resources.memory. Kubernetes reserva parte de la capacidad de cada nodo para los componentes del sistema, por lo que debes elegir nodos más grandes que estos valores. Para usar una etiqueta diferente, configura workers.nodeLabelKey y workers.nodeLabelValue. Para quitar el requisito de la etiqueta, establece workers.nodeLabelKey="". Para reemplazar las reglas de programación predeterminadas, establece workers.affinity.

Para habilitar los trabajadores en tu implementación existente, ejecuta el comando helm upgrade:

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

Reemplaza lo siguiente:

  • HELM_CHART_PATH: Es la ruta de acceso a tu gráfico de Helm de Spanner Omni.
  • NAMESPACE: Es el espacio de nombres de Kubernetes en el que se implementa tu clúster de Spanner Omni, por ejemplo, spanner-ns.

Para permitir que los trabajadores se ejecuten en cualquier nodo que tenga suficiente CPU y memoria asignables, establece workers.nodeLabelKey en una cadena vacía. Esto quita el requisito de etiqueta de nodo y la tolerancia a la contaminación:

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

Los parámetros de configuración opcionales incluyen los siguientes:

  • --set workers.replicas=WORKER_REPLICAS: Es la cantidad de réplicas de trabajadores que se implementarán. El valor predeterminado es 1.

  • --set workers.resources.cpu=CPU_CORES: Es el límite y la solicitud de CPU para cada trabajador. El valor predeterminado es 6.

  • --set workers.resources.memory=MEMORY_LIMIT: Límite y solicitud de memoria para cada trabajador. El valor predeterminado es 24Gi.

  • --set workers.storage.size=STORAGE_SIZE: Es la capacidad de almacenamiento de cada trabajador. El valor predeterminado es 20Gi.

  • --set workers.storage.storageClassName=STORAGE_CLASS: Clase de almacenamiento que se usará para el almacenamiento de trabajadores, por ejemplo, hyperdisk-balanced-rwo en GKE o aws-gp3 en Amazon EKS. El valor predeterminado es una cadena vacía, que hereda la clase de almacenamiento predeterminada del clúster.

  • --set workers.port=WORKER_PORT: Es el puerto de red en el que escucha el trabajador. El valor predeterminado es deployment.basePort, que es 15000.

  • --set workers.joinServers={ROOT_HOST_1:PORT,ROOT_HOST_2:PORT}: Es una lista explícita separada por comas de las direcciones de los servidores raíz a los que se unirá. El valor predeterminado es una lista vacía ([]), que descubre todos los servidores raíz activos de la topología de implementación.

  • --set workers.nodeLabelKey=NODE_LABEL_KEY: Es la clave de etiqueta del nodo de Kubernetes que se usa para la afinidad y las tolerancias de nodos para aislar los trabajadores en un grupo de nodos dedicado. El valor predeterminado es spanner-role. Configúralo como una cadena vacía "" para inhabilitar la afinidad y las tolerancias de nodos.

  • --set workers.nodeLabelValue=NODE_LABEL_VALUE: Es el valor de la etiqueta del nodo de Kubernetes que se usa para la afinidad de nodos y las tolerancias. El valor predeterminado workers.

  • --set workers.pdbMaxUnavailable=MAX_UNAVAILABLE: Es la cantidad máxima de Pods de trabajadores que pueden no estar disponibles durante las interrupciones voluntarias en PodDisruptionBudget. El valor predeterminado es 1.

  • workers.affinity: Son reglas de afinidad personalizadas de Kubernetes para los Pods de trabajo. Si no se especifica, se aplican la afinidad de nodo predeterminada (con workers.nodeLabelKey y workers.nodeLabelValue) y la anti-afinidad de Pod en todos los nombres de host (kubernetes.io/hostname). Como se trata de un objeto anidado, especifícalo en un archivo values.yaml con la marca -f.

Verifica la implementación del trabajador

Para verificar que los Pods de trabajador se estén ejecutando y estén listos, ejecuta el siguiente comando:

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

Cómo escalar y retirar trabajadores

Los trabajadores no almacenan datos del usuario ni participan en el consenso de la base de datos. El ajuste de escala y la baja de los trabajadores son instantáneos. Puedes iniciar un trabajador antes o después de iniciar la creación del índice de vectores, y dar de baja al trabajador inmediatamente después de que se complete la creación del índice.

Automatiza el escalamiento de trabajadores

Para automatizar la creación y el ajuste de escala de los trabajadores, supervisa la métrica spanner_box_compute_heavy_workers_required. Cuando el valor de la métrica es mayor que 0, la implementación requiere uno o más trabajadores para completar las operaciones en segundo plano pendientes, como la creación de un índice de vectores en una tabla grande. Cuando el valor de la métrica vuelve a 0, todas las operaciones pendientes se completan y puedes retirar los trabajadores.

Cómo retirar un trabajador de VM

Para detener un proceso de trabajador que se ejecuta en una VM, presiona Control + C en la terminal que ejecuta el proceso de trabajador o detén el proceso con su ID de proceso (PID):

kill -TERM PID

Reemplaza PID por el ID del proceso de spanner workers. Como alternativa, apaga la VM de trabajador.

Cómo retirar un trabajador de Kubernetes

Para retirar los trabajadores en Kubernetes, inhabilítalos en tu versión de Helm o reduce la escala verticalmente de las réplicas de trabajadores directamente con kubectl:

  • Inhabilita los trabajadores: Para quitar el trabajador StatefulSet y el servicio de tu clúster y, al mismo tiempo, conservar el resto de la implementación, ejecuta el comando helm upgrade con workers.enabled=false:

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

    Reemplaza lo siguiente:

    • HELM_CHART_PATH: Es la ruta de acceso a tu gráfico de Helm de Spanner Omni.
    • NAMESPACE: Es el espacio de nombres de Kubernetes en el que se implementa tu clúster de Spanner Omni, por ejemplo, spanner-ns.

  • Reducir la escala verticalmente de las réplicas de trabajadores: Para reducir la escala verticalmente de los Pods de trabajadores a cero réplicas y mantener activa la configuración de trabajadores en tu clúster, ejecuta el comando kubectl scale:

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

    Reemplaza NAMESPACE por el espacio de nombres de Kubernetes en el que se implementa tu clúster de Spanner Omni, por ejemplo, spanner-ns.

Supervisa y soluciona problemas de los trabajadores

Si tu implementación tiene habilitada la supervisión, puedes supervisar los trabajadores con los paneles de Prometheus o Grafana. Los trabajadores exponen métricas similares a las de los servidores de Spanner Omni. Los paneles de Grafana incluyen un panel de Estadísticas de los trabajadores que te permite supervisar el uso de recursos de cada trabajador.

Los trabajadores escriben archivos de registro en el subdirectorio logs dentro del directorio base especificado por --base-dir:

BASE_DIR/logs

El comando spanner admin diagnostics create no recopila registros ni diagnósticos de los trabajadores. Para inspeccionar los registros del trabajador, consulta los archivos en BASE_DIR/logs directamente en la máquina o el Pod del trabajador, o bien ejecuta kubectl logs para los Pods del trabajador de Kubernetes.

Para obtener más información sobre la supervisión y la configuración de paneles, consulta Descripción general de Monitoring y Supervisa con paneles de Grafana.

La creación del índice vectorial no avanza

Si creas un índice vectorial en una tabla grande y la creación del índice permanece pendiente sin avanzar, verifica que al menos un trabajador esté en ejecución y conectado a la implementación.

Spanner Omni te permite crear un índice vectorial incluso cuando no hay trabajadores activos, de modo que puedas implementar trabajadores solo cuando sea necesario. Si no hay ningún trabajador activo, la operación de creación de índices se detiene de forma indefinida hasta que se implemente un trabajador. Una vez que se inicia un trabajador y se registra en la implementación, se reanuda automáticamente la creación del índice.