Deployment in più regioni su GKE e GKE On-Prem

Stai visualizzando la versione 1.3 di Documentazione di Apigee hybrid. This version is end of life. You should upgrade to a newer version. Per ulteriori informazioni, vedi Versioni supportate.

Version 1.3 (unsupported)

Versioni supportate:

• v1.13 (ultima versione)                        
• v1.12                         
• v1.11                         
• Elenco delle versioni supportate

   Versioni non supportate:

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Questo argomento descrive un deployment multiregionale per Apigee hybrid su GKE e Anthos GKE di cui è stato eseguito il deployment on-prem.

Le topologie per il deployment in più regioni includono quanto segue:

• Active-Active: quando hai applicazioni di cui è stato eseguito il deployment in più località geografiche e hai bisogno di una risposta dell'API con bassa latenza per i tuoi deployment. Puoi eseguire il deployment di ambienti ibridi dalle sedi più vicine ai tuoi clienti. Ad esempio: costa occidentale degli Stati Uniti, costa orientale degli Stati Uniti, Europa, APAC.
• Attivo-passivo: in presenza di una regione principale e di un failover o un'emergenza regione di ripristino.

Le regioni in un deployment ibrido multiregionale comunicano tramite Cassandra, come nell'immagine seguente mostra:

Bilanciamento del carico della connessione MART

Ogni cluster a livello di regione deve avere il proprio IP e nome host MART. ma ti serve solo per connettere il piano di gestione a uno di questi. Cassandra propaga le informazioni a tutti dei cluster. L'opzione migliore per l'alta disponibilità di MART è il bilanciamento del carico dei singoli indirizzi IP di MART e la configurazione dell'organizzazione in modo che comunichi con l'URL MART bilanciato in base al carico.

Prerequisiti

Prima di configurare il servizio ibrido per più regioni, devi completare i seguenti prerequisiti:

• Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi
• Configura la comunicazione tra regioni
• Apri le porte Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni (la porta 7000 può essere utilizzata 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 assicurarsi che i tempi dei server siano sincronizzati.

Diverse funzionalità, come la scadenza e la revoca dei token, si basano su date e ore di sistema precise. Se i componenti di runtime sono ospitati in diversi data center, assicurati che gli orari del sistema siano sincronizzati.

Puoi utilizzare uno strumento come ntpdate per verificare che gli orari del server siano sincronizzati.

Configura l'host seed multi-region

Questa sezione descrive come espandere il cluster Cassandra esistente in 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 multiregionali che non conoscerebbero.

1. Esegui questo comando kubectl per identificare un indirizzo host di origine per Cassandra in la 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 del seed viene 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 quale IP restituito dal comando precedente sarà il seed multiregionale .

3. La configurazione in questo passaggio dipende dal fatto che tu stia utilizzando GKE o GKE On-Prem:

   Solo GKE: nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in Gestisci i 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 degli override, dove 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/nella nuova regione, prima di installare l'ibrido, imposta gli stessi certificati TLS e credenziali in overrides.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 in overrides.yaml nel primo data center devono corrispondere a quelle specificate in overrides.yaml nel secondo data center. Per maggiori dettagli, vedi Configurazione di TLS per Cassandra.

Configura la nuova regione

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

Per configurare la nuova regione:

1. 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 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  -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 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 il valore "namespace" 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

2. Installa l'ambiente ibrido nella nuova regione. Assicurati che overrides-DC_name.yaml include gli stessi certificati TLS configurati nella prima regione, come spiegate nella sezione precedente.

   Esegui i seguenti due comandi per installare la versione ibrida nella nuova regione:

   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 nel 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 rebuild -- dc-1

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

   L'esempio seguente mostra esempi di voci di log:

   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 seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e richiedi di nuovo.
   Gli host di seed sono membri del cluster locale. Per avviare un nuova regione è obbligatorio un host di origine esterno. Una volta avviata la regione, devi per riportare gli host di origine ai propri cluster locali in overrides.yaml e poi e applicare nuovamente la configurazione.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Controlla lo stato del cluster Cassandra

Il seguente comando è utile per vedere se la configurazione del cluster ha esito positivo in due data center on-premise. Il comando controlla lo stato di nodetool per le due regioni.

kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool 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