Implantação multirregional no GKE e no GKE On-Prem

Neste tópico, descrevemos uma implantação multirregional da Apigee híbrida no GKE e no Anthos GKE implantado no local.

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:

Balanceamento de carga da conexão MART

Cada cluster regional precisa ter o próprio IP e nome de host MART. No entanto, você só precisa conectar o plano de gerenciamento a um deles. O Cassandra propaga informações para todos os clusters. A melhor opção para alta disponibilidade do MART é balancear a carga dos endereços IP MART individuais e configurar sua organização para se comunicar com o URL do MART com carga balanceada.

Pré-requisitos

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 pods em clusters diferentes (os clusters estão em execução no "modo de rede de ilha", por exemplo, em 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 da Apigee híbrida.
  Para informações sobre o recurso hostNetwork do Kubernetes, consulte Namespaces do host na documentação do Kubernetes.
- Ative o 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 do 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 do 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 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.

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.
A configuração nesta etapa depende se você está no GKE ou no GKE On-Prem:

Somente GKE: 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 # Set this to true for Non GKE platforms.
```
Exemplo:
```
cassandra:
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: false
```
Somente GKE On-Prem: no data center 2, configure cassandra.multiRegionSeedHost no seu 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.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 em overrides.yaml no primeiro data center precisam corresponder àquelas especificadas em overrides.yaml 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-DC_name.yaml inclua os mesmos certificados TLS configurados na primeira região, conforme explicado na seção anterior.
Execute os dois comandos a seguir para instalar a Apigee híbrida na nova região:
```
apigeectl init -f overrides/overrides-DC_name.yaml
```
```
apigeectl apply -f overrides/overrides-DC_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.
1. Receba apigeeorg do cluster com o seguinte comando:
```
kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
```
  Exemplo:
```
Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
```
2. Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (YAML). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nome datareplication.yaml.
  O arquivo deve conter o seguinte:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Em que:
  - REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
  - NAMESPACE é o mesmo namespace fornecido em overrides.yaml. Geralmente é "apigee".
  - APIGEEORG_VALUE é a saída de valor do comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name na etapa anterior. Por exemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION é o nome do data center na região de origem. Este é 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"
```
3. Aplique o CassandraDataReplication com o seguinte comando:
```
kubectl apply -f datareplication.yaml
```
4. Verifique o status de recriação usando o comando a seguir.
  Observação : a operação de recriação pode levar várias horas, dependendo do tamanho dos dados.
```
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
```
  Os resultados terão esta aparência:
```
{
  "rebuildDetails": {
    "apigee-cassandra-default-0": {
      "state": "complete",
      "updated": 1623105760
    },
    "apigee-cassandra-default-1": {
      "state": "complete",
      "updated": 1623105765
    },
    "apigee-cassandra-default-2": {
      "state": "complete",
      "updated": 1623105770
    }
  },
  "state": "complete",
  "updated": 1623105770
}
```

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