Deployment multiregionale

Version 1.15 (latest)

   Supported versions:

• v1.15 (latest)                        
• v1.14                        
• v1.13                         
• List of supported versions

   Unsupported versions:

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

Questo argomento descrive un deployment multiregionale per Apigee Hybrid su GKE, Anthos GKE di cui è stato eseguito il deployment on-premise, 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 multiregionale includono quanto segue:

• Active-Active: quando hai applicazioni di cui è stato eseguito il deployment in più località geografiche e richiedi una risposta API a bassa latenza per i tuoi deployment. Hai la possibilità di eseguire il deployment dell'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: quando hai una regione primaria e una regione di failover o di ripristino di emergenza.

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

Prerequisiti

Prima di configurare la connettività ibrida per più regioni, devi completare i seguenti prerequisiti:

GKE

• Quando installi deployment Apigee multiregionali tra reti diverse (ad es. diversi provider cloud, diverse reti VPC, cloud e on-premise e così via), devi fornire una connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. Ciò può essere ottenuto con VPN o soluzioni di connettività specifiche per il cloud.
• Se utilizzi Workload Identity Federation for GKE in un cluster per autenticare i service account, ti consigliamo vivamente di utilizzare Workload Identity Federation for GKE per ogni cluster a cui ti espandi. Consulta Abilitazione di Workload Identity Federation for GKE o Abilitazione di Workload Identity Federation su AKS ed EKS.
• Configura 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, allora il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione dei nomi host funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza il comando 1. Se hostNetwork è impostato su true, utilizza il comando 2.
  
  Se la risoluzione dei nomi host funziona, l'output mostrerà un indirizzo IP. Se la risoluzione del nome host non va a buon fine, 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 Cassandra multiregione:
  • Assicurati che lo spazio dei nomi di rete del pod abbia connettività tra le regioni, inclusi firewall, VPN, peering VPC e peering VNet. Questo vale per la maggior parte delle installazioni GKE.
  • Se lo spazio dei nomi di rete del pod non ha connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isolata"), attiva la funzionalità Kubernetes hostNetwork 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à isolata e hostNetwork di seguito.

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

    Aggiungi una voce host statica 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 regioni e data center diversi. Per informazioni sui numeri di porta di Cassandra, consulta Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

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

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

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

GKE On-Prem

• Quando installi deployment Apigee multiregionali tra reti diverse (ad es. diversi provider cloud, diverse reti VPC, cloud e on-premise e così via), devi fornire una connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. Ciò può essere ottenuto con VPN o soluzioni di connettività specifiche per il cloud.
• Configura 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, allora il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione dei nomi host funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza il comando 1. Se hostNetwork è impostato su true, utilizza il comando 2.
  
  Se la risoluzione dei nomi host funziona, l'output mostrerà un indirizzo IP. Se la risoluzione del nome host non va a buon fine, 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 Cassandra multiregione:
  • Se lo spazio dei nomi di rete del pod non ha connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isolata", il caso predefinito nelle installazioni GKE on-premise), attiva la funzionalità Kubernetes hostNetwork impostando cassandra.hostNetwork: true nel file di override per tutte le regioni dell'installazione multiregionale ibrida di Apigee.

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

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

    Aggiungi una voce host statica 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 di Cassandra tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in regioni e data center diversi. Consulta Configurare le porte per i numeri di porta di Cassandra.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

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

Diverse funzionalità, come la scadenza e la revoca dei token, si basano su orari di sistema accurati. Se ospiti i componenti runtime in data center diversi, assicurati di sincronizzare gli orari di sistema.

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

AKS

• Quando installi deployment Apigee multiregionali tra reti diverse (ad es. diversi provider cloud, diverse reti VPC, cloud e on-premise e così via), devi fornire una connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. Ciò può essere ottenuto con VPN o soluzioni di connettività specifiche per il cloud.
• Segui la guida all'installazione ibrida per tutti i prerequisiti, come la configurazione di Google Cloud e dell'organizzazione, prima di passare ai passaggi di configurazione del cluster.
• Assicurati che cert-manager sia installato in ogni cluster.
• Assicurati che tutti i pod Cassandra siano in grado di risolvere i propri nomi host. Se hostNetwork è impostato su false, il nome host è il nome del pod Cassandra. Se hostNetwork è impostato su true, allora il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione dei nomi host funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza il comando 1. Se hostNetwork è impostato su true, utilizza il comando 2.
  
  Se la risoluzione dei nomi host funziona, l'output mostrerà un indirizzo IP. Se la risoluzione del nome host non va a buon fine, 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 Cassandra multiregione:
  • Se lo spazio dei nomi di rete del pod non ha connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isolata", il caso predefinito nelle installazioni AKS), attiva la funzionalità Kubernetes hostNetwork impostando cassandra.hostNetwork: true nel file di override per tutte le regioni dell'installazione multiregionale di Apigee Hybrid.

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

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

    Aggiungi una voce host statica 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 di Cassandra tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in regioni e data center diversi. Consulta Configurare le porte per i numeri di porta di Cassandra.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

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

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

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

EKS

• Quando installi deployment Apigee multiregionali tra reti diverse (ad es. diversi provider cloud, diverse reti VPC, cloud e on-premise e così via), devi fornire una connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. Ciò può essere ottenuto con VPN o soluzioni di connettività specifiche per il cloud.
• Segui la guida all'installazione ibrida per tutti i prerequisiti, come la configurazione di Google Cloud e dell'organizzazione, prima di passare ai passaggi di configurazione del cluster.
• Assicurati che cert-manager sia installato in ogni cluster.
• Assicurati che tutti i pod Cassandra siano in grado di risolvere i propri nomi host. Se hostNetwork è impostato su false, il nome host è il nome del pod Cassandra. Se hostNetwork è impostato su true, allora il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione dei nomi host funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza il comando 1. Se hostNetwork è impostato su true, utilizza il comando 2.
  
  Se la risoluzione dei nomi host funziona, l'output mostrerà un indirizzo IP. Se la risoluzione del nome host non va a buon fine, 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 Cassandra multiregione:
  • Se lo spazio dei nomi di rete del pod non ha connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isolata"), attiva la funzionalità Kubernetes hostNetwork impostando cassandra.hostNetwork: true nel file di override per tutte le regioni dell'installazione multiregionale ibrida di Apigee. Amazon EKS utilizza per impostazione predefinita il modello di rete completamente integrato.

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

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

    Aggiungi una voce host statica 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 di Cassandra tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in regioni e data center diversi. Consulta Configurare le porte per i numeri di porta di Cassandra.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

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

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

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

OpenShift

• Quando installi deployment Apigee multiregionali tra reti diverse (ad es. diversi provider cloud, diverse reti VPC, cloud e on-premise e così via), devi fornire una connettività interna tra queste reti separate che Cassandra può utilizzare per comunicare tra i nodi. Ciò può essere ottenuto con VPN o soluzioni di connettività specifiche per il cloud.
• Segui la guida all'installazione ibrida per tutti i prerequisiti, come la configurazione di Google Cloud e dell'organizzazione, prima di passare ai passaggi di configurazione del cluster.
• Assicurati che cert-manager sia installato in ogni cluster.
• Assicurati che tutti i pod Cassandra siano in grado di risolvere i propri nomi host. Se hostNetwork è impostato su false, il nome host è il nome del pod Cassandra. Se hostNetwork è impostato su true, allora il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione dei nomi host funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza il comando 1. Se hostNetwork è impostato su true, utilizza il comando 2.
  
  Se la risoluzione dei nomi host funziona, l'output mostrerà un indirizzo IP. Se la risoluzione del nome host non va a buon fine, 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 Cassandra multiregione:
  • Se lo spazio dei nomi di rete del pod non ha connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isolata", il caso predefinito nelle installazioni OpenShift), attiva la funzionalità Kubernetes hostNetwork impostando cassandra.hostNetwork: true nel file di override per tutte le regioni dell'installazione multiregionale di Apigee Hybrid.

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

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

    Aggiungi una voce host statica 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 di Cassandra tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in regioni e data center diversi. Consulta Configurare le porte per i numeri di porta di Cassandra.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

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

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

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

Cluster in modalità isolata e hostNetwork

Esistono due modelli di rete principali per i cluster Kubernetes: completamente integrato (o flat) e modalità isolata. Apigee consiglia di utilizzare il modello di rete flat, se possibile, in quanto semplifica la connettività Cassandra multiregionale. Quando un cluster Kubernetes è configurato in modalità isolata, la rete dei pod è isolata. I pod non possono comunicare direttamente con i pod in esecuzione in altri cluster utilizzando l'indirizzo IP del pod. Per ulteriori informazioni sulle differenze tra questi due modelli di rete ed esempi di ciascuno, consulta Implementazioni tipiche del modello di rete.

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

Risoluzione dei nomi host di Cassandra

Sebbene un pod Cassandra non risolva altri pod Cassandra in base al nome host, all'avvio Cassandra verifica che il proprio nome host sia risolvibile tramite DNS. Poiché il nome host del pod è uguale al nome host del nodo di lavoro Kubernetes quando hostNetwork è impostato su true, il nome host del nodo di lavoro deve essere risolvibile in un indirizzo IP tramite il servizio DNS del cluster. Se il nome host del nodo di lavoro 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 imposti hostNetwork su true.

Configura Apigee hybrid per più regioni

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

GKE

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

Avviso:se l'installazione non va a buon fine per una nuova regione, non continuare con l'installazione della regione. Elimina e ricrea l'installazione ibrida nella regione in cui si è verificato l'errore.

Configura l'host seed multiregionale

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 di unirsi al data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si riconoscerebbero.

1. Per la prima regione creata, recupera i pod nello spazio dei nomi apigee:

   kubectl get pods -o wide -n APIGEE_NAMESPACE
   

2. Identifica l'indirizzo host seed 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 seed nel seguente modo:

   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 seed, ad esempio 10.0.0.11.
   • DATACENTER_NAME con il nome del data center, ad esempio dc-2.
   • RACK_NAME con il nome del rack, ad esempio ra-1.
   • CLUSTER_NAME con il nome del cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome del cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere il valore che preferisci, ma deve essere lo stesso in tutte le regioni.

Configura la seconda regione

Per configurare la nuova regione:

1. Installa cert-manager nella seconda regione.

2. Copia il certificato dal cluster esistente al nuovo cluster. 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 dello spazio dei nomi corrente in un file:

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

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

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

   Nota:per coerenza, puoi utilizzare gli stessi CRD utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere il file di override univoco tra la regione 1 e la regione 2 assegnando un nome univoco agli override, ad esempio overrides-region_name.yaml e così via.

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

   ENV_RELEASE_NAME e ENV_GROUP_RELEASE_NAME sono nomi utilizzati per tenere traccia di installazione e upgrade dei grafici apigee-env e apigee-virtualhost. I nomi delle release Helm devono essere univoci all'interno dell'installazione di Apigee Hybrid. Se il nome dell'ambiente è univoco, può essere uguale a ENV_NAME. Tuttavia, se l'ambiente e il gruppo di ambienti hanno lo stesso nome, assicurati di inserire un nome di release Helm univoco per ciascuno. Ad esempio, se entrambi si chiamano dev, puoi utilizzare qualcosa come dev-env-release e dev-envgroup-release.

   Puoi visualizzare un elenco dei nomi delle release con il comando helm list:

   helm list -n APIGEE_NAMESPACE

   .

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

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Vedi Disinstallazione del runtime di hybrid. Se la configurazione non riesce, non tentare di procedere ulteriormente o di unirti al cluster.

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
   -- 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. Configura Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il seguente comando:

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

      Ad esempio:

      Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -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. Negli esempi seguenti, il file avrà il nome datareplication.yaml.

      Il file deve contenere quanto segue:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Dove:

      • REGION_EXPANSION è il nome che stai assegnando a questi metadati. Puoi utilizzare qualsiasi nome.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. che in genere corrisponde a "apigee".
      • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n APIGEE_NAMESPACE -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 source region overrides.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 questo comando:

      kubectl apply -f datareplication.yaml

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

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

   I risultati dovrebbero essere simili a questi:

   {
   "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 seed:
   1. Vuoi rimuovere multiRegionSeedHost: 10.0.0.11 da overrides-DATACENTER_NAME.yaml?

   2. Applica di nuovo la modifica per aggiornare il CR del datastore Apigee:

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

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

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

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

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

   L'esempio seguente mostra alcune voci di log:

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

Controlla lo stato del cluster Cassandra

Il seguente comando è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato di nodetool per le due regioni.

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


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

GKE On-Prem

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

Avviso:se l'installazione non va a buon fine per una nuova regione, non continuare con l'installazione della regione. Elimina e ricrea l'installazione ibrida nella regione in cui si è verificato l'errore.

Configura l'host seed multiregionale

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 di unirsi al data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si riconoscerebbero.

1. Per la prima regione creata, recupera i pod nello spazio dei nomi apigee:

   kubectl get pods -o wide -n APIGEE_NAMESPACE
   

2. Identifica l'indirizzo host seed 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 seed nel seguente modo:

   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 seed, ad esempio 10.0.0.11.
   • DATACENTER_NAME con il nome del data center, ad esempio dc-2.
   • RACK_NAME con il nome del rack, ad esempio ra-1.
   • CLUSTER_NAME con il nome del cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome del cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere il valore che preferisci, ma deve essere lo stesso in tutte le regioni.

Configura la seconda regione

Per configurare la nuova regione:

1. Installa cert-manager nella seconda regione.

2. Copia il certificato dal cluster esistente al nuovo cluster. 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 dello spazio dei nomi corrente in un file:

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

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

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

   Nota:per coerenza, puoi utilizzare gli stessi CRD utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere il file di override univoco tra la regione 1 e la regione 2 assegnando un nome univoco agli override, ad esempio overrides-region_name.yaml e così via.

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

   ENV_RELEASE_NAME e ENV_GROUP_RELEASE_NAME sono nomi utilizzati per tenere traccia di installazione e upgrade dei grafici apigee-env e apigee-virtualhost. I nomi delle release Helm devono essere univoci all'interno dell'installazione di Apigee Hybrid. Se il nome dell'ambiente è univoco, può essere uguale a ENV_NAME. Tuttavia, se l'ambiente e il gruppo di ambienti hanno lo stesso nome, assicurati di inserire un nome di release Helm univoco per ciascuno. Ad esempio, se entrambi si chiamano dev, puoi utilizzare qualcosa come dev-env-release e dev-envgroup-release.

   Puoi visualizzare un elenco dei nomi delle release con il comando helm list:

   helm list -n APIGEE_NAMESPACE

   .

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

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Vedi Disinstallazione del runtime di hybrid. Se la configurazione non riesce, non tentare di procedere ulteriormente o di unirti al cluster.

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
   -- 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. Configura Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il seguente comando:

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

      Ad esempio:

      Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -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. Negli esempi seguenti, il file avrà il nome datareplication.yaml.

      Il file deve contenere quanto segue:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Dove:

      • REGION_EXPANSION è il nome che stai assegnando a questi metadati. Puoi utilizzare qualsiasi nome.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. che in genere corrisponde a "apigee".
      • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n APIGEE_NAMESPACE -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 source region overrides.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 questo comando:

      kubectl apply -f datareplication.yaml

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

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

   I risultati dovrebbero essere simili a questi:

   {
   "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 seed:
   1. Vuoi rimuovere multiRegionSeedHost: 10.0.0.11 da overrides-DATACENTER_NAME.yaml?

   2. Applica di nuovo la modifica per aggiornare il CR del datastore Apigee:

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

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

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

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

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

   L'esempio seguente mostra alcune voci di log:

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

Controlla lo stato del cluster Cassandra

Il seguente comando è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato di nodetool per le due regioni.

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


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

AKS

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

Avviso:se l'installazione non va a buon fine per una nuova regione, non continuare con l'installazione della regione. Elimina e ricrea l'installazione ibrida nella regione in cui si è verificato l'errore.

Crea una rete virtuale in ogni regione

Segui i suggerimenti di Azure per stabilire la comunicazione tra regioni qui: Da VNet a VNet: Connessione di reti virtuali in Azure in regioni diverse.

Crea cluster multiregionali

Configura cluster Kubernetes in più regioni con blocchi CIDR diversi. Vedi anche Passaggio 1: crea un cluster. Utilizza le posizioni e i nomi delle reti virtuali che hai creato in precedenza.

Apri le porte di Cassandra tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in regioni e data center diversi. Consulta Configurare le porte per i numeri di porta di Cassandra.

Configura l'host seed multiregionale

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 di unirsi al data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si riconoscerebbero.

1. Per la prima regione creata, recupera i pod nello spazio dei nomi apigee:

   kubectl get pods -o wide -n APIGEE_NAMESPACE
   

2. Identifica l'indirizzo host seed 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 seed nel seguente modo:

   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 seed, ad esempio 10.0.0.11.
   • DATACENTER_NAME con il nome del data center, ad esempio dc-2.
   • RACK_NAME con il nome del rack, ad esempio ra-1.
   • CLUSTER_NAME con il nome del cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome del cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere il valore che preferisci, ma deve essere lo stesso in tutte le regioni.

Configura la seconda regione

Per configurare la nuova regione:

1. Installa cert-manager nella seconda regione.

2. Copia il certificato dal cluster esistente al nuovo cluster. 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 dello spazio dei nomi corrente in un file:

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

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

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

   Nota:per coerenza, puoi utilizzare gli stessi CRD utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere il file di override univoco tra la regione 1 e la regione 2 assegnando un nome univoco agli override, ad esempio overrides-region_name.yaml e così via.

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

   ENV_RELEASE_NAME e ENV_GROUP_RELEASE_NAME sono nomi utilizzati per tenere traccia di installazione e upgrade dei grafici apigee-env e apigee-virtualhost. I nomi delle release Helm devono essere univoci all'interno dell'installazione di Apigee Hybrid. Se il nome dell'ambiente è univoco, può essere uguale a ENV_NAME. Tuttavia, se l'ambiente e il gruppo di ambienti hanno lo stesso nome, assicurati di inserire un nome di release Helm univoco per ciascuno. Ad esempio, se entrambi si chiamano dev, puoi utilizzare qualcosa come dev-env-release e dev-envgroup-release.

   Puoi visualizzare un elenco dei nomi delle release con il comando helm list:

   helm list -n APIGEE_NAMESPACE

   .

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

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Vedi Disinstallazione del runtime di hybrid. Se la configurazione non riesce, non tentare di procedere ulteriormente o di unirti al cluster.

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
   -- 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. Configura Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il seguente comando:

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

      Ad esempio:

      Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -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. Negli esempi seguenti, il file avrà il nome datareplication.yaml.

      Il file deve contenere quanto segue:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Dove:

      • REGION_EXPANSION è il nome che stai assegnando a questi metadati. Puoi utilizzare qualsiasi nome.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. che in genere corrisponde a "apigee".
      • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n APIGEE_NAMESPACE -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 source region overrides.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 questo comando:

      kubectl apply -f datareplication.yaml

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

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

   I risultati dovrebbero essere simili a questi:

   {
   "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 seed:
   1. Vuoi rimuovere multiRegionSeedHost: 10.0.0.11 da overrides-DATACENTER_NAME.yaml?

   2. Applica di nuovo la modifica per aggiornare il CR del datastore Apigee:

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

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

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

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

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

   L'esempio seguente mostra alcune voci di log:

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

Controlla lo stato del cluster Cassandra

Il seguente comando è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato di nodetool per le due regioni.

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


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

EKS

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

Avviso:se l'installazione non va a buon fine per una nuova regione, non continuare con l'installazione della regione. Elimina e ricrea l'installazione ibrida nella regione in cui si è verificato l'errore.

Crea una rete virtuale in ogni regione

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

Crea cluster multiregionali

Configura cluster Kubernetes in più regioni con blocchi CIDR diversi. Vedi anche Passaggio 1: crea un cluster. Utilizza le posizioni e i nomi delle reti virtuali che hai creato in precedenza.

Apri le porte di Cassandra tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in regioni e data center diversi. Consulta Configurare le porte per i numeri di porta di Cassandra.

Configura l'host seed multiregionale

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 di unirsi al data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si riconoscerebbero.

1. Per la prima regione creata, recupera i pod nello spazio dei nomi apigee:

   kubectl get pods -o wide -n APIGEE_NAMESPACE
   

2. Identifica l'indirizzo host seed 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 seed nel seguente modo:

   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 seed, ad esempio 10.0.0.11.
   • DATACENTER_NAME con il nome del data center, ad esempio dc-2.
   • RACK_NAME con il nome del rack, ad esempio ra-1.
   • CLUSTER_NAME con il nome del cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome del cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere il valore che preferisci, ma deve essere lo stesso in tutte le regioni.

Configura la seconda regione

Per configurare la nuova regione:

1. Installa cert-manager nella seconda regione.

2. Copia il certificato dal cluster esistente al nuovo cluster. 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 dello spazio dei nomi corrente in un file:

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

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

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

   Nota:per coerenza, puoi utilizzare gli stessi CRD utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere il file di override univoco tra la regione 1 e la regione 2 assegnando un nome univoco agli override, ad esempio overrides-region_name.yaml e così via.

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

   ENV_RELEASE_NAME e ENV_GROUP_RELEASE_NAME sono nomi utilizzati per tenere traccia di installazione e upgrade dei grafici apigee-env e apigee-virtualhost. I nomi delle release Helm devono essere univoci all'interno dell'installazione di Apigee Hybrid. Se il nome dell'ambiente è univoco, può essere uguale a ENV_NAME. Tuttavia, se l'ambiente e il gruppo di ambienti hanno lo stesso nome, assicurati di inserire un nome di release Helm univoco per ciascuno. Ad esempio, se entrambi si chiamano dev, puoi utilizzare qualcosa come dev-env-release e dev-envgroup-release.

   Puoi visualizzare un elenco dei nomi delle release con il comando helm list:

   helm list -n APIGEE_NAMESPACE

   .

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

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Vedi Disinstallazione del runtime di hybrid. Se la configurazione non riesce, non tentare di procedere ulteriormente o di unirti al cluster.

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
   -- 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. Configura Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il seguente comando:

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

      Ad esempio:

      Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -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. Negli esempi seguenti, il file avrà il nome datareplication.yaml.

      Il file deve contenere quanto segue:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Dove:

      • REGION_EXPANSION è il nome che stai assegnando a questi metadati. Puoi utilizzare qualsiasi nome.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. che in genere corrisponde a "apigee".
      • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n APIGEE_NAMESPACE -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 source region overrides.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 questo comando:

      kubectl apply -f datareplication.yaml

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

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

   I risultati dovrebbero essere simili a questi:

   {
   "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 seed:
   1. Vuoi rimuovere multiRegionSeedHost: 10.0.0.11 da overrides-DATACENTER_NAME.yaml?

   2. Applica di nuovo la modifica per aggiornare il CR del datastore Apigee:

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

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

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

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

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

   L'esempio seguente mostra alcune voci di log:

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

Controlla lo stato del cluster Cassandra

Il seguente comando è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato di nodetool per le due regioni.

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


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

OpenShift

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

Avviso:se l'installazione non va a buon fine per una nuova regione, non continuare con l'installazione della regione. Elimina e ricrea l'installazione ibrida nella regione in cui si è verificato l'errore.

Configura l'host seed multiregionale

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 di unirsi al data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si riconoscerebbero.

1. Per la prima regione creata, recupera i pod nello spazio dei nomi apigee:

   kubectl get pods -o wide -n APIGEE_NAMESPACE
   

2. Identifica l'indirizzo host seed 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 seed nel seguente modo:

   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 seed, ad esempio 10.0.0.11.
   • DATACENTER_NAME con il nome del data center, ad esempio dc-2.
   • RACK_NAME con il nome del rack, ad esempio ra-1.
   • CLUSTER_NAME con il nome del cluster Cassandra. Per impostazione predefinita, il valore è apigeecluster. Se utilizzi un nome del cluster diverso, devi specificare un valore per cassandra.clusterName. Puoi scegliere il valore che preferisci, ma deve essere lo stesso in tutte le regioni.

Configura la seconda regione

Per configurare la nuova regione:

1. Installa cert-manager nella seconda regione.

2. Copia il certificato dal cluster esistente al nuovo cluster. 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 dello spazio dei nomi corrente in un file:

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

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

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

   Nota:per coerenza, puoi utilizzare gli stessi CRD utilizzando la stessa cartella in cui hai scaricato i grafici. Puoi anche mantenere il file di override univoco tra la regione 1 e la regione 2 assegnando un nome univoco agli override, ad esempio overrides-region_name.yaml e così via.

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

   ENV_RELEASE_NAME e ENV_GROUP_RELEASE_NAME sono nomi utilizzati per tenere traccia di installazione e upgrade dei grafici apigee-env e apigee-virtualhost. I nomi delle release Helm devono essere univoci all'interno dell'installazione di Apigee Hybrid. Se il nome dell'ambiente è univoco, può essere uguale a ENV_NAME. Tuttavia, se l'ambiente e il gruppo di ambienti hanno lo stesso nome, assicurati di inserire un nome di release Helm univoco per ciascuno. Ad esempio, se entrambi si chiamano dev, puoi utilizzare qualcosa come dev-env-release e dev-envgroup-release.

   Puoi visualizzare un elenco dei nomi delle release con il comando helm list:

   helm list -n APIGEE_NAMESPACE

   .

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

   Per risolvere il problema, l'installazione ibrida nella nuova regione deve essere eliminata e ricreata. Vedi Disinstallazione del runtime di hybrid. Se la configurazione non riesce, non tentare di procedere ulteriormente o di unirti al cluster.

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
   -- 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. Configura Cassandra su tutti i pod nei nuovi data center.
   1. Recupera apigeeorg dal cluster con il seguente comando:

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

      Ad esempio:

      Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -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. Negli esempi seguenti, il file avrà il nome datareplication.yaml.

      Il file deve contenere quanto segue:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Dove:

      • REGION_EXPANSION è il nome che stai assegnando a questi metadati. Puoi utilizzare qualsiasi nome.
      • NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. che in genere corrisponde a "apigee".
      • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n APIGEE_NAMESPACE -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 source region overrides.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 questo comando:

      kubectl apply -f datareplication.yaml

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

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

   I risultati dovrebbero essere simili a questi:

   {
   "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 seed:
   1. Vuoi rimuovere multiRegionSeedHost: 10.0.0.11 da overrides-DATACENTER_NAME.yaml?

   2. Applica di nuovo la modifica per aggiornare il CR del datastore Apigee:

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

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

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

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

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

   L'esempio seguente mostra alcune voci di log:

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

Controlla lo stato del cluster Cassandra

Il seguente comando è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato di nodetool per le due regioni.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- 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 di Cassandra.