Implementación multirregional en GKE y GKE On-Prem

Estás viendo la versión 1.3 de la documentación de Apigee Hybrid. This version is end of life. You should upgrade to a newer version. Para obtener más información, consulta las Versiones compatibles.

Version 1.3 (unsupported)

   Versiones compatibles:

• v1.13 (la más reciente)                        
• v1.12                         
• v1.11                         
• Lista de versiones compatibles

   Versiones no compatibles

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

En este tema, se describe una implementación multirregional para Apigee Hybrid en GKE y Anthos GKE implementado de forma local.

Las topologías para la implementación multirregión incluyen lo siguiente:

• Activa-Activa: Cuando tienes aplicaciones implementadas en varias ubicaciones geográficas y necesitas una respuesta de API con baja latencia para tus implementaciones. Tienes la opción de implementar Hybrid en varias ubicaciones geográficas más cercanas a tus clientes. Por ejemplo, la costa oeste de EE.UU., la costa este de EE.UU., Europa y APAC.
• Activo-pasivo: Cuando tienes una región principal y una de conmutación por error o una de recuperación ante desastres.

Las regiones de una implementación híbrida multirregional se comunican a través de Cassandra, como se muestra en la siguiente imagen:

Balanceo de cargas de la conexión de MART

Cada clúster regional debe tener su propia IP de MART y su nombre de host. Sin embargo, solo necesitas conectar el plano de administración a uno de ellos. Cassandra propaga información a todos los clústeres. La mejor opción para la alta disponibilidad de MART es realizar un balanceo de cargas de las direcciones IP de MART individuales y configurar tu organización para que se comunique con la URL de MART con balanceo de cargas.

Requisitos previos

Antes de configurar Hybrid para varias regiones, debes completar los siguientes requisitos:

• Configura los clústeres de Kubernetes en varias regiones con diferentes bloques CIDR
• Configura la comunicación entre regiones
• Abre los puertos de Cassandra 7000 y 7001 entre clústeres de Kubernetes en todas las regiones (7000 se puede usar como opción de copia de seguridad durante la solución de problemas) Consulta también Configura puertos.

Consulta la documentación de Kubernetes para obtener información detallada.

NOTA: Apigee recomienda que te asegures de que los tiempos de tus servidores estén sincronizados.

Varias funciones, como el vencimiento y la revocación de tokens, dependen de horarios precisos del sistema. Si alojas los componentes del entorno de ejecución en diferentes centros de datos, asegúrate de que el sistema registre los horarios.

Puedes usar una herramienta como ntpdate para verificar que los horarios del servidor estén sincronizados.

Configura el host de origen de varias regiones

En esta sección, se describe cómo expandir el clúster existente de Cassandra a una región nueva. Esta configuración permite que la región nueva inicie el clúster y se una al centro de datos existente. Sin esta configuración, los clústeres de Kubernetes multirregionales no se reconocen entre sí.

1. Ejecuta el siguiente comando kubectl para identificar una dirección de host de origen de Cassandra en la región actual.

   Una dirección de host de origen permite que una instancia regional nueva encuentre el clúster original en el primer startup para obtener la topología del clúster. La dirección del host de origen se designa como el punto de contacto en el clúster.

   kubectl get pods -o wide -n apigee
   
   NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
   apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
   apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
   apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

2. Decide cuál de las IP que se muestran del comando anterior será el host de origen multirregión.

3. La configuración de este paso depende de si tienes GKE o GKE On-Prem:

   Solo GKE: En el centro de datos 2, configura cassandra.multiRegionSeedHost y cassandra.datacenter en Administrar componentes del plano de entorno de ejecución, en el que multiRegionSeedHost es una de las IP que muestra el comando anterior:

   cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name

   Por ejemplo:

   cassandra:
     multiRegionSeedHost: 10.0.0.11
     datacenter: "dc-2"
     rack: "ra-1"

   Solo GKE On-Prem: En el centro de datos 2, configura cassandra.multiRegionSeedHost en el archivo de anulación, en el que multiRegionSeedHost es una de las IP que muestra el comando anterior:

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP
   

   Por ejemplo:

   cassandra:
     hostNetwork: true
     dnsPolicy: ClusterFirstWithHostNet
     multiRegionSeedHost: 10.0.0.11
   

4. Antes de instalar Hybrid, en el centro de datos o la región nuevos, configura los mismos certificados TLS y las credenciales en overrides.yaml que configuraste en la primera región.
   NOTA: Asegúrate de usar los mismos certificados y credenciales TLS de Cassandra en el segundo centro de datos que proporcionaste en el centro de datos original. Las credenciales que configuraste en overrides.yaml en el primer centro de datos deben coincidir con las que especifiques en overrides.yaml en el segundo centro de datos. Si quieres obtener más detalles, consulta Configura TLS para Cassandra.

Configura la región nueva

Después de configurar el host de origen, puedes configurar la región nueva.

Para configurar la región nueva, haz lo siguiente:

1. Copia tu certificado del clúster existente en el clúster nuevo. Cassandra y otros componentes híbridos para mTLS usan la raíz de CA nueva. Por lo tanto, es fundamental tener certificados coherentes en todo el clúster.
   1. Establece el contexto en el espacio de nombres original:

      kubectl config use-context original-cluster-name

   2. Exporta la configuración del espacio de nombres actual a un archivo:

      $ kubectl get namespace  -o yaml > apigee-namespace.yaml

   3. Exporta el Secret apigee-ca a un archivo:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Establece el contexto en el nombre del clúster de la región nueva:

      kubectl config use-context new-cluster-name

   5. Importa la configuración del espacio de nombres al clúster nuevo. Asegúrate de actualizar el “espacio de nombres” en el archivo si usas un espacio de nombres diferente en la región nueva:

      kubectl apply -f apigee-namespace.yaml

   6. Importa el secreto al clúster nuevo:

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Instala el híbrido en la nueva región. Asegúrate de que el archivo overrides-DC_name.yaml incluya los mismos certificados TLS que se configuraron en la primera región, como se explica en la sección anterior.

   Ejecuta los siguientes dos comandos para instalar el servicio híbrido en la región nueva:

   apigeectl init -f overrides/overrides-DC_name.yaml

   apigeectl apply -f overrides/overrides-DC_name.yaml

3. Ejecuta nodetool rebuild de manera secuencial en todos los Pods en el nuevo centro de datos. Esto puede llevar unos minutos hasta algunas horas según el tamaño de los datos.

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool rebuild -- dc-1

4. Verifica los procesos de recompilación de los registros. Además, verifica el tamaño de los datos mediante el comando nodetool status:

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   El siguiente ejemplo muestra entradas de registro de ejemplo:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

5. Actualiza los hosts de origen. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a enviar la solicitud.
   Los hosts de origen son miembros del clúster local. Para iniciar una nueva región, se requiere un host de origen externo. Una vez que se inicia una región, debes cambiar los hosts de origen a sus clústeres locales en overrides.yaml y, luego, volver a aplicar la configuración.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Comprueba el estado del clúster de Cassandra

El siguiente comando es útil para ver si la configuración del clúster se realizó de forma correcta en dos centros de datos. El comando comprueba el estado de la herramienta del nodo de las dos regiones.

kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool status


Datacenter: us-central1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1