Despliegue multirregional en AKS

En este tema se explica cómo configurar una implementación multirregión para Apigee hybrid en Microsoft® Azure Kubernetes Service (AKS).

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:

Requisitos previos

Antes de configurar la opción híbrida para varias regiones, debes cumplir los siguientes requisitos:

  • Sigue la guía de instalación híbrida para conocer los requisitos previos, como la configuración de GCP y de la organización, antes de pasar a los pasos de configuración del clúster.

Para obtener información detallada, consulta la documentación de Kubernetes.

Crear una red virtual en cada región

Crea una red virtual para el despliegue multirregional. Por ejemplo, los siguientes comandos crean redes en las regiones Centro de EE. UU. y Este de EE. UU.

Ejecuta este comando para crear una red virtual en la región Este de EE. UU. con el nombre my-hybrid-rg-vnet:

az network vnet create \
 --name my-hybrid-rg-vnet \
 --location eastus \
 --resource-group my-hybrid-rg \
 --address-prefixes 120.38.1.0/24 \
 --subnet-name my-hybrid-rg-vnet-subnet \
 --subnet-prefix 120.38.1.0/26

Ejecuta este comando para crear una red virtual en la región Centro de EE. UU. con el nombre my-hybrid-rg-vnet-ext01:

az network vnet create \
 --name my-hybrid-rg-vnet-ext01 \
 --location centralus \
 --resource-group my-hybrid-rg \
 --address-prefixes 192.138.0.0/24 \
 --subnet-name my-hybrid-rg-vnet-ext01-subnet \
 --subnet-prefix 192.138.0.0/26

Crear un intercambio de tráfico entre redes

Crea un emparejamiento de red entre las redes virtuales.

Obtener los IDs de la red virtual

Los emparejamientos se establecen entre IDs de redes virtuales. Obtenga el ID de cada red virtual con el comando az network vnet show y almacene el ID en una variable.

Obtén el ID de la primera red virtual, la que se llama my-hybrid-rg-vnet:

vNet1Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet \
 --query id --out tsv)

Obtén el ID de la segunda red virtual, la que se llama my-hybrid-rg-vnet-ext01:

vNet2Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet-ext01 \
 --query id \
 --out tsv)

Crear el emparejamiento de la primera a la segunda red virtual

Con los IDs de red virtual, puedes crear un emparejamiento de la primera red virtual (my-hybrid-rg-vnet) a la segunda (my-hybrid-rg-vnet-ext01), como se muestra en los siguientes ejemplos:

az network vnet peering create \
 --name my-hybrid-rg-vnet1-peering \     # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \         # The virtual network name.
 --remote-vnet $vNet2Id \                # Resource ID of the remote virtual network.
 --allow-vnet-access

En la salida del comando, observe que el peeringState es Iniciado. El emparejamiento permanece en el estado Iniciado hasta que crees el emparejamiento de la segunda red virtual a la primera.

{
  ...
  "peeringState": "Initiated",
  ...
}

Crea un intercambio de tráfico entre la segunda red virtual y la primera

Comando de ejemplo:

az network vnet peering create \
 --name my-hybrid-rg-vnet2-peering \        # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet-ext01 \      # The virtual network name.
 --remote-vnet $vNet1Id \                   # Resource ID of the remote virtual network.
 --allow-vnet-access

En la salida del comando, comprueba que peeringState es Connected. Azure también cambia el estado de emparejamiento de la primera a la segunda red virtual a Conectado.

{
  ...
  "peeringState": "Connected",
  ...
}

También puede confirmar que el estado de emparejamiento de my-hybrid-rg-vnet1-peering a my-hybrid-rg-vnet2-peering: ha cambiado a Conectado con el siguiente comando:

az network vnet peering show \
 --name my-hybrid-rg-vnet1-peering \
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \
 --query peeringState

Resultado esperado:

Connected

Crear clústeres multirregionales

Configura clústeres de Kubernetes en varias regiones con diferentes bloques CIDR. Consulta también la guía de inicio rápido de AKS. Usa los nombres de las ubicaciones y de las redes virtuales que hayas creado anteriormente.

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).

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í.

  1. Define el contexto de kubectl en el clúster original antes de recuperar el nombre de la semilla:
    kubectl config use-context original-cluster-name
  2. 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 | grep apigee-cassandra
    
    apigee-cassandra-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
    
  3. Decide cuál de las IPs devueltas por el comando anterior será el host de seed multirregión. En este ejemplo, en el que solo se ejecuta un clúster de Cassandra de un solo nodo, el host de la semilla es 120.38.1.9.
  4. En el centro de datos 2, copie el archivo de anulaciones en un archivo nuevo cuyo nombre incluya el nombre del clúster. Por ejemplo, overrides_your_cluster_name.yaml.
  5. En el centro de datos 2, configure cassandra.multiRegionSeedHost y cassandra.datacenter en overrides_your_cluster_name.yaml, donde multiRegionSeedHost 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: 120.38.1.9
      datacenter: "centralus"
      rack: "ra-1"
  6. 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_your_cluster_name.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:

  1. 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.
    1. Define 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 secreto de apigee-ca a un archivo:
      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
    4. Define el contexto con el nombre del clúster de la nueva región:
      kubectl config use-context new-cluster-name
    5. Importa la configuración del espacio de nombres al nuevo clúster. Asegúrate de actualizar el espacio de nombres del archivo si usas otro en la nueva región:
      kubectl apply -f apigee-namespace.yaml
    6. Importa el secreto al nuevo clúster:

      kubectl -n cert-manager apply -f apigee-ca.yaml
  2. Instala la versión híbrida en la nueva región. Asegúrate de que el archivo overrides_your_cluster_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_your_cluster_name.yaml
    apigeectl apply -f overrides_your_cluster_name.yaml
  3. Amplía todos los espacios de claves de Apigee.

    Sigue estos pasos para ampliar los datos de Cassandra al nuevo centro de datos:

    1. Abre un shell en el pod de Cassandra:
      kubectl run -i --tty --restart=Never --rm --image google/apigee-hybrid-cassandra-client:1.0.0 cqlsh
    2. Conéctate al servidor de Cassandra:
      cqlsh apigee-cassandra-0.apigee-cassandra.apigee.svc.cluster.local -u ddl_user --ssl
      Password:
      
      Connected to apigeecluster at apigee-cassandra-0.apigee-cassandra.apigee.svc.cluster.local:9042.
      [cqlsh 5.0.1 | Cassandra 3.11.3 | CQL spec 3.4.4 | Native protocol v4]
      Use HELP for help.
    3. Obtén los espacios de claves disponibles:
      SELECT * from system_schema.keyspaces ;
       keyspace_name              | durable_writes | replication
      ----------------------------+----------------+--------------------------------------------------------------------------------------------------------
                      system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
                    system_schema |           True |                                                {'class': 'org.apache.cassandra.locator.LocalStrategy'}
       cache_hybrid_test_7_hybrid |           True |                  {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         kms_hybrid_test_7_hybrid |           True |                  {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         kvm_hybrid_test_7_hybrid |           True |                  {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
               system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
                           system |           True |                                                {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                           perses |           True |                  {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       quota_hybrid_test_7_hybrid |           True |                  {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                    system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
      
      (10 rows)
    4. Actualiza o amplía los espacios de claves de Apigee:
      ALTER KEYSPACE cache_hybrid_test_7_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-1':3, 'dc-2':3};
      ALTER KEYSPACE kms_hybrid_test_7_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-1':3, 'dc-2':3};
      ALTER KEYSPACE kvm_hybrid_test_7_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-1':3, 'dc-2':3};
      ALTER KEYSPACE perses WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-1':3, 'dc-2':3};
      ALTER KEYSPACE quota_hybrid_test_7_hybrid  WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-1':3, 'dc-2':3};
    5. Valida la expansión del espacio de claves:
      SELECT * from system_schema.keyspaces ;
       keyspace_name              | durable_writes | replication
      ----------------------------+----------------+--------------------------------------------------------------------------------------------------------
                      system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
                    system_schema |           True |                                                {'class': 'org.apache.cassandra.locator.LocalStrategy'}
       cache_hybrid_test_7_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3', 'dc-2': '3'}
         kms_hybrid_test_7_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3', 'dc-2': '3'}
         kvm_hybrid_test_7_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3', 'dc-2': '3'}
               system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
                           system |           True |                                                {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                           perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3', 'dc-2': '3'}
       quota_hybrid_test_7_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3', 'dc-2': '3'}
                    system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
      
      (10 rows)
      ddl@cqlsh>
  4. Ejecuta nodetool rebuild de forma secuencial en todos los nodos 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-0 -n apigee  -- nodetool rebuild -- dc-1
  5. 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-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
  6. Actualiza los hosts de inicialización. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a aplicarlo.
    apigeectl apply -f overrides-DC_name.yaml