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

Este tópico descreve uma implementação multirregional para o Apigee Hybrid no GKE e o Anthos GKE implementado no local.

As topologias para a implementação multirregional incluem o seguinte:

  • Ativo-ativo: quando tem aplicações implementadas em várias localizações geográficas e precisa de uma resposta da API com baixa latência para as suas implementações. Tem a opção de implementar a solução híbrida em várias localizações geográficas mais próximas dos seus clientes. Por exemplo: Costa Oeste dos EUA, Costa Leste dos EUA, Europa, APAC.
  • Ativo-passivo: quando tem uma região principal e uma região de recuperação de desastres ou de comutação por falha.

As regiões numa implementação híbrida de várias regiões comunicam através do Cassandra, conforme mostra a imagem seguinte:

Balanceamento de carga da ligação MART

Cada cluster regional tem de ter o seu próprio IP e nome de anfitrião MART. No entanto, só precisa de associar o plano de gestão a um deles. O Cassandra propaga informações a todos os clusters. A melhor opção para a elevada disponibilidade do MART é o equilíbrio de carga dos endereços IP individuais do MART e configurar a sua organização para comunicar com o URL do MART com equilíbrio de carga.

Pré-requisitos

Antes de configurar o modo híbrido para várias regiões, tem de concluir os seguintes pré-requisitos:

  • Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR
  • Configure a comunicação entre regiões
  • Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões (7000 pode ser usado como uma opção de cópia de segurança durante a resolução de problemas). Consulte também o artigo Configurar portas.

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

Configure o anfitrião de origem multirregião

Esta secção descreve como expandir o cluster do Cassandra existente para uma nova região. Esta configuração permite que a nova região inicialize o cluster e se junte ao centro de dados existente. Sem esta configuração, os clusters Kubernetes multirregionais não se reconheceriam.

  1. Execute o seguinte comando kubectl para identificar um endereço de anfitrião inicial para o Cassandra na região atual.

    Um endereço de anfitrião inicial permite que uma nova instância regional encontre o cluster original no primeiro arranque para saber a topologia do cluster. O endereço do anfitrião inicial é designado como o ponto de contacto 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 qual dos IPs devolvidos pelo comando anterior vai ser o anfitrião principal de várias regiões.
  3. A configuração neste passo depende de estar a usar o GKE ou o GKE On-Prem:

    Apenas GKE: no centro de dados 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em Gerir componentes do plano de tempo de execução, onde multiRegionSeedHost é um dos IPs devolvidos pelo comando anterior:

    cassandra:
      multiRegionSeedHost: seed_host_IP
      datacenter: data_center_name
      rack: rack_name

    Por exemplo:

    cassandra:
      multiRegionSeedHost: 10.0.0.11
      datacenter: "dc-2"
      rack: "ra-1"

    Apenas para o GKE on-prem: no centro de dados 2, configure cassandra.multiRegionSeedHost no ficheiro de substituições, em que multiRegionSeedHost é um dos IPs devolvidos pelo comando anterior:

    cassandra:
      hostNetwork: true
      multiRegionSeedHost: seed_host_IP
    

    Por exemplo:

    cassandra:
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      multiRegionSeedHost: 10.0.0.11
    
  4. No novo centro de dados/região, antes de instalar o híbrido, defina os mesmos certificados TLS e credenciais em overrides.yaml que definiu na primeira região.

Configure a nova região

Depois de configurar o anfitrião inicial, pode configurar a nova região.

Para configurar a nova região:

  1. Copie o certificado do cluster existente para o novo cluster. A nova raiz da AC é usada pelo Cassandra e outros componentes híbridos para mTLS. Por conseguinte, é essencial ter certificados consistentes no cluster.
    1. Defina o contexto para o espaço de nomes original:
      kubectl config use-context original-cluster-name
    2. Exporte a configuração do espaço de nomes atual para um ficheiro:
      $ kubectl get namespace namespace -o yaml > apigee-namespace.yaml
    3. Exporte o segredo apigee-ca para um ficheiro:
      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 espaço de nomes para o novo cluster. Certifique-se de que atualiza o "namespace" no ficheiro se estiver a usar um espaço de nomes diferente na nova região:
      kubectl apply -f apigee-namespace.yaml
    6. Importe o segredo para o novo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml
  2. Instale o híbrido na nova região. Certifique-se de que o ficheiro overrides-DC_name.yaml inclui os mesmos certificados TLS que estão configurados na primeira região, conforme explicado na secção anterior.

    Execute os dois comandos seguintes para instalar o híbrido na nova região:

    apigeectl init -f overrides/overrides-DC_name.yaml
    apigeectl apply -f overrides/overrides-DC_name.yaml
  3. Executar nodetool rebuild sequencialmente em todos os pods no novo centro de dados. Este processo pode demorar alguns minutos a algumas horas, consoante o tamanho dos dados.
    kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1

    Onde JMX_user e JMX_password são o nome de utilizador e a palavra-passe do utilizador do JMX do Cassandra.

  4. Valide os processos de reconstrução a partir dos registos. Além disso, valide o tamanho dos dados com 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 seguinte mostra entradas de registo 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 anfitriões iniciais. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e volte a aplicar.
    apigeectl apply -f overrides/overrides-DC_name.yaml

Verifique o estado do cluster do Cassandra

O comando seguinte é útil para ver se a configuração do cluster foi bem-sucedida em dois centros de dados. O comando verifica o estado do nodetool para as 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