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 :
- 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 les comptes de service, nous vous recommandons vivement d'utiliser Workload Identity pour chaque cluster vers lequel vous étendez le déploiement. Consultez la section Activer Workload Identity sur GKE ou Activer la fédération d'identité de charge de travail sur AKS et EKS.
- 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.
- 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éfinissantcassandra.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. - 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.
- 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.
- 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éfinissantcassandra.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. - 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.
- 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
Pour en savoir plus, consultez la documentation concernant Kubernetes.
- 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.
- 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éfinissantcassandra.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. - 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.
- 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
Pour en savoir plus, consultez la documentation concernant Kubernetes.
- 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.
- 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éfinissantcassandra.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. - 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.
- 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
Pour en savoir plus, consultez la documentation concernant Kubernetes.
- 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.
- 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éfinissantcassandra.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. - 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.
- 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é
Pour en savoir plus, consultez la documentation concernant Kubernetes.
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.
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.
-
Pour la première région créée, récupérez les pods dans l'espace de noms Apigee :
kubectl get pods -o wide -n
APIGEE_NAMESPACE - Identifiez l'adresse hôte source multirégionale de Cassandra dans cette région, par exemple
10.0.0.11
. -
Préparez le fichier
overrides.yaml
pour la deuxième région et ajoutez l'adresse IP de l'hôte source comme suit :cassandra: multiRegionSeedHost: "
SEED_HOST_IP_ADDRESS " datacenter: "DATACENTER_NAME " rack: "RACK_NAME " hostNetwork: false clusterName:CLUSTER_NAME Remplacez les éléments suivants :
- SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple
10.0.0.11
. - DATACENTER_NAME par le nom du centre de données, par exemple
dc-2
. - RACK_NAME par le nom du rack, par exemple
ra-1
. - CLUSTER_NAME par le nom de votre cluster Cassandra. La valeur par défaut est
apigeecluster
. Si vous utilisez un autre nom de cluster, vous devez spécifier une valeur pour cassandra.clusterName. Vous êtes libre de choisir vous-même la valeur, mais elle doit être identique dans toutes les régions.
- SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple
Configurer la deuxième région
Pour configurer la nouvelle région, procédez comme suit :
-
Installez cert-manager dans la deuxième région.
- 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.
-
Définissez le contexte sur l'espace de noms d'origine :
kubectl config use-context
ORIGINAL_CLUSTER_NAME -
Exportez la configuration actuelle de l'espace de noms dans un fichier :
kubectl get namespace
APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml -
Exportez le secret
apigee-ca
vers un fichier :kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
-
Définissez le contexte sur le nom du cluster de la nouvelle région :
kubectl config use-context
NEW_CLUSTER_NAME -
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 autre espace de noms dans la nouvelle région :
kubectl apply -f apigee-namespace.yaml
-
Importez le secret dans le nouveau cluster :
kubectl -n cert-manager apply -f apigee-ca.yaml
-
-
Suivez les étapes pour Installer les CRD Apigee hybrid dans la nouvelle région.
-
Utilisez les charts Helm pour installer Apigee hybrid dans la nouvelle région à l'aide des commandes des charts Helm suivantes (comme illustré dans la région 1) :
helm upgrade operator apigee-operator \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade datastore apigee-datastore \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade telemetry apigee-telemetry \ --install \ --namespace
APIGEE_NAMESPACE > \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade redis apigee-redis \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade ingress-manager apigee-ingress-manager \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade
# repeat the below command for each env mentioned on the overridesORG_NAME apigee-org \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade
# repeat the below command for each env group mentioned on the overridesENV_NAME apigee-env/ \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ --set env=ENV_NAME \ -f overrides-DATACENTER_NAME .yamlhelm upgrade apigee-virtualhost-
ENV_GROUP_NAME apigee-virtualhost/ \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ --set envgroup=ENV_GROUP_NAME \ -f overrides-DATACENTER_NAME .yaml - 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.
kubectl exec apigee-cassandra-default-0 -n
APIGEE_NAMESPACE \ -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_JMX_PASSWORD statusExemple 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
- Configurez Cassandra sur tous les pods des nouveaux centres de données.
- Obtenez
apigeeorg
à partir du cluster à l'aide de la commande suivante :kubectl get apigeeorg -n
APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"Exemple :
Ex: kubectl get apigeeorg -n
APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" "rg-hybrid-b7d3b9c" - 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_NAMESPACE -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"
- Appliquez la fonction
CassandraDataReplication
avec la commande suivante :kubectl apply -f datareplication.yaml
- Obtenez
- Vérifiez l'état de la recompilation à l'aide de la commande suivante.
kubectl -n
APIGEE_NAMESPACE 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 }
- Une fois la réplication de données terminée et validée, mettez à jour les hôtes sources :
-
Supprimez
multiRegionSeedHost: 10.0.0.11
deoverrides-DATACENTER_NAME.yaml
. -
Appliquez à nouveau la modification pour mettre à jour le RS de datastore apigee :
helm upgrade datastore apigee-datastore/ \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yaml
-
Supprimez
- 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_NAMESPACE kubectl exec apigee-cassandra-default-0 -n
APIGEE_NAMESPACE -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_JMX_PASSWORD statusL'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
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 -nAPIGEE_NAMESPACE -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_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
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.
-
Pour la première région créée, récupérez les pods dans l'espace de noms Apigee :
kubectl get pods -o wide -n
APIGEE_NAMESPACE - Identifiez l'adresse hôte source multirégionale de Cassandra dans cette région, par exemple
10.0.0.11
. -
Préparez le fichier
overrides.yaml
pour la deuxième région et ajoutez l'adresse IP de l'hôte source comme suit :cassandra: multiRegionSeedHost: "
SEED_HOST_IP_ADDRESS " datacenter: "DATACENTER_NAME " rack: "RACK_NAME " hostNetwork: false clusterName:CLUSTER_NAME Remplacez les éléments suivants :
- SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple
10.0.0.11
. - DATACENTER_NAME par le nom du centre de données, par exemple
dc-2
. - RACK_NAME par le nom du rack, par exemple
ra-1
. - CLUSTER_NAME par le nom de votre cluster Cassandra. La valeur par défaut est
apigeecluster
. Si vous utilisez un autre nom de cluster, vous devez spécifier une valeur pour cassandra.clusterName. Vous êtes libre de choisir vous-même la valeur, mais elle doit être identique dans toutes les régions.
- SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple
Configurer la deuxième région
Pour configurer la nouvelle région, procédez comme suit :
-
Installez cert-manager dans la deuxième région.
- 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.
-
Définissez le contexte sur l'espace de noms d'origine :
kubectl config use-context
ORIGINAL_CLUSTER_NAME -
Exportez la configuration actuelle de l'espace de noms dans un fichier :
kubectl get namespace
APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml -
Exportez le secret
apigee-ca
vers un fichier :kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
-
Définissez le contexte sur le nom du cluster de la nouvelle région :
kubectl config use-context
NEW_CLUSTER_NAME -
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 autre espace de noms dans la nouvelle région :
kubectl apply -f apigee-namespace.yaml
-
Importez le secret dans le nouveau cluster :
kubectl -n cert-manager apply -f apigee-ca.yaml
-
-
Suivez les étapes pour Installer les CRD Apigee hybrid dans la nouvelle région.
-
Utilisez les charts Helm pour installer Apigee hybrid dans la nouvelle région à l'aide des commandes des charts Helm suivantes (comme illustré dans la région 1) :
helm upgrade operator apigee-operator \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade datastore apigee-datastore \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade telemetry apigee-telemetry \ --install \ --namespace
APIGEE_NAMESPACE > \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade redis apigee-redis \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade ingress-manager apigee-ingress-manager \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade
# repeat the below command for each env mentioned on the overridesORG_NAME apigee-org \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade
# repeat the below command for each env group mentioned on the overridesENV_NAME apigee-env/ \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ --set env=ENV_NAME \ -f overrides-DATACENTER_NAME .yamlhelm upgrade apigee-virtualhost-
ENV_GROUP_NAME apigee-virtualhost/ \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ --set envgroup=ENV_GROUP_NAME \ -f overrides-DATACENTER_NAME .yaml - 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.
kubectl exec apigee-cassandra-default-0 -n
APIGEE_NAMESPACE \ -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_JMX_PASSWORD statusExemple 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
- Configurez Cassandra sur tous les pods des nouveaux centres de données.
- Obtenez
apigeeorg
à partir du cluster à l'aide de la commande suivante :kubectl get apigeeorg -n
APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"Exemple :
Ex: kubectl get apigeeorg -n
APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" "rg-hybrid-b7d3b9c" - 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_NAMESPACE -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"
- Appliquez la fonction
CassandraDataReplication
avec la commande suivante :kubectl apply -f datareplication.yaml
- Obtenez
- Vérifiez l'état de la recompilation à l'aide de la commande suivante.
kubectl -n
APIGEE_NAMESPACE 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 }
- Une fois la réplication de données terminée et validée, mettez à jour les hôtes sources :
-
Supprimez
multiRegionSeedHost: 10.0.0.11
deoverrides-DATACENTER_NAME.yaml
. -
Appliquez à nouveau la modification pour mettre à jour le RS de datastore apigee :
helm upgrade datastore apigee-datastore/ \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yaml
-
Supprimez
- 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_NAMESPACE kubectl exec apigee-cassandra-default-0 -n
APIGEE_NAMESPACE -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_JMX_PASSWORD statusL'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
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 -nAPIGEE_NAMESPACE -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_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
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.
-
Pour la première région créée, récupérez les pods dans l'espace de noms Apigee :
kubectl get pods -o wide -n
APIGEE_NAMESPACE - Identifiez l'adresse hôte source multirégionale de Cassandra dans cette région, par exemple
10.0.0.11
. -
Préparez le fichier
overrides.yaml
pour la deuxième région et ajoutez l'adresse IP de l'hôte source comme suit :cassandra: multiRegionSeedHost: "
SEED_HOST_IP_ADDRESS " datacenter: "DATACENTER_NAME " rack: "RACK_NAME " hostNetwork: false clusterName:CLUSTER_NAME Remplacez les éléments suivants :
- SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple
10.0.0.11
. - DATACENTER_NAME par le nom du centre de données, par exemple
dc-2
. - RACK_NAME par le nom du rack, par exemple
ra-1
. - CLUSTER_NAME par le nom de votre cluster Cassandra. La valeur par défaut est
apigeecluster
. Si vous utilisez un autre nom de cluster, vous devez spécifier une valeur pour cassandra.clusterName. Vous êtes libre de choisir vous-même la valeur, mais elle doit être identique dans toutes les régions.
- SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple
Configurer la deuxième région
Pour configurer la nouvelle région, procédez comme suit :
-
Installez cert-manager dans la deuxième région.
- 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.
-
Définissez le contexte sur l'espace de noms d'origine :
kubectl config use-context
ORIGINAL_CLUSTER_NAME -
Exportez la configuration actuelle de l'espace de noms dans un fichier :
kubectl get namespace
APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml -
Exportez le secret
apigee-ca
vers un fichier :kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
-
Définissez le contexte sur le nom du cluster de la nouvelle région :
kubectl config use-context
NEW_CLUSTER_NAME -
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 autre espace de noms dans la nouvelle région :
kubectl apply -f apigee-namespace.yaml
-
Importez le secret dans le nouveau cluster :
kubectl -n cert-manager apply -f apigee-ca.yaml
-
-
Suivez les étapes pour Installer les CRD Apigee hybrid dans la nouvelle région.
-
Utilisez les charts Helm pour installer Apigee hybrid dans la nouvelle région à l'aide des commandes des charts Helm suivantes (comme illustré dans la région 1) :
helm upgrade operator apigee-operator \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade datastore apigee-datastore \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade telemetry apigee-telemetry \ --install \ --namespace
APIGEE_NAMESPACE > \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade redis apigee-redis \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade ingress-manager apigee-ingress-manager \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade
# repeat the below command for each env mentioned on the overridesORG_NAME apigee-org \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade
# repeat the below command for each env group mentioned on the overridesENV_NAME apigee-env/ \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ --set env=ENV_NAME \ -f overrides-DATACENTER_NAME .yamlhelm upgrade apigee-virtualhost-
ENV_GROUP_NAME apigee-virtualhost/ \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ --set envgroup=ENV_GROUP_NAME \ -f overrides-DATACENTER_NAME .yaml - 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.
kubectl exec apigee-cassandra-default-0 -n
APIGEE_NAMESPACE \ -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_JMX_PASSWORD statusExemple 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
- Configurez Cassandra sur tous les pods des nouveaux centres de données.
- Obtenez
apigeeorg
à partir du cluster à l'aide de la commande suivante :kubectl get apigeeorg -n
APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"Exemple :
Ex: kubectl get apigeeorg -n
APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" "rg-hybrid-b7d3b9c" - 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_NAMESPACE -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"
- Appliquez la fonction
CassandraDataReplication
avec la commande suivante :kubectl apply -f datareplication.yaml
- Obtenez
- Vérifiez l'état de la recompilation à l'aide de la commande suivante.
kubectl -n
APIGEE_NAMESPACE 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 }
- Une fois la réplication de données terminée et validée, mettez à jour les hôtes sources :
-
Supprimez
multiRegionSeedHost: 10.0.0.11
deoverrides-DATACENTER_NAME.yaml
. -
Appliquez à nouveau la modification pour mettre à jour le RS de datastore apigee :
helm upgrade datastore apigee-datastore/ \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yaml
-
Supprimez
- 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_NAMESPACE kubectl exec apigee-cassandra-default-0 -n
APIGEE_NAMESPACE -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_JMX_PASSWORD statusL'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
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 -nAPIGEE_NAMESPACE -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_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
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.
-
Pour la première région créée, récupérez les pods dans l'espace de noms Apigee :
kubectl get pods -o wide -n
APIGEE_NAMESPACE - Identifiez l'adresse hôte source multirégionale de Cassandra dans cette région, par exemple
10.0.0.11
. -
Préparez le fichier
overrides.yaml
pour la deuxième région et ajoutez l'adresse IP de l'hôte source comme suit :cassandra: multiRegionSeedHost: "
SEED_HOST_IP_ADDRESS " datacenter: "DATACENTER_NAME " rack: "RACK_NAME " hostNetwork: false clusterName:CLUSTER_NAME Remplacez les éléments suivants :
- SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple
10.0.0.11
. - DATACENTER_NAME par le nom du centre de données, par exemple
dc-2
. - RACK_NAME par le nom du rack, par exemple
ra-1
. - CLUSTER_NAME par le nom de votre cluster Cassandra. La valeur par défaut est
apigeecluster
. Si vous utilisez un autre nom de cluster, vous devez spécifier une valeur pour cassandra.clusterName. Vous êtes libre de choisir vous-même la valeur, mais elle doit être identique dans toutes les régions.
- SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple
Configurer la deuxième région
Pour configurer la nouvelle région, procédez comme suit :
-
Installez cert-manager dans la deuxième région.
- 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.
-
Définissez le contexte sur l'espace de noms d'origine :
kubectl config use-context
ORIGINAL_CLUSTER_NAME -
Exportez la configuration actuelle de l'espace de noms dans un fichier :
kubectl get namespace
APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml -
Exportez le secret
apigee-ca
vers un fichier :kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
-
Définissez le contexte sur le nom du cluster de la nouvelle région :
kubectl config use-context
NEW_CLUSTER_NAME -
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 autre espace de noms dans la nouvelle région :
kubectl apply -f apigee-namespace.yaml
-
Importez le secret dans le nouveau cluster :
kubectl -n cert-manager apply -f apigee-ca.yaml
-
-
Suivez les étapes pour Installer les CRD Apigee hybrid dans la nouvelle région.
-
Utilisez les charts Helm pour installer Apigee hybrid dans la nouvelle région à l'aide des commandes des charts Helm suivantes (comme illustré dans la région 1) :
helm upgrade operator apigee-operator \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade datastore apigee-datastore \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade telemetry apigee-telemetry \ --install \ --namespace
APIGEE_NAMESPACE > \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade redis apigee-redis \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade ingress-manager apigee-ingress-manager \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade
# repeat the below command for each env mentioned on the overridesORG_NAME apigee-org \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade
# repeat the below command for each env group mentioned on the overridesENV_NAME apigee-env/ \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ --set env=ENV_NAME \ -f overrides-DATACENTER_NAME .yamlhelm upgrade apigee-virtualhost-
ENV_GROUP_NAME apigee-virtualhost/ \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ --set envgroup=ENV_GROUP_NAME \ -f overrides-DATACENTER_NAME .yaml - 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.
kubectl exec apigee-cassandra-default-0 -n
APIGEE_NAMESPACE \ -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_JMX_PASSWORD statusExemple 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
- Configurez Cassandra sur tous les pods des nouveaux centres de données.
- Obtenez
apigeeorg
à partir du cluster à l'aide de la commande suivante :kubectl get apigeeorg -n
APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"Exemple :
Ex: kubectl get apigeeorg -n
APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" "rg-hybrid-b7d3b9c" - 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_NAMESPACE -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"
- Appliquez la fonction
CassandraDataReplication
avec la commande suivante :kubectl apply -f datareplication.yaml
- Obtenez
- Vérifiez l'état de la recompilation à l'aide de la commande suivante.
kubectl -n
APIGEE_NAMESPACE 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 }
- Une fois la réplication de données terminée et validée, mettez à jour les hôtes sources :
-
Supprimez
multiRegionSeedHost: 10.0.0.11
deoverrides-DATACENTER_NAME.yaml
. -
Appliquez à nouveau la modification pour mettre à jour le RS de datastore apigee :
helm upgrade datastore apigee-datastore/ \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yaml
-
Supprimez
- 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_NAMESPACE kubectl exec apigee-cassandra-default-0 -n
APIGEE_NAMESPACE -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_JMX_PASSWORD statusL'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
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 -nAPIGEE_NAMESPACE -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_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
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.
-
Pour la première région créée, récupérez les pods dans l'espace de noms Apigee :
kubectl get pods -o wide -n
APIGEE_NAMESPACE - Identifiez l'adresse hôte source multirégionale de Cassandra dans cette région, par exemple
10.0.0.11
. -
Préparez le fichier
overrides.yaml
pour la deuxième région et ajoutez l'adresse IP de l'hôte source comme suit :cassandra: multiRegionSeedHost: "
SEED_HOST_IP_ADDRESS " datacenter: "DATACENTER_NAME " rack: "RACK_NAME " hostNetwork: false clusterName:CLUSTER_NAME Remplacez les éléments suivants :
- SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple
10.0.0.11
. - DATACENTER_NAME par le nom du centre de données, par exemple
dc-2
. - RACK_NAME par le nom du rack, par exemple
ra-1
. - CLUSTER_NAME par le nom de votre cluster Cassandra. La valeur par défaut est
apigeecluster
. Si vous utilisez un autre nom de cluster, vous devez spécifier une valeur pour cassandra.clusterName. Vous êtes libre de choisir vous-même la valeur, mais elle doit être identique dans toutes les régions.
- SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple
Configurer la deuxième région
Pour configurer la nouvelle région, procédez comme suit :
-
Installez cert-manager dans la deuxième région.
- 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.
-
Définissez le contexte sur l'espace de noms d'origine :
kubectl config use-context
ORIGINAL_CLUSTER_NAME -
Exportez la configuration actuelle de l'espace de noms dans un fichier :
kubectl get namespace
APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml -
Exportez le secret
apigee-ca
vers un fichier :kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
-
Définissez le contexte sur le nom du cluster de la nouvelle région :
kubectl config use-context
NEW_CLUSTER_NAME -
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 autre espace de noms dans la nouvelle région :
kubectl apply -f apigee-namespace.yaml
-
Importez le secret dans le nouveau cluster :
kubectl -n cert-manager apply -f apigee-ca.yaml
-
-
Suivez les étapes pour Installer les CRD Apigee hybrid dans la nouvelle région.
-
Utilisez les charts Helm pour installer Apigee hybrid dans la nouvelle région à l'aide des commandes des charts Helm suivantes (comme illustré dans la région 1) :
helm upgrade operator apigee-operator \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade datastore apigee-datastore \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade telemetry apigee-telemetry \ --install \ --namespace
APIGEE_NAMESPACE > \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade redis apigee-redis \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade ingress-manager apigee-ingress-manager \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade
# repeat the below command for each env mentioned on the overridesORG_NAME apigee-org \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yamlhelm upgrade
# repeat the below command for each env group mentioned on the overridesENV_NAME apigee-env/ \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ --set env=ENV_NAME \ -f overrides-DATACENTER_NAME .yamlhelm upgrade apigee-virtualhost-
ENV_GROUP_NAME apigee-virtualhost/ \ --install \ --namespaceAPIGEE_NAMESPACE \ --atomic \ --set envgroup=ENV_GROUP_NAME \ -f overrides-DATACENTER_NAME .yaml - 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.
kubectl exec apigee-cassandra-default-0 -n
APIGEE_NAMESPACE \ -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_JMX_PASSWORD statusExemple 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
- Configurez Cassandra sur tous les pods des nouveaux centres de données.
- Obtenez
apigeeorg
à partir du cluster à l'aide de la commande suivante :kubectl get apigeeorg -n
APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"Exemple :
Ex: kubectl get apigeeorg -n
APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" "rg-hybrid-b7d3b9c" - 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_NAMESPACE -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"
- Appliquez la fonction
CassandraDataReplication
avec la commande suivante :kubectl apply -f datareplication.yaml
- Obtenez
- Vérifiez l'état de la recompilation à l'aide de la commande suivante.
kubectl -n
APIGEE_NAMESPACE 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 }
- Une fois la réplication de données terminée et validée, mettez à jour les hôtes sources :
-
Supprimez
multiRegionSeedHost: 10.0.0.11
deoverrides-DATACENTER_NAME.yaml
. -
Appliquez à nouveau la modification pour mettre à jour le RS de datastore apigee :
helm upgrade datastore apigee-datastore/ \ --install \ --namespace
APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME .yaml
-
Supprimez
- 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_NAMESPACE kubectl exec apigee-cassandra-default-0 -n
APIGEE_NAMESPACE -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_JMX_PASSWORD statusL'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
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 -nAPIGEE_NAMESPACE -- nodetool -uAPIGEE_JMX_USER -pwAPIGEE_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.