Questa pagina è stata tradotta dall'API Cloud Translation.

Ripristino in più regioni

In questa pagina viene descritto come recuperare o ripristinare Cassandra in più regioni.

In un deployment multiregionale, Apigee hybrid viene distribuito in più località geografiche in data center diversi. Se una o più regioni hanno esito negativo, ma rimangono regioni integre, puoi utilizzare una regione integro per recuperare le regioni di Cassandra non riuscite con i dati più recenti.

In caso di errore catastrofico di tutte le regioni ibride, Cassandra può essere ripristinato. È importante notare che, se nel deployment sono presenti più organizzazioni Apigee, il processo di ripristino ripristina i dati per tutte le organizzazioni. In una configurazione con più organizzazioni, il ripristino solo di un'organizzazione specifica non è supportato.

Questo argomento descrive entrambi gli approcci per recuperare le regioni in errore:

Recupera le regioni non riuscite - Descrive i passaggi per recuperare le regioni non riuscite in base a una regione integro.
Ripristina regioni non riuscite: descrive i passaggi per ripristinare le regioni in errore da un backup. Questo approccio è necessario solo se sono interessate tutte le regioni ibride.

Recupera regioni non riuscite

Per recuperare le regioni non riuscite da una regione integra, segui questi passaggi:

Reindirizza il traffico API dalle regioni interessate alla regione funzionante. Pianifica la capacità di conseguenza per supportare il traffico deviato dalle regioni con errori.
Rimuovi la regione interessata. Per ogni regione interessata, segui i passaggi descritti in Disattivare una regione ibrida. Attendi il completamento del ritiro prima di andare al passaggio successivo.
Ripristina la regione interessata. Per eseguire il ripristino, crea una nuova regione, come descritto in Deployment multiregionale su GKE, GKE On-Prem e AKS.

Ripristino da un backup

Nota: se vuoi conservare una configurazione esistente per la risoluzione dei problemi e l'analisi delle cause principali (RCA), devi eliminare tutti i componenti org e env dal cluster Kubernetes ad eccezione del controller Apigee e conservare il cluster. Il cluster conterrà il datastore Apigee (Cassandra) esistente che puoi utilizzare per la risoluzione dei problemi. Crea un nuovo cluster Kubernetes e ripristina Cassandra nel nuovo cluster.

Il backup di Cassandra può risiedere su Cloud Storage o su un server remoto in base alla tua configurazione. Per ripristinare Cassandra da un backup, segui questi passaggi:

Importante: se hai installato Apigee hybrid in più regioni, devi controllare il file degli override per la regione che stai ripristinando per assicurarti che cassandra:hostNetwork sia impostato su false prima di eseguire il ripristino. Per controllare l'impostazione hostNetwork nella regione che stai tentando di ripristinare, utilizza questo comando:

kubectl -n apigee get apigeeds -o=jsonpath='{.items[].spec.components.cassandra.hostNetwork}'

Apri il file degli override per la regione da ripristinare.
Imposta cassandra:hostNetwork su false.

Utilizza apigeectl per applicare il file degli override:

$APIGEECTL_HOME/apigeectl apply YOUR_OVERRIDES_FILE.yaml

Prima di continuare, verifica che hostNetwork sia impostato su false:

kubectl -n apigee get apigeeds -o=jsonpath='{.items[].spec.components.cassandra.hostNetwork}'

Elimina l'ibrido dalla regione che stai ripristinando:
```
apigeectl delete -f overrides.yaml
```
Ripristina la regione che ti interessa da un backup. Per maggiori informazioni, consulta la pagina Ripristinare una regione da un backup.
Rimuovi i riferimenti alle regioni eliminate e aggiungi i riferimenti alle regioni ripristinate nei metadati KeySpaces.
Ottieni il nome della regione utilizzando l'opzione nodetool status.
```
kubectl exec -n apigee -it apigee-cassandra-default-0 -- bash
      nodetool  -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status |grep -i Datacenter
```
dove:
- APIGEE_JMX_USER è il nome utente dell'utente delle operazioni JMX di Cassandra. Utilizzato per l'autenticazione e la comunicazione con l'interfaccia JMX di Cassandra. Vedi cassandra:auth:jmx:username.
- APIGEE_JMX_PASSWORD è la password per l'utente delle operazioni JMX di Cassandra. Vedi cassandra:auth:jmx:password.
Aggiorna la replica KeySpaces.
1. Crea un container client e connettiti al cluster Cassandra tramite l'interfaccia CQL.
2. Recupera l'elenco degli spazi delle chiavi utente dall'interfaccia CQL:
```
cqlsh CASSANDRA_SEED_HOST -u APIGEE_DDL_USER -p APIGEE_DDL_PASSWORD
      --ssl -e "select keyspace_name from system_schema.keyspaces;"|grep -v system
```
  dove:
  - CASSANDRA_SEED_HOST è l'host originale di Cassandra per più regioni. Per la maggior parte delle installazioni multiregionali, utilizza l'indirizzo IP di un host nella prima regione. Vedi Configurare Apigee hybrid per più regioni e cassandra:externalSeedHost.
  - APIGEE_DDL_USER e APIGEE_DDL_PASSWORD sono il nome utente e la password amministratore dell'utente Cassandra Data Definition Language (DDL). I valori predefiniti sono "ddl_user" e "iloveapis123".
    Puoi controllare il nome utente e la password DDL controllando il valore memorizzato nel apigee-datastore-default-credssecret. Per controllare questo secret, devi disporre dei privilegi amministrativi. Il seguente comando restituirà i valori codificati in base-64 per il nome utente e la password DDL:
```
kubectl get secret apigee-datastore-default-creds -n apigee -o yaml
```
    Consulta cassandra.auth.ddl.password nel riferimento sulle proprietà di configurazione e Opzioni a riga di comando nella documentazione cqlsh di Apache Cassandra.
3. Per ogni spazio delle chiavi, esegui questo comando dall'interfaccia CQL per aggiornare le impostazioni di replica:
```
ALTER KEYSPACE KEYSPACE_NAME WITH replication = {'class': 'NetworkTopologyStrategy', 'REGION_NAME':3};
```
  dove:
  - KEYSPACE_NAME è il nome dello spazio delle chiavi elencato nell'output del passaggio precedente.
  - REGION_NAME è il nome della regione ottenuto nel passaggio 4.