Deployment multiregionale

Stai visualizzando la versione 1.11 di Documentazione di Apigee hybrid. Per ulteriori informazioni, vedi Versioni supportate.

Version 1.11 

   Versioni supportate:

• v1.13 (più recente)                        
• 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 multi-regione per Apigee Hybrid su GKE, Anthos GKE di cui è stato eseguito il deployment on-premise, Microsoft® Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) e RedHat OpenShift. Seleziona la tua piattaforma nei prerequisiti e nelle procedure.

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 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 mostrato nella seguente immagine:

Prerequisiti

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

GKE

• Quando installi deployment Apigee multiregionali tra diversi (ad es. provider cloud diversi, reti VPC diverse, servizi on-prem e così via), devi fornire connettività interna tra questi reti separate che Cassandra può utilizzare per comunicare tra i nodi. Questo può essere ottenuto con VPN o soluzioni di connettività specifiche per il cloud.
• Se utilizzi Workload Identity in un cluster per autenticare gli account di servizio, ti consigliamo vivamente di utilizzare Workload Identity per ogni cluster a cui esegui l'espansione. Consulta Attivare Workload Identity con Apigee hybrid.
• Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi
• Assicurati che cert-manager sia installato in ogni cluster
• Configurare la comunicazione tra regioni
• Assicurati che tutti i pod Cassandra siano in grado di risolvere i propri nomi host. Se hostNetwork è impostato su false, il nome host è il nome del pod Cassandra. Se hostNetwork è impostato su true, allora il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento: per verificare se la risoluzione dell'hostname funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza Comando 1. Se hostNetwork è impostato su true, utilizza Comando 2.
  
  Se La risoluzione del nome host funziona, l'output mostrerà un indirizzo IP. Se la risoluzione del nome host non va a buon fine, l'output includerà "Host not found".
  
  Comando 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Comando 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Requisiti di Cassandra Multi Region:
  • Assicurati che lo spazio dei nomi di rete del pod abbia connettività tra le regioni, inclusi firewall, VPN, peering VPC e peering vNet. Questo è il caso della maggior parte delle installazioni di GKE.
  • Se lo spazio dei nomi di rete del pod non ha connettività tra i cluster (i cluster sono in esecuzione in "modalità di rete isolata"), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file delle sostituzioni per tutte le regioni dell'installazione Apigee ibrida multi-regione.

    Per ulteriori informazioni sulla necessità di hostNetwork, consulta Cluster in modalità Isola e hostNetwork di seguito.

  • Attiva hostNetwork sui cluster esistenti prima di estendere la configurazione multiregione a nuove regioni.
  • Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire la ricerca DNS in avanti dei relativi nomi host. Apigee Cassandra utilizza la ricerca DNS in avanti 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 la porta TCP 7001 tra i cluster Kubernetes in tutte le regioni per consentire ai nodi worker di comunicare tra regioni e data center. Per informazioni sui numeri di porta Cassandra, consulta Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

Nota: Apigee consiglia di assicurarti che i tuoi server gli orari sono sincronizzati.

Diverse funzionalità, come la scadenza e la revoca del 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 il server gli orari sono sincronizzati.

GKE On-Prem

• Quando installi i deployment Apigee multiregione tra reti diverse (ad es. diversi provider cloud, reti VPC diverse, cloud e on-premise e così via), devi fornire la connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. Questo può essere fatto con le VPN o la connettività specifica per il cloud. soluzioni.
• Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi
• Assicurati che cert-manager sia installato in ogni cluster
• Configurare la comunicazione tra regioni
• Assicurati che tutti i pod Cassandra siano in grado di risolvere i propri nomi host. Se hostNetwork è impostato su false, il nome host è il nome del pod Cassandra. Se hostNetwork è impostato su true, allora il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione dei nomi host funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza Comando 1. Se hostNetwork è impostato su true, utilizza Comando 2.
  
  Se La risoluzione del nome host funziona, l'output mostrerà un indirizzo IP. Se la risoluzione del nome host non va a buon fine, l'output includerà "Host not found".
  
  Comando 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Comando 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Requisiti di Cassandra per più regioni:
  • Se lo spazio dei nomi della rete del pod non ha connettività tra i cluster (i cluster sono in esecuzione in "modalità di rete a isola", il caso predefinito nelle installazioni on-premise di GKE), 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.

    Per ulteriori informazioni sulla necessità di hostNetwork, consulta Cluster in modalità Isola e hostNetwork di seguito.

  • 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'inoltro Ricerca DNS dei rispettivi nomi host. Apigee Cassandra utilizza una ricerca DNS diretta per ottenere l'host IP all'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 tra i cluster Kubernetes su tutti regioni e data center in modo da consentire ai nodi worker tra regioni e data center di comunicare. Consulta Configurare le porte per i numeri di porta Cassandra.

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 del token si basano su orari di sistema precisi. Se i componenti di runtime sono ospitati in diversi data center, quindi assicurati di sincronizzare gli orari di sistema.

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

AKS

• Quando installi deployment Apigee multiregionali tra diversi (ad es. provider cloud diversi, reti VPC diverse, servizi on-prem e così via), devi fornire connettività interna tra questi reti separate che Cassandra può utilizzare per comunicare tra i nodi. Questo può essere fatto con le VPN o la connettività specifica per il cloud. soluzioni.
• 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.
• Assicurati che cert-manager sia installato in ogni cluster
• Assicurati che tutti i pod Cassandra siano in grado di risolvere i propri nomi host. Se hostNetwork è impostato su false, il nome host è il nome del pod Cassandra. Se hostNetwork è impostato su true, il nome host è il nome host del nodo Kubernetes in cui è in esecuzione il pod Cassandra.
  Suggerimento:per verificare se la risoluzione dei nomi host funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza il comando 1. Se hostNetwork è impostato su true, utilizza il comando 2.
  
  Se la risoluzione del nome host funziona, l'output mostrerà un indirizzo IP. Se il nome host non è un errore, l'output includerà "Host non trovato".
  
  Comando 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Comando 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Requisiti di Cassandra Multi Region:
  • Se lo spazio dei nomi della rete dei pod non dispone di connettività tra i cluster (i cluster sono in esecuzione in "modalità Island Network", il caso predefinito nelle installazioni AKS), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file degli override per tutte le regioni in la tua installazione ibrida di Apigee in più regioni.

    Per ulteriori informazioni sulla necessità di hostNetwork, vedi Cluster in modalità Isola e hostNetwork di seguito.

  • Attiva hostNetwork sui cluster esistenti prima di estendere la configurazione multiregione a nuove regioni.
  • Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire la ricerca DNS in avanti dei relativi nomi host. Apigee Cassandra utilizza la ricerca DNS in avanti 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 tra i cluster Kubernetes su tutti regioni e data center in modo da consentire ai nodi worker tra regioni e data center di comunicare. Consulta Configurare le porte per Numeri di porta di Cassandra.

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 il server gli orari sono sincronizzati.

EKS

• Quando installi deployment Apigee multiregionali tra diversi (ad es. provider cloud diversi, reti VPC diverse, servizi on-prem e così via), devi fornire connettività interna tra questi reti separate che Cassandra può utilizzare per comunicare tra i nodi. Questo può essere fatto con le VPN o la connettività specifica per il cloud. soluzioni.
• Segui la guida all'installazione ibrida per eventuali prerequisiti come la configurazione di Google Cloud e dell'organizzazione prima di passare ai passaggi di configurazione del cluster.
• Assicurati che cert-manager sia installato in ogni cluster
• Assicurati che tutti i pod Cassandra siano in grado di risolvere i propri nomi host. Se hostNetwork è impostato su false, il nome host è Nome pod Cassandra. Se hostNetwork è impostato su true, allora il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento: per verificare se la risoluzione dell'hostname funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza Comando 1. Se hostNetwork è impostato su true, utilizza il comando 2.
  
  Se la risoluzione del nome host funziona, l'output mostrerà un indirizzo IP. Se il nome host non è un errore, l'output includerà "Host non trovato".
  
  Comando 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Comando 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Requisiti di Cassandra per più regioni:
  • Se lo spazio dei nomi di rete del pod non ha connettività tra i cluster (i cluster sono in esecuzione in "modalità di rete isolata"), 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. Amazon EKS utilizza completamente integrato per impostazione predefinita.

    Per ulteriori informazioni sulla necessità di hostNetwork, vedi Cluster in modalità Isola e hostNetwork di seguito.

  • Attiva hostNetwork sui cluster esistenti prima di estendere la configurazione multiregione a nuove regioni.
  • Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire la ricerca DNS in avanti dei relativi nomi host. Apigee Cassandra utilizza la ricerca DNS in avanti 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 tra i cluster Kubernetes su tutti regioni e data center in modo da consentire ai nodi worker tra regioni e data center di comunicare. Consulta Configurare le porte per i numeri di porta Cassandra.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

Nota: Apigee consiglia di assicurarti che i tuoi server gli orari sono 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 il server gli orari sono sincronizzati.

OpenShift

• Quando installi i deployment Apigee multiregione tra reti diverse (ad es. diversi provider cloud, reti VPC diverse, cloud e on-premise e così via), devi fornire la connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. Questo può essere fatto con le VPN o la connettività specifica per il cloud. soluzioni.
• Segui la guida all'installazione ibrida per eventuali prerequisiti come la configurazione di Google Cloud e dell'organizzazione prima di passare ai passaggi di configurazione del cluster.
• Assicurati che cert-manager sia installato in ogni cluster
• Assicurati che tutti i pod Cassandra siano in grado di risolvere i propri nomi host. Se hostNetwork è impostato su false, il nome host è Nome pod Cassandra. Se hostNetwork è impostato su true, il nome host è il nome host del nodo Kubernetes in cui è in esecuzione il pod Cassandra.
  Suggerimento:per verificare se la risoluzione dei nomi host funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza il comando 1. Se hostNetwork è impostato su true, utilizza Comando 2.
  
  Se La risoluzione del nome host funziona, l'output mostrerà un indirizzo IP. Se il nome host non è un errore, l'output includerà "Host non trovato".
  
  Comando 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Comando 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Requisiti di Cassandra per più regioni:
  • Se lo spazio dei nomi della rete dei pod non dispone di connettività tra i cluster (i cluster sono in esecuzione in "modalità Island network", impostazione predefinita nelle installazioni OpenShift), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file degli override per tutte le regioni in la tua installazione ibrida di Apigee in più regioni.

    Per ulteriori informazioni sulla necessità di hostNetwork, consulta Cluster in modalità Isola e hostNetwork di seguito.

  • Abilita hostNetwork sui cluster esistenti prima di espandere da più regioni a nuove regioni.
  • Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire la ricerca DNS in avanti dei relativi nomi host. Apigee Cassandra utilizza la ricerca DNS in avanti 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 tra i cluster Kubernetes in tutte le regioni per consentire ai nodi worker di comunicare tra regioni e data center. Consulta Configurare le porte per i numeri di porta Cassandra.

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 i tempi del server siano sincronizzati.

Cluster in modalità Isola e hostNetwork

Esistono due modelli di rete principali per i cluster Kubernetes: completamente integrato (o piatto) e modalità isola. Apigee consiglia di utilizzare il modello di rete piatto, se possibile, in quanto semplifica la connettività Cassandra multiregione. Quando un cluster Kubernetes è configurato in modalitàเกาะ, la rete del pod è isolata. I pod non possono comunicare direttamente con i pod in esecuzione in altri cluster utilizzando l'indirizzo IP del pod. Consulta Implementazioni di modelli di rete tipici per ulteriori informazioni sulle differenze tra questi due modelli di rete e su esempi di ciascuno.

Quando Apigee Hybrid viene eseguito su due o più cluster Kubernetes che utilizzano un modello di rete in modalità isola, è necessario attivare l'impostazione hostNetwork per Cassandra tramite la proprietà cassandra.hostNetwork. Per impostazione predefinita, i pod Kubernetes sono isolati in singoli spazi dei nomi di rete che impediscono loro di utilizzare l'IP del nodo worker Kubernetes. Quando il criterio hostNetwork è impostato su true, il pod non è isolato all'interno del proprio spazio dei nomi di rete, l'indirizzo IP e il nome host del nodo worker Kubernetes su cui è pianificato il pod. Ciò consente Cassandra di utilizzare in modo nativo l'IP del nodo worker di Kubernetes come IP, fornendo un mezzo per Cassandra per stabilire un mesh completo tra tutti i pod di Cassandra in più cluster in esecuzione modalità isola.

Risoluzione dei nomi host Cassandra

Sebbene un pod Cassandra non risolva altri pod Cassandra in base al nome host, all'avvio verifica che il proprio nome host sia risolvibile dal DNS. Poiché il nome host del pod è uguale al Il nome host del nodo worker Kubernetes quando hostNetwork è impostato su true, il nodo worker il nome host deve essere risolvibile in un indirizzo IP tramite il servizio DNS del cluster. Se la classe il nome host del nodo worker non è risolvibile. Non sarà possibile avviare completamente il pod Cassandra. Pertanto, è importante che i nomi host dei nodi worker di Kubernetes siano risolvibili dai pod nel cluster quando imposti hostNetwork su true.

Configurare Apigee Hybrid per più regioni

Questa sezione descrive come configurare Apigee hybrid per più regioni.

GKE

Importante: quando espandi Apigee Hybrid a un nuovo datacenter regionale, assicurati di installare la stessa versione di Hybrid che hai nel tuo datacenter esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.

Avviso:se l'installazione non riesce per una nuova regione, non continuare l'installazione della regione. Elimina e ricrea l'installazione ibrida nella regione con errori.

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.

Segui le procedure per lo strumento che utilizzi per gestire e installare Apigee hybrid:

Grafici Helm

1. Per la prima regione creata, ottieni i pod nel tuo spazio dei nomi apigee:

   kubectl get pods -o wide -n apigee
   

2. Identifica l'indirizzo host di origine multiregionale per Cassandra in questa regione, ad esempio 10.0.0.11.

3. Prepara il file overrides.yaml per la seconda regione e aggiungi l'indirizzo IP dell'host di origine come segue:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Sostituisci quanto segue:

   • SEED_HOST_IP_ADDRESS con l'indirizzo IP dell'host iniziale, ad esempio 10.0.0.11.
   • DATACENTER_NAME con il nome del data center, ad esempio dc-2.
   • RACK_NAME con il nome del rack, ad esempio ra-1.
   • CLUSTER_NAME con il nome del cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome del cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere liberamente un valore diverso, ma deve essere uguale in tutte le regioni.

Configura la seconda regione

Per configurare la nuova regione:

1. Installa cert-manager nella regione 2:

   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.1/cert-manager.yaml
   

2. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova radice dell'autorità di certificazione viene utilizzata da Cassandra e da 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 attuale in un file:

      kubectl get namespace apigee -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 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
      

3. Segui i passaggi per Installa i CRD ibridi di Apigee nella nuova regione.

4. Ora utilizza i grafici Helm per installare Apigee hybrid nella nuova regione con i seguenti comandi di grafico Helm (come per la regione 1):

   Nota: per garantire la coerenza, puoi utilizzare gli stessi CRD utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere univoco il file delle sostituzioni tra la regione 1 e la 2 assegnando un nome univoco alle sostituzioni, ad esempio overrides-region_name.yaml e così via.
   Importante: ometti il flag ‑‑atomic per i cluster sottoposti a migrazione.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Verifica la configurazione del cluster Cassandra eseguendo il seguente comando. L'output dovrebbe mostrare sia i data center esistenti che quelli nuovi.
   Avviso: se l'output di questo comando non mostra sia i data center esistenti che quelli nuovi, la configurazione non è riuscita. In tal caso, non proseguire più avanti.

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Consulta Disinstallare il runtime di hybrid. Se la configurazione non va a buon fine, non tentare di procedere o di partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Esempio di configurazione corretta:

   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

6. Configurare Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il comando seguente:

      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"
      

   2. Crea un file di risorse personalizzate di replica dei dati Cassandra (YAML). Il file può avere un nome qualsiasi. Nei seguenti esempi il file avrà il nome datareplication.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 stai assegnando a questi metadati. Puoi puoi usare un nome qualsiasi.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
      • APIGEEORG_VALUE è il valore visualizzato dall'output del comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di overrides.yaml della regione di origine

      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"

   3. Applica CassandraDataReplication con il seguente comando:

      kubectl apply -f datareplication.yaml

7. Verifica lo stato della ricompilazione utilizzando il comando seguente.
   Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.

   kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

   I risultati dovrebbero essere simili ai seguenti:

   {
   "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
   }

8. Una volta completata e verificata la replica dei dati, aggiorna gli host di seed:
   1. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DATACENTER_NAME.yaml.

   2. Applica di nuovo la modifica per aggiornare la RP apigee datastore:

      Importante: ometti il flag ‑‑atomic per di cui è stata eseguita la migrazione.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Verifica i processi di ricreazione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di ricostruzione mostra lo stato completato e i log dei processi di ricostruzione contengono "Tutte le sessioni completate", tutti i dati sono stati copiati correttamente nella nuova regione.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Suggerimento: APIGEE_JMX_USER e Il parametro APIGEE_JMX_PASSWORD di solito è definito nelle variabili di ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   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

apigeectl

1. Imposta il contesto kubectl sul cluster originale prima di recuperare il nome seed:

   kubectl config use-context original-cluster-name

2. Esegui il seguente comando kubectl per identificare un indirizzo host iniziale per Cassandra nella regione corrente.

   Un indirizzo host di origine consente a una nuova istanza regionale di trovare originale alla primissima startup a scoprire la topologia del cluster. L'indirizzo host del seed viene designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra --field-selector status.phase=Running

   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

3. Decidi quale degli IP restituiti dal comando precedente sarà l'host iniziale con più regioni.
4. 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
     hostNetwork: false
     clusterName: cluster_name # must be the same for all regions

   Ad esempio:

   cassandra:
     multiRegionSeedHost: 10.0.0.11
     datacenter: "dc-2"
     rack: "ra-1"
     hostNetwork: false
     clusterName: my-apigee-cluster

5. Nel nuovo data center/nella nuova regione, prima di installare la versione ibrida, imposta gli stessi certificati TLS e le stesse credenziali in overrides.yaml come hai fatto nella prima regione.
   Nota: assicurati di utilizzare gli stessi certificati e le stesse credenziali TLS di Cassandra nel secondo data center di quelli forniti nel data center originale. Le credenziali che impostati nel file degli override nel primo data center devono corrispondere a quelli specificati nel il file degli override nel secondo data center. Per maggiori dettagli, consulta Configurazione di TLS per Cassandra.

Configurare la nuova regione

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

Per configurare la nuova regione:

1. Copia il tuo certificato dal cluster esistente a quello nuovo. 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 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 il file overrides-DC_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:

   Importante: quando espandi Apigee Hybrid a un nuovo datacenter regionale, assicurati di installare la stessa versione di Hybrid che hai nel tuo datacenter esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.

   apigeectl init -f overrides/overrides-DC_name.yaml

   apigeectl apply -f overrides/overrides-DC_name.yaml

3. Verifica che l'installazione ibrida sia riuscita eseguendo questo comando:

   apigeectl check-ready -f overrides_DC_name.yaml

4. Verifica la configurazione del cluster Cassandra eseguendo il seguente comando. L'output dovrebbe mostrare sia i data center esistenti che quelli nuovi.
   Avviso: se l'output di questo comando non mostra entrambi data center nuovi ed esistenti, la configurazione non è riuscita. In tal caso, non proseguire più avanti.

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminati e ricreati. Consulta Disinstallare il runtime di hybrid. Se la configurazione non va a buon fine, non tentare di procedere o di partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Esempio di configurazione corretta:

   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

5. Configura Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il comando seguente:

      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"
      

   2. Crea un file della risorsa personalizzata (YAML) per la replica dei dati di Cassandra. Il file può avere un nome qualsiasi. Nei seguenti esempi il file avrà il nome datareplication.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 stai assegnando a questi metadati. Puoi puoi usare un nome qualsiasi.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
      • APIGEEORG_VALUE è il valore di output dal kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di overrides.yaml della regione di origine

      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"

   3. Applica CassandraDataReplication con il seguente comando:

      kubectl apply -f datareplication.yaml

   4. Verifica lo stato della ricompilazione utilizzando il comando seguente.
      Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.

      kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

      I risultati dovrebbero avere il seguente aspetto:

      {
        "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
      }

6. Verifica i processi di ricreazione dai log. Verifica inoltre le dimensioni dei dati usando il comando nodetool status.
   Nota: se l'operazione di ricompilazione mostra lo stato completato e i log dei processi di ricreazione contengono "Tutte le sessioni completate" tutti i dati sono stati copiata correttamente nella nuova regione.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

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

7. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Nota: gli host di origine 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 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 -u APIGEE_JMX_USER -pw APIGEE_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: 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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

GKE On-Prem

Importante: quando espandi Apigee Hybrid a un nuovo datacenter regionale, assicurati di installare la stessa versione di Hybrid che hai nel tuo datacenter esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.

Avviso:se l'installazione non riesce per una nuova regione, non continuare l'installazione della regione. Elimina e ricrea l'installazione ibrida nella regione che non è riuscita.

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.

Segui le procedure per lo strumento che utilizzi per gestire e installare Apigee hybrid:

Grafici Helm

1. Per la prima regione creata, ottieni i pod nel tuo spazio dei nomi apigee:

   kubectl get pods -o wide -n apigee
   

2. Identifica l'indirizzo host di origine multiregionale per Cassandra in questa regione, ad esempio 10.0.0.11.

3. Prepara il file overrides.yaml per la seconda regione e aggiungi l'indirizzo IP dell'host di origine come segue:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Sostituisci quanto segue:

   • SEED_HOST_IP_ADDRESS con l'indirizzo IP dell'host iniziale, ad esempio 10.0.0.11.
   • DATACENTER_NAME con il nome del data center, ad esempio dc-2.
   • RACK_NAME con il nome del rack, ad esempio ra-1.
   • CLUSTER_NAME con il nome del cluster Cassandra. Per impostazione predefinita, è apigeecluster. Se utilizzi un nome del cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere il valore che preferisci, ma deve essere lo stesso in tutte le regioni.

Configura la seconda regione

Per configurare la nuova regione:

1. Installa cert-manager nella regione 2:

   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.1/cert-manager.yaml
   

2. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova radice dell'autorità di certificazione viene utilizzata da Cassandra e da 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 attuale in un file:

      kubectl get namespace apigee -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 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
      

3. Segui i passaggi per Installa i CRD ibridi di Apigee nella nuova regione.

4. Ora utilizza i grafici Helm per installare Apigee hybrid nella nuova regione con i seguenti comandi di grafico Helm (come per la regione 1):

   Nota: per garantire la coerenza, puoi utilizzare gli stessi CRD utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere univoco il file delle sostituzioni tra la regione 1 e la 2 assegnando un nome univoco alle sostituzioni, ad esempio overrides-region_name.yaml e così via.
   Importante: ometti il flag ‑‑atomic per i cluster sottoposti a migrazione.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Verifica la configurazione del cluster Cassandra eseguendo questo comando. L'output dovrebbe mostrare sia i data center esistenti che quelli nuovi.
   Avviso: se l'output di questo comando non mostra entrambi data center nuovi ed esistenti, la configurazione non è riuscita. In questo caso, non procedere oltre.

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminati e ricreati. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non tentare di procedere o di partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Esempio di configurazione corretta:

   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

6. Configurare Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il comando seguente:

      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"
      

   2. Crea un file di risorse personalizzate di replica dei dati Cassandra (YAML). Il file può avere un nome qualsiasi. Nei seguenti esempi il file avrà il nome datareplication.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 stai assegnando a questi metadati. Puoi puoi usare un nome qualsiasi.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
      • APIGEEORG_VALUE è il valore visualizzato dall'output del comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di overrides.yaml della regione di origine

      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"

   3. Applica CassandraDataReplication con il seguente comando:

      kubectl apply -f datareplication.yaml

7. Verifica lo stato della ricompilazione utilizzando il comando seguente.
   Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.

   kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

   I risultati dovrebbero essere simili ai seguenti:

   {
   "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
   }

8. Una volta completata e verificata la replica dei dati, aggiorna gli host di seed:
   1. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DATACENTER_NAME.yaml.

   2. Riapplica la modifica per aggiornare la RP del datastore apigee:

      Importante: ometti il flag ‑‑atomic per di cui è stata eseguita la migrazione.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Verifica le procedure di ricostruzione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di ricompilazione mostra lo stato completato e i log dei processi di ricreazione contengono "Tutte le sessioni completate" tutti i dati sono stati copiata correttamente nella nuova regione.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Suggerimento: APIGEE_JMX_USER e Il parametro APIGEE_JMX_PASSWORD di solito è definito nelle variabili di ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   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

apigeectl

1. Nel file overrides.yaml del cluster originale, assicurati che cassandra:hostNetwork impostato su true. Ad esempio:

   cassandra:
     hostNetwork: true

   Consulta la sezione Prerequisiti per ulteriori informazioni su quando eseguire l'impostazione hostNetwork: true.

2. Se cassandra:hostNetwork non è impostato su true, procedi nel seguente modo:
   1. cassandra.hostNetwork modificato in true.
   2. Applica il file di configurazione overrides.yaml con il comando:

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi il completamento di un riavvio graduale dei pod Cassandra.

   4. Verifica che il cluster Cassandra sia integro con quanto segue :

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        

        nodetool -u  -pw APIGEE_JMX_PASSWORD status
        

      Assicurati che tutti i nodi Cassandra nell'output siano in stato UN (Up/Normal):

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
        

      Assicurati che nell'output non siano elencati nodi non raggiungibili.

3. Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seme:

   kubectl config use-context original-cluster-name

4. 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 apprendere la topologia del cluster. L'indirizzo host del seed viene designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra --field-selector status.phase=Running

   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

5. Decidi quale degli IP restituiti dal comando precedente sarà l'host iniziale con più regioni.
6. Nel data center 2, configura cassandra.multiRegionSeedHost nel file delle sostituzioni, dove multiRegionSeedHost è uno degli IP restituiti dal comando precedente:

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name
     clusterName: cluster_name # must be the same for all regions

   Ad esempio:

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: 10.0.0.11
     datacenter: "dc-2"
     rack: "ra-1"
     clusterName: my-apigee-cluster

7. Nel nuovo data center/nella nuova regione, prima di installare la versione ibrida, imposta gli stessi certificati TLS e le stesse credenziali in overrides.yaml come hai fatto nella prima regione.
   Nota: assicurati di utilizzare gli stessi certificati e le stesse credenziali TLS di Cassandra nel secondo data center di quelli forniti nel data center 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 seed, puoi configurare la nuova regione.

Per configurare la nuova regione:

1. Copia il tuo certificato dal cluster esistente a quello nuovo. 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 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 il file overrides-DC_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:

   Importante: quando espandi Apigee Hybrid a un nuovo datacenter regionale, assicurati di installare la stessa versione di Hybrid che hai nel tuo datacenter esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.

   apigeectl init -f overrides/overrides-DC_name.yaml

   apigeectl apply -f overrides/overrides-DC_name.yaml

3. Verifica che l'installazione ibrida sia riuscita eseguendo questo comando:

   apigeectl check-ready -f overrides_DC_name.yaml

4. Verifica la configurazione del cluster Cassandra eseguendo il seguente comando. L'output dovrebbe mostrare sia i data center esistenti che quelli nuovi.
   Avviso: se l'output di questo comando non mostra entrambi data center nuovi ed esistenti, la configurazione non è riuscita. In tal caso, non proseguire più avanti.

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminati e ricreati. Vedi Disinstallare il runtime ibrido. Se Se la configurazione non va a buon fine, non tentare di andare avanti né tentare di unirsi al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Esempio di configurazione corretta:

   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

5. Configura Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il comando seguente:

      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"
      

   2. Crea un file della risorsa personalizzata (YAML) per la replica dei dati di Cassandra. Il file può avere un nome qualsiasi. Nei seguenti esempi il file avrà il nome datareplication.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 stai assegnando a questi metadati. Puoi puoi usare un nome qualsiasi.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
      • APIGEEORG_VALUE è il valore di output dal kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di overrides.yaml della regione di origine

      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"

   3. Applica CassandraDataReplication con il seguente comando:

      kubectl apply -f datareplication.yaml

   4. Verifica lo stato della ricompilazione utilizzando il comando seguente.
      Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.

      kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

      I risultati dovrebbero avere il seguente aspetto:

      {
        "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
      }

6. Verifica i processi di ricreazione dai log. Verifica inoltre le dimensioni dei dati usando il comando nodetool status.
   Nota: se l'operazione di ricompilazione mostra lo stato completato e i log dei processi di ricreazione contengono "Tutte le sessioni completate" tutti i dati sono stati copiata correttamente nella nuova regione.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

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

7. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Nota: gli host di origine 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 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 -u APIGEE_JMX_USER -pw APIGEE_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: 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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

AKS

Importante: quando espandi Apigee hybrid a un nuovo data center regionale, assicurati di installare la stessa versione di ibrido che hai nella di un data center. Evita di eseguire versioni diverse dell'ibrido in più data center.

Avviso: se l'installazione non va a buon fine per una nuova regione, non continuare con l'installazione della regione. Elimina e ricrea l'installazione ibrida nella regione con errori.

Crea una rete virtuale in ogni regione

Segui i consigli di Azure per stabilire la comunicazione tra regioni qui: VNet-to-VNet: Connecting Virtual Networks in Azure across Different Regions.

Crea cluster multiregionali

Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi. Consulta: 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 tra i cluster Kubernetes in tutte le regioni per consentire ai nodi worker di comunicare tra regioni e data center. Consulta Configurare le porte per i numeri di porta Cassandra.

Configura l'host seed multi-region

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.

Segui le procedure per lo strumento che utilizzi per gestire e installare Apigee hybrid:

Grafici Helm

1. Per la prima regione creata, ottieni i pod nel tuo spazio dei nomi apigee:

   kubectl get pods -o wide -n apigee
   

2. Identifica l'indirizzo host di origine multiregionale per Cassandra in questa regione, ad esempio 10.0.0.11.

3. Prepara il file overrides.yaml per la seconda regione e aggiungi l'indirizzo IP dell'host di origine come segue:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Sostituisci quanto segue:

   • SEED_HOST_IP_ADDRESS con l'indirizzo IP dell'host iniziale, ad esempio 10.0.0.11.
   • DATACENTER_NAME con il nome del data center, ad esempio dc-2.
   • RACK_NAME con il nome del rack, ad esempio ra-1.
   • CLUSTER_NAME con il nome del cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome del cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere liberamente un valore diverso, ma deve essere uguale in tutte le regioni.

Configura la seconda regione

Per configurare la nuova regione:

1. Installa cert-manager nella regione 2:

   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.1/cert-manager.yaml
   

2. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova radice dell'autorità di certificazione viene utilizzata da Cassandra e da 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 attuale in un file:

      kubectl get namespace apigee -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 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
      

3. Segui i passaggi per installare i CRD di Apigee hybrid nella nuova regione.

4. Ora utilizza i grafici Helm per installare Apigee hybrid nella nuova regione con i seguenti comandi di grafico Helm (come per la regione 1):

   Nota: puoi usare gli stessi CRD per coerenza usando il nella stessa cartella in cui hai scaricato i grafici, puoi anche il file di override univoco tra la regione 1 e la regione 2 assegnando il nome sostituisce qualcosa di univoco, ad esempio overrides-region_name.yaml e così via.
   Importante: ometti il flag ‑‑atomic per di cui è stata eseguita la migrazione.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Verifica la configurazione del cluster Cassandra eseguendo questo comando. L'output dovrebbe mostrare sia i data center esistenti che quelli nuovi.
   Avviso: se l'output di questo comando non mostra entrambi data center nuovi ed esistenti, la configurazione non è riuscita. In tal caso, non proseguire più avanti.

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminati e ricreati. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non tentare di procedere o di partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Esempio di configurazione corretta:

   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

6. Configurare Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il comando seguente:

      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"
      

   2. Crea un file di risorse personalizzate di replica dei dati Cassandra (YAML). Il file può avere un nome qualsiasi. Nei seguenti esempi il file avrà il nome datareplication.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 stai assegnando a questi metadati. Puoi puoi usare un nome qualsiasi.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
      • APIGEEORG_VALUE è il valore visualizzato dall'output del comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di overrides.yaml della regione di origine

      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"

   3. Applica CassandraDataReplication con il seguente comando:

      kubectl apply -f datareplication.yaml

7. Verifica lo stato della ricompilazione utilizzando il comando seguente.
   Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.

   kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

   I risultati dovrebbero essere simili ai seguenti:

   {
   "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
   }

8. Una volta completata e verificata la replica dei dati, aggiorna gli host di seed:
   1. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DATACENTER_NAME.yaml.

   2. Applica di nuovo la modifica per aggiornare la RP apigee datastore:

      Importante: ometti il flag ‑‑atomic per i cluster sottoposti a migrazione.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Verifica i processi di ricreazione dai log. Verifica inoltre le dimensioni dei dati usando il comando nodetool status.
   Nota: se l'operazione di ricostruzione mostra lo stato completato e i log dei processi di ricostruzione contengono "Tutte le sessioni completate", tutti i dati sono stati copiati correttamente nella nuova regione.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Suggerimento: APIGEE_JMX_USER e APIGEE_JMX_PASSWORD sono in genere definiti nelle variabili di ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   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

apigeectl

1. Nel file overrides.yaml del cluster originale, assicurati che cassandra:hostNetwork sia impostato su true. Ad esempio:

   cassandra:
     hostNetwork: true

   Consulta la sezione Prerequisiti per ulteriori informazioni su quando eseguire l'impostazione hostNetwork: true.

2. Se cassandra:hostNetwork non è impostato su true, procedi nel seguente modo:
   1. cassandra.hostNetwork modificato in true.
   2. Applica il file di configurazione overrides.yaml con il comando:

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi il completamento di un riavvio graduale dei pod Cassandra.

   4. Verifica che il cluster Cassandra sia integro con quanto segue :

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        

        nodetool -u  -pw APIGEE_JMX_PASSWORD status
        

      Assicurati che tutti i nodi Cassandra nell'output siano in stato UN (Up/Normal):

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
        

      Assicurati che nell'output non siano elencati nodi non raggiungibili.

3. Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seme:

   kubectl config use-context original-cluster-name

4. 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 apprendere la topologia del cluster. L'indirizzo host di origine è designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra --field-selector status.phase=Running

   apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000

5. Decidi quale degli IP restituiti dal comando precedente sarà l'host iniziale con più regioni. In questo esempio, in cui è in esecuzione un solo cluster Cassandra a un nodo, l'host iniziale è 120.38.1.9.
6. 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.
7. Nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in overrides_your_cluster_name.yaml, dove multiRegionSeedHost è uno degli IP restituiti dalla comando precedente:

   cassandra:
        multiRegionSeedHost: seed_host_IP
        datacenter: data_center_name
        rack: rack_name
        hostNetwork: true

   clusterName: cluster_name # deve essere uguale per tutte le regioni

   Ad esempio:

   cassandra:
     multiRegionSeedHost: 120.38.1.9
     datacenter: "centralus"
     rack: "ra-1"
     hostNetwork: true
     clusterName: my-apigee-cluster

8. 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 come impostato nella prima regione.
   Nota: assicurati di utilizzare gli stessi certificati e le stesse credenziali TLS di Cassandra nel secondo data center di quelli forniti nel data center 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, vedi Configurazione di TLS per Cassandra.

Configurare la nuova regione

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

Per configurare la nuova regione:

1. Copia il tuo certificato dal cluster esistente a quello nuovo. 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 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_your_cluster_name.yaml include gli stessi certificati TLS configurati nella prima regione, come spiegate nella sezione precedente.

   Esegui questi due comandi per installare il modello ibrido nella nuova regione:

   Importante: quando espandi Apigee Hybrid a un nuovo datacenter regionale, assicurati di installare la stessa versione di Hybrid che hai nel tuo datacenter esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

3. Verifica che l'installazione ibrida sia riuscita eseguendo questo comando:

   apigeectl check-ready -f overrides_your_cluster_name.yaml

4. Verifica la configurazione del cluster Cassandra eseguendo il seguente comando. L'output dovrebbe mostrare sia i data center esistenti che quelli nuovi.
   Avviso: se l'output di questo comando non mostra entrambi data center nuovi ed esistenti, la configurazione non è riuscita. In tal caso, non proseguire più avanti.

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Consulta Disinstallare il runtime di hybrid. Se la configurazione non va a buon fine, non tentare di procedere o di partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Esempio di configurazione corretta:

   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

5. Configura Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il comando seguente:

      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"
      

   2. Crea un file della risorsa personalizzata (YAML) per la replica dei dati di Cassandra. Il file può avere un nome qualsiasi. Nei seguenti esempi il file avrà il nome datareplication.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 stai assegnando a questi metadati. Puoi puoi usare un nome qualsiasi.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
      • APIGEEORG_VALUE è il valore di output dal kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di overrides.yaml della regione di origine

      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"

   3. Applica CassandraDataReplication con il seguente comando:

      kubectl apply -f datareplication.yaml

   4. Verifica lo stato della ricompilazione utilizzando il comando seguente.
      Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.

      kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

      I risultati dovrebbero avere il seguente aspetto:

      {
        "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
      }

6. Verifica i processi di ricreazione dai log. Verifica inoltre le dimensioni dei dati usando il comando nodetool status.
   Nota: se l'operazione di ricompilazione mostra lo stato completato e i log dei processi di ricreazione contengono "Tutte le sessioni completate" tutti i dati sono stati copiata correttamente nella nuova regione.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

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

7. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Nota: gli host di origine 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 applicare nuovamente la configurazione.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Controlla lo stato del cluster Cassandra

Il seguente comando è utile per verificare se la configurazione del cluster è andata a buon fine in due datacenter. Il comando controlla lo stato di nodetool per le due regioni.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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: 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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

EKS

Importante: quando espandi Apigee hybrid a un nuovo data center regionale, assicurati di installare la stessa versione di ibrido che hai nella di un data center. Evita di eseguire versioni diverse di ibrida in più data center. Questa limitazione non si applica quando si esegue l'upgrade di più data center a un nuova versione.

Avviso:se l'installazione non riesce per una nuova regione, non continuare l'installazione della regione. Elimina e ricrea l'installazione ibrida nella regione con errori.

Crea una rete virtuale in ogni regione

Segui i consigli di AWS per stabilire la comunicazione tra regioni come descritto in: Che cos'è il peering VPC?. Il termine AWS per l'utilizzo di regioni diverse è peering VPC interregione.

Creare cluster multiregionali

Configura i cluster Kubernetes in più regioni con blocchi CIDR diversi. Vedi anche Passaggio 1: crea un cluster. Utilizza la di località e nomi di reti virtuali creati in precedenza.

Apri le porte Cassandra tra i cluster Kubernetes su tutti regioni e data center in modo da consentire ai nodi worker tra regioni e data center di comunicare. Consulta Configurare le porte per i numeri di porta Cassandra.

Configura l'host seed multi-region

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.

Segui le procedure per lo strumento che utilizzi per gestire e installare Apigee hybrid:

Grafici Helm

1. Per la prima regione creata, ottieni i pod nel tuo spazio dei nomi apigee:

   kubectl get pods -o wide -n apigee
   

2. Identifica l'indirizzo host di origine multiregionale per Cassandra in questa regione, ad esempio 10.0.0.11.

3. Prepara il file overrides.yaml per la seconda regione e aggiungi l'indirizzo IP dell'host di origine come segue:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Sostituisci quanto segue:

   • SEED_HOST_IP_ADDRESS con l'indirizzo IP dell'host iniziale, ad esempio 10.0.0.11.
   • DATACENTER_NAME con il nome del data center, ad esempio dc-2.
   • RACK_NAME con il nome del rack, ad esempio ra-1.
   • CLUSTER_NAME con il nome del cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome di cluster diverso, devi specificare un per cassandra.clusterName. Puoi scegliere il valore che preferisci, ma deve essere lo stesso in tutte le regioni.

Configura la seconda regione

Per configurare la nuova regione:

1. Installa cert-manager nella regione 2:

   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.1/cert-manager.yaml
   

2. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova radice dell'autorità di certificazione viene utilizzata da Cassandra e da 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 attuale in un file:

      kubectl get namespace apigee -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 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
      

3. Segui i passaggi per installare i CRD di Apigee hybrid nella nuova regione.

4. Ora utilizza i grafici Helm per installare Apigee hybrid nella nuova regione con i seguenti comandi di grafico Helm (come per la regione 1):

   Nota: puoi usare gli stessi CRD per coerenza usando il nella stessa cartella in cui hai scaricato i grafici, puoi anche il file di override univoco tra la regione 1 e la regione 2 assegnando il nome sostituisce qualcosa di univoco, ad esempio overrides-region_name.yaml e così via.
   Importante: ometti il flag ‑‑atomic per di cui è stata eseguita la migrazione.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Verifica la configurazione del cluster Cassandra eseguendo il seguente comando. L'output dovrebbe mostrare sia i data center esistenti che quelli nuovi.
   Avviso: se l'output di questo comando non mostra entrambi data center nuovi ed esistenti, la configurazione non è riuscita. In questo caso, non procedere oltre.

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Vedi Disinstallare il runtime ibrido. Se Se la configurazione non va a buon fine, non tentare di andare avanti né tentare di unirsi al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Esempio di configurazione corretta:

   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

6. Configurare Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il comando seguente:

      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"
      

   2. Crea un file di risorse personalizzate di replica dei dati Cassandra (YAML). Il file può avere un nome qualsiasi. Nei seguenti esempi il file avrà il nome datareplication.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 stai assegnando a questi metadati. Puoi puoi usare un nome qualsiasi.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
      • APIGEEORG_VALUE è il valore visualizzato dall'output del comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di overrides.yaml della regione di origine

      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"

   3. Applica CassandraDataReplication con il seguente comando:

      kubectl apply -f datareplication.yaml

7. Verifica lo stato della ricompilazione utilizzando il comando seguente.
   Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.

   kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

   I risultati dovrebbero essere simili ai seguenti:

   {
   "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
   }

8. Una volta completata e verificata la replica dei dati, aggiorna gli host di seed:
   1. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DATACENTER_NAME.yaml.

   2. Riapplica la modifica per aggiornare la RP del datastore apigee:

      Importante: ometti il flag ‑‑atomic per di cui è stata eseguita la migrazione.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Verifica i processi di ricreazione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di ricompilazione mostra lo stato completato e i log dei processi di ricreazione contengono "Tutte le sessioni completate" tutti i dati sono stati copiata correttamente nella nuova regione.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Suggerimento: APIGEE_JMX_USER e APIGEE_JMX_PASSWORD sono in genere definiti nelle variabili di ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   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

apigeectl

1. Nel file overrides.yaml del cluster originale, assicurati che cassandra:hostNetwork impostato su true. Ad esempio:

   cassandra:
     hostNetwork: true

   Per ulteriori informazioni su quando impostare hostNetwork: true, consulta Prerequisiti.

2. Se cassandra:hostNetwork non è impostato su true, procedi nel seguente modo:
   1. cassandra.hostNetwork modificato in true.
   2. Applica il file di configurazione overrides.yaml con il comando:

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi il completamento di un riavvio graduale dei pod Cassandra.

   4. Verifica che il cluster Cassandra sia integro con quanto segue :

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        

        nodetool -u  -pw APIGEE_JMX_PASSWORD status
        

      Assicurati che tutti i nodi Cassandra nell'output siano in stato UN (Up/Normal):

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
        

      Assicurati che nell'output non siano elencati nodi non raggiungibili.

3. Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seme:

   kubectl config use-context original-cluster-name

4. Esegui il seguente comando kubectl per identificare un indirizzo host iniziale per Cassandra nella regione corrente.

   Un indirizzo host di origine consente a una nuova istanza regionale di trovare originale alla primissima startup a scoprire la topologia del cluster. L'indirizzo host del seed viene designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra --field-selector status.phase=Running

   apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000

5. Decidi quale degli IP restituiti dal comando precedente sarà l'host iniziale con più regioni. In questo esempio, in cui è in esecuzione un solo cluster Cassandra a un nodo, l'host iniziale è 120.38.1.9.
6. 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.
7. 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
        hostNetwork: true

   clusterName: cluster_name # deve essere uguale per tutte le regioni

   Ad esempio:

   cassandra:
     multiRegionSeedHost: 120.38.1.9
     datacenter: "centralus"
     rack: "ra-1"
     hostNetwork: true
     clusterName: my-apigee-cluster

8. 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 come impostato nella prima regione.
   Nota: assicurati di utilizzare gli stessi certificati TLS e credenziali di Cassandra nel secondo data center fornito nel data center originale. Le credenziali che impostati nel file degli override nel primo data center devono corrispondere a quelli specificati nel il file degli override nel secondo data center. Per maggiori dettagli, consulta Configurazione di TLS per Cassandra.

Configurare la nuova regione

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

Per configurare la nuova regione:

1. Copia il tuo certificato dal cluster esistente a quello nuovo. 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 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_your_cluster_name.yaml include gli stessi certificati TLS configurati nella prima regione, come spiegate nella sezione precedente.

   Esegui questi due comandi per installare il modello ibrido nella nuova regione:

   Importante: quando espandi Apigee Hybrid a un nuovo datacenter regionale, assicurati di installare la stessa versione di Hybrid che hai nel tuo datacenter esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

3. Verifica che l'installazione ibrida sia riuscita eseguendo questo comando:

   apigeectl check-ready -f overrides_your_cluster_name.yaml

4. Verifica la configurazione del cluster Cassandra eseguendo il seguente comando. L'output dovrebbe mostrare sia i data center esistenti che quelli nuovi.
   Avviso: se l'output di questo comando non mostra entrambi data center nuovi ed esistenti, la configurazione non è riuscita. In tal caso, non proseguire più avanti.

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non tentare di procedere o di partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Esempio di configurazione corretta:

   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

5. Configura Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il comando seguente:

      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"
      

   2. Crea un file della risorsa personalizzata (YAML) per la replica dei dati di Cassandra. Il file può avere un nome qualsiasi. Nei seguenti esempi il file avrà il nome datareplication.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 stai assegnando a questi metadati. Puoi puoi usare un nome qualsiasi.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
      • APIGEEORG_VALUE è il valore di output dal kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di overrides.yaml della regione di origine

      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"

   3. Applica CassandraDataReplication con il seguente comando:

      kubectl apply -f datareplication.yaml

   4. Verifica lo stato della ricompilazione utilizzando il comando seguente.
      Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.

      kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

      I risultati dovrebbero avere il seguente aspetto:

      {
        "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
      }

6. Verifica i processi di ricreazione dai log. Verifica inoltre le dimensioni dei dati usando il comando nodetool status.
   Nota: se l'operazione di ricompilazione mostra lo stato completato e i log dei processi di ricreazione contengono "Tutte le sessioni completate" tutti i dati sono stati copiata correttamente nella nuova regione.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

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

7. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Nota: gli host di origine 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 applicare nuovamente la configurazione.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Controlla lo stato del cluster Cassandra

Il seguente comando è utile per verificare se la configurazione del cluster è andata a buon fine in due datacenter. Il comando controlla lo stato di nodetool per le due regioni.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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: 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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

OpenShift

Importante: quando espandi Apigee hybrid a un nuovo data center regionale, assicurati di installare la stessa versione di ibrido che hai nella di un data center. Evita di eseguire versioni diverse dell'ibrido in più data center.

Avviso: se l'installazione non va a buon fine per una nuova regione, non continuare con l'installazione della regione. Elimina e ricrea l'installazione ibrida nella regione con errori.

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.

Segui le procedure per lo strumento che utilizzi per gestire e installare Apigee hybrid:

Grafici Helm

1. Per la prima regione creata, ottieni i pod nel tuo spazio dei nomi apigee:

   kubectl get pods -o wide -n apigee
   

2. Identifica l'indirizzo host di origine multiregionale per Cassandra in questa regione, ad esempio 10.0.0.11.

3. Prepara il file overrides.yaml per la seconda regione e aggiungi l'indirizzo IP dell'host di origine come segue:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Sostituisci quanto segue:

   • SEED_HOST_IP_ADDRESS con l'indirizzo IP dell'host iniziale, ad esempio 10.0.0.11.
   • DATACENTER_NAME con il nome del data center, ad esempio dc-2.
   • RACK_NAME con il nome del rack, ad esempio ra-1.
   • CLUSTER_NAME con il nome del cluster Cassandra. Per impostazione predefinita, è apigeecluster. Se utilizzi un nome del cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere il valore che preferisci, ma deve essere lo stesso in tutte le regioni.

Configura la seconda regione

Per configurare la nuova regione:

1. Installa cert-manager nella regione 2:

   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.1/cert-manager.yaml
   

2. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova radice dell'autorità di certificazione viene utilizzata da Cassandra e da 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 attuale in un file:

      kubectl get namespace apigee -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 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
      

3. Segui i passaggi per Installa i CRD ibridi di Apigee nella nuova regione.

4. Ora utilizza i grafici Helm per installare Apigee Hybrid nella nuova regione con i seguenti comandi del grafico Helm (come fatto nella regione 1):

   Nota: per garantire la coerenza, puoi utilizzare gli stessi CRD utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere univoco il file delle sostituzioni tra la regione 1 e la 2 assegnando un nome univoco alle sostituzioni, ad esempio overrides-region_name.yaml e così via.
   Importante: ometti il flag ‑‑atomic per i cluster sottoposti a migrazione.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Verifica la configurazione del cluster Cassandra eseguendo il seguente comando. L'output dovrebbe mostrare sia i data center esistenti che quelli nuovi.
   Avviso: se l'output di questo comando non mostra sia i data center esistenti che quelli nuovi, la configurazione non è riuscita. In questo caso, non procedere oltre.

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Vedi Disinstallare il runtime ibrido. Se Se la configurazione non va a buon fine, non tentare di andare avanti né tentare di unirsi al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Esempio di configurazione corretta:

   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

6. Configurare Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il comando seguente:

      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"
      

   2. Crea un file di risorse personalizzate di replica dei dati Cassandra (YAML). Il file può avere un nome qualsiasi. Nei seguenti esempi il file avrà il nome datareplication.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 stai assegnando a questi metadati. Puoi puoi usare un nome qualsiasi.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
      • APIGEEORG_VALUE è il valore visualizzato dall'output del comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di overrides.yaml della regione di origine

      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"

   3. Applica CassandraDataReplication con il seguente comando:

      kubectl apply -f datareplication.yaml

7. Verifica lo stato della ricompilazione utilizzando il comando seguente.
   Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.

   kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

   I risultati dovrebbero essere simili ai seguenti:

   {
   "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
   }

8. Una volta completata e verificata la replica dei dati, aggiorna gli host di seed:
   1. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DATACENTER_NAME.yaml.

   2. Riapplica la modifica per aggiornare la RP del datastore apigee:

      Importante: ometti il flag ‑‑atomic per i cluster sottoposti a migrazione.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Verifica i processi di ricreazione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di ricostruzione mostra lo stato completato e i log dei processi di ricostruzione contengono "Tutte le sessioni completate", tutti i dati sono stati copiati correttamente nella nuova regione.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Suggerimento: APIGEE_JMX_USER e APIGEE_JMX_PASSWORD sono in genere definiti nelle variabili di ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   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

apigeectl

1. Nel file overrides.yaml del cluster originale, assicurati che cassandra:hostNetwork sia impostato su true. Ad esempio:

   cassandra:
     hostNetwork: true

   Consulta la sezione Prerequisiti per ulteriori informazioni su quando eseguire l'impostazione hostNetwork: true.

2. Se cassandra:hostNetwork non è impostato su true, procedi nel seguente modo:
   1. cassandra.hostNetwork modificato in true.
   2. Applica il file di configurazione overrides.yaml con il comando:

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi il completamento di un riavvio graduale dei pod Cassandra.

   4. Verifica che il cluster Cassandra sia integro con quanto segue :

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        

        nodetool -u  -pw APIGEE_JMX_PASSWORD status
        

      Assicurati che tutti i nodi Cassandra nell'output siano in stato UN (Up/Normal):

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
        

      Assicurati che nell'output non siano elencati nodi non raggiungibili.

3. Imposta il contesto kubectl sul cluster originale prima di recuperare il nome seed:

   kubectl config use-context original-cluster-name

4. 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 apprendere la topologia del cluster. L'indirizzo host di origine è designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra --field-selector status.phase=Running

   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

5. Seleziona l'indirizzo IP dell'host Cassandra di origine da utilizzare come host seed multi-regione. In questo esempio, il apigee-cassandra-default-0cluster è in esecuzione, l'host seed è 10.0.0.11.
6. Nel data center 2, copia il file degli override in un nuovo file il cui nome include il cluster nome. Ad esempio, overrides_your_cluster_name.yaml.
7. 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:
        hostNetwork: true
        multiRegionSeedHost: seed_host_IP # Cassandra pod IP address from the source region.
        datacenter: data_center_name
        rack: rack_name
        clusterName: cluster_name # must be the same for all regions

   Ad esempio:

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: 10.0.0.11
     datacenter: "dc-2"
     rack: "ra-1"
     clusterName: my-apigee-cluster

8. Nel nuovo data center/nella nuova regione, prima di installare la versione ibrida, imposta gli stessi certificati TLS e le stesse credenziali in overrides_your_cluster_name.yaml come hai fatto nella prima regione.
   Nota: assicurati di utilizzare gli stessi certificati TLS e credenziali di Cassandra nel secondo data center fornito nel data center originale. Le credenziali che impostati nel file degli override nel primo data center devono corrispondere a quelli specificati nel il file degli override nel secondo data center. Per maggiori dettagli, consulta 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 tuo certificato dal cluster esistente a quello nuovo. 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 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_your_cluster_name.yaml include gli stessi certificati TLS configurati nella prima regione, come spiegate nella sezione precedente.

   Esegui questi due comandi per installare il modello ibrido nella nuova regione:

   Importante: quando espandi Apigee Hybrid a un nuovo datacenter regionale, assicurati di installare la stessa versione di Hybrid che hai nel tuo datacenter esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

3. Verifica che l'installazione ibrida sia riuscita eseguendo questo comando:

   apigeectl check-ready -f overrides_your_cluster_name.yaml

4. Verifica la configurazione del cluster Cassandra eseguendo il seguente comando. L'output dovrebbe mostrare sia i data center esistenti che quelli nuovi.
   Avviso: se l'output di questo comando non mostra entrambi data center nuovi ed esistenti, la configurazione non è riuscita. In tal caso, non proseguire più avanti.

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Consulta Disinstallare il runtime di hybrid. Se Se la configurazione non va a buon fine, non tentare di andare avanti né tentare di unirsi al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Esempio di configurazione corretta:

   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

5. Configura Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il comando seguente:

      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"
      

   2. Crea un file della risorsa personalizzata (YAML) per la replica dei dati di Cassandra. Il file può avere un nome qualsiasi. Nei seguenti esempi il file avrà il nome datareplication.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 stai assegnando a questi metadati. Puoi puoi usare un nome qualsiasi.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
      • APIGEEORG_VALUE è il valore di output dal kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di overrides.yaml della regione di origine

      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"

   3. Applica CassandraDataReplication con il seguente comando:

      kubectl apply -f datareplication.yaml

   4. Verifica lo stato della ricompilazione utilizzando il comando seguente.
      Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.

      kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

      I risultati dovrebbero avere il seguente aspetto:

      {
        "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
      }

6. Verifica i processi di ricreazione dai log. Verifica inoltre le dimensioni dei dati usando il comando nodetool status.
   Nota: se l'operazione di ricompilazione mostra lo stato completato e i log dei processi di ricreazione contengono "Tutte le sessioni completate" tutti i dati sono stati copiata correttamente nella nuova regione.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

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

7. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Nota: gli host di origine 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 applicare nuovamente la configurazione.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Controlla lo stato del cluster Cassandra

Il seguente comando è utile per verificare se la configurazione del cluster è andata a buon fine in due datacenter. Il comando verifica lo stato nodetool per le due regioni.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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: 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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

Risoluzione dei problemi

Vedi Errore di replica dei dati Cassandra.