Requisitos de instalação

Requisitos de hardware

Você deve atender aos seguintes requisitos mínimos de hardware para uma em um ambiente de produção.

O vídeo a seguir fornece orientações detalhadas sobre o tamanho da sua 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.

Nestas tabelas, os requisitos de disco rígido são adicionais ao espaço em disco exigido pelo no sistema operacional. Dependendo dos aplicativos e do tráfego de rede, a instalação pode exigem 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 compatível com 2.000 IOPS
Processador/Roteador de mensagens na mesma máquina 16 GB 8 núcleos 100GB
Processador de mensagens (independente) 16 GB 8 núcleos 100GB
Roteador (independente) 16 GB 8 núcleos 100GB
Analytics - Postgres/Qpid no mesmo servidor 16GB* 8 núcleos* 500 GB a 1 TB** de armazenamento de rede***, de preferência com back-end SSD, suporte a 1.000 IOPS ou mais*
Analytics – Postgres mestre ou de espera (independente) 16GB* 8 núcleos* 500 GB a 1 TB** de armazenamento de rede***, de preferência com back-end SSD, suporte a 1.000 IOPS ou mais*
Analytics - Qpid independente 8 GB 4 núcleos 30 GB a 50 GB de armazenamento local com SSD

O tamanho padrão da fila de Qpid é 1 GB, que pode ser aumentado para 2 GB. Se você precisar mais capacidade, adicione outros nós Qpid.
OpenLDAP/interface/servidor de gerenciamento 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 Postgres com base na capacidade de processamento:

  • Menos de 250 TPS: 8 GB, 4 núcleos podem ser considerados com a rede gerenciada armazenamento*** compatível com 1.000 IOPS ou mais
  • Maior que 250 TPS: 16 GB, 8 núcleos, armazenamento de rede gerenciado*** com suporte a 1.000 IOPS ou mais
  • Mais de 1.000 TPS: 16 GB, 8 núcleos, armazenamento de rede gerenciado*** com suporte a 2.000 IOPS ou mais
  • Maior que 2.000 TPS: armazenamento de rede gerenciado de 32 GB, 16 núcleos*** com suporte a 2.000 IOPS ou mais
  • Maior que 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 na análise pronta para uso capturada pelo Edge. Se você adicionar valores personalizados aos dados de análise, esses valores deverão ser aumentados de maneira adequada. 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 de rede é recomendado para o banco de dados Postgresql porque:

  • Permite escalonar dinamicamente o tamanho do armazenamento se e quando obrigatórios.
  • As IOPS de rede podem ser ajustadas instantaneamente na maioria ambiente/armazenamento/subsistemas de rede.
  • Os snapshots no nível de armazenamento podem ser ativados como parte do backup e da recuperação soluções.

Além disso, veja a seguir os requisitos de hardware caso você queira instalar a 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 500 GB a 1 TB de armazenamento de rede, de preferência com back-end SSD, compatível com 1.000 IOPS ou ou use a regra da tabela acima.
Analytics – Postgres mestre ou autônomo 16 GB 8 núcleos 500 GB a 1 TB de armazenamento de rede, de preferência com back-end SSD, compatível com 1.000 IOPS ou ou use a regra da tabela acima.
Analytics - Qpid independente 8 GB 4 núcleos 40 GB a 500 GB de armazenamento local com SSD ou HDD rápido

Para instalações superiores a 250 TPS, o HDD com armazenamento local compatível com 1.000 IOPS é recomendado.

Sistema operacional e terceiros requisitos de software

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

Java

Você precisa de uma versão com suporte do Java 1.8 instalada em cada máquina antes da instalação. Os JDKs com suporte 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 executa a instalação.

SELinux

Dependendo das configurações do SELinux, o Edge pode ter problemas para instalar e iniciar Componentes de borda. Se necessário, você pode desativar o SELinux ou configurá-lo para o modo permissivo durante e reative-a após a instalação. Consulte Instalar o utilitário de configuração da Apigee Apigee para mais informações.

Criando a "apigee" usuário

O procedimento de instalação cria um usuário do sistema Unix chamado "apigee". os diretórios de borda e os arquivos pertencem à "apigee", assim como os processos do Edge. Isso significa que os componentes Edge são executados "apigee" usuário. Se necessário, execute os 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. Você não é possível alterar este local do diretório. Embora não seja possível alterar esse diretório, você pode 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". Isso é do 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.52.02.sh. Você precisa executar todas estas etapas como raiz:

  1. Crie a "apigee" usuário e grupo: 
    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 pretendido dos arquivos do Edge.

  3. Mudar a propriedade da raiz de instalação e do link simbólico para "apigee" usuário: 
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Configuração da rede

A Apigee recomenda que você verifique a configuração da 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 o configuração:

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

Dependendo do tipo e da versão do seu sistema operacional, talvez seja necessário editar /etc/hosts e /etc/sysconfig/network se o nome do host não for 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, a opção retorna uma string separada por espaços lista de endereços IP. Por padrão, o instalador do Edge usa o primeiro endereço IP retornado, que pode não estar correta em todas as situações. Como alternativa, você pode definir a seguinte propriedade em o arquivo de configuração da 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 como parte da instalação. O valor padrão é "n". Consulte Referência do arquivo de configuração do Edge para mais informações.

Wrappers TCP

TCP Wrappers podem bloquear a comunicação de algumas portas e afetar o OpenLDAP, Postgres e Instalação do Cassandra. Nesses nós, verifique /etc/hosts.allow e /etc/hosts.deny para garantir que não haja restrições de porta no Portas OpenLDAP, Postgres e Cassandra.

iptables

Confira se não há políticas de iptables impedindo a conectividade entre nós no e as portas do Edge necessárias. Se necessário, pare o iptables durante a instalação usando o comando 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 nos nós de borda com requisitos especiais 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 para /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 os defina como 700, caso contrário, o roteador não será possível iniciar.

Você pode definir a permissão como 744 para conceder 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 /dev/random estiver bloqueado na leitura, o Talvez o serviço Zookeeper falhe ao iniciar.

Cassandra

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

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

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

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

Banco de dados PostgreSQL

Depois de instalar o Edge, é possível ajustar as seguintes configurações do banco de dados PostgreSQL com base no a 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

    Crie o arquivo se ele não existir.

  2. Defina as propriedades listadas acima.
  3. Salve suas 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 no Cassandra e no processador de mensagens nós:

  • Nos nós do Cassandra, defina limites flexíveis e rígidos de memlock, nofile e espaço de endereço (as) para 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 64 K 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 de arquivos temporários abertos a qualquer momento.

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

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

    Para verificar os limites de usuários, execute este comando:

    # su - apigee
$ ulimit -n
100000

    Se você ainda estiver atingindo os limites de arquivos abertos depois de definir os limites do descritor de arquivo para 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)

O Network Security Services (NSS) é um conjunto de bibliotecas que dá suporte ao desenvolvimento de aplicativos clientes e servidores 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 busca DNS no IPv6 ao usar o Daemon de cache do serviço de nomes (NSCD, na sigla em inglês)

Se você instalou e ativou o NSCD (Name Service Cache Daemon), os processadores de mensagem fazer duas buscas DNS: uma para IPv4 e outra para IPv6. Desative a busca DNS no IPv6 quando usando 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 Plataforma para RedHat/CentOS 7

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

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

  1. Abra /etc/hosts em um editor.
  2. Insira um "#" na coluna 1 da linha a seguir para fazer um comentário: 
    #::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 da Amazon Amazon (AMI) da AWS para 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 do UNIX na versão padrão, conforme fornecido pelo EL5 ou EL6.

awk

expr

libxslt

rpm

unzip

nome de base

grep

lua-socket

rpm2cpio

adicionar usuário

bash

 nome do host

ls

sed

wc

bc

id

Ferramentas de rede

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 libibverbos pwd Uname  
escola librdmacm python    

ntpdate

A Apigee recomenda que os servidores os horários são sincronizados. Caso ainda não esteja configurado, o utilitário ntpdate pode atender a esse propósito, o que verifica se os servidores são sincronizados. Use yum install ntp para instalar o utilitário. Isso é muito útil para replicar configurações do OpenLDAP. Você configurou a configuração em UTC.

openldap 2.4

A instalação local requer o OpenLDAP 2.4. Se o servidor tiver uma conexão com a Internet, o script de instalação do Edge faz o download e instala OpenLDAP. Se o seu servidor não tiver uma conexão com a internet, você deverá assegurar que o OpenLDAP esteja já 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 com 13 hosts e 12 com dois data centers, o OpenLDAP a replicação é necessária porque há vários nós hospedando o OpenLDAP.

Firewalls e hosts virtuais

O termo virtual normalmente fica sobrecarregado na área de TI e, portanto, está com uma Apigee Edge para implantação de nuvem privada e hosts virtuais. Para esclarecer, há dois conceitos usos do termo virtual:

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

Um roteador em uma VM pode expor vários hosts virtuais, desde que sejam diferentes um do outro alias de host ou na porta de interface).

Como exemplo de nomenclatura, um único servidor físico A pode executar duas VMs, chamada "VM1" e "VM2". Vamos supor que "VM1" expõe uma interface Ethernet virtual chamada “eth0” na VM e que recebe o endereço IP 111.111.111.111 o maquinário de virtualização ou um servidor DHCP de rede, e, em seguida, suponha que a VM2 exponha Interface Ethernet também chamada de "eth0" e recebe um 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 hosts virtuais endpoints, como neste exemplo hipotético:

O roteador Apigee na VM1 expõe três hosts virtuais em sua interface eth0 (que tem alguns 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 por VM1).

O sistema operacional do host físico pode ter um firewall de rede. Nesse caso, o firewall precisam ser configurados para transmitir o tráfego TCP vinculado às portas que estão sendo expostas na do aplicativo (111.111.111.111:{80, 443} e 111.111.111.222:80). Em Além disso, o sistema operacional de cada VM pode fornecer seu próprio firewall na interface eth0, e essas também precisa permitir a conexão do tráfego das portas 80 e 443.

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

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

Ele é definido quando você implanta uma API. A partir do exemplo acima, é possível implantar duas APIs, mycompany e testmycompany, para a organização mycompany-org pelo 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á qual API enviar as solicitações recebidas

No entanto, se você implantar a API testmycompany com o URL base de /salesdemo, os usuários acessam essa API usando http://api.mycompany.com:80/salesdemo Se você implantar a API mycompany com o URL de base de /, seus 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 obtido da Apigee. Você vai precisa 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 validará a expiração e a mensagem permitida Contagem de processador (MP). Se alguma das configurações de licença tiver expirado, você poderá encontrar os registros na 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 tem uma licença, entre em contato com a equipe de vendas da Apigee.