Implantação de várias regiões no AKS

Neste tópico, explicamos como configurar uma implantação de várias regiões para a Apigee híbrida no Microsoft® Azure Kubernetes Service (AKS).

As topologias para implantação de várias regiões incluem:

  • Ativo-Ativo: quando você tem aplicativos implantados em vários locais geográficos e requer uma resposta de baixa latência da API para suas implantações. Você tem a opção de implantar a Apigee híbrida em várias localizações geográficas mais próximas de seus clientes. Por exemplo: Costa Oeste dos EUA, Costa Leste dos EUA, Europa, APAC.
  • Ativo-Passivo: quando você tem uma região principal e uma região de recuperação de desastres ou failover.

As regiões em uma implantação híbrida multirregional se comunicam por meio do Cassandra, como mostrado na imagem a seguir:

Pré-requisitos

Antes de configurar o híbridos para várias regiões, é preciso atender aos seguintes pré-requisitos:

  • Siga o guia de instalação híbrida para pré-requisitos como o GCP e a configuração organizacional antes de passar para as etapas de configuração do cluster.

Para informações detalhadas, consulte a documentação do Kubernetes.

Criar uma rede virtual em cada região

Crie uma rede virtual para a implantação de várias regiões. Por exemplo, os comandos de exemplo a seguir criam redes nas regiões Central dos EUA e Leste dos EUA.

Execute este comando para criar uma rede virtual na região Leste dos EUA, com o nome 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

Execute este comando para criar uma rede virtual na região Central dos EUA, com o nome 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

Criar peering de rede

Crie um peering de rede entre as redes virtuais.

Acessar os IDs de rede virtual

Os peerings são estabelecidos entre os IDs de rede virtual. Consiga o ID de cada rede virtual com o comando az network vnet show e armazene o ID em uma variável.

Encontre o ID da primeira rede virtual, chamada my-hybrid-rg-vnet:

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

Consiga o ID da segunda rede virtual, chamada 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)

Criar peering da primeira rede virtual com a segunda

Com os IDs de rede virtual, é possível criar um peering da primeira rede virtual (my-hybrid-rg-vnet) com a segunda (my-hybrid-rg-vnet-ext01), conforme mostrado nos exemplos a seguir:

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

Na saída do comando, observe que peeringState foi Iniciado. O peering permanece no estado Iniciado até que você crie o peering da segunda rede virtual de volta com a primeira.

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

Criar um peering da segunda rede virtual com a primeira

Exemplo de comando:

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

Na saída do comando, observe que peeringState está Conectado. O Azure também altera o estado do peering da primeira com a segunda rede virtual para Conectado.

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

Também é possível confirmar o estado do peering de my-hybrid-rg-vnet1-peering como my-hybrid-rg-vnet2-peering: o peering foi alterado para Conectado com o seguinte 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

Resposta esperada:

Connected

Criar clusters multirregionais

Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR. Veja também o Guia de início rápido do AKS. Use os locais e os nomes das redes virtuais que você criou anteriormente.

Abra as portas 7000 e 7001 do Cassandra entre os clusters do Kubernetes em todas as regiões (7000 pode ser usada como opção de backup durante uma solução de problemas)

Configurar o host de propagação multirregional

Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.

  1. Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação:
    kubectl config use-context original-cluster-name
  2. Execute o comando kubectl a seguir para identificar um endereço do host de propagação do Cassandra na região atual.

    Um endereço de host de propagação permite que uma nova instância regional encontre o cluster original na primeira inicialização para aprender a topologia do cluster. O endereço do host de propagação é designado como o ponto de contato no cluster.

    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. Decida quais dos IPs retornados do comando anterior serão o host de propagação multirregional. Neste exemplo, em que apenas um cluster do Cassandra está sendo executado, o host de propagação é 120.38.1.9.
  4. No data center 2, copie o arquivo de modificações para um novo arquivo com o nome do cluster. Por exemplo, overrides_your_cluster_name.yaml
  5. No data center 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em overrides_your_cluster_name.yaml, em que multiRegionSeedHost é um dos IPs retornados pelo comando anterior:
    cassandra:
      multiRegionSeedHost: seed_host_IP
      datacenter: data_center_name
      rack: rack_name

    Exemplo:

    cassandra:
      multiRegionSeedHost: 120.38.1.9
      datacenter: "centralus"
      rack: "ra-1"
  6. No novo data center/região, antes de instalar a Apigee híbrida, defina os mesmos certificados e credenciais TLS em overrides_your_cluster_name.yaml, conforme definido na primeira região.

Configurar a nova região

Depois de configurar o host de propagação, será possível configurar a nova região.

Para configurar a nova região:

  1. Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
    1. Defina o contexto como o namespace original:
      kubectl config use-context original-cluster-name
    2. Exporte a configuração atual do namespace para um arquivo:
      $ kubectl get namespace  -o yaml > apigee-namespace.yaml
    3. Exporte o secret apigee-ca para um arquivo:
      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
    4. Defina o contexto para o nome do cluster da nova região
      kubectl config use-context new-cluster-name
    5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:
      kubectl apply -f apigee-namespace.yaml
    6. Importe o secret para o novo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml
  2. Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides_your_cluster_name.yaml inclua os mesmos certificados TLS configurados na primeira região, conforme explicado na seção anterior.

    Execute os dois comandos a seguir para instalar a Apigee híbrida na nova região:

    apigeectl init -f overrides_your_cluster_name.yaml
    apigeectl apply -f overrides_your_cluster_name.yaml
  3. Expanda todos os keyspaces da Apigee.

    As etapas a seguir expandem os dados do Cassandra para o novo data center:

    1. Abra um shell no pod do Cassandra:
      kubectl run -i --tty --restart=Never --rm --image google/apigee-hybrid-cassandra-client:1.0.0 cqlsh
    2. Conecte-se ao servidor do 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. Consiga os keyspaces disponíveis:
      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. Atualize/expanda os keyspaces da 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. Valide a expansão dos keyspaces:
      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. Execute nodetool rebuild sequencialmente em todos os nós no novo data center. Isso pode levar de alguns minutos a algumas horas, dependendo do tamanho dos dados.
    kubectl exec apigee-cassandra-0 -n apigee  -- nodetool rebuild -- dc-1
  5. Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status:
    kubectl logs apigee-cassandra-0 -f -n apigee

    O exemplo a seguir mostra entradas de registro de exemplo:

    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. Atualize os hosts de propagação. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e aplique novamente.
    apigeectl apply -f overrides-DC_name.yaml