Effectuer un rollback d'Apigee Edge 4.53.01

Si vous rencontrez une erreur lors d'une mise à jour vers Edge 4.53.01, vous pouvez rétablir le composant à l'origine de l'erreur, puis réessayer la mise à jour.

Vous pouvez revenir à l'une des versions majeures suivantes d'Edge 4.53.01 :

  • Version 4.53.00
  • Version 4.52.02

Pour revenir à une version antérieure, vous devez revenir à la version précédente de chaque composant que vous avez peut-être mis à niveau. De plus, selon la version à partir de laquelle vous avez commencé, vous devrez peut-être suivre des étapes spécifiques avant de revenir à une version antérieure de certains composants logiciels. Le tableau suivant liste les différents composants logiciels pour lesquels des étapes spécifiques peuvent être nécessaires lors de la restauration :

Revenir à une version Considérations particulières pour les logiciels
4.53.00 Zookeeper, Postgres, LDAP
4.52.02 Zookeeper, Cassandra, Postgres, LDAP

Voici un scénario dans lequel vous pouvez souhaiter effectuer une restauration :

Effectuez un rollback vers une version majeure ou mineure précédente. Par exemple, de la version 4.53.01 à la version 4.53.00.

Pour en savoir plus, consultez la page Processus de publication d'Apigee Edge.

Ordre de rollback

La restauration des composants doit être effectuée dans l'ordre inverse de leur mise à niveau, à l'exception des serveurs de gestion, qui doivent être restaurés après Cassandra. Voici un exemple d'ordre général de rétablissement pour Private Cloud 4.53.01 :

  1. Restaurez Qpid, les autres composants liés aux données analytiques et Postgres.
  2. Restaurer des routeurs et des processeurs de messages
  3. Rétablir Cassandra et Zookeeper
  4. Effectuer un rollback du serveur de gestion
  5. Rétablir LDAP

Par exemple, supposons que vous ayez mis à niveau l'ensemble du cluster Cassandra, tous vos serveurs de gestion et quelques RMP vers la version 4.53.01 à partir de la version 4.52.02 et que vous souhaitiez effectuer un rollback. Dans ce cas, vous devez :

  • Annuler tous les RMP un par un
  • Rétablir l'ensemble du cluster Cassandra à l'aide de sauvegardes
  • Rétablir les nœuds du serveur Edge Management un par un

Qui peut effectuer une restauration ?

L'utilisateur qui effectue le rollback doit être le même que celui qui a initialement mis à jour Edge ou un utilisateur exécuté en tant que root.

Par défaut, les composants Edge s'exécutent en tant qu'utilisateur "apigee". Dans certains cas, vous pouvez exécuter des composants Edge en tant qu'utilisateurs différents. Par exemple, si le routeur doit accéder à des ports privilégiés, tels que ceux inférieurs à 1000, vous devez l'exécuter en tant que root ou en tant qu'utilisateur ayant accès à ces ports. Vous pouvez également exécuter un composant en tant qu'utilisateur et un autre composant en tant qu'autre utilisateur.

Composants avec code commun

Les composants Edge suivants partagent un code commun. Par conséquent, pour effectuer un rollback de l'un de ces composants sur un nœud, vous devez effectuer un rollback de tous les composants présents sur ce nœud.

  • edge-management-server (serveur de gestion)
  • edge-message-processor (processeur de messages)
  • edge-router (routeur)
  • edge-postgres-server (serveur Postgres)
  • edge-qpid-server (serveur Qpid)

Par exemple, si le serveur de gestion, le routeur et le processeur de messages sont installés sur le nœud, vous devez effectuer un rollback des trois pour en annuler un.

Restauration de Cassandra

Lorsqu'une mise à niveau majeure de Cassandra est effectuée sur un nœud spécifique, Cassandra modifie le schéma des données stockées sur ce nœud. Par conséquent, une restauration directe sur place n'est pas possible.

Scénarios de rollback

Cassandra 4.0.X, disponible avec Edge pour le cloud privé 4.53.01, est compatible avec les autres composants du cloud privé 4.52.02.

Veuillez consulter le tableau ci-dessous pour obtenir un récapitulatif des différentes stratégies de restauration que vous pouvez utiliser :

Scénario Stratégie de rollback
Un seul centre de données, certains nœuds Cassandra mis à niveau Utiliser les sauvegardes
DC unique, tous les nœuds Cassandra mis à niveau N'effectuez pas de rollback de Cassandra. Il est possible d'effectuer un rollback d'autres composants.
Centre de données unique, tous les nœuds (Cassandra et autres) mis à niveau N'effectuez pas de rollback de Cassandra. Il est possible d'effectuer un rollback d'autres composants.
Plusieurs centres de données, certains nœuds d'un centre de données mis à niveau Recompiler à partir d'un fichier DC existant
Plusieurs centres de données, tous les nœuds Cassandra de certains centres de données ont été mis à niveau Recompiler à partir d'un fichier DC existant
Plusieurs centres de données, nœuds Cassandra du dernier centre de données en cours de mise à niveau Essayez de terminer la mise à niveau. Si ce n'est pas possible, rétrogradez un contrôleur de domaine à l'aide d'une sauvegarde. Recompilez les autres DC à partir du DC rétabli.
Plusieurs centres de données, tous les nœuds Cassandra mis à niveau N'effectuez pas de rollback de Cassandra. Il est possible d'effectuer un rollback d'autres composants.
Plusieurs centres de données, tous les nœuds (Cassandra et autres) mis à niveau N'effectuez pas de rollback de Cassandra. Il est possible d'effectuer un rollback d'autres composants.

Éléments généraux à prendre en compte

Lorsque vous envisagez d'effectuer un rollback, tenez compte des points suivants :

  • Rollback des composants d'exécution ou de gestion : si vous souhaitez effectuer un rollback de composants tels que edge-management-server, edge-message-processor ou tout composant non Cassandra vers la version 4.52.02 de Private Cloud, il est recommandé de NE PAS effectuer de rollback de Cassandra. La version de Cassandra fournie avec Private Cloud 4.53.00 est compatible avec tous les composants non Cassandra d'Edge pour le cloud privé 4.52.02. Vous pouvez effectuer un rollback des composants non Cassandra à l'aide de la méthodologie listée ici, tandis que Cassandra reste sur la version 4.0.13.
  • Effectuer un rollback après la mise à niveau de l'ensemble du cluster Cassandra vers la version 4.0.X : si l'ensemble de votre cluster Cassandra est mis à niveau vers la version 4.0.X lors de la mise à niveau vers Private Cloud version 4.53.00, il est recommandé de continuer avec cette configuration de cluster et de NE PAS effectuer de rollback de Cassandra. Les composants tels que edge-management-server, edge-message-processor, edge-router, etc., de la version 4.52.02 du cloud privé sont compatibles avec la version 4.0.X de Cassandra.
  • Effectuer un rollback de Cassandra lors de la mise à niveau de Cassandra : si vous rencontrez des problèmes lors de la mise à niveau de Cassandra, vous pouvez envisager d'effectuer un rollback. Vous pouvez suivre les stratégies de restauration listées dans cet article en fonction de l'état dans lequel vous vous trouvez pendant le processus de mise à niveau.
  • Effectuer un rollback à l'aide de sauvegardes : les sauvegardes effectuées à partir de Cassandra 4.0.X ne sont pas compatibles avec les sauvegardes de Cassandra 3.11.X. Pour effectuer un rollback de Cassandra à l'aide de la restauration de sauvegarde, vous devez effectuer des sauvegardes de Cassandra 3.11.X avant de tenter la mise à niveau.

Rétablir Cassandra à l'aide de la reconstruction

Prérequis

  • Vous exploitez un cluster Edge pour Private Cloud 4.52.02 dans plusieurs centres de données.
  • Vous êtes en train de mettre à niveau Cassandra de la version 3.11.X vers la version 4.0.X et vous avez rencontré des problèmes lors de la mise à niveau.
  • Vous disposez d'au moins un centre de données entièrement fonctionnel dans le cluster qui exécute toujours l'ancienne version de Cassandra (Cassandra 3.11.X).

Cette procédure repose sur le streaming de données depuis un centre de données existant. Cela peut prendre un certain temps, selon la quantité de données stockées dans Cassandra. Vous devez être prêt à détourner le trafic d'exécution de ce centre de données pendant le rollback.

Étapes majeures

  1. Sélectionnez un centre de données (partiellement ou entièrement mis à niveau) que vous souhaitez rétablir. Redirigez le trafic d'exécution vers un autre centre de données opérationnel.
  2. Identifiez le nœud de départ dans le centre de données et commencez par l'un des nœuds de départ.
  3. Arrêtez, désinstallez et nettoyez le nœud Cassandra.
  4. Installez l'ancienne version de Cassandra sur le nœud et configurez-la selon vos besoins.
  5. Supprimez les configurations supplémentaires ajoutées précédemment.
  6. Répétez les étapes ci-dessus pour tous les nœuds de seed du centre de données, un par un.
  7. Répétez les étapes ci-dessus pour tous les nœuds Cassandra restants dans le centre de données, un par un.
  8. Reconstruisez les nœuds à partir du centre de données fonctionnel existant, un par un.
  9. Redémarrez tous les composants edge-* du centre de données connectés à Cassandra.
  10. Testez le trafic et redirigez-le vers ce centre de données.
  11. Répétez les étapes pour chaque centre de données, un par un.

Procédure détaillée

  1. Choisissez un centre de données dans lequel tous les nœuds Cassandra ou certains d'entre eux sont mis à niveau. Détournez tout le trafic du proxy d'exécution et le trafic de gestion de ce centre de données pendant que les nœuds Cassandra de ce centre de données sont restaurés. Assurez-vous que tous les nœuds Cassandra sont à l'état UN (Up/Normal) lorsque la commande nodetool ring est exécutée sur les nœuds. Si certains nœuds sont hors service, résolvez le problème et remettez-les en service avant de continuer.

    Référez-vous à l'exemple ci-dessous :

    /opt/apigee/apigee-cassandra/bin/nodetool status
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

    Vous pouvez exécuter nodetool describecluster sur les nœuds pour comprendre l'état actuel de l'ensemble du cluster. Par exemple, l'illustration suivante montre une instance d'un cluster à deux centres de données où tous les nœuds DC-1 sont sur la version 4 de Cassandra, tandis que tous les nœuds DC-2 sont sur la version 3 de Cassandra :

    # On nodes where Cassandra is upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Stats for all nodes:
    Live: 6
    Joining: 0
    Moving: 0
    Leaving: 0
    Unreachable: 0

Data Centers:
    dc-1 #Nodes: 3 #Down: 0
    dc-2 #Nodes: 3 #Down: 0

Database versions:
    4.0.13: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    3.11.16: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

Keyspaces:
    system_schema -> Replication class: LocalStrategy {}
    system -> Replication class: LocalStrategy {}
    auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
    system_traces -> Replication class: SimpleStrategy {replication_factor=2}
    system_auth -> Replication class: SimpleStrategy {replication_factor=1}

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
  2. Identifiez les nœuds de seed dans le centre de données : consultez la section Identifier les nœuds de seed dans l'annexe. Exécutez les étapes ci-dessous sur l'un des nœuds de seed :
  3. Arrêtez, désinstallez et nettoyez les données du nœud Cassandra. Sélectionnez le premier nœud "seed" (nœud racine) sur Cassandra version 4 dans ce centre de données. Arrête. 
    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe out Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra
  4. Installez l'ancienne version du logiciel Cassandra sur le nœud et définissez certaines configurations. Exécutez le fichier bootstrap d'Edge pour le cloud privé 4.52.02. 
    5. # Download bootstrap of 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord

# Execute bootstrap of 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
  5. Créez ou modifiez le fichier /opt/apigee/customer/application/cassandra.properties.
  6. Ajoutez le contenu suivant au fichier. ipOfNode correspond à l'adresse IP du nœud que Cassandra utilise pour communiquer avec d'autres nœuds Cassandra : 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  7. Assurez-vous que le fichier appartient à l'utilisateur Apigee et qu'il peut le lire : 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. Installez et configurez Cassandra :
    9. # Install cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  9. Vérifiez que le nœud a démarré. Vérifiez la commande suivante sur ce nœud et sur les autres nœuds du cluster. Le nœud doit indiquer qu'il est à l'état "UN" (Up/Normal) : 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. Supprimez les configurations supplémentaires ajoutées précédemment du fichier /opt/apigee/customer/application/cassandra.properties.
  11. Répétez les étapes 3 à 10 sur tous les nœuds de seed Cassandra du centre de données, un par un.
  12. Répétez les étapes 3 à 10 sur tous les nœuds Cassandra restants du centre de données, un par un.
  13. Reconstruisez tous les nœuds du centre de données à partir d'un centre de données exécutant l'ancienne version de Cassandra. Effectuez cette étape sur un nœud à la fois : 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    Cette procédure peut prendre du temps. Vous pouvez ajuster streamingthroughput si nécessaire. Vérifiez l'état d'avancement de l'opération dans nodetool netstats.

  14. (Facultatif) Exécutez la commande de réparation dans le nœud Cassandra si les données ne sont pas reconstruites. 
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  15. Redémarrez tous les composants edge-* du centre de données, un par un : 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  16. Validez le trafic et redirigez-le vers ce centre de données. Exécutez des validations pour le trafic d'exécution et les API de gestion dans ce centre de données, puis commencez à rediriger le trafic du proxy et des API de gestion vers celui-ci.
  17. Répétez les étapes ci-dessus pour chaque centre de données que vous souhaitez rétablir.

Restaurer Cassandra à l'aide d'une sauvegarde

Prérequis

  1. Vous êtes en train de mettre à niveau Cassandra de la version 3.11.X vers la version 4.0.X et vous avez rencontré des problèmes lors de la mise à niveau.
  2. Vous disposez de sauvegardes pour le nœud vers lequel vous effectuez le rollback. La sauvegarde a été effectuée avant la tentative de mise à niveau de la version 3.11.X vers la version 4.0.X.

Étapes

  1. Sélectionnez le nœud que vous souhaitez annuler. Si vous restaurez tous les nœuds d'un centre de données à l'aide de sauvegardes, commencez par les nœuds de seed. Consultez la section "Identifier les nœuds de départ" dans l'annexe.

  2. Arrêtez, désinstallez et nettoyez le nœud Cassandra :

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

  3. Installez l'ancienne version du logiciel Cassandra sur le nœud et configurez-la :

    • Exécutez le fichier bootstrap pour Edge pour le cloud privé 4.52.02 :
      • # Download bootstrap for 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u ‘uName:pWord’

# Execute bootstrap for 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
    • Créez ou modifiez le fichier /opt/apigee/customer/application/cassandra.properties :
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • Assurez-vous que le fichier appartient à l'utilisateur Apigee et qu'il est lisible :
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Installez et configurez Cassandra :
      • # Install Cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Set up Cassandra with the standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

# Verify Cassandra version and check service status
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

    Vérifiez que le nœud a démarré. Vérifiez la commande suivante sur ce nœud et sur les autres nœuds du cluster. Les nœuds doivent indiquer que ce nœud est à l'état "UN" :

    /opt/apigee/apigee-cassandra/bin/nodetool status

  4. Arrêtez le service Cassandra et restaurez la sauvegarde. Pour en savoir plus, consultez la documentation sur la sauvegarde et la restauration :

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Wipe the data directory in preparation for restore
rm -rf /opt/apigee/data/apigee-cassandra/data

# Restore the backup taken before the upgrade attempt
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile

  5. Une fois la sauvegarde restaurée, supprimez les configurations supplémentaires :

    Supprimez la configuration ajoutée précédemment du fichier /opt/apigee/customer/application/cassandra.properties.

  6. Démarrez le service Cassandra sur le nœud :

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

  7. Répétez les étapes sur chaque nœud Cassandra que vous souhaitez restaurer à l'aide de sauvegardes, un à la fois.

  8. Une fois tous les nœuds Cassandra restaurés, redémarrez tous les composants edge-* un par un :

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Optimisations de la sauvegarde (option avancée)

Vous pouvez potentiellement minimiser (ou éliminer) la perte de données lors de la restauration de sauvegardes si vous disposez de répliques contenant les données les plus récentes. Si des répliques sont disponibles, exécutez une réparation sur le nœud restauré après la restauration de la sauvegarde.

Annexe

Identifier les nœuds seed

Sur n'importe quel nœud Cassandra d'un centre de données, exécutez la commande suivante :

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

La commande génère plusieurs lignes. Recherchez la dernière ligne du résultat. Les adresses IP listées sur la dernière ligne sont les nœuds de départ. Dans l'exemple ci-dessous, DC-1-IP1, DC-1-IP2, DC-2-IP1 et DC-2-IP2 sont les adresses IP des nœuds de seed :

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

Effectuer le rollback de la mise à jour Zookeeper 3.8.4

Rollback

Si un rollback est nécessaire :

  1. Effectuez d'abord les étapes de rollback sur les observateurs et les abonnés.
  2. Téléchargez et exécutez le bootstrap de la version vers laquelle vous effectuez le rollback (4.52.02 ou 4.53.00). Le processus varie probablement selon que le nœud dispose d'une connexion Internet externe ou que vous suivez une installation hors connexion.
  3. Arrêtez Zookeeper s'il est en cours d'exécution sur le nœud : 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
  4. Désinstallez le ZooKeeper existant : 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
  5. Installez ZooKeeper comme d'habitude : 
      /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
  6. Une fois que tous les nœuds suiveurs et observateurs ont été rétablis, rétablissez le nœud principal en suivant les étapes 2 à 5 sur le nœud principal.
  7. Une fois tous les nœuds rétablis, vérifiez l'état du cluster et assurez-vous qu'il comporte un nœud principal.

Restaurer une sauvegarde

Consultez Restaurer à partir d'une sauvegarde. Notez que les sauvegardes de Zookeeper effectuées à partir de versions antérieures d'Edge pour le cloud privé, comme 4.52.02 ou 4.53.00, devraient être compatibles avec la version de Zookeeper dans Edge pour le cloud privé 4.53.01.

Effectuer un rollback de la mise à jour Postgres 17

Si vous avez effectué une mise à niveau vers la version 4.53.01 à partir de la version 4.52.02 ou 4.53.00, vous devez annuler la mise à jour de Postgres en plus des composants Edge.

Pour annuler la mise à jour de Postgres lorsque vous mettez à jour Postgres dans une configuration maître-veille :

  • Promouvez le nouveau nœud de secours pour qu'il devienne le maître Postgres. La nouvelle instance maîtresse Postgres sera de la même version que votre installation Edge précédente.
  • Configurez l'ancien nœud de secours pour qu'il devienne un nœud de secours du nouveau nœud maître. L'ancien nœud de secours aura la même version que votre précédente installation Edge.
  • Enregistrez les nouveaux nœuds maître et de secours auprès des groupes "analytics" et "consumer".

Une fois la restauration terminée, l'ancien nœud maître ne sera plus nécessaire. Vous pouvez ensuite désactiver l'ancien nœud maître.

Avant de commencer

Avant d'effectuer un rollback de Postgres 17 vers Postgres 14, procédez comme suit sur l'ancien et le nouveau hôte de secours pour mettre à jour la propriété max_locks_per_transaction sur apigee-postgresql :

  1. Si le fichier /opt/apigee/customer/application/postgresql.properties n'existe pas, créez-le.
  2. Modifiez la propriété de ce fichier pour qu'elle soit attribuée à apigee : 
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. Ajoutez la propriété suivante au fichier : 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. Configurez apigee-postgresql : 
    apigee-service apigee-postgresql configure
  5. Redémarrez apigee-postgresql : 
    apigee-service apigee-postgresql restart
  1. Assurez-vous que le nouveau nœud Postgres de secours est en cours d'exécution : 
    /opt/apigee/apigee-service/bin/apigee-all status

    Si Postgres n'est pas en cours d'exécution, démarrez-le :

    /opt/apigee/apigee-service/bin/apigee-all start
  2. Assurez-vous que Postgres est arrêté sur l'ancien nœud maître et l'ancien nœud de secours : 
    /opt/apigee/apigee-service/bin/apigee-all status

    Si Postgres est en cours d'exécution, arrêtez-le : 

    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop  
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  3. Si Qpid est installé, démarrez-le sur l'ancien nœud de secours : 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
  4. Promouvez le nouveau nœud de secours en tant que maître Postgres :
    1. Promouvez le nouveau nœud de secours pour qu'il devienne le nouveau maître : 
      apigee-service apigee-postgresql promote-standby-to-master old_master_IP

      Si vous y êtes invité, saisissez le mot de passe Postgres de l'utilisateur "apigee", qui est défini par défaut sur "postgres".

    2. Modifiez le fichier de configuration que vous avez utilisé pour installer votre version actuelle d'Edge afin de spécifier les éléments suivants : 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    3. Configurez le nouveau maître :
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
  5. Si vous avez déjà mis à niveau l'ancien nœud de secours vers la version la plus récente, vous devez d'abord rétrograder le logiciel Apigee sur l'ancien nœud de secours. Si l'ancienne version est toujours présente sur l'ancien nœud de secours, vous pouvez ignorer cette étape et passer à l'étape 6.
    1. Arrêtez Postgres sur l'ancien nœud de secours : 
      apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
    2. Désinstallez Postgres de l'ancien nœud de secours : 
      apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
    3. Supprimez le répertoire de données Postgres de l'ancien nœud de secours : 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    4. Téléchargez et exécutez l'ancien bootstrap (pour la version d'Apigee vers laquelle vous effectuez le rollback) sur l'ancien nœud de secours. La procédure exacte peut varier selon que vous utilisez une installation en ligne ou hors connexion. L'exécution de l'ancienne version du bootstrap Apigee configurera les dépôts yum avec les données Apigee de l'ancienne version.
    5. Configurez les composants Postgres sur l'ancien nœud standby : 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. Vérifiez que les composants Postgres de l'ancien nœud de secours ont été restaurés vers l'ancienne version : 
      apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
  6. Reconstruisez l'ancien nœud de secours :
    1. Modifiez le fichier de configuration que vous avez utilisé pour installer votre version actuelle d'Edge afin de spécifier les éléments suivants : 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    2. Supprimez le répertoire de données sur l'ancien nœud de secours : 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    3. Reconfigurez l'ancien nœud de secours pour qu'il devienne un nœud de secours du nouveau maître : 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. Assurez-vous que Postgres est en cours d'exécution sur l'ancien nœud de secours : 
      /opt/apigee/apigee-service/bin/apigee-all status

      Si Postgres n'est pas en cours d'exécution, démarrez-le :

      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
  7. Vérifiez que le nouveau nœud de secours a été ajouté en consultant le fichier /opt/apigee/apigee-postgresql/conf/pg_hba.conf sur le nouveau nœud maître.
  8. Pour afficher les informations actuelles sur les groupes d'analyse et de consommateurs, exécutez la commande suivante sur le serveur de gestion : 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    Cette commande renvoie le nom du groupe d'analyse dans le champ name et le nom du groupe de consommateurs dans le champ name sous consumer-groups. Il renvoie également les UUID des anciens nœuds maître et de secours Postgres dans les champs postgres-server et datastores. Le résultat doit s'afficher au format suivant : 

    {
  "name" : "axgroup-001",
  "properties" : {
  },
  "scopes" : [ "VALIDATE~test", "sgilson~prod" ],
  "uuids" : {
    "qpid-server" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "postgres-server" : [
      "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256"
    ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "datastores" :
      [ "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256" ],
      "properties" : {     }
    }
  ],
  "data-processors" : {
  }
}
  9. Obtenez l'adresse UUID de l'ancien maître en exécutant la commande curl suivante sur l'ancien nœud maître : 
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    Vous devriez voir le UUID du nœud à la fin de la sortie, sous la forme suivante :

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  10. Répétez l'étape précédente pour obtenir les adresses IP de l'ancien nœud de secours et du nouveau maître.
  11. Supprimez les anciens nœuds maître et de secours du groupe de consommateurs : 
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores/masterUUID,standbyUUID" -v

    Où axgroup-001 et consumer-group-001 sont les noms par défaut des groupes "analytics" et "consumer". Les masterUUID,standbyUUID sont dans le même ordre que celui dans lequel ils sont apparus ci-dessus lorsque vous avez consulté les informations actuelles sur les groupes d'analyse et de consommateurs. Vous devrez peut-être les spécifier en tant que standbyUUID,masterUUID.

    La propriété datastores pour consumer-groups doit maintenant être vide.

  12. Supprimez les anciens nœuds maître et de secours du groupe "analytics" : 
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

    La propriété postgres-server sous uuids devrait maintenant être vide.

  13. Enregistrez les nouveaux nœuds maître et de secours PG auprès des groupes "analytics" et "consumer" :
    curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
curl -u sysAdminEmail:password -X POST -H "Content-Type:application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores?uuid=masterUUID,standbyUUID" -v
  14. Validez le groupe "analytics" : 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    Les UUID des nouveaux nœuds maître et de secours devraient figurer dans les groupes "analytics" et "consumer".

  15. Redémarrez le serveur de gestion Edge : 
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
  16. Redémarrez tous les serveurs Qpid : 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
  17. Redémarrez tous les serveurs Postgres : 
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  18. Vérifiez l'état de la réplication en exécutant les scripts suivants sur les deux serveurs. Le système doit afficher des résultats identiques sur les deux serveurs pour garantir la réussite de la réplication :

    Sur la nouvelle instance maître, exécutez la commande suivante :

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master

    Vérifiez qu'il s'agit bien de l'appareil principal. Sur l'ancien nœud standby : 

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

    Vérifiez qu'il s'agit de la sauvegarde.

  19. Répétez l'étape précédente après avoir envoyé plusieurs requêtes API pour vous assurer que les nœuds sont synchronisés.
  20. Mettez hors service l'ancien nœud maître Postgres en suivant la procédure décrite dans Mettre hors service un nœud Postgres.

    Vous pouvez également désinstaller Qpid de l'ancien nœud maître et l'installer sur le nouveau nœud maître. Après avoir désinstallé Qpid, vous pouvez mettre hors service l'ancien nœud maître.

Effectuer le rollback de la mise à jour LDAP 2.6

Cette section fournit un guide complet et détaillé pour effectuer un rollback d'une installation LDAP vers une version LDAP précédente. La restauration doit être effectuée sur l'ensemble du cluster LDAP et n'est possible qu'à l'aide d'une sauvegarde LDAP valide avant la mise à niveau.

L'objectif principal est de rétablir un état cohérent pour l'ensemble du cluster LDAP à partir d'une sauvegarde correcte connue. Cette procédure est la même pour tous les scénarios (serveur unique, actif-actif et actif-passif).

Conditions préalables et points à noter

  • Incompatibilité de la sauvegarde : utilisez une sauvegarde de l'ancienne version 2.4 de LDAP que vous utilisiez avec Edge pour le cloud privé 4.52.02 ou 4.53.00. Cette sauvegarde doit avoir été effectuée avant la tentative de mise à niveau. Les sauvegardes effectuées après la mise à niveau sont incompatibles et ne peuvent pas être utilisées.
  • Indisponibilité de l'API Management : pendant la restauration LDAP, les API Management ne seront pas disponibles, ce qui peut avoir un impact sur les tâches d'administration. Veillez à arrêter tous les serveurs de gestion Edge et l'interface utilisateur Edge avant de poursuivre la restauration LDAP.
  • Risque de perte de données : si vous continuez sans sauvegarde valide et compatible, vous risquez de perdre des données de manière irréversible.
  • Sauvegarde valide : une sauvegarde LDAP valide préalable à la mise à niveau est requise.

Procédure de rollback

  1. Avant de poursuivre la mise à niveau LDAP, assurez-vous d'arrêter tous les serveurs edge-management-server et edge-ui. 
    apigee-service edge-management-server stop
apigee-service edge-ui stop
  2. Sauvegarder les données LDAP existantes (avant d'arrêter LDAP)

    Obtenez le nombre total d'enregistrements pour référence à partir de tous les serveurs LDAP. (Le nombre d'enregistrements doit être identique sur tous les serveurs LDAP.)

          # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password. 
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \ -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
  3. Arrêter et désinstaller le nouveau LDAP 2.6

    Arrêtez le service apigee-openldap et supprimez ses répertoires de configuration et de données. Cette opération doit être effectuée sur tous les serveurs LDAP, un nœud à la fois dans le cluster, pour garantir la cohérence.

    apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
  4. Installer l'ancienne version LDAP 2.4
    • Installez l'ancienne version de LDAP : 
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
    • Valider la version LDAP : 
      source ~/.bash_profile
ldapsearch -VV

#Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46
    • Répétez les étapes ci-dessus sur chaque nœud LDAP, un par un.
  5. Nettoyer les données résiduelles

    Sur tous les serveurs LDAP, arrêtez le service nouvellement installé un par un et nettoyez son répertoire de données pour préparer la restauration à partir de la sauvegarde.

    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
  6. Restaurer des données LDAP

    Si vous configurez un serveur unique, vous pouvez passer directement à l'étape 5b. Pour une configuration multiserveur, passez à l'étape 5a.

    1. Identifier le serveur LDAP actif

      Avant de restaurer les données LDAP, identifiez le serveur (fournisseur) actif en exécutant cette commande.

      grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif

* **Note**:
* If this command returns output, the server is a passive server. 
* If it returns no output, the server is the active server.
    2. Restaurez les données LDAP. (Assurez-vous que l'étape 4 est terminée sur tous les serveurs avant de procéder à la restauration.)
      • Sur le serveur LDAP unique et actif (déterminé à l'étape 5a), restaurez la sauvegarde. 
        cd /opt/apigee/backup/openldap

# To restore a specific backup, provide the timestamp as shown below:
apigee-service apigee-openldap restore 2025.07.28,13.59.00
# Note: If no timestamp is provided, the latest available backup will be restored by default.
apigee-service apigee-openldap restore

# It is recommended to specify the backup explicitly to avoid restoring an unintended version.
      • Démarrez le service apigee-openldap. 
        apigee-service apigee-openldap start
  7. Démarrer les serveurs LDAP restants

    Si vous disposez d'une configuration multiserveur, démarrez le service sur chacun des serveurs LDAP :

    apigee-service apigee-openldap start
  8. Validation finale
    • La dernière étape consiste à vérifier que la restauration a réussi et que les données sont cohérentes dans l'ensemble du cluster LDAP.
    • Exécutez la commande de validation sur tous les serveurs LDAP. Le nombre d'enregistrements doit être identique sur tous les serveurs et correspondre à celui que vous avez enregistré à l'étape 1. 
      # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \ -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
    • Une fois que vous avez confirmé que les données sont correctes et cohérentes, la restauration de votre LDAP est terminée. Vous pouvez maintenant commencer à démarrer edge-management-server, edge-ui et tous les autres composants dépendants, conformément à la procédure de mise à niveau standard de votre organisation.

Effectuer un rollback vers une version majeure ou mineure précédente

Pour effectuer un rollback vers une version majeure ou mineure précédente, procédez comme suit sur chaque nœud hébergeant le composant :

  1. Téléchargez le fichier bootstrap.sh pour la version vers laquelle vous souhaitez effectuer un rollback :

    • Pour revenir à la version 4.52.02, téléchargez bootstrap_4.52.02.sh.
  2. Arrêtez le composant pour effectuer le rollback :
    1. Pour rétablir l'un des composants avec code commun sur le nœud, vous devez tous les arrêter, comme le montre l'exemple suivant : 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
    2. Pour effectuer un rollback d'un autre composant du nœud, arrêtez-le : 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Si vous restaurez la version précédente de la monétisation, désinstallez-la de tous les nœuds Management Server et Message Processor : 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Désinstallez le composant pour effectuer un rollback sur le nœud :
    1. Pour restaurer l'un des composants avec code commun sur le nœud, vous devez tous les désinstaller en désinstallant le groupe de composants edge-gateway et apigee-cassandra-client, comme le montre l'exemple suivant : 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
       
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
    2. Pour revenir à la version précédente de Nginx, procédez comme suit : 
      ###Find the apigee-nginx RPM 
rpm -qa | grep -i "apigee-nginx"

###Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.26.x
    3. Pour effectuer un rollback d'un autre composant sur le nœud, désinstallez uniquement ce composant, comme le montre l'exemple suivant : 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      où component est le nom du composant.

    4. Pour rétablir le routeur Edge, vous devez supprimer le contenu du fichier /opt/nginx/conf.d en plus de désinstaller le groupe de composants edge-gateway : 
      cd /opt/nginx/conf.d
rm -rf *
  5. Désinstallez la version 4.53.01 de apigee-setup : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Installez la version 4.52.02 de l'utilitaire apigee-service et ses dépendances. L'exemple suivant installe la version 4.52.02 de apigee-service : 
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

    Où uName et pWord sont le nom d'utilisateur et le mot de passe que vous avez reçus d'Apigee. Si vous omettez pWord, vous serez invité à le saisir.

    Si vous obtenez une erreur, assurez-vous d'avoir téléchargé le fichier bootstrap.sh à l'étape 1.

  7. Installez apigee-setup : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. Installez l'ancienne version du composant : 
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    où component est le composant à installer et configFile est votre fichier de configuration pour l'ancienne version.

  9. Si vous restaurez Qpid, videz les iptables : 
    sudo iptables -F
  10. Répétez cette procédure pour chaque nœud qui héberge le composant que vous restaurez.

Effectuer un rollback de mTLS

Pour annuler la mise à jour mTLS, procédez comme suit sur tous les hôtes :

  1. Arrêter Apigee : 
    apigee-all stop
  2. Arrêter mTLS : 
    apigee-service apigee-mtls uninstall
  3. Réinstallez mTLS : 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf