Questa pagina è stata tradotta dall'API Cloud Translation.

Deployment multiregionale su GKE e GKE On-Prem

Questo argomento descrive un deployment multiregionale per Apigee hybrid su GKE e Anthos GKE di cui è stato eseguito il deployment on-prem.

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 eseguire il deployment di ambienti ibridi dalle sedi più vicine ai tuoi clienti. Ad esempio: costa occidentale degli Stati Uniti, costa orientale degli Stati Uniti, Europa, APAC.
Attivo-passivo: in presenza di una regione principale e di un failover o un'emergenza regione di ripristino.

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

Bilanciamento del carico della connessione MART

Ogni cluster a livello di regione deve avere il proprio IP e nome host MART. ma ti serve solo per connettere il piano di gestione a uno di questi. Cassandra propaga le informazioni a tutti dei cluster. L'opzione migliore per l'alta disponibilità per MART è il bilanciamento del carico i singoli indirizzi IP MART e configurare la tua organizzazione in modo che comunichi con il bilanciamento del carico URL MART.

Prerequisiti

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

Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi
Configura la comunicazione tra regioni
Requisiti di Cassandra per più regioni:
- Assicurati che lo spazio dei nomi della rete dei pod disponga della connettività tra le regioni, tra cui firewall, VPN, peering VPC e peering vNet. Questo è il caso della maggior parte delle installazioni GKE.
- Se lo spazio dei nomi della rete dei pod non dispone di connettività tra i pod in cluster diversi (i cluster sono in esecuzione in "modalità di rete dell'isola", ad esempio nelle installazioni GKE On-Prem), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file degli override per tutte le regioni in la tua installazione ibrida di Apigee in più regioni.
  Per informazioni sulla funzionalità hostNetwork di Kubernetes, consulta Organizzatore degli spazi dei nomi nella documentazione di Kubernetes.
- Abilita hostNetwork sui cluster esistenti prima di espandere da più regioni a nuove regioni.
- Se hostNetwork è abilitato, assicurati che i nodi worker possano eseguire l'inversione ricerca DNS. Apigee Cassandra utilizza la ricerca DNS diretta e inversa per ottenere l'host IP all'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 Cassandra simile al seguente:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  o
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Apri le porte Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni per che permettono ai nodi worker di comunicare tra regioni e data center. Vedi Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

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 la regione esistente data center. Senza questa configurazione, i cluster Kubernetes multiregionali che non conoscerebbero.

Esegui questo comando kubectl per identificare un indirizzo host di origine per Cassandra in la regione corrente.

Un indirizzo host di origine consente a una nuova istanza regionale di trovare originale alla primissima startup a scoprire la topologia del cluster. L'indirizzo host di origine è 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 IP restituito dal comando precedente sarà il seed multiregionale .
La configurazione in questo passaggio dipende dal fatto che tu sia su GKE o GKE On-Prem:

Solo GKE: nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in Gestisci i 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 impostate 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 overrides.yaml nel primo data center deve corrispondere a quelli specificati in overrides.yaml 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 tuo certificato dal cluster esistente a quello nuovo. La nuova radice dell'autorità di certificazione è utilizzata da Cassandra e da altri componenti ibridi per mTLS. Pertanto, è essenziale avere 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 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 "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 il modello ibrido nella nuova regione. Assicurati che overrides-DC_name.yaml include gli stessi certificati TLS configurati nella prima regione, come spiegate nella sezione precedente.
Esegui questi due comandi per installare il modello 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 che quelli nuovi.

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

Esempio di configurazione corretta:

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

Configurare Cassandra su tutti i pod nei nuovi data center.
1. Recupera apigeeorg dal cluster con il comando seguente:
```
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 risorse personalizzate di replica dei dati Cassandra (YAML). La 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 puoi usare un nome qualsiasi.
  - NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. Solitamente, è "apigee".
  - APIGEEORG_VALUE è il valore di output dal 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 impostato per cassandra:datacenter: in 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 comando seguente.
  Nota: l'operazione di ristrutturazione può richiedere diverse ore a seconda della dimensione dei dati.
```
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
```
  I risultati dovrebbero essere simili ai seguenti:
```
{
  "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 ricreazione dai log. Verifica inoltre 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 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 di origine. 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/overrides-DC_name.yaml
```

Controlla lo stato del cluster Cassandra

Il seguente comando è utile per vedere se la configurazione del cluster ha esito positivo in due data center on-premise. Il comando verifica lo stato 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 Cassandra.