Configuraciones de la Deployment

En este documento, se describen las configuraciones de implementación de Spanner Omni en máquinas virtuales (VM) o servidores de metal desnudo. En este documento, se explican la estructura y las opciones de configuración del archivo de configuración de implementación en YAML (deployment.yaml) que se usa para definir las topologías de implementación de VM y los parámetros de ejecución cuando se usa la CLI de Spanner Omni.

Para obtener información sobre cómo crear una implementación, consulta uno de los siguientes recursos:

Descripción general de la configuración de Deployment

Cuando creas una implementación en VMs o servidores de metal desnudo, pasas este archivo de configuración al comando spanner deployment create en la CLI de Spanner Omni:

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

La configuración de la implementación define los siguientes elementos clave:

  • Modo de un solo servidor: Es un modo de optimización que restringe toda la implementación a un solo servidor para el desarrollo y las pruebas.
  • Ubicaciones: Son los sitios físicos o las regiones de la nube en los que residen tus servidores.
  • Distancias entre ubicaciones: Son las latencias de red entre pares de ubicaciones.
  • Zonas: Son agrupaciones lógicas de servidores que representan réplicas de Paxos.
  • Servidores raíz: Son servidores dedicados responsables de los metadatos de zona y el quórum de membresía.
  • Tipos de réplicas: Roles para cada zona (lectura y escritura, testigo o solo lectura).
  • ANS de reloj: Parámetros de sincronización de TrueTime, incluidos la fluctuación del reloj y el error de la tasa de desviación.
  • Configuración de implementación: Son parámetros de configuración globales, como las ubicaciones de líderes preferidas y la configuración de seguridad de autenticación.

Estructura del archivo de configuración

En el siguiente ejemplo, se muestra la estructura de nivel superior de un archivo de configuración de implementación:

# 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

Campos de nivel superior

La configuración de implementación admite los siguientes campos de nivel superior:

Campo Tipo Descripción
name String Nombre de la implementación, como prod, staging o regional-deployment.
single_server Booleano Es opcional. Si se configura como true, especifica que toda la implementación es de un solo servidor, lo que la restringe a una zona y un servidor. Las implementaciones creadas con single_server: true no pueden agregar zonas ni servidores después de la creación. Si deseas ejecutar Spanner Omni en modo de un solo servidor, no necesitas crear esta configuración de forma manual, ya que Spanner Omni la genera automáticamente cuando ejecutas el comando spanner start-single-server. El valor predeterminado es false.
location Lista de objetos Son las ubicaciones (regiones) físicas o lógicas en la implementación.
location_distance Lista de objetos Es opcional. Es la latencia de red entre pares de ubicaciones.
zone Lista de objetos Obligatorio. Son las zonas que conforman la implementación. Debes especificar al menos una zona.
clock_sla Objeto Es opcional. Parámetros del Acuerdo de Nivel de Servicio (ANS) de sincronización del reloj para TrueTime de software.
deployment_settings Objeto Es opcional. Es la configuración del entorno de ejecución para la ubicación preferida del líder y la autenticación de seguridad.

Nombre de la implementación

El campo name especifica un nombre elegido por el usuario para la implementación. Puedes usar cualquier cadena que identifique la implementación, como prod, staging o regional-deployment.

Modo de servidor único

El campo single_server de nivel superior especifica que toda la implementación es una implementación de un solo servidor. Cuando se establece en true, este parámetro de configuración restringe la implementación a una zona y un servidor, lo que reduce la sobrecarga de recursos para los entornos de desarrollo y pruebas locales. Las implementaciones creadas con single_server:true no pueden agregar zonas ni servidores después de la creación.

Si deseas ejecutar Spanner Omni en el modo de un solo servidor, no es necesario que crees esta configuración de forma manual. Cuando ejecutas el comando spanner start-single-server, Spanner Omni genera automáticamente esta configuración por ti. Para obtener más información, consulta Opción A: Implementación en un solo servidor.

El campo single_server de nivel superior es distinto del campo single_server a nivel de la zona:

  • El campo single_server de nivel superior se aplica a toda la implementación.
  • El campo a nivel de la zona single_server se aplica solo a una zona individual dentro de una implementación. Para obtener más información, consulta Zonas de un solo servidor.

Ubicaciones

Una ubicación representa un centro de datos físico o una región de la nube en la que se encuentran las máquinas (es equivalente a una región en Google Cloud).

Defines ubicaciones en la lista location:

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

Los nombres de ubicación deben cumplir con los siguientes requisitos:

  • Debe comenzar con una letra y terminar con una letra o un dígito.
  • Solo puede contener letras, dígitos, guiones bajos (_) y guiones (-).
  • Opcionalmente, puede incluir un prefijo de dominio seguido de dos puntos (por ejemplo, cloud.google.com:us-east1 o onprem:datacenter1).
  • No se puede usar el nombre reservado default.
  • Debe ser único en toda la implementación.

Distancias de ubicación

La lista location_distance especifica la latencia de red entre pares de ubicaciones. Spanner Omni usa esta información para optimizar la replicación y el enrutamiento de consultas.

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

Cada objeto de distancia de ubicación contiene los siguientes campos:

  • src: Obligatorio. Es el nombre de la ubicación de origen. Debe coincidir con una ubicación definida en la lista location.
  • dest: Obligatorio. Es el nombre de la ubicación de destino. Debe coincidir con una ubicación definida y no puede ser idéntica a src.
  • latency_ms: Es la latencia de red en milisegundos. Debe ser un número entero no negativo. Si se omite, Spanner Omni supone que la latencia es insignificante (inferior a un milisegundo).

La latencia de red en las redes físicas no siempre es simétrica. Si proporcionas (src, dest) y (dest, src), Spanner Omni respeta ambas mediciones. Si solo proporcionas una dirección, Spanner Omni supone que la dirección inversa tiene la misma latencia.

Zonas

Una zona es una agrupación lógica de uno o más servidores dentro de una ubicación. Para la replicación de datos, cada zona representa una réplica de Paxos. Una implementación debe tener al menos una zona.

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

Cada objeto de zona admite los siguientes campos:

Campo Tipo Descripción
name String Obligatorio. Es el nombre de la zona. Sigue las mismas reglas de nomenclatura que los nombres de ubicación. Debe ser único en toda la implementación.
location String Es el nombre de la ubicación en la que reside la zona. Debe coincidir con una ubicación definida en la lista location. Si se omite, Spanner Omni asigna la zona a la ubicación default.
single_server Booleano Es opcional. Si se establece en true, designa que esta zona solo tiene un servidor (solo puede tener un servidor raíz y ningún otro servidor). Elimina la sobrecarga de replicación de metadatos de zona dentro de la zona. En una implementación multizonal, puedes establecer este valor en true para zonas específicas, como una zona de réplica de WITNESS que no almacena datos del usuario, mientras que otras zonas tienen varios servidores. El valor predeterminado es false.
replica_type Cadena de enumeración Es el rol de réplica de la zona en los quórums de Paxos. Los valores admitidos son READ_WRITE, WITNESS y READ_ONLY. El valor predeterminado es READ_WRITE.
root_server Lista de objetos Obligatorio. Es la lista de servidores raíz de la zona.

Tipos de réplicas

Spanner Omni admite tres tipos de réplicas para las zonas:

  • READ_WRITE: Almacena una copia completa de los datos del usuario, responde a las solicitudes de lectura y vota en los quórums de Paxos. Las réplicas de lectura y escritura son aptas para convertirse en líderes de Paxos y proponer escrituras.
  • WITNESS: Vota en los quórums de Paxos para ayudar a lograr el consenso, pero no puede convertirse en líder. Las réplicas de testigos no almacenan datos del usuario y no pueden atender solicitudes de lectura. Ayudan a lograr el quórum sin la sobrecarga de almacenamiento ni la latencia de escritura de una réplica completa en ubicaciones distantes.
  • READ_ONLY: Almacena una copia completa de los datos del usuario que se replican de forma asíncrona desde los líderes. Las réplicas de solo lectura no pueden convertirse en líderes ni votar en los quórums de Paxos. Descargan el tráfico de lectura de las réplicas de lectura y escritura.

Cuando configures los tipos de réplicas, asegúrate de que tu implementación cumpla con las siguientes reglas:

  • La implementación debe contener al menos una zona READ_WRITE.
  • La cantidad de zonas READ_WRITE debe ser estrictamente mayor que la cantidad de zonas WITNESS.

Servidores raíz

Los servidores raíz tienen responsabilidades especiales en Spanner Omni. Almacenan metadatos de la zona y administran la membresía de otros servidores en la zona. Si un quórum de servidores raíz deja de estar disponible, toda la zona dejará de estar disponible.

Cuando configures servidores raíz en deployment.yaml, ten en cuenta los siguientes lineamientos:

  • La cantidad de servidores raíz por zona debe ser un número impar entre uno y nueve, inclusive, para garantizar el quórum de coherencia. Si la cantidad de servidores es un número par, es posible que las implementaciones fallen. Cuando configures tus zonas, designa servidores como servidores raíz. Te recomendamos que uses una para el desarrollo o las pruebas, y tres para las zonas de producción con alta disponibilidad.
  • Solo especifica servidores raíz en el archivo deployment.yaml durante la creación de la implementación inicial. Los servidores que no son raíz se pueden agregar más adelante para escalar la capacidad de procesamiento y almacenamiento.

Cada objeto de servidor raíz admite los siguientes campos:

  • host: Obligatorio. Nombre de host o dirección IP de la máquina que ejecuta el servidor.
  • port_base: Opcional. Es el número de puerto inicial del servidor. El valor predeterminado es 15000. Este puerto se convierte en el puerto gRPC público para las conexiones de clientes. Debes reservar puertos en el rango [port_base + 1, port_base + 31] (por ejemplo, del 15001 al 15031) para los procesos internos de Spanner Omni.

Zonas de un solo servidor

El campo single_server a nivel de la zona especifica que una zona individual contiene solo un servidor. Una zona de un solo servidor solo puede tener un servidor raíz y no se le pueden agregar servidores adicionales más adelante. Este parámetro de configuración elimina la sobrecarga de replicar los metadatos de la zona dentro de esa zona.

A diferencia del campo single_server de nivel superior, que designa que toda la implementación consta de un solo servidor, el campo single_server a nivel de la zona solo se aplica a esa zona específica.

En una implementación multizona, puedes configurar zonas individuales como zonas de un solo servidor, mientras que otras zonas contienen varios servidores. Por ejemplo, considera una implementación con dos zonas de réplica READ_WRITE y una zona de réplica WITNESS:

  • Las dos zonas de READ_WRITE contienen varios servidores (single_server: false) para proporcionar alta disponibilidad y escalar la capacidad de procesamiento y almacenamiento de los datos del usuario.
  • Puedes configurar la zona WITNESS como una zona de un solo servidor o una zona de varios servidores, según el volumen de votación de Paxos:
    • Cargas de trabajo pequeñas a medianas: Si una sola VM o un solo servidor tienen capacidad suficiente para procesar todo el tráfico de votación de Paxos para la implementación, establece single_server: true. Debido a que las réplicas de testigos solo emiten votos y no almacenan datos del usuario, usar un solo servidor elimina la sobrecarga de replicación de metadatos dentro de la zona.
    • Implementaciones a gran escala: Si tienes una capacidad de procesamiento de escritura alta o muchos servidores en cada zona de READ_WRITE (por ejemplo, docenas o cientos de nodos), un solo servidor puede sobrecargarse y provocar errores de consenso de Paxos. Configura la zona WITNESS con varios servidores (single_server: false) para distribuir la carga de trabajo de votación.

Para ver un ejemplo de configuración, consulta Implementación en varias ubicaciones con una réplica de testigo.

ANS de reloj

Spanner Omni se basa en el software TrueTime para proporcionar coherencia externa sin necesidad de relojes atómicos ni hardware de GPS especializados. El objeto clock_sla define los límites de sincronización esperados para los relojes del servidor en toda la implementación:

clock_sla:
  jitter_in_s: 0.005
  rate_error_in_ppm: 200

La configuración de clock_sla incluye los siguientes campos:

  • jitter_in_s: Es la fluctuación máxima esperada del reloj en segundos. Debe ser un número de punto flotante no negativo (>= 0).
  • rate_error_in_ppm: Es el error máximo de la tasa de desviación del reloj en partes por millón (ppm). Debe ser un valor entre 0 y 10000.

Para obtener más información sobre la sincronización de hora, consulta TrueTime y coherencia externa.

Configuración de la implementación

El objeto deployment_settings configura el comportamiento de la implementación global, incluida la preferencia de ubicación del líder y la seguridad de la red:

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

Ubicación del líder preferida

El campo preferred_leader_location designa una ubicación en la que se colocan preferentemente los líderes de Paxos. Elegir líderes cerca de tu carga de trabajo principal de la aplicación reduce la latencia de escritura, ya que evita recorridos de ida y vuelta adicionales en la red.

Cuando configures preferred_leader_location, asegúrate de lo siguiente:

  • La ubicación especificada debe coincidir con una ubicación definida en la lista location (o default).
  • La ubicación designada debe contener al menos una zona READ_WRITE.

Configuración de seguridad

El objeto security_settings configura los modos de autenticación y encriptación:

  • insecure_mode: Booleano. Si se configura como true, se inhabilitan la autenticación y la autorización para las conexiones entrantes. Este modo solo se utiliza para la creación de prototipos y la evaluación. El valor predeterminado es false.
  • authentication_methods: Es la lista de métodos de autenticación habilitados. Obligatorio si insecure_mode es false. Valores admitidos:
    • AUTHENTICATION_METHOD_PASSWORD: Habilita la autenticación con nombre de usuario y contraseña.
    • AUTHENTICATION_METHOD_CLIENT_CERTIFICATE: Habilita la autenticación de certificado de cliente de TLS mutua (mTLS).
  • password_authentication_protocol: Es el protocolo que se usa para la verificación de contraseñas. Se requiere si AUTHENTICATION_METHOD_PASSWORD se incluye en authentication_methods. Valor admitido:
    • PASSWORD_AUTHENTICATION_PROTOCOL_OPAQUE: Usa el protocolo de intercambio de claves autenticado con contraseña asimétrica OPAQUE.

Para obtener más información sobre cómo configurar la encriptación y las credenciales, consulta Crea una implementación con encriptación TLS en VMs.

Ejemplos de configuración de Deployment

En los siguientes ejemplos, se muestran patrones de implementación comunes.

Implementación regional en varias zonas

La siguiente configuración crea una implementación regional con alta disponibilidad en tres zonas de una sola ubicación:

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

Implementación en varias ubicaciones con réplica testigo

La siguiente configuración crea una implementación en varias ubicaciones que abarca dos centros de datos y un sitio de testigo, con la ubicación del líder preferida. La lista location_distance especifica latencias de red realistas y asimétricas entre cada par de ubicaciones. Cada una de las dos zonas READ_WRITE usa tres servidores raíz para lograr una alta disponibilidad, mientras que la zona WITNESS usa single_server: true con un solo servidor raíz, ya que las réplicas de testigo no almacenan datos del usuario:

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

Implementación segura con TLS y autenticación

La siguiente configuración define una implementación con mTLS y autenticación por contraseña habilitadas:

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

¿Qué sigue?