Deployment su più aree geografiche su GKE e GKE On-Prem

Attualmente stai visualizzando la versione 1.4 della documentazione ibrida di Apigee. Questa versione è terminata. Dovresti eseguire l'upgrade a una versione più recente. Per ulteriori informazioni, consulta la sezione Versioni supportate.

Questo argomento descrive un deployment in più aree geografiche per Apigee ibrida su GKE e Anthos GKE con deployment on-prem.

Le topologia per il deployment in più aree geografiche includono:

• Active-Active: se hai eseguito il deployment delle applicazioni in più località geografiche e hai bisogno di una risposta API a bassa latenza, per i tuoi deployment. Hai la possibilità di eseguire il deployment di ambienti ibridi in più località geografiche più vicine ai tuoi clienti. Ad esempio: US West Coast, US East Coast, Europa, APAC.
• Passiva attiva: quando hai un'area geografica principale e un'area geografica di failover o ripristino di emergenza.

Le aree geografiche in un deployment ibrido a più aree geografiche comunicano tramite Cassandra, come mostra la seguente immagine:

Bilanciamento del carico della connessione MART

Ogni cluster a livello di area geografica deve avere un IP e un nome host MART propri, ma è sufficiente connettere il piano di gestione a uno di questi. Cassandra propaga le informazioni in tutti i cluster. L'opzione migliore per l'alta disponibilità per MART è eseguire il bilanciamento del carico dei singoli indirizzi IP MART e configurare l'organizzazione in modo che parli con l'URL MART con bilanciamento del carico.

Prerequisiti

Prima di configurare la modalità ibrida per più aree geografiche, devi completare i seguenti prerequisiti:

• Configura i cluster Kubernetes in più aree geografiche con blocchi CIDR diversi
• Impostare la comunicazione tra aree geografiche
• Le porte 7000 e 7001 di Cassandra aperte tra i cluster Kubernetes in tutte le aree geografiche (7000 possono essere utilizzate come opzione di backup durante la risoluzione dei problemi). Vedi anche Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

NOTA: Apigee consiglia di garantire che i tuoi server siano sincronizzati.

Diverse funzionalità come la scadenza e la revoca del token si basano su tempi di sistema precisi. Se ospiti i componenti runtime in data center diversi, assicurati che la sincronizzazione del sistema venga eseguita.

Puoi utilizzare uno strumento come ntpdate per verificare che i tempi del server siano sincronizzati.

Configura l'host originale a più aree geografiche

Questa sezione descrive come espandere il cluster Cassandra esistente in una nuova area geografica. Questa configurazione consente alla nuova area geografica di eseguire il bootstrap del cluster e di unirsi al data center esistente. Senza questa configurazione, i cluster Kubernetes in più aree geografiche non si conoscerebbero a vicenda.

1. Esegui il comando kubectl seguente per identificare un indirizzo host originale per Cassandra nell'area geografica corrente.

   Un indirizzo host originale consente a una nuova istanza a livello di area geografica di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host di origine è designato come punto di contatto nel 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

2. Decidi quali IP restituire dal comando precedente sarà l'host di origine con più aree geografiche.

3. La configurazione in questo passaggio varia a seconda che tu sia su GKE o GKE On-Prem:

   Solo GKE: nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in Gestisci componenti del piano di runtime, 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: 10.0.0.11
     datacenter: "dc-2"
     rack: "ra-1"

   Solo GKE On-Prem: nel data center 2, configura cassandra.multiRegionSeedHost nel file di override, in cui multiRegionSeedHost è uno degli IP restituiti dal comando precedente:

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP
   

   Ad esempio:

   cassandra:
     hostNetwork: true
     dnsPolicy: ClusterFirstWithHostNet
     multiRegionSeedHost: 10.0.0.11
   

4. Nel nuovo data center/area geografica, prima di installare il modello ibrido, imposta in overrides.yaml gli stessi certificati e credenziali TLS impostati nella prima area geografica.
   NOTA: assicurati di utilizzare gli stessi certificati e le credenziali TLS di Cassandra nel secondo data center forniti nel data center originale. Le credenziali impostate in overrides.yaml nel primo data center devono corrispondere a quelle specificate in overrides.yaml nel secondo data center. Per maggiori dettagli, vedi Configurare TLS per Cassandra.

Configura la nuova area geografica

Dopo aver configurato l'host originale, puoi configurare la nuova area geografica.

Per configurare la nuova area geografica:

1. Copia il tuo certificato dal cluster esistente nel nuovo cluster. La nuova radice della CA viene utilizzata da Cassandra e altri componenti ibridi per mTLS. Pertanto, è essenziale disporre di 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 corrente in un file:

      $ kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   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 del nuovo nome del cluster dell'area geografica:

      kubectl config use-context new-cluster-name

   5. Importa la configurazione dello spazio dei nomi nel nuovo cluster. Assicurati di aggiornare "&namet" nel file se utilizzi uno spazio dei nomi diverso nella nuova area geografica:

      kubectl apply -f apigee-namespace.yaml

   6. Importa il secret nel nuovo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Installa ibrido nella nuova area geografica. Assicurati che il file overrides-DC_name.yaml includa gli stessi certificati TLS configurati nella prima area geografica, come spiegato nella sezione precedente.

   Esegui i due comandi seguenti per installare il modello ibrido nella nuova area geografica:

   apigeectl init -f overrides/overrides-DC_name.yaml

   apigeectl apply -f overrides/overrides-DC_name.yaml

3. Esegui nodetool rebuild in sequenza su tutti i pod del nuovo data center. L'operazione potrebbe richiedere da alcuni minuti a qualche ora, 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 l'utente Cassandra JMX.

4. Verifica i processi di ricostruzione dai log. Inoltre, verifica la dimensione 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

5. Aggiorna gli host originali. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e presenta nuovamente la domanda.
   Gli host di origine sono membri del cluster locale. Per avviare una nuova area geografica è necessario un host originale esterno. Dopo l'avvio di un'area geografica, devi ripristinare gli host originali ai relativi cluster locali in overrides.yaml, quindi applicare nuovamente la configurazione.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Verificare lo stato del cluster Cassandra

Il seguente comando è utile per vedere se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato dello strumento dei nodi per le due aree geografiche.

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

Datacenter: us-central1
=======================
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