Requisitos de instalação

Edge para nuvem privada v4.18.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.

Além disso, veja a seguir os requisitos de hardware caso você queira instalar a Serviços de monetização:

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

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.

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.

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

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

Como criar um link simbólico em /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.18.01.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 desejado 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

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 JAVA_HOME aponta para a raiz do JDK para o usuário que está executando a e 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 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

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, não os defina como 700, caso contrário, o roteador não conseguirá começar. As permissões podem ser definidas como 744 para permitir 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 Ajuste Recursos Java (em inglês). 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 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

• 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 32768
  apigee hard nofile 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

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

ntpdate

É recomendável usar o servidor os horários serã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 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 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 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 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 do aplicativo (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 permitem que o tráfego das portas 80 e 443 se conecte.

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

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 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 componente e deve estar aberto nele para ser acessado 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:

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

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

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 tempo limite de TCP do firewall inativo. Essa configuração deve manter em um estado estabelecido para que o firewall não a desconecte.
2. Em todos os processadores de mensagens, editar /opt/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:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

4. Em todos os roteadores, edite /opt/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:

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

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.