- v1.12 (più recente)
- Versione 1.11
- Versione 1.10
- Elenco delle versioni supportate
- Versione 1.9
- Versione 1.8
- Versione 1.7
- Versione 1.6
- Versione 1.5
- Versione 1.4
- Versione 1.3
- Versione 1.2
- Versione 1.1
Versioni supportate:
Versioni non supportate:
Questo argomento descrive un deployment in più regioni per Apigee hybrid su GKE e Anthos GKE di cui è stato eseguito il deployment on-prem.
Le topologie per il deployment su più regioni includono:
- Attivo-Attivo: se le tue applicazioni sono state distribuite 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 ibrido in più località geografiche più vicine ai tuoi clienti. Ad esempio: costa occidentale degli Stati Uniti, costa orientale degli Stati Uniti, Europa, APAC.
- Attivo-Passivo: se hai una regione principale e una regione di failover o ripristino di emergenza.
Le regioni in un deployment ibrido multiregionale comunicano tramite Cassandra, come mostra la seguente immagine:
Bilanciamento del carico della connessione MART
Ogni cluster a livello di regione deve avere il proprio nome host e IP MART; tuttavia, è sufficiente connettere il piano di gestione a uno di essi. Cassandra propaga le informazioni a tutti i cluster. L'opzione migliore per l'alta disponibilità per MART è bilanciare il carico dei singoli indirizzi IP MART e configurare la tua organizzazione in modo che comunichi con l'URL MART con bilanciamento del carico.
Prerequisiti
Prima di configurare il cloud ibrido per più regioni, devi completare i seguenti prerequisiti:
- Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi.
- Configura la comunicazione tra regioni
- Requisiti per più regioni di Cassandra:
- Assicurati che lo spazio dei nomi di rete dei pod disponga di connettività in tutte le regioni, inclusi firewall, VPN, peering VPC e peering vNet. Questo è il caso per la maggior parte delle installazioni GKE.
- Se lo spazio dei nomi di rete dei pod non dispone di connettività tra pod in cluster diversi (i cluster vengono eseguiti in "modalità di rete isola", ad esempio nelle installazioni di GKE on-prem), abilita la funzionalità
hostNetwork
di Kubernetes impostandocassandra.hostNetwork: true
nel file di override per tutte le regioni nell'installazione multiregionale ibrida di Apigee.Per informazioni sulla funzionalità
hostNetwork
di Kubernetes, consulta Spazi dei nomi host nella documentazione di Kubernetes. - Abilita
hostNetwork
sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni. - Quando
hostNetwork
è abilitato, assicurati che i nodi worker possano eseguire una ricerca DNS inversa. Apigee cassandra utilizza la ricerca DNS diretta e inversa per ottenere l'IP host all'avvio. - Apri le porte Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in più regioni e data center. Vedi Configurare le porte.
Per informazioni dettagliate, consulta la documentazione di Kubernetes.
Configura l'host seed a più regioni
Questa sezione descrive come espandere il cluster Cassandra esistente a una nuova regione. Questa configurazione consente alla nuova regione di eseguire il bootstrap del cluster e unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si sarebbero a conoscenza gli uni degli altri.
Esegui questo comando
kubectl
per identificare un indirizzo host originale per Cassandra nella regione attuale.Un indirizzo host originale consente a una nuova istanza di regione di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host originale 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
- Decidi quale degli IP restituiti dal comando precedente sarà l'host seed a più regioni.
La configurazione in questo passaggio dipende dall'utilizzo o meno di GKE o di GKE On-Prem:
Solo GKE: nel data center 2, configura
cassandra.multiRegionSeedHost
ecassandra.datacenter
in Gestisci i componenti del piano di runtime, dovemultiRegionSeedHost
è uno degli IP restituiti dal comando precedente:cassandra: multiRegionSeedHost: seed_host_IP datacenter: data_center_name rack: rack_name hostNetwork: false # Set this to true for Non GKE platforms.
Ad esempio:
cassandra: multiRegionSeedHost: 10.0.0.11 datacenter: "dc-2" rack: "ra-1" hostNetwork: false
Solo GKE on-prem: nel data center 2, configura
cassandra.multiRegionSeedHost
nel file di override, dovemultiRegionSeedHost
è uno degli IP restituiti dal comando precedente:cassandra: hostNetwork: true multiRegionSeedHost: seed_host_IP datacenter: data_center_name
Ad esempio:
cassandra: hostNetwork: true multiRegionSeedHost: 10.0.0.11 datacenter: "dc-2"
- Nel nuovo data center o nella nuova regione, prima di installare l'ambiente ibrido, imposta in
overrides.yaml
gli stessi certificati e credenziali TLS che hai impostato nella prima regione.
Configura la nuova regione
Dopo aver configurato l'host originale, puoi impostare la nuova regione.
Per configurare la nuova regione:
- Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Pertanto, è essenziale disporre di certificati coerenti in tutto il cluster.
- Imposta il contesto sullo spazio dei nomi originale:
kubectl config use-context original-cluster-name
- Esporta la configurazione attuale dello spazio dei nomi in un file:
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
- Esporta il secret
apigee-ca
in un file:kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
- Imposta il contesto sul nome del cluster della nuova regione:
kubectl config use-context new-cluster-name
- 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
Importa il secret nel nuovo cluster:
kubectl -n cert-manager apply -f apigee-ca.yaml
- Imposta il contesto sullo spazio dei nomi originale:
- Installa ibrido nella nuova regione. Assicurati che il file
overrides-DC_name.yaml
includa gli stessi certificati TLS configurati nella prima regione, come spiegato nella sezione precedente.Esegui questi due comandi per installare l'ambiente ibrido nella nuova regione:
apigeectl init -f overrides/overrides-DC_name.yaml
apigeectl apply -f overrides/overrides-DC_name.yaml
- Verifica che l'installazione ibrida vada a buon fine eseguendo questo comando:
apigeectl check-ready -f overrides_your_cluster_name.yaml
- Verifica la configurazione del cluster Cassandra eseguendo questo comando. L'output dovrebbe mostrare sia i data center nuovi sia quelli esistenti.
kubectl exec apigee-cassandra-default-0 -n apigee \ -- nodetool -u JMX_user -pw JMX_password status
Esempio che mostra una configurazione riuscita:
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
- Configurare Cassandra su tutti i pod nei nuovi data center.
- Ottieni
apigeeorg
dal cluster con il seguente comando:kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
Ad esempio:
Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name "rg-hybrid-b7d3b9c"
- Crea un file di risorsa personalizzata di replica dei dati cassandra (
YAML
). Il file può avere qualsiasi nome. Nei seguenti esempi, il file avrà il nomedatareplication.yaml
.Il file deve contenere quanto segue:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGION
Dove:
- REGION_EXPANSION è il nome che assegni a questi metadati. Puoi utilizzare qualsiasi nome.
- NAMESPACE è lo stesso spazio dei nomi fornito in
overrides.yaml
. In genere è "apigee
". - APIGEEORG_VALUE è il valore dell'output del comando
kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
nel passaggio precedente. Ad esempio,rg-hybrid-b7d3b9c
- SOURCE_REGION è il nome del data center nella regione di origine. Questo è il valore impostato per
cassandra:datacenter:
inoverrides.yaml
.
Ad esempio:
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"
- Applica
CassandraDataReplication
con il comando seguente:kubectl apply -f datareplication.yaml
- Verifica lo stato della ricompilazione utilizzando il comando seguente.
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
I risultati dovrebbero avere un aspetto simile a questo:
{ "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 }
- Ottieni
- Verifica i processi di nuova creazione 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
Nell'esempio seguente sono riportate 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
- Aggiornare gli host di origine. Rimuovi
multiRegionSeedHost: 10.0.0.11
daoverrides-DC_name.yaml
e invia di nuovo la richiesta.apigeectl apply -f overrides/overrides-DC_name.yaml
Controlla lo stato del cluster Cassandra
Il comando seguente è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato del nodetool per le due regioni.
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
Risoluzione dei problemi
Vedi Errore di replica dei dati Cassandra.