Requisitos de instalação

Edge para nuvem privada v4.18.01

Requisitos de hardware

Você precisa atender aos seguintes requisitos mínimos de hardware para uma infraestrutura de alta disponibilidade em um ambiente de produção. Para todos os cenários de instalação descritos em Topologias de instalação, as tabelas a seguir listam os requisitos mínimos de hardware para os componentes de instalação.

Nessas tabelas, os requisitos de disco rígido são adicionais ao espaço em disco necessário pelo sistema operacional. Dependendo dos aplicativos e do tráfego de rede, a instalação pode exigir mais ou menos recursos do que os listados abaixo.

Além disso, confira abaixo os requisitos de hardware se você quiser instalar os Serviços de monetização:

Confira abaixo os requisitos de hardware para instalar o API BaaS:

Requisitos de sistema operacional e software de terceiros

Estas instruções de instalação e os arquivos fornecidos foram testados nos sistemas operacionais e softwares de terceiros listados em Software e versões compatíveis.

Criar o usuário da Apigee

O procedimento de instalação cria um usuário do sistema Unix chamado "apigee". Os diretórios e arquivos do Edge pertencem a "apigee", assim como os processos do Edge. Isso significa que os componentes do Edge são executados como o usuário "apigee". Se necessário, você pode executar componentes como um usuário diferente.

Diretório de instalação

Por padrão, o instalador grava todos os arquivos no diretório /opt/apigee. Não é possível mudar o local do diretório. Não é possível mudar esse diretório, mas você pode criar um link simbólico para mapear /opt/apigee para outro local, conforme descrito abaixo.

Nas instruções deste guia, o diretório de instalação é indicado como /opt/apigee.

Criando um link simbólico de /opt/apigee

Antes de criar o link simbólico, crie um usuário e um grupo chamados "apigee". Esse é o mesmo grupo e usuário criados pelo instalador do Edge.

Para criar o link simbólico, siga estas etapas antes de baixar o arquivo bootstrap_4.18.01.sh. É preciso executar todas estas etapas como raiz:

1. Crie o usuário e o grupo "apigee":

   groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee

2. Crie um link simbólico de /opt/apigee para a raiz de instalação desejada:

   ln -Ts /srv/myInstallDir /opt/apigee

   em que /srv/myInstallDir é o local desejado dos arquivos do Edge.

3. Mude a propriedade da raiz de instalação e do link simbólico para o usuário "apigee":

   chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

É necessário ter uma versão compatível do Java 1.8 instalada em cada máquina antes da instalação. Os JDKs compatíveis estão listados em Software e versões compatíveis.

Verifique se JAVA_HOME aponta para a raiz do JDK do usuário que está fazendo a instalação.

SELinux

Dependendo das suas configurações do SELinux, o Edge pode ter problemas ao instalar e iniciar componentes do Edge. Se necessário, desative o SELinux ou defina-o como permissivo durante a instalação e reative-o depois. Consulte Instalar o utilitário apigee-setup do Edge para mais informações.

Configuração de rede

Recomendamos verificar a configuração de rede antes da instalação. O instalador espera que todas as máquinas tenham endereços IP fixos. Use os comandos a seguir para validar a configuração:

• hostname retorna o nome da máquina.
• hostname -i retorna o endereço IP do nome do host que pode ser acessado de outras máquinas.

Dependendo do tipo e da versão do sistema operacional, talvez seja necessário editar /etc/hosts e /etc/sysconfig/network se o nome do host não estiver definido corretamente. Consulte a documentação do seu sistema operacional específico para mais informações.

Se um servidor tiver várias placas de interface, o comando "hostname -i" vai retornar uma lista de endereços IP separados por espaços. Por padrão, o instalador do Edge usa o primeiro endereço IP retornado, o que pode não ser correto em todas as situações. Como alternativa, defina a seguinte propriedade no arquivo de configuração da instalação:

ENABLE_DYNAMIC_HOSTIP=y

Com essa propriedade definida como "y", o instalador pede que você selecione o endereço IP a ser usado como parte da instalação. O valor padrão é "n". Consulte Referência do arquivo de configuração do Edge para mais informações.

TCP Wrappers

Os wrappers TCP podem bloquear a comunicação de algumas portas e afetar a instalação do OpenLDAP, do Postgres e do Cassandra. Nesses nós, verifique /etc/hosts.allow e /etc/hosts.deny para garantir que não haja restrições de porta nas portas necessárias do OpenLDAP, do Postgres e do Cassandra.

iptables

Valide se não há políticas de iptables impedindo a conectividade entre os nós nas portas de borda necessárias. Se necessário, pare o iptables durante a instalação usando o comando:

sudo/etc/init.d/iptables stop

No CentOS 7.x:

systemctl stop firewalld

Verifique se o roteador de borda pode acessar /etc/rc.d/init.d/functions.

Os nós do roteador de borda e do portal BaaS usam o roteador Nginx e exigem acesso de leitura a /etc/rc.d/init.d/functions.

Se o processo de segurança exigir que você defina permissões em /etc/rc.d/init.d/functions, não as defina como 700. Caso contrário, o roteador não vai iniciar. As permissões podem ser definidas como 744 para permitir acesso de leitura a /etc/rc.d/init.d/functions.

Cassandra

Todos os nós do Cassandra precisam estar conectados a um anel. O Cassandra armazena réplicas de dados em vários nós para garantir confiabilidade e tolerância a falhas. A estratégia de replicação para cada keyspace do Edge determina os nós do Cassandra em que as réplicas são colocadas. Para mais informações,consulte Sobre o fator de replicação e o nível de consistência do Cassandra.

O Cassandra ajusta automaticamente o tamanho do heap do Java com base na memória disponível. Para mais informações, consulte Ajustar recursos do Java. Em caso de degradação de desempenho ou alto consumo de memória.

Depois de instalar o Edge para nuvem privada, verifique se o Cassandra está configurado corretamente examinando o arquivo /opt/apigee/apigee-cassandra/conf/cassandra.yaml. Por exemplo, verifique se o script de instalação do Edge para nuvem privada definiu as seguintes propriedades:

• cluster_name
• initial_token
• partitioner
• seeds
• listen_address
• rpc_address
• snitch

Banco de dados PostgreSQL

Depois de instalar o Edge, ajuste as seguintes configurações do banco de dados PostgreSQL com base na quantidade de RAM disponível no sistema:

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

Para definir esses valores:

1. Edite o arquivo postgresql.properties:

   vi /opt/apigee/customer/application/postgresql.properties

   Se o arquivo não existir, crie-o.

2. Defina as propriedades listadas acima.
3. Salve as edições.
4. Reinicie o banco de dados PostgreSQL:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Limites do sistema

Verifique se você definiu os seguintes limites do sistema nos nós do Cassandra e do processador de mensagens:

• Nos nós do Cassandra, defina limites flexíveis e rígidos de memlock, nofile e espaço de endereço (as) para o usuário de instalação (o padrão é "apigee") em /etc/security/limits.d/90-apigee-edge-limits.conf, conforme mostrado abaixo:

  apigee soft memlock unlimited
  apigee hard memlock unlimited
  apigee soft nofile 32768
  apigee hard nofile 65536
  apigee soft as unlimited
  apigee hard as unlimited

• Nos nós do processador de mensagens, defina o número máximo de descritores de arquivos abertos como 64K em /etc/security/limits.d/90-apigee-edge-limits.conf, conforme mostrado abaixo:

  apigee soft nofile 32768
  apigee hard nofile 65536

  Se necessário, é possível aumentar esse limite. Por exemplo, se você tiver um grande número de arquivos temporários abertos ao mesmo tempo.

jsvc

"jsvc" é um pré-requisito para usar o API BaaS. A versão 1.0.15-dev é instalada quando você instala o API BaaS.

Serviços de segurança de rede (NSS)

Os Network Security Services (NSS) são um conjunto de bibliotecas que oferecem suporte ao desenvolvimento de aplicativos de cliente e servidor com segurança ativada. Verifique se você instalou o NSS v3.19 ou mais recente.

Para verificar sua versão atual:

yum info nss

Para atualizar o NSS:

yum update nss

Consulte este artigo da RedHat para mais informações.

Desativar a busca DNS no IPv6 ao usar o NSCD (Name Service Cache Daemon)

Se você instalou e ativou o NSCD (daemon de cache de serviço de nomes), os processadores de mensagens fazem duas pesquisas de DNS: uma para IPv4 e outra para IPv6. Desative a pesquisa DNS no IPv6 ao usar o NSCD.

Para desativar a busca DNS no IPv6:

1. Em cada nó do processador de mensagens, edite /etc/nscd.conf.
2. Defina a seguinte propriedade:

   enable-cache hosts no

Desativar o IPv6 no Google Cloud Platform para RedHat/CentOS 7

Se você estiver instalando o Edge no RedHat 7 ou no CentOS 7 no Google Cloud Platform, desative o IPv6 em todos os nós do Qpid.

Consulte a documentação do RedHat ou do CentOS para sua versão específica do SO e veja instruções sobre como desativar o IPv6. Por exemplo, você pode:

1. Abra /etc/hosts em um editor.
2. Insira um caractere "#" na coluna um da seguinte linha para comentar:

   #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

3. Salve o arquivo.

AMI da AWS

Se você estiver instalando o Edge em uma Amazon Machine Image (AMI) da AWS para o Red Hat Enterprise Linux 7.x, execute primeiro o seguinte comando:

yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

Ferramentas

O instalador usa as seguintes ferramentas UNIX na versão padrão fornecida pelo EL5 ou EL6.

ntpdate

Recomendamos que os horários dos servidores estejam sincronizados. Se ainda não estiver configurado, o utilitário ntpdate poderá servir para esse propósito, verificando se os servidores estão sincronizados com o tempo. Use yum install ntp para instalar o utilitário. Isso é especialmente útil para replicar configurações do OpenLDAP. O fuso horário do servidor é UTC.

openldap 2.4

A instalação no local exige o OpenLDAP 2.4. Se o servidor tiver uma conexão com a Internet, o script de instalação do Edge fará o download e a instalação do OpenLDAP. Se o servidor não tiver uma conexão de Internet, verifique se o OpenLDAP já está instalado antes de executar o script de instalação do Edge. No RHEL/CentOS, execute yum install openldap-clients openldap-servers para instalar o OpenLDAP.

Para instalações de 13 hosts e de 12 hosts com dois data centers, é necessária a replicação do OpenLDAP porque há vários nós hospedando o OpenLDAP.

Firewalls e hosts virtuais

O termo virtual é comumente sobrecarregado na área de TI, e isso também acontece com uma implantação do Apigee Edge para Private Cloud e hosts virtuais. Para esclarecer, há dois usos principais do termo virtual:

• Máquinas virtuais (VMs): não são necessárias, mas algumas implantações usam a tecnologia de VM para criar servidores isolados para os componentes do Apigee. Os hosts de VM, assim como os físicos, podem ter interfaces de rede e firewalls.
• Hosts virtuais: endpoints da Web, análogos a um host virtual do Apache.

Um roteador em uma VM pode expor vários hosts virtuais, desde que eles sejam diferentes entre si no alias de host ou na porta de interface.

Como exemplo de nomenclatura, um único servidor físico A pode estar executando duas VMs, chamadas "VM1" e "VM2". Vamos supor que "VM1" exponha uma interface Ethernet virtual, que recebe o nome "eth0" dentro da VM e que recebe o endereço IP 111.111.111.111 da máquina de virtualização ou de um servidor DHCP de rede. Em seguida, vamos supor que VM2 exponha uma interface Ethernet virtual também chamada "eth0" e receba o endereço IP 111.111.111.222.

Podemos ter um roteador do Apigee em execução em cada uma das duas VMs. Os roteadores expõem endpoints de host virtual, como neste exemplo hipotético:

O roteador da Apigee na VM1 expõe três hosts virtuais na interface eth0 (que tem um endereço IP específico), api.mycompany.com:80, api.mycompany.com:443 e test.mycompany.com:80.

O roteador na VM2 expõe api.mycompany.com:80 (mesmo nome e porta que são expostos pela VM1).

O sistema operacional do host físico pode ter um firewall de rede. Se for o caso, ele precisa ser configurado para transmitir o tráfego TCP destinado às portas expostas nas interfaces virtualizadas (111.111.111.111:{80, 443} e 111.111.111.222:80). Além disso, o sistema operacional de cada VM pode fornecer um firewall próprio na interface eth0, e eles também precisam permitir que o tráfego das portas 80 e 443 se conecte.

O basepath é o terceiro componente envolvido no roteamento de chamadas de API para diferentes proxies de API que você pode ter implantado. Os pacotes de proxy de API podem compartilhar um endpoint se tiverem caminhos base diferentes. Por exemplo, um basepath pode ser definido como http://api.mycompany.com:80/ e outro como http://api.mycompany.com:80/salesdemo.

Nesse caso, você precisa de um balanceador de carga ou um Traffic Director de algum tipo dividindo o tráfego http://api.mycompany.com:80/ entre os dois endereços IP (111.111.111.111 na VM1 e 111.111.111.222 na VM2). Essa função é específica da sua instalação e é configurada pelo seu grupo de rede local.

O basepath é definido quando você implanta uma API. No exemplo acima, é possível implantar duas APIs, mycompany e testmycompany, para a organização mycompany-org com o host virtual que tem o alias de host api.mycompany.com e a porta definida como 80. Se você não declarar um basepath na implantação, o roteador não saberá para qual API enviar as solicitações recebidas.

No entanto, se você implantar a API testmycompany com o URL base /salesdemo, os usuários vão acessar essa API usando http://api.mycompany.com:80/salesdemo. Se você implantar a API mycompany com o URL base /, os usuários vão acessar a API pelo URL http://api.mycompany.com:80/.

Requisitos de porta de borda

A necessidade de gerenciar o firewall vai além dos hosts virtuais. Os firewalls da VM e do host físico precisam permitir o tráfego das portas necessárias para que os componentes se comuniquem entre si.

A imagem a seguir mostra os requisitos de porta para cada componente do Edge:

Observações sobre este diagrama:

• * A porta 8082 no processador de mensagens só precisa estar aberta para acesso pelo roteador quando você configura TLS/SSL entre o roteador e o processador de mensagens. Se você não configurar o TLS/SSL entre o roteador e o processador de mensagens, a configuração padrão, a porta 8082 ainda precisará estar aberta no processador de mensagens para gerenciar o componente, mas o roteador não exigirá acesso a ele.
• As portas com o prefixo "M" são usadas para gerenciar o componente e precisam estar abertas no componente para acesso pelo servidor de gerenciamento.
• Os seguintes componentes exigem acesso à porta 8080 no servidor de gerenciamento: roteador, processador de mensagens, interface, Postgres e Qpid.
• Um processador de mensagens precisa abrir a porta 4528 como porta de gerenciamento. Se você tiver vários processadores de mensagens, todos eles precisam conseguir acessar uns aos outros pela porta 4528 (indicada pela seta de loop no diagrama acima para a porta 4528 no processador de mensagens). Se você tiver vários data centers, a porta precisará estar acessível de todos os processadores de mensagens em todos os data centers.
• Embora não seja obrigatório, você pode abrir a porta 4527 no roteador para acesso por qualquer processador de mensagens. Caso contrário, você poderá ver mensagens de erro nos arquivos de registro do processador de mensagens.
• Um roteador precisa abrir a porta 4527 como porta de gerenciamento. Se você tiver vários roteadores, todos eles precisarão acessar uns aos outros pela porta 4527 (indicada pela seta de loop no diagrama acima para a porta 4527 no roteador).
• A interface do Edge exige acesso ao roteador, nas portas expostas pelos proxies de API, para oferecer suporte ao botão Enviar na ferramenta de rastreamento.
• O servidor de gerenciamento precisa de acesso à porta JMX nos nós do Cassandra.
• O acesso às portas JMX pode ser configurado para exigir um nome de usuário/senha. Consulte Como monitorar para mais informações.
• Você também pode configurar o acesso TLS/SSL para determinadas conexões, que podem usar portas diferentes. Consulte TLS/SSL para mais informações.
• Se você estiver configurando dois nós do Postgres para usar a replicação principal-standby, abra a porta 22 em cada nó para acesso SSH. Você também pode abrir portas em nós individuais para permitir o acesso por SSH.
• É possível configurar o servidor de gerenciamento e a interface do usuário do Edge para enviar e-mails por um servidor SMTP externo. Se sim, verifique se o servidor de gerenciamento e a interface podem acessar a porta necessária no servidor SMTP. Para SMTP sem TLS, o número da porta geralmente é 25. Para SMTP com TLS, geralmente é 465, mas verifique com seu provedor de SMTP.

A tabela abaixo mostra as portas que precisam ser abertas nos firewalls, por componente do Edge:

curl -v http://routerIP:15999/v1/servers/self/reachable

A próxima tabela mostra as mesmas portas, listadas numericamente, com os componentes de origem e destino:

Um processador de mensagens mantém um pool de conexões dedicado aberto para o Cassandra, que é configurado para nunca atingir o tempo limite. Quando há um firewall entre um processador de mensagens e o servidor do Cassandra, ele pode atingir o tempo limite da conexão. No entanto, o processador de mensagens não foi projetado para restabelecer conexões com o Cassandra.

Para evitar essa situação, a Apigee recomenda que o servidor Cassandra, o processador de mensagens e os roteadores estejam na mesma sub-rede para que um firewall não esteja envolvido na implantação desses componentes.

Se houver um firewall entre o roteador e os processadores de mensagens e um tempo limite TCP ocioso definido, recomendamos:

1. Defina net.ipv4.tcp_keepalive_time = 1800 nas configurações do sysctl no SO Linux, em que 1800 precisa ser menor que o tempo limite de inatividade do TCP do firewall. Essa configuração deve manter a conexão em um estado estabelecido para que o firewall não a desconecte.
2. Em todos os processadores de mensagens, edite /opt/apigee/customer/application/message-processor.properties para adicionar a seguinte propriedade. Se o arquivo não existir, crie-o.

   conf_system_cassandra.maxconnecttimeinmillis=-1

3. Reinicie o processador de mensagens:

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

4. Em todos os roteadores, edite /opt/apigee/customer/application/router.properties para adicionar a seguinte propriedade. Se o arquivo não existir, crie-o.

   conf_system_cassandra.maxconnecttimeinmillis=-1

5. Reinicie o roteador:

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

Se você instalar a configuração de cluster de 12 hosts com dois data centers, verifique se os nós nos dois data centers podem se comunicar pelas portas mostradas abaixo:

Requisitos de porta do BaaS da API

Se você optar por instalar o API BaaS, adicione os componentes da pilha e do portal do API BaaS. Esses componentes usam as portas mostradas na figura abaixo:

Observações sobre este diagrama:

• O portal do BaaS da API nunca faz solicitações diretamente a um nó da pilha do BaaS. Quando um desenvolvedor faz login no portal, o app Portal é baixado no navegador. O app do portal em execução no navegador faz solicitações aos nós da BaaS Stack.
• Uma instalação de produção do API BaaS usa um balanceador de carga entre o nó do portal do API BaaS e os nós da pilha do API BaaS. Ao configurar o portal e fazer chamadas de API do BaaS, você especifica o endereço IP ou o nome DNS do balanceador de carga, não dos nós da pilha.
• Todos os nós da pilha precisam abrir a porta 2551 para acesso de todos os outros nós da pilha (indicado pela seta de loop no diagrama acima para a porta 2551 nos nós da pilha). Se você tiver vários data centers, a porta precisará estar acessível em todos os nós do Stack em todos os data centers.
• É necessário configurar todos os nós da Baas Stack para enviar e-mails por um servidor SMTP externo. Para SMTP sem TLS, o número da porta geralmente é 25. Para SMTP habilitado para TLS, geralmente é 465, mas verifique com seu provedor de SMTP.
• Os nós do Cassandra podem ser dedicados ao API BaaS ou compartilhados com o Edge.

A tabela abaixo mostra as portas padrão que precisam ser abertas nos firewalls por componente:

Licenciamento

Cada instalação do Edge requer um arquivo de licença exclusivo que você recebe da Apigee. Você precisará fornecer o caminho para o arquivo de licença ao instalar o servidor de gerenciamento, por exemplo, /tmp/license.txt.

O instalador copia o arquivo de licença para /opt/apigee/customer/conf/license.txt.

Se o arquivo de licença for válido, o servidor de gerenciamento vai validar a expiração e a contagem permitida de processadores de mensagens (MPs, na sigla em inglês). Se alguma das configurações de licença tiver expirado, você poderá encontrar os registros no seguinte local: /opt/apigee/var/log/edge-management-server/logs. Nesse caso, entre em contato com o suporte do Apigee Edge para saber detalhes da migração.

Se você ainda não tiver uma licença, entre em contato com a equipe de vendas da Apigee.