Documenti

English
Deutsch
Español – América Latina
Français
Indonesia
Italiano
Português – Brasil
中文 – 简体
日本語
한국어

Contattaci Inizia gratuitamente

Questa pagina è stata tradotta dall'API Cloud Translation.

Deployment multiregionale

Questo argomento descrive un deployment in più regioni per Apigee hybrid su GKE, Anthos GKE di cui è stato eseguito il deployment on-prem, RedHat OpenShift e su Microsoft® Azure Kubernetes Service (AKS). Seleziona la tua piattaforma nei prerequisiti e nelle procedure.

Le topologie per il deployment su più regioni includono:

Attivo-Attivo: se le tue applicazioni sono state distribuite in più località geografiche e hai bisogno di una risposta API a bassa latenza per i tuoi deployment. Hai la possibilità di eseguire il deployment di 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 ripristino di emergenza.

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

Prerequisiti

GKE

Prima di configurare il cloud 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 per più regioni di Cassandra:
- Assicurati che lo spazio dei nomi di rete dei pod disponga di connettività in tutte le regioni, inclusi firewall, VPN, peering VPC e peering vNet. Questo è il caso per la maggior parte delle installazioni GKE.
- Se lo spazio dei nomi di rete dei pod non dispone di connettività tra i cluster (i cluster sono in esecuzione in "modalità di rete Island"), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nell'installazione multiregionale ibrida di Apigee.
  Per informazioni sulla funzionalità hostNetwork di Kubernetes, consulta Spazi dei nomi host nella documentazione di Kubernetes.
- Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni.
- Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire una 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 dell'host statico 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 Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in più regioni e data center. Vedi Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

GKE On-Prem

Prima di configurare il cloud 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 per più regioni di Cassandra:
- Se lo spazio dei nomi di rete dei pod non dispone di connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isola", il caso predefinito nelle installazioni di GKE on-prem), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nell'installazione multiregionale ibrida di Apigee.
  Per informazioni sulla funzionalità hostNetwork di Kubernetes, consulta Spazi dei nomi host nella documentazione di Kubernetes.
- Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni.
- Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire una 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 dell'host statico 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 Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in più regioni e data center. Vedi Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

AKS

Prima di configurare il cloud 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 ai passaggi di configurazione del cluster.
Requisiti per più regioni di Cassandra:
- Se lo spazio dei nomi di rete dei pod non dispone di connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isola", il caso predefinito nelle installazioni AKS), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nell'installazione multiregionale ibrida Apigee.
  Per informazioni sulla funzionalità hostNetwork di Kubernetes, consulta Spazi dei nomi host nella documentazione di Kubernetes.
- Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni.
- Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire una 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 dell'host statico 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 Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in più regioni e data center. Vedi Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

EKS

Prima di configurare il cloud 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 ai passaggi di configurazione del cluster.
Requisiti per più regioni di Cassandra:
- Se lo spazio dei nomi di rete dei pod non dispone di connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete Island", il caso predefinito nelle installazioni EKS), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nell'installazione multiregionale ibrida Apigee.
  Per informazioni sulla funzionalità hostNetwork di Kubernetes, consulta Spazi dei nomi host nella documentazione di Kubernetes.
- Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni.
- Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire una 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 dell'host statico 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 Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in più regioni e data center. Vedi Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

OpenShift

Prima di configurare il cloud 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 ai passaggi di configurazione del cluster.
Requisiti per più regioni di Cassandra:
- Se lo spazio dei nomi di rete dei pod non dispone di connettività tra i cluster (i cluster vengono eseguiti in "modalità di rete isola", il caso predefinito nelle installazioni di OpenShift), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file di override per tutte le regioni nell'installazione multiregionale ibrida di Apigee.
  Per informazioni sulla funzionalità hostNetwork di Kubernetes, consulta Spazi dei nomi host nella documentazione di Kubernetes.
- Abilita hostNetwork sui cluster esistenti prima di espandere la configurazione per più regioni a nuove regioni.
- Quando hostNetwork è abilitato, assicurati che i nodi worker possano eseguire una 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 dell'host statico 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 Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni per consentire la comunicazione tra i nodi worker in più regioni e data center. Vedi Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

Configura Apigee hybrid per più regioni

GKE

Configura l'host seed a 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 unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si sarebbero a conoscenza gli uni degli altri.

Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seed:
```
kubectl config use-context original-cluster-name
```

Esegui questo comando kubectl per identificare un indirizzo host originale per Cassandra nella regione attuale.

Un indirizzo host originale consente a una nuova istanza di regione di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host originale viene 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 a più regioni.

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

Ad esempio:

cassandra:
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: false

Nel nuovo data center o nella nuova regione, prima di installare l'ambiente ibrido, imposta in overrides_your_cluster_name.yaml i certificati e le credenziali TLS che hai impostato nella prima regione.
NOTA: nel secondo data center assicurati di utilizzare gli stessi certificati e credenziali TLS di Cassandra 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, consulta la pagina relativa alla configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host originale, puoi impostare la nuova regione.

Per configurare la nuova regione:

Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova CA radice 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 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 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 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 l'ambiente ibrido nella nuova regione:

Importante: quando espandi la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Verifica che l'installazione ibrida vada a buon fine 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 nuovi sia quelli esistenti.

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

Configurare Cassandra su tutti i pod nei nuovi data center.
1. Ottieni 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. Nei seguenti esempi, 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 assegni a questi metadati. Puoi utilizzare qualsiasi nome.
  - NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. In genere è "apigee".
  - APIGEEORG_VALUE è il valore dell'output del 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: 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 comando seguente:
```
kubectl apply -f datareplication.yaml
```
4. Verifica lo stato della ricompilazione utilizzando il comando seguente.
  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 avere un aspetto simile a questo:
```
{
  "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 nuova creazione dai log. Inoltre, verifica la dimensione 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

Nell'esempio seguente sono riportate 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

Aggiornare 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 una nuova regione, è necessario un host originale esterno. Una volta avviata una regione, devi riportare gli host di origine ai cluster locali in overrides.yaml e poi applicare nuovamente la configurazione.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Controlla lo stato del cluster Cassandra

Il comando seguente è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato del 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

GKE On-Prem

Configura l'host seed a 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 unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si sarebbero a conoscenza gli uni degli altri.

Nel file overrides.yaml del cluster originale, assicurati che cassandra:hostNetwork sia impostato su true. Ad esempio:
```
cassandra:
  hostNetwork: true
```
Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seed:
```
kubectl config use-context original-cluster-name
```

Esegui questo comando kubectl per identificare un indirizzo host originale per Cassandra nella regione attuale.

Un indirizzo host originale consente a una nuova istanza di regione di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host originale viene 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 a più regioni.

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 o nella nuova regione, prima di installare l'ambiente ibrido, imposta in overrides_your_cluster_name.yaml i certificati e le credenziali TLS che hai impostato nella prima regione.
NOTA: nel secondo data center assicurati di utilizzare gli stessi certificati e credenziali TLS di Cassandra 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, consulta la pagina relativa alla configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host originale, puoi impostare la nuova regione.

Per configurare la nuova regione:

Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova CA radice 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 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 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 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 l'ambiente ibrido nella nuova regione:

Importante: quando espandi la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Verifica che l'installazione ibrida vada a buon fine 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 nuovi sia quelli esistenti.

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

Configurare Cassandra su tutti i pod nei nuovi data center.
1. Ottieni 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. Nei seguenti esempi, 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 assegni a questi metadati. Puoi utilizzare qualsiasi nome.
  - NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. In genere è "apigee".
  - APIGEEORG_VALUE è il valore dell'output del 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: 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 comando seguente:
```
kubectl apply -f datareplication.yaml
```
4. Verifica lo stato della ricompilazione utilizzando il comando seguente.
  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 avere un aspetto simile a questo:
```
{
  "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 nuova creazione dai log. Inoltre, verifica la dimensione 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

Nell'esempio seguente sono riportate 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

Aggiornare 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 una nuova regione, è necessario un host originale esterno. Una volta avviata una regione, devi riportare gli host di origine ai cluster locali in overrides.yaml e poi applicare nuovamente la configurazione.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Controlla lo stato del cluster Cassandra

Il comando seguente è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato del 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

AKS

Crea una rete virtuale in ogni regione

Segui i suggerimenti di Azure per stabilire una comunicazione tra regioni qui: VNet-to-VNet: connessione di reti virtuali in Azure in diverse regioni.

Crea cluster multiregionali

Configurare i cluster Kubernetes in più regioni con blocchi CIDR diversi. Vedi anche Passaggio 1: crea un cluster. Utilizza le località e i nomi delle reti virtuali che hai creato 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 a 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 unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si sarebbero a conoscenza gli uni degli altri.

Nel file overrides.yaml del cluster originale, assicurati che cassandra:hostNetwork sia impostato su true. Ad esempio:
```
cassandra:
  hostNetwork: true
```
Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seed:
```
kubectl config use-context original-cluster-name
```
Esegui questo comando kubectl per identificare un indirizzo host originale per Cassandra nella regione attuale.

Un indirizzo host originale consente a una nuova istanza di regione di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host originale viene 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
```
Decidi quale degli IP restituiti dal comando precedente sarà l'host seed a più regioni. In questo esempio, dove è in esecuzione un solo cluster cassandra a nodo singolo, l'host seed è 120.38.1.9.
Nel data center 2, copia il file di override in un nuovo file il cui nome include il nome del cluster. Ad esempio, overrides_your_cluster_name.yaml.

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

Ad esempio:

cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: true

Nel nuovo data center o nella nuova regione, prima di installare l'ambiente ibrido, imposta in overrides_your_cluster_name.yaml i certificati e le credenziali TLS che hai impostato nella prima regione.
NOTA: nel secondo data center assicurati di utilizzare gli stessi certificati e credenziali TLS di Cassandra 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, consulta la pagina relativa alla configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host originale, puoi impostare la nuova regione.

Per configurare la nuova regione:

Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova CA radice 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 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 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 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 l'ambiente ibrido nella nuova regione:

Importante: quando espandi la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Verifica che l'installazione ibrida vada a buon fine 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 nuovi sia quelli esistenti.

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

Configurare Cassandra su tutti i pod nei nuovi data center.
1. Ottieni 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. Nei seguenti esempi, 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 assegni a questi metadati. Puoi utilizzare qualsiasi nome.
  - NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. In genere è "apigee".
  - APIGEEORG_VALUE è il valore dell'output del 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: 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 comando seguente:
```
kubectl apply -f datareplication.yaml
```
4. Verifica lo stato della ricompilazione utilizzando il comando seguente.
  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 avere un aspetto simile a questo:
```
{
  "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 nuova creazione dai log. Inoltre, verifica la dimensione 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

Nell'esempio seguente sono riportate 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

Aggiornare 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 una nuova regione, è necessario un host originale esterno. Una volta avviata una regione, devi riportare gli host di origine ai cluster locali in overrides.yaml e poi applicare nuovamente la configurazione.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Controlla lo stato del cluster Cassandra

Il comando seguente è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato del 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

OpenShift

Configura l'host seed a 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 unire il data center esistente. Senza questa configurazione, i cluster Kubernetes multiregionali non si sarebbero a conoscenza gli uni degli altri.

Nel file overrides.yaml del cluster originale, assicurati che cassandra:hostNetwork sia impostato su true. Ad esempio:
```
cassandra:
  hostNetwork: true
```
Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seed:
```
kubectl config use-context original-cluster-name
```

Esegui questo comando kubectl per identificare un indirizzo host originale per Cassandra nella regione attuale.

Un indirizzo host originale consente a una nuova istanza di regione di trovare il cluster originale al primo avvio per apprendere la topologia del cluster. L'indirizzo host originale viene 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

Seleziona l'indirizzo IP dell'host Cassandra di origine da utilizzare come host seed a più regioni. In questo esempio, il cluster apigee-cassandra-default-0è in esecuzione e l'host seed è 10.0.0.11.
Nel data center 2, copia il file di override in un nuovo file il cui nome include il nome del cluster. Ad esempio, overrides_your_cluster_name.yaml.

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:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP # Cassandra pod IP address from the source region.
     datacenter: data_center_name

Ad esempio:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"

Nel nuovo data center o nella nuova regione, prima di installare l'ambiente ibrido, imposta in overrides_your_cluster_name.yaml i certificati e le credenziali TLS che hai impostato nella prima regione.
NOTA: nel secondo data center assicurati di utilizzare gli stessi certificati e credenziali TLS di Cassandra 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, consulta la pagina relativa alla configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host originale, puoi impostare la nuova regione.

Per configurare la nuova regione:

Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova CA radice 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 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 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 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 l'ambiente ibrido nella nuova regione:

Importante: quando espandi la versione ibrida di Apigee in un nuovo data center a livello di regione, assicurati di installare la stessa versione dell'ambiente ibrido presente nel tuo data center esistente. Evita di eseguire versioni diverse dell'ibrido in più data center.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Verifica che l'installazione ibrida vada a buon fine 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 nuovi sia quelli esistenti.

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

Configurare Cassandra su tutti i pod nei nuovi data center.
1. Ottieni 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. Nei seguenti esempi, 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 assegni a questi metadati. Puoi utilizzare qualsiasi nome.
  - NAMESPACE è lo stesso spazio dei nomi fornito in overrides.yaml. In genere è "apigee".
  - APIGEEORG_VALUE è il valore dell'output del 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: 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 comando seguente:
```
kubectl apply -f datareplication.yaml
```
4. Verifica lo stato della ricompilazione utilizzando il comando seguente.
  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 avere un aspetto simile a questo:
```
{
  "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 nuova creazione dai log. Inoltre, verifica la dimensione 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

Nell'esempio seguente sono riportate 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

Aggiornare 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 una nuova regione, è necessario un host originale esterno. Una volta avviata una regione, devi riportare gli host di origine ai cluster locali in overrides.yaml e poi applicare nuovamente la configurazione.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Controlla lo stato del cluster Cassandra

Il comando seguente è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato del 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.

Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.

Ultimo aggiornamento 2024-04-30 UTC.