Requisitos de instalação

Edge for Private Cloud v. 4.16.05

Requisitos de hardware

Você deve atender aos seguintes requisitos mínimos de hardware para uma 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 as 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 ou HDD rápido com suporte a 2.000 IOPS

Roteador/processador de mensagens na mesma máquina

8/16GB

4 núcleos

100GB

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

16 GB*

8 núcleos*

500 GB - 1 TB** de armazenamento de rede***, de preferência com back-end SSD, compatível com 1000 IOPS ou superior*.

Analytics – Postgres independente

16GB*

8 núcleos*

500 GB - 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

30 GB a 50 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.

Outro (OpenLDAP, interface, servidor de gerenciamento)

4 GB

2 núcleos

60 GB

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

A recomendação mínima é de quatro núcleos e oito núcleos para um sistema com alta capacidade de processamento. Você pode executar testes de desempenho para determinar o tamanho ideal para suas APIs.

*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: 16 GB, 8 núcleos, armazenamento de rede gerenciado*** compatível com 1000 IOPS ou superior
  • Mais de 1.000 TPS: armazenamento de rede gerenciado de 16 GB e 8 núcleos*** com suporte a 2.000 IOPS ou mais
  • Mais de 2.000 TPS: armazenamento de rede gerenciado de 32 GB, 16 núcleos*** compatível com 2000 IOPS ou superior
  • Mais de 4.000 TPS: armazenamento de rede gerenciado de 64 GB e 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 Borda Se você adicionar valores personalizados aos dados de análise, esses valores devem ser aumenta proporcionalmente. 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ários

Por exemplo:

(2 mil bytes de dados de análise por solicitação) * 100 solicitações/s * 3.600 segundos/hora * pico de 18 horas uso por dia * 30 dias/mês * 3 meses de retenção = 1.194.393.600.000 bytes ou 1.194,4 GB.

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

  • Ele permite aumentar dinamicamente o tamanho do armazenamento, se e quando necessário.
  • 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 das soluções de backup e recuperação.

Além disso, a seguir estão listados os requisitos de hardware caso você queira instalar a 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

Análises: 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 independente

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

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

Componente BaaS da API

RAM

CPU

Disco rígido

ElasticSearch*

8 GB

4 núcleos

60 a 80 GB

API BaaS Stack *

8 GB

4 núcleos

60 a 80 GB

Portal do API BaaS

1 GB

2 núcleos

20GB

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

16 GB

8 núcleos

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

* É possível instalar o ElasticSearch e a pilha de APIs BaaS no mesmo nó. Nesse caso, configurar o ElasticSearch para usar 4 GB de memória (padrão). Se o ElasticSearch estiver instalado um nó próprio e configurá-lo 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, verifique se que você exclua a pasta /tmp/java antes de uma nova instalação.
  • A pasta temporária /tmp do sistema precisa de permissões de execução para iniciar o Cassandra.
  • Se o usuário "apigee" tiver sido criado antes da instalação, verifique se "/home/apigee" existe como diretório principal e é propriedade do "apigee:apigee".

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 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 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, é possível executar os componentes como um usuário diferente. Consulte "Vincular o roteador a uma porta protegida" em Instalar componentes do Edge em um nó para conferir 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 isso local do diretório.

Nas instruções deste guia, o diretório de instalação é indicado como /<inst_root>/apigee, em que /<inst_root>/apigee é /<inst_root>/apigee 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 com suporte estão listados aqui:

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

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

Configuração de rede

Recomendamos 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 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 acessado de 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.

Cassandra

Todos os nós do Cassandra precisam estar conectados a um anel.

O Cassandra ajusta automaticamente o tamanho de heap do Java com base na memória disponível. Para mais informações, consulte Como ajustar o Java do Google Cloud. Em 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 /<inst_root>/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
  • particionador
  • sementes
  • listen_address
  • rpc_address
  • informar

Aviso: não edite o arquivo.

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. Editar 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 API BaaS. A versão 1.0.15-dev é instalada ao instalar o BaaS de API.

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 o NSS v3.19 ou mais recente.

Para verificar sua versão atual:

> yum info nss

Para atualizar o NSS:

> yum update nss

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

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

dirname

ls

rpm

unzip

nome de base

escola

perl

rpm2cpio

useradd

bash

expr

pgrep (de procps)

sed

wc

bc

grep

ps

tar

delícia

curl

nome do host

pwd

tr

chkconfig

data

id

python

Uname

sudo

Observação:

  • O executável para a ferramenta "useradd" está localizado em /usr/sbin e para chkconfig em /sbin.
  • Com o acesso sudo, você pode ter acesso pelo ambiente do usuário que faz a chamada, por exemplo, geralmente, você chamaria "sudo <command>" ou “sudo PATH=$PATH:/usr/sbin:/sbin <comando>".
  • Verifique se a ferramenta “patch” está instalada antes de um service pack (patch) e instalação.

ntpdate: é recomendável sincronizar o horário dos servidores. Se ainda não estiver configurado, o utilitário "ntpdate" pode atender a essa finalidade, 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 no local exige o OpenLDAP 2.4. Se seu servidor tiver uma conexão com a Internet, o script de instalação de borda será baixado e instalado 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&quot; para instalar o OpenLDAP.

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

Firewalls e hosts virtuais

O termo "virtual" geralmente fica sobrecarregado no campo da TI, portanto, 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. Estas instruções de instalação não oferecem suporte especificamente Instalações de VM.
  • 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, chamados "VM1" e "VM2". Vamos supor que a VM1 exponha uma conexão Ethernet virtual interface, chamada eth0 na VM e que recebeu o endereço IP 111.111.111.111 pela virtualização máquina virtual ou um servidor DHCP de rede, e suponha que a VM2 exponha uma interface Ethernet virtual chamada eth0, 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 que exposto pela 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 (111.111.111.111:{80, 443} e 111.111.111.222:80). Além disso, cada O sistema operacional da VM pode fornecer um firewall próprio na interface eth0, que 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 outro definido como http://api.mycompany.com:80/salesdemo.

Nesse caso, você precisa de um balanceador de carga ou diretor de tráfego de algum tipo para dividir 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ífico para sua instalação e é configurado pelo seu 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 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 vão acessar essa API usando http://api.mycompany.com:80/salesdemo. Se você implantar a API mycompany com o URL base de / e seus usuários acessarem a API pelo URL http://api.mycompany.com:80/.

Requisitos da porta de borda

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

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

Observações sobre o diagrama:

  • *A porta 8082 no processador de mensagens só precisa estar aberta para acesso pelo roteador quando você configurar TLS/SSL entre o roteador e o processador de mensagens. Se você não configurar TLS/SSL entre o roteador e o processador de mensagens, a configuração padrão, a porta 8082, ainda precisa aberto no Processador de Mensagens para gerenciar o componente, mas o Roteador não exige acesso a ele.
  • As portas com prefixo "M" são usadas para gerenciar o componente e precisam estar abertas no componente para acesso pelo servidor de gerenciamento.
  • Os componentes a seguir precisam de 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 a porta de gerenciamento. Se você tiver vários processadores de mensagens, todos eles precisarão ser acessados pela porta 4528 (indicada pela seta de loop no diagrama acima para a porta 4528 no processador de mensagens). Se você tem vários Data centers, a porta precisa estar acessível a todos os processadores de mensagens de todos os data centers.
  • Embora não seja obrigatório, você pode abrir a porta 4527 no Roteador para acesso por qualquer Processador Caso contrário, talvez você veja 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, eles devem poder acessar uns aos outros pela porta 4527 (indicado pela seta de loop diagrama acima para a porta 4527 do roteador).
  • A interface do Edge exige acesso ao roteador, nas portas expostas por proxies de API, para oferecer suporte o botão Send na ferramenta de trace.
  • O servidor de gerenciamento precisa de acesso à porta JMX no Cassandra nós.
  • O acesso às portas JMX pode ser configurado para exigir um nome de usuário/senha. Consulte Como monitorar para mais informações.
  • Você pode configurar o acesso TLS/SSL para determinadas conexões, que podem usar portas diferentes. Consulte TLS/SSL para mais.
  • Ao configurar dois nós do Postgres para usar a replicação mestre-em espera, será necessário abrir a porta 22 em cada nó para acesso SSH. Também é possível abrir portas em nós individuais para permitir SSH.
  • É possível configurar o Management Server e a interface do Edge para enviar e-mails por um servidor SMTP externo. Nesse caso, verifique se o servidor de gerenciamento e a interface podem acessar as no servidor SMTP. Para SMTP não TLS, o número da porta normalmente é 25. Para TLS ativado SMTP, geralmente é a 465, mas verifique com o seu provedor SMTP.

A tabela abaixo mostra as portas que precisam ser abertas em firewalls por componente de borda:

Componente

Port

Descrição

Portas HTTP padrão

80, 443

HTTP e outras portas usadas para hosts virtuais

Servidor de gerenciamento

8080

Porta para chamadas da API Edge Management. Esses componentes precisam ter acesso à porta 8080 do servidor de gerenciamento: Router, processador de mensagens, interface, Postgres e Qpid.

1099

Porta JMX

4526

Para chamadas de gerenciamento e cache distribuído

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 para o processador de mensagens e deve estar aberta no componente para gerenciado pelo servidor de gerenciamento.

Se você configurar TLS/SSL entre o roteador e o processador de mensagens, usado pelo roteador para verificar a integridade do processador de mensagens.

1101

Porta JMX

4528

Para cache distribuído e chamadas de gerenciamento 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

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 disponíveis.

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

> 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 o servidor de gerenciamento, o roteador, o processador de mensagens e assim por diante

2.888 a 3.888

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

Cassandra

7.000, 9.042 e 9.160

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

7199

Porta JMX. Precisa estar aberto para o acesso do servidor de gerenciamento.

Qpid

5672

Usado para comunicações do roteador e do processador de mensagens com 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

Chamadas de gerenciamento e cache distribuídos

Postgres

5432

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

8084

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

1103

Porta JMX

4530

Chamadas de gerenciamento e cache distribuídos

22

Ao configurar dois nós do Postgres para usar a replicação mestre-em espera, é preciso abrir porta 22 em cada nó para acesso SSH.

LDAP

10389

OpenLDAP

SmartDocs

59002

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

Observação: talvez seja necessário abrir portas nos firewalls para fazer testes. Para exemplo, 59001 e assim por diante.

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

Número da porta

Objetivo

Componente de origem

Componente de destino

<virtual host port#>

o HTTP e todas as outras portas usadas para tráfego de chamadas de API do host virtual. portas 80 e 443 são os mais usados. o roteador de mensagens pode encerrar conexões TLS/SSL.

Cliente externo (ou balanceador de carga)

Ouvinte no Message Router

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 do cliente Zookeeper

Servidor de gerenciamento

Roteador

processador de mensagens

Servidor Qpid

Servidor Postgres

Zookeeper

2888 e 3888

Gerenciamento de internós do Zookeeper

Zookeeper

Zookeeper

4526 a 4530

Portas de Gerenciamento de RPC usadas para cache distribuído e chamadas dos servidores de gerenciamento aos 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 a comunicação do roteador

Roteador

processador de mensagens

processador de mensagens

5.432

Cliente Postgres

Servidor Qpid

Postgres

5.672

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

Roteador

processador de mensagens

Servidor Qpid

7.000

Comunicações entre nós do Cassandra

Cassandra

Outro nó do Cassandra

7.199

Gerenciamento de JMX. Precisa estar aberto para acesso no nó do Cassandra pelo gerenciador Servidor.

Cliente JMX

Cassandra

8080

Porta da API Management

Clientes da API de gerenciamento

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 deve estar aberto no componente para acesso pelo servidor de gerenciamento

Clientes da API de gerenciamento

Roteador (8081)

Processador de mensagens (8082)

Servidor Qpid (8083)

Servidor Postgres (8084)

8.998

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

Roteador

processador de mensagens

9.000

Porta da interface de gerenciamento padrão do Edge

Navegador

Servidor da interface de gerenciamento

9.042

Transporte nativo CQL

Roteador

processador de mensagens

Servidor de gerenciamento

Cassandra

9.160

Cliente econômico do Cassandra

Roteador

processador de mensagens

Servidor de gerenciamento

Cassandra

10.389 (link em inglês)

Porta LDAP

Servidor de gerenciamento

OpenLDAP

15999 Porta de verificação de integridade. Um balanceador de carga usa essa porta para determinar se o roteador disponíveis. Balanceador de carga Roteador

59002

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ões dedicado aberto para o Cassandra, que é configurado para nunca exceder o tempo limite. Quando um firewall está entre um processador de mensagens e o servidor do Cassandra, a o firewall da conexão poderá atingir o tempo limite. No entanto, o processador de mensagens não foi projetado restabelecer as conexões com o Cassandra.

Para evitar essa situação, a Apigee recomenda que o servidor do Cassandra, o processador de mensagens e da rede estejam na mesma sub-rede, de modo que o firewall não se envolva na implantação desses componentes de solução.

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

  1. Defina net.ipv4.tcp_keepalive_time = 1800 nas configurações de sysctl no SO Linux, em que 1800 deve ser menor que o firewall inativo Tempo limite do TCP. Essa configuração deve manter a conexão em um estado estabelecido para que o firewall não desconecta a conexão.
  2. Em todos os processadores de mensagens, edite /<inst_root>/apigee/customer/application/message-processor.properties para adicionar a propriedade a seguir. Crie o arquivo se ele não existir.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  3. Reinicie o processador de mensagens:
    &gt; /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor restart
  4. Em todos os roteadores, edite /&lt;inst_root&gt;/apigee/customer/application/router.properties. para adicionar a seguinte propriedade. Crie o arquivo se ele não existir.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  5. Reinicie o roteador:
    &gt; /opt/apigee/apigee-service/bin/apigee-service Edge-router restart

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

Requisitos de porta do BaaS da API

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

Observações sobre o diagrama:

  • Os nós do Cassandra podem ser dedicados ao API BaaS ou compartilhados com o Edge.
  • Uma instalação de produção da API BaaS usa um balanceador de carga entre o nó do Portal da API BaaS e os nós da pilha da API BaaS. Ao configurar o portal e fazer chamadas de API BaaS, você especifique o endereço IP ou o nome do DNS do balanceador de carga, e não dos nós da pilha.
  • É necessário configurar todos os nós do Baas Stack para enviar e-mails por um servidor SMTP externo. Para SMTP não TLS, o número da porta normalmente é 25. Para SMTP com TLS ativado, geralmente é 465, mas verifique com seu provedor de SMTP.

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

Componente

Port

Descrição

Portal de APIs BaaS

9000

Porta da interface do BaaS da API

Pilha BaaS de API

8080

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

ElasticSearch

9.200 a 9.400

Para se comunicar com a pilha API BaaS e entre nós do ElasticSearch

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 /&lt;inst_root&gt;/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 tiver expirado, você poderá encontrar os registros na seguinte local: /&lt;inst_root&gt;/apigee/var/log/edge-management-server/logs. Nesse caso, entre em contato com o suporte da Apigee para detalhes da migração.