Effectuer une restauration dans plusieurs régions

Cette page explique comment récupérer ou restaurer Cassandra dans plusieurs régions.

Dans un déploiement multirégional, Apigee hybrid est déployé dans plusieurs emplacements géographiques situés dans différents centres de données. Si une ou plusieurs régions connaissent une défaillance, mais qu'il reste des régions opérationnelles, vous pouvez utiliser l'une de ces régions opérationnelles afin de récupérer les données les plus récentes pour les régions Cassandra subissant une défaillance.

En cas de défaillance sérieuse de toutes les régions hybrides, il est possible de restaurer Cassandra. Il est important de noter que, si vous avez plusieurs organisations Apigee dans votre déploiement, le processus de restauration restaure les données pour toutes les organisations. Dans une configuration comportant plusieurs organisations, la restauration d'une organisation spécifique n'est pas acceptée.

Cet article décrit les deux approches permettant de récupérer la ou les régions subissant une défaillance :

Récupérer la ou les régions ayant échoué : décrit la procédure de récupération de la ou des régions ayant échoué en fonction d'une région opérationnelle.
Restaurer la ou les régions ayant échoué : décrit la procédure à suivre pour restaurer la ou les régions ayant échoué à partir d'une sauvegarde. Cette approche n'est requise que si toutes les régions hybrides sont affectées.

Récupérer des régions ayant échoué

Pour récupérer une ou plusieurs régions ayant échoué à partir d'une région opérationnelle, procédez comme suit :

Redirigez le trafic de l'API des régions concernées vers la région opérationnelle. Planifiez la capacité en conséquence pour gérer le trafic détourné des régions défaillantes.
Mettez hors service la région concernée. Pour chaque région affectée, suivez les étapes décrites dans la section Mettre hors service une région hybride. Attendez la fin de la mise hors service avant de passer à l'étape suivante.
Restaurez la région affectée. Pour effectuer une restauration, créez une région comme décrit dans la section Déploiement multirégional sur GKE, GKE On-Prem et AKS.

Effectuer une restauration à partir d'une sauvegarde

Remarque : Si vous souhaitez conserver une configuration existante pour le dépannage et l'analyse des causes fondamentales, vous devez supprimer tous les composants org et env du Cluster Kubernetes à l'exception du contrôleur Apigee, et conserver le cluster Le cluster inclut le datastore Apigee existant (Cassandra) qui peut vous permettre de résoudre des problèmes. Créez un cluster Kubernetes, puis restaurez Cassandra dans le nouveau cluster.

En fonction de votre configuration, la sauvegarde Cassandra peut se trouver sur Cloud Storage ou sur un serveur distant. Pour restaurer Cassandra à partir d'une sauvegarde, procédez comme suit :

Supprimez le déploiement hybride Apigee de toutes les régions :
```
apigeectl delete -f overrides.yaml
```
Restaurez la région souhaitée à partir d'une sauvegarde. Pour en savoir plus, consultez la section Restaurer une région à partir d'une sauvegarde.
Supprimez les références des régions supprimées et ajoutez les références des régions restaurées dans les métadonnées KeySpaces.
Récupérez le nom de la région à l'aide de l'option 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
```
où :
- APIGEE_JMX_USER est le nom de l'utilisateur des opérations Cassandra JMX. Permet l'authentification et la communication avec l'interface Cassandra JMX. Consultez cassandra:auth:jmx:username.
- APIGEE_JMX_PASSWORD est le mot de passe de l'utilisateur des opérations Cassandra JMX. Consultez cassandra:auth:jmx:password.
Mettez à jour la réplication KeySpaces.
1. Créez un conteneur client et connectez-vous au cluster Cassandra via l'interface CQL.
2. Obtenez la liste des espaces de clés utilisateur à partir de l'interface 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
```
  où :
  - CASSANDRA_SEED_HOST est l'hôte source multirégional pour Cassandra. Pour la plupart des installations multirégionales, utilisez l'adresse IP d'un hôte de votre première région. Consultez les sections Configurer Apigee hybrid pour une zone multirégionale et cassandra:externalSeedHost.
  - APIGEE_DDL_USER et APIGEE_DDL_PASSWORD sont le nom d'utilisateur et le mot de passe d'administrateur de l'utilisateur Cassandra LDD (langage de définition de données). Les valeurs par défaut sont "ddl_user" et "iloveapis123".
    Vous pouvez vérifier le nom d'utilisateur et le mot de passe LDD en consultant la valeur stockée dans le secret apigee-datastore-default-creds. Vous devez disposer des droits d'administrateur pour vérifier ce secret. La commande suivante renvoie les valeurs encodées en base64 pour le nom d'utilisateur et le mot de passe LDD :
```
kubectl get secret apigee-datastore-default-creds -n apigee -o yaml
```
    Consultez la section cassandra.auth.ddl.password dans la documentation de référence sur les propriétés de configuration et les options de ligne de commande dans la documentation cqlsh Apache Cassandra.
3. Pour chaque espace de clés, exécutez la commande suivante à partir de l'interface CQL pour mettre à jour les paramètres de réplication :
```
ALTER KEYSPACE KEYSPACE_NAME WITH replication = {'class': 'NetworkTopologyStrategy', 'REGION_NAME':3};
```
  où :
  - KEYSPACE_NAME correspond au nom de l'espace de clés répertorié dans la sortie de l'étape précédente.
  - REGION_NAME correspond au nom de la région obtenu à l'étape 4.