Se usó la API de Cloud Translation para traducir esta página.

Cómo agregar un centro de datos

Edge for Private Cloud v4.18.05

En este documento, se describe cómo agregar un centro de datos (también llamado región) a un centro de datos existente en el centro de atención.

Consideraciones antes de agregar un centro de datos

Antes de instalar un centro de datos, debes saber configurar OpenLDAP, Servidores ZooKeeper, Cassandra y Postgres en los centros de datos. Además, debes asegurarte de que el necesarios estén abiertos entre los nodos de los dos centros de datos.

OpenLDAP
Cada centro de datos tiene su propio servidor OpenLDAP configurado con la replicación habilitada. Cuando instalar el nuevo centro de datos, debes configurar OpenLDAP para usar la replicación y volver a configurar el servidor OpenLDAP en el centro de datos existente para usar la replicación.
ZooKeeper
En la propiedad ZK_HOSTS de ambos centros de datos, especificar las direcciones IP o los nombres de DNS de todos los nodos de ZooKeeper de ambos datos centros de datos en el mismo orden, y marcará los nodos con el modificador “:observer”. Los nodos que no tienen el modificador :observer se llaman “votadores”. Debes tener un número extraño cantidad de "votantes" en tu configuración.

En esta topología, el host de ZooKeeper en el host 9 es el observador:

En el ejemplo de archivo de configuración que se muestra a continuación, el nodo 9 se etiqueta con el :observer para que tengas cinco votantes: nodos 1, 2, 3, 7 y 8.

Para ZK_CLIENT_HOSTS para cada centro de datos, especifica las direcciones IP o nombres de DNS solo de ZooKeeper nodos del centro de datos, en el mismo orden, para todos los nodos de ZooKeeper en el centro de atención.
Cassandra
Todos los centros de datos deben tener la misma cantidad de nodos Cassandra.

Para CASS_HOSTS de cada centro de datos, asegúrate de especificar todas las IP de Cassandra. (no nombres de DNS) para ambos datos locales. Para el centro de datos 1, enumera primero los nodos de Cassandra en ese centro de datos. Para centros de datos 2, enumera primero los nodos de Cassandra en ese centro de datos. Genera una lista de los nodos de Cassandra en la misma para todos los nodos de Cassandra en el centro de datos.

Todos los nodos de Cassandra deben tener un sufijo ':d,r'; Por ejemplo: 'ip:1,1 = centro de datos 1 y bastidor/zona de disponibilidad 1 y 'ip:2,1 = centro de datos 2 y bastidor/zona de disponibilidad 1.

Por ejemplo: “192.168.124.201:1,1 192.168.124.202:1,1 192.168.124.203:1,1 192.168.124.204:2,1 192.168.124.205:2,1 192.168.124.206:2,1"

El primer nodo de la zona de disponibilidad o bastidor 1 de cada centro de datos se usará como origen servidor. En este modelo de implementación, la configuración de Cassandra se verá de la siguiente manera:

Postgres

De forma predeterminada, Edge instala todos los nodos de Postgres en el modo principal. Sin embargo, cuando tienes varios centros de datos, configurarás los nodos de Postgres para usar la replicación en espera de instancia principal, de modo que si la falla el nodo principal, el nodo en espera puede continuar con el tráfico del servidor. Por lo general, se configura el servidor Postgres principal en un centro de datos y el servidor en espera en el segundo en el centro de atención.

Si el centro de datos existente ya está configurado para ejecutar dos nodos de Postgres en modo principal/en espera; luego, como parte de este procedimiento, anula el registro del nodo en espera existente y reemplazarlo por un nodo en espera en el centro de datos nuevo.

En la siguiente tabla, se muestra la configuración de Postgres anterior y posterior para ambos, diferentes:

Antes	Después
Nodo principal de Postgres único en dc-1	Nodo principal de Postgres en dc-1 Nodo Postgres en espera en dc-2
Nodo principal de Postgres en dc-1 Nodo Postgres en espera en dc-1	Nodo principal de Postgres en dc-1 Nodo Postgres en espera en dc-2 Anula el registro del nodo Postgres anterior en espera en dc-1

Antes

Después

Nodo principal de Postgres único en dc-1

Nodo principal de Postgres en dc-1

Nodo Postgres en espera en dc-2

Nodo principal de Postgres en dc-1

Nodo Postgres en espera en dc-1

Nodo principal de Postgres en dc-1

Nodo Postgres en espera en dc-2

Anula el registro del nodo Postgres anterior en espera en dc-1

Requisitos de puerto
Debes asegurarte de que los puertos necesarios estén abiertos entre los nodos de los dos centros de datos. Para obtener un diagrama de puertos, consulta Requisitos de puertos.

Actualiza el centro de datos existente

Para agregar un centro de datos, debes seguir los pasos para instalar y configurar los datos nuevos del centro de datos original, sino que también debe actualizarlos en el centro de datos original. Estos son necesarias porque agregarás nuevos nodos Cassandra y ZooKeeper en los nuevos que deben ser accesibles para el centro de datos existente, y hay que OpenLDAP para usar la replicación.

Crea los archivos de configuración

A continuación, se muestran los archivos de configuración silenciosos para los dos centros de datos, donde cada dato tiene 6 nodos, como se muestra en Topologías de instalación. Observa que el archivo de configuración para dc-1 agrega parámetros de configuración adicionales para:

Configurar OpenLDAP con replicación en dos nodos de OpenLDAP
Agrega los nuevos nodos Cassandra y ZooKeeper de dc-2 al archivo de configuración de dc-1.

# Datacenter 1
IP1=IPorDNSnameOfNode1
IP2=IPorDNSnameOfNode2
IP3=IPorDNSnameOfNode3
IP7=IPorDNSnameOfNode7
IP8=IPorDNSnameOfNode8
IP9=IPorDNSnameOfNode9 
HOSTIP=$(hostname -i)
MSIP=$IP1
ADMIN_EMAIL=opdk@google.com
APIGEE_ADMINPW=Secret123
LICENSE_FILE=/tmp/license.txt
USE_LDAP_REMOTE_HOST=n
LDAP_TYPE=2
LDAP_SID=1
LDAP_PEER=$IP7
APIGEE_LDAPPW=secret
MP_POD=gateway-1
REGION=dc-1
ZK_HOSTS="$IP1 $IP2 $IP3 $IP7 $IP8 $IP9:observer"
ZK_CLIENT_HOSTS="$IP1 $IP2 $IP3"
# Must use IP addresses for CASS_HOSTS, not DNS names.
CASS_HOSTS="$IP1:1,1 $IP2:1,1 $IP3:1,1 $IP7:2,1 $IP8:2,1 $IP9:2,1"
SKIP_SMTP=n
SMTPHOST=smtp.example.com
SMTPUSER=smtp@example.com 
SMTPPASSWORD=smtppwd   
SMTPSSL=n
SMTPPORT=25
SMTPMAILFROM="My Company <myco@company.com>"

# Datacenter 2
IP1=IPorDNSnameOfNode1
IP2=IPorDNSnameOfNode2
IP3=IPorDNSnameOfNode3
IP7=IPorDNSnameOfNode7
IP8=IPorDNSnameOfNode8
IP9=IPorDNSnameOfNode9 
HOSTIP=$(hostname -i)
MSIP=$IP7
ADMIN_EMAIL=opdk@google.com
APIGEE_ADMINPW=Secret123
LICENSE_FILE=/tmp/license.txt
USE_LDAP_REMOTE_HOST=n
LDAP_TYPE=2
LDAP_SID=2
LDAP_PEER=$IP1
APIGEE_LDAPPW=secret
MP_POD=gateway-2
REGION=dc-2
ZK_HOSTS="$IP1 $IP2 $IP3 $IP7 $IP8 $IP9:observer"
ZK_CLIENT_HOSTS="$IP7 $IP8 $IP9"
# Must use IP addresses for CASS_HOSTS, not DNS names.
CASS_HOSTS="$IP7:2,1 $IP8:2,1 $IP9:2,1 $IP1:1,1 $IP2:1,1 $IP3:1,1"
SKIP_SMTP=n
SMTPHOST=smtp.example.com
SMTPUSER=smtp@example.com 
SMTPPASSWORD=smtppwd   
SMTPSSL=n
SMTPPORT=25
SMTPMAILFROM="My Company <myco@company.com>"

Agregar un centro de datos nuevo

En este procedimiento, los centros de datos tienen el siguiente nombre:

dc-1: El centro de datos existente
dc-2: el nuevo centro de datos

Para agregar un centro de datos nuevo, sigue estos pasos:

En dc-1, vuelve a ejecutar setup.sh en los nodos de Cassandra originales con el nuevo dc-1. de configuración que incluye los nodos de Cassandra de dc-2:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ds -f configFile1
```
En dc-1, vuelve a ejecutar setup.sh en el nodo del servidor de administración:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ms -f configFile1
```
En dc-2, instala apigee-setup en todos los nodos. Consulta Instala la utilidad de Apigee-setup de Edge para obtener más información. información.
En dc-2, instala Cassandra y ZooKeeper en los nodos adecuados:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ds -f configFile2
```
En dc-2, ejecuta el comando de recompilación en todos los nodos de Cassandra y especifica la Nombre de la región de dc-1:
```
/opt/apigee/apigee-cassandra/bin/nodetool -h cassIP rebuild dc-1
```
En dc-2, instala el Servidor de administración en el nodo adecuado:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ms -f configFile2
```
En el nodo del servidor de administración en dc-2, instala apigee-provision. que instala la utilidad apigee-adminapi.sh:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision install
```
En dc-2, instala Routes and Message Processors en los nodos adecuados:
```
/opt/apigee/apigee-setup/bin/setup.sh -p rmp -f configFile2
```

En dc-2, instala Qpid en los nodos correspondientes:

/opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile2

En dc-2, instala Postgres en el nodo adecuado:

/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile2

Configura la instancia principal o en espera de Postgres para los nodos de Postgres. El nodo de Postgres en dc-1 es el y el nodo de Postgres en dc-2 es el servidor en espera.
Nota: Si dc-1 ya está configurado para tienes dos nodos de Postgres ejecutándose en modo principal/en espera, luego, como parte de este procedimiento, usa el el nodo principal de Postgres existente en dc-1 como instancia principal Nodo de Postgres en dc-2 como el servidor en espera. Más adelante en este procedimiento, anulará el registro del servidor en espera de Postgres existente en dc-1.
1. En el nodo principal de dc-1, edita el archivo de configuración para establecer lo siguiente:
```
PG_MASTER=IPorDNSofDC1Master
PG_STANDBY=IPorDNSofDC2Standby
```
2. Habilita la replicación en la instancia principal nueva:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFIle
```
3. En el nodo en espera de dc-2, edita el archivo de configuración para establecer lo siguiente:
```
PG_MASTER=IPorDNSofDC1Master
PG_STANDBY=IPorDNSofDC2Standby
```
4. En el nodo en espera de dc-2, detén el servidor y, luego, borra cualquier datos existentes de Postgres:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
rm -rf /opt/apigee/data/apigee-postgresql/
```
  Nota: Si es necesario, puedes crear una copia de seguridad de estos datos antes de y borrarlo.
5. Configura el nodo en espera en dc-2:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
```
En dc-1, actualiza la configuración de análisis y configura las organizaciones.
1. En el nodo del servidor de administración de dc-1, obtén el UUID de Postgres nodo:
```
apigee-adminapi.sh servers list -r dc-1 -p analytics -t postgres-server \
  --admin adminEmail --pwd adminPword --host localhost
```
  El UUID aparece al final de los datos que se muestran. Guarda ese valor.
  
  Nota: Si dc-1 está configurado para tener dos nodos de Postgres en ejecución principal/en espera, verás dos direcciones IP y un UUID en el resultado. Guarda ambos UUID. A partir de las IP, debería poder determinar qué UUID es para la instancia principal y cuál es para el nodo en espera.
2. En el nodo del servidor de administración de dc-2, obtén el UUID de Postgres como se muestra en el paso anterior. Guarda ese valor.
3. En el nodo del Servidor de administración de dc-1, determina el nombre del de Google Analytics y grupos de consumidores. Muchos de los siguientes comandos requieren esa información.
  De forma predeterminada, el nombre del grupo de análisis es “axgroup-001” y el nombre del consumidor. grupo es "consumer-group-001". En el archivo de configuración silencioso de una región, puedes establecer el nombre del grupo de estadísticas con la propiedad AXGROUP
  
  Si no conoces los nombres de los grupos de analítica y de consumidores, usa los siguientes para mostrarlas:
```
apigee-adminapi.sh analytics groups list \
  --admin adminEmail --pwd adminPword --host localhost
```
  Este comando devuelve el nombre del grupo de análisis en el campo de nombre, y el grupo de consumidores en el campo consumer-groups.
4. En el nodo de Management Server de dc-1, quita el Postgres existente servidor desde el grupo de estadísticas:
  1. Quita el nodo de Postgres del grupo del consumidor:
```
apigee-adminapi.sh analytics groups consumer_groups datastores remove \
  -g axgroup-001 -c consumer-group-001 -u UUID \
  -Y --admin adminEmail --pwd adminPword --host localhost
```
    Si dc-1 está configurado para tener dos nodos de Postgres en ejecución en modo principal/en espera, quita ambos:
```
apigee-adminapi.sh analytics groups consumer_groups datastores remove \
  -g axgroup-001 -c consumer-group-001 -u "UUID_1,UUID_2" \
  -Y --admin adminEmail --pwd adminPword --host localhost
```
  2. Quita el nodo de Postgres del grupo de estadísticas:
```
apigee-adminapi.sh analytics groups postgres_server remove \
  -g axgroup-001 -u UUID -Y --admin adminEmail \
  --pwd adminPword --host localhost
```
    Si dc-1 está configurado para tener dos nodos de Postgres que se ejecutan en modo principal/en espera, quitar ambas:
```
apigee-adminapi.sh analytics groups postgres_server \
  remove -g axgroup-001 -u UUID1,UUID2 -Y --admin adminEmail \
  --pwd adminPword --host localhost
```
5. En el nodo del servidor de administración de dc-1, agrega la nueva instancia principal o en espera. Servidores de Postgres al grupo de estadísticas:
  1. Agrega ambos servidores de Postgres al grupo de estadísticas:
```
apigee-adminapi.sh analytics groups postgres_server \
  add -g axgroup-001 -u "UUID_1,UUID_2" --admin adminEmail \
  --pwd adminPword --host localhost
```
    Ehere, UUID_1 corresponde al nodo principal de Postgres en dc-1, y UUID_2 corresponde al Postgres en espera en dc-2.
  2. Agrega los servidores de PG al grupo del consumidor como principal o en espera:
```
apigee-adminapi.sh analytics groups consumer_groups datastores \
  add -g axgroup-001 -c consumer-group-001 -u "UUID_1,UUID_2" --admin adminEmail \
  --pwd adminPword --host localhost
```
6. Agrega los servidores Qpid de dc-2 al grupo de estadísticas:
  1. En el nodo del servidor de administración de dc-1, obtén los UUID del Qpid Nodos en dc-2:
```
apigee-adminapi.sh servers list -r dc-2 -p central -t qpid-server \
  --admin adminEmail --pwd adminPword --host localhost
```
    Los UUID aparecen al final de los datos que se muestran. Guarda esos valores.
  2. En el nodo del servidor de administración de dc-1, agrega los nodos de Qpid al nodo Analytics group (ejecuta ambos comandos):
```
apigee-adminapi.sh analytics groups qpid_server \
  add -g axgroup-001 -u "UUID_1" --admin adminEmail \
  --pwd adminPword --host localhost

apigee-adminapi.sh analytics groups qpid_server \
  add -g axgroup-001 -u "UUID_2" --admin adminEmail \
  --pwd adminPword --host localhost
```
  3. En el nodo del servidor de administración de dc-1, agrega los nodos de Qpid al nodo consumidor (ejecuta ambos comandos):
```
apigee-adminapi.sh analytics groups consumer_groups consumers \
  add -g axgroup-001 -c consumer-group-001 -u "UUID_1" \
  --admin adminEmail --pwd adminPword --host localhost

apigee-adminapi.sh analytics groups consumer_groups consumers \
  add -g axgroup-001 -c consumer-group-001 -u "UUID_2" \
  --admin adminEmail --pwd adminPword --host localhost
```
7. Anula el registro y borra el servidor en espera anterior de Postgres de dc-1:
  1. Anula el registro del servidor en espera dc-1 de Postgres existente:
```
apigee-adminapi.sh servers deregister -u UUID -r dc-1 \
  -p analytics -t postgres-server -Y --admin adminEmail \
  --pwd adminPword --host localhost
```
    Donde UUID es el nodo de Postgres anterior en espera en dc-1.
  2. Borra el servidor en espera dc-1 de Postgres existente:
    Nota: Este comando no desinstala Postgres en tu nodo del servidor. Solo lo quita de la lista de nodos de Edge. Puedes desinstalarla más adelante Postgres desde el nodo, si es necesario
```
apigee-adminapi.sh servers delete -u UUID \
  --admin adminEmail --pwd adminPword --host localhost
```
Actualizar los espacios de claves de Cassandra con el factor de replicación correcto para los dos centros de datos Tú solo tendrás que ejecutar este paso una vez en cualquier servidor Cassandra en cualquiera de los centros de datos:
Nota: Los siguientes comandos configuran el factor de replicación a “3”, lo que indica tres nodos de Cassandra en el clúster. Modifica este valor según sea necesario para la instalación.
1. Inicia la utilidad cqlsh de Cassandra:
```
/opt/apigee/apigee-cassandra/bin/cqlsh cassandraIP
```
2. Ejecuta los siguientes comandos de CQL en “cqlsh>” para configurar la replicación para los espacios de claves de Cassandra:
  1. ```
  ALTER KEYSPACE "identityzone" WITH replication = { 'class': 'NetworkTopologyStrategy', 'dc-1': '3','dc-2': '3' }; 
```
2. ```
ALTER KEYSPACE "system_traces" WITH replication = { 'class': 'NetworkTopologyStrategy', 'dc-1': '3','dc-2': '3' };
```
  3. Para ver los espacios de claves, usa el siguiente comando:
```
select * from system.schema_keyspaces;
```
  4. Salga de cqlsh:
```
exit
```
Ejecuta el siguiente comando nodetool en todos los nodos de Cassandra en dc-1 para obtener una versión gratuita. memoria:
```
/opt/apigee/apigee-cassandra/bin/nodetool -h cassandraIP cleanup
```
Para cada organización y entorno que quieras admitir en todos los centros de datos:
1. En el nodo del servidor de administración de dc-1, agrega el nuevo MP_POD al Organización:
```
apigee-adminapi.sh orgs pods add -o orgName -r dc-2 -p gateway-2 \
  --admin adminEmail --pwd adminPword --host localhost
```
  Donde gateway-2 es el nombre del Pod de puerta de enlace según lo define el MP_POD en el archivo de configuración de dc-2.
2. Agrega los nuevos Message Processor a la organización y al entorno:
  1. En el nodo del servidor de administración de dc-2, obtén los UUID del Nodos del procesador de mensajes en dc-2:
```
apigee-adminapi.sh servers list -r dc-2 -p gateway-2 \
  -t message-processor --admin adminEmail --pwd adminPword --host localhost
```
    Los UUID aparecen al final de los datos que se muestran. Guarda esos valores.
  2. En el nodo del Servidor de administración de dc-1, para cada Procesador de mensajes en dc-2, agrega Message Processor a un entorno para la organización:
```
apigee-adminapi.sh orgs envs servers add -o orgName -e envName \
  -u UUID --admin adminEmail --pwd adminPword --host localhost
```
3. En el nodo del servidor de administración de dc-1, verifica la organización:
```
apigee-adminapi.sh orgs apis deployments -o orgName -a apiProxyName \
  --admin adminEmail --pwd adminPword --host localhost
```
  En el ejemplo anterior, apiProxyName es el nombre de un proxy de API implementado en la organización.