Déploiement multirégional

Vous consultez actuellement la version 1.9 de la documentation d'Apigee hybrid. Pour en savoir plus, consultez la section Versions compatibles.

Version 1.9 (unsupported)

   Versions compatibles :

• v1.13 (la plus récente)
• v1.12
• v1.11                         
• Liste des versions compatibles

   Versions non compatibles :

• v1.10
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Cet article décrit un déploiement multirégional pour Apigee hybrid sur GKE, Anthos GKE déployé sur site, Microsoft® Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) et sur Red Hat OpenShift. Sélectionnez votre plate-forme dans les prérequis et les procédures.

Voici quelques exemple de topologies pour le déploiement multirégional :

• Actif/Actif : lorsque des applications sont déployées dans plusieurs emplacements géographiques et que vous avez besoin d'une réponse d'API à faible latence pour vos déploiements. Vous avez la possibilité de déployer un environnement hybride dans plusieurs emplacements géographiques les plus proches de vos clients. Par exemple : la côte ouest des États-Unis, la côte est des États-Unis, l'Europe, l'Asie-Pacifique.
• Actif/Passif : lorsque vous disposez d'une région principale et d'une région de basculement ou de reprise après sinistre.

Les régions d'un déploiement hybride multirégional communiquent via Cassandra, comme le montre l'image suivante :

Prérequis

Avant de configurer un environnement hybride pour plusieurs régions, vous devez remplir les conditions préalables suivantes :

GKE

• Lorsque vous installez des déploiements Apigee multirégionaux entre différents réseaux (par exemple, différents fournisseurs de services cloud, différents réseaux VPC, infrastructures cloud et sur site, etc.), vous devez fournir une connectivité interne entre ces réseaux distincts que Cassandra peut utiliser pour communiquer entre les nœuds. Cela peut être réalisé avec des VPN ou des solutions de connectivité spécifiques au cloud.
• Si vous utilisez Workload Identity dans un cluster pour authentifier des comptes de service, chaque cluster que vous développez doit également utiliser Workload Identity. Consultez Activer Workload Identity avec Apigee hybrid.
• Configurez des clusters Kubernetes dans plusieurs régions avec des blocs CIDR différents
• Assurez-vous que cert-manager est installé dans chaque cluster.
• Configurez la communication interrégionale
• Assurez-vous que tous les pods Cassandra peuvent résoudre leurs propres noms d'hôte. Si hostNetwork est défini sur false, le nom d'hôte est le nom du pod Cassandra. Si hostNetwork est défini sur true, le nom d'hôte est le nom d'hôte du nœud Kubernetes exécutant le pod Cassandra.
  Conseil : Pour vérifier si la résolution du nom d'hôte fonctionne, exécutez ces commandes.
  
  Si hostNetwork est défini sur false, exécutez la commande 1. Si hostNetwork est défini sur true, exécutez la commande 2.
  
  Si la résolution du nom d'hôte fonctionne, le résultat affiche une adresse IP. Si la résolution du nom d'hôte échoue, le résultat inclut "Host not found" (Hôte introuvable).
  
  Commande 1 :

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Commande 2 :

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Exigences multirégionales Cassandra :
  • Assurez-vous que l'espace de noms du réseau du pod dispose d'une connectivité entre les régions, y compris les pare-feu, les VPN, l'appairage VPC et l'appairage vNet. C'est le cas de la plupart des installations GKE.
  • Si l'espace de noms du réseau du pod n'a pas de connectivité entre les clusters (les clusters s'exécutent en "réseau en mode île"), activez la fonctionnalité Kubernetes hostNetwork en définissant cassandra.hostNetwork: true dans le fichier de remplacement pour toutes les régions de votre installation multirégionale Apigee hybrid.

    Pour plus d'informations sur la nécessité de hostNetwork, consultez la section Clusters en mode île et hostNetwork ci-dessous.

  • Activez hostNetwork sur les clusters existants avant d'étendre votre configuration multirégionale à de nouvelles régions.
  • Lorsque hostNetwork est activé, assurez-vous que les nœuds de calcul peuvent effectuer une résolution DNS directe de leurs noms d'hôte. Apigee Cassandra utilise la résolution DNS directe pour obtenir l'adresse IP de l'hôte au démarrage.
    Conseil : Si la résolution DNS ne fonctionne pas, essayez cette solution.

    Ajoutez une entrée d'hôte statique dans le fichier /etc/hosts de chaque nœud de calcul Cassandra comme suit :

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    ou

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • Ouvrez le port TCP 7001 entre les clusters Kubernetes dans toutes les régions pour permettre aux nœuds de calcul des régions et des centres de données de communiquer. Pour en savoir plus sur les numéros de port Cassandra, consultez la page Configurer les ports.

Pour en savoir plus, consultez la documentation concernant Kubernetes.

Remarque : Apigee vous recommande de vous assurer que les heures de vos serveurs sont synchronisées.

Plusieurs fonctionnalités, telles que l'expiration et la révocation de jetons, dépendent de l'heure exacte du système. Si vous hébergez les composants de l'environnement d'exécution dans différents centres de données, assurez-vous que les heures des systèmes sont synchronisées.

Vous pouvez utiliser un outil tel que ntpdate pour vérifier que les heures des serveurs sont synchronisées.

GKE On-Prem

• Lorsque vous installez des déploiements Apigee multirégionaux entre différents réseaux (par exemple, différents fournisseurs de services cloud, différents réseaux VPC, infrastructures cloud et sur site, etc.), vous devez fournir une connectivité interne entre ces réseaux distincts que Cassandra peut utiliser pour communiquer entre les nœuds. Cela peut être réalisé avec des VPN ou des solutions de connectivité spécifiques au cloud.
• Configurez des clusters Kubernetes dans plusieurs régions avec des blocs CIDR différents
• Assurez-vous que cert-manager est installé dans chaque cluster.
• Configurez la communication interrégionale
• Assurez-vous que tous les pods Cassandra peuvent résoudre leurs propres noms d'hôte. Si hostNetwork est défini sur false, le nom d'hôte est le nom du pod Cassandra. Si hostNetwork est défini sur true, le nom d'hôte est le nom d'hôte du nœud Kubernetes exécutant le pod Cassandra.
  Conseil : Pour vérifier si la résolution du nom d'hôte fonctionne, exécutez ces commandes.
  
  Si hostNetwork est défini sur false, exécutez la commande 1. Si hostNetwork est défini sur true, exécutez la commande 2.
  
  Si la résolution du nom d'hôte fonctionne, le résultat affiche une adresse IP. Si la résolution du nom d'hôte échoue, le résultat inclut "Host not found" (Hôte introuvable).
  
  Commande 1 :

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Commande 2 :

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Exigences multirégionales Cassandra :
  • Si l'espace de noms du réseau du pod n'a pas de connectivité entre les clusters (les clusters s'exécutent en "réseau en mode île", le cas d'installation par défaut dans GKE On-Prem), activez la fonctionnalité Kubernetes hostNetwork en définissant cassandra.hostNetwork: true dans le fichier de remplacement pour toutes les régions de votre installation multirégionale Apigee hybrid.

    Pour plus d'informations sur la nécessité de hostNetwork, consultez la section Clusters en mode île et hostNetwork ci-dessous.

  • Activez hostNetwork sur les clusters existants avant d'étendre votre configuration multirégionale à de nouvelles régions.
  • Lorsque hostNetwork est activé, assurez-vous que les nœuds de calcul peuvent effectuer une résolution DNS directe de leurs noms d'hôte. Apigee Cassandra utilise la résolution DNS directe pour obtenir l'adresse IP de l'hôte au démarrage.
    Conseil : Si la résolution DNS ne fonctionne pas, essayez cette solution.

    Ajoutez une entrée d'hôte statique dans le fichier /etc/hosts de chaque nœud de calcul Cassandra comme suit :

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    ou

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • Ouvrez les ports Cassandra entre les clusters Kubernetes dans toutes les régions pour permettre aux nœuds de calcul des régions et des centres de données de communiquer. Pour en savoir plus sur les numéros de ports Cassandra, consultez la page Configurer des ports.

Pour en savoir plus, consultez la documentation concernant Kubernetes.

Remarque : Apigee vous recommande de vous assurer que les heures de vos serveurs sont synchronisées.

Plusieurs fonctionnalités, telles que l'expiration et la révocation de jetons, dépendent de l'heure exacte du système. Si vous hébergez les composants de l'environnement d'exécution dans différents centres de données, assurez-vous que les heures des systèmes sont synchronisées.

Vous pouvez utiliser un outil tel que ntpdate pour vérifier que les heures des serveurs sont synchronisées.

AKS

• Lorsque vous installez des déploiements Apigee multirégionaux entre différents réseaux (par exemple, différents fournisseurs de services cloud, différents réseaux VPC, infrastructures cloud et sur site, etc.), vous devez fournir une connectivité interne entre ces réseaux distincts que Cassandra peut utiliser pour communiquer entre les nœuds. Cela peut être réalisé avec des VPN ou des solutions de connectivité spécifiques au cloud.
• Suivez le guide d'installation de la solution hybride pour connaître les conditions préalables relatives à Google Cloud et à la configuration d'organisation avant de passer aux étapes de configuration du cluster.
• Assurez-vous que cert-manager est installé dans chaque cluster.
• Assurez-vous que tous les pods Cassandra peuvent résoudre leurs propres noms d'hôte. Si hostNetwork est défini sur false, le nom d'hôte est le nom du pod Cassandra. Si hostNetwork est défini sur true, le nom d'hôte est le nom d'hôte du nœud Kubernetes exécutant le pod Cassandra.
  Conseil : Pour vérifier si la résolution du nom d'hôte fonctionne, exécutez ces commandes.
  
  Si hostNetwork est défini sur false, exécutez la commande 1. Si hostNetwork est défini sur true, exécutez la commande 2.
  
  Si la résolution du nom d'hôte fonctionne, le résultat affiche une adresse IP. Si la résolution du nom d'hôte échoue, le résultat inclut "Host not found" (Hôte introuvable).
  
  Commande 1 :

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Commande 2 :

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Exigences multirégionales Cassandra :
  • Si l'espace de noms du réseau du pod n'a pas de connectivité entre les clusters (les clusters s'exécutent en "réseau en mode île", le cas par défaut dans les installations AKS), activez la fonctionnalité Kubernetes hostNetwork en définissant cassandra.hostNetwork: true dans le fichier de remplacement pour toutes les régions de votre installation multirégionale Apigee hybrid.

    Pour plus d'informations sur la nécessité de hostNetwork, consultez la section Clusters en mode île et hostNetwork ci-dessous.

  • Activez hostNetwork sur les clusters existants avant d'étendre votre configuration multirégionale à de nouvelles régions.
  • Lorsque hostNetwork est activé, assurez-vous que les nœuds de calcul peuvent effectuer une résolution DNS directe de leurs noms d'hôte. Apigee Cassandra utilise la résolution DNS directe pour obtenir l'adresse IP de l'hôte au démarrage.
    Conseil : Si la résolution DNS ne fonctionne pas, essayez cette solution.

    Ajoutez une entrée d'hôte statique dans le fichier /etc/hosts de chaque nœud de calcul Cassandra comme suit :

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    ou

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • Ouvrez les ports Cassandra entre les clusters Kubernetes dans toutes les régions pour permettre aux nœuds de calcul des régions et des centres de données de communiquer. Pour en savoir plus sur les numéros de ports Cassandra, consultez la page Configurer des ports.

Pour en savoir plus, consultez la documentation concernant Kubernetes.

Remarque : Apigee vous recommande de vous assurer que les heures de vos serveurs sont synchronisées.

Plusieurs fonctionnalités, telles que l'expiration et la révocation de jetons, dépendent de l'heure exacte du système. Si vous hébergez les composants de l'environnement d'exécution dans différents centres de données, assurez-vous que les heures des systèmes sont synchronisées.

Vous pouvez utiliser un outil tel que ntpdate pour vérifier que les heures des serveurs sont synchronisées.

EKS

• Lorsque vous installez des déploiements Apigee multirégionaux entre différents réseaux (par exemple, différents fournisseurs de services cloud, différents réseaux VPC, infrastructures cloud et sur site, etc.), vous devez fournir une connectivité interne entre ces réseaux distincts que Cassandra peut utiliser pour communiquer entre les nœuds. Cela peut être réalisé avec des VPN ou des solutions de connectivité spécifiques au cloud.
• Suivez le guide d'installation de la solution hybride pour connaître les conditions préalables relatives à Google Cloud et à la configuration d'organisation avant de passer aux étapes de configuration du cluster.
• Assurez-vous que cert-manager est installé dans chaque cluster.
• Assurez-vous que tous les pods Cassandra peuvent résoudre leurs propres noms d'hôte. Si hostNetwork est défini sur false, le nom d'hôte est le nom du pod Cassandra. Si hostNetwork est défini sur true, le nom d'hôte est le nom d'hôte du nœud Kubernetes exécutant le pod Cassandra.
  Conseil : Pour vérifier si la résolution du nom d'hôte fonctionne, exécutez ces commandes.
  
  Si hostNetwork est défini sur false, exécutez la commande 1. Si hostNetwork est défini sur true, exécutez la commande 2.
  
  Si la résolution du nom d'hôte fonctionne, le résultat affiche une adresse IP. Si la résolution du nom d'hôte échoue, le résultat inclut "Host not found" (Hôte introuvable).
  
  Commande 1 :

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Commande 2 :

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Exigences multirégionales Cassandra :
  • Si l'espace de noms du réseau du pod n'a pas de connectivité entre les clusters (les clusters s'exécutent en "réseau en mode île"), activez la fonctionnalité Kubernetes hostNetwork en définissant cassandra.hostNetwork: true dans le fichier de remplacement pour toutes les régions de votre installation multirégionale Apigee hybrid. Par défaut, Amazon EKS utilise le modèle de réseau entièrement intégré.

    Pour plus d'informations sur la nécessité de hostNetwork, consultez la section Clusters en mode île et hostNetwork ci-dessous.

  • Activez hostNetwork sur les clusters existants avant d'étendre votre configuration multirégionale à de nouvelles régions.
  • Lorsque hostNetwork est activé, assurez-vous que les nœuds de calcul peuvent effectuer une résolution DNS directe de leurs noms d'hôte. Apigee Cassandra utilise la résolution DNS directe pour obtenir l'adresse IP de l'hôte au démarrage.
    Conseil : Si la résolution DNS ne fonctionne pas, essayez cette solution.

    Ajoutez une entrée d'hôte statique dans le fichier /etc/hosts de chaque nœud de calcul Cassandra comme suit :

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    ou

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • Ouvrez les ports Cassandra entre les clusters Kubernetes dans toutes les régions pour permettre aux nœuds de calcul des régions et des centres de données de communiquer. Pour en savoir plus sur les numéros de ports Cassandra, consultez la page Configurer des ports.

Pour en savoir plus, consultez la documentation concernant Kubernetes.

Remarque : Apigee vous recommande de vous assurer que les heures de vos serveurs sont synchronisées.

Plusieurs fonctionnalités, telles que l'expiration et la révocation de jetons, dépendent de l'heure exacte du système. Si vous hébergez les composants de l'environnement d'exécution dans différents centres de données, assurez-vous que les heures des systèmes sont synchronisées.

Vous pouvez utiliser un outil tel que ntpdate pour vérifier que les heures des serveurs sont synchronisées.

OpenShift

• Lorsque vous installez des déploiements Apigee multirégionaux entre différents réseaux (par exemple, différents fournisseurs de services cloud, différents réseaux VPC, infrastructures cloud et sur site, etc.), vous devez fournir une connectivité interne entre ces réseaux distincts que Cassandra peut utiliser pour communiquer entre les nœuds. Cela peut être réalisé avec des VPN ou des solutions de connectivité spécifiques au cloud.
• Suivez le guide d'installation de la solution hybride pour connaître les conditions préalables relatives à Google Cloud et à la configuration d'organisation avant de passer aux étapes de configuration du cluster.
• Assurez-vous que cert-manager est installé dans chaque cluster.
• Assurez-vous que tous les pods Cassandra peuvent résoudre leurs propres noms d'hôte. Si hostNetwork est défini sur false, le nom d'hôte est le nom du pod Cassandra. Si hostNetwork est défini sur true, le nom d'hôte est le nom d'hôte du nœud Kubernetes exécutant le pod Cassandra.
  Conseil : Pour vérifier si la résolution du nom d'hôte fonctionne, exécutez ces commandes.
  
  Si hostNetwork est défini sur false, exécutez la commande 1. Si hostNetwork est défini sur true, exécutez la commande 2.
  
  Si la résolution du nom d'hôte fonctionne, le résultat affiche une adresse IP. Si la résolution du nom d'hôte échoue, le résultat inclut "Host not found" (Hôte introuvable).
  
  Commande 1 :

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Commande 2 :

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Exigences multirégionales Cassandra :
  • Si l'espace de noms du réseau du pod n'a pas de connectivité entre les clusters (les clusters s'exécutent en "réseau en mode île", le cas par défaut dans les installations OpenShift), activez la fonctionnalité hostNetwork Kubernetes en définissant cassandra.hostNetwork: true dans le fichier de remplacement pour toutes les régions de votre installation multirégionale Apigee hybrid.

    Pour plus d'informations sur la nécessité de hostNetwork, consultez la section Clusters en mode île et hostNetwork ci-dessous.

  • Activez hostNetwork sur les clusters existants avant d'étendre votre configuration multirégionale à de nouvelles régions.
  • Lorsque hostNetwork est activé, assurez-vous que les nœuds de calcul peuvent effectuer une résolution DNS directe de leurs noms d'hôte. Apigee Cassandra utilise la résolution DNS directe pour obtenir l'adresse IP de l'hôte au démarrage.
    Conseil : Si la résolution DNS ne fonctionne pas, essayez cette solution.

    Ajoutez une entrée d'hôte statique dans le fichier /etc/hosts de chaque nœud de calcul Cassandra comme suit :

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    ou

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • Ouvrez les ports Cassandra entre les clusters Kubernetes dans toutes les régions pour permettre aux nœuds de calcul des régions et des centres de données de communiquer. Pour en savoir plus sur les numéros de ports Cassandra, consultez la page Configurer des ports.

Pour en savoir plus, consultez la documentation concernant Kubernetes.

Remarque : Apigee vous recommande de vous assurer que les heures de vos serveurs sont synchronisées.

Plusieurs fonctionnalités, telles que l'expiration et la révocation de jetons, dépendent de l'heure exacte du système. Si vous hébergez les composants de l'environnement d'exécution dans différents centres de données, assurez-vous que les heures des systèmes sont synchronisées.

Vous pouvez utiliser un outil tel que ntpdate pour vérifier que les heures des serveurs sont synchronisées.

Clusters en mode île et hostNetwork

Il existe deux principaux modèles de réseau pour les clusters Kubernetes : les modèles entièrement intégrés (ou plats) et les clusters en mode île. Apigee recommande d'utiliser le modèle de réseau plat dans la mesure du possible, car il simplifie la connectivité multirégionale Cassandra. Lorsqu'un cluster Kubernetes est configuré en mode île, le réseau du pod est isolé. Les pods ne peuvent pas communiquer directement avec les pods exécutés dans d'autres clusters à l'aide de l'adresse IP du pod. Pour plus d'informations sur les différences entre ces deux modèles de réseau et des exemples, consultez la section Implémentations de modèles de réseau classiques.

Lorsque Apigee hybride s'exécute sur au moins deux clusters Kubernetes en utilisant un modèle de mise en réseau en mode île, vous devez activer le paramètre hostNetwork pour Cassandra via la propriété cassandra.hostNetwork. Par défaut, les pods Kubernetes sont isolés dans des espaces de noms réseau individuels qui les empêchent d'utiliser l'adresse IP du nœud de calcul Kubernetes. Lorsque hostNetwork est défini sur true, le pod n'est pas isolé dans son propre espace de noms réseau et utilise à la place l'adresse IP et le nom d'hôte du nœud de calcul Kubernetes sur lequel le pod est programmé. Cela permet à Cassandra d'utiliser de manière native l'adresse IP du nœud de calcul Kubernetes comme adresse IP, ce qui permet à Cassandra d'établir un maillage complet entre tous les pods Cassandra dans plusieurs clusters exécutés en mode île.

Résolution du nom d'hôte Cassandra

Bien qu'un pod Cassandra ne résolve pas les autres pods Cassandra par nom d'hôte, au démarrage, Cassandra vérifie que son propre nom d'hôte peut être résolu par DNS. Comme le nom d'hôte du pod est identique au nom d'hôte du nœud de calcul Kubernetes lorsque hostNetwork est défini sur "true", le nom d'hôte du nœud de calcul doit pouvoir être résolu en adresse IP via le service DNS du cluster. Si le nom d'hôte du nœud de calcul Kubernetes ne peut pas être résolu, le pod Cassandra échoue. Par conséquent, il est important que les noms d'hôte des nœuds de calcul Kubernetes puissent être résolus à partir des pods du cluster lorsque vous définissez hostNetwork sur true.

Configurer Apigee hybrid pour une zone multirégionale

Cette section explique comment configurer Apigee hybrid pour une zone multirégionale.

GKE

Important : Lorsque vous déployez Apigee hybrid dans un nouveau centre de données régional, veillez à installer la même version que dans votre centre de données existant. Évitez d'exécuter différentes versions d'Apigee hybrid dans plusieurs centres de données.

Avertissement : Si l'installation échoue pour une nouvelle région, ne poursuivez pas l'installation. Au lieu de cela, supprimez l'installation d'Apigee hybrid et recréez-la sur la région défaillante.

Configurer l'hôte source multirégional

Cette section décrit comment étendre le cluster Cassandra existant à une nouvelle région. Cette configuration permet à la nouvelle région d'amorcer le cluster et de rejoindre le centre de données existant. Sans cette configuration, les clusters Kubernetes multirégionaux ne se connaîtraient pas les uns les autres.

1. Définissez le contexte kubectl sur le cluster d'origine avant de récupérer le nom source :

   kubectl config use-context original-cluster-name

2. Exécutez la commande kubectl suivante pour identifier une adresse d'hôte source pour Cassandra dans la région actuelle.

   Une adresse hôte source permet à une nouvelle instance régionale de trouver le cluster d'origine lors du premier démarrage pour apprendre la topologie du cluster. L'adresse hôte source est désignée comme point de contact dans le cluster.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra --field-selector status.phase=Running

   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

3. Déterminez quelles adresses IP renvoyées par la commande précédente seront les hôtes sources multirégionaux.
4. Dans le centre de données 2, configurez cassandra.multiRegionSeedHost et cassandra.datacenter sur la page Gérer les composants du plan d'exécution, où multiRegionSeedHost est l'une des adresses IP renvoyées par la commande précédente :

   cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name
     hostNetwork: false
     clusterName: cluster_name # must be the same for all regions

   Exemple :

   cassandra:
     multiRegionSeedHost: 10.0.0.11
     datacenter: "dc-2"
     rack: "ra-1"
     hostNetwork: false
     clusterName: my-apigee-cluster

5. Dans le nouveau centre de données ou la nouvelle région, définissez les mêmes certificats et identifiants TLS dans overrides.yaml que ceux définis dans la première région avant d'installer un environnement hybride.
   Remarque : Veillez à utiliser dans le deuxième centre de données les mêmes certificats et identifiants TLS Cassandra que ceux du centre de données d'origine. Les identifiants que vous avez définis dans le fichier de remplacement du premier centre de données doivent correspondre à ceux que vous avez spécifiés dans le fichier de remplacement du deuxième centre de données. Pour en savoir plus, consultez la section Configurer TLS pour Cassandra.

Configurer la nouvelle région

Après avoir configuré l'hôte source, vous pouvez configurer la nouvelle région.

Pour configurer la nouvelle région, procédez comme suit :

1. Copiez votre certificat à partir du cluster existant vers le nouveau cluster. Le nouveau certificat racine CA est utilisé par Cassandra et d'autres composants hybrides pour mTLS. Par conséquent, il est essentiel de disposer de certificats cohérents dans l'ensemble du cluster.
   1. Définissez le contexte sur l'espace de noms d'origine :

      kubectl config use-context original-cluster-name

   2. Exportez la configuration actuelle de l'espace de noms dans un fichier :

      kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   3. Exportez le secret apigee-ca vers un fichier :

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Définissez le contexte sur le nom du cluster de la nouvelle région :

      kubectl config use-context new-cluster-name

   5. Importez la configuration de l'espace de noms dans le nouveau cluster. Veillez à mettre à jour l'espace de noms dans le fichier si vous utilisez un espace de noms différent dans la nouvelle région :

      kubectl apply -f apigee-namespace.yaml

   6. Importez le secret dans le nouveau cluster :

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Installez la version hybride dans la nouvelle région. Assurez-vous que le fichier overrides-DC_name.yaml inclut les mêmes certificats TLS que ceux configurés dans la première région, comme expliqué dans la section précédente.

   Exécutez les deux commandes suivantes pour installer un environnement hybride dans la nouvelle région :

   Important : Lorsque vous déployez Apigee hybrid dans un nouveau centre de données régional, veillez à installer la même version que dans votre centre de données existant. Évitez d'exécuter différentes versions d'Apigee hybrid dans plusieurs centres de données.

   apigeectl init -f overrides/overrides-DC_name.yaml

   apigeectl apply -f overrides/overrides-DC_name.yaml

3. Vérifiez que l'installation hybride a réussi en exécutant la commande suivante :

   apigeectl check-ready -f overrides_DC_name.yaml

4. Vérifiez la configuration du cluster Cassandra en exécutant la commande suivante. La sortie doit afficher les centres de données existants et nouveaux.
   Avertissement : Si le résultat de cette commande n'affiche pas les centres de données existants et nouveaux, la configuration a échoué. Dans ce cas, ne continuez pas.

   Pour résoudre le problème, l'installation hybride sur la nouvelle région doit être supprimée et recréée. Consultez la page Désinstaller l'environnement d'exécution hybride. Si la configuration échoue, n'essayez pas de continuer ni de joindre le cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Exemple illustrant une configuration réussie :

   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

5. Configurez Cassandra sur tous les pods des nouveaux centres de données.
   1. Obtenez apigeeorg à partir du cluster à l'aide de la commande suivante :

      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      

      Exemple :

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      "rg-hybrid-b7d3b9c"
      

   2. Créez un fichier de ressource personnalisée pour la réplication de données Cassandra (YAML). Le fichier peut porter n'importe quel nom. Dans les exemples suivants, le fichier sera nommé datareplication.yaml.

      Le fichier doit contenir les éléments suivants :

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Où :

      • REGION_EXPANSION est le nom que vous attribuez à ces métadonnées. Vous pouvez utiliser n'importe quel nom.
      • NAMESPACE est le même espace de noms que celui fourni dans overrides.yaml. Il s'agit généralement de "apigee".
      • APIGEEORG_VALUE correspond à la valeur renvoyée par la commande kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name à l'étape précédente. Par exemple, rg-hybrid-b7d3b9c.
      • SOURCE_REGION est la région source, la valeur pour le centre de données se trouve dans la section "cassandra" du fichier yaml de remplacement de la région source.

      Exemple :

      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. Appliquez la fonction CassandraDataReplication avec la commande suivante :

      kubectl apply -f datareplication.yaml

   4. Vérifiez l'état de la recompilation à l'aide de la commande suivante.
      Remarque : L'opération de recompilation peut prendre plusieurs heures suivant la taille des données.

      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Les résultats doivent ressembler à ceci :

      {
        "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
      }

6. Vérifiez les processus de recompilation des journaux. Vérifiez également la taille des données à l'aide de la commande nodetool status :
   Remarque : Si l'opération de recompilation indique l'état terminé et que les journaux des processus de recompilation contiennent "Toutes les sessions terminées", toutes les données ont bien été copiées dans la nouvelle région.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   L'exemple suivant montre des entrées de journal :

   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

7. Mettez à jour les hôtes sources. Supprimez multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml, puis recommencez la même opération.
   Remarque : Les hôtes sources sont des membres de clusters locaux. Pour démarrer une nouvelle région, un hôte source externe est requis. Une fois qu'une région démarre, vous devez faire revenir les hôtes sources à leurs clusters locaux dans overrides.yaml, puis appliquer à nouveau la configuration.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Vérifier l'état du cluster Cassandra

La commande suivante permet de voir si la configuration du cluster a réussi dans deux centres de données. La commande vérifie l'état de nodetool pour les deux régions.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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: us-west1
====================
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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

GKE On-Prem

Important : Lorsque vous déployez Apigee hybrid dans un nouveau centre de données régional, veillez à installer la même version que dans votre centre de données existant. Évitez d'exécuter différentes versions d'Apigee hybrid dans plusieurs centres de données.

Avertissement : Si l'installation échoue pour une nouvelle région, ne poursuivez pas l'installation. Au lieu de cela, supprimez l'installation d'Apigee hybrid et recréez-la sur la région défaillante.

Configurer l'hôte source multirégional

Cette section décrit comment étendre le cluster Cassandra existant à une nouvelle région. Cette configuration permet à la nouvelle région d'amorcer le cluster et de rejoindre le centre de données existant. Sans cette configuration, les clusters Kubernetes multirégionaux ne se connaîtraient pas les uns les autres.

1. Dans le fichier overrides.yaml de votre cluster d'origine, assurez-vous que cassandra:hostNetwork est défini sur true. Exemple :

   cassandra:
     hostNetwork: true

   Pour en savoir plus sur la définition de hostNetwork: true, consultez la section Prérequis.

2. Si l'élément cassandra:hostNetwork n'est pas défini sur true, procédez comme suit :
   1. Remplacez cassandra.hostNetwork par true.
   2. Appliquez le fichier de configuration overrides.yaml à l'aide de la commande suivante :

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendez que les pods Cassandra aient effectué un redémarrage progressif.

   4. Vérifiez que le cluster Cassandra est opérationnel à l'aide des commandes suivantes :

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
        

      Assurez-vous que tous les nœuds Cassandra du résultat possèdent l'état Up and normal (UN) :

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
        

      Assurez-vous qu'aucun nœud inaccessible ne s'affiche dans le résultat.

      Conseil : APIGEE_JMX_USER et APIGEE_JMX_PASSWORD sont généralement définis dans les variables d'environnement $APIGEE_JMX_USER et $APIGEE_JMX_PASSWORD.
3. Définissez le contexte kubectl sur le cluster d'origine avant de récupérer le nom source :

   kubectl config use-context original-cluster-name

4. Exécutez la commande kubectl suivante pour identifier une adresse d'hôte source pour Cassandra dans la région actuelle.

   Une adresse hôte source permet à une nouvelle instance régionale de trouver le cluster d'origine lors du premier démarrage pour apprendre la topologie du cluster. L'adresse hôte source est désignée comme point de contact dans le cluster.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra --field-selector status.phase=Running

   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

5. Déterminez quelles adresses IP renvoyées par la commande précédente seront les hôtes sources multirégionaux.
6. Dans le centre de données 2, configurez cassandra.multiRegionSeedHost dans votre fichier de remplacement, où multiRegionSeedHost est l'une des adresses IP renvoyées par la commande précédente :

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name
     clusterName: cluster_name # must be the same for all regions

   Exemple :

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: 10.0.0.11
     datacenter: "dc-2"
     rack: "ra-1"
     clusterName: my-apigee-cluster

7. Dans le nouveau centre de données ou la nouvelle région, définissez les mêmes certificats et identifiants TLS dans overrides.yaml que ceux définis dans la première région avant d'installer un environnement hybride.
   Remarque : Veillez à utiliser dans le deuxième centre de données les mêmes certificats et identifiants TLS Cassandra que ceux du centre de données d'origine. Les identifiants que vous avez définis dans le fichier de remplacement du premier centre de données doivent correspondre à ceux que vous avez spécifiés dans le fichier de remplacement du deuxième centre de données. Pour en savoir plus, consultez la section Configurer TLS pour Cassandra.

Configurer la nouvelle région

Après avoir configuré l'hôte source, vous pouvez configurer la nouvelle région.

Pour configurer la nouvelle région, procédez comme suit :

1. Copiez votre certificat à partir du cluster existant vers le nouveau cluster. Le nouveau certificat racine CA est utilisé par Cassandra et d'autres composants hybrides pour mTLS. Par conséquent, il est essentiel de disposer de certificats cohérents dans l'ensemble du cluster.
   1. Définissez le contexte sur l'espace de noms d'origine :

      kubectl config use-context original-cluster-name

   2. Exportez la configuration actuelle de l'espace de noms dans un fichier :

      kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   3. Exportez le secret apigee-ca vers un fichier :

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Définissez le contexte sur le nom du cluster de la nouvelle région :

      kubectl config use-context new-cluster-name

   5. Importez la configuration de l'espace de noms dans le nouveau cluster. Veillez à mettre à jour l'espace de noms dans le fichier si vous utilisez un espace de noms différent dans la nouvelle région :

      kubectl apply -f apigee-namespace.yaml

   6. Importez le secret dans le nouveau cluster :

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Installez la version hybride dans la nouvelle région. Assurez-vous que le fichier overrides-DC_name.yaml inclut les mêmes certificats TLS que ceux configurés dans la première région, comme expliqué dans la section précédente.

   Exécutez les deux commandes suivantes pour installer un environnement hybride dans la nouvelle région :

   Important : Lorsque vous déployez Apigee hybrid dans un nouveau centre de données régional, veillez à installer la même version que dans votre centre de données existant. Évitez d'exécuter différentes versions d'Apigee hybrid dans plusieurs centres de données.

   apigeectl init -f overrides/overrides-DC_name.yaml

   apigeectl apply -f overrides/overrides-DC_name.yaml

3. Vérifiez que l'installation hybride a réussi en exécutant la commande suivante :

   apigeectl check-ready -f overrides_DC_name.yaml

4. Vérifiez la configuration du cluster Cassandra en exécutant la commande suivante. La sortie doit afficher les centres de données existants et nouveaux.
   Avertissement : Si le résultat de cette commande n'affiche pas les centres de données existants et nouveaux, la configuration a échoué. Dans ce cas, ne continuez pas.

   Pour résoudre le problème, l'installation hybride sur la nouvelle région doit être supprimée et recréée. Consultez la page Désinstaller l'environnement d'exécution hybride. Si la configuration échoue, n'essayez pas de continuer ni de joindre le cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Exemple illustrant une configuration réussie :

   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

5. Configurez Cassandra sur tous les pods des nouveaux centres de données.
   1. Obtenez apigeeorg à partir du cluster à l'aide de la commande suivante :

      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      

      Exemple :

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      "rg-hybrid-b7d3b9c"
      

   2. Créez un fichier de ressource personnalisée pour la réplication de données Cassandra (YAML). Le fichier peut porter n'importe quel nom. Dans les exemples suivants, le fichier sera nommé datareplication.yaml.

      Le fichier doit contenir les éléments suivants :

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Où :

      • REGION_EXPANSION est le nom que vous attribuez à ces métadonnées. Vous pouvez utiliser n'importe quel nom.
      • NAMESPACE est le même espace de noms que celui fourni dans overrides.yaml. Il s'agit généralement de "apigee".
      • APIGEEORG_VALUE correspond à la valeur renvoyée par la commande kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name à l'étape précédente. Par exemple, rg-hybrid-b7d3b9c.
      • SOURCE_REGION est la région source, la valeur pour le centre de données se trouve dans la section "cassandra" du fichier yaml de remplacement de la région source.

      Exemple :

      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. Appliquez la fonction CassandraDataReplication avec la commande suivante :

      kubectl apply -f datareplication.yaml

   4. Vérifiez l'état de la recompilation à l'aide de la commande suivante.
      Remarque : L'opération de recompilation peut prendre plusieurs heures suivant la taille des données.

      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Les résultats doivent ressembler à ceci :

      {
        "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
      }

6. Vérifiez les processus de recompilation des journaux. Vérifiez également la taille des données à l'aide de la commande nodetool status :
   Remarque : Si l'opération de recompilation indique l'état terminé et que les journaux des processus de recompilation contiennent "Toutes les sessions terminées", toutes les données ont bien été copiées dans la nouvelle région.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   L'exemple suivant montre des entrées de journal :

   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

7. Mettez à jour les hôtes sources. Supprimez multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml, puis recommencez la même opération.
   Remarque : Les hôtes sources sont des membres de clusters locaux. Pour démarrer une nouvelle région, un hôte source externe est requis. Une fois qu'une région démarre, vous devez faire revenir les hôtes sources à leurs clusters locaux dans overrides.yaml, puis appliquer à nouveau la configuration.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Vérifier l'état du cluster Cassandra

La commande suivante permet de voir si la configuration du cluster a réussi dans deux centres de données. La commande vérifie l'état de nodetool pour les deux régions.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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: us-west1
====================
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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

AKS

Important : Lorsque vous déployez Apigee hybrid dans un nouveau centre de données régional, veillez à installer la même version que dans votre centre de données existant. Évitez d'exécuter différentes versions d'Apigee hybrid dans plusieurs centres de données.

Avertissement : Si l'installation échoue pour une nouvelle région, ne poursuivez pas l'installation. Au lieu de cela, supprimez l'installation d'Apigee hybrid et recréez-la sur la région défaillante.

Créer un réseau virtuel dans chaque région

Suivez les recommandations Azure pour établir une communication interrégionale : VNet vers VNet : Connecter des réseaux virtuels dans Azure dans différentes régions.

Créer des clusters multirégionaux

Configurez des clusters Kubernetes dans plusieurs régions avec des blocs CIDR différents. Consultez également l'étape 1 : Créer un cluster. Utilisez les emplacements et les noms de réseaux virtuels que vous avez créés précédemment.

Ouvrez les ports Cassandra entre les clusters Kubernetes dans toutes les régions pour permettre aux nœuds de calcul des régions et des centres de données de communiquer. Pour en savoir plus sur les numéros de ports Cassandra, consultez la page Configurer des ports.

Configurer l'hôte source multirégional

Cette section décrit comment étendre le cluster Cassandra existant à une nouvelle région. Cette configuration permet à la nouvelle région d'amorcer le cluster et de rejoindre le centre de données existant. Sans cette configuration, les clusters Kubernetes multirégionaux ne se connaîtraient pas les uns les autres.

1. Dans le fichier overrides.yaml de votre cluster d'origine, assurez-vous que cassandra:hostNetwork est défini sur true. Exemple :

   cassandra:
     hostNetwork: true

   Pour en savoir plus sur la définition de hostNetwork: true, consultez la section Prérequis.

2. Si l'élément cassandra:hostNetwork n'est pas défini sur true, procédez comme suit :
   1. Remplacez cassandra.hostNetwork par true.
   2. Appliquez le fichier de configuration overrides.yaml à l'aide de la commande suivante :

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendez que les pods Cassandra aient effectué un redémarrage progressif.

   4. Vérifiez que le cluster Cassandra est opérationnel à l'aide des commandes suivantes :

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
        

      Assurez-vous que tous les nœuds Cassandra du résultat possèdent l'état Up and normal (UN) :

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
        

      Assurez-vous qu'aucun nœud inaccessible ne s'affiche dans le résultat.

      Conseil : APIGEE_JMX_USER et APIGEE_JMX_PASSWORD sont généralement définis dans les variables d'environnement $APIGEE_JMX_USER et $APIGEE_JMX_PASSWORD.
3. Définissez le contexte kubectl sur le cluster d'origine avant de récupérer le nom source :

   kubectl config use-context original-cluster-name

4. Exécutez la commande kubectl suivante pour identifier une adresse d'hôte source pour Cassandra dans la région actuelle.

   Une adresse hôte source permet à une nouvelle instance régionale de trouver le cluster d'origine lors du premier démarrage pour apprendre la topologie du cluster. L'adresse hôte source est désignée comme point de contact dans le cluster.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra --field-selector status.phase=Running

   apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000

5. Déterminez quelles adresses IP renvoyées par la commande précédente seront les hôtes sources multirégionaux. Dans cet exemple, où un cluster Cassandra à nœud unique est exécuté, l'hôte source est 120.38.1.9.
6. Dans le centre de données 2, copiez votre fichier de remplacement dans un nouveau fichier dont le nom inclut le nom du cluster. Exemple : overrides_your_cluster_name.yaml.
7. Dans le centre de données 2, configurez cassandra.multiRegionSeedHost et cassandra.datacenter dans overrides_your_cluster_name.yaml, où multiRegionSeedHost est l'une des adresses IP renvoyées par la commande précédente :

   cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name
     hostNetwork: true
     clusterName: cluster_name # must be the same for all regions

   Exemple :

   cassandra:
     multiRegionSeedHost: 120.38.1.9
     datacenter: "centralus"
     rack: "ra-1"
     hostNetwork: truev

8. Dans le nouveau centre de données ou la nouvelle région, définissez les mêmes certificats et identifiants TLS dans overrides_your_cluster_name.yaml que ceux définis dans la première région avant d'installer un environnement hybride.
   Remarque : Veillez à utiliser dans le deuxième centre de données les mêmes certificats et identifiants TLS Cassandra que ceux du centre de données d'origine. Les identifiants que vous avez définis dans le fichier de remplacement du premier centre de données doivent correspondre à ceux que vous avez spécifiés dans le fichier de remplacement du deuxième centre de données. Pour en savoir plus, consultez la section Configurer TLS pour Cassandra.

Configurer la nouvelle région

Après avoir configuré l'hôte source, vous pouvez configurer la nouvelle région.

Pour configurer la nouvelle région, procédez comme suit :

1. Copiez votre certificat à partir du cluster existant vers le nouveau cluster. Le nouveau certificat racine CA est utilisé par Cassandra et d'autres composants hybrides pour mTLS. Par conséquent, il est essentiel de disposer de certificats cohérents dans l'ensemble du cluster.
   1. Définissez le contexte sur l'espace de noms d'origine :

      kubectl config use-context original-cluster-name

   2. Exportez la configuration actuelle de l'espace de noms dans un fichier :

      kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   3. Exportez le secret apigee-ca vers un fichier :

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Définissez le contexte sur le nom du cluster de la nouvelle région :

      kubectl config use-context new-cluster-name

   5. Importez la configuration de l'espace de noms dans le nouveau cluster. Veillez à mettre à jour l'espace de noms dans le fichier si vous utilisez un espace de noms différent dans la nouvelle région :

      kubectl apply -f apigee-namespace.yaml

   6. Importez le secret dans le nouveau cluster :

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Installez la version hybride dans la nouvelle région. Assurez-vous que le fichier overrides_your_cluster_name.yaml inclut les mêmes certificats TLS que ceux configurés dans la première région, comme expliqué dans la section précédente.

   Exécutez les deux commandes suivantes pour installer un environnement hybride dans la nouvelle région :

   Important : Lorsque vous déployez Apigee hybrid dans un nouveau centre de données régional, veillez à installer la même version que dans votre centre de données existant. Évitez d'exécuter différentes versions d'Apigee hybrid dans plusieurs centres de données.

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

3. Vérifiez que l'installation hybride a réussi en exécutant la commande suivante :

   apigeectl check-ready -f overrides_your_cluster_name.yaml

4. Vérifiez la configuration du cluster Cassandra en exécutant la commande suivante. La sortie doit afficher les centres de données existants et nouveaux.
   Avertissement : Si le résultat de cette commande n'affiche pas les centres de données existants et nouveaux, la configuration a échoué. Dans ce cas, ne continuez pas.

   Pour résoudre le problème, l'installation hybride sur la nouvelle région doit être supprimée et recréée. Consultez la page Désinstaller l'environnement d'exécution hybride. Si la configuration échoue, n'essayez pas de continuer ni de joindre le cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Exemple illustrant une configuration réussie :

   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

5. Configurez Cassandra sur tous les pods des nouveaux centres de données.
   1. Obtenez apigeeorg à partir du cluster à l'aide de la commande suivante :

      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      

      Exemple :

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      "rg-hybrid-b7d3b9c"
      

   2. Créez un fichier de ressource personnalisée pour la réplication de données Cassandra (YAML). Le fichier peut porter n'importe quel nom. Dans les exemples suivants, le fichier sera nommé datareplication.yaml.

      Le fichier doit contenir les éléments suivants :

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Où :

      • REGION_EXPANSION est le nom que vous attribuez à ces métadonnées. Vous pouvez utiliser n'importe quel nom.
      • NAMESPACE est le même espace de noms que celui fourni dans overrides.yaml. Il s'agit généralement de "apigee".
      • APIGEEORG_VALUE correspond à la valeur renvoyée par la commande kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name à l'étape précédente. Par exemple, rg-hybrid-b7d3b9c.
      • SOURCE_REGION est la région source, la valeur pour le centre de données se trouve dans la section "cassandra" du fichier yaml de remplacement de la région source.

      Exemple :

      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. Appliquez la fonction CassandraDataReplication avec la commande suivante :

      kubectl apply -f datareplication.yaml

   4. Vérifiez l'état de la recompilation à l'aide de la commande suivante.
      Remarque : L'opération de recompilation peut prendre plusieurs heures suivant la taille des données.

      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Les résultats doivent ressembler à ceci :

      {
        "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
      }

6. Vérifiez les processus de recompilation des journaux. Vérifiez également la taille des données à l'aide de la commande nodetool status :
   Remarque : Si l'opération de recompilation indique l'état terminé et que les journaux des processus de recompilation contiennent "Toutes les sessions terminées", toutes les données ont bien été copiées dans la nouvelle région.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   L'exemple suivant montre des entrées de journal :

   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

7. Mettez à jour les hôtes sources. Supprimez multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml, puis recommencez la même opération.
   Remarque : Les hôtes sources sont des membres de clusters locaux. Pour démarrer une nouvelle région, un hôte source externe est requis. Une fois qu'une région démarre, vous devez faire revenir les hôtes sources à leurs clusters locaux dans overrides.yaml, puis appliquer à nouveau la configuration.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Vérifier l'état du cluster Cassandra

La commande suivante permet de voir si la configuration du cluster a réussi dans deux centres de données. La commande vérifie l'état de nodetool pour les deux régions.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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: us-west1
====================
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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

EKS

Important : Lorsque vous déployez Apigee hybrid dans un nouveau centre de données régional, veillez à installer la même version que dans votre centre de données existant. Évitez d'exécuter différentes versions d'Apigee hybrid dans plusieurs centres de données. Cette restriction ne s'applique pas lors de la mise à niveau de plusieurs centres de données vers une nouvelle version.

Avertissement : Si l'installation échoue pour une nouvelle région, ne poursuivez pas l'installation. Au lieu de cela, supprimez l'installation d'Apigee hybrid et recréez-la sur la région défaillante.

Créer un réseau virtuel dans chaque région

Suivez les recommandations AWS pour établir une communication interrégionale, comme décrit dans la page Qu'est-ce que l'appairage de VPC ? Le terme AWS décrivant l'utilisation de différentes régions est l'appairage de VPC inter-région.

Créer des clusters multirégionaux

Configurez des clusters Kubernetes dans plusieurs régions avec des blocs CIDR différents. Consultez également l'étape 1 : Créer un cluster. Utilisez les emplacements et les noms de réseaux virtuels que vous avez créés précédemment.

Ouvrez les ports Cassandra entre les clusters Kubernetes dans toutes les régions pour permettre aux nœuds de calcul des régions et des centres de données de communiquer. Pour en savoir plus sur les numéros de ports Cassandra, consultez la page Configurer des ports.

Configurer l'hôte source multirégional

Cette section décrit comment étendre le cluster Cassandra existant à une nouvelle région. Cette configuration permet à la nouvelle région d'amorcer le cluster et de rejoindre le centre de données existant. Sans cette configuration, les clusters Kubernetes multirégionaux ne se connaîtraient pas les uns les autres.

1. Dans le fichier overrides.yaml de votre cluster d'origine, assurez-vous que cassandra:hostNetwork est défini sur true. Exemple :

   cassandra:
     hostNetwork: true

   Pour en savoir plus sur la définition de hostNetwork: true, consultez la section Prérequis.

2. Si l'élément cassandra:hostNetwork n'est pas défini sur true, procédez comme suit :
   1. Remplacez cassandra.hostNetwork par true.
   2. Appliquez le fichier de configuration overrides.yaml à l'aide de la commande suivante :

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendez que les pods Cassandra aient effectué un redémarrage progressif.

   4. Vérifiez que le cluster Cassandra est opérationnel à l'aide des commandes suivantes :

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
        

      Assurez-vous que tous les nœuds Cassandra du résultat possèdent l'état Up and normal (UN) :

        nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD describecluster
        

      Assurez-vous qu'aucun nœud inaccessible ne s'affiche dans le résultat.

3. Définissez le contexte kubectl sur le cluster d'origine avant de récupérer le nom source :

   kubectl config use-context original-cluster-name

4. Exécutez la commande kubectl suivante pour identifier une adresse d'hôte source pour Cassandra dans la région actuelle.

   Une adresse hôte source permet à une nouvelle instance régionale de trouver le cluster d'origine lors du premier démarrage pour apprendre la topologie du cluster. L'adresse hôte source est désignée comme point de contact dans le 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

5. Déterminez quelles adresses IP renvoyées par la commande précédente seront les hôtes sources multirégionaux. Dans cet exemple, où un cluster Cassandra à nœud unique est exécuté, l'hôte source est 120.38.1.9.
6. Dans le centre de données 2, copiez votre fichier de remplacement dans un nouveau fichier dont le nom inclut le nom du cluster. Exemple : overrides_your_cluster_name.yaml.
7. Dans le centre de données 2, configurez cassandra.multiRegionSeedHost et cassandra.datacenter dans overrides_your_cluster_name.yaml, où multiRegionSeedHost est l'une des adresses IP renvoyées par la commande précédente :

   cassandra:
        multiRegionSeedHost: seed_host_IP
        datacenter: data_center_name
        rack: rack_name
        hostNetwork: true
        clusterName: cluster_name # must be the same for all regions

   Exemple :

   cassandra:
     multiRegionSeedHost: 120.38.1.9
     datacenter: "centralus"
     rack: "ra-1"
     hostNetwork: true
     clusterName: my-apigee-cluster

8. Dans le nouveau centre de données ou la nouvelle région, définissez les mêmes certificats et identifiants TLS dans overrides_your_cluster_name.yaml que ceux définis dans la première région avant d'installer un environnement hybride.
   Remarque : Veillez à utiliser dans le deuxième centre de données les mêmes certificats et identifiants TLS Cassandra que ceux du centre de données d'origine. Les identifiants que vous avez définis dans le fichier de remplacement du premier centre de données doivent correspondre à ceux que vous avez spécifiés dans le fichier de remplacement du deuxième centre de données. Pour en savoir plus, consultez la section Configurer TLS pour Cassandra.

Configurer la nouvelle région

Après avoir configuré l'hôte source, vous pouvez configurer la nouvelle région.

Pour configurer la nouvelle région, procédez comme suit :

1. Copiez votre certificat à partir du cluster existant vers le nouveau cluster. Le nouveau certificat racine CA est utilisé par Cassandra et d'autres composants hybrides pour mTLS. Par conséquent, il est essentiel de disposer de certificats cohérents dans l'ensemble du cluster.
   1. Définissez le contexte sur l'espace de noms d'origine :

      kubectl config use-context original-cluster-name

   2. Exportez la configuration actuelle de l'espace de noms dans un fichier :

      kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   3. Exportez le secret apigee-ca vers un fichier :

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Définissez le contexte sur le nom du cluster de la nouvelle région :

      kubectl config use-context new-cluster-name

   5. Importez la configuration de l'espace de noms dans le nouveau cluster. Veillez à mettre à jour l'espace de noms dans le fichier si vous utilisez un espace de noms différent dans la nouvelle région :

      kubectl apply -f apigee-namespace.yaml

   6. Importez le secret dans le nouveau cluster :

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Installez la version hybride dans la nouvelle région. Assurez-vous que le fichier overrides_your_cluster_name.yaml inclut les mêmes certificats TLS que ceux configurés dans la première région, comme expliqué dans la section précédente.

   Exécutez les deux commandes suivantes pour installer un environnement hybride dans la nouvelle région :

   Important : Lorsque vous déployez Apigee hybrid dans un nouveau centre de données régional, veillez à installer la même version que dans votre centre de données existant. Évitez d'exécuter différentes versions d'Apigee hybrid dans plusieurs centres de données.

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

3. Vérifiez que l'installation hybride a réussi en exécutant la commande suivante :

   apigeectl check-ready -f overrides_your_cluster_name.yaml

4. Vérifiez la configuration du cluster Cassandra en exécutant la commande suivante. La sortie doit afficher les centres de données existants et nouveaux.
   Avertissement : Si le résultat de cette commande n'affiche pas les centres de données existants et nouveaux, la configuration a échoué. Dans ce cas, ne continuez pas.

   Pour résoudre le problème, l'installation hybride sur la nouvelle région doit être supprimée et recréée. Consultez la page Désinstaller l'environnement d'exécution hybride. Si la configuration échoue, n'essayez pas de continuer ni de joindre le cluster.

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

   Exemple illustrant une configuration réussie :

   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

5. Configurez Cassandra sur tous les pods des nouveaux centres de données.
   1. Obtenez apigeeorg à partir du cluster à l'aide de la commande suivante :

      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      

      Exemple :

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      "rg-hybrid-b7d3b9c"
      

   2. Créez un fichier de ressource personnalisée pour la réplication de données Cassandra (YAML). Le fichier peut porter n'importe quel nom. Dans les exemples suivants, le fichier sera nommé datareplication.yaml.

      Le fichier doit contenir les éléments suivants :

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Où :

      • REGION_EXPANSION est le nom que vous attribuez à ces métadonnées. Vous pouvez utiliser n'importe quel nom.
      • NAMESPACE est le même espace de noms que celui fourni dans overrides.yaml. Il s'agit généralement de "apigee".
      • APIGEEORG_VALUE correspond à la valeur renvoyée par la commande kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name à l'étape précédente. Par exemple, rg-hybrid-b7d3b9c.
      • SOURCE_REGION est la région source, la valeur pour le centre de données se trouve dans la section "cassandra" du fichier yaml de remplacement de la région source.

      Exemple :

      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. Appliquez la fonction CassandraDataReplication avec la commande suivante :

      kubectl apply -f datareplication.yaml

   4. Vérifiez l'état de la recompilation à l'aide de la commande suivante.
      Remarque : L'opération de recompilation peut prendre plusieurs heures suivant la taille des données.

      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Les résultats doivent ressembler à ceci :

      {
        "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
      }

6. Vérifiez les processus de recompilation des journaux. Vérifiez également la taille des données à l'aide de la commande 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'exemple suivant montre des entrées de journal :

   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

7. Mettez à jour les hôtes sources. Supprimez multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml, puis recommencez la même opération.
   Remarque : Les hôtes sources sont des membres de clusters locaux. Pour démarrer une nouvelle région, un hôte source externe est requis. Une fois qu'une région démarre, vous devez faire revenir les hôtes sources à leurs clusters locaux dans overrides.yaml, puis appliquer à nouveau la configuration.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Vérifier l'état du cluster Cassandra

La commande suivante permet de voir si la configuration du cluster a réussi dans deux centres de données. La commande vérifie l'état de nodetool pour les deux régions.

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: us-west1
====================
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

Important : Lorsque vous déployez Apigee hybrid dans un nouveau centre de données régional, veillez à installer la même version que dans votre centre de données existant. Évitez d'exécuter différentes versions d'Apigee hybrid dans plusieurs centres de données.

Avertissement : Si l'installation échoue pour une nouvelle région, ne poursuivez pas l'installation. Au lieu de cela, supprimez l'installation d'Apigee hybrid et recréez-la sur la région défaillante.

Configurer l'hôte source multirégional

Cette section décrit comment étendre le cluster Cassandra existant à une nouvelle région. Cette configuration permet à la nouvelle région d'amorcer le cluster et de rejoindre le centre de données existant. Sans cette configuration, les clusters Kubernetes multirégionaux ne se connaîtraient pas les uns les autres.

1. Dans le fichier overrides.yaml de votre cluster d'origine, assurez-vous que cassandra:hostNetwork est défini sur true. Exemple :

   cassandra:
     hostNetwork: true

   Pour en savoir plus sur la définition de hostNetwork: true, consultez la section Prérequis.

2. Si l'élément cassandra:hostNetwork n'est pas défini sur true, procédez comme suit :
   1. Remplacez cassandra.hostNetwork par true.
   2. Appliquez le fichier de configuration overrides.yaml à l'aide de la commande suivante :

        apigeectl apply -f overrides.yaml --datastore
        

   3. Attendez que les pods Cassandra aient effectué un redémarrage progressif.

   4. Vérifiez que le cluster Cassandra est opérationnel à l'aide des commandes suivantes :

        kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
        

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
        

      Assurez-vous que tous les nœuds Cassandra du résultat possèdent l'état Up and normal (UN) :

        nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD describecluster
        

      Assurez-vous qu'aucun nœud inaccessible ne s'affiche dans le résultat.

      Conseil : APIGEE_JMX_USER et APIGEE_JMX_PASSWORD sont généralement définis dans les variables d'environnement $APIGEE_JMX_USER et $APIGEE_JMX_PASSWORD.
3. Définissez le contexte kubectl sur le cluster d'origine avant de récupérer le nom source :

   kubectl config use-context original-cluster-name

4. Exécutez la commande kubectl suivante pour identifier une adresse d'hôte source pour Cassandra dans la région actuelle.

   Une adresse hôte source permet à une nouvelle instance régionale de trouver le cluster d'origine lors du premier démarrage pour apprendre la topologie du cluster. L'adresse hôte source est désignée comme point de contact dans le cluster.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra --field-selector status.phase=Running

   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

5. Sélectionnez l'adresse IP de votre hôte Cassandra source à utiliser en tant qu'hôte source multirégional. Dans cet exemple, il s'agit du cluster apigee-cassandra-default-0 en cours d'exécution, et l'hôte source est 10.0.0.11.
6. Dans le centre de données 2, copiez votre fichier de remplacement dans un nouveau fichier dont le nom inclut le nom du cluster. Exemple : overrides_your_cluster_name.yaml.
7. Dans le centre de données 2, configurez cassandra.multiRegionSeedHost et cassandra.datacenter dans overrides_your_cluster_name.yaml, où multiRegionSeedHost est l'une des adresses IP renvoyées par la commande précédente :

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP # Cassandra pod IP address from the source region.
     datacenter: data_center_name
     rack: rack_name
     clusterName: cluster_name # must be the same for all regions

   Exemple :

   cassandra:
     hostNetwork: true
     multiRegionSeedHost: 10.0.0.11
     datacenter: "dc-2"
     rack: "ra-1"
     clusterName: my-apigee-cluster

8. Dans le nouveau centre de données ou la nouvelle région, définissez les mêmes certificats et identifiants TLS dans overrides_your_cluster_name.yaml que ceux définis dans la première région avant d'installer un environnement hybride.
   Remarque : Veillez à utiliser dans le deuxième centre de données les mêmes certificats et identifiants TLS Cassandra que ceux du centre de données d'origine. Les identifiants que vous avez définis dans le fichier de remplacement du premier centre de données doivent correspondre à ceux que vous avez spécifiés dans le fichier de remplacement du deuxième centre de données. Pour en savoir plus, consultez la section Configurer TLS pour Cassandra.

Configurer la nouvelle région

Après avoir configuré l'hôte source, vous pouvez configurer la nouvelle région.

Pour configurer la nouvelle région, procédez comme suit :

1. Copiez votre certificat à partir du cluster existant vers le nouveau cluster. Le nouveau certificat racine CA est utilisé par Cassandra et d'autres composants hybrides pour mTLS. Par conséquent, il est essentiel de disposer de certificats cohérents dans l'ensemble du cluster.
   1. Définissez le contexte sur l'espace de noms d'origine :

      kubectl config use-context original-cluster-name

   2. Exportez la configuration actuelle de l'espace de noms dans un fichier :

      kubectl get namespace namespace -o yaml > apigee-namespace.yaml

   3. Exportez le secret apigee-ca vers un fichier :

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Définissez le contexte sur le nom du cluster de la nouvelle région :

      kubectl config use-context new-cluster-name

   5. Importez la configuration de l'espace de noms dans le nouveau cluster. Veillez à mettre à jour l'espace de noms dans le fichier si vous utilisez un espace de noms différent dans la nouvelle région :

      kubectl apply -f apigee-namespace.yaml

   6. Importez le secret dans le nouveau cluster :

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Installez la version hybride dans la nouvelle région. Assurez-vous que le fichier overrides_your_cluster_name.yaml inclut les mêmes certificats TLS que ceux configurés dans la première région, comme expliqué dans la section précédente.

   Exécutez les deux commandes suivantes pour installer un environnement hybride dans la nouvelle région :

   Important : Lorsque vous déployez Apigee hybrid dans un nouveau centre de données régional, veillez à installer la même version que dans votre centre de données existant. Évitez d'exécuter différentes versions d'Apigee hybrid dans plusieurs centres de données.

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

3. Vérifiez que l'installation hybride a réussi en exécutant la commande suivante :

   apigeectl check-ready -f overrides_your_cluster_name.yaml

4. Vérifiez la configuration du cluster Cassandra en exécutant la commande suivante. La sortie doit afficher les centres de données existants et nouveaux.
   Avertissement : Si le résultat de cette commande n'affiche pas les centres de données existants et nouveaux, la configuration a échoué. Dans ce cas, ne continuez pas.

   Pour résoudre le problème, l'installation hybride sur la nouvelle région doit être supprimée et recréée. Consultez la page Désinstaller l'environnement d'exécution hybride. Si la configuration échoue, n'essayez pas de continuer ni de joindre le cluster.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
     -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Exemple illustrant une configuration réussie :

   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

5. Configurez Cassandra sur tous les pods des nouveaux centres de données.
   1. Obtenez apigeeorg à partir du cluster à l'aide de la commande suivante :

      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      

      Exemple :

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      "rg-hybrid-b7d3b9c"
      

   2. Créez un fichier de ressource personnalisée pour la réplication de données Cassandra (YAML). Le fichier peut porter n'importe quel nom. Dans les exemples suivants, le fichier sera nommé datareplication.yaml.

      Le fichier doit contenir les éléments suivants :

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Où :

      • REGION_EXPANSION est le nom que vous attribuez à ces métadonnées. Vous pouvez utiliser n'importe quel nom.
      • NAMESPACE est le même espace de noms que celui fourni dans overrides.yaml. Il s'agit généralement de "apigee".
      • APIGEEORG_VALUE correspond à la valeur renvoyée par la commande kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name à l'étape précédente. Par exemple, rg-hybrid-b7d3b9c.
      • SOURCE_REGION est la région source, la valeur pour le centre de données se trouve dans la section "cassandra" du fichier yaml de remplacement de la région source.

      Exemple :

      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. Appliquez la fonction CassandraDataReplication avec la commande suivante :

      kubectl apply -f datareplication.yaml

   4. Vérifiez l'état de la recompilation à l'aide de la commande suivante.
      Remarque : L'opération de recompilation peut prendre plusieurs heures suivant la taille des données.

      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Les résultats doivent ressembler à ceci :

      {
        "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
      }

6. Vérifiez les processus de recompilation des journaux. Vérifiez également la taille des données à l'aide de la commande nodetool status :
   Remarque : Si l'opération de recompilation indique l'état terminé et que les journaux des processus de recompilation contiennent "Toutes les sessions terminées", toutes les données ont bien été copiées dans la nouvelle région.

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   L'exemple suivant montre des entrées de journal :

   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

7. Mettez à jour les hôtes sources. Supprimez multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml, puis recommencez la même opération.
   Remarque : Les hôtes sources sont des membres de clusters locaux. Pour démarrer une nouvelle région, un hôte source externe est requis. Une fois qu'une région démarre, vous devez faire revenir les hôtes sources à leurs clusters locaux dans overrides.yaml, puis appliquer à nouveau la configuration.

   apigeectl apply -f overrides/overrides-DC_name.yaml

Vérifier l'état du cluster Cassandra

La commande suivante permet de voir si la configuration du cluster a réussi dans deux centres de données. La commande vérifie l'état de nodetool pour les deux régions.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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: us-west1
====================
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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

Dépannage

Consultez la section Échec de la réplication de données Cassandra.