Implementação em várias regiões

Este tópico descreve uma implementação em várias regiões para o Apigee Hybrid no GKE, o Anthos GKE implementado no local, o RedHat OpenShift e o Microsoft® Azure Kubernetes Service (AKS). Selecione a sua plataforma nos pré-requisitos e procedimentos.

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:

Pré-requisitos

GKE

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
  • Requisitos da Cassandra Multi Region:
    • Certifique-se de que o espaço de nomes da rede de pods tem conetividade nas regiões, incluindo firewalls, VPN, interligação de VPCs e interligação de Vnets. Este é o caso da maioria das instalações do GKE.
    • Se o espaço de nomes da rede de pods não tiver conetividade entre clusters (os clusters estiverem a ser executados no "modo de rede isolada"), ative a funcionalidade hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no ficheiro de substituições para todas as regiões na sua instalação multirregiões do Apigee Hybrid.

      Para obter informações sobre a funcionalidade hostNetwork do Kubernetes, consulte os espaços de nomes de anfitriões na documentação do Kubernetes.

    • Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
    • Quando hostNetwork está ativado, certifique-se de que os nós de trabalho podem realizar uma procura de DNS inverso. O Apigee Cassandra usa a pesquisa de DNS direta e inversa para obter o IP do anfitrião durante o arranque.
    • Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho em todas as regiões e centros de dados comuniquem. Consulte o artigo Configure portas.

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

GKE On-Prem

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
  • Requisitos da Cassandra Multi Region:
    • Se o espaço de nomes da rede de pods não tiver conetividade entre clusters (os clusters estão a ser executados no "modo de rede isolada", o caso predefinido nas instalações do GKE on-prem), ative a funcionalidade hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no ficheiro de substituições para todas as regiões na sua instalação multirregiões híbrida do Apigee.

      Para obter informações sobre a funcionalidade hostNetwork do Kubernetes, consulte os espaços de nomes de anfitriões na documentação do Kubernetes.

    • Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
    • Quando hostNetwork está ativado, certifique-se de que os nós de trabalho podem realizar uma procura de DNS inverso. O Apigee Cassandra usa a pesquisa de DNS direta e inversa para obter o IP do anfitrião durante o arranque.
    • Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho em todas as regiões e centros de dados comuniquem. Consulte o artigo Configure portas.

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

AKS

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

  • Siga o guia de instalação híbridapara ver os pré-requisitos, como a configuração do Google Cloud e da organização , antes de avançar para os passos de configuração do cluster.
  • Requisitos da Cassandra Multi Region:
    • Se o espaço de nomes da rede de pods não tiver conetividade entre clusters (os clusters estão a ser executados no "modo de rede isolada", o caso predefinido nas instalações do AKS), ative a funcionalidade hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no ficheiro de substituições para todas as regiões na instalação multirregiões do Apigee Hybrid.

      Para obter informações sobre a funcionalidade hostNetwork do Kubernetes, consulte os espaços de nomes de anfitriões na documentação do Kubernetes.

    • Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
    • Quando hostNetwork está ativado, certifique-se de que os nós de trabalho podem realizar uma procura de DNS inverso. O Apigee cassandra usa a pesquisa de DNS direta e inversa para obter o IP do anfitrião durante o arranque.
    • Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho em todas as regiões e centros de dados comuniquem. Consulte o artigo Configure portas.

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

EKS

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

  • Siga o guia de instalação híbridapara ver os pré-requisitos, como a configuração do Google Cloud e da organização , antes de avançar para os passos de configuração do cluster.
  • Requisitos da Cassandra Multi Region:
    • Se o espaço de nomes da rede de pods não tiver conetividade entre clusters (os clusters estão a ser executados no "modo de rede isolada", o caso predefinido nas instalações do EKS), ative a funcionalidade hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no ficheiro de substituições para todas as regiões na instalação multirregiões do Apigee Hybrid.

      Para obter informações sobre a funcionalidade hostNetwork do Kubernetes, consulte os espaços de nomes de anfitriões na documentação do Kubernetes.

    • Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
    • Quando hostNetwork está ativado, certifique-se de que os nós de trabalho podem realizar uma procura de DNS inverso. O Apigee cassandra usa a pesquisa de DNS direta e inversa para obter o IP do anfitrião durante o arranque.
    • Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho em todas as regiões e centros de dados comuniquem. Consulte o artigo Configure portas.

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

OpenShift

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

  • Siga o guia de instalação híbridapara ver os pré-requisitos, como a configuração do Google Cloud e da organização , antes de avançar para os passos de configuração do cluster.
  • Requisitos da Cassandra Multi Region:
    • Se o espaço de nomes da rede de pods não tiver conetividade entre clusters (os clusters estão a ser executados no "modo de rede isolada", o caso predefinido nas instalações do OpenShift), ative a funcionalidade hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no ficheiro de substituições para todas as regiões na instalação multirregiões do Apigee Hybrid.

      Para obter informações sobre a funcionalidade hostNetwork do Kubernetes, consulte os espaços de nomes de anfitriões na documentação do Kubernetes.

    • Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
    • Quando hostNetwork está ativado, certifique-se de que os nós de trabalho podem realizar uma procura de DNS inverso. O Apigee cassandra usa a pesquisa de DNS direta e inversa para obter o IP do anfitrião durante o arranque.
    • Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho em todas as regiões e centros de dados comuniquem. Consulte o artigo Configure portas.

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

Configure o Apigee Hybrid para várias regiões

GKE

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. Defina o contexto do kubectl para o cluster original antes de obter o nome da semente: 
    kubectl config use-context original-cluster-name

  2. 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
  3. Decida qual dos IPs devolvidos pelo comando anterior vai ser o anfitrião principal de várias regiões.
  4. 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
  hostNetwork: false

    Por exemplo:

    cassandra:
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: false
  5. No novo centro de dados/região, antes de instalar o híbrido, defina os mesmos certificados TLS e credenciais em overrides_your_cluster_name.yaml como 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 namespace 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_your_cluster_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_your_cluster_name.yaml
     
    apigeectl apply -f overrides_your_cluster_name.yaml
  3. Verifique se a instalação híbrida foi bem-sucedida executando o seguinte comando: 
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Valide a configuração do cluster do Cassandra executando o seguinte comando. O resultado deve mostrar os centros de dados existentes e novos. 
    kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u JMX_user -pw JMX_password status

    Exemplo que mostra uma configuração bem-sucedida: 

    Datacenter: dc-1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b
  5. Configure o Cassandra em todos os pods nos novos centros de dados.
    1. Obtenha o apigeeorg do cluster com o seguinte comando: 
      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name

      Por exemplo: 

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
    2. Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.

      O ficheiro tem de conter o seguinte: 

      apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION

      Onde:

      • REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
      • NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
      • APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
      • SOURCE_REGION é o nome do centro de dados na região de origem. Este é o valor definido para cassandra:datacenter: no seu overrides.yaml.

      Por exemplo: 

      apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
    3. Aplique o CassandraDataReplication com o seguinte comando: 
      kubectl apply -f datareplication.yaml
    4. Valide o estado da reconstrução através do seguinte comando. 
      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Os resultados devem ter um aspeto semelhante ao seguinte: 

      {
  "rebuildDetails": {
    "apigee-cassandra-default-0": {
      "state": "complete",
      "updated": 1623105760
    },
    "apigee-cassandra-default-1": {
      "state": "complete",
      "updated": 1623105765
    },
    "apigee-cassandra-default-2": {
      "state": "complete",
      "updated": 1623105770
    }
  },
  "state": "complete",
  "updated": 1623105770
}
  6. 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
  7. Atualize os anfitriões iniciais. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e volte a aplicá-lo. 
    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: dc-1
=================
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: dc-2
================
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

GKE On-Prem

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. No ficheiro overrides.yaml do cluster original, certifique-se de que cassandra:hostNetwork está definido como true. Por exemplo: 
    cassandra:
  hostNetwork: true
  2. Defina o contexto do kubectl para o cluster original antes de obter o nome da semente: 
    kubectl config use-context original-cluster-name

  3. 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
  4. Decida qual dos IPs devolvidos pelo comando anterior vai ser o anfitrião principal de várias regiões.
  5. 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
  datacenter: data_center_name

    Por exemplo:

    cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  6. No novo centro de dados/região, antes de instalar o híbrido, defina os mesmos certificados TLS e credenciais em overrides_your_cluster_name.yaml como 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 namespace 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_your_cluster_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_your_cluster_name.yaml
     
    apigeectl apply -f overrides_your_cluster_name.yaml
  3. Verifique se a instalação híbrida foi bem-sucedida executando o seguinte comando: 
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Valide a configuração do cluster do Cassandra executando o seguinte comando. O resultado deve mostrar os centros de dados existentes e novos. 
    kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u JMX_user -pw JMX_password status

    Exemplo que mostra uma configuração bem-sucedida: 

    Datacenter: dc-1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b
  5. Configure o Cassandra em todos os pods nos novos centros de dados.
    1. Obtenha o apigeeorg do cluster com o seguinte comando: 
      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name

      Por exemplo: 

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
    2. Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.

      O ficheiro tem de conter o seguinte: 

      apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION

      Onde:

      • REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
      • NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
      • APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
      • SOURCE_REGION é o nome do centro de dados na região de origem. Este é o valor definido para cassandra:datacenter: no seu overrides.yaml.

      Por exemplo: 

      apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
    3. Aplique o CassandraDataReplication com o seguinte comando: 
      kubectl apply -f datareplication.yaml
    4. Valide o estado da reconstrução através do seguinte comando. 
      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Os resultados devem ter um aspeto semelhante ao seguinte: 

      {
  "rebuildDetails": {
    "apigee-cassandra-default-0": {
      "state": "complete",
      "updated": 1623105760
    },
    "apigee-cassandra-default-1": {
      "state": "complete",
      "updated": 1623105765
    },
    "apigee-cassandra-default-2": {
      "state": "complete",
      "updated": 1623105770
    }
  },
  "state": "complete",
  "updated": 1623105770
}
  6. 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
  7. Atualize os anfitriões iniciais. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e volte a aplicá-lo. 
    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: dc-1
=================
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: dc-2
================
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

AKS

Crie uma rede virtual em cada região

Siga as recomendações do Azure para estabelecer comunicação entre regiões aqui: VNet para VNet: Ligar redes virtuais no Azure em diferentes regiões.

Crie clusters multirregionais

Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR. Consulte também o Passo 1: crie um cluster. Use os nomes das localizações e das redes virtuais que criou anteriormente.

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)

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. No ficheiro overrides.yaml do cluster original, certifique-se de que cassandra:hostNetwork está definido como true. Por exemplo: 
    cassandra:
  hostNetwork: true
  2. Defina o contexto do kubectl para o cluster original antes de obter o nome da semente: 
    kubectl config use-context original-cluster-name

  3. 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 | grep apigee-cassandra
     
    apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
  4. Decida qual dos IPs devolvidos pelo comando anterior vai ser o anfitrião principal de várias regiões. Neste exemplo, em que apenas está em execução um cluster cassandra de nó único, o anfitrião de sementes é 120.38.1.9.
  5. No centro de dados 2, copie o ficheiro de substituições para um novo ficheiro cujo nome inclua o nome do cluster. Por exemplo, overrides_your_cluster_name.yaml.
  6. No centro de dados 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em overrides_your_cluster_name.yaml, onde multiRegionSeedHost é um dos IPs devolvidos pelo comando anterior: 
    cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name
     hostNetwork: true

    Por exemplo:

    cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: true
  7. No novo centro de dados/região, antes de instalar o híbrido, defina os mesmos certificados TLS e credenciais em overrides_your_cluster_name.yaml como 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 namespace 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_your_cluster_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_your_cluster_name.yaml
     
    apigeectl apply -f overrides_your_cluster_name.yaml
  3. Verifique se a instalação híbrida foi bem-sucedida executando o seguinte comando: 
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Valide a configuração do cluster do Cassandra executando o seguinte comando. O resultado deve mostrar os centros de dados existentes e novos. 
    kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u JMX_user -pw JMX_password status

    Exemplo que mostra uma configuração bem-sucedida: 

    Datacenter: dc-1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b
  5. Configure o Cassandra em todos os pods nos novos centros de dados.
    1. Obtenha o apigeeorg do cluster com o seguinte comando: 
      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name

      Por exemplo: 

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
    2. Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.

      O ficheiro tem de conter o seguinte: 

      apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION

      Onde:

      • REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
      • NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
      • APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
      • SOURCE_REGION é o nome do centro de dados na região de origem. Este é o valor definido para cassandra:datacenter: no seu overrides.yaml.

      Por exemplo: 

      apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
    3. Aplique o CassandraDataReplication com o seguinte comando: 
      kubectl apply -f datareplication.yaml
    4. Valide o estado da reconstrução através do seguinte comando. 
      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Os resultados devem ter um aspeto semelhante ao seguinte: 

      {
  "rebuildDetails": {
    "apigee-cassandra-default-0": {
      "state": "complete",
      "updated": 1623105760
    },
    "apigee-cassandra-default-1": {
      "state": "complete",
      "updated": 1623105765
    },
    "apigee-cassandra-default-2": {
      "state": "complete",
      "updated": 1623105770
    }
  },
  "state": "complete",
  "updated": 1623105770
}
  6. 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
  7. Atualize os anfitriões iniciais. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e volte a aplicá-lo. 
    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: dc-1
=================
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: dc-2
================
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

OpenShift

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. No ficheiro overrides.yaml do cluster original, certifique-se de que cassandra:hostNetwork está definido como true. Por exemplo: 
    cassandra:
  hostNetwork: true
  2. Defina o contexto do kubectl para o cluster original antes de obter o nome da semente: 
    kubectl config use-context original-cluster-name

  3. 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
  4. Selecione o endereço IP do anfitrião do Cassandra de origem para usar como anfitrião de semente de várias regiões. Neste exemplo, o cluster apigee-cassandra-default-0está em execução e o anfitrião inicial é 10.0.0.11.
  5. No centro de dados 2, copie o ficheiro de substituições para um novo ficheiro cujo nome inclua o nome do cluster. Por exemplo, overrides_your_cluster_name.yaml.
  6. No centro de dados 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em overrides_your_cluster_name.yaml, onde multiRegionSeedHost é um dos IPs devolvidos pelo comando anterior: 
    cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP # Cassandra pod IP address from the source region.
     datacenter: data_center_name

    Por exemplo:

    cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  7. No novo centro de dados/região, antes de instalar o híbrido, defina os mesmos certificados TLS e credenciais em overrides_your_cluster_name.yaml como 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 namespace 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_your_cluster_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_your_cluster_name.yaml
     
    apigeectl apply -f overrides_your_cluster_name.yaml
  3. Verifique se a instalação híbrida foi bem-sucedida executando o seguinte comando: 
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Valide a configuração do cluster do Cassandra executando o seguinte comando. O resultado deve mostrar os centros de dados existentes e novos. 
    kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u JMX_user -pw JMX_password status

    Exemplo que mostra uma configuração bem-sucedida: 

    Datacenter: dc-1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b
  5. Configure o Cassandra em todos os pods nos novos centros de dados.
    1. Obtenha o apigeeorg do cluster com o seguinte comando: 
      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name

      Por exemplo: 

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
    2. Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.

      O ficheiro tem de conter o seguinte: 

      apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION

      Onde:

      • REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
      • NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
      • APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
      • SOURCE_REGION é o nome do centro de dados na região de origem. Este é o valor definido para cassandra:datacenter: no seu overrides.yaml.

      Por exemplo: 

      apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
    3. Aplique o CassandraDataReplication com o seguinte comando: 
      kubectl apply -f datareplication.yaml
    4. Valide o estado da reconstrução através do seguinte comando. 
      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Os resultados devem ter um aspeto semelhante ao seguinte: 

      {
  "rebuildDetails": {
    "apigee-cassandra-default-0": {
      "state": "complete",
      "updated": 1623105760
    },
    "apigee-cassandra-default-1": {
      "state": "complete",
      "updated": 1623105765
    },
    "apigee-cassandra-default-2": {
      "state": "complete",
      "updated": 1623105770
    }
  },
  "state": "complete",
  "updated": 1623105770
}
  6. 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
  7. Atualize os anfitriões iniciais. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e volte a aplicá-lo. 
    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: dc-1
=================
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: dc-2
================
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

Resolução de problemas

Consulte o artigo Falha na replicação de dados do Cassandra.