Implantação multirregional

Neste tópico, descrevemos uma implantação multirregional para Apigee híbrida no GKE, o Anthos GKE implantado no local, Microsoft® Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) e no RedHat OpenShift. Selecione sua plataforma nos pré-requisitos e procedimentos.

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:

Arquitetura de implantação híbrida multirregional da Apigee

Pré-requisitos

Antes de configurar a implantação híbrida para várias regiões, é preciso atender aos seguintes pré-requisitos:

GKE

  • Ao instalar implantações multirregionais da Apigee entre diferentes redes, por exemplo, provedores de nuvem, redes VPC diferentes, na nuvem e no local etc., é preciso fornecer conectividade interna entre essas redes separadas que o Cassandra pode usar para a comunicação entre nós. Isso pode ser feito com VPNs ou soluções de conectividade específicas da nuvem.
  • Se você estiver usando a Identidade da carga de trabalho em um cluster para autenticar contas de serviço, cada cluster para o qual expandir também precisará usar a Identidade da carga de trabalho. Consulte como ativar a Identidade da carga de trabalho com a Apigee híbrida.
  • Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR.
  • Verifique se cert-manager está instalado em cada cluster
  • Configurar a comunicação entre regiões
  • Verifique se todos os pods do Cassandra conseguem resolver seus próprios nomes de host. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do host do nó do Kubernetes executando o pod do Cassandra.
  • Requisitos da multirregião Cassandra:
    • Verifique se o namespace da rede do pod tem conectividade entre as regiões, incluindo firewalls, vpn, peering vpc e vNet. Esse é o caso da maioria das instalações do GKE.
    • Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters estão sendo executados no "modo de rede ilha"), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.

      Para mais informações sobre a necessidade de hostNetwork, consulte Clusters no modo de ilha e hostNetwork abaixo.

    • Ative hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
    • Quando hostNetwork estiver ativado, verifique se os nós de trabalho podem realizar buscas DNS de nomes do host. O Cassandra da Apigee usa a busca DNS direta para obter o IP do host durante a inicialização.
    • Abra a porta TCP 7001 entre os clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho em regiões e data centers se comuniquem. Consulte Configurar portas para informações sobre os números de portas do Cassandra.

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

GKE On-Prem

  • Ao instalar implantações multirregionais da Apigee entre diferentes redes, por exemplo, provedores de nuvem, redes VPC diferentes, na nuvem e no local etc., é preciso fornecer conectividade interna entre essas redes separadas que o Cassandra pode usar para a comunicação entre nós. Isso pode ser feito com VPNs ou soluções de conectividade específicas da nuvem.
  • Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR.
  • Verifique se cert-manager está instalado em cada cluster
  • Configurar a comunicação entre regiões
  • Verifique se todos os pods do Cassandra conseguem resolver seus próprios nomes de host. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do host do nó do Kubernetes executando o pod do Cassandra.
  • Requisitos da multirregião Cassandra:
    • Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters estão sendo executados no "modo de rede ilha", o caso padrão nas instalações do GKE On-Prem), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.

      Para mais informações sobre a necessidade de hostNetwork, consulte Clusters no modo de ilha e hostNetwork abaixo.

    • Ative hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
    • Quando hostNetwork estiver ativado, verifique se os nós de trabalho conseguem realizar buscas DNS de nomes do host. O Cassandra da Apigee usa a busca DNS direta para obter o IP do host durante a inicialização.
    • Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.

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

AKS

  • Ao instalar implantações multirregionais da Apigee entre diferentes redes, por exemplo, provedores de nuvem, redes VPC diferentes, na nuvem e no local etc., é preciso fornecer conectividade interna entre essas redes separadas que o Cassandra pode usar para a comunicação entre nós. Isso pode ser feito com VPNs ou soluções de conectividade específicas da nuvem.
  • Siga o guia de instalação híbrida para pré-requisitos como o Google Cloud e a configuração organizacional antes de passar para as etapas de configuração do cluster.
  • Verifique se o cert-manager está instalado em cada cluster
  • Verifique se todos os pods do Cassandra conseguem resolver seus próprios nomes de host. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do host do nó do Kubernetes que executa o pod do Cassandra.
  • Requisitos da multirregião Cassandra:
    • Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters estão sendo executados no "modo de rede ilha", o caso padrão em instalações AKS), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.

      Para mais informações sobre a necessidade de hostNetwork, consulte Clusters no modo de ilha e hostNetwork abaixo.

    • Ative hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
    • Quando hostNetwork estiver ativado, verifique se os nós de trabalho podem realizar buscas DNS de nomes do host. O Cassandra da Apigee usa a busca DNS direta para obter o IP do host durante a inicialização.
    • Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.

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

EKS

  • Ao instalar implantações multirregionais da Apigee entre diferentes redes, por exemplo, provedores de nuvem, redes VPC diferentes, na nuvem e no local etc., é preciso fornecer conectividade interna entre essas redes separadas que o Cassandra pode usar para a comunicação entre nós. Isso pode ser feito com VPNs ou soluções de conectividade específicas da nuvem.
  • Siga o guia de instalação híbrida para pré-requisitos como o Google Cloud e a configuração organizacional antes de passar para as etapas de configuração do cluster.
  • Verifique se o cert-manager está instalado em cada cluster
  • Verifique se todos os pods do Cassandra conseguem resolver seus próprios nomes de host. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do host do nó do Kubernetes que executa o pod do Cassandra.
  • Requisitos da multirregião Cassandra:
    • Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters estão sendo executados no "modo de rede ilha"), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee. O Amazon EKS usa o modelo de rede totalmente integrado por padrão.

      Para mais informações sobre a necessidade de hostNetwork, consulte Clusters no modo de ilha e hostNetwork abaixo.

    • Ative hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
    • Quando hostNetwork estiver ativado, verifique se os nós de trabalho podem realizar buscas DNS de nomes do host. O Cassandra da Apigee usa a busca DNS direta para obter o IP do host durante a inicialização.
    • Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.

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

OpenShift

  • Ao instalar implantações multirregionais da Apigee entre diferentes redes, por exemplo, provedores de nuvem, redes VPC diferentes, na nuvem e no local etc., é preciso fornecer conectividade interna entre essas redes separadas que o Cassandra pode usar para a comunicação entre nós. Isso pode ser feito com VPNs ou soluções de conectividade específicas da nuvem.
  • Siga o guia de instalação híbrida para pré-requisitos como o Google Cloud e a configuração organizacional antes de passar para as etapas de configuração do cluster.
  • Verifique se o cert-manager está instalado em cada cluster
  • Verifique se todos os pods do Cassandra conseguem resolver seus próprios nomes de host. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do host do nó do Kubernetes que executa o pod do Cassandra.
  • Requisitos da multirregião Cassandra:
    • Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters estão sendo executados no "modo de rede de ilha", o caso padrão nas instalações do OpenShift), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.

      Para mais informações sobre a necessidade de hostNetwork, consulte Clusters no modo de ilha e hostNetwork abaixo.

    • Ative hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
    • Quando hostNetwork estiver ativado, verifique se os nós de trabalho podem realizar buscas DNS de nomes do host. O Cassandra da Apigee usa a busca DNS direta para obter o IP do host durante a inicialização.
    • Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.

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

Clusters no modo de ilha e hostNetwork

Há dois modelos de rede principais para clusters do Kubernetes: totalmente integrado (ou simples) e no modo de ilha. A Apigee recomenda o uso do modelo de rede simples sempre que possível, porque ele simplifica a conectividade multirregional do Cassandra. Quando um cluster do Kubernetes é configurado no modo de ilha, a rede do pod fica isolada. Os pods não conseguem se comunicar diretamente com outros em execução em outros clusters usando o endereço IP deles. Consulte Implementações típicas de modelos de rede para mais informações sobre as diferenças entre esses dois modelos de rede e exemplos de cada um.

Quando a Apigee híbrida está em execução em dois ou mais clusters do Kubernetes usando um modelo de rede de modo de ilha, é necessário ativar a configuração hostNetwork para o Cassandra por meio da propriedade cassandra.hostNetwork. Por padrão, os pods do Kubernetes são isolados em namespaces de rede individuais, o que os impede de usar o IP do nó de trabalho do Kubernetes. Quando hostNetwork é definido como true, o pod não é isolado no próprio namespace de rede. Em vez disso, ele usa o endereço IP e o nome de host do nó de trabalho do Kubernetes em que ele está programado. Isso permite que o Cassandra use nativamente o IP do nó de trabalho do Kubernetes como o próprio IP, o que fornece a ele um meio para estabelecer uma malha completa entre todos os pods dele que estão em vários clusters em execução no modo de ilha.

Resolução do nome de host do Cassandra

Um pod do Cassandra não resolve outros pods do Cassandra por nome de host. No entanto, durante a inicialização, o Cassandra verifica se o próprio nome de host pode ser resolvido por DNS. Como o nome de host do pod é igual ao nome de host do nó de trabalho do Kubernetes quando hostNetwork é definido como verdadeiro, o nome de host do nó de trabalho precisa ser resolvido para um endereço IP por meio do serviço DNS do cluster. Se o nome de host do nó de trabalho do Kubernetes não puder ser resolvido, o pod do Cassandra não será totalmente iniciado. Portanto, é importante que os nomes de host dos nós de trabalho do Kubernetes possam ser resolvidos por meio de pods no cluster ao definir hostNetwork como true.

Configurar o híbrido da Apigee para multirregião

Nesta seção, descrevemos como configurar a Apigee híbrida para várias regiões.

GKE

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 -l app=apigee-cassandra --field-selector status.phase=Running
    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 quais dos IPs retornados do comando anterior serão o host de propagação multirregional.
  4. 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
      hostNetwork: false
      clusterName: cluster_name # must be the same for all regions

    Exemplo:

    cassandra:
      multiRegionSeedHost: 10.0.0.11
      datacenter: "dc-2"
      rack: "ra-1"
      hostNetwork: false
      clusterName: my-apigee-cluster
  5. 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.

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. Para verificar se a instalação híbrida foi bem-sucedida, execute o seguinte comando:
    apigeectl check-ready -f overrides_DC_name.yaml
  4. Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos e atuais.
    kubectl exec apigee-cassandra-default-0 -n apigee  \
      -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

    Exemplo de configuração concluída:

    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. Configurar o Cassandra em todos os pods nos novos data centers.
    1. Receba apigeeorg do cluster com o seguinte comando:
      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Exemplo:

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

      O arquivo deve 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

      Em que:

      • REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
      • NAMESPACE é o mesmo namespace fornecido em overrides.yaml. Geralmente é "apigee".
      • APIGEEORG_VALUE é a saída de valor do comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" na etapa anterior. Por exemplo, rg-hybrid-b7d3b9c
      • SOURCE_REGION é a região de origem, o valor do data center na seção Cassandra das modificações da região de origem.yaml

      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. Verifique o status de recriação usando o comando a seguir.
      kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

      Os resultados terão esta aparência:

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

Verificar o status do cluster do Cassandra

O comando a seguir é útil para conferir 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 APIGEE_JMX_USER -pw APIGEE_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: 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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

GKE On-Prem

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. No arquivo overrides.yaml do cluster original, verifique se cassandra:hostNetwork está definido como true. Por exemplo:
    cassandra:
      hostNetwork: true

    Consulte Pré-requisitos para mais informações sobre quando definir hostNetwork: true.

  2. Se cassandra:hostNetwork não estiver definido como true, faça o seguinte:
    1. Altere cassandra.hostNetwork para true.
    2. Aplique o arquivo de configuração overrides.yaml com o comando:
        apigeectl apply -f overrides.yaml --datastore
        
    3. Aguarde até que os pods do Cassandra concluam uma reinicialização.
    4. Verifique se o cluster do Cassandra está íntegro com os comandos a seguir:

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        
        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
        

      Verifique se todos os nós do Cassandra na saída estão em status UN (para cima/normal):

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
        

      Confira se não há nós inacessíveis listados na saída.

  3. Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação:
    kubectl config use-context original-cluster-name
  4. 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 -l app=apigee-cassandra --field-selector status.phase=Running
    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
  5. Decida quais dos IPs retornados do comando anterior serão o host de propagação multirregional.
  6. No data center 2, configure cassandra.multiRegionSeedHost no arquivo de substituições, em que multiRegionSeedHost é um dos IPs retornados pelo comando anterior:
    cassandra:
      hostNetwork: true
      multiRegionSeedHost: seed_host_IP
      datacenter: data_center_name
      rack: rack_name
        clusterName: cluster_name # must be the same for all regions
    

    Exemplo:

    cassandra:
      hostNetwork: true
      multiRegionSeedHost: 10.0.0.11
      datacenter: "dc-2"
      rack: "ra-1"
      clusterName: my-apigee-cluster
    
  7. 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.

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. Para verificar se a instalação híbrida foi bem-sucedida, execute o seguinte comando:
    apigeectl check-ready -f overrides_DC_name.yaml
  4. Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos e atuais.
    kubectl exec apigee-cassandra-default-0 -n apigee  \
      -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

    Exemplo de configuração concluída:

    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. Configurar o Cassandra em todos os pods nos novos data centers.
    1. Receba apigeeorg do cluster com o seguinte comando:
      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Exemplo:

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

      O arquivo deve 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

      Em que:

      • REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
      • NAMESPACE é o mesmo namespace fornecido em overrides.yaml. Geralmente é "apigee".
      • APIGEEORG_VALUE é a saída de valor do comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" na etapa anterior. Por exemplo, rg-hybrid-b7d3b9c
      • SOURCE_REGION é a região de origem, o valor do data center na seção Cassandra das modificações da região de origem.yaml

      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. Verifique o status de recriação usando o comando a seguir.
      kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

      Os resultados terão esta aparência:

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

Verificar o status do cluster do Cassandra

O comando a seguir é útil para conferir 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 APIGEE_JMX_USER -pw APIGEE_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: 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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

AKS

Criar uma rede virtual em cada região

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

Criar clusters multirregionais

Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR. Consulte também a Etapa 1: criar um cluster. Use os locais e os nomes das redes virtuais que você criou anteriormente.

Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.

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. No arquivo overrides.yaml do cluster original, verifique se cassandra:hostNetwork está definido como true. Por exemplo:
    cassandra:
      hostNetwork: true

    Consulte Pré-requisitos para mais informações sobre quando definir hostNetwork: true.

  2. Se cassandra:hostNetwork não estiver definido como true, faça o seguinte:
    1. Altere cassandra.hostNetwork para true.
    2. Aplique o arquivo de configuração overrides.yaml com o comando:
        apigeectl apply -f overrides.yaml --datastore
        
    3. Aguarde até que os pods do Cassandra concluam uma reinicialização.
    4. Verifique se o cluster do Cassandra está íntegro com os comandos a seguir:

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        
        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
        

      Verifique se todos os nós do Cassandra na saída estão em status UN (para cima/normal):

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
        

      Confira se não há nós inacessíveis listados na saída.

  3. Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação:
    kubectl config use-context original-cluster-name
  4. 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 -l app=apigee-cassandra --field-selector status.phase=Running
    apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
    
  5. 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.
  6. 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
  7. 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
         hostNetwork: true
         clusterName: cluster_name # must be the same for all regions

    Exemplo:

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

Configurar a nova região

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

Para configurar a nova região:

  1. Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
    1. Defina o contexto como o namespace original:
      kubectl config use-context original-cluster-name
    2. Exporte a configuração atual do namespace para um arquivo:
      kubectl get namespace 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. Para verificar se a instalação híbrida foi bem-sucedida, execute o seguinte comando:
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos e atuais.
    kubectl exec apigee-cassandra-default-0 -n apigee  \
      -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

    Exemplo de configuração concluída:

    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. Configurar o Cassandra em todos os pods nos novos data centers.
    1. Receba apigeeorg do cluster com o seguinte comando:
      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Exemplo:

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

      O arquivo deve 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

      Em que:

      • REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
      • NAMESPACE é o mesmo namespace fornecido em overrides.yaml. Geralmente é "apigee".
      • APIGEEORG_VALUE é a saída de valor do comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" na etapa anterior. Por exemplo, rg-hybrid-b7d3b9c
      • SOURCE_REGION é a região de origem, o valor do data center na seção Cassandra das modificações da região de origem.yaml

      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. Verifique o status de recriação usando o comando a seguir.
      kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

      Os resultados terão esta aparência:

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

Verificar o status do cluster do Cassandra

O comando a seguir é útil para conferir 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 APIGEE_JMX_USER -pw APIGEE_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: 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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

EKS

Criar uma rede virtual em cada região

Siga as recomendações da AWS para estabelecer comunicação entre regiões, conforme descrito em: O que é peering de VPC?. O termo da AWS para usar regiões diferentes é peering de VPC entre regiões.

Criar clusters multirregionais

Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR. Consulte também a Etapa 1: criar um cluster. Use os locais e os nomes das redes virtuais que você criou anteriormente.

Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.

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. No arquivo overrides.yaml do cluster original, verifique se cassandra:hostNetwork está definido como true. Por exemplo:
    cassandra:
      hostNetwork: true

    Consulte Pré-requisitos para mais informações sobre quando definir hostNetwork: true.

  2. Se cassandra:hostNetwork não estiver definido como true, faça o seguinte:
    1. Altere cassandra.hostNetwork para true.
    2. Aplique o arquivo de configuração overrides.yaml com o comando:
        apigeectl apply -f overrides.yaml --datastore
        
    3. Aguarde até que os pods do Cassandra concluam uma reinicialização.
    4. Verifique se o cluster do Cassandra está íntegro com os comandos a seguir:

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        
        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
        

      Verifique se todos os nós do Cassandra na saída estão em status UN (para cima/normal):

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD describecluster
        

      Confira se não há nós inacessíveis listados na saída.

  3. Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação:
    kubectl config use-context original-cluster-name
  4. 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-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
    
  5. 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.
  6. 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
  7. 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
         hostNetwork: true
         clusterName: cluster_name # must be the same for all regions

    Exemplo:

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

Configurar a nova região

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

Para configurar a nova região:

  1. Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
    1. Defina o contexto como o namespace original:
      kubectl config use-context original-cluster-name
    2. Exporte a configuração atual do namespace para um arquivo:
      kubectl get namespace 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. Para verificar se a instalação híbrida foi bem-sucedida, execute o seguinte comando:
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos e atuais.
    kubectl exec apigee-cassandra-default-0 -n apigee  \
      -- nodetool -u JMX_user -pw JMX_password status

    Exemplo de configuração concluída:

    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. Configurar o Cassandra em todos os pods nos novos data centers.
    1. Receba apigeeorg do cluster com o seguinte comando:
      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      

      Exemplo:

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

      O arquivo deve 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

      Em que:

      • REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
      • NAMESPACE é o mesmo namespace fornecido em overrides.yaml. Geralmente é "apigee".
      • APIGEEORG_VALUE é a saída de valor do comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name na etapa anterior. Por exemplo, rg-hybrid-b7d3b9c
      • SOURCE_REGION é a região de origem, o valor do data center na seção Cassandra das modificações da região de origem.yaml

      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. Verifique o status de recriação usando o comando a seguir.
      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Os resultados terão esta aparência:

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

Verificar o status do cluster do Cassandra

O comando a seguir é útil para conferir 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: 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: 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

OpenShift

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. No arquivo overrides.yaml do cluster original, verifique se cassandra:hostNetwork está definido como true. Por exemplo:
    cassandra:
      hostNetwork: true

    Consulte Pré-requisitos para mais informações sobre quando definir hostNetwork: true.

  2. Se cassandra:hostNetwork não estiver definido como true, faça o seguinte:
    1. Altere cassandra.hostNetwork para true.
    2. Aplique o arquivo de configuração overrides.yaml com o comando:
        apigeectl apply -f overrides.yaml --datastore
        
    3. Aguarde até que os pods do Cassandra concluam uma reinicialização.
    4. Verifique se o cluster do Cassandra está íntegro com os comandos a seguir:

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        
        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
        

      Verifique se todos os nós do Cassandra na saída estão em status UN (para cima/normal):

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
        

      Confira se não há nós inacessíveis listados na saída.

  3. Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação:
    kubectl config use-context original-cluster-name
  4. 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 -l app=apigee-cassandra --field-selector status.phase=Running
    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
  5. Selecione o endereço IP do host de origem do Cassandra para ser usado como host de origem multirregional. Neste exemplo, este é o apigee-cassandra-default-0cluster em execução, o host de origem é 10.0.0.11.
  6. 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
  7. 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:
         hostNetwork: true
         multiRegionSeedHost: seed_host_IP # Cassandra pod IP address from the source region.
         datacenter: data_center_name
         rack: rack_name
         clusterName: cluster_name # must be the same for all regions

    Exemplo:

    cassandra:
      hostNetwork: true
      multiRegionSeedHost: 10.0.0.11
      datacenter: "dc-2"
      rack: "ra-1"
      clusterName: my-apigee-cluster
  8. No novo data center/região, antes de instalar a Apigee híbrida, defina os mesmos certificados e credenciais TLS em overrides_your_cluster_name.yaml, conforme definido na primeira região.

Configurar a nova região

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

Para configurar a nova região:

  1. Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
    1. Defina o contexto como o namespace original:
      kubectl config use-context original-cluster-name
    2. Exporte a configuração atual do namespace para um arquivo:
      kubectl get namespace 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. Para verificar se a instalação híbrida foi bem-sucedida, execute o seguinte comando:
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos e atuais.
    kubectl exec apigee-cassandra-default-0 -n apigee  \
      -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

    Exemplo de configuração concluída:

    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. Configurar o Cassandra em todos os pods nos novos data centers.
    1. Receba apigeeorg do cluster com o seguinte comando:
      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Exemplo:

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

      O arquivo deve 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

      Em que:

      • REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
      • NAMESPACE é o mesmo namespace fornecido em overrides.yaml. Geralmente é "apigee".
      • APIGEEORG_VALUE é a saída de valor do comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" na etapa anterior. Por exemplo, rg-hybrid-b7d3b9c
      • SOURCE_REGION é a região de origem, o valor do data center na seção Cassandra das modificações da região de origem.yaml

      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. Verifique o status de recriação usando o comando a seguir.
      kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

      Os resultados terão esta aparência:

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

Verificar o status do cluster do Cassandra

O comando a seguir é útil para conferir 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 APIGEE_JMX_USER -pw APIGEE_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: 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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

Solução de problemas

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