Deployment multiregionale

Al momento stai visualizzando la versione 1.11 della documentazione di Apigee hybrid. Per saperne di più, consulta Versioni supportate.

Version 1.11 

Versioni supportate:

• v1.12 (più recente)                        
• Versione 1.11                         
• Versione 1.10                                        
• Elenco delle versioni supportate

Versioni non supportate:

• Versione 1.9                                         
• Versione 1.8                                         
• Versione 1.7                                         
• Versione 1.6                                         
• Versione 1.5                                         
• Versione 1.4                                         
• Versione 1.3                                         
• Versione 1.2                                         
• Versione 1.1                                         

Questo argomento descrive un deployment in più regioni per Apigee hybrid su GKE, Anthos GKE con deployment on-prem, Microsoft® Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) e su RedHat OpenShift. Seleziona la tua piattaforma nei prerequisiti e nelle procedure.

Le topologie per il deployment su più regioni includono:

• Attivo-Attivo: se le tue applicazioni sono state distribuite in più località geografiche e hai bisogno di una risposta API a bassa latenza per i tuoi deployment. Hai la possibilità di eseguire il deployment di ibrido in più località geografiche più vicine ai tuoi clienti. Ad esempio: costa occidentale degli Stati Uniti, costa orientale degli Stati Uniti, Europa, APAC.
• Attivo-Passivo: se hai una regione principale e una regione di failover o ripristino di emergenza.

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

Prerequisiti

Prima di configurare un ambiente ibrido per più regioni, devi completare i seguenti prerequisiti:

GKE

• Quando installi deployment di Apigee in più regioni tra reti diverse (ad es.diversi cloud provider, reti VPC diverse, cloud e on-prem, ecc.), devi fornire una connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. utilizzando le VPN o le soluzioni di connettività specifiche per il cloud.
• Se utilizzi Workload Identity per eseguire l'autenticazione degli account di servizio in un cluster, ti consigliamo vivamente di utilizzare Workload Identity per ogni cluster in cui esegui l'espansione. Consulta Abilitazione di Workload Identity con Apigee hybrid.
• Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi.
• Assicurati che cert-manager sia installato in ogni cluster
• Configura 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, il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione del nome 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 la risoluzione del nome host non riesce, 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 per più regioni di Cassandra:
  • Assicurati che lo spazio dei nomi di rete dei pod disponga di connettività in tutte le regioni, inclusi firewall, VPN, peering VPC e peering vNet. Questo è il caso per la maggior parte delle installazioni GKE.
  • Se lo spazio dei nomi di rete dei pod non dispone di connettività tra i cluster (i cluster sono in esecuzione in "modalità di rete Island"), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nell'installazione multiregionale ibrida di Apigee.

    Per maggiori informazioni sulla necessità di hostNetwork, consulta Cluster in modalità Island e hostNetwork di seguito.

  • Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni.
  • Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire la ricerca DNS dei loro nomi host. Apigee Cassandra utilizza la ricerca DNS in avanti per ottenere l'IP host all'avvio.
    Suggerimento: se la risoluzione DNS non funziona, prova questa soluzione alternativa.

    Aggiungi una voce dell'host statico nel file /etc/hosts di ogni nodo worker cassandra simile alla 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 la comunicazione tra i nodi worker in più regioni e data center. Per informazioni sui numeri di porta di Cassandra, consulta Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

Nota: Apigee consiglia di garantire che gli orari dei server siano sincronizzati.

Varie funzionalità, come la scadenza e la revoca dei token, si basano su tempi di sistema precisi. Se ospiti i componenti di runtime in data center diversi, assicurati che gli orari di sistema siano sincronizzati.

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

GKE On-Prem

• Quando installi deployment di Apigee in più regioni tra reti diverse (ad es.diversi cloud provider, reti VPC diverse, cloud e on-prem, ecc.), devi fornire una connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. utilizzando le VPN o le soluzioni di connettività specifiche per il cloud.
• Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi.
• Assicurati che cert-manager sia installato in ogni cluster
• Configura 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, il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione del nome 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 la risoluzione del nome host non riesce, 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 per più regioni di Cassandra:
  • Se lo spazio dei nomi di rete dei pod non dispone di connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isola", il caso predefinito nelle installazioni di GKE on-prem), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nell'installazione multiregionale ibrida di Apigee.

    Per maggiori informazioni sulla necessità di hostNetwork, consulta Cluster in modalità Island e hostNetwork di seguito.

  • Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni.
  • Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire la ricerca DNS dei loro nomi host. Apigee Cassandra utilizza la ricerca DNS in avanti per ottenere l'IP host all'avvio.
    Suggerimento: se la risoluzione DNS non funziona, prova questa soluzione alternativa.

    Aggiungi una voce dell'host statico nel file /etc/hosts di ogni nodo worker cassandra simile alla 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 la comunicazione tra i nodi worker tra regioni e data center. Consulta Configurare le porte per i numeri di porta di Cassandra.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

Nota: Apigee consiglia di garantire che gli orari dei server siano sincronizzati.

Varie funzionalità, come la scadenza e la revoca dei token, si basano su tempi di sistema precisi. Se ospiti i componenti di runtime in data center diversi, 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 di Apigee in più regioni tra reti diverse (ad es.diversi cloud provider, reti VPC diverse, cloud e on-prem, ecc.), devi fornire una connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. utilizzando le VPN o le soluzioni di connettività specifiche per il cloud.
• Segui la guida all'installazione ibrida per eventuali prerequisiti come Google Cloud e la configurazione 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 è il nome del pod Cassandra. Se hostNetwork è impostato su true, il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione del nome 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 la risoluzione del nome host non riesce, 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 per più regioni di Cassandra:
  • Se lo spazio dei nomi di rete dei pod non dispone di connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isola", il caso predefinito nelle installazioni AKS), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nell'installazione multiregionale ibrida Apigee.

    Per maggiori informazioni sulla necessità di hostNetwork, consulta Cluster in modalità Island e hostNetwork di seguito.

  • Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni.
  • Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire la ricerca DNS dei loro nomi host. Apigee Cassandra utilizza la ricerca DNS in avanti per ottenere l'IP host all'avvio.
    Suggerimento: se la risoluzione DNS non funziona, prova questa soluzione alternativa.

    Aggiungi una voce dell'host statico nel file /etc/hosts di ogni nodo worker cassandra simile alla 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 la comunicazione tra i nodi worker tra regioni e data center. Consulta Configurare le porte per i numeri di porta di Cassandra.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

Nota: Apigee consiglia di garantire che gli orari dei server siano sincronizzati.

Varie funzionalità, come la scadenza e la revoca dei token, si basano su tempi di sistema precisi. Se ospiti i componenti di runtime in data center diversi, assicurati che gli orari di sistema siano sincronizzati.

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

EKS

• Quando installi deployment di Apigee in più regioni tra reti diverse (ad es.diversi cloud provider, reti VPC diverse, cloud e on-prem, ecc.), devi fornire una connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. utilizzando le VPN o le soluzioni di connettività specifiche per il cloud.
• Segui la guida all'installazione ibrida per eventuali prerequisiti come Google Cloud e la configurazione 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 è il nome del pod Cassandra. Se hostNetwork è impostato su true, il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione del nome 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 la risoluzione del nome host non riesce, 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 per più regioni di Cassandra:
  • Se lo spazio dei nomi di rete dei pod non dispone di connettività tra i cluster (i cluster sono in esecuzione in "modalità di rete Island"), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nell'installazione multiregionale ibride di Apigee. Per impostazione predefinita, Amazon EKS utilizza il modello di rete completamente integrato.

    Per maggiori informazioni sulla necessità di hostNetwork, consulta Cluster in modalità Island e hostNetwork di seguito.

  • Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni.
  • Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire la ricerca DNS dei loro nomi host. Apigee Cassandra utilizza la ricerca DNS in avanti per ottenere l'IP host all'avvio.
    Suggerimento: se la risoluzione DNS non funziona, prova questa soluzione alternativa.

    Aggiungi una voce dell'host statico nel file /etc/hosts di ogni nodo worker cassandra simile alla 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 la comunicazione tra i nodi worker tra regioni e data center. Consulta Configurare le porte per i numeri di porta di Cassandra.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

Nota: Apigee consiglia di garantire che gli orari dei server siano sincronizzati.

Varie funzionalità, come la scadenza e la revoca dei token, si basano su tempi di sistema precisi. Se ospiti i componenti di runtime in data center diversi, assicurati che gli orari di sistema siano sincronizzati.

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

OpenShift

• Quando installi deployment di Apigee in più regioni tra reti diverse (ad es.diversi cloud provider, reti VPC diverse, cloud e on-prem, ecc.), devi fornire una connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. utilizzando le VPN o le soluzioni di connettività specifiche per il cloud.
• Segui la guida all'installazione ibrida per eventuali prerequisiti come Google Cloud e la configurazione 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 è il nome del pod Cassandra. Se hostNetwork è impostato su true, il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione del nome 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 la risoluzione del nome host non riesce, 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 per più regioni di Cassandra:
  • Se lo spazio dei nomi di rete dei pod non dispone di connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isola", il caso predefinito nelle installazioni di OpenShift), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nell'installazione multiregionale ibrida di Apigee.

    Per maggiori informazioni sulla necessità di hostNetwork, consulta Cluster in modalità Island e hostNetwork di seguito.

  • Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni.
  • Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire la ricerca DNS dei loro nomi host. Apigee Cassandra utilizza la ricerca DNS in avanti per ottenere l'IP host all'avvio.
    Suggerimento: se la risoluzione DNS non funziona, prova questa soluzione alternativa.

    Aggiungi una voce dell'host statico nel file /etc/hosts di ogni nodo worker cassandra simile alla 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 la comunicazione tra i nodi worker tra regioni e data center. Consulta Configurare le porte per i numeri di porta di Cassandra.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

Nota: Apigee consiglia di garantire che gli orari dei server siano sincronizzati.

Varie funzionalità, come la scadenza e la revoca dei token, si basano su tempi di sistema precisi. Se ospiti i componenti di runtime in data center diversi, assicurati che gli orari di 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 integrati (o flat) e in modalità a isola. Apigee consiglia di utilizzare il modello di rete piatta, ove possibile, in quanto semplifica la connettività Cassandra multiregionale. Quando un cluster Kubernetes è configurato in modalità isola, la rete di pod è isolata. I pod non possono comunicare direttamente con i pod in esecuzione in altri cluster utilizzando l'indirizzo IP dei pod. Consulta le implementazioni tipiche dei modelli di rete per ulteriori informazioni sulle differenze tra questi due modelli di rete e per gli esempi di ciascuno.

Quando Apigee Hybrid è in esecuzione su due o più cluster Kubernetes utilizzando un modello di networking in modalità isola, è necessario abilitare l'impostazione hostNetwork per Cassandra tramite la proprietà cassandra.hostNetwork. Per impostazione predefinita, i pod Kubernetes vengono isolati in singoli spazi dei nomi di rete, impedendo loro di utilizzare l'IP del nodo worker di Kubernetes. Quando hostNetwork è impostato su true, il pod non è isolato all'interno del proprio spazio dei nomi di rete, ma utilizza l'indirizzo IP e il nome host del nodo worker Kubernetes su cui è pianificato il pod. Questo consente a Cassandra di utilizzare in modo nativo l'IP del nodo worker Kubernetes come IP, il che consente a Cassandra di stabilire un mesh completo tra tutti i pod Cassandra in più cluster in esecuzione in modalità isola.

Risoluzione del nome host Cassandra

Sebbene un pod Cassandra non risolva altri pod Cassandra in base al nome host, all'avvio Cassandra verifica che il suo nome host sia risolvibile dal DNS. Poiché il nome host del pod è uguale al nome host del nodo worker Kubernetes quando hostNetwork è impostato su true, il nome host del nodo worker deve essere risolvibile in un indirizzo IP tramite il servizio DNS del cluster. Se il nome host del nodo worker Kubernetes non è risolvibile, il pod Cassandra non verrà avviato completamente. Pertanto, è importante che i nomi host dei nodi worker Kubernetes siano risolvibili dai pod nel cluster quando si imposta hostNetwork su true.

Configura Apigee hybrid per più regioni

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

GKE

Importante: quando espandi la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center esistente. 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 proseguire con l'installazione. Elimina e ricrea l'installazione ibrida nella regione che non ha superato il test.

Configura l'host seed a più regioni

Questa sezione descrive come espandere il cluster Cassandra esistente a una nuova regione. Questa configurazione consente alla nuova regione di eseguire il bootstrap del cluster e unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si sarebbero a conoscenza gli uni degli altri.

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

Grafici Helm

1. Per la prima regione creata, ottieni i pod nello 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 originale, 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 tuo cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome di cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere liberamente il valore che preferisci, 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 CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Di conseguenza, è 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 l'attuale configurazione dello spazio dei nomi 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 ibridi 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: puoi utilizzare gli stessi CRD per coerenza utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere il file di override univoco tra la regione 1 e la 2 assegnando un nome univoco agli override, come overrides-region_name.yaml e così via.
   Importante: ometti il flag ‑‑atomic per i cluster 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 nuovi sia quelli esistenti.
   Avviso: se l'output di questo comando non mostra sia i data center nuovi sia quelli esistenti, significa che la configurazione non è riuscita. In questo caso, non proseguire.

   Per risolvere il problema, è necessario eliminare e ricreare l'installazione ibrida nella nuova regione. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non provare a proseguire o a partecipare al cluster.

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

   Esempio che mostra una configurazione riuscita:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

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

      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Ad esempio:

      Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

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

      Ad esempio:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: region-expansion
      namespace: apigee
      spec:
      organizationRef: rg-hybrid-b7d3b9c
      force: false
      source:
      region: "dc-1"

   3. Applica CassandraDataReplication con il comando seguente:

      kubectl apply -f datareplication.yaml

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

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

   I risultati dovrebbero avere un aspetto simile a questo:

   {
   "rebuildDetails": {
   "apigee-cassandra-default-0": {
   "state": "complete",
   "updated": 1623105760
   },
   "apigee-cassandra-default-1": {
   "state": "complete",
   "updated": 1623105765
   },
   "apigee-cassandra-default-2": {
   "state": "complete",
   "updated": 1623105770
   }
   },
   "state": "complete",
   "updated": 1623105770
   }

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

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

      Importante: ometti il flag ‑‑atomic per i cluster 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 nuova creazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di nuova creazione mostra lo stato completato e i log dei processi di nuova creazione 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 di solito definiti nelle variabili di ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   Nell'esempio seguente sono riportate voci di log di esempio:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

apigeectl

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

   kubectl config use-context original-cluster-name

2. Esegui questo comando kubectl per identificare un indirizzo host originale per Cassandra nella regione attuale.

   Un indirizzo host originale consente a una nuova istanza di regione di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host originale viene designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee -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 seed a 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 o nella nuova regione, prima di installare l'ambiente ibrido, imposta in overrides.yaml i certificati e le credenziali TLS che hai impostato nella prima regione.
   Nota: assicurati di utilizzare nel secondo data center gli stessi certificati e credenziali TLS di Cassandra che hai fornito nel data center originale. Le credenziali impostate nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, consulta la pagina relativa alla configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host originale, puoi impostare la nuova regione.

Per configurare la nuova regione:

1. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Pertanto, è essenziale disporre di certificati coerenti in tutto il cluster.
   1. Imposta il contesto sullo spazio dei nomi originale:

      kubectl config use-context original-cluster-name

   2. Esporta la configurazione attuale dello spazio dei nomi 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 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

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

   Esegui questi due comandi per installare l'ambiente ibrido nella nuova regione:

   Importante: quando espandi la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center 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 vada a buon fine eseguendo questo comando:

   apigeectl check-ready -f overrides_DC_name.yaml

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

   Per risolvere il problema, è necessario eliminare e ricreare l'installazione ibrida nella nuova regione. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non provare a proseguire o a partecipare al cluster.

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

   Esempio che mostra una configurazione riuscita:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

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

      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Ad esempio:

      Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

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

      Ad esempio:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: region-expansion
        namespace: apigee
      spec:
        organizationRef: rg-hybrid-b7d3b9c
        force: false
        source:
          region: "dc-1"

   3. Applica CassandraDataReplication con il comando seguente:

      kubectl apply -f datareplication.yaml

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

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

      I risultati dovrebbero avere un aspetto simile a questo:

      {
        "rebuildDetails": {
          "apigee-cassandra-default-0": {
            "state": "complete",
            "updated": 1623105760
          },
          "apigee-cassandra-default-1": {
            "state": "complete",
            "updated": 1623105765
          },
          "apigee-cassandra-default-2": {
            "state": "complete",
            "updated": 1623105770
          }
        },
        "state": "complete",
        "updated": 1623105770
      }

6. Verifica i processi di nuova creazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di nuova creazione mostra lo stato completato e i log dei processi di nuova creazione 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

   Nell'esempio seguente sono riportate voci di log di esempio:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

7. Aggiornare gli host di origine. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Nota: gli host origine sono membri del cluster locale. Per avviare una nuova regione, è necessario un host originale esterno. Una volta avviata una regione, devi riportare gli host di origine ai 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 comando seguente è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato del nodetool per le due regioni.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u 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 la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center esistente. 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 proseguire con l'installazione. Elimina e ricrea l'installazione ibrida nella regione che non ha superato il test.

Configura l'host seed a più regioni

Questa sezione descrive come espandere il cluster Cassandra esistente a una nuova regione. Questa configurazione consente alla nuova regione di eseguire il bootstrap del cluster e unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si sarebbero a conoscenza gli uni degli altri.

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

Grafici Helm

1. Per la prima regione creata, ottieni i pod nello 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 originale, 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 tuo cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome di cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere liberamente il valore che preferisci, 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 CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Di conseguenza, è 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 l'attuale configurazione dello spazio dei nomi 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 ibridi 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: puoi utilizzare gli stessi CRD per coerenza utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere il file di override univoco tra la regione 1 e la 2 assegnando un nome univoco agli override, come overrides-region_name.yaml e così via.
   Importante: ometti il flag ‑‑atomic per i cluster 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 nuovi sia quelli esistenti.
   Avviso: se l'output di questo comando non mostra sia i data center nuovi sia quelli esistenti, significa che la configurazione non è riuscita. In questo caso, non proseguire.

   Per risolvere il problema, è necessario eliminare e ricreare l'installazione ibrida nella nuova regione. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non provare a proseguire o a partecipare al cluster.

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

   Esempio che mostra una configurazione riuscita:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

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

      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Ad esempio:

      Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

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

      Ad esempio:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: region-expansion
      namespace: apigee
      spec:
      organizationRef: rg-hybrid-b7d3b9c
      force: false
      source:
      region: "dc-1"

   3. Applica CassandraDataReplication con il comando seguente:

      kubectl apply -f datareplication.yaml

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

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

   I risultati dovrebbero avere un aspetto simile a questo:

   {
   "rebuildDetails": {
   "apigee-cassandra-default-0": {
   "state": "complete",
   "updated": 1623105760
   },
   "apigee-cassandra-default-1": {
   "state": "complete",
   "updated": 1623105765
   },
   "apigee-cassandra-default-2": {
   "state": "complete",
   "updated": 1623105770
   }
   },
   "state": "complete",
   "updated": 1623105770
   }

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

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

      Importante: ometti il flag ‑‑atomic per i cluster 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 nuova creazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di nuova creazione mostra lo stato completato e i log dei processi di nuova creazione 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 di solito definiti nelle variabili di ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   Nell'esempio seguente sono riportate voci di log di esempio:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

apigeectl

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

   cassandra:
     hostNetwork: true

   Consulta i prerequisiti per maggiori informazioni su quando impostare hostNetwork: true.

2. Se cassandra:hostNetwork non è impostato su true:
   1. Cambia cassandra.hostNetwork in true.
   2. Applica il file di configurazione overrides.yaml con il comando:

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi che i pod Cassandra completino un riavvio in sequenza.

   4. Verifica che il cluster Cassandra sia integro utilizzando i seguenti comandi:

        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 seed:

   kubectl config use-context original-cluster-name

4. Esegui questo comando kubectl per identificare un indirizzo host originale per Cassandra nella regione attuale.

   Un indirizzo host originale consente a una nuova istanza di regione di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host originale viene designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee -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 seed a più regioni.
6. Nel data center 2, configura cassandra.multiRegionSeedHost nel file di override, 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 o nella nuova regione, prima di installare l'ambiente ibrido, imposta in overrides.yaml i certificati e le credenziali TLS che hai impostato nella prima regione.
   Nota: assicurati di utilizzare nel secondo data center gli stessi certificati e credenziali TLS di Cassandra che hai fornito nel data center originale. Le credenziali impostate nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, consulta la pagina relativa alla configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host originale, puoi impostare la nuova regione.

Per configurare la nuova regione:

1. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Pertanto, è essenziale disporre di certificati coerenti in tutto il cluster.
   1. Imposta il contesto sullo spazio dei nomi originale:

      kubectl config use-context original-cluster-name

   2. Esporta la configurazione attuale dello spazio dei nomi 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 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

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

   Esegui questi due comandi per installare l'ambiente ibrido nella nuova regione:

   Importante: quando espandi la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center 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 vada a buon fine eseguendo questo comando:

   apigeectl check-ready -f overrides_DC_name.yaml

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

   Per risolvere il problema, è necessario eliminare e ricreare l'installazione ibrida nella nuova regione. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non provare a proseguire o a partecipare al cluster.

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

   Esempio che mostra una configurazione riuscita:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

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

      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Ad esempio:

      Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

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

      Ad esempio:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: region-expansion
        namespace: apigee
      spec:
        organizationRef: rg-hybrid-b7d3b9c
        force: false
        source:
          region: "dc-1"

   3. Applica CassandraDataReplication con il comando seguente:

      kubectl apply -f datareplication.yaml

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

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

      I risultati dovrebbero avere un aspetto simile a questo:

      {
        "rebuildDetails": {
          "apigee-cassandra-default-0": {
            "state": "complete",
            "updated": 1623105760
          },
          "apigee-cassandra-default-1": {
            "state": "complete",
            "updated": 1623105765
          },
          "apigee-cassandra-default-2": {
            "state": "complete",
            "updated": 1623105770
          }
        },
        "state": "complete",
        "updated": 1623105770
      }

6. Verifica i processi di nuova creazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di nuova creazione mostra lo stato completato e i log dei processi di nuova creazione 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

   Nell'esempio seguente sono riportate voci di log di esempio:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

7. Aggiornare gli host di origine. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Nota: gli host origine sono membri del cluster locale. Per avviare una nuova regione, è necessario un host originale esterno. Una volta avviata una regione, devi riportare gli host di origine ai 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 comando seguente è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato del nodetool per le due regioni.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u 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 la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center esistente. 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 proseguire con l'installazione. Elimina e ricrea l'installazione ibrida nella regione che non ha superato il test.

Crea una rete virtuale in ogni regione

Segui i suggerimenti di Azure per stabilire una comunicazione tra regioni qui: VNet-to-VNet: connessione di reti virtuali in Azure in diverse regioni.

Crea cluster multiregionali

Configurare i cluster Kubernetes in più regioni con blocchi CIDR diversi. Vedi anche 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 la comunicazione tra i nodi worker tra regioni e data center. Consulta Configurare le porte per i numeri di porta di Cassandra.

Configura l'host seed a più regioni

Questa sezione descrive come espandere il cluster Cassandra esistente a una nuova regione. Questa configurazione consente alla nuova regione di eseguire il bootstrap del cluster e unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si sarebbero a conoscenza gli uni degli altri.

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

Grafici Helm

1. Per la prima regione creata, ottieni i pod nello 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 originale, 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 tuo cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome di cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere liberamente il valore che preferisci, 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 CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Di conseguenza, è 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 l'attuale configurazione dello spazio dei nomi 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 ibridi 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: puoi utilizzare gli stessi CRD per coerenza utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere il file di override univoco tra la regione 1 e la 2 assegnando un nome univoco agli override, come overrides-region_name.yaml e così via.
   Importante: ometti il flag ‑‑atomic per i cluster 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 nuovi sia quelli esistenti.
   Avviso: se l'output di questo comando non mostra sia i data center nuovi sia quelli esistenti, significa che la configurazione non è riuscita. In questo caso, non proseguire.

   Per risolvere il problema, è necessario eliminare e ricreare l'installazione ibrida nella nuova regione. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non provare a proseguire o a partecipare al cluster.

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

   Esempio che mostra una configurazione riuscita:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

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

      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Ad esempio:

      Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

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

      Ad esempio:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: region-expansion
      namespace: apigee
      spec:
      organizationRef: rg-hybrid-b7d3b9c
      force: false
      source:
      region: "dc-1"

   3. Applica CassandraDataReplication con il comando seguente:

      kubectl apply -f datareplication.yaml

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

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

   I risultati dovrebbero avere un aspetto simile a questo:

   {
   "rebuildDetails": {
   "apigee-cassandra-default-0": {
   "state": "complete",
   "updated": 1623105760
   },
   "apigee-cassandra-default-1": {
   "state": "complete",
   "updated": 1623105765
   },
   "apigee-cassandra-default-2": {
   "state": "complete",
   "updated": 1623105770
   }
   },
   "state": "complete",
   "updated": 1623105770
   }

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

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

      Importante: ometti il flag ‑‑atomic per i cluster 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 nuova creazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di nuova creazione mostra lo stato completato e i log dei processi di nuova creazione 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 di solito definiti nelle variabili di ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   Nell'esempio seguente sono riportate voci di log di esempio:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

apigeectl

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

   cassandra:
     hostNetwork: true

   Consulta i prerequisiti per maggiori informazioni su quando impostare hostNetwork: true.

2. Se cassandra:hostNetwork non è impostato su true:
   1. Cambia cassandra.hostNetwork in true.
   2. Applica il file di configurazione overrides.yaml con il comando:

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi che i pod Cassandra completino un riavvio in sequenza.

   4. Verifica che il cluster Cassandra sia integro utilizzando i seguenti comandi:

        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 seed:

   kubectl config use-context original-cluster-name

4. Esegui questo comando kubectl per identificare un indirizzo host originale per Cassandra nella regione attuale.

   Un indirizzo host originale consente a una nuova istanza di regione di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host originale viene designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee -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 seed a più regioni. In questo esempio, dove è in esecuzione un solo cluster cassandra a nodo singolo, l'host seed è 120.38.1.9.
6. Nel data center 2, copia il file di override 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 o nella nuova regione, prima di installare l'ambiente ibrido, imposta in overrides_your_cluster_name.yaml i certificati e le credenziali TLS che hai impostato nella prima regione.
   Nota: assicurati di utilizzare nel secondo data center gli stessi certificati e credenziali TLS di Cassandra che hai fornito nel data center originale. Le credenziali impostate nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, consulta la pagina relativa alla configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host originale, puoi impostare la nuova regione.

Per configurare la nuova regione:

1. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Pertanto, è essenziale disporre di certificati coerenti in tutto il cluster.
   1. Imposta il contesto sullo spazio dei nomi originale:

      kubectl config use-context original-cluster-name

   2. Esporta la configurazione attuale dello spazio dei nomi 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 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

2. Installa ibrido nella nuova regione. Assicurati che il file overrides_your_cluster_name.yaml includa gli stessi certificati TLS configurati nella prima regione, come spiegato nella sezione precedente.

   Esegui questi due comandi per installare l'ambiente ibrido nella nuova regione:

   Importante: quando espandi la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center 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 vada a buon fine eseguendo questo comando:

   apigeectl check-ready -f overrides_your_cluster_name.yaml

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

   Per risolvere il problema, è necessario eliminare e ricreare l'installazione ibrida nella nuova regione. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non provare a proseguire o a partecipare al cluster.

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

   Esempio che mostra una configurazione riuscita:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

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

      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Ad esempio:

      Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

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

      Ad esempio:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: region-expansion
        namespace: apigee
      spec:
        organizationRef: rg-hybrid-b7d3b9c
        force: false
        source:
          region: "dc-1"

   3. Applica CassandraDataReplication con il comando seguente:

      kubectl apply -f datareplication.yaml

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

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

      I risultati dovrebbero avere un aspetto simile a questo:

      {
        "rebuildDetails": {
          "apigee-cassandra-default-0": {
            "state": "complete",
            "updated": 1623105760
          },
          "apigee-cassandra-default-1": {
            "state": "complete",
            "updated": 1623105765
          },
          "apigee-cassandra-default-2": {
            "state": "complete",
            "updated": 1623105770
          }
        },
        "state": "complete",
        "updated": 1623105770
      }

6. Verifica i processi di nuova creazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di nuova creazione mostra lo stato completato e i log dei processi di nuova creazione 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

   Nell'esempio seguente sono riportate voci di log di esempio:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

7. Aggiornare gli host di origine. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Nota: gli host origine sono membri del cluster locale. Per avviare una nuova regione, è necessario un host originale esterno. Una volta avviata una regione, devi riportare gli host di origine ai 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 comando seguente è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato del nodetool per le due regioni.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u 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 la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center esistente. Evita di eseguire versioni diverse dell'ibrido in più data center. Questa limitazione non si applica quando esegui l'upgrade di più data center a una nuova versione.

Avviso:se l'installazione non va a buon fine per una nuova regione, non proseguire con l'installazione. Elimina e ricrea l'installazione ibrida nella regione che non ha superato il test.

Crea una rete virtuale in ogni regione

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

Crea cluster multiregionali

Configurare i cluster Kubernetes in più regioni con blocchi CIDR diversi. Vedi anche 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 la comunicazione tra i nodi worker tra regioni e data center. Consulta Configurare le porte per i numeri di porta di Cassandra.

Configura l'host seed a più regioni

Questa sezione descrive come espandere il cluster Cassandra esistente a una nuova regione. Questa configurazione consente alla nuova regione di eseguire il bootstrap del cluster e unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si sarebbero a conoscenza gli uni degli altri.

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

Grafici Helm

1. Per la prima regione creata, ottieni i pod nello 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 originale, 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 tuo cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome di cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere liberamente il valore che preferisci, 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 CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Di conseguenza, è 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 l'attuale configurazione dello spazio dei nomi 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 ibridi 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: puoi utilizzare gli stessi CRD per coerenza utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere il file di override univoco tra la regione 1 e la 2 assegnando un nome univoco agli override, come overrides-region_name.yaml e così via.
   Importante: ometti il flag ‑‑atomic per i cluster 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 nuovi sia quelli esistenti.
   Avviso: se l'output di questo comando non mostra sia i data center nuovi sia quelli esistenti, significa che la configurazione non è riuscita. In questo caso, non proseguire.

   Per risolvere il problema, è necessario eliminare e ricreare l'installazione ibrida nella nuova regione. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non provare a proseguire o a partecipare al cluster.

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

   Esempio che mostra una configurazione riuscita:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

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

      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Ad esempio:

      Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

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

      Ad esempio:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: region-expansion
      namespace: apigee
      spec:
      organizationRef: rg-hybrid-b7d3b9c
      force: false
      source:
      region: "dc-1"

   3. Applica CassandraDataReplication con il comando seguente:

      kubectl apply -f datareplication.yaml

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

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

   I risultati dovrebbero avere un aspetto simile a questo:

   {
   "rebuildDetails": {
   "apigee-cassandra-default-0": {
   "state": "complete",
   "updated": 1623105760
   },
   "apigee-cassandra-default-1": {
   "state": "complete",
   "updated": 1623105765
   },
   "apigee-cassandra-default-2": {
   "state": "complete",
   "updated": 1623105770
   }
   },
   "state": "complete",
   "updated": 1623105770
   }

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

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

      Importante: ometti il flag ‑‑atomic per i cluster 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 nuova creazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di nuova creazione mostra lo stato completato e i log dei processi di nuova creazione 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 di solito definiti nelle variabili di ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   Nell'esempio seguente sono riportate voci di log di esempio:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

apigeectl

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

   cassandra:
     hostNetwork: true

   Consulta i prerequisiti per maggiori informazioni su quando impostare hostNetwork: true.

2. Se cassandra:hostNetwork non è impostato su true:
   1. Cambia cassandra.hostNetwork in true.
   2. Applica il file di configurazione overrides.yaml con il comando:

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi che i pod Cassandra completino un riavvio in sequenza.

   4. Verifica che il cluster Cassandra sia integro utilizzando i seguenti comandi:

        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 seed:

   kubectl config use-context original-cluster-name

4. Esegui questo comando kubectl per identificare un indirizzo host originale per Cassandra nella regione attuale.

   Un indirizzo host originale consente a una nuova istanza di regione di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host originale viene designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee -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 seed a più regioni. In questo esempio, dove è in esecuzione un solo cluster cassandra a nodo singolo, l'host seed è 120.38.1.9.
6. Nel data center 2, copia il file di override 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 o nella nuova regione, prima di installare l'ambiente ibrido, imposta in overrides_your_cluster_name.yaml i certificati e le credenziali TLS che hai impostato nella prima regione.
   Nota: assicurati di utilizzare nel secondo data center gli stessi certificati e credenziali TLS di Cassandra che hai fornito nel data center originale. Le credenziali impostate nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, consulta la pagina relativa alla configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host originale, puoi impostare la nuova regione.

Per configurare la nuova regione:

1. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Pertanto, è essenziale disporre di certificati coerenti in tutto il cluster.
   1. Imposta il contesto sullo spazio dei nomi originale:

      kubectl config use-context original-cluster-name

   2. Esporta la configurazione attuale dello spazio dei nomi 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 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

2. Installa ibrido nella nuova regione. Assicurati che il file overrides_your_cluster_name.yaml includa gli stessi certificati TLS configurati nella prima regione, come spiegato nella sezione precedente.

   Esegui questi due comandi per installare l'ambiente ibrido nella nuova regione:

   Importante: quando espandi la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center 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 vada a buon fine eseguendo questo comando:

   apigeectl check-ready -f overrides_your_cluster_name.yaml

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

   Per risolvere il problema, è necessario eliminare e ricreare l'installazione ibrida nella nuova regione. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non provare a proseguire o a partecipare al cluster.

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

   Esempio che mostra una configurazione riuscita:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

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

      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Ad esempio:

      Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

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

      Ad esempio:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: region-expansion
        namespace: apigee
      spec:
        organizationRef: rg-hybrid-b7d3b9c
        force: false
        source:
          region: "dc-1"

   3. Applica CassandraDataReplication con il comando seguente:

      kubectl apply -f datareplication.yaml

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

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

      I risultati dovrebbero avere un aspetto simile a questo:

      {
        "rebuildDetails": {
          "apigee-cassandra-default-0": {
            "state": "complete",
            "updated": 1623105760
          },
          "apigee-cassandra-default-1": {
            "state": "complete",
            "updated": 1623105765
          },
          "apigee-cassandra-default-2": {
            "state": "complete",
            "updated": 1623105770
          }
        },
        "state": "complete",
        "updated": 1623105770
      }

6. Verifica i processi di nuova creazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di nuova creazione mostra lo stato completato e i log dei processi di nuova creazione 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

   Nell'esempio seguente sono riportate voci di log di esempio:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

7. Aggiornare gli host di origine. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Nota: gli host origine sono membri del cluster locale. Per avviare una nuova regione, è necessario un host originale esterno. Una volta avviata una regione, devi riportare gli host di origine ai 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 comando seguente è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato del nodetool per le due regioni.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u 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 la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center esistente. 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 proseguire con l'installazione. Elimina e ricrea l'installazione ibrida nella regione che non ha superato il test.

Configura l'host seed a più regioni

Questa sezione descrive come espandere il cluster Cassandra esistente a una nuova regione. Questa configurazione consente alla nuova regione di eseguire il bootstrap del cluster e unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si sarebbero a conoscenza gli uni degli altri.

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

Grafici Helm

1. Per la prima regione creata, ottieni i pod nello 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 originale, 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 tuo cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome di cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere liberamente il valore che preferisci, 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 CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Di conseguenza, è 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 l'attuale configurazione dello spazio dei nomi 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 ibridi 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: puoi utilizzare gli stessi CRD per coerenza utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere il file di override univoco tra la regione 1 e la 2 assegnando un nome univoco agli override, come overrides-region_name.yaml e così via.
   Importante: ometti il flag ‑‑atomic per i cluster 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 nuovi sia quelli esistenti.
   Avviso: se l'output di questo comando non mostra sia i data center nuovi sia quelli esistenti, significa che la configurazione non è riuscita. In questo caso, non proseguire.

   Per risolvere il problema, è necessario eliminare e ricreare l'installazione ibrida nella nuova regione. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non provare a proseguire o a partecipare al cluster.

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

   Esempio che mostra una configurazione riuscita:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

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

      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Ad esempio:

      Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

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

      Ad esempio:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: region-expansion
      namespace: apigee
      spec:
      organizationRef: rg-hybrid-b7d3b9c
      force: false
      source:
      region: "dc-1"

   3. Applica CassandraDataReplication con il comando seguente:

      kubectl apply -f datareplication.yaml

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

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

   I risultati dovrebbero avere un aspetto simile a questo:

   {
   "rebuildDetails": {
   "apigee-cassandra-default-0": {
   "state": "complete",
   "updated": 1623105760
   },
   "apigee-cassandra-default-1": {
   "state": "complete",
   "updated": 1623105765
   },
   "apigee-cassandra-default-2": {
   "state": "complete",
   "updated": 1623105770
   }
   },
   "state": "complete",
   "updated": 1623105770
   }

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

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

      Importante: ometti il flag ‑‑atomic per i cluster 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 nuova creazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di nuova creazione mostra lo stato completato e i log dei processi di nuova creazione 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 di solito definiti nelle variabili di ambiente $APIGEE_JMX_USER e $APIGEE_JMX_PASSWORD.

   Nell'esempio seguente sono riportate voci di log di esempio:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

apigeectl

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

   cassandra:
     hostNetwork: true

   Consulta i prerequisiti per maggiori informazioni su quando impostare hostNetwork: true.

2. Se cassandra:hostNetwork non è impostato su true:
   1. Cambia cassandra.hostNetwork in true.
   2. Applica il file di configurazione overrides.yaml con il comando:

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi che i pod Cassandra completino un riavvio in sequenza.

   4. Verifica che il cluster Cassandra sia integro utilizzando i seguenti comandi:

        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 seed:

   kubectl config use-context original-cluster-name

4. Esegui questo comando kubectl per identificare un indirizzo host originale per Cassandra nella regione attuale.

   Un indirizzo host originale consente a una nuova istanza di regione di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host originale viene designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee -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 a più regioni. In questo esempio, il cluster apigee-cassandra-default-0è in esecuzione e l'host seed è 10.0.0.11.
6. Nel data center 2, copia il file di override 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:
        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 o nella nuova regione, prima di installare l'ambiente ibrido, imposta in overrides_your_cluster_name.yaml i certificati e le credenziali TLS che hai impostato nella prima regione.
   Nota: assicurati di utilizzare nel secondo data center gli stessi certificati e credenziali TLS di Cassandra che hai fornito nel data center originale. Le credenziali impostate nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, consulta la pagina relativa alla configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host originale, puoi impostare la nuova regione.

Per configurare la nuova regione:

1. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova CA radice viene utilizzata da Cassandra e da altri componenti ibridi per mTLS. Pertanto, è essenziale disporre di certificati coerenti in tutto il cluster.
   1. Imposta il contesto sullo spazio dei nomi originale:

      kubectl config use-context original-cluster-name

   2. Esporta la configurazione attuale dello spazio dei nomi 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 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

2. Installa ibrido nella nuova regione. Assicurati che il file overrides_your_cluster_name.yaml includa gli stessi certificati TLS configurati nella prima regione, come spiegato nella sezione precedente.

   Esegui questi due comandi per installare l'ambiente ibrido nella nuova regione:

   Importante: quando espandi la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center 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 vada a buon fine eseguendo questo comando:

   apigeectl check-ready -f overrides_your_cluster_name.yaml

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

   Per risolvere il problema, è necessario eliminare e ricreare l'installazione ibrida nella nuova regione. Vedi Disinstallare il runtime ibrido. Se la configurazione non va a buon fine, non provare a proseguire o a partecipare al cluster.

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

   Esempio che mostra una configurazione riuscita:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

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

      kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      

      Ad esempio:

      Ex: kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

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

      Ad esempio:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: region-expansion
        namespace: apigee
      spec:
        organizationRef: rg-hybrid-b7d3b9c
        force: false
        source:
          region: "dc-1"

   3. Applica CassandraDataReplication con il comando seguente:

      kubectl apply -f datareplication.yaml

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

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

      I risultati dovrebbero avere un aspetto simile a questo:

      {
        "rebuildDetails": {
          "apigee-cassandra-default-0": {
            "state": "complete",
            "updated": 1623105760
          },
          "apigee-cassandra-default-1": {
            "state": "complete",
            "updated": 1623105765
          },
          "apigee-cassandra-default-2": {
            "state": "complete",
            "updated": 1623105770
          }
        },
        "state": "complete",
        "updated": 1623105770
      }

6. Verifica i processi di nuova creazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status.
   Nota: se l'operazione di nuova creazione mostra lo stato completato e i log dei processi di nuova creazione 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

   Nell'esempio seguente sono riportate voci di log di esempio:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

7. Aggiornare gli host di origine. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Nota: gli host origine sono membri del cluster locale. Per avviare una nuova regione, è necessario un host originale esterno. Una volta avviata una regione, devi riportare gli host di origine ai 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 comando seguente è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato del nodetool per le due regioni.

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