4.17.05 Rollback

Edge pour Private Cloud version 4.17.05

En cas d'erreur lors d'une mise à jour de Edge 4.17.05, vous pouvez effectuer un rollback du composant à l'origine de l'erreur, puis relancer la mise à jour. Par exemple, si la mise à jour vers Postgres 9.4 échoue, vous pouvez effectuer un rollback des nœuds Postgres et relancer la mise à jour.

Il existe deux cas dans lesquels vous pouvez effectuer un rollback:

  1. Effectuez un rollback vers une version plus ancienne. (de 4.17.05 à 4.17.01, par exemple).
  2. Effectuez un rollback vers une ancienne version dans la même version.

Pour effectuer un rollback dans les deux cas, suivez la procédure ci-dessous.

Qui peut effectuer le rollback

L'utilisateur effectuant le rollback doit être le même que celui qui a mis à jour Edge ou un utilisateur s'exécutant en mode 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 à 1 000, vous devez l'exécuter en tant qu'utilisateur racine ou utilisateur ayant accès à ces ports. Vous pouvez également exécuter un composant en tant qu'utilisateur et un autre en tant qu'utilisateur.

Quels composants peuvent faire l'objet d'un rollback

Lorsque vous effectuez un rollback, vous devez tenir compte des conditions suivantes:

  • Les cinq composants Edge répertoriés ci-dessous partagent un code commun. Par conséquent, pour effectuer un rollback de l'un des cinq composants d'un nœud, vous devez effectuer un rollback de l'un des cinq composants installés sur le nœud. Par exemple, si le serveur de gestion, le routeur et le processeur de messages sont installés sur le nœud, vous devez effectuer le rollback de l'un d'entre eux pour les restaurer.
    Les cinq composants qui partagent du code sont les suivants :
    • Serveur de gestion
    • Routeur
    • Processeur de messages
    • Serveur Qpid
    • Serveur Postgres
  • Si vous effectuez une mise à jour depuis Edge 4.16.01, n'effectuez pas de rollback de Cassandra. Cette version d'Edge contient une version mise à jour de Cassandra. Si vous effectuez le rollback de certains composants, conservez la version 4.17.05 de Cassandra.

Rollback de la version 4.17.05

Cette section contient la procédure pour effectuer un rollback d'Edge 4.17.05 vers une version antérieure. Cette section se divise en deux parties:

  • Si vous effectuez une mise à jour à partir de la version 4.16.01 ou 4.16.05 uniquement – Rollback de la mise à jour de Postgres vers la version 9.4
    La dernière partie de chaque procédure de mise à jour à partir de la version 4.16.01 ou 4.16.05 consiste à mettre à jour les nœuds Postgres vers la version 9.4. Si cette mise à jour échoue, vous pouvez suivre cette procédure pour l'annuler.
  • Rollback de tous les autres composants Edge
    Suivez cette procédure pour effectuer un rollback de tous les autres composants Edge.

Rollback de la mise à jour Postgres 9.4

Pour effectuer un rollback de la mise à jour Postgres lors de la mise à jour de Postgres dans une configuration de mise en veille principale, procédez comme suit:

  • Promouvoir le nouveau nœud de secours pour qu'il devienne le maître Postgres. Le nouveau nœud maître Postgres sera identique à la version de votre installation Edge précédente.
  • Configurez l'ancien nœud de secours en tant que nœud de secours du nouveau maître. L'ancien nœud de secours sera doté de la même version que votre installation Edge précédente.
  • Enregistrez les nouveaux nœuds maître et de secours auprès des groupes d'analyse et de consommateurs.

Une fois le rollback effectué, l'ancien nœud maître n'est plus nécessaire. Vous pouvez ensuite mettre l'ancien nœud maître hors service.

  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 bord-postgres-server stop
    > /opt/apigee/apigee-service/bin/apigee-re apigee
  3. S'il est installé, démarrez Qpid sur l'ancien nœud de secours:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-qpid-server start

    Remarque: Dans de nombreuses configurations, l'ancien nœud de secours n'hébergera que Postgres, mais pas Qpid.
  4. Définissez le nouveau nœud de secours en tant que maître Postgres :
    1. Promouvez le nouveau nœud de secours en tant que nouveau nœud de secours:
      > apigee-service apigee-postgresql promotion-standby-to-master new_standby_IP

      Si vous y êtes invité, saisissez le mot de passe Postgres pour 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 pour spécifier les éléments suivants:
      # adresse IP du nouveau maître:
      PG_MASTER=new_standby_IP
      # adresse IP de l'ancien nœud de secours
      PG_STANDBY=old_standby_IP
    3. Configurez le nouveau maître:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-réplication-on-master -f configFile
  5. Recréez l'ancien nœud de secours :
    1. Modifiez le fichier de configuration que vous avez utilisé pour installer votre version actuelle d'Edge pour spécifier les éléments suivants:
      # adresse IP du nouveau maître:
      PG_MASTER=new_standby_IP
      # adresse IP de l'ancien nœud de secours
      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 en faire un nœud de secours du nouveau maître:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-réplication-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

      S'il n'est pas en cours d'exécution, démarrez-le:
      > /opt/apigee/apigee-service/bin/apigee-service Edge-postgres-server start
  6. Vérifiez que le nouveau nœud de secours a été ajouté en affichant le fichier /opt/apigee/apigee-postgresql/conf/pg_hba.conf sur le nouveau maître.
  7. Affichez les informations actuelles des groupes de consommateurs et d'analyse en exécutant 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. Les UUID des anciens nœuds maîtres et de secours Postgres sont également renvoyés dans le champ postgres-server et dans le champ datastores. "5-125-6-5-5"-5-8


















  8. Obtenez l'adresse UUID de l'ancien nœud 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

    L'identifiant du nœud doit s'afficher à la fin du résultat, au format suivant :
    "


    Si le serveur Postgres n'est pas en cours d'exécution, vous pouvez exécuter la commande suivante sur le serveur de gestion pour déterminer l'UUID:
    > curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/servers?pod=analytics

    Le résultat de cette commande liste l'UUID pour l'adresse IP de chaque nœud Postres.
  9. 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.
  10. Supprimez les anciens nœuds maîtres et de secours du groupe grand public:
    > curl -u sysAdminEmail:password -X DELETE "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001 les noms d'analyse des consommateurs, où les noms des groupes consommateur,

    masterUUID,standbyUUID sont dans le même ordre qu'ils apparaissent ci-dessus lorsque vous avez consulté les informations actuelles sur les données analytiques et le groupe de consommateurs ci-dessus. Vous devrez peut-être les spécifier en tant que standbyUUID,masterUUID.

    La propriété datastores pour consumer-groups doit désormais être vide.
  11. Supprimez les anciens nœuds maîtres et de secours du groupe d'analyse:
    > curl -u sysAdminEmail:password -X DELETE "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=master,standby UUID

  12. Enregistrer les nouveaux nœuds UUID-de-gré et de nœud de secours avec les groupes d'analyse et de secours :
    > curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d '' "http://<ms_IP>:8080/v1/analytics/groups/ax/json?

  13. Validez le groupe d'analyse:
    > curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/analytics/groups/ax

    Les UUID des nouveaux nœuds maîtres et de secours doivent s'afficher dans le groupe d'analyse et dans le groupe de consommateurs.
  14. Redémarrez le serveur de gestion Edge:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-management-server restart
  15. Redémarrez tous les serveurs Qpid:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-qpid-server restart
  16. Redémarrez tous les serveurs Postgres:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-postgres-server restart
  17. Vérifiez l'état de la réplication en émettant les scripts suivants sur les deux serveurs. Le système doit afficher des résultats identiques sur les deux serveurs pour assurer une réplication réussie:

    Sur le nouveau serveur 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 du maître.

    Sur l'ancien nœud de secours:
    > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

    Vérifiez qu'il s'agit bien du nœud de secours.
  18. 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.
  19. Mettez l'ancien maître Postgres hors service à l'aide de la procédure décrite dans la section Mettre à jour Apigee Edge de la version 4.16.01/4.16.05 à la version 4.17.05.

    Remarque: Si l'ancien nœud maître exécutait Qpid, vous pouvez laisser ce serveur en cours d'exécution pour exécuter Qpid. Vérifiez qu'elle est en cours d'exécution. Si ce n'est pas le cas, démarrez-le:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-management-server start

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

Annuler l'installation de Qpid de l'ancien maître et installer Qpid sur le nouveau

Suivez la procédure suivante pour désinstaller Qpid de l'ancien maître et l'installer sur le nouveau:

  1. Bloquez l'accès au port Qpid 5672 sur l'ancien maître pour que les processeurs de messages ne puissent pas y accéder en exécutant la commande suivante sur tous les processeurs de messages:
    > iptables -A OUTPUT -p tcp -d 10.233.147.20 --dport 5672 -j DROP
  2. Assurez-vous que la file d'attente de messages Qpid est vide en exécutant la commande suivante. Vous ne pouvez pas désinstaller Qpid tant qu'il n'a pas traité tous les messages en attente:
    > qpid-stat -q

    Cette commande affiche un tableau contenant un nombre de messages pour msg, msgIn et msgOut. Tous les messages ont été traités lorsque msg=0 et msgIn=msgOut.
  3. Déterminez l'UUID du serveur Qpid sur l'ancien maître en exécutant la commande suivante sur l'ancien maître. Enregistrez ces informations pour plus tard dans la procédure:
    > curl -u sysAdminEmail:password http://<node_IP>::8083/v1/servers/self
  4. Arrêtez Qpid sur l'ancien maître:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-qpid-server stop
    > /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
  5. Désinstallez le serveur Qpid:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-qpid-server désinstalle
    > /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd désinstallation
  6. Supprimez l'ancien serveur Qpid : UUID/spd-des groupes d'analyse et de consommateurs :
    > curl -u sysAdminEmail:password -X DELETE -H "Content-Type: application/json" -d '' "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001

  7. Supprimez l'ancien serveur Qpid de Zookeeper:
    > curl -u sysAdminEmail:password -X DELETE http://<ms_IP>:8080/v1/servers/qpid_UUID
  8. Installez Qpid sur le nouveau maître:
    > /opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile.
  9. Déterminez l'UUID du serveur Qpid sur le nouveau maître en exécutant la commande suivante sur celui-ci. Enregistrez ces informations pour plus tard dans la procédure:
    > curl -u sysAdminEmail:password http://<node_IP>::8083/v1/servers/self



  10. Redémarrez tous les processeurs de messages:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor restart
  11. Exécutez la commande suivante sur le nouveau serveur Qpid pour vérifier que les files d'attente ont été créées:
    > qpid-stat -q

    Vérifiez que msg, msgIn et msgOut sont mis à jour lorsque le serveur Qpid traite les messages.

Pour effectuer un rollback de composants individuels depuis la version 4.17.05

Dans le cadre du rollback, vous devez télécharger le fichier bootstrap.sh pour votre version actuelle d'Edge:

  • Pour effectuer un rollback vers la version 4.17.01, téléchargez bootstrap_4.17.01.sh.
  • Pour effectuer un rollback vers la version 4.16.09, téléchargez bootstrap_4.16.09.sh.
  • Pour effectuer un rollback vers la version 4.16.05, téléchargez bootstrap_4.16.05.sh.
  • Pour effectuer un rollback vers la version 4.16.01, téléchargez bootstrap.sh.

Pour chaque nœud hébergeant un composant à restaurer:

  1. Arrêtez le composant pour effectuer un rollback :
    1. Si vous effectuez un rollback de l'un des composants suivants sur le nœud, vous devez tous les arrêter: serveur de gestion, routeur, processeur de messages, serveur Qpid ou serveur Postgres:
      • > apigee-service Edge-management-server stop
      • > apigee-service Edge-router stop
      • > apigee-service Edge-message-processor arrêt
      • > apigee-service Edge-qpid-server stop
      • > apigee-service Edge-postgres-server stop
    2. Si vous effectuez le rollback d'un autre composant du nœud, arrêtez uniquement ce composant:
      • > apigee-service comp arrêt
  2. Si vous effectuez un rollback de la monétisation, désinstallez-la de tous les nœuds du serveur de gestion et des nœuds de traitement des messages:
    > apigee-service Edge-mint-gateway désinstalle
  3. Désinstallez le composant pour effectuer un rollback sur le nœud :
    1. Si vous effectuez un rollback de l'un des composants suivants sur le nœud, désinstallez tous les composants suivants: Serveur de gestion, Routeur, Processeur de messages, Serveur Qpid ou Serveur Postgres:
      > Désinstaller la passerelle périphérique apigee-service
    2. Si vous effectuez un rollback d'un autre composant du nœud, désinstallez uniquement ce composant:
      > apigee-service comp désinstaller
    3. Si vous effectuez un rollback du routeur, vous devez supprimer le contenu de /opt/nginx/conf.d:
      > cd /opt/nginx/conf.d
      > rm -rf *
  4. Pour effectuer un rollback du composant:
    1. Désinstallez la version 4.17.05 de apigee-setup:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-setup désinstallation
    2. Téléchargez bootstrap.sh pour la version 4.16.01, 4.16.05, 4.16.09 ou 4.17.01:

      Par exemple, pour 4.16.09:
      > curl https://software.apigee.com/bootstrap_4.16.09.sh_mp-1sh
    3. Installez l'utilitaire apigee-service 4.16.01, 4.16.05 ou 4.16.09 et les dépendances.

      Par exemple, pour la version 4.16.09:
      > sudo bash /tmp/bootstrap_4.16.09.sh apigeeuser=uName apigeepassword=pWord

      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 êtes invité à le saisir.
    4. Installez la version 4.16.01, 4.16.05 ou 4.16.09 de apigee-setup:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
    5. Installez la version 4.16.01, 4.16.05, 4.16.09 ou 4.17.01 du composant:
      > /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile
      config.0.9 ou 4.0 est le fichier de configuration, ou 6.0, où configFile.
    6. Si vous effectuez un rollback de Qpid, videz iptables:
      > sudo iptables -F
  5. Pour effectuer un rollback du composant vers une version spécifique de la version 4.17.05:
    1. Téléchargez la version spécifique du composant:
      > /opt/apigee/apigee-service/bin/apigee-service comp-version install

      comp-version est le composant et la version à installer. Par exemple :
      > /opt/apigee/apigee-service/bin/apigee-service Edge-ui-4.17.05-0.0.3749 install

      Si vous utilisez le dépôt en ligne Apigee, vous pouvez déterminer les versions des composants disponibles à l'aide de la commande suivante :
      > yum --show duplicates list compui-4


    2. Utilisez apigee-setup pour installer le composant:
      > /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile

      Par exemple:
      > /opt/apigee/apigee-setup/bin/setup.sh -p ui -f comment configFile vous n'allez spécifier que le nom du composant configFile.

Contactez l'assistance Apigee si vous rencontrez des problèmes lors du rollback.