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

Você está visualizando a versão 1.1 da documentação da Apigee híbrida. This version is end of life. You should upgrade to a newer version. Para mais informações, consulte Versões compatíveis.

Version 1.1 (unsupported)

Versões com suporte:

• v1.13 (mais recente)                        
• v1.12                         
• v1.11
• Lista de versões com suporte

Versões sem suporte:

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

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.

OBSERVAÇÃO: a Apigee recomenda que você verifique se os horários dos seus servidores estão sincronizados.

Vários recursos, como expiração e revogação de token, dependem dos horários precisos do sistema. Se você hospedar os componentes de ambiente de execução em diferentes data centers, verifique se os horários do sistema estão sincronizados.

Use uma ferramenta como ntpdate para verificar se os horários dos servidores estão sincronizados.

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.

OBSERVAÇÃO: as etapas nesta seção são fornecidas apenas como exemplos. Adapte-as conforme necessário para atender às suas necessidades.

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.

OBSERVAÇÃO: as etapas nesta seção são fornecidas apenas como exemplos. Adapte-as conforme necessário para atender às suas necessidades.

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:

Se você não especificar o parâmetro --allow-vnet-access, um peering será estabelecido, mas nenhuma comunicação poderá passar por ele.

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.
   OBSERVAÇÃO: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

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

      OBSERVAÇÃO: se você não vir um prompt de comando, tente pressionar a tecla ENTER.
   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.
   Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.

   apigeectl apply -f overrides-DC_name.yaml