Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

4.17.01 Rollback

Edge for Private Cloud v. 4.17.01

En cas d'erreur lors d'une mise à jour vers Edge 4.17.01, vous pouvez restaurer le composant à l'origine de l'erreur, puis réessayer d'effectuer la mise à jour. Par exemple, si la mise à jour vers Postgres 9.4 échoue, vous pouvez effectuer un rollback uniquement sur les nœuds Postgres et réessayer la mise à jour.

Deux scénarios peuvent vous amener à effectuer un rollback :

Effectuer un rollback vers une version antérieure. Par exemple, de la version 4.17.01 à la version 4.16.09.
Effectuer un rollback vers une version antérieure de la même version.

Suivez la procédure ci-dessous pour effectuer un rollback dans les deux scénarios.

Qui peut effectuer le rollback ?

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

Éléments pouvant être soumis à un rollback

Vous devez tenir compte des conditions suivantes lorsque vous effectuez un rollback :

Les cinq composants Edge listé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 un rollback sur les trois pour effectuer un rollback sur l'un d'entre eux.
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 à partir d'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 un rollback de composants, laissez Cassandra à la version 4.17.01.

Rollback de la version 4.17.01…

Cette section décrit la procédure à suivre pour effectuer un rollback d'Edge 4.17.01 vers une version précédente. Cette section est divisée en deux parties :

Si vous effectuez une mise à jour à partir de la version 4.16.01 ou 4.16.05 uniquement : annuler 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 utiliser cette procédure pour annuler la mise à jour.
Effectuer un rollback de tous les autres composants Edge
Utilisez cette procédure pour effectuer un rollback de tous les autres composants Edge.

Pour effectuer un rollback de la mise à jour de Postgres 9.4 :

Pour effectuer un rollback de la mise à jour de Postgres lors de la mise à jour de Postgres dans une configuration maître-serveur de secours, procédez comme suit :

Promouvez le nouveau nœud de secours pour qu'il devienne le maître Postgres. Le nouveau maître 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 sera 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 "analytics" et "consumer".

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

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
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
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éberge que Postgres, mais pas Qpid.
Promouvez le nouveau nœud de secours en tant que maître Postgres :
1. Promouvez le nouveau nœud de secours en tant que nouveau maître :
  > apigee-service apigee-postgresql promote-standby-to-master new_standby_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 :
  # Adresse IP du nouveau maître:
  PG_MASTER=new_standby_IP
  # Adresse IP du nœud de secours ancien
  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
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 :
  # Adresse IP du nouveau maître:
  PG_MASTER=new_standby_IP
  # Adresse IP du nœud de secours ancien
  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 nœud 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
  
  S'il n'est pas en cours d'exécution, démarrez-le :
  > /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
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.
Affichez les informations actuelles sur le groupe d'analyse et de consommateurs 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 sous consumer-groups. Il renvoie également les UUID des anciens nœuds maître et de secours Postgres dans le champ postgres-server et dans le champ datastores. Le résultat doit se présenter sous la forme suivante :

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

L'UUID du nœud doit s'afficher à la fin du résultat, sous la forme suivante :
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"

Remarque : Le service edge-postgres-server doit être en cours d'exécution. 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 de l'adresse IP de chaque nœud Postgres.
Répétez l'étape précédente pour obtenir les adresses IP de l'ancien nœud de secours et du nouveau nœud maître.
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 d'analyse et de consommateurs. masterUUID,standbyUUID sont dans le même ordre que celui indiqué ci-dessus lorsque vous avez consulté les informations actuelles sur le groupe d'analyse et de consommateurs. Vous devrez peut-être les spécifier sous la forme standbyUUID,masterUUID.

La propriété datastores pour consumer-groups doit maintenant être vide.
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 doit maintenant être vide.
Enregistrez les nouveaux nœuds PG maître et de secours auprès des groupes d'analyse et de consommateurs :
> 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
Validez le groupe d'analyse :
> curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/analytics/groups/ax

Les UUID des nouveaux nœuds maître et de secours doivent s'afficher dans le groupe d'analyse et le groupe de consommateurs.
Redémarrez le serveur de gestion Edge :
> /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
Redémarrez tous les serveurs Qpid :
> /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
Redémarrez tous les serveurs Postgres :
> /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
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 une réplication réussie :

Sur le nouveau 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.
Répétez l'étape précédente après avoir effectué plusieurs requêtes API pour vous assurer que les nœuds sont synchronisés.
Mettre hors service l'ancien maître Postgres en suivant la procédure décrite dans Mettre à jour Apigee Edge vers la version 4.16.09.

Remarque : Si l'ancien nœud maître exécutait Qpid, vous pouvez laisser ce serveur exécuter Qpid. Assurez-vous qu'il 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 nœud maître et l'installer sur le nouveau nœud maître, comme décrit ci-dessous. Après avoir désinstallé Qpid, vous pouvez mettre hors service l'ancien nœud maître.

Désinstaller Qpid de l'ancien maître et installer Qpid sur le nouveau maître

Procédez comme suit pour désinstaller Qpid de l'ancien maître et l'installer sur le nouveau maître :

Bloquez l'accès au port Qpid 5672 sur l'ancien maître à partir de l'accès par les processeurs de messages 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
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 pour msg, msgIn et msgOut. Tous les messages auront été traités lorsque msg=0 et msgIn=msgOut.
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 les utiliser plus tard dans la procédure :
> curl -u sysAdminEmail:password http://<node_IP>::8083/v1/servers/self
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
Désinstallez le serveur Qpid :
> /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server uninstall
> /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall
Supprimez l'ancien serveur Qpid des groupes "analytics" et "consumer" :
> curl -u sysAdminEmail:password -X DELETE -H "Content-Type: application/json" -d '' "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/consumers/qpid_UUID" -v

> curl -u sysAdminEmail:password -X DELETE "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=qpid_UUID&type=qpid-server" -v
Supprimez l'ancien serveur Qpid de ZooKeeper :
> curl -u sysAdminEmail:password -X DELETE http://<ms_IP>:8080/v1/servers/qpid_UUID
Installez Qpid sur le nouveau maître :
> /opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile
Déterminez l'UUID du serveur Qpid sur le nouveau maître en exécutant la commande suivante sur le nouveau maître. Enregistrez ces informations pour les utiliser plus tard dans la procédure :
> curl -u sysAdminEmail:password http://<node_IP>::8083/v1/servers/self
Enregistrez le nouveau serveur Qpid 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=qpid_UUID&type=qpid-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/consumers?uuid=qpid_UUID" -v
Redémarrez tous les processeurs de messages :
> /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
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

Assurez-vous que les valeurs msg, msgIn et msgOut sont mises à jour à mesure que le serveur Qpid traite les messages.

Pour effectuer un rollback de composants individuels à partir de la version 4.17.01 :

Pour effectuer le rollback, vous devez télécharger le fichier bootstrap.sh de votre version actuelle d'Edge :

Pour revenir à la version 4.16.09, téléchargez bootstrap_4.16.09.sh.
Pour revenir à la version 4.16.05, téléchargez bootstrap_4.16.05.sh.
Pour revenir à la version 4.16.01, téléchargez bootstrap.sh.

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

Arrêtez le composant à restaurer :
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 stop
  - > apigee-service edge-qpid-server stop
  - > apigee-service edge-postgres-server stop
2. Si vous effectuez un rollback d'un autre composant sur le nœud, arrêtez uniquement ce composant :
  - > apigee-service comp stop
Si vous effectuez un rollback de la monétisation, désinstallez-la de tous les nœuds du serveur de gestion et du processeur de messages :
> apigee-service edge-mint-gateway uninstall
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-les tous : serveur de gestion, routeur, processeur de messages, serveur Qpid ou serveur Postgres :
  > apigee-service edge-gateway uninstall
2. Si vous effectuez un rollback d'un autre composant sur le nœud, désinstallez uniquement ce composant :
  > apigee-service comp uninstall
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 *
Pour effectuer un rollback du composant :
1. Désinstallez la version 4.17.01 d'apigee-setup :
  > /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
2. Téléchargez bootstrap.sh pour la version 4.16.01, 4.16.05 ou 4.16.09 :
  
  Par exemple, pour la version 4.16.09 :
  > curl https://software.apigee.com/bootstrap_4.16.09.sh -o /tmp/bootstrap_4.16.09.sh
3. Installez l'utilitaire apigee-service 4.16.01, 4.16.05 ou 4.16.09 et ses dépendances.
  
  Par exemple, pour la version 4.16.09 :
  > sudo bash /tmp/bootstrap_4.16.09.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.
4. Installez la version 4.16.01, 4.16.05 ou 4.16.09 d'apigee-setup :
  > /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
5. Installez la version 4.16.01, 4.16.05 ou 4.16.09 du composant :
  > /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile
  
  où comp est le composant à installer et configFile est votre fichier de configuration 4.16.01, 4.16.05 ou 4.16.09.
6. Si vous effectuez un rollback de Qpid, videz iptables :
  > sudo iptables -F
Pour effectuer un rollback du composant vers une version spécifique de la version 4.17.01 :
1. Téléchargez la version spécifique du composant :
  > /opt/apigee/apigee-service/bin/apigee-service comp-version install
  
  où comp-version correspond au composant et à la version à installer. Par exemple :
  > /opt/apigee/apigee-service/bin/apigee-service edge-ui-4.17.01-0.0.3749 install
  
  Si vous utilisez le dépôt en ligne Apigee, vous pouvez déterminer les versions de composants disponibles à l'aide de la commande suivante :
  > yum --showduplicates list comp
  
  Par exemple :
  > yum --showduplicates list edge-ui
2. Utilisez apigee-setup pour installer le composant :
  > /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile
  
  Exemple :
  > /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
  
  Notez que vous ne spécifiez que le nom du composant lors de l'installation.

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