Como adicionar um data center

Edge para nuvem privada v4.18.01

Este documento descreve como adicionar um data center (também chamado de região) a um data center existente.

Considerações antes de adicionar um data center

Antes de instalar um data center, é necessário entender como configurar os servidores OpenLDAP, ZooKeeper, Cassandra e Postgres nos data centers. Você também precisa garantir que as portas necessárias estejam abertas entre os nós nos dois data centers.

  • OpenLDAP
    Cada data center tem o próprio servidor OpenLDAP configurado com a replicação ativada. Ao instalar o novo data center, configure o OpenLDAP para usar a replicação e reconfigure o servidor OpenLDAP no data center atual para usar a replicação.
  • ZooKeeper
    Para a propriedade ZK_HOSTS de ambos os data centers, especifique os endereços IP ou nomes DNS de todos os nós do ZooKeeper de ambos os data centers, na mesma ordem, e marque-os com o modificador ":observer". Os nós sem o modificador ":observer" são chamados de "voters". Você precisa ter um número ímpar de "eleitores" na sua configuração.

    Nesta topologia, o host do ZooKeeper no host 9 é o observador:



    No exemplo de arquivo de configuração mostrado abaixo, o nó 9 é marcado com o modificador ":observer" para que você tenha cinco votantes: os nós 1, 2, 3, 7 e 8.

    Para a propriedade ZK_CLIENT_HOSTS de cada data center, especifique os endereços IP ou nomes DNS apenas dos nós do ZooKeeper no data center, na mesma ordem, para todos os nós do ZooKeeper no data center.
  • Cassandra
    Todos os data centers precisam ter o mesmo número de nós do Cassandra.

    Para CASS_HOSTS em cada data center, especifique todos os endereços IP do Cassandra (não os nomes DNS) para os dois data centers. No data center 1, liste primeiro os nós do Cassandra nesse data center. Para o data center 2, liste primeiro os nós do Cassandra nesse data center. Liste os nós do Cassandra na mesma ordem para todos os nós do Cassandra no data center.

    Todos os nós do Cassandra precisam ter um sufixo ":<d>,<r>", por exemplo, "<ip>:1,1 = data center 1 e rack/zona de disponibilidade 1 e "<ip>:2,1 = data center 2 e rack/zona de disponibilidade 1.
    Por exemplo, "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"

    O primeiro nó no rack/zona de disponibilidade 1 de cada data center será usado como servidor semente. Nesse modelo de implantação, a configuração do Cassandra será assim:


  • Postgres
    Por padrão, o Edge instala todos os nós do Postgres no modo mestre. No entanto, quando você tem vários data centers, configura os nós do Postgres para usar a replicação mestre-standby. Assim, se o nó mestre falhar, o nó reserva poderá continuar o tráfego do servidor. Normalmente, você configura o servidor Postgres mestre em um data center e o servidor em espera no segundo data center.

    Se o data center atual já estiver configurado para ter dois nós do Postgres em execução no modo mestre/de espera, como parte desse procedimento, cancele o registro do nó de espera atual e o substitua por um nó de espera no novo data center.

    A tabela a seguir mostra a configuração do Postgres antes e depois dos dois cenários:

    Antes

    Depois

    Um único nó mestre do Postgres em dc-1

    Nó mestre do Postgres em dc-1

    Nó Postgres de espera em dc-2

    Nó mestre do Postgres em dc-1

    Nó do Postgres em espera em dc-1

    Nó mestre do Postgres em dc-1

    Nó Postgres de espera em dc-2

    Desregistrar o antigo nó do Standby Postgres em dc-1
  • Requisitos de porta
    As portas necessárias precisam estar abertas entre os nós nos dois data centers. Para conferir um diagrama de portas, consulte Requisitos de instalação.

Atualizar o data center atual

Para adicionar um data center, é necessário seguir as etapas para instalar e configurar os novos nós do data center, mas também atualizar os nós no data center original. Essas modificações são necessárias porque você está adicionando novos nós do Cassandra e do ZooKeeper no novo data center, que precisam ser acessíveis ao data center atual, e você precisa reconfigurar o OpenLDAP para usar a replicação.

Como criar os arquivos de configuração

Os arquivos de configuração silenciosa dos dois data centers são mostrados abaixo, em que cada data center tem seis nós, conforme mostrado em Topologias de instalação. O arquivo de configuração de dc-1 adiciona outras configurações a:

  • Configurar o OpenLDAP com replicação em dois nós do OpenLDAP.
  • Adicione os novos nós do Cassandra e do ZooKeeper de dc-2 ao arquivo de configuração 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>"

Procedimento para adicionar um novo data center

Neste procedimento, os data centers são chamados de:

  • dc-1: o data center atual
  • dc-2: o novo data center
  1. Em dc-1, execute novamente o setup.sh nos nós do Cassandra originais com o novo arquivo de configuração dc-1 que inclui os nós do Cassandra de dc-2:
    /opt/apigee/apigee-setup/bin/setup.sh -p ds -f configFile1
  2. Em dc-1, execute novamente o setup.sh no nó do servidor de gerenciamento:
    > /opt/apigee/apigee-setup/bin/setup.sh -p ms -f configFile1
  3. Em dc-2, instale o apigee-setup em todos os nós. Consulte Instalar o utilitário apigee-setup do Edge para mais informações.
  4. Em dc-2, instale o Cassandra e o ZooKeeper nos nós apropriados:
    /opt/apigee/apigee-setup/bin/setup.sh -p ds -f configFile2
  5. Em dc-2, execute o comando de reconstrução em todos os nós do Cassandra, especificando o nome da região de dc-1:
    > /opt/apigee/apigee-cassandra/bin/nodetool -h cassIP rebuild dc-1
  6. Em dc-2, instale o servidor de gerenciamento no nó apropriado:
    > /opt/apigee/apigee-setup/bin/setup.sh -p ms -f configFile2
  7. No nó do Servidor de gerenciamento em dc-2, instale o apigee-provision, que instala o utilitário apigee-adminapi.sh:
    > /opt/apigee/apigee-service/bin/apigee-service apigee-provision install
  8. Em dc-2, instale as rotas e os processadores de mensagens nos nós adequados:
    > /opt/apigee/apigee-setup/bin/setup.sh -p rmp -f configFile2
  9. Em dc-2, instale o Qpid nos nós apropriados:
    > /opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile2
  10. Em dc-2, instale o Postgres no nó apropriado:
    > /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile2
  11. Configure o mestre/standby do Postgres para os nós do Postgres. O nó do Postgres em dc-1 é o mestre, e o nó do Postgres em dc-2 é o servidor de espera.

    Observação: se o dc-1 já estiver configurado para ter dois nós do Postgres em execução no modo mestre/standby, como parte deste procedimento, use o nó mestre do Postgres em dc-1 como mestre e o nó do Postgres em dc-2 como servidor de standby. Mais adiante neste procedimento, você vai cancelar o registro do servidor de espera do Postgres em dc-1.
    1. No nó mestre em dc-1, edite o arquivo de configuração para definir:
      PG_MASTER=IPorDNSofDC1Master
      PG_STANDBY=IPorDNSofDC2Standby
    2. Ative a replicação no novo mestre:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFIle
    3. No nó de espera em dc-2, edite o arquivo de configuração para definir:
      PG_MASTER=IPorDNSofDC1Master
      PG_STANDBY=IPorDNSofDC2Standby
    4. No nó reserva em dc-2, pare o servidor e exclua todos os dados do Postgres:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
      > rm -rf /opt/apigee/data/apigee-postgresql/
      Observação: se necessário, faça backup desses dados antes de excluí-los.
    5. Configure o nó de espera em dc-2:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
  12. Em dc-1, atualize a configuração da análise e configure as organizações.
    1. No nó do servidor de gerenciamento de dc-1, acesse o UUID do nó do Postgres:
      > servidores apigee-adminapi.sh list -r dc-1 -p analytics -t postgres-server --admin adminEmail --pwd adminPword --host localhost

      O UUID aparece no final dos dados retornados. Salve esse valor.

      Observação: se o dc-1 estiver configurado para ter dois nós do Postgres em execução no modo mestre/standby, dois endereços IP e UUIDs vão aparecer na saída. Salve os dois UUIDs. Com os IPs, você pode determinar qual UUID é para o mestre e qual é para o nó de espera.
    2. No nó do servidor de gerenciamento de dc-2, acesse o UUID do nó do Postgres, conforme mostrado na etapa anterior. Salve esse valor.
    3. No nó do servidor de gerenciamento de dc-1, determine o nome dos grupos de análise e de consumidor. Muitos dos comandos abaixo exigem essas informações.
      Por padrão, o nome do grupo de análise é axgroup-001, e o nome do grupo de consumidor é consumer-group-001. No arquivo de configuração silenciosa de uma região, é possível definir o nome do grupo de análise usando a propriedade AXGROUP.

      Se você não tiver certeza dos nomes dos grupos de análise e de consumo, use o seguinte comando para exibi-los:
      > apigee-adminapi.sh analytics groups list --admin adminEmail --pwd adminPword --host localhost

      Esse comando retorna o nome do grupo de análise no campo "name" e o nome do grupo de consumo no campo "consumer-groups".
    4. No nó do servidor de gerenciamento de dc-1, remova o servidor Postgres atual do grupo de análise:
      1. Remover o nó do Postgres do nó do Postgres do grupo do consumidor::
        > .


        UUID
      2. Remover o nó do Postgres do grupo de análises:
        >


        UUID
    5. No nó do servidor de gerenciamento de dc-1, adicione os novos servidores mestre/de espera do Postgres ao grupo de análise:
      1. Adicione os dois servidores do Postgres ao grupo de análise:
        > apigee-adminapi.sh analytics groups postgres_server add -g axgroup-001 -u "UUID_1,UUID_2" --admin adminEmail --pwd adminPword --host localhost

        em que UUID_1 corresponde ao nó mestre do Postgres em dc-1, e UUID_2 corresponde ao nó de espera do Postgres em dc-2.
      2. Adicione os servidores do PG ao grupo de consumidores como mestre/reserva:
        > 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. Adicione os servidores Qpid de dc-2 ao grupo de análise:
      1. No nó do servidor de gerenciamento de dc-1, extraia os UUIDs dos nós do Qpid em dc-2:
        > apigee-adminapi.sh servers list -r dc-2 -p central -t qpid-server --admin adminEmail --pwd adminPword --host localhost

        Os UUIDs aparecem no final dos dados retornados. Salve esses valores.
      2. No nó do servidor de gerenciamento de dc-1, adicione os nós Qpid ao grupo de análises (execute os dois 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. No nó do servidor de gerenciamento de dc-1, adicione os nós Qpid ao grupo de consumidores (execute os dois 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. Cancele o registro e exclua o servidor em espera antigo do Postgres em dc-1:
      1. Desregistre o servidor de espera do Postgres dc-1:
        > apigee-adminapi.sh servers deregister -u UUID -r dc-1 -p analytics -t postgres-server -Y --admin adminEmail --pwd adminPword --host localhost

        em que UUID é o antigo standby nó Postgres em dc-1.
      2. Exclua o servidor de espera dc-1 Postgres:
        Observação: este comando não desinstala o nó do servidor Postgres. Ele só é removido da lista de nós de borda. Posteriormente, você poderá desinstalar o Postgres do nó, se necessário.
        > apigee-adminapi.sh servers delete -u UUID --admin adminEmail --pwd adminPword --host localhost
  13. Atualize os keyspaces do Cassandra com o fator de replicação correto para os dois data centers. Você só precisa executar esta etapa uma vez em qualquer servidor do Cassandra em qualquer data center:

    Observação: todos os comandos abaixo definem o fator de replicação como "3", indicando três nós do Cassandra no cluster. Modifique esse valor conforme necessário para a instalação.
    1. Inicie o utilitário cqlsh do Cassandra:
      > /opt/apigee/apigee-cassandra/bin/cqlsh cassandraIP
    2. Execute os seguintes comandos CQL no prompt "cqlsh>" para definir os níveis de replicação dos keyspaces do Cassandra:
      1. cqlsh> ALTER KEYSPACE "identityzone" WITH replication = { 'class': 'NetworkTopologyStrategy', 'dc-1': '3','dc-2': '3' };
      2. cqlsh> ALTER KEYSPACE "system_traces" WITH replication = { 'class': 'NetworkTopologyStrategy', 'dc-1': '3','dc-2': '3' };
      3. Confira os keyspaces usando o comando:
        cqlsh> select * from system.schema_keyspaces;
      4. Sair do cqlsh:
        cqlsh> exit
  14. Execute o comando nodetool a seguir em todos os nós do Cassandra no dc-1 para liberar memória:
    > /opt/apigee/apigee-cassandra/bin/nodetool -h cassandraIP cleanup
  15. Para cada organização e ambiente que você quer oferecer suporte em todos os data centers:
    1. No nó do servidor de gerenciamento de dc-1, adicione o novo MP_POD à organização:
      > apigee-adminapi.sh orgs pods add -o orgName -r dc-2 -p gateway-2 --admin adminEmail --pwd adminPword --host localhost

      em que gateway-2 é o nome do pod de gateway, conforme definido pela propriedade MP_POD no arquivo de configuração dc-2.
    2. Adicione os novos processadores de mensagens à organização e ao ambiente:
      1. No nó do servidor de gerenciamento de dc-2, acesse os UUIDs dos nós do processador de mensagens em dc-2:
        > servidores apigee-adminapi.sh list -r dc-2 -p gateway-2 -t message-processor --admin adminEmail --pwd adminPword --host no final dos dados retornados

        Os UUIDs aparecem no final dos dados retornados.
        Salve esses valores.
      2. No nó do servidor de gerenciamento de dc-1, para cada processador de mensagens em dc-2, adicione o processador de mensagens a um ambiente para a organização:
        > apigee-adminapi.sh orgs envs servers add -o orgName -e envName -u UUID --admin adminEmail --pwd adminPword --host localhost
    3. No nó do servidor de gerenciamento de dc-1, verifique a organização:
      > apigee-adminapi.sh orgs apis deployments -o orgName -a apiProxyName --admin adminEmail --pwd adminPword --host localhost

      em que apiProxyName é o nome de um proxy de API implantado na organização.