Esta página foi traduzida pela API Cloud Translation.

Implementação em várias regiões

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

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

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

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

Arquitetura de implementação multirregional híbrida do Apigee

Pré-requisitos

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

GKE

Quando instalar implementações do Apigee em várias regiões entre diferentes redes (por exemplo, diferentes fornecedores de nuvem, diferentes redes VPC, nuvem e no local, etc.), tem de fornecer conectividade interna entre estas redes separadas que o Cassandra pode usar para comunicar entre nós. Isto pode ser conseguido com VPNs ou soluções de conectividade específicas da nuvem.
Se estiver a usar a Identidade de workload num cluster para autenticar contas de serviço, recomendamos vivamente que use a Identidade de workload para cada cluster para o qual se expandir. Consulte os artigos Ativar o Workload Identity no GKE ou Ativar a federação de identidades da carga de trabalho no AKS e no EKS.
Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR.
Certifique-se de que o cert-manager está instalado em cada cluster.
Configure a comunicação entre regiões.
Certifique-se de que todos os pods do Cassandra conseguem resolver os respetivos nomes de anfitrião. Se hostNetwork estiver definido como false, o nome do anfitrião é o nome do pod do Cassandra. Se hostNetwork estiver definido como true, o nome do anfitrião é o nome do anfitrião do nó do Kubernetes que executa o pod do Cassandra.
Sugestão: para verificar se a resolução do nome do anfitrião está a funcionar, use estes comandos.

Se hostNetwork estiver definido como false, use o comando 1. Se hostNetwork estiver definido como true, use o comando 2.

Se a resolução do nome de anfitrião estiver a funcionar, o resultado apresenta um endereço IP. Se a resolução do nome do anfitrião falhar, o resultado inclui "Host not found" (Anfitrião 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 Cassandra Multi Region:
- Certifique-se de que o espaço de nomes da rede de pods tem conetividade nas regiões, incluindo firewalls, VPN, interligação de VPCs e interligação de Vnets. Este é o caso da maioria das instalações do GKE.
- Se o espaço de nomes da rede de pods não tiver conetividade entre clusters (os clusters estiverem a ser executados no "modo de rede isolada"), ative a funcionalidade hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no ficheiro de substituições para todas as regiões na sua instalação multirregiões do Apigee Hybrid.
  Para mais informações sobre a necessidade de hostNetwork, consulte Clusters do modo isolado e hostNetwork abaixo.
- Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
- Quando a opção hostNetwork está ativada, certifique-se de que os nós de trabalho podem realizar uma procura de DNS de encaminhamento dos respetivos nomes de anfitriões. O Apigee Cassandra usa a procura de DNS direto para obter o IP do anfitrião durante o arranque.
  Dica: se a resolução de DNS não estiver a funcionar, experimente esta solução alternativa.
  Adicione uma entrada de anfitrião estática no ficheiro /etc/hosts de cada nó de trabalho do 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 clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho em todas as regiões e centros de dados comuniquem. Consulte o artigo Configurar portas para obter informações acerca dos números de portas do Cassandra.

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

GKE On-Prem

Quando instalar implementações do Apigee em várias regiões entre diferentes redes (por exemplo, diferentes fornecedores de nuvem, diferentes redes VPC, nuvem e no local, etc.), tem de fornecer conectividade interna entre estas redes separadas que o Cassandra pode usar para comunicar entre nós. Isto pode ser conseguido com VPNs ou soluções de conectividade específicas da nuvem.
Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR.
Certifique-se de que o cert-manager está instalado em cada cluster.
Configure a comunicação entre regiões.
Certifique-se de que todos os pods do Cassandra conseguem resolver os respetivos nomes de anfitrião. Se hostNetwork estiver definido como false, o nome do anfitrião é o nome do pod do Cassandra. Se hostNetwork estiver definido como true, o nome do anfitrião é o nome do anfitrião do nó do Kubernetes que executa o pod do Cassandra.
Sugestão: para verificar se a resolução do nome do anfitrião está a funcionar, use estes comandos.

Se hostNetwork estiver definido como false, use o comando 1. Se hostNetwork estiver definido como true, use o comando 2.

Se a resolução do nome de anfitrião estiver a funcionar, o resultado apresenta um endereço IP. Se a resolução do nome do anfitrião falhar, o resultado inclui "Host not found" (Anfitrião 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 Cassandra Multi Region:
- Se o espaço de nomes da rede de pods não tiver conetividade entre clusters (os clusters estão a ser executados no "modo de rede isolada", o caso predefinido nas instalações do GKE on-prem), ative a funcionalidade hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no ficheiro de substituições para todas as regiões na sua instalação multirregiões híbrida do Apigee.
  Para mais informações sobre a necessidade de hostNetwork, consulte Clusters do modo isolado e hostNetwork abaixo.
- Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
- Quando a opção hostNetwork está ativada, certifique-se de que os nós de trabalho podem realizar uma procura de DNS dos respetivos nomes de anfitriões. O Apigee Cassandra usa a procura de DNS direta para obter o IP do anfitrião durante o arranque.
  Dica: se a resolução de DNS não estiver a funcionar, experimente esta solução alternativa.
  Adicione uma entrada de anfitrião estática no ficheiro /etc/hosts de cada nó de trabalho do 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 em todas as regiões e centros de dados comuniquem. Consulte Configurar portas para os números de portas do Cassandra.

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

AKS

Quando instalar implementações do Apigee em várias regiões entre diferentes redes (por exemplo, diferentes fornecedores de nuvem, diferentes redes VPC, nuvem e no local, etc.), tem de fornecer conectividade interna entre estas redes separadas que o Cassandra pode usar para comunicar entre nós. Isto pode ser conseguido com VPNs ou soluções de conectividade específicas da nuvem.
Siga o guia de instalação híbridapara ver os pré-requisitos, como a configuração do Google Cloud e da organização , antes de avançar para os passos de configuração do cluster.
Certifique-se de que o cert-manager está instalado em cada cluster.
Certifique-se de que todos os pods do Cassandra conseguem resolver os respetivos nomes de anfitrião. Se hostNetwork estiver definido como false, o nome do anfitrião é o nome do pod do Cassandra. Se hostNetwork estiver definido como true, o nome do anfitrião é o nome do anfitrião do nó do Kubernetes que executa o pod do Cassandra.
Sugestão: para verificar se a resolução do nome do anfitrião está a funcionar, use estes comandos.

Se hostNetwork estiver definido como false, use o comando 1. Se hostNetwork estiver definido como true, use o comando 2.

Se a resolução do nome do anfitrião estiver a funcionar, o resultado apresenta um endereço IP. Se a resolução do nome do anfitrião falhar, o resultado inclui "Host not found" (Anfitrião 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 Cassandra Multi Region:
- Se o espaço de nomes da rede de pods não tiver conetividade entre clusters (os clusters estão a ser executados no "modo de rede isolada", o caso predefinido nas instalações do AKS), ative a funcionalidade hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no ficheiro de substituições para todas as regiões na instalação multirregiões do Apigee Hybrid.
  Para mais informações sobre a necessidade de hostNetwork, consulte Clusters do modo isolado e hostNetwork abaixo.
- Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
- Quando a opção hostNetwork está ativada, certifique-se de que os nós de trabalho podem realizar uma procura de DNS de encaminhamento dos respetivos nomes de anfitriões. O Apigee Cassandra usa a procura de DNS direto para obter o IP do anfitrião durante o arranque.
  Dica: se a resolução de DNS não estiver a funcionar, experimente esta solução alternativa.
  Adicione uma entrada de anfitrião estática no ficheiro /etc/hosts de cada nó de trabalho do 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 em todas as regiões e centros de dados comuniquem. Consulte Configurar portas para os números de portas do Cassandra.

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

EKS

Quando instalar implementações do Apigee em várias regiões entre diferentes redes (por exemplo, diferentes fornecedores de nuvem, diferentes redes VPC, nuvem e no local, etc.), tem de fornecer conectividade interna entre estas redes separadas que o Cassandra pode usar para comunicar entre nós. Isto pode ser conseguido com VPNs ou soluções de conectividade específicas da nuvem.
Siga o guia de instalação híbridapara ver os pré-requisitos, como a configuração do Google Cloud e da organização , antes de avançar para os passos de configuração do cluster.
Certifique-se de que o cert-manager está instalado em cada cluster.
Certifique-se de que todos os pods do Cassandra conseguem resolver os respetivos nomes de anfitrião. Se hostNetwork estiver definido como false, o nome do anfitrião é o nome do pod do Cassandra. Se hostNetwork estiver definido como true, o nome do anfitrião é o nome do anfitrião do nó do Kubernetes que executa o pod do Cassandra.
Sugestão: para verificar se a resolução do nome do anfitrião está a funcionar, use estes comandos.

Se hostNetwork estiver definido como false, use o comando 1. Se hostNetwork estiver definido como true, use o comando 2.

Se a resolução do nome do anfitrião estiver a funcionar, o resultado apresenta um endereço IP. Se a resolução do nome do anfitrião falhar, o resultado inclui "Host not found" (Anfitrião 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 Cassandra Multi Region:
- Se o espaço de nomes da rede de pods não tiver conetividade entre clusters (os clusters estão a ser executados no "modo de rede isolada"), ative a funcionalidade hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no ficheiro de substituições para todas as regiões na sua instalação multirregiões do Apigee hybrid. O Amazon EKS usa o modelo de rede totalmente integrado por predefinição.
  Para mais informações sobre a necessidade de hostNetwork, consulte Clusters do modo isolado e hostNetwork abaixo.
- Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
- Quando a opção hostNetwork está ativada, certifique-se de que os nós de trabalho podem realizar uma procura de DNS de encaminhamento dos respetivos nomes de anfitriões. O Apigee Cassandra usa a procura de DNS direto para obter o IP do anfitrião durante o arranque.
  Dica: se a resolução de DNS não estiver a funcionar, experimente esta solução alternativa.
  Adicione uma entrada de anfitrião estática no ficheiro /etc/hosts de cada nó de trabalho do 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 em todas as regiões e centros de dados comuniquem. Consulte Configurar portas para os números de portas do Cassandra.

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

OpenShift

Quando instalar implementações do Apigee em várias regiões entre diferentes redes (por exemplo, diferentes fornecedores de nuvem, diferentes redes VPC, nuvem e no local, etc.), tem de fornecer conectividade interna entre estas redes separadas que o Cassandra pode usar para comunicar entre nós. Isto pode ser conseguido com VPNs ou soluções de conectividade específicas da nuvem.
Siga o guia de instalação híbridapara ver os pré-requisitos, como a configuração do Google Cloud e da organização , antes de avançar para os passos de configuração do cluster.
Certifique-se de que o cert-manager está instalado em cada cluster.
Certifique-se de que todos os pods do Cassandra conseguem resolver os respetivos nomes de anfitrião. Se hostNetwork estiver definido como false, o nome do anfitrião é o nome do pod do Cassandra. Se hostNetwork estiver definido como true, o nome do anfitrião é o nome do anfitrião do nó do Kubernetes que executa o pod do Cassandra.
Sugestão: para verificar se a resolução do nome do anfitrião está a funcionar, use estes comandos.

Se hostNetwork estiver definido como false, use o comando 1. Se hostNetwork estiver definido como true, use o comando 2.

Se a resolução do nome do anfitrião estiver a funcionar, o resultado apresenta um endereço IP. Se a resolução do nome do anfitrião falhar, o resultado inclui "Host not found" (Anfitrião 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 Cassandra Multi Region:
- Se o espaço de nomes da rede de pods não tiver conetividade entre clusters (os clusters estão a ser executados no "modo de rede isolada", o caso predefinido nas instalações do OpenShift), ative a funcionalidade hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no ficheiro de substituições para todas as regiões na instalação multirregiões do Apigee Hybrid.
  Para mais informações sobre a necessidade de hostNetwork, consulte Clusters do modo isolado e hostNetwork abaixo.
- Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
- Quando a opção hostNetwork está ativada, certifique-se de que os nós de trabalho podem realizar uma procura de DNS de encaminhamento dos respetivos nomes de anfitriões. O Apigee Cassandra usa a procura de DNS direto para obter o IP do anfitrião durante o arranque.
  Dica: se a resolução de DNS não estiver a funcionar, experimente esta solução alternativa.
  Adicione uma entrada de anfitrião estática no ficheiro /etc/hosts de cada nó de trabalho do 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 em todas as regiões e centros de dados comuniquem. Consulte Configurar portas para os números de portas do Cassandra.

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

Clusters do modo de ilha e hostNetwork

Existem dois modelos de rede principais para clusters do Kubernetes: totalmente integrado (ou plano) e modo de ilha. A Apigee recomenda a utilização do modelo de rede simples sempre que possível, uma vez que simplifica a conetividade do Cassandra em várias regiões. Quando um cluster do Kubernetes está configurado no modo de ilha, a rede de pods está isolada. Os pods não podem comunicar diretamente com pods executados noutros clusters através do endereço IP do pod. Consulte o artigo Implementações típicas de modelos de rede para mais informações sobre as diferenças entre estes dois modelos de rede e exemplos de cada um.

Quando o Apigee Hybrid é executado em dois ou mais clusters do Kubernetes com um modelo de rede no modo isolado, tem de ativar a definição hostNetwork para o Cassandra através da propriedade cassandra.hostNetwork. Por predefinição, os pods do Kubernetes estão isolados em espaços de nomes de rede individuais que impedem a utilização do IP do nó de trabalho do Kubernetes. Quando hostNetwork está definido como true, o pod não está isolado no seu próprio espaço de nomes de rede e, em vez disso, usa o endereço IP e o nome do anfitrião do nó de trabalho do Kubernetes no qual o pod está agendado. Isto permite que o Cassandra use nativamente o IP do nó de trabalho do Kubernetes como o seu IP, o que dá ao Cassandra um meio de estabelecer uma malha completa entre todos os pods do Cassandra em vários clusters em execução no modo isolado.

Resolução do nome do anfitrião do Cassandra

Embora um pod do Cassandra não resolva outros pods do Cassandra por nome de anfitrião, no arranque, o Cassandra verifica se o respetivo nome de anfitrião é resolvível pelo DNS. Uma vez que o nome do anfitrião do pod é igual ao nome do anfitrião do nó de trabalho do Kubernetes quando hostNetwork está definido como verdadeiro, o nome do anfitrião do nó de trabalho tem de ser resolvível para um endereço IP através do serviço DNS do cluster. Se não for possível resolver o nome do anfitrião do nó de trabalho do Kubernetes, o pod do Cassandra não é iniciado totalmente. Por conseguinte, é importante que os nomes de anfitrião dos nós de trabalho do Kubernetes sejam resolvidos a partir de pods no cluster quando define hostNetwork como true.

Configure o Apigee Hybrid para várias regiões

Esta secção descreve como configurar o Apigee hybrid para várias regiões.

GKE

Configure o anfitrião de origem multirregião

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

Para a primeira região criada, obtenha os pods no seu espaço de nomes do Apigee:
```
kubectl get pods -o wide -n APIGEE_NAMESPACE
```
Identifique o endereço do anfitrião inicial de várias regiões para o Cassandra nesta região, por exemplo, 10.0.0.11.
Prepare o ficheiro overrides.yaml para a segunda região e adicione o endereço IP do anfitrião inicial da seguinte forma:
```
cassandra:
  multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
  datacenter: "DATACENTER_NAME"
  rack: "RACK_NAME"
  hostNetwork: false
  clusterName: CLUSTER_NAME
```
Substitua o seguinte:
- SEED_HOST_IP_ADDRESS com o endereço IP do anfitrião inicial, por exemplo, 10.0.0.11.
- DATACENTER_NAME com o nome do centro de dados, por exemplo, dc-2.
- RACK_NAME com o nome do suporte, por exemplo, ra-1.
- CLUSTER_NAME com o nome do seu cluster do Cassandra. Por predefinição, o valor é apigeecluster. Se usar um nome de cluster diferente, tem de especificar um valor para cassandra.clusterName. Pode escolher o seu próprio valor, mas tem de ser o mesmo em todas as regiões.

Configure a segunda região

Para configurar a nova região:

Instale o cert-manager na segunda região.
Copie o certificado do cluster existente para o novo cluster. A nova raiz da AC é usada pelo Cassandra e outros componentes híbridos para mTLS. Por conseguinte, é essencial ter certificados consistentes no cluster.
1. Defina o contexto para o espaço de nomes original:
```
kubectl config use-context ORIGINAL_CLUSTER_NAME
```
2. Exporte a configuração do espaço de nomes atual para um ficheiro:
```
kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
```
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context NEW_CLUSTER_NAME
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o espaço de nomes no ficheiro se estiver a usar um espaço de nomes diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Siga os passos para instalar os CRDs híbridos do Apigee na nova região.

Agora, use os gráficos Helm para instalar o Apigee hybrid na nova região com os seguintes comandos de gráficos Helm (como feito na região 1):

Nota: pode usar os mesmos CRDs para consistência usando a mesma pasta onde tem os gráficos transferidos. Também pode manter o ficheiro de substituições exclusivo entre a região 1 e 2 ao atribuir-lhe um nome exclusivo, como overrides-region_name.yaml, etc.

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

ENV_RELEASE_NAME e ENV_GROUP_RELEASE_NAME são nomes usados para monitorizar a instalação e as atualizações dos gráficos apigee-env e apigee-virtualhost. Os nomes das versões do Helm têm de ser exclusivos na sua instalação híbrida do Apigee. Se o nome do ambiente for exclusivo, pode ser igual a ENV_NAME. No entanto, se tiver o mesmo nome para o ambiente e o grupo de ambientes, certifique-se de que introduz um nome de lançamento do Helm exclusivo para cada um. Por exemplo, se ambos tiverem o nome dev, pode usar algo como dev-env-release e dev-envgroup-release.

Pode ver uma lista de nomes de lançamentos com o comando helm list:

helm list -n APIGEE_NAMESPACE

Valide a configuração do cluster do Cassandra executando o seguinte comando. A saída deve mostrar os centros de dados existentes e novos.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
-- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

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

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

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

Configure o Cassandra em todos os pods nos novos centros de dados.
1. Obtenha o apigeeorg do cluster com o seguinte comando:
```
kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
```
  Por exemplo:
```
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
"rg-hybrid-b7d3b9c"
```
2. Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.
  O ficheiro tem de conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Onde:
  - REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
  - NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
  - APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION é a região de origem, o valor do centro de dados na secção cassandra de source region overrides.yaml
  Por exemplo:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
3. Aplique o CassandraDataReplication com o seguinte comando:
```
kubectl apply -f datareplication.yaml
```

Valide o estado da reconstrução através do seguinte comando.

kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

Os resultados devem ter um aspeto semelhante ao seguinte:

{
"rebuildDetails": {
"apigee-cassandra-default-0": {
"state": "complete",
"updated": 1623105760
},
"apigee-cassandra-default-1": {
"state": "complete",
"updated": 1623105765
},
"apigee-cassandra-default-2": {
"state": "complete",
"updated": 1623105770
}
},
"state": "complete",
"updated": 1623105770
}

Assim que a replicação de dados estiver concluída e validada, atualize os anfitriões iniciais:
1. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
2. Volte a aplicar a alteração para atualizar o CR do arquivo de dados do Apigee:
```
helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
```

Valide os processos de reconstrução a partir dos registos. Além disso, valide o tamanho dos dados com o comando nodetool status.

kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

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

O exemplo seguinte mostra entradas de registo de exemplo:

INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Verifique o estado do cluster do Cassandra

O comando seguinte é útil para ver se a configuração do cluster foi bem-sucedida em dois centros de dados. O comando verifica o estado do nodetool para as duas regiões.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- 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

Configure o anfitrião de origem multirregião

Para a primeira região criada, obtenha os pods no seu espaço de nomes do Apigee:
```
kubectl get pods -o wide -n APIGEE_NAMESPACE
```
Identifique o endereço do anfitrião inicial de várias regiões para o Cassandra nesta região, por exemplo, 10.0.0.11.
Prepare o ficheiro overrides.yaml para a segunda região e adicione o endereço IP do anfitrião inicial da seguinte forma:
```
cassandra:
  multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
  datacenter: "DATACENTER_NAME"
  rack: "RACK_NAME"
  hostNetwork: false
  clusterName: CLUSTER_NAME
```
Substitua o seguinte:
- SEED_HOST_IP_ADDRESS com o endereço IP do anfitrião inicial, por exemplo, 10.0.0.11.
- DATACENTER_NAME com o nome do centro de dados, por exemplo, dc-2.
- RACK_NAME com o nome do suporte, por exemplo, ra-1.
- CLUSTER_NAME com o nome do seu cluster do Cassandra. Por predefinição, o valor é apigeecluster. Se usar um nome de cluster diferente, tem de especificar um valor para cassandra.clusterName. Pode escolher o seu próprio valor, mas tem de ser o mesmo em todas as regiões.

Configure a segunda região

Para configurar a nova região:

Instale o cert-manager na segunda região.
Copie o certificado do cluster existente para o novo cluster. A nova raiz da AC é usada pelo Cassandra e outros componentes híbridos para mTLS. Por conseguinte, é essencial ter certificados consistentes no cluster.
1. Defina o contexto para o espaço de nomes original:
```
kubectl config use-context ORIGINAL_CLUSTER_NAME
```
2. Exporte a configuração do espaço de nomes atual para um ficheiro:
```
kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
```
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context NEW_CLUSTER_NAME
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o espaço de nomes no ficheiro se estiver a usar um espaço de nomes diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Siga os passos para instalar os CRDs híbridos do Apigee na nova região.

Agora, use os gráficos Helm para instalar o Apigee hybrid na nova região com os seguintes comandos de gráficos Helm (como feito na região 1):

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

Pode ver uma lista de nomes de lançamentos com o comando helm list:

helm list -n APIGEE_NAMESPACE

Valide a configuração do cluster do Cassandra executando o seguinte comando. A saída deve mostrar os centros de dados existentes e novos.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
-- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

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

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

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

Configure o Cassandra em todos os pods nos novos centros de dados.
1. Obtenha o apigeeorg do cluster com o seguinte comando:
```
kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
```
  Por exemplo:
```
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
"rg-hybrid-b7d3b9c"
```
2. Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.
  O ficheiro tem de conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Onde:
  - REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
  - NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
  - APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION é a região de origem, o valor do centro de dados na secção cassandra de source region overrides.yaml
  Por exemplo:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
3. Aplique o CassandraDataReplication com o seguinte comando:
```
kubectl apply -f datareplication.yaml
```

Valide o estado da reconstrução através do seguinte comando.

kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

Os resultados devem ter um aspeto semelhante ao seguinte:

{
"rebuildDetails": {
"apigee-cassandra-default-0": {
"state": "complete",
"updated": 1623105760
},
"apigee-cassandra-default-1": {
"state": "complete",
"updated": 1623105765
},
"apigee-cassandra-default-2": {
"state": "complete",
"updated": 1623105770
}
},
"state": "complete",
"updated": 1623105770
}

Assim que a replicação de dados estiver concluída e validada, atualize os anfitriões iniciais:
1. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
2. Volte a aplicar a alteração para atualizar o CR do arquivo de dados do Apigee:
```
helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
```

Valide os processos de reconstrução a partir dos registos. Além disso, valide o tamanho dos dados com o comando nodetool status.

kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

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

O exemplo seguinte mostra entradas de registo de exemplo:

INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Verifique o estado do cluster do Cassandra

O comando seguinte é útil para ver se a configuração do cluster foi bem-sucedida em dois centros de dados. O comando verifica o estado do nodetool para as duas regiões.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- 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

Crie uma rede virtual em cada região

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

Crie clusters multirregionais

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

Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho em todas as regiões e centros de dados comuniquem. Consulte o artigo Configurar portas para ver os números das portas do Cassandra.

Configure o anfitrião de origem multirregião

Para a primeira região criada, obtenha os pods no seu espaço de nomes do Apigee:
```
kubectl get pods -o wide -n APIGEE_NAMESPACE
```
Identifique o endereço do anfitrião inicial de várias regiões para o Cassandra nesta região, por exemplo, 10.0.0.11.
Prepare o ficheiro overrides.yaml para a segunda região e adicione o endereço IP do anfitrião inicial da seguinte forma:
```
cassandra:
  multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
  datacenter: "DATACENTER_NAME"
  rack: "RACK_NAME"
  hostNetwork: false
  clusterName: CLUSTER_NAME
```
Substitua o seguinte:
- SEED_HOST_IP_ADDRESS com o endereço IP do anfitrião inicial, por exemplo, 10.0.0.11.
- DATACENTER_NAME com o nome do centro de dados, por exemplo, dc-2.
- RACK_NAME com o nome do suporte, por exemplo, ra-1.
- CLUSTER_NAME com o nome do seu cluster do Cassandra. Por predefinição, o valor é apigeecluster. Se usar um nome de cluster diferente, tem de especificar um valor para cassandra.clusterName. Pode escolher o seu próprio valor, mas tem de ser o mesmo em todas as regiões.

Configure a segunda região

Para configurar a nova região:

Instale o cert-manager na segunda região.
Copie o certificado do cluster existente para o novo cluster. A nova raiz da AC é usada pelo Cassandra e outros componentes híbridos para mTLS. Por conseguinte, é essencial ter certificados consistentes no cluster.
1. Defina o contexto para o espaço de nomes original:
```
kubectl config use-context ORIGINAL_CLUSTER_NAME
```
2. Exporte a configuração do espaço de nomes atual para um ficheiro:
```
kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
```
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context NEW_CLUSTER_NAME
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o espaço de nomes no ficheiro se estiver a usar um espaço de nomes diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Siga os passos para instalar os CRDs híbridos do Apigee na nova região.

Agora, use os gráficos Helm para instalar o Apigee hybrid na nova região com os seguintes comandos de gráficos Helm (como feito na região 1):

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

Pode ver uma lista de nomes de lançamentos com o comando helm list:

helm list -n APIGEE_NAMESPACE

Valide a configuração do cluster do Cassandra executando o seguinte comando. A saída deve mostrar os centros de dados existentes e novos.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
-- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

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

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

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

Configure o Cassandra em todos os pods nos novos centros de dados.
1. Obtenha o apigeeorg do cluster com o seguinte comando:
```
kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
```
  Por exemplo:
```
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
"rg-hybrid-b7d3b9c"
```
2. Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.
  O ficheiro tem de conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Onde:
  - REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
  - NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
  - APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION é a região de origem, o valor do centro de dados na secção cassandra de source region overrides.yaml
  Por exemplo:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
3. Aplique o CassandraDataReplication com o seguinte comando:
```
kubectl apply -f datareplication.yaml
```

Valide o estado da reconstrução através do seguinte comando.

kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

Os resultados devem ter um aspeto semelhante ao seguinte:

{
"rebuildDetails": {
"apigee-cassandra-default-0": {
"state": "complete",
"updated": 1623105760
},
"apigee-cassandra-default-1": {
"state": "complete",
"updated": 1623105765
},
"apigee-cassandra-default-2": {
"state": "complete",
"updated": 1623105770
}
},
"state": "complete",
"updated": 1623105770
}

Assim que a replicação de dados estiver concluída e validada, atualize os anfitriões iniciais:
1. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
2. Volte a aplicar a alteração para atualizar o CR do arquivo de dados do Apigee:
```
helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
```

Valide os processos de reconstrução a partir dos registos. Além disso, valide o tamanho dos dados com o comando nodetool status.

kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

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

O exemplo seguinte mostra entradas de registo de exemplo:

INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Verifique o estado do cluster do Cassandra

O comando seguinte é útil para ver se a configuração do cluster foi bem-sucedida em dois centros de dados. O comando verifica o estado do nodetool para as duas regiões.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- 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

Crie uma rede virtual em cada região

Siga as recomendações da AWS para estabelecer a comunicação entre regiões, conforme descrito em: O que é o intercâmbio de VPCs?. O termo da AWS para usar diferentes regiões é interligação de VPCs entre regiões.

Crie clusters multirregionais

Configure o anfitrião de origem multirregião

Para a primeira região criada, obtenha os pods no seu espaço de nomes do Apigee:
```
kubectl get pods -o wide -n APIGEE_NAMESPACE
```
Identifique o endereço do anfitrião inicial de várias regiões para o Cassandra nesta região, por exemplo, 10.0.0.11.
Prepare o ficheiro overrides.yaml para a segunda região e adicione o endereço IP do anfitrião inicial da seguinte forma:
```
cassandra:
  multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
  datacenter: "DATACENTER_NAME"
  rack: "RACK_NAME"
  hostNetwork: false
  clusterName: CLUSTER_NAME
```
Substitua o seguinte:
- SEED_HOST_IP_ADDRESS com o endereço IP do anfitrião inicial, por exemplo, 10.0.0.11.
- DATACENTER_NAME com o nome do centro de dados, por exemplo, dc-2.
- RACK_NAME com o nome do suporte, por exemplo, ra-1.
- CLUSTER_NAME com o nome do seu cluster do Cassandra. Por predefinição, o valor é apigeecluster. Se usar um nome de cluster diferente, tem de especificar um valor para cassandra.clusterName. Pode escolher o seu próprio valor, mas tem de ser o mesmo em todas as regiões.

Configure a segunda região

Para configurar a nova região:

Instale o cert-manager na segunda região.
Copie o certificado do cluster existente para o novo cluster. A nova raiz da AC é usada pelo Cassandra e outros componentes híbridos para mTLS. Por conseguinte, é essencial ter certificados consistentes no cluster.
1. Defina o contexto para o espaço de nomes original:
```
kubectl config use-context ORIGINAL_CLUSTER_NAME
```
2. Exporte a configuração do espaço de nomes atual para um ficheiro:
```
kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
```
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context NEW_CLUSTER_NAME
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o espaço de nomes no ficheiro se estiver a usar um espaço de nomes diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Siga os passos para instalar os CRDs híbridos do Apigee na nova região.

Agora, use os gráficos Helm para instalar o Apigee hybrid na nova região com os seguintes comandos de gráficos Helm (como feito na região 1):

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

Pode ver uma lista de nomes de lançamentos com o comando helm list:

helm list -n APIGEE_NAMESPACE

Valide a configuração do cluster do Cassandra executando o seguinte comando. A saída deve mostrar os centros de dados existentes e novos.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
-- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

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

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

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

Configure o Cassandra em todos os pods nos novos centros de dados.
1. Obtenha o apigeeorg do cluster com o seguinte comando:
```
kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
```
  Por exemplo:
```
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
"rg-hybrid-b7d3b9c"
```
2. Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.
  O ficheiro tem de conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Onde:
  - REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
  - NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
  - APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION é a região de origem, o valor do centro de dados na secção cassandra de source region overrides.yaml
  Por exemplo:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
3. Aplique o CassandraDataReplication com o seguinte comando:
```
kubectl apply -f datareplication.yaml
```

Valide o estado da reconstrução através do seguinte comando.

kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

Os resultados devem ter um aspeto semelhante ao seguinte:

{
"rebuildDetails": {
"apigee-cassandra-default-0": {
"state": "complete",
"updated": 1623105760
},
"apigee-cassandra-default-1": {
"state": "complete",
"updated": 1623105765
},
"apigee-cassandra-default-2": {
"state": "complete",
"updated": 1623105770
}
},
"state": "complete",
"updated": 1623105770
}

Assim que a replicação de dados estiver concluída e validada, atualize os anfitriões iniciais:
1. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
2. Volte a aplicar a alteração para atualizar o CR do arquivo de dados do Apigee:
```
helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
```

Valide os processos de reconstrução a partir dos registos. Além disso, valide o tamanho dos dados com o comando nodetool status.

kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

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

O exemplo seguinte mostra entradas de registo de exemplo:

INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Verifique o estado do cluster do Cassandra

O comando seguinte é útil para ver se a configuração do cluster foi bem-sucedida em dois centros de dados. O comando verifica o estado do nodetool para as duas regiões.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

OpenShift

Configure o anfitrião de origem multirregião

Para a primeira região criada, obtenha os pods no seu espaço de nomes do Apigee:
```
kubectl get pods -o wide -n APIGEE_NAMESPACE
```
Identifique o endereço do anfitrião inicial de várias regiões para o Cassandra nesta região, por exemplo, 10.0.0.11.
Prepare o ficheiro overrides.yaml para a segunda região e adicione o endereço IP do anfitrião inicial da seguinte forma:
```
cassandra:
  multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
  datacenter: "DATACENTER_NAME"
  rack: "RACK_NAME"
  hostNetwork: false
  clusterName: CLUSTER_NAME
```
Substitua o seguinte:
- SEED_HOST_IP_ADDRESS com o endereço IP do anfitrião inicial, por exemplo, 10.0.0.11.
- DATACENTER_NAME com o nome do centro de dados, por exemplo, dc-2.
- RACK_NAME com o nome do suporte, por exemplo, ra-1.
- CLUSTER_NAME com o nome do seu cluster do Cassandra. Por predefinição, o valor é apigeecluster. Se usar um nome de cluster diferente, tem de especificar um valor para cassandra.clusterName. Pode escolher o seu próprio valor, mas tem de ser o mesmo em todas as regiões.

Configure a segunda região

Para configurar a nova região:

Instale o cert-manager na segunda região.
Copie o certificado do cluster existente para o novo cluster. A nova raiz da AC é usada pelo Cassandra e outros componentes híbridos para mTLS. Por conseguinte, é essencial ter certificados consistentes no cluster.
1. Defina o contexto para o espaço de nomes original:
```
kubectl config use-context ORIGINAL_CLUSTER_NAME
```
2. Exporte a configuração do espaço de nomes atual para um ficheiro:
```
kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
```
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context NEW_CLUSTER_NAME
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o espaço de nomes no ficheiro se estiver a usar um espaço de nomes diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Siga os passos para instalar os CRDs híbridos do Apigee na nova região.

Agora, use os gráficos Helm para instalar o Apigee hybrid na nova região com os seguintes comandos de gráficos Helm (como feito na região 1):

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

Pode ver uma lista de nomes de lançamentos com o comando helm list:

helm list -n APIGEE_NAMESPACE

Valide a configuração do cluster do Cassandra executando o seguinte comando. A saída deve mostrar os centros de dados existentes e novos.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
-- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

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

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

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

Configure o Cassandra em todos os pods nos novos centros de dados.
1. Obtenha o apigeeorg do cluster com o seguinte comando:
```
kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
```
  Por exemplo:
```
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
"rg-hybrid-b7d3b9c"
```
2. Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.
  O ficheiro tem de conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Onde:
  - REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
  - NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
  - APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION é a região de origem, o valor do centro de dados na secção cassandra de source region overrides.yaml
  Por exemplo:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
3. Aplique o CassandraDataReplication com o seguinte comando:
```
kubectl apply -f datareplication.yaml
```

Valide o estado da reconstrução através do seguinte comando.

kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

Os resultados devem ter um aspeto semelhante ao seguinte:

{
"rebuildDetails": {
"apigee-cassandra-default-0": {
"state": "complete",
"updated": 1623105760
},
"apigee-cassandra-default-1": {
"state": "complete",
"updated": 1623105765
},
"apigee-cassandra-default-2": {
"state": "complete",
"updated": 1623105770
}
},
"state": "complete",
"updated": 1623105770
}

Assim que a replicação de dados estiver concluída e validada, atualize os anfitriões iniciais:
1. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
2. Volte a aplicar a alteração para atualizar o CR do arquivo de dados do Apigee:
```
helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
```

Valide os processos de reconstrução a partir dos registos. Além disso, valide o tamanho dos dados com o comando nodetool status.

kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

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

O exemplo seguinte mostra entradas de registo de exemplo:

INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Verifique o estado do cluster do Cassandra

O comando seguinte é útil para ver se a configuração do cluster foi bem-sucedida em dois centros de dados. O comando verifica o estado do nodetool para as duas regiões.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- 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

Resolução de problemas

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

Implementação em várias regiões Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Pré-requisitos

GKE

GKE On-Prem

AKS

EKS

OpenShift

Clusters do modo de ilha e hostNetwork

Resolução do nome do anfitrião do Cassandra

Configure o Apigee Hybrid para várias regiões

GKE

Configure o anfitrião de origem multirregião

Configure a segunda região

Verifique o estado do cluster do Cassandra

GKE On-Prem

Configure o anfitrião de origem multirregião

Configure a segunda região

Verifique o estado do cluster do Cassandra

AKS

Crie uma rede virtual em cada região

Crie clusters multirregionais

Configure o anfitrião de origem multirregião

Configure a segunda região

Verifique o estado do cluster do Cassandra

EKS

Crie uma rede virtual em cada região

Crie clusters multirregionais

Configure o anfitrião de origem multirregião

Configure a segunda região

Verifique o estado do cluster do Cassandra

OpenShift

Configure o anfitrião de origem multirregião

Configure a segunda região

Verifique o estado do cluster do Cassandra

Resolução de problemas

Implementação em várias regiões