English
Deutsch
Español – América Latina
Français
Indonesia
Italiano
Português – Brasil
中文 – 简体
日本語
한국어

Entre em contato Comece gratuitamente

Implantação multirregional

Neste tópico, descrevemos uma implantação de várias regiões para a Apigee híbrida no GKE, o Anthos GKE implantado no local, RedHat OpenShift e no Microsoft® Azure Kubernetes Service (AKS). Selecione sua plataforma nos pré-requisitos e procedimentos.

As topologias para implantação de várias regiões incluem:

Ativo-Ativo: quando você tem aplicativos implantados em vários locais geográficos e requer uma resposta de baixa latência da API para suas implantações. Você tem a opção de implantar a Apigee híbrida em várias localizações geográficas mais próximas de seus clientes. Por exemplo: Costa Oeste dos EUA, Costa Leste dos EUA, Europa, APAC.
Ativo-Passivo: quando você tem uma região principal e uma região de recuperação de desastres ou failover.

As regiões em uma implantação híbrida multirregional se comunicam por meio do Cassandra, como mostrado na imagem a seguir:

Pré-requisitos

GKE

Antes de configurar o híbridos para várias regiões, é preciso atender aos seguintes pré-requisitos:

Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR.
Configurar a comunicação entre regiões
Requisitos da multirregião Cassandra:
- Verifique se o namespace da rede do pod tem conectividade entre as regiões, incluindo firewalls, vpn, peering vpc e vNet. Esse é o caso da maioria das instalações do GKE.
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters estão sendo executados no "modo de rede ilha"), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.
  Para informações sobre o recurso hostNetwork do Kubernetes, consulte Namespaces do host na documentação do Kubernetes.
- Ative hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
- Quando hostNetwork estiver ativado, verifique se os nós de trabalho podem realizar a busca DNS reversa. A Apigee cassandra usa busca DNS reversa e direta para conseguir o IP do host ao iniciar.
  Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.
  Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho cassandra semelhante ao seguinte:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  ou
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho entre regiões e data centers se comuniquem. Consulte Configurar portas.

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

GKE On-Prem

Antes de configurar o híbridos para várias regiões, é preciso atender aos seguintes pré-requisitos:

Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR.
Configurar a comunicação entre regiões
Requisitos da multirregião Cassandra:
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters estão sendo executados no "modo de rede ilha", o caso padrão nas instalações do GKE On-Prem), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.
  Para informações sobre o recurso hostNetwork do Kubernetes, consulte Namespaces do host na documentação do Kubernetes.
- Ative hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
- Quando hostNetwork estiver ativado, verifique se os nós de trabalho podem realizar a busca DNS reversa. A Apigee cassandra usa busca DNS reversa e direta para conseguir o IP do host ao iniciar.
  Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.
  Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho cassandra semelhante ao seguinte:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  ou
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho entre regiões e data centers se comuniquem. Consulte Configurar portas.

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

AKS

Antes de configurar o híbridos para várias regiões, é preciso atender aos seguintes pré-requisitos:

Siga o guia de instalação híbrida para pré-requisitos como o Google Cloud e a configuração organizacional antes de passar para as etapas de configuração do cluster.
Requisitos da multirregião Cassandra:
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters estão sendo executados no "modo de rede ilha", o caso padrão em instalações AKS), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.
  Para informações sobre o recurso hostNetwork do Kubernetes, consulte Namespaces do host na documentação do Kubernetes.
- Ative hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
- Quando hostNetwork estiver ativado, verifique se os nós de trabalho podem realizar a busca DNS reversa. A Apigee cassandra usa busca DNS reversa e direta para conseguir o IP do host ao iniciar.
  Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.
  Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho cassandra semelhante ao seguinte:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  ou
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho entre regiões e data centers se comuniquem. Consulte Configurar portas.

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

EKS

Antes de configurar o híbridos para várias regiões, é preciso atender aos seguintes pré-requisitos:

Siga o guia de instalação híbrida para pré-requisitos como o Google Cloud e a configuração organizacional antes de passar para as etapas de configuração do cluster.
Requisitos da multirregião Cassandra:
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters estão sendo executados no "modo de rede ilha", o caso padrão em instalações EKS), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.
  Para informações sobre o recurso hostNetwork do Kubernetes, consulte Namespaces do host na documentação do Kubernetes.
- Ative hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
- Quando hostNetwork estiver ativado, verifique se os nós de trabalho podem realizar a busca DNS reversa. A Apigee cassandra usa busca DNS reversa e direta para conseguir o IP do host ao iniciar.
  Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.
  Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho cassandra semelhante ao seguinte:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  ou
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho entre regiões e data centers se comuniquem. Consulte Configurar portas.

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

OpenShift

Antes de configurar o híbridos para várias regiões, é preciso atender aos seguintes pré-requisitos:

Siga o guia de instalação híbrida para pré-requisitos como o Google Cloud e a configuração organizacional antes de passar para as etapas de configuração do cluster.
Requisitos da multirregião Cassandra:
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters estão sendo executados no "modo de rede de ilha", o caso padrão nas instalações do OpenShift), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.
  Para informações sobre o recurso hostNetwork do Kubernetes, consulte Namespaces do host na documentação do Kubernetes.
- Ative hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
- Quando hostNetwork estiver ativado, verifique se os nós de trabalho podem realizar a busca DNS reversa. A Apigee cassandra usa busca DNS reversa e direta para conseguir o IP do host ao iniciar.
  Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.
  Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho cassandra semelhante ao seguinte:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  ou
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho entre regiões e data centers se comuniquem. Consulte Configurar portas.

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

Configurar o híbrido da Apigee para multirregião

GKE

Configurar o host de propagação multirregional

Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.

Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação:
```
kubectl config use-context original-cluster-name
```

Execute o comando kubectl a seguir para identificar um endereço do host de propagação do Cassandra na região atual.

Um endereço de host de propagação permite que uma nova instância regional encontre o cluster original na primeira inicialização para aprender a topologia do cluster. O endereço do host de propagação é designado como o ponto de contato no cluster.

kubectl get pods -o wide -n apigee

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 quais dos IPs retornados do comando anterior serão o host de propagação multirregional.

No data center 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em Gerenciar componentes do plano de execução, em que multiRegionSeedHost é um dos IPs retornados pelo comando anterior:

cassandra:
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
  hostNetwork: false

Exemplo:

cassandra:
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: false

No novo data center/região, antes de instalar a Apigee híbrida, defina os mesmos certificados e credenciais TLS em overrides_your_cluster_name.yaml, conforme definido na primeira região.
OBSERVAÇÃO: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

Configurar a nova região

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

Para configurar a nova região:

Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
1. Defina o contexto como o namespace original:
```
kubectl config use-context original-cluster-name
```
2. Exporte a configuração atual do namespace para um arquivo:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exporte o secret apigee-ca para um arquivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o secret para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides_your_cluster_name.yaml inclua os mesmos certificados TLS configurados na primeira região, conforme explicado na seção anterior.
Execute os dois comandos a seguir para instalar a Apigee híbrida na nova região:

Importante: ao expandir o Apigee híbrido para um novo data center regional, instale a mesma versão do data center existente. Evite executar versões diferentes de implementações híbridas em diversos data centers.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Para verificar se a instalação híbrida foi bem-sucedida, execute o seguinte comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos e atuais.

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

Exemplo de configuração concluída:

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

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

Configurar o Cassandra em todos os pods nos novos data centers.

Receba apigeeorg do cluster com o seguinte comando:

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

Exemplo:

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

Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (YAML). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nome datareplication.yaml.
O arquivo deve conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
Em que:
- REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
- NAMESPACE é o mesmo namespace fornecido em overrides.yaml. Geralmente é "apigee".
- APIGEEORG_VALUE é a saída de valor do comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name na etapa anterior. Por exemplo, rg-hybrid-b7d3b9c
- SOURCE_REGION é o nome do data center na região de origem. Esse é o valor definido para cassandra:datacenter: no overrides.yaml.
Exemplo:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
Aplique o CassandraDataReplication com o seguinte comando:
```
kubectl apply -f datareplication.yaml
```

Verifique o status de recriação usando o comando a seguir.

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

Os resultados terão esta aparência:

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

Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status:

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

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

O exemplo a seguir mostra entradas de registro de exemplo:

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

Atualize os hosts de propagação. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e aplique novamente.
Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Verificar o status do cluster do Cassandra

O comando a seguir é útil para conferir se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das duas regiões.

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


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

GKE On-Prem

Configurar o host de propagação multirregional

Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.

No arquivo overrides.yaml do cluster original, verifique se cassandra:hostNetwork está definido como true. Por exemplo:
```
cassandra:
  hostNetwork: true
```
Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação:
```
kubectl config use-context original-cluster-name
```

Execute o comando kubectl a seguir para identificar um endereço do host de propagação do Cassandra na região atual.

Um endereço de host de propagação permite que uma nova instância regional encontre o cluster original na primeira inicialização para aprender a topologia do cluster. O endereço do host de propagação é designado como o ponto de contato no cluster.

kubectl get pods -o wide -n apigee

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 quais dos IPs retornados do comando anterior serão o host de propagação multirregional.

No data center 2, configure cassandra.multiRegionSeedHost no arquivo de modificações, em que multiRegionSeedHost é um dos IPs retornados pelo comando anterior:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name

Exemplo:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"

No novo data center/região, antes de instalar a Apigee híbrida, defina os mesmos certificados e credenciais TLS em overrides_your_cluster_name.yaml, conforme definido na primeira região.
OBSERVAÇÃO: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

Configurar a nova região

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

Para configurar a nova região:

Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
1. Defina o contexto como o namespace original:
```
kubectl config use-context original-cluster-name
```
2. Exporte a configuração atual do namespace para um arquivo:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exporte o secret apigee-ca para um arquivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o secret para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides_your_cluster_name.yaml inclua os mesmos certificados TLS configurados na primeira região, conforme explicado na seção anterior.
Execute os dois comandos a seguir para instalar a Apigee híbrida na nova região:

Importante: ao expandir o Apigee híbrido para um novo data center regional, instale a mesma versão do data center existente. Evite executar versões diferentes de implementações híbridas em diversos data centers.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Para verificar se a instalação híbrida foi bem-sucedida, execute o seguinte comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos e atuais.

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

Exemplo de configuração concluída:

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

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

Configurar o Cassandra em todos os pods nos novos data centers.

Receba apigeeorg do cluster com o seguinte comando:

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

Exemplo:

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

Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (YAML). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nome datareplication.yaml.
O arquivo deve conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
Em que:
- REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
- NAMESPACE é o mesmo namespace fornecido em overrides.yaml. Geralmente é "apigee".
- APIGEEORG_VALUE é a saída de valor do comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name na etapa anterior. Por exemplo, rg-hybrid-b7d3b9c
- SOURCE_REGION é o nome do data center na região de origem. Esse é o valor definido para cassandra:datacenter: no overrides.yaml.
Exemplo:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
Aplique o CassandraDataReplication com o seguinte comando:
```
kubectl apply -f datareplication.yaml
```

Verifique o status de recriação usando o comando a seguir.

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

Os resultados terão esta aparência:

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

Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status:

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

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

O exemplo a seguir mostra entradas de registro de exemplo:

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

Atualize os hosts de propagação. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e aplique novamente.
Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Verificar o status do cluster do Cassandra

O comando a seguir é útil para conferir se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das duas regiões.

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


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

AKS

Criar uma rede virtual em cada região

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

Criar clusters multirregionais

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

Abra as portas 7000 e 7001 do Cassandra entre os clusters do Kubernetes em todas as regiões (7000 pode ser usada como opção de backup durante uma solução de problemas)

Configurar o host de propagação multirregional

Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.

No arquivo overrides.yaml do cluster original, verifique se cassandra:hostNetwork está definido como true. Por exemplo:
```
cassandra:
  hostNetwork: true
```
Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação:
```
kubectl config use-context original-cluster-name
```
Execute o comando kubectl a seguir para identificar um endereço do host de propagação do Cassandra na região atual.

Um endereço de host de propagação permite que uma nova instância regional encontre o cluster original na primeira inicialização para aprender a topologia do cluster. O endereço do host de propagação é designado como o ponto de contato no cluster.
```
kubectl get pods -o wide -n apigee | grep apigee-cassandra
```
```
apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
```
Decida quais dos IPs retornados do comando anterior serão o host de propagação multirregional. Neste exemplo, em que apenas um cluster do Cassandra está sendo executado, o host de propagação é 120.38.1.9.
No data center 2, copie o arquivo de modificações para um novo arquivo com o nome do cluster. Por exemplo: overrides_your_cluster_name.yaml

No data center 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em overrides_your_cluster_name.yaml, em que multiRegionSeedHost é um dos IPs retornados pelo comando anterior:

cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name
     hostNetwork: true

Exemplo:

cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: true

No novo data center/região, antes de instalar a Apigee híbrida, defina os mesmos certificados e credenciais TLS em overrides_your_cluster_name.yaml, conforme definido na primeira região.
OBSERVAÇÃO: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

Configurar a nova região

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

Para configurar a nova região:

Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
1. Defina o contexto como o namespace original:
```
kubectl config use-context original-cluster-name
```
2. Exporte a configuração atual do namespace para um arquivo:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exporte o secret apigee-ca para um arquivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o secret para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides_your_cluster_name.yaml inclua os mesmos certificados TLS configurados na primeira região, conforme explicado na seção anterior.
Execute os dois comandos a seguir para instalar a Apigee híbrida na nova região:

Importante: ao expandir o Apigee híbrido para um novo data center regional, instale a mesma versão do data center existente. Evite executar versões diferentes de implementações híbridas em diversos data centers.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Para verificar se a instalação híbrida foi bem-sucedida, execute o seguinte comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos e atuais.

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

Exemplo de configuração concluída:

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

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

Configurar o Cassandra em todos os pods nos novos data centers.

Receba apigeeorg do cluster com o seguinte comando:

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

Exemplo:

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

Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (YAML). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nome datareplication.yaml.
O arquivo deve conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
Em que:
- REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
- NAMESPACE é o mesmo namespace fornecido em overrides.yaml. Geralmente é "apigee".
- APIGEEORG_VALUE é a saída de valor do comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name na etapa anterior. Por exemplo, rg-hybrid-b7d3b9c
- SOURCE_REGION é o nome do data center na região de origem. Esse é o valor definido para cassandra:datacenter: no overrides.yaml.
Exemplo:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
Aplique o CassandraDataReplication com o seguinte comando:
```
kubectl apply -f datareplication.yaml
```

Verifique o status de recriação usando o comando a seguir.

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

Os resultados terão esta aparência:

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

Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status:

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

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

O exemplo a seguir mostra entradas de registro de exemplo:

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

Atualize os hosts de propagação. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e aplique novamente.
Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Verificar o status do cluster do Cassandra

O comando a seguir é útil para conferir se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das duas regiões.

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


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

OpenShift

Configurar o host de propagação multirregional

Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.

No arquivo overrides.yaml do cluster original, verifique se cassandra:hostNetwork está definido como true. Por exemplo:
```
cassandra:
  hostNetwork: true
```
Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação:
```
kubectl config use-context original-cluster-name
```

Execute o comando kubectl a seguir para identificar um endereço do host de propagação do Cassandra na região atual.

Um endereço de host de propagação permite que uma nova instância regional encontre o cluster original na primeira inicialização para aprender a topologia do cluster. O endereço do host de propagação é designado como o ponto de contato no cluster.

kubectl get pods -o wide -n apigee

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 host de origem do Cassandra para ser usado como host de origem multirregional. Neste exemplo, este é o apigee-cassandra-default-0cluster em execução, o host de origem é 10.0.0.11.
No data center 2, copie o arquivo de modificações para um novo arquivo com o nome do cluster. Por exemplo: overrides_your_cluster_name.yaml

No data center 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em overrides_your_cluster_name.yaml, em que multiRegionSeedHost é um dos IPs retornados pelo comando anterior:

cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP # Cassandra pod IP address from the source region.
     datacenter: data_center_name

Exemplo:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"

No novo data center/região, antes de instalar a Apigee híbrida, defina os mesmos certificados e credenciais TLS em overrides_your_cluster_name.yaml, conforme definido na primeira região.
OBSERVAÇÃO: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

Configurar a nova região

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

Para configurar a nova região:

Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
1. Defina o contexto como o namespace original:
```
kubectl config use-context original-cluster-name
```
2. Exporte a configuração atual do namespace para um arquivo:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exporte o secret apigee-ca para um arquivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o secret para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides_your_cluster_name.yaml inclua os mesmos certificados TLS configurados na primeira região, conforme explicado na seção anterior.
Execute os dois comandos a seguir para instalar a Apigee híbrida na nova região:

Importante: ao expandir o Apigee híbrido para um novo data center regional, instale a mesma versão do data center existente. Evite executar versões diferentes de implementações híbridas em diversos data centers.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Para verificar se a instalação híbrida foi bem-sucedida, execute o seguinte comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos e atuais.

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

Exemplo de configuração concluída:

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

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

Configurar o Cassandra em todos os pods nos novos data centers.

Receba apigeeorg do cluster com o seguinte comando:

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

Exemplo:

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

Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (YAML). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nome datareplication.yaml.
O arquivo deve conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
Em que:
- REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
- NAMESPACE é o mesmo namespace fornecido em overrides.yaml. Geralmente é "apigee".
- APIGEEORG_VALUE é a saída de valor do comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name na etapa anterior. Por exemplo, rg-hybrid-b7d3b9c
- SOURCE_REGION é o nome do data center na região de origem. Esse é o valor definido para cassandra:datacenter: no overrides.yaml.
Exemplo:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
Aplique o CassandraDataReplication com o seguinte comando:
```
kubectl apply -f datareplication.yaml
```

Verifique o status de recriação usando o comando a seguir.

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

Os resultados terão esta aparência:

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

Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status:

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

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

O exemplo a seguir mostra entradas de registro de exemplo:

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

Atualize os hosts de propagação. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e aplique novamente.
Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Verificar o status do cluster do Cassandra

O comando a seguir é útil para conferir se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das duas regiões.

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


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

Solução de problemas

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

Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.

Última atualização 2024-11-15 UTC.