Questa pagina è stata tradotta dall'API Cloud Translation.

Deployment multiregionale su AKS

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

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

Attivo-Attivo: quando è stato eseguito il deployment delle applicazioni in più aree geografiche da più località e hai bisogno di una risposta API a bassa latenza per i tuoi deployment. Puoi implementare la soluzione ibrida in più località geografiche vicine ai tuoi clienti. Ad esempio: costa occidentale degli Stati Uniti, costa orientale degli Stati Uniti, Europa, APAC.
Attivo-passivo: quando 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 mostrato nella seguente immagine:

Prerequisiti

Prima di configurare l'ambiente ibrida per più regioni, devi completare i seguenti prerequisiti:

Segui l'installazione ibrida guida per eventuali prerequisiti, come Google Cloud e la configurazione dell'organizzazione prima di andare ai passaggi di configurazione del cluster.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

Crea una rete virtuale in ogni regione

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

Esegui questo comando per creare una rete virtuale nella regione degli Stati Uniti orientali, con 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 degli Stati Uniti centrali, con 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

Creare un peering di rete tra le reti virtuali.

Ottieni gli ID rete virtuale

I peering vengono stabiliti tra gli ID rete virtuale. Recupera l'ID di ogni rete virtuale con az network vnet show e memorizza 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 istanza rete (my-hybrid-rg-vnet) al secondo (my-hybrid-rg-vnet-ext01), come mostrato nei seguenti esempi:

Se non specifichi il parametro --allow-vnet-access, un peering è ma non è possibile comunicare.

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 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, tieni presente che peeringState è Connesso. Azure inoltre modifica lo stato del peering della prima alla seconda rete virtuale in Connesso.

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

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

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 i cluster Kubernetes in più regioni con blocchi CIDR diversi. Consulta: anche la guida rapida di AKS. Utilizza la di località e nomi di reti virtuali creati in precedenza.

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

Configura l'host seed multi-region

Questa sezione descrive come espandere il cluster Cassandra esistente in una nuova regione. Questa configurazione consente alla nuova regione di avviare il cluster e di partecipare al data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali che non conoscerebbero.

Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seme:
```
kubectl config use-context original-cluster-name
```
Esegui questo comando kubectl per identificare un indirizzo host di origine per Cassandra in la regione corrente.

Un indirizzo host iniziale consente a una nuova istanza regionale di trovare il cluster originale alla prima accensione per apprenderne la topologia. L'indirizzo host di origine è 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
```
Decidi quale IP restituito dal comando precedente sarà il seed multiregionale . In questo esempio, in cui è in esecuzione un solo cluster Cassandra a un nodo, l'host iniziale è 120.38.1.9.
Nel data center 2, copia il file degli override in un nuovo file il cui nome include il cluster nome. Ad esempio, overrides_your_cluster_name.yaml.
Nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter a 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"
```
Nel nuovo data center/nella nuova regione, prima di installare la versione ibrida, imposta in overrides_your_cluster_name.yaml gli stessi certificati TLS e le stesse credenziali che hai impostato nella prima regione.
NOTA: assicurati di utilizzare gli stessi certificati TLS e credenziali di Cassandra nella seconda quello fornito nel data center originale. Le credenziali che hai impostato il file degli override nel primo data center deve corrispondere a quelli specificati in il file degli 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 regione:

Copia il certificato dal cluster esistente al nuovo cluster. Il nuovo certificato CA radice viene utilizzato da Cassandra e da altri componenti ibride per mTLS. Pertanto, è essenziale avere 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 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 "namespace" 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
```
Installa il modello ibrido nella nuova regione. Assicurati che overrides_your_cluster_name.yaml include gli stessi certificati TLS configurati nella prima regione, come spiegate nella sezione precedente.
Esegui i seguenti due comandi per installare la versione ibrida nella nuova regione:
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```

Espandi tutti gli spazi chiavi apigee.

I passaggi che seguono estendono i dati di Cassandra al nuovo data center:

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

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.

Ottieni gli spazi delle chiavi 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)

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};

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>

Esegui nodetool rebuild in sequenza su tutti i nodi del nuovo data center. L'operazione può richiedere da alcuni minuti a diverse ore, a seconda delle dimensioni dei dati.
```
kubectl exec apigee-cassandra-0 -n apigee  -- nodetool rebuild -- dc-1
```

Verifica le procedure di ricostruzione dai log. Verifica inoltre le dimensioni dei dati utilizzando il comando nodetool status:

kubectl logs apigee-cassandra-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

Aggiorna gli host seed. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
Gli host di origine sono membri del cluster locale. Per avviare un nuova regione è obbligatorio un host di origine esterno. Una volta avviata la regione, devi per riportare gli host di origine ai propri cluster locali in overrides.yaml e poi e applicare nuovamente la configurazione.
```
apigeectl apply -f overrides-DC_name.yaml
```