Cette page a été traduite par l'API Cloud Translation.

4.18.01 Rollback

Edge pour Private Cloud v4.18.01

En cas d'erreur lors d'une mise à jour vers Edge 4.18.01, vous pouvez effectuer un rollback du composant à l'origine de l'erreur, puis réessayez d'effectuer la mise à jour. Par exemple, si la mise à jour vers Postgres 9.6 échoue, vous pouvez effectuer un rollback uniquement sur les nœuds Postgres et relancer la mise à jour.

Il existe deux scénarios dans lesquels vous pouvez effectuer un rollback:

Effectuez un rollback vers une version plus ancienne. par exemple de 4.18.01 à 4.17.01.
effectuer un rollback vers une ancienne version 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 effectuant le rollback doit être le même que l'utilisateur qui a initialement mis à jour Edge, ou un utilisateur 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 Edge composants en tant que différents utilisateurs. Par exemple, si le routeur doit accéder à des ports privilégiés, tels que ceux inférieurs à 1 000, vous devez exécuter le routeur en tant que racine ou en tant qu'utilisateur ayant accès à ces . Vous pouvez également exécuter un composant en tant qu'utilisateur et un autre composant en tant qu'autre utilisateur.

Composants pouvant 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 les cinq composants d'un nœud, vous devez effectuer un rollback de l'un des cinq composants installés sur le nœud. Pour exemple, si le serveur de gestion, le routeur et le processeur de messages sont installés sur le pour effectuer le rollback de l'une d'entre elles, vous devez effectuer le rollback tous les trois.

Les cinq composants qui partagent du code sont les suivants:
- Serveur de gestion
- Routeur
- Processeur de messages
- Serveur Qpid
- Serveur Postgres
Si vous effectuez la mise à jour à partir d'Edge 4.16.01, n'effectuez pas de rollback vers Cassandra. Ce d’Edge contient une version mise à jour de Cassandra. Si vous effectuez un rollback de certains composants, laissez Cassandra à la version 4.18.01.

Rollback de la version 4.18.01

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

Effectuer un rollback de la mise à jour Postgres
La dernière partie de chaque procédure de mise à jour consiste à mettre à jour les nœuds Postgres vers la version 9.6. Si de la mise à jour échoue, vous pouvez suivre cette procédure pour effectuer un rollback de la mise à jour.
Effectuer un rollback de tous les autres composants Edge
Utilisez cette procédure pour effectuer le rollback de tous les autres composants Edge.

Pour effectuer un rollback de la mise à jour Postgres 9.6

Pour effectuer un rollback de la mise à jour de Postgres dans une configuration de secours principal, vous:

Convertissez le nouveau nœud de secours en nœud maître Postgres. Le nouveau nœud maître Postgres sera la même version que votre installation Edge précédente.
Configurez l'ancien nœud de secours pour en faire un nœud de secours du nouveau nœud maître. L'ancien nœud de secours sera la même version que votre installation Edge précédente.
Enregistrez les nouveaux nœuds maîtres et de secours auprès des groupes d'analyse et de consommateurs.

Une fois le rollback terminé, l'ancien nœud maître n'est plus nécessaire. Vous pouvez puis mettez 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
```

Vérifiez 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ébergera que Postgres, mais pas Qpid.
Promouvez le nouveau nœud de secours en tant que maître Postgres: <ph type="x-smartling-placeholder">
1. Faites passer le nouveau nœud de secours en 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 pour "apigee". utilisateur, dont la valeur par défaut est "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:
```
# 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
```
Recréez l'ancien nœud de secours: <ph type="x-smartling-placeholder">
1. Modifiez le fichier de configuration que vous avez utilisé pour installer votre version actuelle d'Edge pour 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 de 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-replication-on-standby -f configFile
```
4. Vérifiez 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 affichant le /opt/apigee/apigee-postgresql/conf/pg_hba.conf sur le nouveau maître.

Affichez les informations actuelles sur les données analytiques et 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 nom du groupe de consommateurs dans le champ name sous consumer-groups. Il y a aussi renvoie les UUID des anciens nœuds maîtres et nœuds de secours Postgres dans le dans les champs postgres-server et datastores. Vous devriez voir 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'ancienne instance. 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 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 répertorie l'UUID pour l'adresse IP de chaque nœud Postres.
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 client:
```
> 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 du l'analyse et les groupes de consommateurs. Les masterUUID,standbyUUID sont dans le même ordre que apparaît ci-dessus lorsque vous avez consulté les informations actuelles sur les données analytiques et les groupes de consommateurs. Toi vous devrez peut-être les spécifier en tant que standbyUUID,masterUUID.

La propriété datastores pour consumer-groups doit maintenant ê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 sous uuids doit maintenant être vide.

Enregistrez les nouveaux nœuds maîtres et de secours de PG avec les 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 être répertoriés dans le groupe d'analyse. 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 la réussite de la réplication:

Sur le nouveau nœud 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 de l'instance 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 de l'instance 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 dans synchro.
Mettez l'ancien système Postgres hors service en suivant la procédure décrite dans Mettre à jour Apigee Edge 4.16.01/4.16.05 vers 4.17.09.
Remarque: Si l'ancien nœud maître exécutait Qpid, vous pouvez laisser ce serveur en service pour exécuter Qpid. Vérifiez 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'ancienne instance maître et installer Qpid sur le nouveau. comme décrit ci-dessous. Après avoir désinstallé Qpid, vous pouvez mettre l'ancien maître hors service. d'un nœud.

Supprimez Qpid de l'ancienne instance maître et installez-la sur la nouvelle instance.

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

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 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ésinstallez Qpid jusqu'à ce que tous les messages en attente aient été traités:
```
> qpid-stat -q
```
Cette commande affiche une table contenant un nombre pour msg, msgIn, and msgOut. Tous les messages auront été traités le 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 pouvoir les utiliser ultérieurement dans la procédure:
```
> curl -u sysAdminEmail:password http://node_IP::8083/v1/servers/self
```

Arrêtez Qpid sur l'ancienne instance 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 d'analyse et de consommation:

> 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 nœud 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 la nouvelle instance maître. Enregistrez ces informations pour pouvoir 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 bien été créées:
```
> qpid-stat -q
```
Assurez-vous que msg, msgIn et msgOut est mis à jour en tant que serveur Qpid traite les messages.

Pour effectuer un rollback de composants individuels depuis 4.18.01

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.09, téléchargez bootstrap_4.17.09.sh
Pour effectuer un rollback vers la version 4.17.05, téléchargez bootstrap_4.17.05.sh.
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 devant faire l'objet d'un rollback:

Arrêtez le composant pour le rollback: <ph type="x-smartling-placeholder">
1. Si vous effectuez le rollback de l'un des composants suivants sur le nœud, vous devez les arrêter tous: Management Server, Router, Message Processing, Qpid Server ou Postgres. Serveur: <ph type="x-smartling-placeholder">
  - ```
  > 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 le rollback d'un autre composant sur le nœud, arrêtez uniquement composant: <ph type="x-smartling-placeholder">
  - ```
  > apigee-service comp stop
```
Si vous effectuez un rollback de la monétisation, désinstallez-la de l'ensemble du serveur de gestion et des messages Nœuds de processeur:
```
> apigee-service edge-mint-gateway uninstall
```
Désinstallez le composant pour effectuer un rollback sur le nœud: <ph type="x-smartling-placeholder">
1. Si vous effectuez le rollback de l'un des composants suivants sur le nœud, tous les désinstaller: Management Server, Router, Message Processing, Qpid Server ou Postgres Serveur:
```
> apigee-service edge-gateway uninstall
```
2. Si vous effectuez un rollback d'un autre composant sur le nœud, désinstallez-le uniquement. 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: <ph type="x-smartling-placeholder">
1. Désinstallez la version 4.18.01 de apigee-setup:
```
> /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
```
2. Téléchargez bootstrap.sh pour la version souhaitée: 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, puis les dépendances. Par exemple, pour 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é à saisir
4. Installez apigee-setup :
```
> /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
```
5. Installez la version souhaitée du composant:
```
> /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile
```
  où comp est le composant à installer et configFile est votre pour la version souhaitée.
6. Si vous effectuez un rollback de Qpid, videz iptables:
```
> sudo iptables -F
```
Pour restaurer une version spécifique de la version 4.18.01 du composant: <ph type="x-smartling-placeholder">
1. Téléchargez la version du composant concerné:
```
> /opt/apigee/apigee-service/bin/apigee-service comp-version install
```
  où comp-version correspond au composant et à la version à installer. 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
```
2. Installez le composant à l'aide de apigee-setup:
```
> /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 devez spécifier le nom du composant que lors de l'installation.

Contactez l'assistance Apigee Edge si vous rencontrez des problèmes lors d'un rollback.