Esta página foi traduzida pela API Cloud Translation.

Implementação multirregional no AKS

Este tópico explica como configurar uma implementação em várias regiões para o Apigee hybrid no Microsoft® Azure Kubernetes Service (AKS).

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 de 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:

Pré-requisitos

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

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.
Requisitos da Cassandra Multi Region:
- Se o espaço de nomes da rede do pod não tiver conetividade entre pods em clusters diferentes (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 sua instalação multirregiões do Apigee Hybrid.
- Ative a opção hostNetwork nos clusters existentes antes de expandir a sua configuração multirregional para novas regiões.
- Quando hostNetwork está ativado, certifique-se de que os nós de trabalho podem realizar uma procura de DNS inverso. O Apigee Cassandra usa a pesquisa de DNS direta e inversa 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 7000 e 7001 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 Configure portas.

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

Crie uma rede virtual em cada região

Siga a documentação do Serviço de Kubernetes do Azure (AKS) para:

Crie uma rede virtual em cada região.
Estabeleça o intercâmbio de rede entre as regiões.
Valide o peering de rede.

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 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões (7000 pode ser usado como uma opção de cópia de segurança durante a resolução de problemas)

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 | 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.
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
```
Por exemplo:
```
cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "dc-1"
  rack: "ra-1"
```
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 que definiu na primeira região.
NOTA: certifique-se de que usa as mesmas credenciais e certificados TLS 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 o 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 apigee -o yaml > apigee-namespace.yaml
```
  apigee é o espaço de nomes predefinido.
3. Exporte o segredo apigee-ca para um ficheiro:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do espaço de nomes para o novo cluster. Certifique-se de que atualiza o "espaço de nomes" no ficheiro se estiver a usar um espaço de nomes diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o segredo para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
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:
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Executar nodetool rebuild sequencialmente em todos os nós no novo centro de dados. Este processo pode demorar alguns minutos a algumas horas, consoante o tamanho dos dados.
```
kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1
```
Onde JMX_user e JMX_password são o nome de utilizador e a palavra-passe do utilizador do JMX do Cassandra.

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 aplicá-lo.
Os anfitriões iniciais são membros do cluster local. Para iniciar uma nova região, é necessário um anfitrião de origem externo. Depois de uma região ser iniciada, tem de alterar os anfitriões iniciais novamente para os respetivos clusters locais em overrides.yaml e, em seguida, voltar a aplicar a configuração.
```
apigeectl apply -f overrides-DC_name.yaml
```