Implantação multirregional

Você está visualizando a versão 1.10 da documentação da Apigee híbrida. Para mais informações, consulte Versões compatíveis.

Version 1.10 

Versões com suporte:

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

Versões sem suporte:

• 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, 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.
  Dica: para verificar se a resolução de nome do host está funcionando, use estes comandos.
  
  Se hostNetwork estiver definido como hostNetwork, use o Comando 1. Se hostNetwork estiver definido como hostNetwork, 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 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.
  Dica: para verificar se a resolução de nome do host está funcionando, use estes comandos.
  
  Se hostNetwork estiver definido como hostNetwork, use o Comando 1. Se hostNetwork estiver definido como hostNetwork, 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 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.
  Dica: para verificar se a resolução de nome do host está funcionando, use estes comandos.
  
  Se hostNetwork estiver definido como hostNetwork, use o Comando 1. Se hostNetwork estiver definido como hostNetwork, 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 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.
  Dica: para verificar se a resolução de nome do host está funcionando, use estes comandos.
  
  Se hostNetwork estiver definido como hostNetwork, use o Comando 1. Se hostNetwork estiver definido como hostNetwork, 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 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.
  Dica: para verificar se a resolução de nome do host está funcionando, use estes comandos.
  
  Se hostNetwork estiver definido como hostNetwork, use o Comando 1. Se hostNetwork estiver definido como hostNetwork, 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. 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.
   Observação: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

Configurar a nova região

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

Para configurar a nova região:

1. Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
   1. Defina o contexto como o namespace original:

      kubectl config use-context original-cluster-name

   2. Exporte a configuração atual do namespace para um arquivo:

      kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   3. Exporte o secret apigee-ca para um arquivo:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Defina o contexto para o nome do cluster da nova região:

      kubectl config use-context new-cluster-name

   5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:

      kubectl apply -f apigee-namespace.yaml

   6. Importe o secret para o novo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides-DC_name.yaml inclua os mesmos certificados TLS configurados na primeira região, conforme explicado na seção anterior.

   Execute os dois comandos a seguir para instalar a Apigee híbrida na nova região:

   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.

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

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

6. 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 estão 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

   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.
   Observação: Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Verificar o status do cluster do Cassandra

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

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

      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.
   Observação: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

Configurar a nova região

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

Para configurar a nova região:

1. Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
   1. Defina o contexto como o namespace original:

      kubectl config use-context original-cluster-name

   2. Exporte a configuração atual do namespace para um arquivo:

      kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   3. Exporte o secret apigee-ca para um arquivo:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Defina o contexto para o nome do cluster da nova região:

      kubectl config use-context new-cluster-name

   5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:

      kubectl apply -f apigee-namespace.yaml

   6. Importe o secret para o novo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides-DC_name.yaml inclua os mesmos certificados TLS configurados na primeira região, conforme explicado na seção anterior.

   Execute os dois comandos a seguir para instalar a Apigee híbrida na nova região:

   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.

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

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

6. 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 estão 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

   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.
   Observação: Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Verificar o status do cluster do Cassandra

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

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

      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.
   Observação: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

Configurar a nova região

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

Para configurar a nova região:

1. Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
   1. Defina o contexto como o namespace original:

      kubectl config use-context original-cluster-name

   2. Exporte a configuração atual do namespace para um arquivo:

      kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   3. Exporte o secret apigee-ca para um arquivo:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Defina o contexto para o nome do cluster da nova região:

      kubectl config use-context new-cluster-name

   5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:

      kubectl apply -f apigee-namespace.yaml

   6. Importe o secret para o novo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides_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:

   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.

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

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

6. 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 estão 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

   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.
   Observação: Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Verificar o status do cluster do Cassandra

O comando a seguir é útil para 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. 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.
   Observação: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

Configurar a nova região

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

Para configurar a nova região:

1. Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
   1. Defina o contexto como o namespace original:

      kubectl config use-context original-cluster-name

   2. Exporte a configuração atual do namespace para um arquivo:

      kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   3. Exporte o secret apigee-ca para um arquivo:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Defina o contexto para o nome do cluster da nova região:

      kubectl config use-context new-cluster-name

   5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:

      kubectl apply -f apigee-namespace.yaml

   6. Importe o secret para o novo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides_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:

   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.

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

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.
   Observação: Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Verificar o status do cluster do Cassandra

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

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

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

      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.
   Observação: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

Configurar a nova região

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

Para configurar a nova região:

1. Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
   1. Defina o contexto como o namespace original:

      kubectl config use-context original-cluster-name

   2. Exporte a configuração atual do namespace para um arquivo:

      kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   3. Exporte o secret apigee-ca para um arquivo:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Defina o contexto para o nome do cluster da nova região:

      kubectl config use-context new-cluster-name

   5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:

      kubectl apply -f apigee-namespace.yaml

   6. Importe o secret para o novo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides_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:

   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.

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

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

6. 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 estão 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

   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.
   Observação: Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Verificar o status do cluster do Cassandra

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