Requisitos de instalação

Edge para nuvem privada v. 4.16.09

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. 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 adicionados ao espaço exigido 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.

Componente de instalação

RAM

CPU

Mínimo de disco rígido

Cassandra

16 GB

8 núcleos

250 GB de armazenamento local com SSD ou HDD rápido com suporte a 2.000 IOPS

Processador/roteador de mensagens na mesma máquina

8/16GB

4 núcleos

100GB

Analytics: Postgres/Qpid no mesmo servidor (não recomendado para produção)

16GB*

8 núcleos*

500 GB a 1 TB** de armazenamento de rede***, de preferência com back-end SSD, com suporte a 1.000 IOPS ou mais*.

Google Analytics - Postgres autônomo

16GB*

8 núcleos*

500 GB a 1 TB** de armazenamento de rede***, de preferência com back-end SSD, com suporte a 1.000 IOPS ou mais*.

Analytics: Qpid independente

8 GB

4 núcleos

De 30 GB a 50 GB de armazenamento local com SSD ou HDD rápido

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

Outro (OpenLDAP, UI, Servidor de gerenciamento)

4 GB

2 núcleos

60 GB

† Ajuste os requisitos do sistema do processador de mensagens com base na capacidade:

A recomendação mínima é de 4 núcleos e 8 núcleos para um sistema de alta capacidade. Execute testes de desempenho para determinar o tamanho ideal das suas APIs.

*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 armazenamento de rede gerenciado*** compatível com 1.000 IOPS ou mais
  • Mais de 250 TPS: 16 GB, 8 núcleos, armazenamento de rede gerenciado*** com suporte para 1.000 IOPS ou mais
  • Mais de 1.000 TPS: 16 GB, 8 núcleos, armazenamento de rede gerenciado*** com suporte para 2.000 IOPS ou mais
  • Mais de 2.000 TPS: 32 GB, 16 núcleos, armazenamento de rede gerenciado*** com suporte para 2.000 IOPS ou mais
  • Mais de 4.000 TPS: 64 GB, 32 núcleos, armazenamento de rede gerenciado*** com suporte para 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 precisarão ser aumentados adequadamente. Use a seguinte fórmula para estimar o armazenamento necessário:

(# bytes/solicitação) * (solicitações por segundo) * (segundos por hora) * (horas de pico de uso por dia) * (dias por mês) * (meses de retenção de dados) = bytes de armazenamento necessário

Por exemplo:

(2 mil bytes de dados de análise por solicitação, * 100 s/s

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

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

Além disso, a lista a seguir apresenta os requisitos de hardware para instalar os Serviços de monetização:

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

De 500 GB a 1 TB de armazenamento de rede, de preferência com back-end SSD, com suporte a 1.000 IOPS ou mais, ou use a regra da tabela acima.

Google Analytics - Postgres autônomo

16 GB

8 núcleos

De 500 GB a 1 TB de armazenamento de rede, de preferência com back-end SSD, com suporte a 1.000 IOPS ou mais, ou use a regra da tabela acima.

Analytics: Qpid independente

8 GB

4 núcleos

40 GB

Confira a seguir os requisitos de hardware para instalar o BaaS da API:

Componente API BaaS

RAM

CPU

Disco rígido

ElasticSearch*

8 GB

4 núcleos

60 a 80 GB

Pilha BaaS da API *

8 GB

4 núcleos

60 a 80 GB

Portal da API BaaS

1 GB

2 núcleos

20GB

Cassandra (opcional: normalmente você usa o mesmo cluster do Cassandra para os serviços do Edge e da API BaaS)

16 GB

8 núcleos

250 GB de armazenamento local com SSD ou HDD rápido com suporte a 2.000 IOPS

* É possível instalar o ElasticSearch e a API BaaS Stack no mesmo nó. Se você fizer isso, configure o ElasticSearch para usar 4 GB de memória (padrão). Se o ElasticSearch estiver instalado no próprio nó, configure-o para usar 6 GB de memória.

Observação:

  • Se o sistema de arquivos raiz não for grande o suficiente para a instalação, é recomendável colocar os dados em um disco maior.
  • Se uma versão mais antiga do Apigee Edge para nuvem privada estiver instalada na máquina, exclua a pasta /tmp/java antes de uma nova instalação.
  • A pasta temporária /tmp precisa de permissões de execução para iniciar o Cassandra.
  • Se o usuário “apigee” foi criado antes da instalação, verifique se “/home/apigee” existe como diretório principal e é de propriedade de “apigee:apigee”.

Requisitos do sistema operacional e de software de terceiros

Estas instruções de instalação e os arquivos de instalação fornecidos foram testados nos sistemas operacionais e nos softwares de terceiros listados aqui: https://apigee.com/docs/api-services/reference/supported-software.

Como 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 de borda são de propriedade da "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, eles poderão ser executados como um usuário diferente. Consulte "Como vincular o roteador a uma porta protegida" em Instalar componentes de borda em um nó para ver um exemplo.

Diretório de instalação

Por padrão, o instalador grava todos os arquivos no diretório /opt/apigee. Não é possível alterar o local desse diretório.

Nas instruções deste guia, o diretório de instalação é indicado como /<inst_root>/apigee, em que /<inst_root> é /opt por padrão.

Java

Você precisa de uma versão com suporte do Java1.8 instalada em cada máquina antes da instalação. Os JDKs compatíveis estão listados aqui:

https://apigee.com/docs/api-services/reference/supported-software

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

Configuração de rede

É recomendável verificar as configurações de rede antes da instalação. O instalador espera que todas as máquinas tenham endereços IP fixos. Use os seguintes comandos 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 endereçado em 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 estiver definido corretamente. Consulte a documentação do seu sistema operacional para mais informações.

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 de borda determina os nós do Cassandra em que as réplicas são colocadas. Para saber mais,consulte Sobre o fator de replicação do Cassandra e o nível de consistência.

O Cassandra ajusta automaticamente o tamanho da pilha Java com base na memória disponível. Para mais informações, consulte Como ajustar recursos do Java. No caso de queda no 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 /<inst_root>/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
  • particionador
  • sementes
  • listen_address
  • rpc_address
  • detalhar

Aviso: não edite esse arquivo.

Banco de dados PostgreSQL

Depois de instalar o Edge, é possível 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 postgresql.properties:
    > vi /<inst_root>/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:
    > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

jsvc

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

Serviços de segurança de rede (NSS, na sigla em inglês)

Os serviços de segurança de rede (NSS, na sigla em inglês) são um conjunto de bibliotecas com suporte ao desenvolvimento de aplicativos 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 (em inglês) da RedHat para saber mais.

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

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

Consulte a documentação do RedHat ou CentOS da sua versão específica do sistema operacional para instruções sobre como desativar o IPv6.

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, 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 pela EL5 ou EL6.

awk

dirname

ls

rpm

unzip

basename

echo

perl

rpm2cpio

adição de usuário

bash

expr

pgrep (de procps)

sed

wc

bc

grep

ps

tar

delícia

curl

nome do host

pwd

tr

chkconfig

date

id

python

uname

sudo

Observação:

  • O executável da ferramenta "useradd" está localizado em /usr/sbin e para chkconfig em /sbin.
  • Com o acesso sudo, é possível ter acesso ao ambiente do usuário que fez a chamada. Por exemplo, normalmente você chama "sudo <command>" ou "sudo PATH=$PATH:/usr/sbin:/sbin <command>".
  • Verifique se a ferramenta “patch” está instalada antes da instalação de um pacote de serviços (patch).

ntpdate: é recomendável que o horário dos servidores seja sincronizado. Se ainda não estiver configurado, o utilitário "ntpdate" pode servir para essa finalidade, que verifica se os servidores estão sincronizados. Use "yum install ntp" para instalar o utilitário. Isso é muito útil para replicar configurações do OpenLDAP. Você configurou o fuso horário do servidor em 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 vai fazer o download e instalar o OpenLDAP. Se o servidor não tiver uma conexão com a Internet, verifique se o OpenLDAP já está instalado antes de executar o script de instalação do Edge. No php/CentOS, execute "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, é necessário a replicação OpenLDAP, porque há vários nós hospedando o OpenLDAP.

Firewalls e hosts virtuais

O termo "virtual" geralmente fica sobrecarregado na área de TI e também está com o Apigee Edge para implantação de nuvem privada e hosts virtuais. Para esclarecer, há dois usos principais do termo "virtual":

  • Máquinas virtuais (VM): não são obrigatórias, mas algumas implantações usam tecnologia de VM para criar servidores isolados para os componentes da Apigee. Os hosts de VM, assim como os físicos, podem ter interfaces de rede e firewalls. Estas instruções de instalação não oferecem suporte específico a instalações de VM.
  • 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 no alias do host ou na porta da interface.

Como exemplo, um único servidor físico "A" pode estar executando duas VMs, chamadas "VM1" e "VM2". Vamos supor que a VM1 exponha uma interface Ethernet virtual que recebe o nome eth0 dentro da VM e recebe o endereço IP 111.111.111.111 pela máquina de virtualização ou uma interface DHCP1 de rede.

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

O roteador da Apigee na VM1 expõe três hosts virtuais na interface eth0 (que tem alguns endereços IP específicos), 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, esse firewall precisa ser configurado para passar o tráfego TCP vinculado às portas que estão sendo expostas nas interfaces virtualizadas (111.111.111.111:{80, 443} e 111.111.111.222:80). Além disso, cada sistema operacional de VM pode fornecer o próprio firewall na interface eth0, e eles 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 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 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 para sua instalação específica e é configurada pelo grupo de rede local.

Ele é 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 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, então 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 /, seus usuários acessarão 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 de VM e de host físico precisam permitir o tráfego para as portas exigidas pelos componentes para se comunicarem entre si.

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

Observações neste diagrama:

  • *A porta 8082 no processador de mensagens só precisa estar aberta para acesso pelo roteador quando você configurar o 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 porta 8082 da configuração padrão 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 serem acessadas pelo servidor de gerenciamento.
  • Os componentes a seguir exigem acesso à porta 8080 no servidor de gerenciamento: Router, Message Processor, UI, Postgres e Qpid.
  • Um processador de mensagens precisa abrir a porta 4528 como a porta de gerenciamento. Se você tiver vários processadores de mensagens, todos poderão acessar uns aos outros pela porta 4528 (indicado pela seta de loop no diagrama acima na porta 4528 do processador de mensagens). Se você tiver vários data centers, a porta precisa ser acessível para todos os processadores de mensagens de todos os data centers.
  • Embora não seja necessário, você pode abrir a porta 4527 no roteador para acesso por qualquer processador de mensagens. Caso contrário, você pode receber mensagens de erro nos arquivos de registro do processador de mensagens.
  • Um roteador precisa abrir a porta 4527 como a 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 do roteador).
  • A interface do Edge requer acesso ao roteador, nas portas expostas por proxies de API, para oferecer suporte ao botão Enviar na ferramenta de trace.
  • O servidor de gerenciamento requer acesso à porta JMX nos nós do Cassandra.
  • O acesso às portas JMX pode ser configurado para exigir nome de usuário e senha. Consulte Como monitorar para mais informações.
  • Também é possível 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 mestre em espera, precisará abrir a porta 22 em cada nó para ter acesso SSH. Também é possível abrir portas em nós individuais para permitir o acesso SSH.
  • É possível configurar o Servidor de gerenciamento e a IU de borda para enviar e-mails por meio de um servidor SMTP externo. Se você fizer isso, verifique se o servidor de gerenciamento e a IU podem acessar a porta necessária no servidor SMTP. Para SMTP sem TLS, o número da porta geralmente é 25. Para SMTP com TLS ativado, ele geralmente é 465, mas verifique com seu provedor SMTP.

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

Componente

Port

Descrição

Portas HTTP padrão

80, 443

HTTP mais quaisquer outras portas que você usar para hosts virtuais

Servidor de gerenciamento

8080

Porta para chamadas da API de gerenciamento de borda. Esses componentes exigem acesso à porta 8080 no servidor de gerenciamento: Router, Message Processor, UI, Postgres e Qpid.

1099

Porta JMX

4526

Para chamadas de gerenciamento e cache distribuídos

IU de gerenciamento

9000

Porta de acesso do navegador à interface de gerenciamento

Processador de mensagens

8998

Porta do processador de mensagens para comunicações do roteador

8082

Porta de gerenciamento padrão do processador de mensagens e precisa estar aberta no componente para acesso pelo servidor de gerenciamento.

Se você configurar o TLS/SSL entre o roteador e o processador de mensagens, usado pelo roteador para fazer verificações de integridade no processador de mensagens.

1101

Porta JMX

4528

Para chamadas de gerenciamento e cache distribuídos entre processadores de mensagens e para comunicação do roteador

Roteador

8081

Porta de gerenciamento padrão do roteador e precisa estar aberta no componente para acesso pelo servidor de gerenciamento.

4527

Para chamadas de gerenciamento e cache distribuídos

15999

Porta de verificação de integridade. Um balanceador de carga usa essa porta para determinar se o roteador está disponível.

Para saber o status de um roteador, o balanceador de carga faz uma solicitação para a porta 15999 nele:

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

Se o roteador estiver acessível, a solicitação retornará HTTP 200.

ZooKeeper

2181

Usado por outros componentes, como servidor de gerenciamento, roteador, processador de mensagens e assim por diante

2.888.3.888

Usado internamente pelo ZooKeeper para a comunicação do cluster ZooKeeper (conhecido como conjunto do ZooKeeper)

Cassandra

7.000, 9.042, 9.160

Portas do Apache Cassandra para comunicação entre os nós do Cassandra e acesso por outros componentes do Edge.

7199

Porta JMX. Precisa estar aberto para acesso pelo servidor de gerenciamento.

Qpid (em inglês)

5672

Usado para comunicações do roteador e do processador de mensagens para o servidor Qpid

8083

Porta de gerenciamento padrão no servidor Qpid e precisa estar aberta no componente para acesso pelo servidor de gerenciamento.

1102

Porta JMX

4529

Para chamadas de gerenciamento e cache distribuídos

Postgres (em inglês)

5432

Usado para comunicação do Qpid/Management Server para o Postgres

8084

Porta de gerenciamento padrão no servidor Postgres e precisa estar aberta no componente para acesso pelo servidor de gerenciamento.

1103

Porta JMX

4530

Para chamadas de gerenciamento e cache distribuídos

22

Se você estiver configurando dois nós do Postgres para usar a replicação mestre em espera, precisará abrir a porta 22 em cada nó para ter acesso SSH.

LDAP

10389

OpenLDAP

SmartDocs

59002

A porta no roteador de borda para onde as solicitações de página do SmartDocs são enviadas.

Observação: também pode ser necessário abrir portas nos firewalls para fazer testes. Por exemplo, 59001 e assim por diante.

A tabela a seguir mostra as mesmas portas, listadas numericamente, com os componentes de origem e destino:

Número da porta

Propósito

Componente de origem

Componente de destino

<porta do host virtual#>

HTTP mais todas as outras portas que você usa para o tráfego de chamadas da API do host virtual. As portas 80 e 443 são as mais usadas. O roteador de mensagens pode encerrar conexões TLS/SSL.

Cliente externo (ou balanceador de carga)

Listener no roteador de mensagens

De 1099 a 1103

Gerenciamento do JMX

Cliente JMX

Servidor de gerenciamento (1099)

Processador de mensagens (1101)

Servidor Qpid (1102)

Servidor Postgres (1103)

2.181

Comunicação com o cliente do Zookeeper

Servidor de gerenciamento

Roteador

processador de mensagens

Servidor Qpid

Servidor Postgres

Zookeeper

2888 e 3888

Gerenciamento de tráfego interno do Zookeeper

Zookeeper

Zookeeper

4.526 a 4530

Portas de gerenciamento de RPC usadas para cache distribuído e chamadas dos servidores de gerenciamento para outros componentes

Servidor de gerenciamento

Servidor de gerenciamento (4526)

Roteador (4527)

Processador de mensagens (4528)

Servidor Qpid (4529)

Servidor Postgres (4530)

4.528

Para chamadas de cache distribuídas entre processadores de mensagens e para comunicação do roteador

Roteador

processador de mensagens

processador de mensagens

5.432 (link em inglês)

Cliente Postgres

Servidor Qpid

Postgres

5.672

Usado para enviar análises do roteador e do processador de mensagens ao Qpid

Roteador

processador de mensagens

Servidor Qpid

7000

Comunicações entre nós do Cassandra

Cassandra

Outro nó do Cassandra

7.199 (link em inglês)

Gerenciamento do JMX. Precisa estar aberto para acesso ao nó do Cassandra pelo servidor de gerenciamento.

Cliente JMX

Cassandra

8080

Porta da API Management

Clientes da API Management

Servidor de gerenciamento

8081 a 8084

Portas da API do componente, usadas para emitir solicitações de API diretamente para componentes individuais. Cada componente abre uma porta diferente. A porta exata usada depende da configuração, mas precisa estar aberta no componente para acesso pelo servidor de gerenciamento

Clientes da API Management

Roteador (8081)

Processador de mensagens (8082)

Servidor Qpid (8083)

Servidor Postgres (8084)

8.998

Comunicação entre um roteador e um processador de mensagens

Roteador

processador de mensagens

9.000

Porta da interface padrão do gerenciamento de borda

Navegador

Servidor de interface de gerenciamento

9042 (link em inglês)

Transporte nativo CQL

Roteador

processador de mensagens

Servidor de gerenciamento

Cassandra

9.160 (link em inglês)

Cassandra thrift client

Roteador

processador de mensagens

Servidor de gerenciamento

Cassandra

10.389 (link em inglês)

Porta LDAP

Servidor de gerenciamento

OpenLDAP

15.999

Porta de verificação de integridade. Um balanceador de carga usa essa porta para determinar se o roteador está disponível.

Balanceador de carga Roteador

59.002 (link em inglês)

A porta do roteador para onde as solicitações da página do SmartDocs são enviadas

SmartDocs

Roteador

Um processador de mensagens mantém um pool de conexão dedicado aberto para o Cassandra, que é configurado para nunca atingir o tempo limite. Quando um firewall está 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 as conexões com o Cassandra.

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

Se um firewall estiver entre o roteador e os processadores de mensagens e tiver um tempo limite de tcp inativo definido, nossas recomendações são:

  1. Defina net.ipv4.tcp_keepalive_time = 1800 nas configurações do sysctl no SO Linux, em que 1800 deve ser menor que o tempo limite de tcp de inatividade do firewall. Essa configuração precisa manter a conexão em um estado estabelecido para que o firewall não a desconecte.
  2. Em todos os processadores de mensagens, edite /<inst_root>/apigee/customer/application/message-processor.properties para adicionar a propriedade a seguir. Se o arquivo não existir, crie-o.
    conf_system_casssandra.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 /<inst_root>/apigee/customer/application/router.properties para adicionar a propriedade a seguir. Se o arquivo não existir, crie-o.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  5. Reinicie o roteador:
    > /opt/apigee/apigee-service/bin/apigee-service cloud-router restart

Se você instalar a configuração em cluster do host 12 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ê decidir instalar a API BaaS, vai adicionar os componentes da pilha de API BaaS e do portal de BaaS de API. Esses componentes usam as portas mostradas na figura abaixo:

Observações neste diagrama:

  • O portal da API BaaS nunca faz solicitações diretamente para um nó da pilha do BaaS. Quando um desenvolvedor faz login no portal, o app é transferido por download para o navegador. O app do portal em execução no navegador faz solicitações aos nós da pilha BaaS.
  • Uma instalação de produção do BaaS da API usa um balanceador de carga entre o nó do portal do BaaS da API e os nós da pilha da API do BaaS. Ao configurar o portal e fazer chamadas da API BaaS, especifique o endereço IP ou o nome DNS do balanceador de carga, não dos nós da pilha.
  • É preciso configurar todos os nós da pilha Baas para enviar e-mails por um servidor SMTP externo. Para SMTP sem TLS, o número da porta geralmente é 25. Para SMTP com TLS ativado, ele geralmente é 465, mas verifique com seu provedor SMTP.
  • Os nós do Cassandra podem ser dedicados à API BaaS ou compartilhados com o Edge.

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

Componente

Port

Descrição

Portal da API BaaS

9000

Porta da interface da API BaaS

Pilha BaaS da API

8080

Porta em que a solicitação de API é recebida

ElasticSearch

9.200 a 9.400

Para comunicação com a API BaaS Stack e comunicação entre nós do ElasticSearch

Licenciamento

Cada instalação do Edge requer um arquivo de licença exclusivo recebido 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 /<inst_root>/apigee/customer/conf/license.txt.

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