Deployment multiregionale su AKS

Attualmente stai visualizzando la versione 1.2 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.2 (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 spiega come configurare un deployment multiregionale per Apigee Hybrid su Microsoft® Azure Kubernetes Service (AKS).

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 soluzione ibrida per più regioni, devi completare i seguenti prerequisiti:

• Segui la guida all'installazione ibrida per tutti i prerequisiti come la configurazione di GCP e dell'organizzazione prima di passare ai passaggi di configurazione del cluster.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

NOTA:Apigee consiglia di assicurarsi che l'ora dei server sia sincronizzata.

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.

Crea una rete virtuale in ogni regione

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

NOTA: i passaggi in questa sezione sono forniti solo a titolo di esempio. Adattali in base alle tue esigenze.

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

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 nella regione Stati Uniti centrali, con il nome my-hybrid-rg-vnet-ext01:

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

Crea un peering di rete tra le reti virtuali.

NOTA: i passaggi in questa sezione sono forniti solo a titolo di esempio. Adattali in base alle tue esigenze.

Recuperare gli ID rete virtuale

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

Ottieni 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 negli esempi seguenti:

Se non specifichi il parametro --allow-vnet-access, viene stabilito un peering, ma non può essere utilizzato per la 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, tieni presente che peeringState è Initiated. Il peering rimane nello stato Iniziato finché 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 è Connected. Azure modifica anche lo stato di peering del primo peering di rete virtuale in Connesso.

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

Puoi anche verificare che lo stato di peering per il peering da my-hybrid-rg-vnet1-peering a my-hybrid-rg-vnet2-peering: sia 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

Configura cluster Kubernetes in più regioni con blocchi CIDR diversi. Consulta anche la guida rapida di AKS. Utilizza i nomi delle località e delle reti virtuali che hai creato in precedenza.

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

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 | grep apigee-cassandra
   
   apigee-cassandra-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
   

3. 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.
4. 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.
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 l'ibrido, imposta gli stessi certificati TLS e credenziali in overrides_your_cluster_name.yaml che hai impostato 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.

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

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

3. Espandi tutti gli spazi chiave Apigee.

   I seguenti passaggi espandono i dati di Cassandra al nuovo data center:

   1. Apri una shell nel pod Cassandra:

      kubectl run -i --tty --restart=Never --rm --image google/apigee-hybrid-cassandra-client:1.0.0 cqlsh

      NOTA: se non vedi un prompt dei comandi, prova a premere il tasto INVIO.
   2. Connettiti al server Cassandra:

      cqlsh apigee-cassandra-0.apigee-cassandra.apigee.svc.cluster.local -u ddl_user --ssl
      Password:
      
      Connected to apigeecluster at apigee-cassandra-0.apigee-cassandra.apigee.svc.cluster.local:9042.
      [cqlsh 5.0.1 | Cassandra 3.11.3 | CQL spec 3.4.4 | Native protocol v4]
      Use HELP for help.

   3. Ottieni gli spazi chiave disponibili:

      SELECT * from system_schema.keyspaces ;
       keyspace_name              | durable_writes | replication
      ----------------------------+----------------+--------------------------------------------------------------------------------------------------------
                      system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
                    system_schema |           True |                                                {'class': 'org.apache.cassandra.locator.LocalStrategy'}
       cache_hybrid_test_7_hybrid |           True |                  {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         kms_hybrid_test_7_hybrid |           True |                  {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         kvm_hybrid_test_7_hybrid |           True |                  {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
               system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
                           system |           True |                                                {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                           perses |           True |                  {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       quota_hybrid_test_7_hybrid |           True |                  {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                    system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
      
      (10 rows)

   4. Aggiorna/espandi gli spazi delle chiavi Apigee:

      ALTER KEYSPACE cache_hybrid_test_7_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-1':3, 'dc-2':3};
      ALTER KEYSPACE kms_hybrid_test_7_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-1':3, 'dc-2':3};
      ALTER KEYSPACE kvm_hybrid_test_7_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-1':3, 'dc-2':3};
      ALTER KEYSPACE perses WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-1':3, 'dc-2':3};
      ALTER KEYSPACE quota_hybrid_test_7_hybrid  WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-1':3, 'dc-2':3};

   5. Convalida l'espansione dello spazio delle chiavi:

      SELECT * from system_schema.keyspaces ;
       keyspace_name              | durable_writes | replication
      ----------------------------+----------------+--------------------------------------------------------------------------------------------------------
                      system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
                    system_schema |           True |                                                {'class': 'org.apache.cassandra.locator.LocalStrategy'}
       cache_hybrid_test_7_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3', 'dc-2': '3'}
         kms_hybrid_test_7_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3', 'dc-2': '3'}
         kvm_hybrid_test_7_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3', 'dc-2': '3'}
               system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
                           system |           True |                                                {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                           perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3', 'dc-2': '3'}
       quota_hybrid_test_7_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3', 'dc-2': '3'}
                    system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '1', 'dc-2': '1'}
      
      (10 rows)
      ddl@cqlsh>

4. Esegui nodetool rebuild in sequenza su tutti i nodi nel nuovo data center. L'operazione può richiedere da pochi minuti ad alcune ore, a seconda delle dimensioni dei dati.

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

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

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

   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

6. Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e riapplica.
   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-DC_name.yaml