- v1.15 (última)
- v1.14
- v1.13
- Lista de versiones admitidas
- v1.12
- v1.11
- v1.10
- v1.9
- v1.8
- v1.7
- Versión 1.6
- v1.5
- Versión 1.4
- Versión 1.3
- v1.2
- v1.1
Versiones compatibles:
Versiones no compatibles:
En este tema se describe un despliegue multirregional de Apigee hybrid en GKE y Anthos GKE desplegado on-prem.
Las topologías de implementación multirregional incluyen las siguientes:
- Activo-activo: cuando tienes aplicaciones implementadas en varias ubicaciones geográficas y necesitas una respuesta de API de baja latencia para tus implementaciones. Tiene la opción de implementar una solución híbrida en varias ubicaciones geográficas cercanas a sus clientes. Por ejemplo: costa oeste de EE. UU., costa este de EE. UU., Europa o Asia-Pacífico.
- Activo-Pasivo: cuando tienes una región principal y una región de conmutación por error o de recuperación tras desastres.
Las regiones de una implementación híbrida multirregional se comunican a través de Cassandra, como se muestra en la siguiente imagen:
Balancear la carga de la conexión MART
Cada clúster regional debe tener su propia dirección IP y nombre de host de MART. Sin embargo, solo tienes que conectar el plano de gestión a uno de ellos. Cassandra propaga la información a todos los clústeres. La mejor opción para conseguir una alta disponibilidad de MART es balancear la carga de las direcciones IP de MART individuales y configurar tu organización para que se comunique con la URL de MART con balanceo de carga.
Requisitos previos
Antes de configurar la opción híbrida para varias regiones, debes cumplir los siguientes requisitos:
- Configurar clústeres de Kubernetes en varias regiones con diferentes bloques CIDR
- Configurar la comunicación entre regiones
- Abre los puertos 7000 y 7001 de Cassandra entre los clústeres de Kubernetes de todas las regiones (el puerto 7000 se puede usar como opción de copia de seguridad durante la solución de problemas). Consulta también Configurar puertos.
Para obtener información detallada, consulta la documentación de Kubernetes.
Configurar el host de seed multirregional
En esta sección se describe cómo ampliar el clúster de Cassandra a una nueva región. Esta configuración permite que la nueva región arranque el clúster y se una al centro de datos. Sin esta configuración, los clústeres de Kubernetes multirregionales no se reconocerían entre sí.
Ejecuta el siguiente comando
kubectl
para identificar una dirección de host de inicialización de Cassandra en la región actual.Una dirección de host de inicialización permite que una nueva instancia regional encuentre el clúster original en el primer inicio para conocer la topología del clúster. La dirección del host de inicio se designa como punto de contacto del 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
- Decide cuál de las IPs devueltas por el comando anterior será el host de seed multirregión.
La configuración de este paso depende de si usas GKE o GKE On-Prem:
Solo en GKE: En el centro de datos 2, configure
cassandra.multiRegionSeedHost
ycassandra.datacenter
en Gestionar componentes del plano de tiempo de ejecución, dondemultiRegionSeedHost
es una de las IPs devueltas por 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 anulaciones, dondemultiRegionSeedHost
es una de las IPs devueltas por el comando anterior:cassandra: hostNetwork: true multiRegionSeedHost: seed_host_IP
Por ejemplo:
cassandra: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet multiRegionSeedHost: 10.0.0.11
- En el nuevo centro de datos o región, antes de instalar la opción híbrida, define los mismos certificados TLS y las mismas credenciales en
overrides.yaml
que en la primera región.
Configurar la nueva región
Una vez que hayas configurado el host de origen, podrás configurar la nueva región.
Para configurar la nueva región, sigue estos pasos:
- Copia el certificado del clúster actual al nuevo. La nueva raíz de CA la usan Cassandra y otros componentes híbridos para mTLS. Por lo tanto, es fundamental que los certificados del clúster sean coherentes.
- Define el contexto en el espacio de nombres original:
kubectl config use-context original-cluster-name
- Exporta la configuración del espacio de nombres actual a un archivo:
$ kubectl get namespace
-o yaml > apigee-namespace.yaml - Exporta el secreto de
apigee-ca
a un archivo:kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
- Define el contexto con el nombre del clúster de la nueva región:
kubectl config use-context new-cluster-name
- Importa la configuración del espacio de nombres al nuevo clúster. Asegúrate de actualizar el
"namespace" del archivo si usas otro
en la nueva región:
kubectl apply -f apigee-namespace.yaml
Importa el secreto al nuevo clúster:
kubectl -n cert-manager apply -f apigee-ca.yaml
- Define el contexto en el espacio de nombres original:
- Instala la versión híbrida en la nueva región. Asegúrate de que el archivo
overrides-DC_name.yaml
incluya los mismos certificados TLS que se hayan configurado en la primera región, tal como se explica en la sección anterior.Ejecuta los dos comandos siguientes para instalar Hybrid en la nueva región:
apigeectl init -f overrides/overrides-DC_name.yaml
apigeectl apply -f overrides/overrides-DC_name.yaml
- Ejecuta
nodetool rebuild
secuencialmente en todos los pods del nuevo centro de datos. Este proceso puede tardar desde unos minutos hasta unas horas, en función del tamaño de los datos.kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool rebuild -- dc-1
- Verifica los procesos de recompilación en los registros. Además, compruebe el tamaño de los datos
con el comando
nodetool status
:kubectl logs apigee-cassandra-default-0 -f -n apigee
En el siguiente ejemplo se muestran 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
- Actualiza los hosts de inicialización. Quita
multiRegionSeedHost: 10.0.0.11
deoverrides-DC_name.yaml
y vuelve a aplicarlo.apigeectl apply -f overrides/overrides-DC_name.yaml
Comprobar el estado del clúster de Cassandra
El siguiente comando es útil para comprobar si la configuración del clúster se ha realizado correctamente en dos centros de datos. El comando comprueba el estado de nodetool 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