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

Mettre un centre de données hors service

Vous pouvez être amené à mettre hors service un centre de données. Par exemple, si vous mettez à niveau votre système d'exploitation, vous devez installer le nouveau système d'exploitation dans un nouveau centre de données, puis mettre hors service l'ancien centre de données. Les sections suivantes présentent un exemple de mise hors service d'un centre de données, dans lequel deux centres de données, dc-1 et dc-2, sont présents dans une installation en cluster de 12 nœuds :

dc-1 est le centre de données à mettre hors service.
dc-2 est le deuxième centre de données utilisé dans la procédure de désactivation.

Si vous mettez à niveau votre système d'exploitation, dc-2 peut être le centre de données dans lequel vous avez installé la nouvelle version du système d'exploitation. Toutefois, l'installation d'un nouvel OS n'est pas nécessaire pour mettre hors service un centre de données.

Éléments à prendre en compte avant de mettre hors service un centre de données

Tenez compte des points suivants lorsque vous mettez hors service un centre de données :

Bloquez tout le trafic d'exécution et de gestion vers le centre de données mis hors service, et redirigez-le vers d'autres centres de données.
Après la mise hors service du centre de données, la capacité de votre cluster Apigee sera réduite. Pour compenser cette perte, envisagez d'augmenter la capacité dans les centres de données restants ou d'ajouter des centres de données après la mise hors service.
Selon les composants analytiques installés dans le centre de données, il est possible que des données analytiques soient perdues pendant la mise hors service. Pour en savoir plus, consultez Ajouter ou supprimer des nœuds Qpid.
Avant de mettre hors service un centre de données, vous devez comprendre comment tous les composants sont configurés dans tous les centres de données, en particulier les serveurs SymasLDAP, ZooKeeper, Cassandra et Postgres. Vous devez également sauvegarder tous les composants et leurs configurations.

Avant de commencer

Serveur de gestion : toutes les étapes de mise hors service dépendent fortement du serveur de gestion. Si vous ne disposez que d'un seul serveur de gestion, nous vous recommandons d'installer un nouveau composant serveur de gestion dans un centre de données autre que dc-1 avant de mettre hors service le serveur de gestion sur dc-1. Assurez-vous qu'un des serveurs de gestion est disponible en permanence.
Routeur : avant de mettre hors service un routeur, désactivez l'accessibilité des routeurs en bloquant le port 15999. Assurez-vous qu'aucun trafic d'exécution n'est dirigé vers les routeurs que vous mettez hors service.
Cassandra et ZooKeeper : les sections ci-dessous décrivent comment mettre hors service dc-1 dans une configuration à deux centres de données.
Si vous avez plus de deux centres de données, veillez à supprimer toutes les références au nœud mis hors service (dc-1 dans ce cas) de tous les fichiers de configuration silencieux dans tous les centres de données restants. Dans le cas des nœuds Cassandra à mettre hors service, supprimez ces hôtes de CASS_HOSTS. Les nœuds Cassandra restants doivent conserver l'ordre d'origine de CASS_HOSTS.
Postgres : si vous mettez hors service le maître Postgres, veillez à promouvoir l'un des nœuds de secours disponibles en tant que nouveau maître Postgres. Bien que le serveur QPID conserve un tampon dans la file d'attente, si le maître Postgres n'est pas disponible pendant une longue période, vous risquez de perdre des données analytiques.
Attention : Vous devez supprimer et ajouter des serveurs PostgreSQL du groupe "analytics" et du groupe "consumer" en même temps. Vous risquez de perdre des données analytiques si le délai entre les deux étapes est important.
Suggestion : Le processeur de messages dispose d'une petite file d'attente dans laquelle il conserve les données analytiques en mémoire pendant une courte période, ce qui peut vous aider à éviter de perdre des données. Avant de modifier le groupe "analytics", bloquez le port 5672 dans le centre de données qui reçoit le trafic, puis assurez-vous de le réactiver rapidement après avoir effectué les modifications, car il existe un risque de dépassement de données.

Par exemple, pour arrêter temporairement le trafic d'analyse des processeurs de messages vers le serveur Qpid :
1. Saisissez la commande suivante :
```
iptables -A INPUT -p tcp --destination-port 5672 ! -s `hostname` -i eth0 -j DROP
```
2. Suivez les étapes pour modifier axgroup.
3. Supprimez la règle iptable après les modifications apportées à axgroup :
```
iptables -F
```

Prérequis

Avant de mettre hors service un composant, nous vous recommandons d'effectuer une sauvegarde complète de tous les nœuds. Utilisez la procédure correspondant à votre version actuelle d'Edge pour effectuer la sauvegarde. Pour en savoir plus sur la sauvegarde, consultez Sauvegarder et restaurer.

Remarque : Si vous avez plusieurs nœuds Cassandra ou ZooKeeper, sauvegardez-les un par un, car le processus de sauvegarde arrête temporairement ZooKeeper.
Avant de procéder à la mise hors service, assurez-vous qu'Edge est opérationnel à l'aide de la commande suivante :
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Assurez-vous qu'aucun trafic d'exécution n'arrive actuellement au centre de données que vous mettez hors service.

Ordre de mise hors service des composants

Si vous installez Edge for Private Cloud sur plusieurs nœuds, vous devez mettre hors service les composants Edge sur ces nœuds dans l'ordre suivant :

Interface utilisateur Edge (edge-ui)
Serveur de gestion (edge-management-server)
Symas LDAP (apigee-openldap)
Routeur (edge-router)
Processeur de messages (edge-message-processor)
Serveur Qpid et Qpidd (edge-qpid-server et apigee-qpidd)
Base de données Postgres et PostgreSQL (edge-postgres-server et apigee-postgresql)
ZooKeeper (apigee-zookeeper)
Cassandra (apigee-cassandra)

Les sections suivantes expliquent comment mettre hors service chaque composant.

Interface utilisateur Edge

Pour arrêter et désinstaller le composant Edge UI de dc-1, saisissez les commandes suivantes :

/opt/apigee/apigee-service/bin/apigee-service edge-ui stop
/opt/apigee/apigee-service/bin/apigee-service edge-ui uninstall

Serveur de gestion

Pour mettre hors service le serveur de gestion sur dc-1, procédez comme suit :

Arrêtez le serveur de gestion sur dc-1 :

apigee-service edge-management-server stop

Recherchez l'UUID du serveur de gestion enregistré dans dc-1 :

curl -u <AdminEmailID>:'<AdminPassword>' -X GET “http://{MS_IP}:8080/v1/servers?pod=central&region=dc-1&type=management-server”

Annulez l'enregistrement du type de serveur :

curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers -d "type=management-server&region=dc-1&pod=central&uuid=UUID&action=remove"

Supprimez le serveur. Remarque : Si d'autres composants sont également installés sur ce serveur, annulez leur enregistrement avant de supprimer l'UUID.
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/{UUID}
```

Désinstallez le composant serveur de gestion sur dc-1 :

/opt/apigee/apigee-service/bin/apigee-service edge-management-server uninstall

Symas LDAP

Cette section explique comment mettre hors service SymasLDAP sur dc-1.

Remarque : Si vous avez plus de deux centres de données, consultez la section Configurations avec plus de deux centres de données ci-dessous.

Pour mettre hors service SymasLDAP sur dc-1, procédez comme suit :

Sauvegardez le nœud dc-1 SymasLDAP en suivant la procédure décrite dans Sauvegarder vos données.
Interrompez la réplication des données entre les deux centres de données, dc-1 et dc-2, en exécutant les étapes suivantes dans les deux centres de données.
Remarque : Si votre configuration comporte plus de deux centres de données, vous devez procéder comme suit :
1. Identifiez le nœud SymasLDAP qui effectue la réplication vers le nœud que vous mettez hors service.
2. Modifiez la réplication pour que ce nœud soit répliqué sur un autre nœud afin de boucler la boucle de réplication.
Par exemple, supposons que vous disposiez de trois centres de données, dans lesquels le nœud 1 est répliqué sur le nœud 2, le nœud 2 est répliqué sur le nœud 3 et le nœud 3 est répliqué sur le nœud 1. Si vous mettez hors service le nœud 1, vous devez interrompre la réplication sur le nœud 1 et modifier la réplication pour le nœud 3 afin qu'il effectue la réplication sur le nœud 2.
1. Vérifiez l'état actuel :
```
      /opt/symas/bin/ldapsearch -H ldap://{HOST}:{PORT} -LLL -x -b "cn=config" -D "cn=admin,cn=config" -w {credentials} -o ldif-wrap=no 'olcSyncRepl' | grep olcSyncrepl
```
  Le résultat devrait ressembler à ce qui suit :
```
olcSyncrepl: {0}rid=001 provider=ldap://{HOST}:{PORT}/ binddn="cn=manager,dc=apigee,dc=com" bindmethod=simple credentials={credentials} searchbase="dc=apigee,dc=com" attrs="*,+" type=refreshAndPersist retry="60 1 300 12 7200 +" timeout=1
```
2. Créez un fichier break_repl.ldif contenant les commandes suivantes :
```
dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcSyncRepl

dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcMirrorMode
```
3. Exécutez la commande ldapmodify :
```
      /opt/symas/bin/ldapmodify -x -w {credentials} -D "cn=admin,cn=config" -H "ldap://{HOST}:{PORT}/" -f path/to/file/break_repl.ldif
```
  Le résultat devrait ressembler à ce qui suit :
```
modifying entry "olcDatabase={2}mdb,cn=config"
modifying entry "olcDatabase={2}mdb,cn=config"
```
Vous pouvez vérifier que dc-2 n'effectue plus de réplication sur dc-1 en créant une entrée dans le LDAP de dc-2 et en vous assurant qu'elle n'apparaît pas dans le LDAP de dc-1.

Vous pouvez également suivre les étapes ci-dessous, qui créent un utilisateur en lecture seule dans le nœud dc-2 SymasLDAP, puis vérifier si l'utilisateur est répliqué ou non. L'utilisateur est ensuite supprimé.
1. Créez un fichier readonly-user.ldif dans dc-2 avec le contenu suivant :
```
dn: uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: readonly-user
sn: readonly-user
userPassword: {testPassword}
```
2. Ajoutez un utilisateur avec la commande `ldapadd` dans dc-2 :
```
/opt/symas/bin/ldapadd -H ldap://{HOST}:{PORT} -w {credentials} -D "cn=manager,dc=apigee,dc=com" -f path/to/file/readonly-user.ldif
```
  Le résultat doit ressembler à ceci :
```
adding new entry "uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com"
```
3. Recherchez l'utilisateur dans dc-1 pour vous assurer qu'il n'est pas répliqué. Si l'utilisateur n'est pas présent dans dc-1, vous serez sûr qu'aucune réplication n'est effectuée entre les deux LDAP :
```
/opt/symas/bin/ldapsearch -H ldap://{HOST}:{PORT} -x -w {credentials} -D "cn=manager,dc=apigee,dc=com" -b uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com -LLL
```
  Le résultat devrait ressembler à ce qui suit :
```
No such object (32)
Matched DN: ou=users,ou=global,dc=apigee,dc=com
```
4. Supprimez l'utilisateur en lecture seule que vous avez ajouté précédemment :
```
/opt/symas/bin/ldapdelete -v -H ldap://{HOST}:{PORT} -w {credentials} -D "cn=manager,dc=apigee,dc=com" "uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com"
```

Arrêtez SymasLDAP dans dc-1 :

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap stop

Désinstallez le composant SymasLDAP sur dc-1 :

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap uninstall

Routeur

Cette section explique comment mettre hors service un routeur. Pour en savoir plus sur la suppression du routeur, consultez Supprimer un serveur.

Les étapes suivantes permettent de mettre hors service le routeur à partir de dc-1. Si plusieurs nœuds de routeur sont configurés dans dc-1, effectuez les étapes sur tous les nœuds de routeur, un par un.

Remarque : Nous partons du principe que le port de vérification de l'état du routeur (15999) est configuré dans votre équilibreur de charge et que le blocage du port 15999 rendra le routeur inaccessible. Vous devrez peut-être disposer d'un accès racine pour bloquer le port.

Pour mettre hors service un routeur, procédez comme suit :

Désactivez l'accessibilité des routeurs en bloquant le port 15999, qui est le port de vérification de l'état. Assurez-vous que le trafic d'exécution est bloqué sur ce centre de données :
```
iptables -A INPUT -i eth0 -p tcp --dport 15999 -j REJECT
```

Vérifiez que le routeur est accessible :

curl -vvv -X GET http://{ROUTER_IP}:15999/v1/servers/self/reachable

Le résultat devrait ressembler à ce qui suit :

About to connect() to 10.126.0.160 port 15999 (#0)
Trying 10.126.0.160...
Connection refused
Failed connect to 10.126.0.160:15999; Connection refused
Closing connection 0
curl: (7) Failed connect to 10.126.0.160:15999; Connection refused

Obtenez l'UUID du routeur, comme décrit dans Obtenir les UUID.

Arrêtez le routeur :

/opt/apigee/apigee-service/bin/apigee-service edge-router stop

Listez les pods de passerelle disponibles dans l'organisation à l'aide de la commande suivante :
```
curl -u  <AdminEmailID>:'<AdminPassword>' -X GET "http://{MS_IP}:8080/v1/organizations/{ORG}/pods"
```
Consultez À propos des pods.

Annulez l'enregistrement du type de serveur :

curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers -d "type=router&region=dc-1&pod=gateway-1&uuid=UUID&action=remove"

Annulez l'enregistrement du serveur :

curl -u <AdminEmailID>:'<AdminPassword>’ -X DELETE http://{MS_IP}:8080/v1/servers/UUID

Désinstallez edge-router :

/opt/apigee/apigee-service/bin/apigee-service edge-router uninstall

Consultez Supprimer un serveur.

Videz les règles iptables pour activer le port 15999 bloqué :
```
iptables -F
```

Processeur de messages

Cette section explique comment mettre hors service le processeur de messages à partir de dc-1. Pour en savoir plus sur la suppression du processeur de messages, consultez Supprimer un serveur.

Étant donné que nous supposons que dc-1 dispose d'une installation en cluster de 12 nœuds, deux nœuds Processeur de messages sont configurés dans dc-1. Exécutez les commandes suivantes dans les deux nœuds.

Obtenez les UUID des processeurs de messages, comme décrit dans Obtenir les UUID.

Arrêtez le processeur de messages :

apigee-service edge-message-processor stop

Annulez l'enregistrement du type de serveur :

curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers -d "type=message-processor&region=dc-1&pod=gateway-1&uuid=UUID&action=remove"

Dissociez un environnement du processeur de messages.

curl -H "Content-Type:application/x-www-form-urlencoded" <AdminEmailID>:'<AdminPassword>’  \
-X POST http://{MS_IP}:8080/v1/organizations/{ORG}/environments/{ENV}/servers \
-d "action=remove&uuid=UUID"

Annulez l'enregistrement du type de serveur :

curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers -d "type=message-processor&region=dc-1&pod=gateway-1&uuid=UUID&action=remove"

Désinstallez le processeur de messages :

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor uninstall

Annulez l'enregistrement du serveur :

curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID

Serveur Qpid et Qpidd

Cette section explique comment mettre hors service Qpid Server (edge-qpid-server) et Qpidd (apigee-qpidd). Deux nœuds Qpid sont configurés dans dc-1. Vous devez donc suivre les étapes suivantes pour les deux nœuds :

Obtenez l'UUID pour Qpidd, comme décrit dans Obtenir les UUID.

Arrêtez edge-qpid-server et apigee-qpidd :

/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop

Obtenez la liste des groupes "analytics" et "consumer" :

curl -u <AdminEmailID>:'<AdminPassword>' -X GET http://{MS_IP}:8080/v1/analytics/groups/ax

Supprimez Qpid du groupe "consumer" :

curl -u <AdminEmailID>:'<AdminPassword>' -H "Content-Type: application/json"  -X DELETE \ "http://{MS_IP}:8080/v1/analytics/groups/ax/{ax_group}/consumer-groups/{consumer_group}/consumers/{QPID_UUID}"

Supprimez Qpid du groupe "analytics" :

curl -v -u <AdminEmailID>:'<AdminPassword>' \
-X DELETE "http://{MS_IP}:8080/v1/analytics/groups/ax/{ax_group}/servers?uuid={QPID_UUID}&type=qpid-server"

Annulez l'enregistrement du serveur Qpid à partir de l'installation Edge :

curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers \
-d "type=qpid-server&region=dc-1&pod=central&uuid={QPID_UUID}&action=remove"

Supprimez le serveur Qpid de l'installation Edge :

curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID

Redémarrez tous les composants edge-qpid-server sur tous les nœuds pour vous assurer que la modification est prise en compte par ces composants :

$ /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
$ /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server wait_for_ready

Désinstallez edge-qpid-server et apigee-qpidd :

$ /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server uninstall
$ /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall

Postgres et Postgresql

Le centre de données que vous mettez hors service peut comporter un maître ou un standby Postgres. Les sections suivantes expliquent comment les mettre hors service :

Mise hors service du nœud maître Postgres
Mise hors service du Postgres de secours

Attention : Vous devez supprimer et ajouter des serveurs PostgreSQL du groupe "analytics" et du groupe "consumer" en même temps. Vous risquez de perdre des données analytiques si le délai entre les deux étapes est important.

Suggestion : Le processeur de messages dispose d'une petite file d'attente dans laquelle il conserve les données analytiques en mémoire pendant une courte période, ce qui peut vous aider à éviter de perdre des données. Avant de modifier le groupe "analytics", bloquez le port 5672 dans le centre de données qui reçoit le trafic, puis assurez-vous de le réactiver rapidement après avoir effectué les modifications, car il existe un risque de dépassement de données.

Par exemple, pour arrêter temporairement le trafic d'analyse des processeurs de messages vers le serveur Qpid :

Saisissez la commande suivante :

iptables -A INPUT -p tcp --destination-port 5672 ! -s `hostname` -i eth0 -j DROP

Suivez les étapes pour modifier axgroup.
Supprimez la règle iptable après les modifications apportées à axgroup :
```
iptables -F
```

Mise hors service du nœud maître Postgres

Remarque : Si vous mettez hors service le maître Postgres, veillez à promouvoir l'un des nœuds de secours disponibles en tant que nouveau maître Postgres. Bien que les files d'attente QPID mettent les données en mémoire tampon, vous risquez de perdre des données analytiques si le maître Postgres n'est pas disponible pendant une longue période.

Pour mettre hors service le nœud maître Postgres :

Sauvegardez le nœud maître Postgres dc-1 en suivant les instructions des liens suivants :
- Sauvegarder et restaurer
- Sauvegarder vos données
Obtenez les UUID des serveurs Postgres, comme décrit dans Obtenir les UUID.

Sur dc-1, arrêtez edge-postgres-server et apigee-postgresql sur le maître actuel :

/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop

Sur le nœud de secours de dc-2, saisissez la commande suivante pour en faire le nœud maître :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql promote-standby-to-master <IP of OLD Progress master>
```
Remarque : Si vous avez plusieurs nœuds Postgres de secours, vous devez ajouter des entrées d'hôte sur le nouveau nœud maître et mettre à jour le paramètre de réplication pour tous les nœuds Postgres de secours disponibles.

Pour ajouter des entrées d'hôte au nouveau maître Postgres, suivez les étapes de la section appropriée ci-dessous :

S'il ne reste qu'un seul nœud de secours

Par exemple, supposons que trois nœuds Postgres étaient configurés avant la mise hors service. Vous avez mis hors service le maître existant et promu l'un des nœuds de secours PostgreSQL restants en tant que maître. Configurez le nœud de secours restant en procédant comme suit :
1. Sur le nouveau maître, modifiez le fichier de configuration pour définir les éléments suivants :
```
PG_MASTER=IP_or_DNS_of_new_PG_MASTER
PG_STANDBY=IP_or_DNS_of_PG_STANDBY
```
2. Activez la réplication sur la nouvelle instance maître :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFIle
```
S'il reste plusieurs nœuds de secours
1. Ajoutez la configuration suivante dans /opt/apigee/customer/application/postgresql.properties :
```
conf_pg_hba_replication.connection=host replication apigee standby_1_ip/32 trust \n host replication apigee standby_2_ip/32 trust
```
2. Assurez-vous que le fichier /opt/apigee/customer/application/postgresql.properties appartient à l'utilisateur apigee :
```
chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
```
3. Redémarrez apigee-postgresql :
```
apigee-service apigee-postgresql restart
```
4. Vérifiez que le maître Postgres est correctement configuré en saisissant la commande suivante dans dc-2 :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
5. Supprimez et ajoutez des serveurs PostgreSQL au groupe "analytics" et au groupe "consumer".
  Attention : Effectuez les deux prochaines étapes ensemble, car vous risquez de perdre des données analytiques entre les deux étapes.
  1. Supprimez l'ancien serveur Postgres du groupe "analytics" en suivant les instructions de la section Supprimer un serveur Postgres d'un groupe "analytics".
  2. Ajoutez un serveur Postgres au groupe "analytics" en suivant les instructions de la section Ajouter un serveur Postgres existant à un groupe "analytics".
6. Annulez l'enregistrement de l'ancien serveur postgres depuis dc-1 :
```
curl -u <AdminEmailID>:<AdminPassword> -X POST http://{MS_IP}:8080/v1/servers \
-d "type=postgres-server®ion=dc-1&pod=analytics&uuid=UUID&action=remove"
      
```
7. Supprimez l'ancien serveur PostgreSQL de dc-1 :
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
```
8. Vous pouvez maintenant mettre hors service l'ancien maître Postgres sans risque. Désinstallez edge-postgres-server et apigee-postgresql :
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server uninstall
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql uninstall
```
Mise hors service du Postgres de secours

Remarque : La documentation pour une installation en cluster de 12 nœuds montre que le nœud postgresql dc-1 est maître, mais pour plus de commodité, dans cette section, il est supposé que le nœud postgresql dc-1 est un nœud de secours et que le nœud postgresql dc-2 est maître.

Pour mettre hors service le Postgres de secours, procédez comme suit :
1. Obtenez les UUID des serveurs Postgres en suivant les instructions de la section Obtenir les UUID.
2. Arrêtez apigee-postgresql sur le nœud de secours actuel dans dc-1 :
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
```
3. Supprimez et ajoutez des serveurs PostgreSQL au groupe "analytics" et au groupe "consumer".
  Attention : Effectuez les deux prochaines étapes ensemble, car vous risquez de perdre des données analytiques entre les deux étapes.
  1. Supprimez l'ancien serveur Postgres du groupe "analytics" en suivant les instructions de la section Supprimer un serveur Postgres d'un groupe "analytics".
  2. Ajoutez un serveur Postgres au groupe "analytics" en suivant les instructions de la section Ajouter un serveur Postgres existant à un groupe "analytics".
4. Annulez l'enregistrement de l'ancien serveur postgres depuis dc-1 :
```
curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers \
-d "type=postgres-server&region=dc-1&pod=analytics&uuid=UUID&action=remove"
```
5. Supprimez l'ancien serveur PostgreSQL de dc-1 :
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
```
6. Vous pouvez maintenant mettre hors service l'ancien maître Postgres sans risque. Désinstallez edge-postgres-server et apigee-postgresql :
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server uninstall
```
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql uninstall
```
ZooKeeper et Cassandra

Cette section explique comment mettre hors service les serveurs ZooKeeper et Cassandra dans une configuration à deux centres de données.

Si vous avez plus de deux centres de données, veillez à supprimer toutes les références au nœud mis hors service (dc-1 dans ce cas) de tous les fichiers de configuration silencieux dans tous les centres de données restants. Dans le cas des nœuds Cassandra à mettre hors service, supprimez ces hôtes de CASS_HOSTS. Les nœuds Cassandra restants doivent conserver l'ordre d'origine de CASS_HOSTS.

Remarque concernant ZooKeeper : Vous devez maintenir un quorum de nœuds votants pendant que vous modifiez la propriété ZK_HOST dans le fichier de configuration, afin de vous assurer que l'ensemble ZooKeeper reste fonctionnel. Votre configuration doit comporter un nombre impair de nœuds votants. Pour en savoir plus, consultez Tâches de maintenance Apache ZooKeeper.

Attention : Si vous mettez hors service un centre de données qui comporte un nœud ZooKeeper principal, il y aura un temps d'arrêt.

Pour mettre hors service les serveurs ZooKeeper et Cassandra :
1. Sauvegardez les nœuds Cassandra et ZooKeeper dc-1 en suivant les instructions des liens suivants :
  - Sauvegarder et restaurer
  - Sauvegarder vos données
  Remarque : Si vous avez plusieurs nœuds ZooKeeper, sauvegardez-les un par un. Le processus de sauvegarde arrête temporairement ZooKeeper.
2. Listez les UUID des serveurs ZooKeeper et Cassandra dans le centre de données où les nœuds Cassandra vont être mis hors service.
```
apigee-adminapi.sh servers list -r dc-1 -p central -t application-datastore --admin <AdminEmailID> --pwd '<AdminPassword>' --host localhost
```
3. Annulez l'enregistrement du type de serveur :
```
curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://MS_IP:8080/v1/servers -d "type=cache-datastore&type=user-settings-datastore&type=scheduler-datastore&type=audit-datastore&type=apimodel-datastore&type=application-datastore&type=edgenotification-datastore&type=identityzone-datastore&type=user-settings-datastore&type=auth-datastore&region=dc-1&pod=central&uuid=UUID&action=remove"
```
4. Annulez l'enregistrement du serveur :
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MS_IP:8080/v1/servers/UUID
```
5. Mettez à jour le fichier de configuration en supprimant les adresses IP des nœuds mis hors service de ZK_HOSTS et CASS_HOSTS.
  Remarques :
  - Vous devez maintenir un quorum de nœuds votants pendant que vous modifiez la propriété ZK_HOST dans le fichier de configuration, pour vous assurer que l'ensemble ZooKeeper reste fonctionnel. Votre configuration doit comporter un nombre impair de nœuds votants. Consultez À propos de ZooKeeper et Edge.
  - Pour les nœuds Cassandra à mettre hors service, supprimez ces hôtes de CASS_HOSTS. Les nœuds Cassandra restants doivent conserver l'ordre d'origine de CASS_HOSTS.
  - Les nœuds observateurs ZooKeeper ne participent pas au vote et ne sont pas pris en compte lors de la détermination d'un quorum.
  Exemple : Supposons que vous disposiez des adresses IP $IP1 $IP2 $IP3 dans dc-1 et $IP4 $IP5 $IP6 dans dc-2, et que vous mettiez dc-1 hors service. Vous devez ensuite supprimer les adresses IP $IP1 $IP2 $IP3 des fichiers de configuration.
  - Entrées existantes dans le fichier de configuration :
```
ZK_HOSTS="$IP1 $IP2 $IP3 $IP4 $IP5 $IP6"
CASS_HOSTS="$IP1:1,1 $IP2:1,1 $IP3:1,1, $IP4:2,1 $IP5:2,1 $IP6:2,1”
```
  - Nouvelles entrées du fichier de configuration :
```
ZK_HOSTS="$IP4 $IP5 $IP6"
CASS_HOSTS="$IP4:2,1 $IP5:2,1 $IP6:2,1"
```
6. Mettez à jour le fichier de configuration silencieux (modifié à l'étape e) avec les adresses IP des nœuds mis hors service supprimés et exécutez le profil du serveur de gestion sur tous les nœuds hébergeant des serveurs de gestion :
```
/opt/apigee/apigee-setup/bin/setup.sh -p ms -f updated_config_file
```
7. Mettez à jour le fichier de configuration avec les adresses IP des nœuds mis hors service supprimés, puis exécutez le profil MP/RMP sur tous les nœuds Routeur et Processeur de messages :
  - Si le routeur Edge et le processeur de messages sont configurés sur le même nœud, saisissez :
```
/opt/apigee/apigee-setup/bin/setup.sh -p rmp -f updated_config_file
```
  - Si le routeur Edge et le processeur de messages sont configurés sur des nœuds distincts, saisissez ce qui suit :
    
    Pour le routeur :
```
/opt/apigee/apigee-setup/bin/setup.sh -p r -f updated_config_file
```
    Pour le processeur de messages :
```
/opt/apigee/apigee-setup/bin/setup.sh -p mp -f updated_config_file
```
8. Reconfigurez tous les nœuds Qpid en supprimant les adresses IP des nœuds mis hors service du fichier de réponses :
```
/opt/apigee/apigee-setup/bin/setup.sh -p qs -f updated_config_file
```
9. Reconfigurez tous les nœuds Postgres en supprimant les adresses IP des nœuds mis hors service du fichier de réponse :
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f updated_config_file
```
10. Modifiez l'espace de clés system_auth. Si l'authentification Cassandra est activée sur un nœud Cassandra existant, mettez à jour le facteur de réplication de l'espace de clés system_auth en exécutant la commande suivante :
```
ALTER KEYSPACE system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-2': '3'};
```
  Cette commande définit le facteur de réplication sur '3', ce qui indique qu'il y a trois nœuds Cassandra dans le cluster. Modifiez cette valeur si nécessaire.
  
  Une fois cette étape terminée, la topologie Cassandra ne doit plus contenir dc-1 dans aucun espace de clés.
11. Mettez hors service les nœuds Cassandra sur dc-1, un par un.
  Remarque : Les nœuds mis hors service contiennent toujours Cassandra avec des informations de seed du cluster d'origine. Si le service Cassandra se met à démarrer par hasard, les nœuds mis hors service rejoindront l'anneau du cluster. Pour éviter cela, assurez-vous de désinstaller le composant Cassandra après la mise hors service et n'autorisez aucun nœud mis hors service à devenir opérationnel et à rejoindre le cluster.
  
  Pour mettre hors service les nœuds Cassandra, saisissez la commande suivante :
```
/opt/apigee/apigee-cassandra/bin/nodetool -h cassIP -u cassandra -pw '<AdminPassword>' decommission
```
  Remarque : Si un nœud est bloqué dans un état de mise hors service, vous pouvez utiliser Cassandra nodetool removenode pour le supprimer. Exemple :
```
/opt/apigee/apigee-cassandra/bin/nodetool removenode UUID
```
12. Vérifiez la connexion des nœuds Cassandra depuis dc-1 à l'aide de l'une des commandes suivantes :
```
/opt/apigee/apigee-cassandra/bin/cqlsh cassIP 9042 -u cassandra -p '<AdminPassword>'
```
  Ou exécutez la commande de validation secondaire sur le nœud mis hors service :
```
/opt/apigee/apigee-cassandra/bin/nodetool netstats
```
  La commande ci-dessus doit renvoyer :
```
Mode: DECOMMISSIONED
```
13. Exécutez le profil DS pour tous les nœuds Cassandra et ZooKeeper dans dc-2 :
```
/opt/apigee/apigee-setup/bin/setup.sh -p ds -f updated_config_file
```
14. Arrêtez apigee-cassandra et apigee-zookeeper dans dc-1 :
```
apigee-service apigee-cassandra stop
apigee-service apigee-zookeeper stop
```
15. Désinstallez apigee-cassandra et apigee-zookeeper dans dc-1 :
```
apigee-service apigee-cassandra uninstall
apigee-service apigee-zookeeper uninstall
```
Supprimer les liaisons de dc-1

Pour supprimer les liaisons de dc-1, procédez comme suit :
1. Supprimez les liaisons de dc-1.
  1. Listez tous les pods disponibles dans l'organisation :
```
curl -v -u  <AdminEmailID>:'<AdminPassword>' -X GET "http://MS_IP:8080/v1/o/ORG/pods"
```
  2. Pour vérifier que toutes les liaisons ont été supprimées, obtenez les UUID des serveurs associés aux pods :
```
curl -v -u  <AdminEmailID>:'<AdminPassword>' \
-X GET "http://MS_IP:8080/v1/regions/dc-1/pods/gateway-1/servers"
```
    Si cette commande ne renvoie aucun UUID, cela signifie que les étapes précédentes ont supprimé toutes les liaisons et que vous pouvez ignorer l'étape suivante. Sinon, passez à l'étape suivante.
  3. Supprimez toutes les liaisons de serveur pour les UUID obtenus à l'étape précédente :
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MS_IP:8080/v1/servers/UUID
```
  4. Dissociez l'organisation du pod :
```
curl -v -u  <AdminEmailID>:'<AdminPassword>'  "http://MS_IP:8080/v1/o/ORG/pods" -d "action=remove&region=dc-1&pod=gateway-1" -H "Content-Type: application/x-www-form-urlencoded" -X POST
```
2. Supprimez les pods :
```
curl -v -u <AdminEmailID>:'<AdminPassword>' "http://MS_IP:8080/v1/regions/dc-1/pods/gateway-1" -X DELETE
```
3. Supprimez la région.
```
curl -v -u <AdminEmailID>:'<AdminPassword>'  "http://MS_IP:8080/v1/regions/dc-1" -X DELETE
```
Remarque : Si vous oubliez de supprimer l'un des serveurs, l'étape ci-dessus renverra un message d'erreur indiquant qu'un serveur particulier du pod existe toujours. Dans ce cas, supprimez-le en suivant les étapes de dépannage ci-dessous, tout en personnalisant le type dans la commande curl.

À ce stade, vous avez terminé la mise hors service de dc-1.

Annexe

Dépannage

Si, après avoir effectué les étapes précédentes, il reste des serveurs dans certains pods, suivez les étapes ci-dessous pour annuler leur enregistrement et les supprimer. Remarque : Modifiez les types et le pod si nécessaire.
1. Obtenez les UUID à l'aide de la commande suivante :
```
apigee-adminapi.sh servers list -r dc-1 -p POD -t  --admin <AdminEmailID> --pwd  '<AdminPassword>’ --host localhost
```
2. Annulez l'enregistrement du type de serveur :
```
curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://MP_IP:8080/v1/servers -d "type=TYPE=REGION=dc-1&pod=POD&uuid=UUID&action=remove"
```
3. Supprimez les serveurs un par un :
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MP_IP:8080/v1/servers/UUID
```
Validation

Vous pouvez valider la mise hors service à l'aide des commandes suivantes.

Serveur de gestion
1. Exécutez les commandes suivantes à partir des serveurs de gestion dans toutes les régions.
```
curl -v -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/servers?pod=central&region=dc-1
curl -v -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/servers?pod=gateway&region=dc-1
curl -v -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/servers?pod=analytics&region=dc-1
```
2. Exécutez la commande suivante sur tous les composants pour vérifier les exigences de port pour tous les ports de gestion.
```
curl -v http://MS_IP:8080/v1/servers/self
```
3. Vérifiez le groupe "analytics".
```
curl -v  -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/o/ORG/e/ENV/provisioning/axstatus
curl -v  -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/analytics/groups/ax
```

Mettre un centre de données hors service

Éléments à prendre en compte avant de mettre hors service un centre de données

Avant de commencer

Prérequis

Ordre de mise hors service des composants

Interface utilisateur Edge

Serveur de gestion

Symas LDAP

Routeur

Processeur de messages

Serveur Qpid et Qpidd

Postgres et Postgresql

Mise hors service du nœud maître Postgres

S'il ne reste qu'un seul nœud de secours

S'il reste plusieurs nœuds de secours

Mise hors service du Postgres de secours

ZooKeeper et Cassandra

Supprimer les liaisons de dc-1

Annexe

Dépannage

Validation

Serveur de gestion

Nœuds Cassandra/ZooKeeper

Journaux