Requisitos de instalação

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.

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 necessário pelo 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.

Além disso, a lista a seguir mostra os requisitos de hardware se você quiser instalar os Serviços de monetização (não compatíveis com a instalação tudo em um):

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 exige 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 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.

Pré-requisito: ativar o repositório EPEL

Antes de continuar com a instalação, verifique se o repositório EPEL (Extra Packages for Enterprise Linux) está ativado. Use os seguintes comandos com base na versão do sistema operacional:

• Para Red Hat/CentOS/Oracle 8.X:

  wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

  sudo rpm -ivh epel-release-latest-8.noarch.rpm

• Para Red Hat/CentOS/Oracle 9.X:

  wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

  sudo rpm -ivh epel-release-latest-9.noarch.rpm

Java

Você precisa 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.

Confirme se a variável de ambiente 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.

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 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, execute 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 em Como criar um link simbólico de /opt/apigee.

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

Como criar 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 fazer o download do arquivo bootstrap_4.53.01.sh. É necessário 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 symlink 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 symlink 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 cartões 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, você pode definir 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 de borda para mais informações.

Wrappers TCP

Os wrappers TCP podem bloquear a comunicação de algumas portas e afetar a instalação do SymasLDAP, 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 SymasLDAP, do Postgres e do Cassandra.

iptables

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

sudo/etc/init.d/iptables stop

Acesso ao diretório

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

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 Java em caso de degradação da performance 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, 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

Configuração de localidade para Rocky 9.X

Se você estiver usando o Rocky 9.X, verifique se o sistema está configurado com LANG=en_US.utf8 nas configurações de localidade em todo o sistema. Para configurar isso, execute os seguintes comandos:

dnf -y -q install langpacks-en
localectl set-locale LANG=en_US.utf8
reboot

Limites do sistema

Verifique se você definiu os seguintes limites do sistema nos nós do Cassandra e do Message Processor:

• 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
  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 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.

• Se você encontrar o seguinte erro em um roteador ou processador de mensagens system.log, os limites de descritores de arquivo podem estar definidos como muito baixos:

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

  Para verificar seus limites de usuários, execute:

  # su - apigee
  $ ulimit -n
  100000
  

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

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 cliente e servidor com segurança ativada. Verifique se você instalou o NSS v3.19 ou uma versão 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 pesquisa de DNS no IPv6 ao usar o NSCD (daemon de cache de serviço de nomes)

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 todos os nós do processador de mensagens, edite /etc/nscd.conf
2. Defina a seguinte propriedade:

   enable-cache hosts no

Desativar o IPv6 no RHEL 8 e versões mais recentes

Se você estiver instalando o Edge no RHEL 8 ou em versões mais recentes no Google Cloud Platform, desative o IPv6 em todos os nós do Qpid.

Para instruções sobre como desativar o IPv6, consulte a documentação fornecida pelo fornecedor do SO. Por exemplo, você pode encontrar informações relevantes na documentação do Red Hat Enterprise Linux.

Ferramentas

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

Sincronização de tempo

A Apigee recomenda que os horários dos seus servidores estejam sincronizados. Se ainda não estiver configurado, o utilitário ntpdate ou uma ferramenta equivalente poderá servir para esse propósito, verificando se os servidores estão sincronizados com o tempo. Por exemplo, use yum install ntp ou um comando equivalente para instalar o utilitário. Isso é especialmente útil para replicar configurações do LDAP. Defina o fuso horário do servidor como UTC.

Firewalls e hosts virtuais

O termo virtual é comumente sobrecarregado na área de TI, assim como em uma implantação do Apigee Edge para nuvem privada e 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 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, chamada "eth0" dentro da VM, e que receba 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 a VM2 exponha uma interface Ethernet virtual também chamada "eth0" e que 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 do 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. 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, cada sistema operacional da VM pode fornecer um firewall próprio na interface eth0, e esses também precisam permitir que o tráfego das portas 80 e 443 se conecte.

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 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 de 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 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 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/.

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 mais detalhes sobre a migração.

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