Deployment multiregionale su AKS

Stai visualizzando la versione 1.3 della documentazione di Apigee hybrid. This version is end of life. You should upgrade to a newer version. Per maggiori informazioni, vedi Versioni supportate.

Version 1.3 (unsupported)

Versioni supportate:

• v1.12 (più recente)                        
• v1.11                         
• v1.10                                        
• Elenco delle versioni supportate

Versioni non supportate:

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

Questo argomento spiega come configurare un deployment multiregionale per Apigee hybrid su Microsoft® Azure Kubernetes Service (AKS).

Le topologie per il deployment in più regioni includono quanto segue:

• Attivo-Attivo: se hai eseguito il deployment delle applicazioni in più località geografiche e hai bisogno di una risposta dell'API a bassa latenza per i tuoi deployment. Puoi eseguire il deployment di un modello ibrido in più località geografiche più vicine ai tuoi clienti. Ad esempio: costa occidentale degli Stati Uniti, costa orientale degli Stati Uniti, Europa, APAC.
• Attivo-passivo: se hai una regione principale e una regione di failover o di ripristino di emergenza.

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

Prerequisiti

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

• Segui la guida all'installazione ibrida per eventuali prerequisiti come Google Cloud e la configurazione dell'organizzazione prima di passare alla procedura di configurazione del cluster.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

NOTA: Apigee consiglia di assicurare che gli orari dei server siano sincronizzati.

Diverse funzionalità, come la scadenza e la revoca del token, si basano su orari di sistema accurati. Se ospiti i componenti di 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 regione

Creare una rete virtuale per il deployment multiregionale. Ad esempio, i comandi di esempio seguenti creano reti nelle regioni degli Stati Uniti centrali e degli Stati Uniti orientali.

NOTA: i passaggi in questa sezione sono forniti solo a titolo esemplificativo. Adattale in base alle tue esigenze.

Esegui questo comando per creare una rete virtuale con il nome my-hybrid-rg-vnet nella regione degli Stati Uniti orientali:

az network vnet create \
 --name my-hybrid-rg-vnet \
 --location eastus \
 --resource-group my-hybrid-rg \
 --address-prefixes 120.38.1.0/24 \
 --subnet-name my-hybrid-rg-vnet-subnet \
 --subnet-prefix 120.38.1.0/26

Esegui questo comando per creare una rete virtuale con il nome my-hybrid-rg-vnet-ext01 nella regione degli Stati Uniti centrali:

az network vnet create \
 --name my-hybrid-rg-vnet-ext01 \
 --location centralus \
 --resource-group my-hybrid-rg \
 --address-prefixes 192.138.0.0/24 \
 --subnet-name my-hybrid-rg-vnet-ext01-subnet \
 --subnet-prefix 192.138.0.0/26

Crea peering di rete

Creare un peering di rete tra le reti virtuali.

NOTA: i passaggi in questa sezione sono forniti solo a titolo esemplificativo. Adattale in base alle tue esigenze.

Recuperare gli ID delle reti virtuali

I peering vengono stabiliti tra ID rete virtuali. Recupera l'ID di ogni rete virtuale con il comando az network vnet show e archivia l'ID in una variabile.

Recupera l'ID della prima rete virtuale, quella denominata my-hybrid-rg-vnet:

vNet1Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet \
 --query id --out tsv)

Recupera l'ID della seconda rete virtuale, quella denominata my-hybrid-rg-vnet-ext01:

vNet2Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet-ext01 \
 --query id \
 --out tsv)

Crea il peering dalla prima alla seconda rete virtuale

Con gli ID rete virtuale, puoi creare un peering dalla prima rete virtuale (my-hybrid-rg-vnet) alla seconda (my-hybrid-rg-vnet-ext01), come mostrato nei seguenti esempi:

Se non specifichi il parametro --allow-vnet-access, viene stabilito un peering, ma non può attraversarlo alcuna comunicazione.

az network vnet peering create \
 --name my-hybrid-rg-vnet1-peering \     # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \         # The virtual network name.
 --remote-vnet $vNet2Id \                # Resource ID of the remote virtual network.
 --allow-vnet-access

Nell'output del comando, nota che peeringState è stato iniziato. Il peering rimane in stato Iniziato fino a quando non crei il peering dalla seconda rete virtuale alla prima.

{
  ...
  "peeringState": "Initiated",
  ...
}

Crea un peering dalla seconda rete virtuale alla prima

Comando di esempio:

az network vnet peering create \
 --name my-hybrid-rg-vnet2-peering \        # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet-ext01 \      # The virtual network name.
 --remote-vnet $vNet1Id \                   # Resource ID of the remote virtual network.
 --allow-vnet-access

Nell'output del comando, nota che peeringState è Connesso. Azure cambia anche lo stato di peering del primo peering di rete virtuale in Connesso.

{
  ...
  "peeringState": "Connected",
  ...
}

Puoi anche confermare che lo stato di peering per my-hybrid-rg-vnet1-peering in my-hybrid-rg-vnet2-peering: peering è cambiato in Connesso con il seguente comando:

az network vnet peering show \
 --name my-hybrid-rg-vnet1-peering \
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \
 --query peeringState

Output previsto:

Connected

Crea cluster multiregionali

Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi. Vedi anche il Passaggio 1: crea un cluster. Utilizza le località e i nomi delle reti virtuali creati 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 seed per 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 unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non conoscerebbero gli altri.

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

   kubectl config use-context original-cluster-name

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

   Un indirizzo host di origine consente a una nuova istanza a livello di regione di trovare il cluster originale al primo avvio in modo da 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 quale IP restituito dal comando precedente sarà l'host seed multiregionale. In questo esempio, in cui è in esecuzione un solo cluster Cassandra a nodo, l'host di origine è 120.38.1.9.
4. Nel data center 2, copia il file degli 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. Nel nuovo data center/nella nuova regione, prima di installare la versione ibrida, imposta in overrides_your_cluster_name.yaml gli stessi certificati e credenziali TLS impostati nella prima regione.
   NOTA: assicurati di utilizzare nel secondo data center gli stessi certificati TLS e credenziali di Cassandra che hai fornito nel data center originale. Le credenziali impostate nel file degli override nel primo data center devono corrispondere a quelle specificate nel file degli override nel secondo data center. Per maggiori dettagli, consulta Configurazione di TLS per Cassandra.

Configura la nuova regione

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

Per configurare la nuova regione:

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

      kubectl config use-context original-cluster-name

   2. Esporta la configurazione attuale dello spazio dei nomi in un file:

      $ kubectl get namespace  -o yaml > apigee-namespace.yaml

   3. Esporta il secret di 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 il modello ibrido nella nuova regione. Assicurati che il file overrides_your_cluster_name.yaml includa gli stessi certificati TLS configurati nella prima regione, come spiegato nella sezione precedente.

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

   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. L'operazione potrebbe richiedere da pochi minuti a qualche ora, a seconda della dimensione dei dati.

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool rebuild -- dc-1

4. Verifica i processi di ricreazione dai log. Verifica inoltre le dimensioni dei dati utilizzando il comando nodetool status:

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

   L'esempio seguente mostra esempi di voci di log:

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

5. Aggiorna gli host di origine. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e applica di nuovo la richiesta.
   Gli host di origine sono membri del cluster locale. Per avviare una nuova regione è necessario un host di origine esterno. Dopo l'avvio di una regione, devi riportare gli host di origine ai rispettivi cluster locali in overrides.yaml e quindi applicare di nuovo la configurazione.

   apigeectl apply -f overrides-DC_name.yaml