Questa pagina è stata tradotta dall'API Cloud Translation.

Deployment multiregionale su AKS

Questo argomento spiega come configurare un deployment multiregionale per Apigee hybrid su Microsoft® Servizio Azure Kubernetes (AKS).

Le topologie per il deployment multiregionale includono:

Attivo-Attivo: quando è stato eseguito il deployment delle applicazioni in più aree geografiche da più località e hai bisogno di una risposta API a bassa latenza per i tuoi deployment. Puoi implementare la soluzione ibrida in più località geografiche vicine ai tuoi clienti. Ad esempio: costa occidentale degli Stati Uniti, costa orientale degli Stati Uniti, Europa, APAC.
Attivo-passivo: quando hai una regione principale e una regione di failover o di ripristino di emergenza.

Le regioni in un deployment ibrido multiregionale comunicano tramite Cassandra, come mostrato nella seguente immagine:

Prerequisiti

Prima di configurare l'ambiente ibrida per più regioni, devi completare i seguenti prerequisiti:

Segui l'installazione ibrida guida per eventuali prerequisiti, come Google Cloud e la configurazione dell'organizzazione. prima di andare ai passaggi di configurazione del cluster.
Requisiti di Cassandra per più regioni:
- Se lo spazio dei nomi di rete del pod non ha connettività tra i pod in cluster diversi (i cluster sono in esecuzione in "modalità di rete a isole", la situazione predefinita nelle installazioni AKS), attiva la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file delle sostituzioni per tutte le regioni della tua installazione Apigee ibrida multi-regione.
- Attiva hostNetwork sui cluster esistenti prima di estendere la configurazione multiregione a nuove regioni.
- Se hostNetwork è abilitato, assicurati che i nodi worker possano eseguire l'inversione ricerca DNS. Apigee Cassandra utilizza sia la ricerca DNS in avanti che quella inversa per ottenere l'indirizzo IP dell'host durante l'avvio.
  Suggerimento: se la risoluzione DNS non funziona, prova questa soluzione alternativa.
  Aggiungi una voce host statica nel file /etc/hosts di ciascun nodo worker Cassandra simile al seguente:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  o
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Apri le porte Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione dei nodi worker tra regioni e data center. Vedi Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

Crea una rete virtuale in ogni regione

Segui Azure documentazione di Kubernetes Service (AKS) per:

Crea una rete virtuale in ogni regione.
Stabilisci il peering di rete tra le regioni.
Verifica il peering di rete.

Creare cluster multiregionali

Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi. Consulta: anche il Passaggio 1: crea un cluster. Utilizza le località e i nomi delle reti virtuali che hai creato in precedenza.

Apri le porte Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni (7000 può essere utilizzato come opzione di backup durante la risoluzione dei problemi)

Configura l'host seed per più regioni

Questa sezione descrive come espandere il cluster Cassandra esistente a una nuova regione. Questa configurazione consente alla nuova regione di avviare il cluster e di partecipare al data center esistente. Senza questa configurazione, i cluster Kubernetes multiregione non si conoscerebbero.

Imposta il contesto kubectl sul cluster originale prima di recuperare il nome seed:
```
kubectl config use-context original-cluster-name
```
Esegui il seguente comando kubectl per identificare un indirizzo host iniziale per Cassandra nella regione corrente.

Un indirizzo host iniziale consente a una nuova istanza regionale di trovare il cluster originale alla prima accensione per apprenderne la topologia. L'indirizzo host di origine è designato come punto di contatto nel 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
```
Decidi quale degli IP restituiti dal comando precedente sarà l'host iniziale per più regioni. In questo esempio, in cui è in esecuzione un solo cluster Cassandra a un nodo, l'host iniziale è 120.38.1.9.
Nel data center 2, copia il file delle sostituzioni in un nuovo file il cui nome include il nome del cluster. Ad esempio, overrides_your_cluster_name.yaml.
Nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in overrides_your_cluster_name.yaml, dove multiRegionSeedHost è uno degli IP restituiti dal comando precedente:
```
cassandra:
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
```
Ad esempio:
```
cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "dc-1"
  rack: "ra-1"
```
Nel nuovo data center/nella nuova regione, prima di installare l'ibrido, imposta gli stessi certificati TLS e credenziali in overrides_your_cluster_name.yaml impostate nella prima regione.
NOTA: assicurati di utilizzare gli stessi certificati e le stesse credenziali TLS di Cassandra nel secondo centro dati di quelli forniti nel centro dati originale. Le credenziali impostate nel file delle sostituzioni nel primo data center devono corrispondere a quelle specificate nel file delle sostituzioni nel secondo data center. Per maggiori dettagli, consulta Configurazione di TLS per Cassandra.

Configurare la nuova regione

Dopo aver configurato l'host di origine, puoi configurare la nuova regione.

Per configurare la nuova regione:

Copia il certificato dal cluster esistente al nuovo cluster. Il nuovo certificato CA radice viene utilizzato da Cassandra e da altri componenti ibride per mTLS. Pertanto, è essenziale avere certificati coerenti in tutto il cluster.
1. Imposta il contesto sullo spazio dei nomi originale:
```
kubectl config use-context original-cluster-name
```
2. Esporta la configurazione dello spazio dei nomi attuale in un file:
```
$ kubectl get namespace apigee -o yaml > apigee-namespace.yaml
```
  apigee è lo spazio dei nomi predefinito.
3. Esporta il secret apigee-ca in un file:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Imposta il contesto sul nome del cluster della nuova regione:
```
kubectl config use-context new-cluster-name
```
5. Importa la configurazione dello spazio dei nomi nel nuovo cluster. Assicurati di aggiornare lo "spazio dei nomi" nel file se utilizzi uno spazio dei nomi diverso nella nuova regione:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importa il secret nel nuovo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Installa il modello ibrido nella nuova regione. Assicurati che il file overrides_your_cluster_name.yaml includa gli stessi certificati TLS configurati nella prima regione, come spiegato nella sezione precedente.
Esegui i seguenti due comandi per installare la versione ibrida nella nuova regione:
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Esegui nodetool rebuild in sequenza su tutti i nodi del nuovo data center. L'operazione può richiedere da alcuni minuti a diverse ore, a seconda delle dimensioni dei dati.
```
kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1
```
Dove JMX_user e JMX_password sono il nome utente e la password per Utente Cassandra JMX.

Verifica le procedure di ricostruzione dai log. Verifica inoltre le dimensioni dei dati utilizzando il 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

L'esempio seguente mostra voci di log di esempio:

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

Aggiorna gli host di origine. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
Gli host di seed sono membri del cluster locale. Per avviare una nuova regione è necessario un host seed esterno. Una volta avviata una regione, devi ripristinare gli host seed nei rispettivi cluster locali in overrides.yaml e poi riapplicare la configurazione.
```
apigeectl apply -f overrides-DC_name.yaml
```