Implantação multirregional no GKE e no GKE On-Prem

No momento, você está vendo a versão 1.4 da documentação da Apigee Híbrida. Esta versão é o fim da vida útil. Faça upgrade para uma versão mais recente. Para mais informações, consulte Versões compatíveis.

Version 1.4 (unsupported)

   Supported versions:

• v1.12 (latest)                        
• v1.11                         
• v1.10                                        
• List of supported versions

   Unsupported versions:

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

Neste tópico, descrevemos uma implantação multirregional da Apigee híbrida no GKE e no Anthos GKE implantado no local.

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:

Balanceamento de carga da conexão MART

Cada cluster regional precisa ter o próprio IP e nome de host MART. No entanto, você só precisa conectar o plano de gerenciamento a um deles. O Cassandra propaga informações para todos os clusters. A melhor opção para alta disponibilidade do MART é balancear a carga dos endereços IP MART individuais e configurar sua organização para se comunicar com o URL do MART com carga balanceada.

Pré-requisitos

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

• Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR.
• Configurar a comunicação entre regiões
• 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). Consulte também Configurar portas.

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.

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. 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
   
   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. Decida quais dos IPs retornados do comando anterior serão o host de propagação multirregional.

3. A configuração nesta etapa depende se você está no GKE ou no GKE On-Prem:

   Somente GKE: no data center 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em Gerenciar componentes do plano de execução, 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: 10.0.0.11
     datacenter: "dc-2"
     rack: "ra-1"

   Somente GKE On-Prem: no data center 2, configure cassandra.multiRegionSeedHost no seu arquivo de modificações, em que multiRegionSeedHost é um dos IPs retornados pelo comando anterior:

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP
   

   Exemplo:

   cassandra:
     hostNetwork: true
     dnsPolicy: ClusterFirstWithHostNet
     multiRegionSeedHost: 10.0.0.11
   

4. No novo data center/região, antes de instalar a Apigee híbrida, defina os mesmos certificados e credenciais TLS em overrides.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 em overrides.yaml no primeiro data center precisam corresponder àquelas especificadas em overrides.yaml 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 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-DC_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/overrides-DC_name.yaml

   apigeectl apply -f overrides/overrides-DC_name.yaml

3. Execute nodetool rebuild em sequência em todos os pods no novo data center. Isso pode levar de alguns minutos a algumas horas, dependendo do tamanho dos dados.

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1

   Em que JMX_user e JMX_password são o nome de usuário e a senha do usuário do Cassandra JMX.

4. 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-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

   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

5. 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/overrides-DC_name.yaml

Verificar o status do cluster do Cassandra

O comando a seguir é útil para ver se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das duas regiões.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password 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