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 carga de trabalho num cluster para autenticar contas de serviço, cada cluster para o qual se expandir também tem de usar a identidade de carga de trabalho. Consulte o artigo Ativar o Workload Identity com o Apigee Hybrid.
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.

Defina o contexto do kubectl para o cluster original antes de obter o nome da semente:
```
kubectl config use-context original-cluster-name
```

Execute o seguinte comando kubectl para identificar um endereço de anfitrião inicial para o Cassandra na região atual.

Um endereço de anfitrião inicial permite que uma nova instância regional encontre o cluster original no primeiro arranque para saber a topologia do cluster. O endereço do anfitrião inicial é designado como o ponto de contacto no cluster.

kubectl get pods -o wide -n apigee -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

Decida qual dos IPs devolvidos pelo comando anterior vai ser o anfitrião principal de várias regiões.

No centro de dados 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em Gerir componentes do plano de tempo de execução, onde multiRegionSeedHost é um dos IPs devolvidos pelo comando anterior:

cassandra:
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
  hostNetwork: false
  clusterName: cluster_name # must be the same for all regions

Por exemplo:

cassandra:
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: false
  clusterName: my-apigee-cluster

No novo centro de dados/região, antes de instalar o híbrido, defina os mesmos certificados TLS e credenciais em overrides.yaml como definiu na primeira região.
Nota: certifique-se de que usa os mesmos certificados TLS e credenciais do Cassandra no segundo centro de dados que indicou no centro de dados original. As credenciais que definir no ficheiro de substituições no primeiro centro de dados têm de corresponder às que especificar no ficheiro de substituições no segundo centro de dados. Para ver detalhes, consulte o artigo Configurar TLS para Cassandra.

Configure a nova região

Depois de configurar o anfitrião inicial, pode configurar a nova região.

Para configurar a nova 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 namespace -o yaml > apigee-namespace.yaml
```
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o "namespace" no ficheiro se estiver a usar um namespace diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instale o híbrido na nova região. Certifique-se de que o ficheiro overrides-DC_name.yaml inclui os mesmos certificados TLS que estão configurados na primeira região, conforme explicado na secção anterior.
Execute os dois comandos seguintes para instalar o híbrido na nova região:

Importante: quando expandir o Apigee hybrid para um novo centro de dados regional, certifique-se de que instala a mesma versão do hybrid que tem no seu centro de dados existente. Evite executar diferentes versões do híbrido em vários centros de dados.
```
apigeectl init -f overrides/overrides-DC_name.yaml
```
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```
Verifique se a instalação híbrida foi bem-sucedida executando o seguinte comando:
```
apigeectl check-ready -f overrides_DC_name.yaml
```

Valide a configuração do cluster do Cassandra executando o seguinte comando. O resultado deve mostrar os centros de dados existentes e novos.

kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u 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.

Obtenha o apigeeorg do cluster com o seguinte comando:

kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"

Por exemplo:

Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
"rg-hybrid-b7d3b9c"

Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.
O ficheiro tem de conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
Onde:
- REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
- NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
- APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
- SOURCE_REGION é 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"
```
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 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
}

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

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

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

O exemplo seguinte mostra entradas de registo de exemplo:

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

Atualize os anfitriões iniciais. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e volte a aplicá-lo.
Nota: os anfitriões iniciais são membros do cluster local. Para iniciar uma nova região, é necessário um anfitrião de origem externo. Assim que uma região for iniciada, tem de alterar os anfitriões de origem novamente para os respetivos clusters locais em overrides.yaml e, em seguida, voltar a aplicar a configuração.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Verifique o estado do cluster do Cassandra

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

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

No ficheiro overrides.yaml do cluster original, certifique-se de que cassandra:hostNetwork está definido como true. Por exemplo:
```
cassandra:
  hostNetwork: true
```
Consulte a secção Pré-requisitos para mais informações sobre quando definir hostNetwork: true.
Se o valor de cassandra:hostNetwork não estiver definido como true, faça o seguinte:
1. Alterar cassandra.hostNetwork para true.
2. Aplique o ficheiro de configuração overrides.yaml com o comando:
```
  apigeectl apply -f overrides.yaml --datastore
  
```
3. Aguarde que os pods do Cassandra concluam um reinício contínuo.
4. Verifique se o cluster do Cassandra está em bom estado com os seguintes comandos:
```
  kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
  
```
```
  nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
  
```
  Certifique-se de que todos os nós do Cassandra na saída estão no estado UN (Ativado/Normal):
```
  nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
  
```
  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.
  
  Certifique-se de que não existem nós inacessíveis listados no resultado.
Defina o contexto do kubectl para o cluster original antes de obter o nome da semente:
```
kubectl config use-context original-cluster-name
```

Execute o seguinte comando kubectl para identificar um endereço de anfitrião inicial para o Cassandra na região atual.

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

Decida qual dos IPs devolvidos pelo comando anterior vai ser o anfitrião principal de várias regiões.

No centro de dados 2, configure cassandra.multiRegionSeedHost no ficheiro de substituições, em que multiRegionSeedHost é um dos IPs devolvidos pelo comando anterior:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
    clusterName: cluster_name # must be the same for all regions

Por exemplo:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  rack: "ra-1"
  clusterName: my-apigee-cluster

No novo centro de dados/região, antes de instalar o híbrido, defina os mesmos certificados TLS e credenciais em overrides.yaml como definiu na primeira região.
Nota: certifique-se de que usa os mesmos certificados TLS e credenciais do Cassandra no segundo centro de dados que indicou no centro de dados original. As credenciais que definir no ficheiro de substituições no primeiro centro de dados têm de corresponder às que especificar no ficheiro de substituições no segundo centro de dados. Para ver detalhes, consulte o artigo Configurar TLS para Cassandra.

Configure a nova região

Depois de configurar o anfitrião inicial, pode configurar a nova região.

Para configurar a nova 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 namespace -o yaml > apigee-namespace.yaml
```
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o "namespace" no ficheiro se estiver a usar um namespace diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instale o híbrido na nova região. Certifique-se de que o ficheiro overrides-DC_name.yaml inclui os mesmos certificados TLS que estão configurados na primeira região, conforme explicado na secção anterior.
Execute os dois comandos seguintes para instalar o híbrido na nova região:

Importante: quando expandir o Apigee hybrid para um novo centro de dados regional, certifique-se de que instala a mesma versão do hybrid que tem no seu centro de dados existente. Evite executar diferentes versões do híbrido em vários centros de dados.
```
apigeectl init -f overrides/overrides-DC_name.yaml
```
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```
Verifique se a instalação híbrida foi bem-sucedida executando o seguinte comando:
```
apigeectl check-ready -f overrides_DC_name.yaml
```

Valide a configuração do cluster do Cassandra executando o seguinte comando. O resultado deve mostrar os centros de dados existentes e novos.

kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u 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.

Obtenha o apigeeorg do cluster com o seguinte comando:

kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"

Por exemplo:

Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
"rg-hybrid-b7d3b9c"

Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.
O ficheiro tem de conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
Onde:
- REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
- NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
- APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
- SOURCE_REGION é 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"
```
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 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
}

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

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

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

O exemplo seguinte mostra entradas de registo de exemplo:

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

Atualize os anfitriões iniciais. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e volte a aplicá-lo.
Nota: os anfitriões iniciais são membros do cluster local. Para iniciar uma nova região, é necessário um anfitrião de origem externo. Assim que uma região for iniciada, tem de alterar os anfitriões de origem novamente para os respetivos clusters locais em overrides.yaml e, em seguida, voltar a aplicar a configuração.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Verifique o estado do cluster do Cassandra

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

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

No ficheiro overrides.yaml do cluster original, certifique-se de que cassandra:hostNetwork está definido como true. Por exemplo:
```
cassandra:
  hostNetwork: true
```
Consulte a secção Pré-requisitos para mais informações sobre quando definir hostNetwork: true.
Se o valor de cassandra:hostNetwork não estiver definido como true, faça o seguinte:
1. Alterar cassandra.hostNetwork para true.
2. Aplique o ficheiro de configuração overrides.yaml com o comando:
```
  apigeectl apply -f overrides.yaml --datastore
  
```
3. Aguarde que os pods do Cassandra concluam um reinício contínuo.
4. Verifique se o cluster do Cassandra está em bom estado com os seguintes comandos:
```
  kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
  
```
```
  nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
  
```
  Certifique-se de que todos os nós do Cassandra na saída estão no estado UN (Ativado/Normal):
```
  nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
  
```
  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.
  
  Certifique-se de que não existem nós inacessíveis listados no resultado.
Defina o contexto do kubectl para o cluster original antes de obter o nome da semente:
```
kubectl config use-context original-cluster-name
```
Execute o seguinte comando kubectl para identificar um endereço de anfitrião inicial para o Cassandra na região atual.

Um endereço de anfitrião inicial permite que uma nova instância regional encontre o cluster original no primeiro arranque para saber a topologia do cluster. O endereço do anfitrião inicial é designado como o ponto de contacto no cluster.
```
kubectl get pods -o wide -n apigee -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
```
Decida qual dos IPs devolvidos pelo comando anterior vai ser o anfitrião principal de várias regiões. Neste exemplo, em que apenas está em execução um cluster cassandra de nó único, o anfitrião de sementes é 120.38.1.9.
No centro de dados 2, copie o ficheiro de substituições para um novo ficheiro cujo nome inclua o nome do cluster. Por exemplo, overrides_your_cluster_name.yaml.

No centro de dados 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em overrides_your_cluster_name.yaml, onde multiRegionSeedHost é um dos IPs devolvidos pelo comando anterior:

cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name
     hostNetwork: true
     clusterName: cluster_name # must be the same for all regions

Por exemplo:

cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "centralus"
  rack: "ra-1"
  hostNetwork: true
  clusterName: my-apigee-cluster

No novo centro de dados/região, antes de instalar o híbrido, defina os mesmos certificados TLS e credenciais em overrides_your_cluster_name.yaml como definiu na primeira região.
Nota: certifique-se de que usa os mesmos certificados TLS e credenciais do Cassandra no segundo centro de dados que indicou no centro de dados original. As credenciais que definir no ficheiro de substituições no primeiro centro de dados têm de corresponder às que especificar no ficheiro de substituições no segundo centro de dados. Para ver detalhes, consulte o artigo Configurar TLS para Cassandra.

Configure a nova região

Depois de configurar o anfitrião inicial, pode configurar a nova região.

Para configurar a nova 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 namespace -o yaml > apigee-namespace.yaml
```
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o "namespace" no ficheiro se estiver a usar um namespace diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instale o híbrido na nova região. Certifique-se de que o ficheiro overrides_your_cluster_name.yaml inclui os mesmos certificados TLS que estão configurados na primeira região, conforme explicado na secção anterior.
Execute os dois comandos seguintes para instalar o híbrido na nova região:

Importante: quando expandir o Apigee hybrid para um novo centro de dados regional, certifique-se de que instala a mesma versão do hybrid que tem no seu centro de dados existente. Evite executar diferentes versões do híbrido em vários centros de dados.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Verifique se a instalação híbrida foi bem-sucedida executando o seguinte comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Valide a configuração do cluster do Cassandra executando o seguinte comando. O resultado deve mostrar os centros de dados existentes e novos.

kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u 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.

Obtenha o apigeeorg do cluster com o seguinte comando:

kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"

Por exemplo:

Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
"rg-hybrid-b7d3b9c"

Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.
O ficheiro tem de conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
Onde:
- REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
- NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
- APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
- SOURCE_REGION é 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"
```
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 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
}

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

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

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

O exemplo seguinte mostra entradas de registo de exemplo:

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

Atualize os anfitriões iniciais. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e volte a aplicá-lo.
Nota: os anfitriões iniciais são membros do cluster local. Para iniciar uma nova região, é necessário um anfitrião de origem externo. Assim que uma região for iniciada, tem de alterar os anfitriões de origem novamente para os respetivos clusters locais em overrides.yaml e, em seguida, voltar a aplicar a configuração.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Verifique o estado do cluster do Cassandra

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

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

No ficheiro overrides.yaml do cluster original, certifique-se de que cassandra:hostNetwork está definido como true. Por exemplo:
```
cassandra:
  hostNetwork: true
```
Consulte a secção Pré-requisitos para mais informações sobre quando definir hostNetwork: true.
Se o valor de cassandra:hostNetwork não estiver definido como true, faça o seguinte:
1. Alterar cassandra.hostNetwork para true.
2. Aplique o ficheiro de configuração overrides.yaml com o comando:
```
  apigeectl apply -f overrides.yaml --datastore
  
```
3. Aguarde que os pods do Cassandra concluam um reinício contínuo.
4. Verifique se o cluster do Cassandra está em bom estado com os seguintes comandos:
```
  kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
  
```
```
  nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
  
```
  Certifique-se de que todos os nós do Cassandra na saída estão no estado UN (Ativado/Normal):
```
  nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD describecluster
  
```
  Certifique-se de que não existem nós inacessíveis listados no resultado.
Defina o contexto do kubectl para o cluster original antes de obter o nome da semente:
```
kubectl config use-context original-cluster-name
```
Execute o seguinte comando kubectl para identificar um endereço de anfitrião inicial para o Cassandra na região atual.

Um endereço de anfitrião inicial permite que uma nova instância regional encontre o cluster original no primeiro arranque para saber a topologia do cluster. O endereço do anfitrião inicial é designado como o ponto de contacto no cluster.
```
kubectl get pods -o wide -n apigee | grep apigee-cassandra
```
```
apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
```
Decida qual dos IPs devolvidos pelo comando anterior vai ser o anfitrião principal de várias regiões. Neste exemplo, em que apenas está em execução um cluster cassandra de nó único, o anfitrião de sementes é 120.38.1.9.
No centro de dados 2, copie o ficheiro de substituições para um novo ficheiro cujo nome inclua o nome do cluster. Por exemplo, overrides_your_cluster_name.yaml.

cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name
     hostNetwork: true
     clusterName: cluster_name # must be the same for all regions

Por exemplo:

cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "centralus"
  rack: "ra-1"
  hostNetwork: true
  clusterName: my-apigee-cluster

No novo centro de dados/região, antes de instalar o híbrido, defina os mesmos certificados TLS e credenciais em overrides_your_cluster_name.yaml como definiu na primeira região.
Nota: certifique-se de que usa os mesmos certificados TLS e credenciais do Cassandra no segundo centro de dados que indicou no centro de dados original. As credenciais que definir no ficheiro de substituições no primeiro centro de dados têm de corresponder às que especificar no ficheiro de substituições no segundo centro de dados. Para ver detalhes, consulte o artigo Configurar TLS para Cassandra.

Configure a nova região

Depois de configurar o anfitrião inicial, pode configurar a nova região.

Para configurar a nova 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 namespace -o yaml > apigee-namespace.yaml
```
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o "namespace" no ficheiro se estiver a usar um namespace diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instale o híbrido na nova região. Certifique-se de que o ficheiro overrides_your_cluster_name.yaml inclui os mesmos certificados TLS que estão configurados na primeira região, conforme explicado na secção anterior.
Execute os dois comandos seguintes para instalar o híbrido na nova região:

Importante: quando expandir o Apigee hybrid para um novo centro de dados regional, certifique-se de que instala a mesma versão do hybrid que tem no seu centro de dados existente. Evite executar diferentes versões do híbrido em vários centros de dados.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Verifique se a instalação híbrida foi bem-sucedida executando o seguinte comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Valide a configuração do cluster do Cassandra executando o seguinte comando. O resultado deve mostrar os centros de dados existentes e novos.

kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u JMX_user -pw JMX_password status

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

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

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

Configure o Cassandra em todos os pods nos novos centros de dados.

Obtenha o apigeeorg do cluster com o seguinte comando:

kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name

Por exemplo:

Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"

Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.
O ficheiro tem de conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
Onde:
- REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
- NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
- APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
- SOURCE_REGION é 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"
```
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 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
}

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

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

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

O exemplo seguinte mostra entradas de registo de exemplo:

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

Atualize os anfitriões iniciais. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e volte a aplicar.
Nota: os anfitriões iniciais são membros do cluster local. Para iniciar uma nova região, é necessário um anfitrião de origem externo. Assim que uma região for iniciada, tem de alterar os anfitriões de origem novamente para os respetivos clusters locais em overrides.yaml e, em seguida, voltar a aplicar a configuração.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Verifique o estado do cluster do Cassandra

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

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: 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

Configure o anfitrião de origem multirregião

No ficheiro overrides.yaml do cluster original, certifique-se de que cassandra:hostNetwork está definido como true. Por exemplo:
```
cassandra:
  hostNetwork: true
```
Consulte a secção Pré-requisitos para mais informações sobre quando definir hostNetwork: true.
Se o valor de cassandra:hostNetwork não estiver definido como true, faça o seguinte:
1. Alterar cassandra.hostNetwork para true.
2. Aplique o ficheiro de configuração overrides.yaml com o comando:
```
  apigeectl apply -f overrides.yaml --datastore
  
```
3. Aguarde que os pods do Cassandra concluam um reinício contínuo.
4. Verifique se o cluster do Cassandra está em bom estado com os seguintes comandos:
```
  kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
  
```
```
  nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
  
```
  Certifique-se de que todos os nós do Cassandra na saída estão no estado UN (Ativado/Normal):
```
  nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
  
```
  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.
  
  Certifique-se de que não existem nós inacessíveis listados no resultado.
Defina o contexto do kubectl para o cluster original antes de obter o nome da semente:
```
kubectl config use-context original-cluster-name
```

Execute o seguinte comando kubectl para identificar um endereço de anfitrião inicial para o Cassandra na região atual.

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

Selecione o endereço IP do anfitrião do Cassandra de origem para usar como anfitrião de semente de várias regiões. Neste exemplo, o cluster apigee-cassandra-default-0está em execução e o anfitrião inicial é 10.0.0.11.
No centro de dados 2, copie o ficheiro de substituições para um novo ficheiro cujo nome inclua o nome do cluster. Por exemplo, overrides_your_cluster_name.yaml.

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

Por exemplo:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  rack: "ra-1"
  clusterName: my-apigee-cluster

No novo centro de dados/região, antes de instalar o híbrido, defina os mesmos certificados TLS e credenciais em overrides_your_cluster_name.yaml como definiu na primeira região.
Nota: certifique-se de que usa os mesmos certificados TLS e credenciais do Cassandra no segundo centro de dados que indicou no centro de dados original. As credenciais que definir no ficheiro de substituições no primeiro centro de dados têm de corresponder às que especificar no ficheiro de substituições no segundo centro de dados. Para ver detalhes, consulte o artigo Configurar TLS para Cassandra.

Configure a nova região

Depois de configurar o anfitrião inicial, pode configurar a nova região.

Para configurar a nova 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 namespace -o yaml > apigee-namespace.yaml
```
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o "namespace" no ficheiro se estiver a usar um namespace diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instale o híbrido na nova região. Certifique-se de que o ficheiro overrides_your_cluster_name.yaml inclui os mesmos certificados TLS que estão configurados na primeira região, conforme explicado na secção anterior.
Execute os dois comandos seguintes para instalar o híbrido na nova região:

Importante: quando expandir o Apigee hybrid para um novo centro de dados regional, certifique-se de que instala a mesma versão do hybrid que tem no seu centro de dados existente. Evite executar diferentes versões do híbrido em vários centros de dados.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Verifique se a instalação híbrida foi bem-sucedida executando o seguinte comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Valide a configuração do cluster do Cassandra executando o seguinte comando. O resultado deve mostrar os centros de dados existentes e novos.

kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u 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.

Obtenha o apigeeorg do cluster com o seguinte comando:

kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"

Por exemplo:

Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
"rg-hybrid-b7d3b9c"

Crie um ficheiro de recurso personalizado de replicação de dados do Cassandra (YAML). O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml.
O ficheiro tem de conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
Onde:
- REGION_EXPANSION é o nome que está a dar a estes metadados. Pode usar qualquer nome.
- NAMESPACE é o mesmo espaço de nomes fornecido em overrides.yaml. Normalmente, é "apigee".
- APIGEEORG_VALUE é o valor apresentado pelo comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" no passo anterior. Por exemplo, rg-hybrid-b7d3b9c
- SOURCE_REGION é 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"
```
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 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
}

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

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

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

O exemplo seguinte mostra entradas de registo de exemplo:

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

Atualize os anfitriões iniciais. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e volte a aplicá-lo.
Nota: os anfitriões iniciais são membros do cluster local. Para iniciar uma nova região, é necessário um anfitrião de origem externo. Assim que uma região for iniciada, tem de alterar os anfitriões de origem novamente para os respetivos clusters locais em overrides.yaml e, em seguida, voltar a aplicar a configuração.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Verifique o estado do cluster do Cassandra

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

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u 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 nova região

Verifique o estado do cluster do Cassandra

GKE On-Prem

Configure o anfitrião de origem multirregião

Configure a nova 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 nova 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 nova região

Verifique o estado do cluster do Cassandra

OpenShift

Configure o anfitrião de origem multirregião

Configure a nova região

Verifique o estado do cluster do Cassandra

Resolução de problemas

Implementação em várias regiões