Questa pagina è stata tradotta dall'API Cloud Translation.

Deployment in più regioni su GKE e GKE On-Prem

Questo argomento descrive un deployment multiregionale per Apigee Hybrid su GKE e Anthos GKE distribuito on-premise.

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:

Bilanciamento del carico della connessione MART

Ogni cluster regionale deve avere il proprio indirizzo IP e nome host MART, ma devi connettere il piano di gestione a uno solo. Cassandra propaga le informazioni a tutti i cluster. L'opzione migliore per la disponibilità elevata di MART è bilanciare il carico dei singoli indirizzi IP MART e configurare l'organizzazione in modo che comunichi con l'URL MART bilanciato.

Prerequisiti

Prima di configurare la soluzione ibrida per più regioni, devi completare i seguenti prerequisiti:

Configura cluster Kubernetes in più regioni con blocchi CIDR diversi
Configurare la comunicazione tra regioni
Requisiti per Cassandra multiregione:
- 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 dei pod non ha connettività tra i pod in cluster diversi (i cluster vengono eseguiti in "modalità di rete isolata", ad esempio 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 inversa. Apigee cassandra utilizza la ricerca DNS diretta e inversa 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 7000 e 7001 di Cassandra tra i cluster Kubernetes in tutte le regioni per consentire ai nodi worker in regioni e data center di comunicare. Vedi Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

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.

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

Decidi quale degli IP restituiti dal comando precedente sarà l'host seed multiregionale.
La configurazione in questo passaggio dipende dal fatto che tu utilizzi GKE o GKE On-Prem:

Solo GKE: nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in Gestisci 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 # Set this to true for Non GKE platforms.
```
Ad esempio:
```
cassandra:
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: false
```
Solo GKE On-Prem: nel data center 2, configura cassandra.multiRegionSeedHost nel file di override, dove multiRegionSeedHost è uno degli IP restituiti dal comando precedente:
```
cassandra:
  hostNetwork: true
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
```
Ad esempio:
```
cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
```
Nel nuovo data center/nella nuova regione, prima di installare l'ibrido, imposta gli stessi certificati TLS e credenziali in overrides.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 in overrides.yaml nel primo data center devono corrispondere a quelle specificate in overrides.yaml 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:

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
```
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:
```
apigeectl init -f overrides/overrides-DC_name.yaml
```
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```
Verifica che l'installazione ibrida sia riuscita eseguendo questo comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Verifica la configurazione del cluster Cassandra eseguendo questo comando. L'output dovrebbe mostrare sia i data center esistenti sia quelli nuovi.

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

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 è il nome del data center nella regione di origine. Questo è il valore impostato per cassandra:datacenter: nel tuo 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
}
```

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

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/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: dc-2
================
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.