Implantação multirregional

Version 1.12 

Versões com suporte:

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

Versões sem suporte:

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

Neste tópico, 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:

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, , recomendamos o uso dela para cada cluster em que você expandir. Consulte Como ativar a Identidade da carga de trabalho no GKE ou Como ativar a federação de identidade da carga de trabalho no AKS e EKS.
• Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR.
• Verifique se o 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 false, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como true, o nome do host será o nome do host do nó do Kubernetes executando o pod do Cassandra.
  Dica: para verificar se a resolução de nome do host está funcionando, use estes comandos.
  
  Se hostNetwork estiver definido como false, use o Comando 1. Se hostNetwork estiver definido como true, use o Comando 2.
  
  Se a resolução de nome do host estiver funcionando, a saída mostrará um endereço IP. Se a resolução do nome do host falhar, a saída incluirá "Host não encontrado".
  
  Comando 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Comando 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• 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.
    Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.

    Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho cassandra semelhante ao seguinte:

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    ou

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • 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.

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

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

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

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 o 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 false, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como true, o nome do host será o nome do host do nó do Kubernetes executando o pod do Cassandra.
  Dica: para verificar se a resolução de nome do host está funcionando, use estes comandos.
  
  Se hostNetwork estiver definido como false, use o Comando 1. Se hostNetwork estiver definido como true, use o Comando 2.
  
  Se a resolução de nome do host estiver funcionando, a saída mostrará um endereço IP. Se a resolução do nome do host falhar, a saída incluirá "Host não encontrado".
  
  Comando 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Comando 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• 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.
    Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.

    Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho cassandra semelhante ao seguinte:

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    ou

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • 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.

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

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

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

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 false, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como true, o nome do host será o nome do host do nó do Kubernetes que executa o pod do Cassandra.
  Dica: para verificar se a resolução de nome do host está funcionando, use estes comandos.
  
  Se hostNetwork estiver definido como false, use o Comando 1. Se hostNetwork estiver definido como true, use o Comando 2.
  
  Se a resolução de nome do host estiver funcionando, a saída mostrará um endereço IP. Se a resolução de nome do host falhar, a saída incluirá "Host não encontrado".
  
  Comando 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Comando 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• 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.
    Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.

    Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho cassandra semelhante ao seguinte:

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    ou

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • 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.

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

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

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

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 false, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como true, o nome do host será o nome do host do nó do Kubernetes que executa o pod do Cassandra.
  Dica: para verificar se a resolução de nome do host está funcionando, use estes comandos.
  
  Se hostNetwork estiver definido como false, use o Comando 1. Se hostNetwork estiver definido como true, use o Comando 2.
  
  Se a resolução de nome do host estiver funcionando, a saída mostrará um endereço IP. Se a resolução de nome do host falhar, a saída incluirá "Host não encontrado".
  
  Comando 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Comando 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• 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.
    Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.

    Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho cassandra semelhante ao seguinte:

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    ou

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • 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.

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

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

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

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 false, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como true, o nome do host será o nome do host do nó do Kubernetes que executa o pod do Cassandra.
  Dica: para verificar se a resolução de nome do host está funcionando, use estes comandos.
  
  Se hostNetwork estiver definido como false, use o Comando 1. Se hostNetwork estiver definido como true, use o Comando 2.
  
  Se a resolução de nome do host estiver funcionando, a saída mostrará um endereço IP. Se a resolução de nome do host falhar, a saída incluirá "Host não encontrado".
  
  Comando 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Comando 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• 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.
    Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.

    Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho cassandra semelhante ao seguinte:

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    ou

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • 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.

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

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

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

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

Importante: ao expandir o Apigee híbrido para um novo data center regional, instale a mesma versão do data center existente. Evite executar versões diferentes de implementações híbridas em diversos data centers.

Aviso: se a instalação de uma nova região falhar, não continue a instalação. Em vez disso, exclua e recrie a instalação híbrida na região com falha.

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. Para a primeira região criada, acesse os pods no namespace da Apigee:

   kubectl get pods -o wide -n apigee
   

2. Identifique o endereço do host de semente multirregional para Cassandra nesta região, por exemplo, 10.0.0.11.

3. Prepare o arquivo overrides.yaml para a segunda região e adicione o endereço IP do host de semente da seguinte maneira:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Substitua:

   • SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo, 10.0.0.11.
   • DATACENTER_NAME pelo nome do data center. Por exemplo, dc-2.
   • RACK_NAME pelo nome do rack, por exemplo, ra-1.
   • CLUSTER_NAME pelo nome do cluster da Cassandra. Por padrão, o valor é apigeecluster. Se você usar um nome de cluster diferente, será preciso especificar um valor para cassandra.clusterName. É possível escolher o próprio valor, mas ele precisa ser o mesmo em todas as regiões.

Configurar a segunda região

Para configurar a nova região:

1. Instale o cert-manager na segunda região.

2. 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 apigee -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. Atualize o namespace no arquivo se 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
      

3. Siga as etapas para instalar os CRDs da Apigee híbrida na nova região.

4. Agora use gráficos do Helm para instalar a Apigee híbrida na nova região com os seguintes comandos do gráfico do Helm (como feito na região 1):

   Observação: é possível usar as mesmas CRDs para manter a consistência utilizando a mesma pasta em que você fez o download dos gráficos. Também é possível manter o arquivo de modificações exclusivo entre região 1 e 2 ao nomear algo exclusivo, como overrides-region_name.yaml.
   Importante: omita ‑‑atomic sinalização para clusters migrados.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos.
   Aviso: se a saída desse comando não mostrar os data centers novos e atuais, a configuração falhou. Nesse caso, não prossiga.

   Para corrigir o problema, a instalação híbrida na nova região precisa ser excluída e recriada. Consulte Desinstalar o ambiente de execução híbrido. Se a configuração falhar, não tente prosseguir ou mesclar o cluster.

   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

6. 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

7. Verifique o status de recriação usando o comando a seguir.
   Observação : a operação de recriação pode levar várias horas, dependendo do tamanho dos dados.

   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
   }

8. Depois que a replicação de dados for concluída e verificada, atualize os hosts de origem:
   1. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml

   2. Reaplique a alteração para atualizar a resposta automática do repositório de dados da Apigee:

      Importante: omita a flag ‑‑atomic para clusters migrados.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status.
   Observação : se a operação de recriação mostrar o estado concluído e os registros dos processos de recriação contiverem a mensagem "Todas as sessões concluídas", todos os dados foram copiados para a nova região.
   .

   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

   Dica: APIGEE_JMX_USER e APIGEE_JMX_PASSWORD geralmente são definidos nas variáveis de ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   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

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

Importante: ao expandir o Apigee híbrido para um novo data center regional, instale a mesma versão do data center existente. Evite executar versões diferentes de implementações híbridas em diversos data centers.

Aviso: se a instalação de uma nova região falhar, não continue a instalação. Em vez disso, exclua e recrie a instalação híbrida na região com falha.

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. Para a primeira região criada, acesse os pods no namespace da Apigee:

   kubectl get pods -o wide -n apigee
   

2. Identifique o endereço do host de semente multirregional para Cassandra nesta região, por exemplo, 10.0.0.11.

3. Prepare o arquivo overrides.yaml para a segunda região e adicione o endereço IP do host de semente da seguinte maneira:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Substitua:

   • SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo, 10.0.0.11.
   • DATACENTER_NAME pelo nome do data center. Por exemplo, dc-2.
   • RACK_NAME pelo nome do rack, por exemplo, ra-1.
   • CLUSTER_NAME pelo nome do cluster da Cassandra. Por padrão, o valor é apigeecluster. Se você usar um nome de cluster diferente, será preciso especificar um valor para cassandra.clusterName. É possível escolher o próprio valor, mas ele precisa ser o mesmo em todas as regiões.

Configurar a segunda região

Para configurar a nova região:

1. Instale o cert-manager na segunda região.

2. 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 apigee -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. Atualize o namespace no arquivo se 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
      

3. Siga as etapas para instalar os CRDs da Apigee híbrida na nova região.

4. Agora use gráficos do Helm para instalar a Apigee híbrida na nova região com os seguintes comandos do gráfico do Helm (como feito na região 1):

   Observação: é possível usar as mesmas CRDs para manter a consistência utilizando a mesma pasta em que você fez o download dos gráficos. Também é possível manter o arquivo de modificações exclusivo entre região 1 e 2 ao nomear algo exclusivo, como overrides-region_name.yaml.
   Importante: omita ‑‑atomic sinalização para clusters migrados.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos.
   Aviso: se a saída desse comando não mostrar os data centers novos e atuais, a configuração falhou. Nesse caso, não prossiga.

   Para corrigir o problema, a instalação híbrida na nova região precisa ser excluída e recriada. Consulte Desinstalar o ambiente de execução híbrido. Se a configuração falhar, não tente prosseguir ou mesclar o cluster.

   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

6. 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

7. Verifique o status de recriação usando o comando a seguir.
   Observação : a operação de recriação pode levar várias horas, dependendo do tamanho dos dados.

   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
   }

8. Depois que a replicação de dados for concluída e verificada, atualize os hosts de origem:
   1. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml

   2. Reaplique a alteração para atualizar a resposta automática do repositório de dados da Apigee:

      Importante: omita a flag ‑‑atomic para clusters migrados.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status.
   Observação : se a operação de recriação mostrar o estado concluído e os registros dos processos de recriação contiverem a mensagem "Todas as sessões concluídas", todos os dados foram copiados para a nova região.
   .

   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

   Dica: APIGEE_JMX_USER e APIGEE_JMX_PASSWORD geralmente são definidos nas variáveis de ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   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

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

Importante: ao expandir o Apigee híbrido para um novo data center regional, instale a mesma versão do data center existente. Evite executar versões diferentes de implementações híbridas em diversos data centers.

Aviso: se a instalação de uma nova região falhar, não continue a instalação. Em vez disso, exclua e recrie a instalação híbrida na região com falha.

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. Para a primeira região criada, acesse os pods no namespace da Apigee:

   kubectl get pods -o wide -n apigee
   

2. Identifique o endereço do host de semente multirregional para Cassandra nesta região, por exemplo, 10.0.0.11.

3. Prepare o arquivo overrides.yaml para a segunda região e adicione o endereço IP do host de semente da seguinte maneira:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Substitua:

   • SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo, 10.0.0.11.
   • DATACENTER_NAME pelo nome do data center. Por exemplo, dc-2.
   • RACK_NAME pelo nome do rack, por exemplo, ra-1.
   • CLUSTER_NAME pelo nome do cluster da Cassandra. Por padrão, o valor é apigeecluster. Se você usar um nome de cluster diferente, será preciso especificar um valor para cassandra.clusterName. É possível escolher o próprio valor, mas ele precisa ser o mesmo em todas as regiões.

Configurar a segunda região

Para configurar a nova região:

1. Instale o cert-manager na segunda região.

2. 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 apigee -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. Atualize o namespace no arquivo se 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
      

3. Siga as etapas para instalar os CRDs da Apigee híbrida na nova região.

4. Agora use gráficos do Helm para instalar a Apigee híbrida na nova região com os seguintes comandos do gráfico do Helm (como feito na região 1):

   Observação: é possível usar as mesmas CRDs para manter a consistência utilizando a mesma pasta em que você fez o download dos gráficos. Também é possível manter o arquivo de modificações exclusivo entre região 1 e 2 ao nomear algo exclusivo, como overrides-region_name.yaml.
   Importante: omita ‑‑atomic sinalização para clusters migrados.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos.
   Aviso: se a saída desse comando não mostrar os data centers novos e atuais, a configuração falhou. Nesse caso, não prossiga.

   Para corrigir o problema, a instalação híbrida na nova região precisa ser excluída e recriada. Consulte Desinstalar o ambiente de execução híbrido. Se a configuração falhar, não tente prosseguir ou mesclar o cluster.

   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

6. 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

7. Verifique o status de recriação usando o comando a seguir.
   Observação : a operação de recriação pode levar várias horas, dependendo do tamanho dos dados.

   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
   }

8. Depois que a replicação de dados for concluída e verificada, atualize os hosts de origem:
   1. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml

   2. Reaplique a alteração para atualizar a resposta automática do repositório de dados da Apigee:

      Importante: omita a flag ‑‑atomic para clusters migrados.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status.
   Observação : se a operação de recriação mostrar o estado concluído e os registros dos processos de recriação contiverem a mensagem "Todas as sessões concluídas", todos os dados foram copiados para a nova região.
   .

   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

   Dica: APIGEE_JMX_USER e APIGEE_JMX_PASSWORD geralmente são definidos nas variáveis de ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   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

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

Importante: ao expandir o Apigee híbrido para um novo data center regional, instale a mesma versão do data center existente. Evite executar versões diferentes de implementações híbridas em diversos data centers. Essa restrição não se aplica ao fazer upgrade de vários data centers para uma nova versão.

Aviso: se a instalação de uma nova região falhar, não continue a instalação. Em vez disso, exclua e recrie a instalação híbrida na região com falha.

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. Para a primeira região criada, acesse os pods no namespace da Apigee:

   kubectl get pods -o wide -n apigee
   

2. Identifique o endereço do host de semente multirregional para Cassandra nesta região, por exemplo, 10.0.0.11.

3. Prepare o arquivo overrides.yaml para a segunda região e adicione o endereço IP do host de semente da seguinte maneira:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Substitua:

   • SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo, 10.0.0.11.
   • DATACENTER_NAME pelo nome do data center. Por exemplo, dc-2.
   • RACK_NAME pelo nome do rack, por exemplo, ra-1.
   • CLUSTER_NAME pelo nome do cluster da Cassandra. Por padrão, o valor é apigeecluster. Se você usar um nome de cluster diferente, será preciso especificar um valor para cassandra.clusterName. É possível escolher o próprio valor, mas ele precisa ser o mesmo em todas as regiões.

Configurar a segunda região

Para configurar a nova região:

1. Instale o cert-manager na segunda região.

2. 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 apigee -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. Atualize o namespace no arquivo se 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
      

3. Siga as etapas para instalar os CRDs da Apigee híbrida na nova região.

4. Agora use gráficos do Helm para instalar a Apigee híbrida na nova região com os seguintes comandos do gráfico do Helm (como feito na região 1):

   Observação: é possível usar as mesmas CRDs para manter a consistência utilizando a mesma pasta em que você fez o download dos gráficos. Também é possível manter o arquivo de modificações exclusivo entre região 1 e 2 ao nomear algo exclusivo, como overrides-region_name.yaml.
   Importante: omita ‑‑atomic sinalização para clusters migrados.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos.
   Aviso: se a saída desse comando não mostrar os data centers novos e atuais, a configuração falhou. Nesse caso, não prossiga.

   Para corrigir o problema, a instalação híbrida na nova região precisa ser excluída e recriada. Consulte Desinstalar o ambiente de execução híbrido. Se a configuração falhar, não tente prosseguir ou mesclar o cluster.

   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

6. 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

7. Verifique o status de recriação usando o comando a seguir.
   Observação : a operação de recriação pode levar várias horas, dependendo do tamanho dos dados.

   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
   }

8. Depois que a replicação de dados for concluída e verificada, atualize os hosts de origem:
   1. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml

   2. Reaplique a alteração para atualizar a resposta automática do repositório de dados da Apigee:

      Importante: omita a flag ‑‑atomic para clusters migrados.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status.
   Observação : se a operação de recriação mostrar o estado concluído e os registros dos processos de recriação contiverem a mensagem "Todas as sessões concluídas", todos os dados foram copiados para a nova região.
   .

   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

   Dica: APIGEE_JMX_USER e APIGEE_JMX_PASSWORD geralmente são definidos nas variáveis de ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   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

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

OpenShift

Importante: ao expandir o Apigee híbrido para um novo data center regional, instale a mesma versão do data center existente. Evite executar versões diferentes de implementações híbridas em diversos data centers.

Aviso: se a instalação de uma nova região falhar, não continue a instalação. Em vez disso, exclua e recrie a instalação híbrida na região com falha.

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. Para a primeira região criada, acesse os pods no namespace da Apigee:

   kubectl get pods -o wide -n apigee
   

2. Identifique o endereço do host de semente multirregional para Cassandra nesta região, por exemplo, 10.0.0.11.

3. Prepare o arquivo overrides.yaml para a segunda região e adicione o endereço IP do host de semente da seguinte maneira:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Substitua:

   • SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo, 10.0.0.11.
   • DATACENTER_NAME pelo nome do data center. Por exemplo, dc-2.
   • RACK_NAME pelo nome do rack, por exemplo, ra-1.
   • CLUSTER_NAME pelo nome do cluster da Cassandra. Por padrão, o valor é apigeecluster. Se você usar um nome de cluster diferente, será preciso especificar um valor para cassandra.clusterName. É possível escolher o próprio valor, mas ele precisa ser o mesmo em todas as regiões.

Configurar a segunda região

Para configurar a nova região:

1. Instale o cert-manager na segunda região.

2. 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 apigee -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. Atualize o namespace no arquivo se 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
      

3. Siga as etapas para instalar os CRDs da Apigee híbrida na nova região.

4. Agora use gráficos do Helm para instalar a Apigee híbrida na nova região com os seguintes comandos do gráfico do Helm (como feito na região 1):

   Observação: é possível usar as mesmas CRDs para manter a consistência utilizando a mesma pasta em que você fez o download dos gráficos. Também é possível manter o arquivo de modificações exclusivo entre região 1 e 2 ao nomear algo exclusivo, como overrides-region_name.yaml.
   Importante: omita ‑‑atomic sinalização para clusters migrados.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos.
   Aviso: se a saída desse comando não mostrar os data centers novos e atuais, a configuração falhou. Nesse caso, não prossiga.

   Para corrigir o problema, a instalação híbrida na nova região precisa ser excluída e recriada. Consulte Desinstalar o ambiente de execução híbrido. Se a configuração falhar, não tente prosseguir ou mesclar o cluster.

   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

6. 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

7. Verifique o status de recriação usando o comando a seguir.
   Observação : a operação de recriação pode levar várias horas, dependendo do tamanho dos dados.

   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
   }

8. Depois que a replicação de dados for concluída e verificada, atualize os hosts de origem:
   1. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml

   2. Reaplique a alteração para atualizar a resposta automática do repositório de dados da Apigee:

      Importante: omita a flag ‑‑atomic para clusters migrados.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status.
   Observação : se a operação de recriação mostrar o estado concluído e os registros dos processos de recriação contiverem a mensagem "Todas as sessões concluídas", todos os dados foram copiados para a nova região.
   .

   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

   Dica: APIGEE_JMX_USER e APIGEE_JMX_PASSWORD geralmente são definidos nas variáveis de ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   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

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.