Retirar un centro de datos

A veces, es posible que debas dar de baja un centro de datos. Por ejemplo, si actualizas tu sistema operativo, debes instalar el nuevo sistema operativo en un centro de datos nuevo y, luego, dar de baja el centro de datos anterior. En las siguientes secciones, se presenta un ejemplo de baja de un centro de datos, en el que hay dos centros de datos, dc-1 y dc-2, en una instalación en clúster de 12 nodos:

  • dc-1 es el centro de datos que se retirará.
  • dc-2 es un segundo centro de datos que se usa en el procedimiento de baja.

Si actualizas tu sistema operativo, dc-2 podría ser el centro de datos en el que instalaste la nueva versión del sistema operativo (SO). Sin embargo, no es necesario instalar un SO nuevo para dar de baja un centro de datos.

Consideraciones antes de dar de baja un centro de datos

Ten en cuenta las siguientes consideraciones cuando desactives un centro de datos:

  • Bloquea todo el tráfico de administración y de tiempo de ejecución hacia el centro de datos que se está dando de baja y redirígelo a otros centros de datos.
  • Después de dar de baja el centro de datos, tendrás una capacidad reducida en tu clúster de Apigee. Para compensar esto, considera aumentar la capacidad en los centros de datos restantes o agregar centros de datos después de la baja.
  • Durante el proceso de baja, existe la posibilidad de que se pierdan datos de Analytics, según los componentes de Analytics que estén instalados en el centro de datos que se da de baja. Puedes encontrar más detalles en Cómo agregar o quitar nodos de Qpid.
  • Antes de retirar un centro de datos, debes comprender cómo se configuran todos los componentes en todos los centros de datos, en especial los servidores de SymasLDAP, ZooKeeper, Cassandra y Postgres. También debes crear copias de seguridad de todos los componentes y sus configuraciones.

Antes de comenzar

  • Servidor de administración: Todos los pasos de baja dependen en gran medida del servidor de administración. Si solo tienes un servidor de administración disponible, te recomendamos que instales un nuevo componente del servidor de administración en un centro de datos que no sea dc-1 antes de retirar el servidor de administración en dc-1 y asegúrate de que uno de los servidores de administración esté siempre disponible.
  • Router: Antes de retirar un router, inhabilita la accesibilidad de los routers bloqueando el puerto 15999. Asegúrate de que no se dirija tráfico de tiempo de ejecución a los routers que se dan de baja.
  • Cassandra y ZooKeeper: En las siguientes secciones, se describe cómo retirar dc-1 en una configuración de dos centros de datos.

    Si tienes más de dos centros de datos, asegúrate de quitar todas las referencias al nodo que se está retirando (dc-1 en este caso) de todos los archivos de configuración silenciosa en todos los centros de datos restantes. En el caso de los nodos de Cassandra que se deben inhabilitar, quita esos hosts de CASS_HOSTS. Los nodos de Cassandra restantes deben permanecer en el orden original de CASS_HOSTS.

  • Postgres: Si das de baja el servidor principal de Postgres, asegúrate de promover uno de los nodos en espera disponibles como un nuevo servidor principal de Postgres. Si bien el servidor de QPID mantiene un búfer en la cola, si el servidor principal de Postgres no está disponible durante un período más prolongado, corres el riesgo de perder datos de análisis.

Requisitos previos

  • Antes de retirar cualquier componente, te recomendamos que realices una copia de seguridad completa de todos los nodos. Usa el procedimiento para tu versión actual de Edge para realizar la copia de seguridad. Para obtener más información sobre las copias de seguridad, consulta Copia de seguridad y restablecimiento.

  • Antes de retirar Edge, asegúrate de que esté en funcionamiento con el siguiente comando:
    /opt/apigee/apigee-service/bin/apigee-all status
  • Asegúrate de que no llegue tráfico de tiempo de ejecución al centro de datos que estás dando de baja.

Orden de baja de los componentes

Si instalas Edge para la nube privada en varios nodos, debes retirar los componentes de Edge en esos nodos en el siguiente orden:

  1. IU de Edge (edge-ui)
  2. Servidor de administración (edge-management-server)
  3. LDAP de Symas (apigee-openldap)
  4. Router (router perimetral)
  5. Message Processor (edge-message-processor)
  6. Servidor Qpid y Qpidd (edge-qpid-server y apigee-qpidd)
  7. Bases de datos Postgres y PostgreSQL (edge-postgres-server y apigee-postgresql)
  8. ZooKeeper (apigee-zookeeper)
  9. Cassandra (apigee-cassandra)

En las siguientes secciones, se explica cómo retirar cada componente.

IU de Edge

Para detener y desinstalar el componente de IU de Edge de dc-1, ingresa los siguientes comandos:

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

Servidor de administración

Para retirar el servidor de administración en dc-1, sigue estos pasos:

  1. Detén el servidor de administración en dc-1:
    apigee-service edge-management-server stop
  2. Busca el UUID del servidor de administración registrado en dc-1:
    curl -u <AdminEmailID>:'<AdminPassword>' -X GET “http://{MS_IP}:8080/v1/servers?pod=central&region=dc-1&type=management-server”
  3. Tipo de servidor para cancelar el registro:
    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"
  4. Borra el servidor. Nota: Si también hay otros componentes instalados en este servidor, primero anula el registro de todos ellos antes de borrar el UUID.
    curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/{UUID}
  5. Desinstala el componente del servidor de administración en dc-1:
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server uninstall

LDAP de Symas

En esta sección, se explica cómo retirar SymasLDAP en dc-1.

Nota: Si tienes más de dos centros de datos, consulta la sección Configuraciones con más de dos centros de datos a continuación.

Para retirar SymasLDAP en dc-1, sigue estos pasos:

  1. Sigue los pasos que se indican en Cómo crear una copia de seguridad para crear una copia de seguridad del nodo dc-1 de SymasLDAP.
  2. Para interrumpir la replicación de datos entre los dos centros de datos, dc-1 y dc-2, ejecuta los siguientes pasos en ambos centros de datos.

    1. Verifica el estado actual:
            /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

      El resultado debería ser similar al siguiente ejemplo:

      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. Crea un archivo break_repl.ldif que contenga los siguientes comandos:
      dn: olcDatabase={2}mdb,cn=config
      changetype: modify
      delete: olcSyncRepl
      
      dn: olcDatabase={2}mdb,cn=config
      changetype: modify
      delete: olcMirrorMode
    3. Ejecuta el comando ldapmodify:
            /opt/symas/bin/ldapmodify -x -w {credentials} -D "cn=admin,cn=config" -H "ldap://{HOST}:{PORT}/" -f path/to/file/break_repl.ldif

      El resultado debería ser similar al siguiente ejemplo:

      modifying entry "olcDatabase={2}mdb,cn=config"
      modifying entry "olcDatabase={2}mdb,cn=config"
  3. Para verificar que dc-2 ya no se replica en dc-1, crea una entrada en el LDAP de dc-2 y asegúrate de que no aparezca en el LDAP de dc-1.

    De manera opcional, puedes seguir los pasos que se indican a continuación, que crean un usuario de solo lectura en el nodo dc-2 de SymasLDAP y, luego, verifican si el usuario se replicó o no. Luego, se borra al usuario.

    1. Crea un archivo readonly-user.ldif en dc-2 con el siguiente contenido:
      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. Agrega un usuario con el comando "ldapadd" en 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

      El resultado será similar al siguiente:

      adding new entry "uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com"
    3. Busca al usuario en dc-1 para asegurarte de que no se haya replicado. Si el usuario no está presente en dc-1, tendrás la certeza de que ambos LDAP ya no se replican:
      /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

      El resultado debería ser similar al siguiente ejemplo:

      No such object (32)
      Matched DN: ou=users,ou=global,dc=apigee,dc=com
    4. Quita el usuario de solo lectura que agregaste anteriormente:
      /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"
  4. Detén SymasLDAP en dc-1:
    /opt/apigee/apigee-service/bin/apigee-service apigee-openldap stop
  5. Desinstala el componente SymasLDAP en dc-1:
    /opt/apigee/apigee-service/bin/apigee-service apigee-openldap uninstall

Router

En esta sección, se explica cómo retirar un router. Consulta Cómo quitar un servidor para obtener más detalles sobre cómo quitar el router.

En los siguientes pasos, se da de baja el router de dc-1. Si hay varios nodos de Router configurados en dc-1, realiza los pasos en todos los nodos de Router de a uno por vez.

Nota: Aquí se supone que el puerto de verificación de estado 15999 del router está configurado en tu balanceador de cargas y que bloquear el puerto 15999 hará que el router sea inaccesible. Es posible que necesites acceso con permisos de administrador para bloquear el puerto.

Para retirar un router, sigue estos pasos:

  1. Inhabilita la accesibilidad de los routers bloqueando el puerto 15999, el puerto de verificación de estado. Asegúrate de que el tráfico del tiempo de ejecución esté bloqueado en este centro de datos:

    iptables -A INPUT -i eth0 -p tcp --dport 15999 -j REJECT
  2. Verifica que se pueda acceder al router:

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

    El resultado debería ser similar al siguiente ejemplo:

    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
  3. Obtén el UUID del router, como se describe en Cómo obtener UUIDs.
  4. Detén el router:
    /opt/apigee/apigee-service/bin/apigee-service edge-router stop
  5. Enumera los pods de puerta de enlace disponibles en la organización con el siguiente comando:
    curl -u  <AdminEmailID>:'<AdminPassword>' -X GET "http://{MS_IP}:8080/v1/organizations/{ORG}/pods"

    Consulta Acerca de los Pods.

  6. Anula el registro del tipo de servidor:
    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"
  7. Cancela el registro del servidor:
    curl -u <AdminEmailID>:'<AdminPassword>’ -X DELETE http://{MS_IP}:8080/v1/servers/UUID
  8. Desinstala edge-router:
    /opt/apigee/apigee-service/bin/apigee-service edge-router uninstall
    Consulta Cómo quitar un servidor.
  9. Vacía las reglas de iptables para habilitar el puerto 15999 bloqueado:
    iptables -F

Message Processor

En esta sección, se describe cómo retirar el procesador de mensajes de dc-1. Consulta Cómo quitar un servidor para obtener más detalles sobre cómo quitar el procesador de mensajes.

Dado que suponemos que dc-1 tiene una instalación en clúster de 12 nodos, hay dos nodos de Message Processor configurados en dc-1. Ejecuta los siguientes comandos en ambos nodos.

  1. Obtén los UUID de los procesadores de mensajes, como se describe en Obtén los UUID.
  2. Detén el procesador de mensajes:
    apigee-service edge-message-processor stop
  3. Anula el registro del tipo de servidor:
    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"
  4. Desasocia un entorno del procesador de mensajes.
    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"
  5. Anula el registro del tipo de servidor:
    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"
  6. Desinstala el procesador de mensajes:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor uninstall
  7. Cancela el registro del servidor:
    curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID

Servidor Qpid y Qpidd

En esta sección, se explica cómo retirar el servidor Qpid (edge-qpid-server) y Qpidd (apigee-qpidd). Hay dos nodos de Qpid configurados en dc-1, por lo que debes seguir los pasos que se indican a continuación para ambos nodos:

  1. Obtén el UUID de Qpidd, como se describe en Obtén UUIDs.
  2. Detén edge-qpid-server y apigee-qpidd:
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
    /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
  3. Obtén una lista de los grupos de Analytics y de consumidores:
    curl -u <AdminEmailID>:'<AdminPassword>' -X GET http://{MS_IP}:8080/v1/analytics/groups/ax
  4. Quita Qpid del grupo de consumidores:
    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}"
  5. Quita Qpid del grupo de 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"
  6. Cancela el registro del servidor Qpid de la instalación de 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"
  7. Quita el servidor de Qpid de la instalación de Edge:
    curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
  8. Reinicia todos los componentes de edge-qpid-server en todos los nodos para asegurarte de que esos componentes detecten el cambio:
    $ /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
    $ /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server wait_for_ready
  9. Desinstala edge-qpid-server y apigee-qpidd:
    $ /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server uninstall
    $ /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall

Postgres y Postgresql

El centro de datos que das de baja podría tener un servidor principal o un servidor en espera de Postgres. En las siguientes secciones, se explica cómo darlos de baja:

Retiro de la instancia principal de Postgres

Nota: Si das de baja el servidor principal de Postgres, asegúrate de promover uno de los nodos de reserva disponibles como un nuevo servidor principal de Postgres. Si bien las colas de QPID almacenan datos en búfer, si el servidor principal de Postgres no está disponible durante un período prolongado, corres el riesgo de perder datos de análisis.

Para retirar la instancia principal de Postgres, haz lo siguiente:

  1. Sigue las instrucciones de los siguientes vínculos para crear una copia de seguridad del nodo principal de Postgres dc-1:
  2. Obtén los UUID de los servidores de Postgres, como se describe en Obtén los UUID.
  3. En dc-1, detén edge-postgres-server y apigee-postgresql en el servidor principal actual:
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  4. En el nodo en espera de dc-2, ingresa el siguiente comando para convertirlo en el nodo principal:
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql promote-standby-to-master <IP of OLD Progress master>

    Nota: Si tienes más de un nodo de Postgres en espera, debes agregar entradas de host en el nuevo principal y actualizar la configuración de replicación para todos los nodos de Postgres en espera disponibles.

    Para agregar entradas de host al nuevo servidor principal de Postgres, sigue los pasos que se indican en la sección correspondiente a continuación:

    Si solo queda un nodo en espera

    Por ejemplo, supongamos que, antes de la baja, había tres nodos de Postgres configurados. Diste de baja la instancia principal existente y promoviste uno de los nodos de espera de Postgres restantes a la instancia principal. Para configurar el nodo en espera restante, sigue estos pasos:

    1. En el nuevo servidor principal, edita el archivo de configuración para establecer lo siguiente:
      PG_MASTER=IP_or_DNS_of_new_PG_MASTER
      PG_STANDBY=IP_or_DNS_of_PG_STANDBY
    2. Habilita la replicación en el nuevo principal:
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFIle

    Si queda más de un nodo en espera

    1. Agrega la siguiente configuración en /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. Asegúrate de que el archivo /opt/apigee/customer/application/postgresql.properties sea propiedad del usuario apigee:
      chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
    3. Reinicia apigee-postgresql:
      apigee-service apigee-postgresql restart
    4. Para actualizar la configuración de replicación en un nodo en espera, haz lo siguiente:

      1. Modifica el archivo de configuración /opt/silent.conf y actualiza el campo PG_MASTER con la dirección IP de la nueva instancia principal de Postgres.
      2. Quita los datos antiguos de Postgres con el siguiente comando:
        rm -rf /opt/apigee/data/apigee-postgresql/
      3. Configura la replicación en el nodo en espera:
        /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    5. Para verificar que el servidor principal de Postgres esté configurado correctamente, ingresa el siguiente comando en dc-2:
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
    6. Quita y agrega servidores de PostgreSQL del grupo de Analytics y del grupo de consumidores.
      1. Quita el servidor de Postgres anterior del grupo de Analytics siguiendo las instrucciones que se indican en Cómo quitar un servidor de Postgres de un grupo de Analytics.
      2. Agrega un nuevo servidor de Postgres al grupo de Analytics siguiendo las instrucciones que se indican en Agrega un servidor de Postgres existente a un grupo de Analytics.
    7. Cancela el registro del servidor de Postgres anterior de 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"
            
    8. Borra el servidor postgres anterior de dc-1:
      curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
    9. Ahora es seguro retirar el servidor principal de Postgres anterior. Desinstala edge-postgres-server y apigee-postgresql:
      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server uninstall
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql uninstall

    Retiro de la instancia de espera de Postgres

    Nota: La documentación de una instalación en clúster de 12 nodos muestra el nodo dc-1 postgresql como principal, pero, para mayor comodidad, en esta sección se supone que el nodo dc-1 postgresql es de reserva y el nodo dc-2 postgresql es principal.

    Para retirar el servidor de espera de Postgres, sigue estos pasos:

    1. Obtén los UUID de los servidores de PostgreSQL siguiendo las instrucciones en Obtén UUID.
    2. Detén apigee-postgresql en el nodo en espera actual en dc-1:
      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
    3. Quita y agrega servidores de PostgreSQL del grupo de Analytics y del grupo de consumidores.
      1. Quita el servidor de Postgres anterior del grupo de Analytics siguiendo las instrucciones que se indican en Cómo quitar un servidor de Postgres de un grupo de Analytics.
      2. Agrega un nuevo servidor de Postgres al grupo de Analytics siguiendo las instrucciones que se indican en Agrega un servidor de Postgres existente a un grupo de Analytics.
    4. Cancela el registro del servidor de Postgres anterior de 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. Borra el servidor postgres anterior de dc-1:
      curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
    6. Ahora es seguro retirar el servidor principal de Postgres anterior. Desinstala edge-postgres-server y apigee-postgresql:
      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server uninstall
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql uninstall

    ZooKeeper y Cassandra

    En esta sección, se explica cómo retirar los servidores de ZooKeeper y Cassandra en una configuración de dos centros de datos.

    Si tienes más de dos centros de datos, asegúrate de quitar todas las referencias al nodo que se está retirando (dc-1 en este caso) de todos los archivos de configuración silenciosa en todos los centros de datos restantes. En el caso de los nodos de Cassandra que se deben inhabilitar, quita esos hosts de CASS_HOSTS. Los nodos de Cassandra restantes deben permanecer en el orden original de CASS_HOSTS.

    Nota sobre ZooKeeper: Debes mantener un quórum de nodos de votación mientras modificas la propiedad ZK_HOST en el archivo de configuración para garantizar que el conjunto de ZooKeeper siga funcionando. Debes tener una cantidad impar de nodos de votación en tu configuración. Para obtener más información, consulta Tareas de mantenimiento de Apache ZooKeeper.

    Para retirar los servidores de ZooKeeper y Cassandra, haz lo siguiente:

    1. Realiza una copia de seguridad de los nodos de Cassandra y ZooKeeper de dc-1 siguiendo las instrucciones que se indican en los siguientes vínculos:
    2. Enumera los UUID de los servidores de ZooKeeper y Cassandra en el centro de datos donde se inhabilitarán los nodos de Cassandra.

      apigee-adminapi.sh servers list -r dc-1 -p central -t application-datastore --admin <AdminEmailID> --pwd '<AdminPassword>' --host localhost
    3. Anula el registro del tipo de servidor:
      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. Cancela el registro del servidor:
      curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MS_IP:8080/v1/servers/UUID
    5. Actualiza el archivo de configuración con las IPs de los nodos retirados que se quitaron de ZK_HOSTS y CASS_HOSTS.

      Ejemplo: Supongamos que tienes las IPs $IP1 $IP2 $IP3 en dc-1 y $IP4 $IP5 $IP6 en dc-2, y que estás retirando dc-1. Luego, debes quitar las IPs $IP1 $IP2 $IP3 de los archivos de configuración.

      • Entradas existentes del archivo de configuración:
        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”
      • Nuevas entradas de archivos de configuración:
        ZK_HOSTS="$IP4 $IP5 $IP6"
        CASS_HOSTS="$IP4:2,1 $IP5:2,1 $IP6:2,1"
    6. Actualiza el archivo de configuración silenciosa (modificado en el paso e) con las IPs de los nodos retirados y ejecuta el perfil del servidor de administración en todos los nodos que alojan servidores de administración:
      /opt/apigee/apigee-setup/bin/setup.sh -p ms -f updated_config_file
    7. Actualiza el archivo de configuración con las IPs de los nodos retirados y ejecuta el perfil de MP/RMP en todos los nodos de Router y Message Processor:
      • Si Edge Router y Message Processor están configurados en el mismo nodo, ingresa lo siguiente:
        /opt/apigee/apigee-setup/bin/setup.sh -p rmp -f updated_config_file
      • Si Edge Router y Message Processor están configurados en nodos separados, ingresa lo siguiente:

        Para el router:

        /opt/apigee/apigee-setup/bin/setup.sh -p r -f updated_config_file

        Para el procesador de mensajes, haz lo siguiente:

        /opt/apigee/apigee-setup/bin/setup.sh -p mp -f updated_config_file
    8. Vuelve a configurar todos los nodos de Qpid y quita las IPs de los nodos retirados del archivo de respuesta:
      /opt/apigee/apigee-setup/bin/setup.sh -p qs -f updated_config_file
    9. Vuelve a configurar todos los nodos de Postgres, con las IPs de los nodos retirados quitadas del archivo de respuesta:
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f updated_config_file
    10. Modifica el keyspace system_auth. Si tienes habilitada la autenticación de Cassandra en un nodo de Cassandra existente, actualiza el factor de replicación del espacio de claves system_auth ejecutando el siguiente comando:
      ALTER KEYSPACE system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-2': '3'};

      Este comando establece el factor de replicación en '3', lo que indica que hay tres nodos de Cassandra en el clúster. Modifica este valor según sea necesario.

      Después de completar este paso, la topología de Cassandra no debería tener dc-1 en ninguno de los espacios de claves.

    11. Inhabilita los nodos de Cassandra en dc-1, uno por uno.

      Para retirar los nodos de Cassandra, ingresa el siguiente comando:

      /opt/apigee/apigee-cassandra/bin/nodetool -h cassIP -u cassandra -pw '<AdminPassword>' decommission
    12. Verifica la conexión de los nodos de Cassandra desde dc-1 con uno de los siguientes comandos:
      /opt/apigee/apigee-cassandra/bin/cqlsh cassIP 9042 -u cassandra -p '<AdminPassword>'

      O bien, el comando de verificación secundaria que se ejecutará en el nodo retirado:

      /opt/apigee/apigee-cassandra/bin/nodetool netstats

      El comando anterior debería mostrar lo siguiente:

      Mode: DECOMMISSIONED
    13. Ejecuta el perfil de DS para todos los nodos de Cassandra y ZooKeeper en dc-2:
      /opt/apigee/apigee-setup/bin/setup.sh -p ds -f updated_config_file
    14. Detén apigee-cassandra y apigee-zookeeper en dc-1:
      apigee-service apigee-cassandra stop
      apigee-service apigee-zookeeper stop
    15. Desinstala apigee-cassandra y apigee-zookeeper en dc-1:
      apigee-service apigee-cassandra uninstall
      apigee-service apigee-zookeeper uninstall

    Borra las vinculaciones de dc-1

    Para borrar las vinculaciones de dc-1, sigue estos pasos:

    1. Borra las vinculaciones de dc-1.
      1. Enumera todos los Pods disponibles en la organización:
        curl -v -u  <AdminEmailID>:'<AdminPassword>' -X GET "http://MS_IP:8080/v1/o/ORG/pods"
      2. Para verificar si se quitaron todas las vinculaciones, obtén los UUID de los servidores asociados con los pods:
        curl -v -u  <AdminEmailID>:'<AdminPassword>' \
        -X GET "http://MS_IP:8080/v1/regions/dc-1/pods/gateway-1/servers"

        Si este comando no devuelve ningún UUID, los pasos anteriores quitaron todas las vinculaciones, por lo que puedes omitir el siguiente paso. De lo contrario, realiza el siguiente paso.

      3. Quita todas las vinculaciones del servidor para los UUID que obtuviste en el paso anterior:
        curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MS_IP:8080/v1/servers/UUID
      4. Desvincula la organización del 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. Borra los Pods:
      curl -v -u <AdminEmailID>:'<AdminPassword>' "http://MS_IP:8080/v1/regions/dc-1/pods/gateway-1" -X DELETE
    3. Borra la región.
      curl -v -u <AdminEmailID>:'<AdminPassword>'  "http://MS_IP:8080/v1/regions/dc-1" -X DELETE

    En este punto, completaste la baja del servidor dc-1.

    Apéndice

    Solución de problemas

    Si, después de realizar los pasos anteriores, aún hay servidores en algunos pods, sigue estos pasos para anular el registro y borrar los servidores. Nota: Cambia los tipos y el pod según sea necesario.

    1. Obtén los UUID con el siguiente comando:
      apigee-adminapi.sh servers list -r dc-1 -p POD -t  --admin <AdminEmailID> --pwd  '<AdminPassword>’ --host localhost
    2. Tipo de servidor para cancelar el registro:
      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. Borra los servidores uno por uno:
      curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MP_IP:8080/v1/servers/UUID

    Validación

    Puedes validar la baja con los siguientes comandos.

    Servidor de administración

    1. Ejecuta los siguientes comandos desde los servidores de administración en todas las regiones.
      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. Ejecuta el siguiente comando en todos los componentes para verificar los requisitos de puertos para todos los puertos de administración.
      curl -v http://MS_IP:8080/v1/servers/self
    3. Verifica el grupo de análisis.
      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
    4. Nodos de Cassandra/ZooKeeper

      1. En todos los nodos de Cassandra, ingresa lo siguiente:
        /opt/apigee/apigee-cassandra/bin/nodetool -h <host> statusthrift

        Esto devolverá un estado running o not running para ese nodo en particular.

      2. En un nodo, ingresa lo siguiente:
        /opt/apigee/apigee-cassandra/bin/nodetool -h <host> ring
        /opt/apigee/apigee-cassandra/bin/nodetool -h <host> status

        Los comandos anteriores mostrarán información sobre los centros de datos activos.

      3. En los nodos de ZooKeeper, primero ingresa lo siguiente:
        echo ruok | nc <host> 2181
        

        Este comando devuelve imok.

        A continuación, ingresa lo siguiente:

        echo stat | nc <host> 2181 | grep Mode
        

        El valor de Mode que devuelve el comando anterior será uno de los siguientes: observer, leader o follower.

      4. En un nodo de ZooKeeper, ejecuta lo siguiente:
        /opt/apigee/apigee-zookeeper/contrib/zk-tree.sh >> /tmp/zk-tree.out.txt
      5. En el nodo principal de Postgres, ejecuta lo siguiente:
        /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master

        Valida que la respuesta indique que el nodo es el principal.

      6. En el nodo en espera, ejecuta lo siguiente:
        /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

        Asegúrate de que la respuesta confirme que el nodo es el de reserva.

      7. Accede a la base de datos de PostgreSQL con el siguiente comando:
        psql -h localhost -d apigee -U postgres

        Cuando se te solicite, ingresa la contraseña del usuario postgres (predeterminada: postgres).

        Luego, ejecuta la siguiente consulta para verificar el client_received_start_timestamp máximo:

        SELECT max(client_received_start_timestamp) FROM "analytics"."$org.$env.fact" LIMIT 1;

      Registros

      Revisa los registros de los componentes para asegurarte de que no haya errores.