Deployment multiregionale

Attualmente stai visualizzando la versione 1.8 della documentazione di Apigee hybrid. This version is end of life. You should upgrade to a newer version. Per ulteriori informazioni, consulta Versioni supportate.

Version 1.8 (unsupported)

   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.
• Active-Passive: 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 fornitori di servizi 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
• Configurare la comunicazione tra regioni
• Assicurati che tutti i pod Cassandra siano in grado di risolvere i propri nomi host. Se hostNetwork è impostato su false, il nome host è il nome del pod Cassandra. Se hostNetwork è impostato su true, allora il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione dei nomi host funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza 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 multiregionale:
  • 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 informazioni sulla funzionalità hostNetwork di Kubernetes, consulta la sezione Spazi dei nomi host nella documentazione di Kubernetes.

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

GKE On-Prem

• Quando installi deployment Apigee multiregionali tra reti diverse (ad es. diversi fornitori di servizi 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
• Configurare la comunicazione tra regioni
• Assicurati che tutti i pod Cassandra siano in grado di risolvere i propri nomi host. Se hostNetwork è impostato su false, il nome host è il nome del pod Cassandra. Se hostNetwork è impostato su true, allora il nome host è il nome host del nodo Kubernetes che esegue il pod Cassandra.
  Suggerimento:per verificare se la risoluzione dei nomi host funziona, utilizza questi comandi.
  
  Se hostNetwork è impostato su false, utilizza 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 multiregionale:
  • 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 informazioni sulla funzionalità hostNetwork di Kubernetes, consulta la sezione Spazi dei nomi host nella documentazione di Kubernetes.

  • 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 fornitori di servizi 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 multiregionale:
  • 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 informazioni sulla funzionalità hostNetwork di Kubernetes, consulta la sezione Spazi dei nomi host nella documentazione di Kubernetes.

  • 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 fornitori di servizi 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 multiregionale:
  • 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 informazioni sulla funzionalità hostNetwork di Kubernetes, consulta la sezione Spazi dei nomi host nella documentazione di Kubernetes.

  • 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 fornitori di servizi 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 multiregionale:
  • 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), abilita la funzionalità Kubernetes hostNetwork impostando cassandra.hostNetwork: true nel file di override per tutte le regioni dell'installazione multiregionale di Apigee Hybrid.

    Per informazioni sulla funzionalità hostNetwork di Kubernetes, consulta la sezione Spazi dei nomi host nella documentazione di Kubernetes.

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

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

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. Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seed:

   kubectl config use-context original-cluster-name

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

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

   kubectl get pods -o wide -n apigee

   NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
   apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
   apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
   apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

3. Decidi quale degli IP restituiti dal comando precedente sarà l'host seed multiregionale.
4. Nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in Manage runtime plane components (Gestisci i componenti del piano di runtime), dove multiRegionSeedHost è uno degli IP restituiti dal comando precedente:

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

   Ad esempio:

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

5. Nel nuovo data center/regione, prima di installare ibrido, imposta gli stessi certificati TLS e credenziali in overrides.yaml come hai fatto nella prima regione.
   Nota:assicurati di utilizzare gli stessi certificati e credenziali TLS di Cassandra nel secondo data center che hai fornito nel data center originale. Le credenziali che imposti nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, vedi Configurazione di TLS per Cassandra.

Configurare la nuova regione

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

Per configurare la nuova regione:

1. Copia il certificato dal cluster esistente al nuovo cluster. La nuova CA root 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 namespace -o yaml > apigee-namespace.yaml

   3. Esporta il secret apigee-ca in un file:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Imposta il contesto sul nome del cluster della nuova regione:

      kubectl config use-context new-cluster-name

   5. Importa la configurazione dello spazio dei nomi nel nuovo cluster. Assicurati di aggiornare lo "spazio dei nomi" nel file se utilizzi uno spazio dei nomi diverso nella nuova regione:

      kubectl apply -f apigee-namespace.yaml

   6. Importa il secret nel nuovo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

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

   Esegui i seguenti due comandi per installare l'ibrido nella nuova regione:

   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.

   apigeectl init -f overrides/overrides-DC_name.yaml

   apigeectl apply -f overrides/overrides-DC_name.yaml

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

   apigeectl check-ready -f overrides_DC_name.yaml

4. Verifica la configurazione del cluster Cassandra eseguendo 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 partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u JMX_user -pw JMX_password status

   Esempio che mostra una configurazione riuscita:

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

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

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

      Ad esempio:

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

   2. Crea un file di risorsa personalizzata di replica dei dati Cassandra (YAML). Il file può avere qualsiasi nome. 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. In genere è "apigee".
      • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di 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 il seguente comando:

      kubectl apply -f datareplication.yaml

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

6. Verifica i processi di ricompilazione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status:

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

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

   L'esempio seguente mostra alcune voci di log di esempio:

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

7. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e riapplica.
   Nota: gli host seed sono membri del cluster locale. Per avviare una nuova regione, è necessario un host di seeding esterno. Una volta avviata una regione, devi ripristinare i seed host nei cluster locali in overrides.yaml e poi riapplicare la configurazione.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Controlla lo stato del cluster Cassandra

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

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status


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

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

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. Nel file overrides.yaml per il cluster originale, assicurati che cassandra:hostNetwork sia impostato su true. Ad esempio:

   cassandra:
     hostNetwork: true

   Per saperne di più su quando impostare hostNetwork: true, consulta Prerequisiti.

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

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi il completamento del riavvio graduale dei pod Cassandra.

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

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

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
        

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

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD describecluster
        

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

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

   kubectl config use-context original-cluster-name

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

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

   kubectl get pods -o wide -n apigee

   NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
   apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
   apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
   apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

5. Decidi quale degli IP restituiti dal comando precedente sarà l'host seed multiregionale.
6. Nel data center 2, configura cassandra.multiRegionSeedHost nel file di override, dove multiRegionSeedHost è uno degli indirizzi IP restituiti dal comando precedente:

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

   Ad esempio:

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

7. Nel nuovo data center/regione, prima di installare ibrido, imposta gli stessi certificati TLS e credenziali in overrides.yaml come hai fatto nella prima regione.
   Nota:assicurati di utilizzare gli stessi certificati e credenziali TLS di Cassandra nel secondo data center che hai fornito nel data center originale. Le credenziali che imposti nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, vedi Configurazione di TLS per Cassandra.

Configurare la nuova regione

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

Per configurare la nuova regione:

1. Copia il certificato dal cluster esistente al nuovo cluster. La nuova CA root 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 namespace -o yaml > apigee-namespace.yaml

   3. Esporta il secret apigee-ca in un file:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Imposta il contesto sul nome del cluster della nuova regione:

      kubectl config use-context new-cluster-name

   5. Importa la configurazione dello spazio dei nomi nel nuovo cluster. Assicurati di aggiornare lo "spazio dei nomi" nel file se utilizzi uno spazio dei nomi diverso nella nuova regione:

      kubectl apply -f apigee-namespace.yaml

   6. Importa il secret nel nuovo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

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

   Esegui i seguenti due comandi per installare l'ibrido nella nuova regione:

   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.

   apigeectl init -f overrides/overrides-DC_name.yaml

   apigeectl apply -f overrides/overrides-DC_name.yaml

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

   apigeectl check-ready -f overrides_DC_name.yaml

4. Verifica la configurazione del cluster Cassandra eseguendo 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 partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u JMX_user -pw JMX_password status

   Esempio che mostra una configurazione riuscita:

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

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

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

      Ad esempio:

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

   2. Crea un file di risorsa personalizzata di replica dei dati Cassandra (YAML). Il file può avere qualsiasi nome. 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. In genere è "apigee".
      • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di 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 il seguente comando:

      kubectl apply -f datareplication.yaml

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

6. Verifica i processi di ricompilazione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status:

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

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

   L'esempio seguente mostra alcune voci di log di esempio:

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

7. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e riapplica.
   Nota: gli host seed sono membri del cluster locale. Per avviare una nuova regione, è necessario un host di seeding esterno. Una volta avviata una regione, devi ripristinare i seed host nei cluster locali in overrides.yaml e poi riapplicare la configurazione.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Controlla lo stato del cluster Cassandra

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

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status


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

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. 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 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 i nomi delle località e 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. Nel file overrides.yaml per il cluster originale, assicurati che cassandra:hostNetwork sia impostato su true. Ad esempio:

   cassandra:
     hostNetwork: true

   Per saperne di più su quando impostare hostNetwork: true, consulta Prerequisiti.

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

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi il completamento del riavvio graduale dei pod Cassandra.

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

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

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
        

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

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD describecluster
        

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

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

   kubectl config use-context original-cluster-name

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

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

   kubectl get pods -o wide -n apigee | grep apigee-cassandra

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

5. Decidi quale degli IP restituiti dal comando precedente sarà l'host seed multiregionale. In questo esempio, in cui è in esecuzione un solo cluster Cassandra, l'host seed è 120.38.1.9.
6. Nel data center 2, copia il file di override in un nuovo file il cui nome includa il nome del cluster. Ad esempio, overrides_your_cluster_name.yaml.
7. Nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in overrides_your_cluster_name.yaml, dove multiRegionSeedHost è uno degli IP restituiti dal comando precedente:

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

   Ad esempio:

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

8. Nel nuovo data center/regione, prima di installare ibrido, imposta gli stessi certificati TLS e credenziali in overrides_your_cluster_name.yaml come hai fatto nella prima regione.
   Nota:assicurati di utilizzare gli stessi certificati e credenziali TLS di Cassandra nel secondo data center che hai fornito nel data center originale. Le credenziali che imposti nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, vedi Configurazione di TLS per Cassandra.

Configurare la nuova regione

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

Per configurare la nuova regione:

1. Copia il certificato dal cluster esistente al nuovo cluster. La nuova CA root 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 namespace -o yaml > apigee-namespace.yaml

   3. Esporta il secret apigee-ca in un file:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Imposta il contesto sul nome del cluster della nuova regione:

      kubectl config use-context new-cluster-name

   5. Importa la configurazione dello spazio dei nomi nel nuovo cluster. Assicurati di aggiornare lo "spazio dei nomi" nel file se utilizzi uno spazio dei nomi diverso nella nuova regione:

      kubectl apply -f apigee-namespace.yaml

   6. Importa il secret nel nuovo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

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

   Esegui i seguenti due comandi per installare l'ibrido nella nuova regione:

   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.

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

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

   apigeectl check-ready -f overrides_your_cluster_name.yaml

4. Verifica la configurazione del cluster Cassandra eseguendo 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 partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u JMX_user -pw JMX_password status

   Esempio che mostra una configurazione riuscita:

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

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

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

      Ad esempio:

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

   2. Crea un file di risorsa personalizzata di replica dei dati Cassandra (YAML). Il file può avere qualsiasi nome. 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. In genere è "apigee".
      • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di 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 il seguente comando:

      kubectl apply -f datareplication.yaml

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

6. Verifica i processi di ricompilazione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status:

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

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

   L'esempio seguente mostra alcune voci di log di esempio:

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

7. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 120.38.1.9 da overrides-DC_name.yaml e riapplica.
   Nota: gli host seed sono membri del cluster locale. Per avviare una nuova regione, è necessario un host di seeding esterno. Una volta avviata una regione, devi ripristinare i seed host nei cluster locali in overrides.yaml e poi riapplicare la configurazione.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Controlla lo stato del cluster Cassandra

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

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status


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

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 i nomi delle località e 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. Nel file overrides.yaml per il cluster originale, assicurati che cassandra:hostNetwork sia impostato su true. Ad esempio:

   cassandra:
     hostNetwork: true

   Per saperne di più su quando impostare hostNetwork: true, consulta Prerequisiti.

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

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi il completamento del riavvio graduale dei pod Cassandra.

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

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

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
        

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

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD describecluster
        

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

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

   kubectl config use-context original-cluster-name

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

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

   kubectl get pods -o wide -n apigee | grep apigee-cassandra

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

5. Decidi quale degli IP restituiti dal comando precedente sarà l'host seed multiregionale. In questo esempio, in cui è in esecuzione un solo cluster Cassandra, l'host seed è 120.38.1.9.
6. Nel data center 2, copia il file di override in un nuovo file il cui nome includa il nome del cluster. Ad esempio, overrides_your_cluster_name.yaml.
7. Nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in overrides_your_cluster_name.yaml, dove multiRegionSeedHost è uno degli IP restituiti dal comando precedente:

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

   Ad esempio:

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

8. Nel nuovo data center/regione, prima di installare ibrido, imposta gli stessi certificati TLS e credenziali in overrides_your_cluster_name.yaml come hai fatto nella prima regione.
   Nota:assicurati di utilizzare gli stessi certificati e credenziali TLS di Cassandra nel secondo data center che hai fornito nel data center originale. Le credenziali che imposti nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, vedi Configurazione di TLS per Cassandra.

Configurare la nuova regione

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

Per configurare la nuova regione:

1. Copia il certificato dal cluster esistente al nuovo cluster. La nuova CA root 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 namespace -o yaml > apigee-namespace.yaml

   3. Esporta il secret apigee-ca in un file:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Imposta il contesto sul nome del cluster della nuova regione:

      kubectl config use-context new-cluster-name

   5. Importa la configurazione dello spazio dei nomi nel nuovo cluster. Assicurati di aggiornare lo "spazio dei nomi" nel file se utilizzi uno spazio dei nomi diverso nella nuova regione:

      kubectl apply -f apigee-namespace.yaml

   6. Importa il secret nel nuovo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

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

   Esegui i seguenti due comandi per installare l'ibrido nella nuova regione:

   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.

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

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

   apigeectl check-ready -f overrides_your_cluster_name.yaml

4. Verifica la configurazione del cluster Cassandra eseguendo 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 partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u JMX_user -pw JMX_password status

   Esempio che mostra una configurazione riuscita:

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

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

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

      Ad esempio:

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

   2. Crea un file di risorsa personalizzata di replica dei dati Cassandra (YAML). Il file può avere qualsiasi nome. 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. In genere è "apigee".
      • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di 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 il seguente comando:

      kubectl apply -f datareplication.yaml

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

6. Verifica i processi di ricompilazione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status:

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

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

   L'esempio seguente mostra alcune voci di log di esempio:

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

7. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e riapplica.
   Nota: gli host seed sono membri del cluster locale. Per avviare una nuova regione, è necessario un host di seeding esterno. Una volta avviata una regione, devi ripristinare i seed host nei cluster locali in overrides.yaml e poi riapplicare la configurazione.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Controlla lo stato del cluster Cassandra

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

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status


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

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

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. Nel file overrides.yaml per il cluster originale, assicurati che cassandra:hostNetwork sia impostato su true. Ad esempio:

   cassandra:
     hostNetwork: true

   Per saperne di più su quando impostare hostNetwork: true, consulta Prerequisiti.

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

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendi il completamento del riavvio graduale dei pod Cassandra.

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

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

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
        

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

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD describecluster
        

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

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

   kubectl config use-context original-cluster-name

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

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

   kubectl get pods -o wide -n apigee

   NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
   apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
   apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
   apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

5. Seleziona l'indirizzo IP dell'host Cassandra di origine da utilizzare come host seed multiregionale. In questo esempio, il cluster apigee-cassandra-default-0 è in esecuzione e l'host seed è 10.0.0.11.
6. Nel data center 2, copia il file di override in un nuovo file il cui nome includa il nome del cluster. Ad esempio, overrides_your_cluster_name.yaml.
7. Nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in overrides_your_cluster_name.yaml, dove multiRegionSeedHost è uno degli IP restituiti dal comando precedente:

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP # Cassandra pod IP address from the source region.
     datacenter: data_center_name
     rack: rack_name
     clusterName: cluster_name # must be the same for all regions

   Ad esempio:

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

8. Nel nuovo data center/regione, prima di installare ibrido, imposta gli stessi certificati TLS e credenziali in overrides_your_cluster_name.yaml come hai fatto nella prima regione.
   Nota:assicurati di utilizzare gli stessi certificati e credenziali TLS di Cassandra nel secondo data center che hai fornito nel data center originale. Le credenziali che imposti nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, vedi Configurazione di TLS per Cassandra.

Configurare la nuova regione

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

Per configurare la nuova regione:

1. Copia il certificato dal cluster esistente al nuovo cluster. La nuova CA root 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 namespace -o yaml > apigee-namespace.yaml

   3. Esporta il secret apigee-ca in un file:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Imposta il contesto sul nome del cluster della nuova regione:

      kubectl config use-context new-cluster-name

   5. Importa la configurazione dello spazio dei nomi nel nuovo cluster. Assicurati di aggiornare lo "spazio dei nomi" nel file se utilizzi uno spazio dei nomi diverso nella nuova regione:

      kubectl apply -f apigee-namespace.yaml

   6. Importa il secret nel nuovo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

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

   Esegui i seguenti due comandi per installare l'ibrido nella nuova regione:

   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.

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

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

   apigeectl check-ready -f overrides_your_cluster_name.yaml

4. Verifica la configurazione del cluster Cassandra eseguendo 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 partecipare al cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u JMX_user -pw JMX_password status

   Esempio che mostra una configurazione riuscita:

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

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

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

      Ad esempio:

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

   2. Crea un file di risorsa personalizzata di replica dei dati Cassandra (YAML). Il file può avere qualsiasi nome. 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. In genere è "apigee".
      • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name nel passaggio precedente. Ad esempio, rg-hybrid-b7d3b9c
      • SOURCE_REGION è la regione di origine, il valore del data center nella sezione cassandra di 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 il seguente comando:

      kubectl apply -f datareplication.yaml

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

6. Verifica i processi di ricompilazione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status:

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

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

   L'esempio seguente mostra alcune voci di log di esempio:

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

7. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e riapplica.
   Nota: gli host seed sono membri del cluster locale. Per avviare una nuova regione, è necessario un host di seeding esterno. Una volta avviata una regione, devi ripristinare i seed host nei cluster locali in overrides.yaml e poi riapplicare la configurazione.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Controlla lo stato del cluster Cassandra

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

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status


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

Risoluzione dei problemi

Vedi Errore di replica dei dati di Cassandra.