Deployment su più aree geografiche su AKS

Al momento stai visualizzando la versione 1.6 della documentazione di Apigee hybrid. Questa versione è terminata. Dovresti eseguire l'upgrade a una versione più recente. Per maggiori informazioni, consulta la pagina Versioni supportate.

Questo argomento spiega come configurare un deployment a più aree geografiche per Apigee hybrid su Microsoft® Azure Kubernetes Service (AKS).

Le topologia per il deployment in più aree geografiche includono:

• Attivo-Attivo: quando hai un'applicazione di cui hai eseguito il deployment in più località geografiche e hai bisogno di una risposta dell'API a bassa latenza per i tuoi deployment. Puoi scegliere di eseguire il deployment di ambienti ibridi in più località geografiche più vicine ai tuoi clienti. Ad esempio: costa occidentale degli Stati Uniti, costa orientale degli Stati Uniti, Europa, APAC.
• Passiva attiva: quando hai un'area geografica principale e un'area geografica di failover o di ripristino di emergenza.

Le regioni in un deployment ibrido a più aree geografiche comunicano tramite Cassandra, come mostra la seguente immagine:

Prerequisiti

Prima di configurare la modalità ibrida per più aree geografiche, devi completare i seguenti prerequisiti:

• Prima di passare ai passaggi di configurazione del cluster, segui la guida all'installazione ibrida per tutti i prerequisiti, ad esempio Google Cloud e la configurazione dell'organizzazione.
• Requisiti di Cassandra per più aree geografiche:
  • Assicurati che lo spazio dei nomi di rete dei pod abbia connettività tra aree geografiche, inclusi firewall, vpn, peering vpc e peering vNet.
  • Se lo spazio dei nomi di rete dei pod non ha connettività tra pod in cluster diversi (i cluster sono in esecuzione in "modalità di rete dell'isola"", ad esempio nella maggior parte delle installazioni AKS), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nella tua installazione di Apigee con più regioni ibride.

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

  • Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione di più aree geografiche alle nuove aree geografiche.
  • Quando è abilitato hostNetwork, assicurati che i nodi worker possano eseguire una ricerca DNS inversa. Apigee cassandra utilizza la ricerca DNS avanti e indietro per ottenere l'IP host durante l'avvio.
    Suggerimento: se la risoluzione DNS non funziona, prova questa soluzione alternativa.

    Aggiungi una voce host statica nel file /etc/hosts di ciascun nodo worker di cassandra simile al seguente:

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    o

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • Apri le porte 7000 e 7001 a Cassandra tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker di tutte le regioni e i data center. Consulta la pagina Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

NOTA: Apigee consiglia di assicurarsi che i tuoi server siano sincronizzati.

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

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

Crea una rete virtuale in ogni area geografica

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

Crea cluster multiregionali

Configura i cluster Kubernetes in più aree geografiche con blocchi CIDR diversi. Consulta anche il Passaggio 1: crea un cluster. Utilizza le località e i nomi di reti virtuali che hai creato in precedenza.

Apri le porte Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni (7000 può essere utilizzato come opzione di backup durante la risoluzione dei problemi)

Configura l'host di origine con più regioni

Questa sezione descrive come espandere il cluster Cassandra esistente a una nuova regione. Questa configurazione consente alla nuova regione di eseguire il bootstrap del cluster e di unirsi al data center esistente. Senza questa configurazione, i cluster Kubernetes su più aree geografiche non si conoscono.

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

   kubectl config use-context original-cluster-name

2. Esegui il comando kubectl riportato di seguito per identificare un indirizzo host di origine per Cassandra nella regione corrente.

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

   kubectl get pods -o wide -n apigee | grep apigee-cassandra
   
   apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
   

3. Decidi quali IP restituiti dal comando precedente saranno l'host radice da più aree geografiche. In questo esempio, dove è in esecuzione un solo cluster di cassandra nodo, l'host di origine è 120.38.1.9.
4. Nel data center 2, copia il file di override in un nuovo file il cui nome include il nome del cluster. Ad esempio, overrides_your_cluster_name.yaml.
5. 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

   Ad esempio:

   cassandra:
     multiRegionSeedHost: 120.38.1.9
     datacenter: "centralus"
     rack: "ra-1"

6. Nella nuova area geografica/nel nuovo data center, prima di installare l'ibrido, imposta in overrides_your_cluster_name.yaml gli stessi certificati e credenziali di TLS impostati 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 impostate nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, vedi Configurazione di TLS per Cassandra.

Configura la nuova regione

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

Per configurare la nuova area geografica:

1. Copia il certificato dal cluster esistente al nuovo cluster. La nuova radice CA è utilizzata da Cassandra e altri componenti ibridi per mTLS. Di conseguenza, è essenziale avere certificati coerenti in tutto il cluster.
   1. Imposta il contesto nello 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 "&namet" nel file se utilizzi uno spazio dei nomi diverso nella nuova regione:

      kubectl apply -f apigee-namespace.yaml

   6. Importa il secret nel nuovo cluster:

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

2. Installa l'ibrido nella nuova area geografica. 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 due comandi seguenti per installare la soluzione ibrida nella nuova area geografica:

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

3. Esegui nodetool rebuild in sequenza su tutti i nodi del nuovo data center. A seconda delle dimensioni dei dati, questa operazione potrebbe richiedere da alcuni minuti ad alcune ore.

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1

   Dove JMX_user e JMX_password sono il nome utente e la password dell'utente JMX di Cassandra.

4. Verifica i processi di ricostruzione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status:

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

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

   L'esempio seguente mostra voci di log di esempio:

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

5. Aggiorna gli host di origine. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e presenta di nuovo la domanda.
   Gli host di origine sono membri del cluster locale. Per avviare una nuova regione, è necessario un host radice originale. Dopo l'avvio di una regione, devi riportare gli host di origine nei cluster locali in overrides.yaml e applicare nuovamente la configurazione.

   apigeectl apply -f overrides-DC_name.yaml