Requisitos de instalação

Edge for Private Cloud v. 4.17.01

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 compatível com 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)

16GB*

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.

O tamanho padrão da fila Qpid é 20 GB. Se for preciso adicionar mais capacidade, Nós Qpid.

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 Postgres com base na capacidade de processamento:

  • Menos de 250 TPS: 8 GB, 4 núcleos podem ser considerados com o 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 1000 TPS: 16 GB, 8 núcleos, armazenamento de rede gerenciado*** compatível com 2000 IOPS ou superior
  • 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: 64 GB, armazenamento de rede gerenciado de 32 núcleos*** compatível com 4000 IOPS ou superior

**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:

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

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

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

Pilha BaaS de API *

8 GB

4 núcleos

60 a 80 GB

Portal BaaS da API

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 compatível com 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, recomenda-se 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 "Como vincular o roteador para uma porta protegida" em Instalar os componentes do Edge em um gcloud, 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 isso 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 abaixo.

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

Como criar um link simbólico de /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.17.01.sh. Você precisa executar todas estas etapas como raiz:

  1. Crie a "apigee" usuário e grupo:
    &gt; groupadd -r Apigee
    &gt; 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 instalação desejada. raiz:
    &gt; ln – /srv/myInstallDir /opt/apigee
    em que /srv/myInstallDir é o local desejado do Edge .
  3. Mudar a propriedade da raiz de instalação e do link simbólico para "apigee" usuário:
    &gt; chown -h apigee:apigee /srv/myInstallDir /opt/apigee

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.

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 reativá-la após a instalação. Consulte Instalar o utilitário de configuração da Apigee Apigee para mais informações.

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 IP para o nome do host que pode ser endereçado 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.

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 confirmar que não há restrições de porta no OpenLDAP, Postgres e Cassandra necessários portas.

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

Verifique se o Edge Router pode acessar /etc/rc.d/init.d/functions

Os nós do Edge Router e do Portal BaaS usam o roteador Nginx e exigem 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, faça o seguinte: defini-los como 700, caso contrário, o roteador não será iniciado. As permissões podem ser definidas como 744 para que acesso de leitura a /etc/rc.d/init.d/functions.

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 saber mais,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 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 /&lt;inst_root&gt;/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:
    &gt; vi /&lt;inst_root&gt;/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:
    &gt; /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql reiniciar

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 como mostrados abaixo:
    apigee soft memlock ilimitado
    memlock rígido ilimitado da Apigee
    Apigee soft nofile 32768
    arquivo rígido da Apigee 65536
    Apigee soft como ilimitada
    apigee difícil como ilimitada

  • 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 como mostrados abaixo:
    Apigee soft nofile 32.768
    hard nofile da apigee 65536


    Se necessário, é possível aumentar esse limite. Por exemplo, se você tiver um grande número de objetos arquivos abertos a qualquer momento.

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)

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

Confira 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 mensagens faz duas buscas DNS: uma para IPv4 e outra para IPv6. Desative a busca DNS no IPv6 ao usar 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 o CentOS 7 no Google Cloud Platform, precisa 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 sistema operacional para obter instruções sobre desativar o IPv6.

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

lua-socket

rpm

unzip

nome de base

grep

ls

rpm2cpio

adicionar usuário

bash

nome do host

Ferramentas de rede

sed

wc

bc

id

perl (de procps)

sudo

wget

curl

Libaio

pgrep (de procps)

tar

xerces-c

Cyrus-Sasl
libdb-cxx
ps tr delícia

data

libibverbos

pwd

uuid

chkconfig

dirname
librdmacm
python Uname
escola
libxslt

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 tiver configurado, o utilitário "ntpdate" poderá 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 12 com dois data centers, é necessário Replicação do OpenLDAP porque há vários nós hospedando 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.
  • 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 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 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 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 minhaempresa-org com a que tenha o alias de host 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.
  • Portas com o prefixo "M" são portas usadas para gerenciar o componente e devem estar abertas no para acesso pelo servidor de gerenciamento.
  • Os componentes a seguir exigem acesso à porta 8080 no servidor de gerenciamento: Roteador, Processador de mensagens, interface, Postgres e Qpid.
  • Um processador de mensagens deve abrir a porta 4528 como sua porta de gerenciamento. Se você tem vários Processadores de mensagens, todos eles devem poder acessar uns aos outros pela porta 4528 (indicada pelo 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.
  • Também é possível configurar o acesso TLS/SSL para determinadas conexões, que podem usar em 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.
  • Você pode configurar o servidor de gerenciamento e a interface de usuário do Edge para enviar e-mails por um SMTP externo servidor. Nesse caso, você deve garantir que o servidor de gerenciamento e a interface possam 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

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

59001

Porta usada para testar a instalação do Edge pelo utilitário apigee-validate. Esse utilitário requer acesso à porta 59001 no roteador. Consulte Testar a instalação para saber mais sobre a porta 59001.

ZooKeeper

2181

Usado por outros componentes, como o servidor de gerenciamento, roteador, processador de mensagens etc. ativado

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

1102

Porta JMX

4529

Chamadas de gerenciamento e cache distribuídos

Postgres

5432

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

8084

Porta de gerenciamento padrão no servidor Postgrese deve estar aberta no componente para acesso 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 na 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.

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

<porta do host virtual#>

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)

Listener no roteador de mensagens

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

Zookeeper

Zookeeper

4.526

Porta de gerenciamento de RPC

Servidor de gerenciamento

Servidor de gerenciamento

4.527 Porta de gerenciamento de RPC para cache e chamadas de gerenciamento distribuídos, e para comunicações entre roteadores

Servidor de gerenciamento

Roteador

Roteador

4.528

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

Servidor de gerenciamento

Roteador

processador de mensagens

processador de mensagens

4.529 Porta de gerenciamento de RPC para cache distribuído e chamadas de gerenciamento Servidor de gerenciamento Servidor Qpid
4.530 Porta de gerenciamento de RPC para cache distribuído e chamadas de gerenciamento Servidor de gerenciamento Servidor Postgres

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 de gerenciamento

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 do Gerenciamento de borda padrão

Navegador

Servidor da interface de gerenciamento

9.042

Transporte nativo CQL

Roteador

processador de mensagens

Servidor de gerenciamento

Cassandra

9.160

Cliente de luxo do Cassandra

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

Balanceador de carga Roteador
59.001 Porta usada pelo utilitário apigee-validate para testar a instalação do Edge apigee-validate Roteador

59.002

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 /&lt;inst_root&gt;/apigee/customer/application/message-processor.properties. para adicionar a seguinte propriedade. Crie o arquivo se ele não existir.
    conf_system_cassandra.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_cassandra.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:

  • O portal de APIs BaaS nunca faz solicitações diretamente a um nó de pilha de BaaS. Quando um desenvolvedor fizer login no portal, o app será transferido por download para o navegador. O app do portal em execução o navegador faz solicitações aos nós da pilha de BaaS.
  • Uma instalação de produção do API BaaS usa um balanceador de carga entre o nó do portal da API BaaS e nós de pilha de BaaS da API. 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.
  • Todos os nós da pilha devem abrir a porta 2551 para acesso de todos os outros nós da pilha (indicado pelo a seta de loop no diagrama acima para a porta 2551 nos nós da pilha). Se você tiver vários registros em todos os data centers, ela precisa ser acessível por todos os 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 habilitado para TLS, geralmente é a 465, mas verifique com o provedor SMTP.
  • Os nós do Cassandra podem ser dedicados ao API BaaS ou compartilhados com o Edge.

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

2551

Porta para comunicação entre todos os nós da pilha. Precisa ser acessível por todas as outras pilhas nós no intervalo de dados.

Se você tiver vários data centers, a porta precisará ser acessível de todos os nós de pilha todos os data centers.

ElasticSearch

9.200 a 9.400

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

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 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: /&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.

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