Edge for Private Cloud v4.19.01
Si vous rencontrez une erreur lors d'une mise à jour de Edge 4.19.01, vous pouvez effectuer un rollback du composant à l'origine de l'erreur, puis relancer la mise à jour.
Vous pouvez effectuer un rollback vers les versions suivantes d'Edge 4.19.01:
- Version 4.18.05
- Version 4.18.01
- Version 4.17.09*
* Pour effectuer un rollback de la version 4.19.01 vers la version 4.17.09, vous devez effectuer un rollback de Postgres en plus du rollback des composants sur chaque nœud. Si vous effectuez un rollback vers la version 4.18.01 ou la version 4.18.05, vous n'avez pas besoin d'effectuer un rollback de Postgres, car le processus de mise à niveau n'incluait pas de mise à jour de Postgres.
Il existe deux cas dans lesquels vous pouvez effectuer un rollback:
- Effectuer un rollback vers une version précédente de la fonctionnalité (de 4.19.01 à 4.18.05, par exemple).
- Effectuez un rollback vers une version de mise à jour précédente dans la même version. (de 4.19.01.02 à 4.19.01.01, par exemple).
Pour plus d'informations, consultez le processus de publication d'Apigee Edge.
Qui peut effectuer un rollback
L'utilisateur effectuant un rollback doit être le même que celui qui a mis à jour Edge ou un utilisateur s'exécutant en tant qu'utilisateur 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.
Composants avec du 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 le rollback de tous les composants qui se trouvent sur ce nœud.
edge-management-server
(serveur de gestion)edge-message-processor
(outil de traitement des 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 le rollback des trois.
Effectuer un rollback vers une version précédente de la fonctionnalité
Pour effectuer un rollback de la version 4.19.01 vers la version 4.17.09, vous devez effectuer un rollback de Postgres en plus du rollback des composants sur chaque nœud. Si vous effectuez un rollback depuis la version 4.18.01 ou la version 4.18.05, vous n'avez pas besoin d'effectuer un rollback de Postgres, car le processus de mise à niveau n'incluait pas de mise à jour Postgres.
Pour effectuer un rollback vers une version précédente de la fonctionnalité, procédez comme suit sur chaque nœud qui héberge le composant:
-
Téléchargez le fichier
bootstrap.sh
de la version à restaurer:- Pour effectuer un rollback vers la version 4.18.05, téléchargez
bootstrap_4.18.05.sh
:curl https://software.apigee.com/bootstrap_4.18.05.sh -o /tmp/bootstrap_4.18.05.sh
- Pour effectuer un rollback vers la version 4.18.01, téléchargez
bootstrap_4.18.01.sh
:curl https://software.apigee.com/bootstrap_4.18.01.sh -o /tmp/bootstrap_4.18.01.sh
- Pour effectuer un rollback vers la version 4.17.09, téléchargez
bootstrap_4.17.09.sh
:curl https://software.apigee.com/bootstrap_4.17.09.sh -o /tmp/bootstrap_4.17.09.sh
- Pour effectuer un rollback vers la version 4.18.05, téléchargez
- Arrêtez le composant pour effectuer un rollback :
- Pour effectuer un rollback de l'un des composants avec du code commun sur le nœud, vous devez tous les arrêter, comme indiqué dans 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
- Pour effectuer le rollback d'un autre composant sur le nœud, arrêtez uniquement ce composant :
/opt/apigee/apigee-service/bin/apigee-service component stop
- Pour effectuer un rollback de l'un des composants avec du code commun sur le nœud, vous devez tous les arrêter, comme indiqué dans l'exemple suivant :
- Si vous effectuez un rollback de la monétisation, désinstallez-la de tous les nœuds Management Server et de processeur de messages :
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
- Désinstallez le composant pour effectuer un rollback sur le nœud :
- Pour effectuer un rollback de l'un des composants avec du code commun sur le nœud, vous devez tous les désinstaller en désinstallant le groupe de composants
edge-gateway
, comme indiqué dans l'exemple suivant :/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
- Pour effectuer le rollback d'un autre composant du nœud, désinstallez uniquement ce composant, comme indiqué dans l'exemple suivant :
/opt/apigee/apigee-service/bin/apigee-service component uninstall
Où component correspond au nom du composant.
- Pour effectuer un rollback de Edge Router, vous devez supprimer le contenu du fichier
/opt/nginx/conf.d
en plus de désinstaller le groupe de composantsedge-gateway
:cd /opt/nginx/conf.d
rm -rf *
- Pour effectuer un rollback de l'un des composants avec du code commun sur le nœud, vous devez tous les désinstaller en désinstallant le groupe de composants
- Désinstallez la version 4.19.01 de
apigee-setup
:/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
- Installez la version 4.18.05, 4.18.01 ou 4.17.09 de l'utilitaire
apigee-service
et ses dépendances. L'exemple suivant installe la version 4.17.09 deapigee-service
:sudo bash /tmp/bootstrap_4.17.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 êtes invité à le faire.
Si vous recevez un message d'erreur, vérifiez que vous avez bien téléchargé le fichier
bootstrap.sh
à l'étape 1. - Installer
apigee-setup
:/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
- 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 le fichier de configuration de l'ancienne version.
- Si vous effectuez un rollback de Qpid, videz iptables :
sudo iptables -F
- Répétez cette procédure pour chaque nœud qui héberge le composant pour lequel vous effectuez le rollback.
Pour effectuer un rollback de la version 4.19.01 vers la version 4.17.09, vous devez effectuer un rollback de Postgres en plus du rollback des composants sur chaque nœud. Si vous effectuez un rollback depuis la version 4.18.01 ou la version 4.18.05, vous n'avez pas besoin d'effectuer un rollback de Postgres, car le processus de mise à niveau n'incluait pas de mise à jour Postgres.
Effectuer un rollback vers une version de mise à jour précédente
Pour effectuer le rollback d'un composant vers une version spécifique d'une version, procédez comme suit sur chaque nœud qui héberge le composant:
- Téléchargez la version spécifique du composant :
/opt/apigee/apigee-service/bin/apigee-service component_version install
Où component_version correspond au composant et à la version de mise à jour à installer. Par exemple :
/opt/apigee/apigee-service/bin/apigee-service edge-ui-4.17.09-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 --showduplicates list comp
Exemple :
yum --showduplicates list edge-ui
- 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 spécifiez uniquement le nom du composant lors de l'installation, et non la version.
- Répétez cette procédure pour chaque nœud qui héberge le composant pour lequel vous effectuez le rollback.
Pour effectuer un rollback de la version 4.19.01 vers la version 4.17.09, vous devez effectuer un rollback de Postgres en plus du rollback des composants sur chaque nœud. Si vous effectuez un rollback depuis la version 4.18.01 ou la version 4.18.05, vous n'avez pas besoin d'effectuer un rollback de Postgres, car le processus de mise à niveau n'incluait pas de mise à jour Postgres.
Effectuer un rollback de la mise à jour de Postgres 9.6
Si vous avez effectué une mise à niveau vers la version 4.19.01 depuis la version 4.17.09, vous devez effectuer un rollback de votre mise à jour Postgres en plus des composants Edge.
Pour annuler la mise à jour de Postgres lors de la mise à jour de Postgres dans une configuration de mise en veille principale:
- 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.
- 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
- Définissez le nouveau nœud de secours en tant que maître Postgres :
- Promouvez le nouveau nœud de secours en tant que nouveau nœud maître :
apigee-service apigee-postgresql promote-standby-to-master new_standby_IP
Si vous y êtes invité, entrez le mot de passe Postgres pour l'utilisateur "apigee", dont la valeur par défaut est "postgres".
- 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
- Configurez la nouvelle instance maître:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
- Promouvez le nouveau nœud de secours en tant que nouveau nœud maître :
- Recréez l'ancien nœud de secours :
- 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
- Supprimez le répertoire de données sur l'ancien nœud de secours :
cd /opt/apigee/data/apigee-postgresql/pgdata > rm -rf *
- 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-replication-on-standby -f configFile
- Assurez-vous que Postgres s'exécute 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
- Modifiez le fichier de configuration que vous avez utilisé pour installer votre version actuelle d'Edge afin de spécifier les éléments suivants :
- 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 nœud maître. - Affichez les données d'analyse et les informations sur les groupes 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 champname
sousconsumer-groups
. Les UUID des anciens nœuds maîtres et de secours Postgres sont également renvoyés dans le champpostgres-server
et dans le champdatastores
. 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 nœud maître en exécutant la commande
curl
suivante sur celui-ci :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"
- 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.
- Supprimez les anciens nœuds maîtres 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. Les masterUUID,standbyUUID sont dans le même ordre que celui affiché 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
pourconsumer-groups
doit désormais être vide. - 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=masterUUID,standbyUUID&type=postgres-server" -v
La propriété
postgres-server
sousuuids
devrait désormais être vide. - Enregistrez les nouveaux nœuds maîtres et de secours du PG 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îtres et de secours doivent s'afficher dans le groupe d'analyse et dans 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 émettant 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 d'une instance de secours.
- 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.
- 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.09.
Vous pouvez également désinstaller Qpid de l'ancien nœud maître et installer Qpid sur le nouveau nœud maître. Après avoir désinstallé Qpid, vous pouvez mettre l'ancien nœud maître hors service.
Désinstaller Qpid de l'ancien maître et installer Qpid sur le nouveau
Pour désinstaller Qpid de l'ancien maître et l'installer sur le nouveau:
- Bloquez l'accès au port Qpid 5672 de 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
- 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 une table contenant un nombre pour
msg, msgIn, and msgOut
. Tous les messages seront traités lorsquemsg=0
etmsgIn=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 ultérieurement dans la procédure :
curl -u sysAdminEmail:password http://node_IP::8083/v1/servers/self
- Arrêter 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ésinstaller 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 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/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 celui-ci. Enregistrez ces informations pour les utiliser ultérieurement dans la procédure :
curl -u sysAdminEmail:password http://node_IP::8083/v1/servers/self
- Enregistrez le nouveau serveur Qpid 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=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
msg
,msgIn
etmsgOut
sont mis à jour à mesure que le serveur Qpid traite les messages.
Contactez l'assistance Apigee Edge si vous rencontrez des problèmes lors du rollback.