Requisitos de instalação

Requisitos de hardware

Você precisa atender aos seguintes requisitos mínimos de hardware para uma infraestrutura altamente disponível em um ambiente de produção.

O vídeo a seguir oferece orientações gerais sobre o dimensionamento da instalaçã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 rígido necessário para o sistema operacional. Dependendo dos seus aplicativos e do tráfego de rede, a instalação pode exigir mais ou menos recursos do que os listados abaixo.

Componente de instalação RAM CPU Disco rígido mínimo
Cassandra 16 GB 8 núcleos Armazenamento local de 250 GB com SSD com suporte a 2.000 IOPS
Processador/roteador de mensagens na mesma máquina 16 GB 8 núcleos 100 GB
Processador de mensagens (independente) 16 GB 8 núcleos 100 GB
Roteador (independente) 16 GB 8 núcleos 100 GB
Analytics: Postgres/Qpid no mesmo servidor 16GB* 8 núcleos* 500 GB a 1 TB** de armazenamento em rede***, de preferência com back-end SSD, com suporte a 1.000 IOPS ou mais*
Análises: mestre ou standby do Postgres (independente) 16GB* 8 núcleos* 500 GB a 1 TB** de armazenamento em rede***, de preferência com back-end SSD, com suporte a 1.000 IOPS ou mais*
Analytics: Qpid autônomo 8 GB 4 núcleos Armazenamento local de 30 GB a 50 GB com SSD

O tamanho padrão da fila Qpid é 1 GB, que pode ser aumentado para 2 GB. Se você precisar de mais capacidade, adicione outros nós Qpid.
OpenLDAP/UI/Management Server 8 GB 4 núcleos 60 GB
Servidor de interface/gerenciamento 4 GB 2 núcleos 60 GB
OpenLDAP (independente) 4 GB 2 núcleos 60 GB

* Ajuste os requisitos do sistema do Postgres com base na taxa de transferência:

  • Menos de 250 TPS: 8 GB, 4 núcleos podem ser considerados com armazenamento de rede gerenciado*** com suporte a 1.000 IOPS ou mais
  • Mais de 250 TPS: armazenamento de rede gerenciado de 16 GB e 8 núcleos*** com suporte a 1.000 IOPS ou mais
  • Mais de 1.000 TPS: armazenamento de rede gerenciado de 16 GB e 8 núcleos*** que ofereça suporte a 2.000 IOPS ou mais
  • Mais de 2.000 TPS: armazenamento de rede gerenciado de 32 GB e 16 núcleos*** com suporte a 2.000 IOPS ou mais
  • Mais de 4.000 TPS: armazenamento de rede gerenciado de 64 GB, 32 núcleos*** com suporte a 4.000 IOPS ou mais

** O valor do disco rígido do Postgres é baseado nas análises prontas capturadas pelo Edge. Se você adicionar valores personalizados aos dados do Google Analytics, eles vão ser aumentados de acordo. Use a seguinte fórmula para estimar o armazenamento necessário:

bytes of storage needed =

  (# bytes of analytics data/request) *

  (requests/second) *

  (seconds/hour) *

  (hours of peak usage/day) *

  (days/month) *

  (months of data retention)

Exemplo:

(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.4 GB of storage needed

*** O armazenamento em rede é recomendado para o banco de dados Postgresql porque:

  • Ele permite aumentar dinamicamente o tamanho do armazenamento, se e quando necessário.
  • Os IOPS de rede podem ser ajustados em tempo real na maioria dos ambientes/subsistemas de rede/armazenamento atuais.
  • Os snapshots no nível do armazenamento podem ser ativados como parte das soluções de backup e recuperação.

Além disso, confira abaixo os requisitos de hardware para instalar os Serviços de monetização (não compatíveis com a instalação All-in-One):

Componente com monetização RAM CPU Disco rígido
Servidor de gerenciamento (com serviços de monetização) 8 GB 4 núcleos 60 GB
Analytics: Postgres/Qpid no mesmo servidor 16 GB 8 núcleos Armazenamento de rede de 500 GB a 1 TB, de preferência com back-end SSD, compatível com 1.000 IOPS ou mais, ou use a regra da tabela acima.
Analytics: mestre do Postgres ou modo de espera autônomo 16 GB 8 núcleos Armazenamento em rede de 500 GB a 1 TB, de preferência com back-end SSD, compatível com 1.000 IOPS ou mais, ou use a regra da tabela acima.
Analytics: Qpid autônomo 8 GB 4 núcleos Armazenamento local de 40 GB a 500 GB com SSD ou HDD rápido

Para instalações maiores que 250 TPS, é recomendado usar um HDD com armazenamento local compatível com 1.000 IOPS.

Requisitos de largura de banda de rede do Cassandra

O Cassandra usa o protocolo Gossip para trocar informações com outros nós sobre a topologia de rede. O uso do Gossip, combinado com a natureza distribuída do Cassandra, que envolve a comunicação com vários nós para operações de leitura e gravação, resulta em uma transferência significativa de dados pela rede.

O Cassandra requer uma largura de banda de rede mínima de 1 Gbps por nó. Para instalações de produção, é recomendável usar uma largura de banda maior.

A latência máxima ou do 99º percentil do Cassandra deve ser inferior a 100 milissegundos.

Requisitos do sistema operacional e de softwares de terceiros

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

Java

É necessário ter uma versão com suporte 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 a variável de ambiente JAVA_HOME aponta para a raiz do JDK para o usuário que está realizando 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 modo permissivo durante a instalação e reative-o depois. Consulte Instalar o utilitário apigee-setup do Edge para mais informações.

Criar o usuário "apigee"

O procedimento de instalação cria um usuário do sistema Unix chamado "apigee". Os diretórios e arquivos do Edge são de propriedade de "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, é possível 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 desse diretório. Embora não seja possível mudar esse diretório, é possível criar um link simbólico para mapear /opt/apigee para outro local, conforme descrito em Como criar um link simbólico em /opt/apigee.

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

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

Para criar o link simbólico, siga estas etapas antes de fazer o download do arquivo bootstrap_4.52.02.sh. É necessário executar todas essas 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 da instalação e do link simbólico para o usuário "apigee": 
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Configuração da rede

A Apigee recomenda que você verifique 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ários cards 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, que pode não estar correto em todas as situações. Como alternativa, defina a propriedade a seguir no arquivo de configuração de instalação:

ENABLE_DYNAMIC_HOSTIP=y

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

Wrappers TCP

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 OpenLDAP, Postgres e Cassandra necessárias.

iptables

Verifique se não há políticas iptables que impeçam a conectividade entre nós nas portas Edge necessárias. Se necessário, você pode interromper o iptables durante a instalação usando o comando:

sudo/etc/init.d/iptables stop

No CentOS 7.x:

systemctl stop firewalld

Acesso ao diretório

A tabela a seguir lista os diretórios em nós de borda que têm requisitos especiais de processos de borda:

Serviço Diretório Descrição
Roteador /etc/rc.d/init.d/functions

O Edge Router usa o roteador Nginx e requer 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 ser iniciado.

É possível definir as permissões como 744 para permitir o acesso de leitura a /etc/rc.d/init.d/functions.
Zookeeper /dev/random A biblioteca de cliente do Zookeeper requer acesso de leitura ao gerador de números aleatórios /dev/random. Se o /dev/random for bloqueado na leitura, o serviço do Zookeeper poderá não ser iniciado.

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 saber mais, 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 Como ajustar recursos do Java em caso de degradação de desempenho ou consumo de memória alto.

Depois de instalar o Edge para a nuvem particular, você pode verificar 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, você pode ajustar 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 de memlock, nofile e espaço de endereço (as) flexíveis e rígidos para usuário de instalaçã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
apigee soft nproc 32768
apigee hard nproc 65536
  • Nos nós do processador de mensagens, defina o número máximo de descritores de arquivos abertos como 64 KB em /etc/security/limits.d/90-apigee-edge-limits.conf, conforme mostrado abaixo: 
    apigee soft nofile 32768
apigee hard nofile 65536

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

  • Se você receber o seguinte erro em um roteador ou processador de mensagens system.log, os limites do descritor de arquivo podem estar muito baixos:

    "java.io.IOException: Too many open files"

    Para conferir seus limites de usuário, execute:

    # su - apigee
$ ulimit -n
100000

    Se você ainda estiver atingindo os limites de arquivos abertos depois de definir os limites do descritor de arquivos para 100000, abra um tíquete com o suporte do Apigee Edge para mais soluções.

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

Os serviços de segurança de rede (NSS, na sigla em inglês) são um conjunto de bibliotecas que oferecem suporte ao desenvolvimento de aplicativos de cliente e servidor com recursos de segurança. Verifique se você instalou a NSS v3.19 ou mais recente.

Para verificar a versão atual:

yum info nss

Para atualizar o NSS:

yum update nss

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

Desative a pesquisa DNS no IPv6 ao usar o NSCD (Daemon de cache de nome de serviço).

Se você tiver instalado e ativado o NSCD (Name Service Cache Daemon), os processadores de mensagens vão fazer duas pesquisas DNS: uma para IPv4 e outra para IPv6. Desative a pesquisa DNS no IPv6 ao usar o NSCD.

Para desativar a pesquisa 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 CentOS 7 na Google Cloud Platform, será necessário desativar o IPv6 em todos os nós Qpid.

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

  1. Abra /etc/hosts em um editor.
  2. Insira um caractere "#" na coluna 1 da linha a seguir para comentar: 
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. Salve o arquivo.

AWS AMI

Se você estiver instalando o Edge em uma imagem de máquina (AMI) do Amazon Web Services (AWS) para o Red Hat Enterprise Linux 7.x, primeiro execute 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, conforme fornecido pelo EL5 ou EL6.

awk

expr

libxslt

rpm

unzip

basename

grep

lua-socket

rpm2cpio

useradd

bash

 nome do host

ls

sed

wc

bc

id

net-tools

sudo

wget

curl

libaio

perl (de procps)

tar

xerces-c
cyrus-sasl libdb4 pgrep (de procps) tr delícia

data

 libdb-cxx

ps

uuid

chkconfig
dirname libibverbs pwd uname  
escola librdmacm python    

ntpdate

A Apigee recomenda que os horários dos seus servidores estejam sincronizados. Se ainda não estiver configurado, o utilitário ntpdate poderá servir a essa finalidade, verificando se os servidores estão sincronizados. Use yum install ntp para instalar o utilitário. Isso é útil principalmente para replicar configurações do OpenLDAP. Configure o fuso horário do servidor em UTC.

openldap 2.4

A instalação local requer o OpenLDAP 2.4. Se o servidor tiver uma conexão de Internet, o script de instalação do Edge fará o download e instalará o 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, é possível executar yum install openldap-clients openldap-servers para instalar o OpenLDAP.

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

Firewalls e hosts virtuais

O termo virtual geralmente é sobrecarregado no setor de TI, assim como em uma implantação do Apigee Edge for Private Cloud e em hosts virtuais. Para esclarecer, há dois usos principais do termo virtual:

  • Máquinas virtuais (VMs): não são obrigató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 hosts 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 um do outro no alias do host ou na porta da interface.

Como exemplo de nomenclatura, um único servidor físico A pode executar duas VMs, chamadas "VM1" e "VM2". Vamos supor que a "VM1" exponha uma interface Ethernet virtual, que é nomeada "eth0" na VM e recebe o endereço IP 111.111.111.111 pela máquina de virtualização ou por um servidor DHCP de rede. Vamos supor também que a VM2 exponha uma interface Ethernet virtual também chamada de "eth0" e que recebe o endereço IP 111.111.111.222.

Podemos ter um roteador 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 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 expostos pela VM1).

O sistema operacional do host físico pode ter um firewall de rede. Nesse caso, ele precisa ser configurado para transmitir o tráfego TCP vinculado à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 o próprio firewall na interface eth0, e elas também precisam permitir o tráfego das portas 80 e 443 para a conexão.

O caminho base é 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 de base diferentes. Por exemplo, um caminho base 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 diretor de tráfego que divida 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 para sua instalação e é configurada pelo grupo de rede local.

O caminho base é 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 de api.mycompany.com e a porta definida como 80. Se você não declarar um caminho de base 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 de /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/.

Licenciamento

Cada instalação do Edge requer um arquivo de licença exclusivo que você recebe do Apigee. Você vai 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 do processador de mensagens (MP). Se alguma das configurações de licença estiver expirada, 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 mais sobre a migração.

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