Requisitos de instalación

Edge for Private Cloud v. 4.17.05

Requisitos de hardware

Debes cumplir con los siguientes requisitos mínimos de hardware para un dispositivo con de nube en un entorno de producción. Para todas las situaciones de instalación descritas en Topologías de instalación, en las siguientes tablas se enumeran los requisitos mínimos de hardware para los componentes de instalación.

En estas tablas, los requisitos de disco duro se suman al espacio en disco duro requerido por el sistema operativo. Según las aplicaciones y el tráfico de red, es posible que la instalación requieren más o menos recursos de los que se indican a continuación.

Componente de instalación

RAM

CPU

Disco duro mínimo

Cassandra

16 GB

8 núcleos

Almacenamiento local de 250 GB con SSD o HDD rápido que admite 2,000 IOPS

Procesador de mensajes/router en la misma máquina

16 GB

8 núcleos

100GB

Analytics: Postgres/Qpid en el mismo servidor (no recomendado para producción)

16GB*

8 núcleos*

De 500 GB a 1 TB** de almacenamiento en red***, preferentemente con backend SSD, que admite 1,000 IOPS o superior.*

Analytics: Postgres independiente

16GB*

8 núcleos*

De 500 GB a 1 TB** de almacenamiento en red***, preferentemente con backend SSD, que admiten 1,000 IOPS o más.*

Analytics: Qpid independiente

8 GB

4 núcleos

De 30 GB a 50 GB de almacenamiento local con SSD o HDD rápido

Para instalaciones superiores a 250 TPS, se recomienda un HDD con almacenamiento local que admite 1,000 IOPS se recomienda.

El tamaño predeterminado de la cola de Qpid es de 20 GB. Si necesitas aumentar la capacidad, agrega una Nodos de Qpid.

Otro (OpenLDAP, IU, servidor de administración)

4 GB

2 núcleos

60 GB

*Ajusta los requisitos del sistema de Postgres según la capacidad de procesamiento:

  • Menos de 250 TPS: 8 GB, se pueden considerar 4 núcleos con almacenamiento de red administrado*** que admite 1,000 IOPS o más
  • Más de 250 TPS: 16 GB, 8 núcleos, almacenamiento de red administrada*** que admite 1,000 IOPS o superior
  • Más de 1,000 TPS: 16 GB, 8 núcleos, almacenamiento de red administrada*** que admite 2,000 IOPS o superior
  • Más de 2,000 TPS: 32 GB, 16 núcleos, almacenamiento de red administrada*** que admite 2,000 IOPS o superior
  • Más de 4,000 TPS: 64 GB, 32 núcleos, almacenamiento de red administrada*** que admite 4,000 IOPS o superior

**El valor del disco duro de Postgres se basa en las estadísticas listas para usar que captura Edge. Si agregas valores personalizados a los datos de Analytics, estos deben ser aumentaron en consecuencia. Usa la siguiente fórmula para estimar el almacenamiento requerido:

(cantidad de bytes/solicitud) * (solicitudes por segundo) * (segundos por hora) * (horas de uso máximo por día) * (días por mes) * (meses de retención de datos) = bytes de almacenamiento necesarios

Por ejemplo:

(2,000 bytes de datos de análisis por solicitud) * 100 solicitudes/s * 3,600 segundos/h * 18 horas pico de uso por día × 30 días por mes × 3 meses de retención = 1,194,393,600,000 bytes o 1,194.4 GB.

*** Se recomienda el almacenamiento en red para la base de datos de Postgresql por los siguientes motivos:

  • Permite escalar verticalmente el tamaño de almacenamiento de forma dinámica, siempre y cuando sea como en los productos necesarios.
  • Las IOPS de red pueden ajustarse sobre la marcha en la mayoría de las redes entorno/almacenamiento/subsistemas de red.
  • Las instantáneas a nivel de almacenamiento se pueden habilitar como parte de la copia de seguridad y la recuperación. de Google Cloud.

Además, el siguiente artículo enumera los requisitos de hardware si deseas instalar el Servicios de Monetización:

Componente con monetización

RAM

CPU

Disco duro

Servidor de administración (con servicios de monetización)

8 GB

4 núcleos

60 GB

Analytics: Postgres/Qpid en el mismo servidor

16 GB

8 núcleos

Almacenamiento en red de 500 GB a 1 TB, preferentemente con backend SSD, que admite 1,000 IOPS o más arriba o usa la regla de la tabla que aparece arriba.

Analytics: Postgres independiente

16 GB

8 núcleos

Almacenamiento en red de 500 GB a 1 TB, preferentemente con backend SSD, que admite 1,000 IOPS o más arriba o usa la regla de la tabla que aparece arriba.

Analytics: Qpid independiente

8 GB

4 núcleos

De 40 GB a 500 GB de almacenamiento local con SSD o HDD rápido

Para instalaciones superiores a 250 TPS, se recomienda un HDD con almacenamiento local que admite 1,000 IOPS se recomienda.

A continuación, se muestra una lista de los requisitos de hardware si quieres instalar API BaaS:

Componente de BaaS de API

RAM

CPU

Disco duro

ElasticSearch*

8 GB

4 núcleos

De 60 a 80 GB

Pila de BaaS de la API *

8 GB

4 núcleos

De 60 a 80 GB

Portal de BaaS de la API

1 GB

2 núcleos

20GB

Cassandra (opcional; por lo general, usas el mismo clúster de Cassandra para Edge y los servicios de BaaS de APIs)

16 GB

8 núcleos

Almacenamiento local de 250 GB con SSD o HDD rápido que admite 2,000 IOPS

* Puedes instalar ElasticSearch y API BaaS Stack en el mismo nodo. Si lo haces, configurar ElasticSearch para que use 4 GB de memoria (predeterminado). Si ElasticSearch está instalado en su propio nodo y configurarlo para que use 6 GB de memoria.

Nota:

  • Si el sistema de archivos raíz no es lo suficientemente grande para la instalación, se recomienda colocar los datos en un disco más grande.
  • Si se instaló una versión anterior de Apigee Edge para la nube privada en la máquina, asegúrate de borrar la carpeta /tmp/java antes de una nueva instalación.
  • La carpeta temporal de todo el sistema /tmp necesita permisos de ejecución para iniciar Cassandra.
  • Si el usuario “apigee” se creó antes de la instalación, asegúrate de que “/home/apigee” existe como directorio principal y es propiedad de “apigee:apigee”.

Sistema operativo y herramientas de requisitos de software

Estas instrucciones de instalación y los archivos de instalación suministrados se probaron en el los sistemas operativos y software de terceros que se mencionan aquí: https://apigee.com/docs/api-services/reference/supported-software.

Crea el usuario de Apigee

El procedimiento de instalación crea un usuario de sistema Unix llamado “apigee”. Los directorios perimetrales y Los archivos son propiedad de “apigee”, al igual que los procesos de Edge. Eso significa que los componentes de Edge se ejecutan como “Apigee” usuario. Si es necesario, puedes ejecutar los componentes como un usuario diferente. Consulta “Cómo vincular el router” a un puerto protegido" en Cómo instalar componentes de Edge en un para ver un ejemplo.

Directorio de instalación

De forma predeterminada, el instalador escribe todos los archivos en el directorio /opt/apigee. No puedes cambiar esto del directorio. Si bien no puedes cambiar este directorio, puedes crear un symlink para asignar /opt/apigee para otra ubicación, como se describe a continuación.

En las instrucciones de esta guía, el directorio de instalación se indica como /<inst_root>/apigee, y /<inst_root> es /opt de forma predeterminada.

Crea un symlink a partir de /opt/apigee

Antes de crear el symlink, primero debes crear un usuario y grupo llamados “apigee”. Este es el mismo grupo y usuario que creó el instalador de Edge.

Para crear el symlink, sigue estos pasos antes de descargar el archivo bootstrap_4.17.01.sh. Debes realizar todos estos pasos como raíz:

  1. Crear el “Apigee” usuario y grupo:
    &gt; grupoadd -r Apigee
    &gt; useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Usuario de plataforma de Apigee" Apigee
  2. Crea un symlink desde /opt/apigee hacia la instalación que deseas. raíz:
    &gt; ln -Ts /srv/myInstallDir /opt/apigee
    donde /srv/myInstallDir es la ubicación deseada del perímetro archivos.
  3. Cambiar la propiedad de la raíz de instalación y el symlink a “apigee” usuario:
    &gt; chown -h Apigee:Apigee /srv/myInstallDir /opt/apigee

Java

Necesitas tener instalada una versión compatible de Java 1.8 en cada máquina antes de la instalación. Los JDK compatibles se enumeran aquí:

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

Asegúrate de que JAVA_HOME apunte a la raíz del JDK para el usuario que realiza la instalación.

SELinux

Según tu configuración para SELinux, Edge puede tener problemas durante la instalación y el inicio Componentes de Edge Si es necesario, puedes inhabilitar SELinux o configurarlo en modo permisivo durante instalación y, luego, volver a habilitarla después de la instalación. Consulta Instala la utilidad de Apigee-setup de Edge para obtener más información.

Configuración de red

Te recomendamos comprobar la configuración de red antes de la instalación. El instalador espera que todas las máquinas tengan direcciones IP fijas. Usa los siguientes comandos para validar parámetro de configuración:

  • hostname devuelve el nombre de la máquina
  • hostname -i muestra la IP para el nombre de host que se puede dirigir desde otras máquinas.

Según el tipo y la versión de tu sistema operativo, es posible que debas editar /etc/hosts y /etc/sysconfig/network si el nombre de host no es el correcto. correctamente. Para obtener más información, consulta la documentación de tu sistema operativo específico.

Envoltorios de TCP

Los wrappers TCP pueden bloquear la comunicación de algunos puertos y afectar a OpenLDAP, Postgres y Instalación de Cassandra. En esos nodos, marca /etc/hosts.allow y /etc/hosts.deny para asegurarse de que no haya restricciones de puerto en los entornos de OpenLDAP, Postgres y Cassandra requeridos puertos.

iptables

Valida que no haya políticas de iptables que impidan la conectividad entre nodos en el puertos Edge necesarios. Si es necesario, puedes detener iptables durante la instalación a través del :

> sudo/etc/init.d/iptables stop

En CentOS 7.x, haz lo siguiente:

> systemctl stop firewalld

Asegúrate de que el router perimetral pueda acceder a /etc/rc.d/init.d/functions

El router perimetral y los nodos del portal BaaS usan el router Nginx y requieren acceso de lectura. en /etc/rc.d/init.d/functions.

Si el proceso de seguridad requiere que establezcas permisos en /etc/rc.d/init.d/functions, haz lo siguiente: no los configura en 700 o, de lo contrario, el router no se iniciará. Los permisos se pueden establecer en 744 para permitir acceso de lectura a /etc/rc.d/init.d/functions.

Cassandra

Todos los nodos de Cassandra deben estar conectados a un anillo. Cassandra almacena réplicas de datos en en varios nodos para garantizar la confiabilidad y la tolerancia a errores. La estrategia de replicación de cada El espacio de claves perimetral determina los nodos de Cassandra en los que se colocan las réplicas. Para obtener más información,consulta Acerca de Cassandra Factor de replicación y nivel de coherencia.

Cassandra ajusta automáticamente el tamaño de montón de Java en función de la memoria disponible. Para obtener más información, consulta Ajuste de Java recursos. En caso de una degradación del rendimiento o un alto consumo de memoria.

Luego de instalar Edge para la nube privada, verifica que Cassandra esté configurado de forma correcta examinando el archivo /&lt;inst_root&gt;/apigee/apigee-cassandra/conf/cassandra.yaml . Por ejemplo, asegúrate de que la secuencia de comandos de instalación del perímetro para la nube privada establezca lo siguiente: propiedades:

  • cluster_name
  • initial_token
  • particionador
  • semillas
  • listen_address
  • rpc_address
  • snexo

Advertencia: No edites este archivo.

Base de datos de PostgreSQL

Luego de instalar Edge, puedes ajustar la siguiente configuración de la base de datos de PostgreSQL según el cantidad de RAM disponible en tu 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 establecer estos valores, sigue estos pasos:

  1. Edita postgresql.properties:
    &gt; vi /&lt;inst_root&gt;/apigee/customer/application/postgresql.properties

    Si el archivo no existe, créalo.
  2. Configura las propiedades que se mencionaron anteriormente.
  3. Guarda los cambios.
  4. Reinicia la base de datos de PostgreSQL:
    &gt; /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql reiniciar

Límites del sistema

Asegúrate de haber establecido los siguientes límites del sistema en Cassandra y Message Processor nodos:

  • En los nodos de Cassandra, establece límites de espacio de dirección (como) y suave, nofile y de dirección el usuario de instalación (la configuración predeterminada es “apigee”) en /etc/security/limits.d/90-apigee-edge-limits.conf como como se muestra a continuación:
    software memlock de Apigee ilimitado
    Apigee hard memlock ilimitado
    Apigee Soft Nofile 32768
    Apigee hard nofile 65536
    Apigee soft como ilimitado
    Apigee es ilimitado

  • En los nodos del procesador de mensajes, establece el número máximo de descriptores de archivos abiertos en 64,000. en /etc/security/limits.d/90-apigee-edge-limits.conf como como se muestra a continuación:
    software nofile de Apigee 32,768
    Apigee hard nofile 65536


    Si es necesario, puedes aumentar ese límite. Por ejemplo, si hay una gran cantidad de dominios temporales archivos abiertos en cualquier momento.

jsvc

“jsvc” es un requisito previo para usar las BaaS de las APIs. Se instala la versión 1.0.15-dev cuando instalas la BaaS de la API.

Servicios de seguridad de red (NSS)

Network Security Services (NSS) es un conjunto de bibliotecas que admite el desarrollo de aplicaciones cliente y servidor habilitadas para seguridad. Asegúrate de haber instalado NSS v3.19 o una versión posterior.

Para consultar tu versión actual, haz lo siguiente:

> yum info nss

Para actualizar NSS, haz lo siguiente:

> yum update nss

Consulta este artículo de Red Hat. para obtener más información.

Inhabilitar la búsqueda de DNS en IPv6 cuando se usa NSCD (Daemon de caché del servicio de nombres)

Si instalaste y habilitaste NSCD (Name Service Cache Daemon), los Message Processors realiza dos búsquedas de DNS: una para IPv4 y otra para IPv6. Debes inhabilitar la búsqueda de DNS en IPv6 cuando se usa NSCD

Para inhabilitar la búsqueda de DNS en IPv6, haz lo siguiente:

  1. En cada nodo del procesador de mensajes, edita /etc/nscd.conf
  2. Configura la siguiente propiedad:
    No hay hosts de enable-cache

Inhabilita IPv6 en Google Cloud Plataforma para Red Hat/CentOS 7

Si instalas Edge en Red Hat 7 o CentOS 7 en Google Cloud Platform, es posible que debas debe inhabilitar IPv6 en todos los nodos Qpid.

Consulta la documentación de Red Hat o CentOS para conocer la versión específica de tu SO y obtener instrucciones sobre inhabilitar IPv6. Por ejemplo, puedes hacer lo siguiente:

  1. Abre /etc/hosts en una Editor.
  2. Insertar un "#" carácter en una de las siguientes líneas para comentarlo:
    N.o::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. Guarda el archivo.

AMI de AWS

Si instalas Edge en una imagen de máquina de Amazon (AMI) de AWS para Red Hat Enterprise Linux 7.x, primero debes ejecutar el siguiente comando:

> yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

Herramientas

El instalador usa las siguientes herramientas de UNIX en la versión estándar proporcionada por EL5 o EL6.

sem

expr.

lua-socket

rpm

unzip

nombre base

grep

ls

rpm2cpio

Agregar usuario

Bash

Nombre de host

herramientas de red

sed

wc

bc

id

perl (de procps)

sudo

wget

curl

libaio

pgrep (de procps)

tar

xerces-c

cyrus-sasl
libdb-cxx
ps tr yum

fecha

libibverbio

pwd

uuid

chkconfig

dirname
librdmacm
python uname
echo
libxslt

Nota:

  • El ejecutable de la herramienta “useradd” se encuentra en /usr/sbin, y para chkconfig, en /sbin.
  • Con el acceso sudo, puedes obtener acceso sobre el entorno del usuario que realiza la llamada, por ejemplo, por lo general, llamarías “sudo <command>” o “sudo PATH=$PATH:/usr/sbin:/sbin <comando>”.
  • Asegúrate de tener instalada la herramienta de parches antes de colocar el Service Pack (parche) instalación.

ntpdate: se recomienda sincronizar el tiempo de los servidores. Si "ntpdate" podría cumplir este propósito, el cual verifica si los servidores están sincronizados en el tiempo. Puedes usar “yum install ntp” para instalar el o de terceros. Esto es particularmente útil para replicar configuraciones de OpenLDAP. Ten en cuenta que configuraste el servidor la zona horaria en UTC.

openldap 2.4: la instalación local requiere OpenLDAP 2.4. Si Si el servidor tiene conexión a Internet, la secuencia de comandos de instalación perimetral se descarga y se instala OpenLDAP. Si tu servidor no tiene conexión a Internet, debes asegurarte de que el OpenLDAP ya instalada antes de ejecutar la secuencia de comandos de instalación de Edge. En RHEL/CentOS, puedes ejecutar "yum install openldap-clients" openldap-servers&quot; para instalar el OpenLDAP.

Para instalaciones de 13 hosts y de 12 hosts con dos centros de datos, necesitas Replicación de OpenLDAP porque hay varios nodos que alojan OpenLDAP.

Firewalls y hosts virtuales

El término “virtual” suele sobrecargarse en el ámbito de la TI, así que sucede Apigee Edge para la implementación de nubes privadas y hosts virtuales. Para aclarar, hay dos principales usos del término “virtual”:

  • Máquinas virtuales (VM): No es obligatoria, pero algunas implementaciones usan tecnología de VM. crear servidores aislados para sus componentes de Apigee. Los hosts de VM, al igual que los hosts físicos, pueden tener interfaces de red y firewalls.
  • Hosts virtuales: Extremos web, similares a un host virtual de Apache

Un router en una VM puede exponer varios hosts virtuales (siempre que difieran entre sí en su alias del host o en su puerto de interfaz).

Como ejemplo, un solo servidor físico “A” podría ejecutar dos VMs, llamada “VM1” y “VM2”. Supongamos que VM1 expone una red Ethernet virtual , que se denomina eth0. dentro de la VM, y a qué dirección IP le asigna la dirección IP 111.111.111.111 mediante la virtualización o un servidor DHCP de red; y, luego, supongamos que VM2 expone una interfaz Ethernet virtual llamada eth0 y se le asigna una dirección IP 111.111.111.222.

Es posible que tengamos en ejecución un router de Apigee en cada una de las dos VMs. Los routers exponen como en este ejemplo hipotético:

El router de Apigee en VM1 expone tres hosts virtuales en su interfaz eth0 (que tiene algunos dirección IP específica), api.mycompany.com:80, api.mycompany.com:443 y test.mycompany.com:80.

El router en la VM2 expone api.mycompany.com:80 (el mismo nombre y puerto que que expone la VM1).

El sistema operativo del host físico puede tener un firewall de red. Si es así, se establecerá la configuración se debe configurar para pasar el tráfico de TCP vinculado a los puertos que se exponen en la red interfaces (111.111.111.111:{80, 443} y 111.111.111.222:80). Además, cada El sistema operativo de la VM puede proporcionar su propio firewall en su interfaz eth0, que también debe permitir que se conecte el tráfico de los puertos 80 y 443.

La ruta base es el tercer componente involucrado en el enrutamiento de llamadas a la API a diferentes proxies de API que hayas implementado. Los paquetes de proxy de API pueden compartir un extremo si tienen diferentes basepaths. Por ejemplo, una ruta base se puede definir como http://api.mycompany.com:80/ y otra se define como http://api.mycompany.com:80/salesdemo.

En este caso, necesitas un balanceador de cargas o un director de tráfico de algún tipo que divida el http://api.mycompany.com:80/ entre las dos direcciones IP (111.111.111.111 en VM1 y 111.111.111.222 en VM2). Esta función es específicas de tu instalación en particular, y las configura tu grupo local de redes.

La ruta base se establece cuando implementas una API. En el ejemplo anterior, puedes implementar dos APIs. mycompany y testmycompany para la organización mycompany-org con la configuración host que tiene el alias de host api.mycompany.com y el puerto configurado como 80. Si no declaras un base de la ruta de la implementación, el router no sabrá qué API enviar las solicitudes entrantes. a los que tiene acceso una cuenta.

Sin embargo, si implementas la API testmycompany con la URL base de /salesdemo y los usuarios acceden esa API usando http://api.mycompany.com:80/salesdemo. Si implementa tu API mycompany con la URL base / luego, tus usuarios acceden a la API mediante la URL http://api.mycompany.com:80/.

Requisitos de los puertos perimetrales

La necesidad de administrar el firewall va más allá de los hosts virtuales; una VM y un host físico los firewalls deben permitir el tráfico a los puertos que requieren los componentes para comunicarse con cada entre sí.

En la siguiente imagen, se muestran los requisitos de puertos para cada componente de Edge:

Notas sobre este diagrama:

  • *El puerto 8082 en el Message Processor solo debe estar abierto para que el router acceda a configurar TLS/SSL entre el router y Message Processor. Si no configuras TLS/SSL entre el router y el procesador de mensajes, la configuración predeterminada, el puerto 8082 debe estar abierto en el Message Processor para administrar el componente, pero el router no requiere el acceso a ellos.
  • Los puertos con el prefijo “M” son puertos que se utilizan para administrar el componente y deben estar abiertos en el y debe estar abierta en el componente para que pueda acceder el servidor de administración.
  • Los siguientes componentes requieren acceso al puerto 8080 en el servidor de administración: router, Message Processor, IU, Postgres y Qpid.
  • Un Message Processor debe abrir el puerto 4528 como su puerto de administración. Si tienes varias de mensajes, todos deben poder acceder entre sí a través del puerto 4528 (indicado por el flecha de bucle en el diagrama anterior para el puerto 4528 en Message Processor). Si tienes varias Para los centros de datos, se debe poder acceder al puerto desde todos los procesadores de mensajes de todos los centros de datos.
  • Si bien no es necesario, puedes abrir el puerto 4527 en el router para acceder a través de cualquier mensaje. Procesador. De lo contrario, es posible que veas mensajes de error en los archivos de registro de Message Processor.
  • Un router debe abrir el puerto 4527 como su puerto de administración. Si tienes varios routers, deben poder acceder entre sí a través del puerto 4527 (indicado por la flecha de bucle en el diagrama anterior para el puerto 4527 del router).
  • La IU de Edge requiere acceso al router, en los puertos que exponen los proxies de API, para admitir el botón Enviar en la herramienta de registro.
  • El servidor de administración necesita acceso al puerto JMX en la instancia nodos.
  • El acceso a los puertos JMX se puede configurar para que requiera un nombre de usuario y una contraseña. Consulta Cómo supervisar para obtener más información.
  • Puedes configurar el acceso TLS/SSL para ciertas conexiones, que pueden usar puertos diferentes. Consulta TLS/SSL para más.
  • Si configuras dos nodos de Postgres para usar la replicación en espera de instancia principal, debes abrir el puerto 22 en cada nodo para el acceso SSH. Si lo deseas, puedes abrir puertos en nodos individuales para permitir acceso SSH.
  • Puedes configurar el servidor de administración y la IU perimetral para enviar correos electrónicos a través de un SMTP externo servidor. Si lo hace, debe asegurarse de que el servidor de administración y la IU puedan acceder a los puerto en el servidor SMTP. En el caso de SMTP que no sea TLS, el número de puerto suele ser 25. Para TLS habilitado SMTP, por lo general es 465, pero consulta con tu proveedor de SMTP.

En la siguiente tabla, se muestra que el componente de Edge debe abrir los puertos en firewalls:

Componente

Puerto

Descripción

Puertos HTTP estándar

80, 443

HTTP más cualquier otro puerto que uses para hosts virtuales

Servidor de administración

8080

Puerto para llamadas a la API de Edge Management. Estos componentes requieren acceso al puerto 8080 en servidor de administración: Router, Procesador de mensajes, IU, Postgres y Qpid.

1099

Puerto JMX

4526

Para caché distribuida y llamadas de administración

IU de administración

9000

Puerto para el acceso del navegador a la IU de administración

Message Processor

8998

Puerto del procesador de mensajes para las comunicaciones del router

8082

Puerto de administración predeterminado para Message Processor y debe estar abierto en el componente de el acceso por el servidor de administración.

Si configuras TLS/SSL entre el router y el procesador de mensajes, que usa el router para realizar verificaciones de estado en Message Processor.

1101

Puerto JMX

4528

Para caché distribuida y llamadas de administración entre procesadores de mensajes y para comunicación desde el router

Router

8081

Puerto de administración predeterminado para el router; debe estar abierto en el componente para acceder por el servidor de administración.

4527

Para caché distribuida y llamadas de administración

15999

Puerto de verificación de estado. Un balanceador de cargas usa este puerto para determinar si el router disponibles.

Para obtener el estado de un router, el balanceador de cargas envía una solicitud al puerto 15999 en el Router:

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

Si se puede acceder al router, la solicitud muestra HTTP 200.

59001

Puerto que se usa para probar la instalación de Edge por parte de la utilidad apigee-validate. Esta utilidad requiere acceso al puerto 59001 en el router. Consulta Prueba la instalación para obtener más información sobre el puerto 59001.

ZooKeeper

2181

Lo utilizan otros componentes, como el servidor de administración, el router, el procesador de mensajes, etcétera. activado

2888 y 3888

ZooKeeper lo usa internamente para el clúster de ZooKeeper (conocido como el ensamble de ZooKeeper). comunicación

Cassandra

7000, 9042 y 9160

Puertos de Apache Cassandra para la comunicación entre los nodos de Cassandra y el acceso para otros componentes de Edge.

7199

JMX. Debe estar abierto para que pueda acceder el servidor de administración.

Qpid

5672

Se usa para las comunicaciones entre el router y el procesador de mensajes con el servidor Qpid

8083

Puerto de administración predeterminado en el servidor Qpid y debe estar abierto en el componente para el acceso por el servidor de administración.

1102

Puerto JMX

4529

Para caché distribuida y llamadas de administración

Postgres

5432

Se usa para la comunicación entre Qpid/Management Server y Postgres

8084

Puerto de administración predeterminado en el servidor Postgresy debe estar abierto en el componente para obtener acceso por el servidor de administración.

1103

Puerto JMX

4530

Para caché distribuida y llamadas de administración

22

Si configuras dos nodos de Postgres para usar la replicación en espera de instancia principal, debes abrir el puerto 22 de cada nodo para el acceso SSH.

LDAP

10,389

OpenLDAP

SmartDocs

59002

El puerto del router perimetral al que se envían las solicitudes de páginas de SmartDocs.

En la siguiente tabla, se muestran los mismos puertos, enumerados numéricamente, con el origen y el destino componentes:

Número de puerto

Objetivo

Componente de origen

Componente de destino

<puerto de host virtual#>

HTTP o cualquier otro puerto que uses para el tráfico de llamadas a la API de host virtual. Puertos 80 y 443 son los más utilizados; el Enrutador de mensajes puede finalizar las conexiones TLS/SSL.

Cliente externo (o balanceador de cargas)

Objeto de escucha en Message Router

De 1099 a 1103

Administración de JMX

Cliente JMX

Servidor de administración (1099)

Message Processor (1101)

Servidor Qpid (1102)

Postgres Server (1103)

2,181

Comunicación con el cliente de Zookeeper

Servidor de administración

Router

Message Processor

Servidor Qpid

Servidor de Postgres

Zookeeper

2888 y 3888

Administración de nodos de Zookeeper

Zookeeper

Zookeeper

4,526

Puerto de administración de RPC

Servidor de administración

Servidor de administración

4,527 Puerto de administración de RPC para la caché distribuida y las llamadas de administración, y para las comunicaciones entre los routers

Servidor de administración

Router

Router

4,528

Para llamadas de caché distribuidas entre procesadores de mensajes y para la comunicación desde el router

Servidor de administración

Router

Message Processor

Message Processor

4,529 Puerto de administración de RPC para la caché distribuida y las llamadas de administración Servidor de administración Servidor Qpid
4,530 Puerto de administración de RPC para la caché distribuida y las llamadas de administración Servidor de administración Servidor de Postgres

5,432

Cliente de Postgres

Servidor Qpid

Postgres

5,672

Se usa para enviar estadísticas del router y el procesador de mensajes a Qpid

Router

Message Processor

Servidor Qpid

7,000

Comunicaciones entre nodos de Cassandra

Cassandra

Otro nodo de Cassandra

7,199

Administración de JMX. Debe estar abierto para que la gerencia acceda al nodo de Cassandra. Servidor.

cliente JMX

Cassandra

8080

Puerto de la API de Management

Clientes de la API de Management

Servidor de administración

De 8081 a 8084

Puertos de API de componentes, que se usan para emitir solicitudes a la API directamente a componentes individuales. Cada componente abre un puerto diferente. el puerto exacto usado depende de la configuración pero debe estar abierto en el componente para que pueda acceder el servidor de administración

Clientes de la API de Management

Router (8081)

Message Processor (8082)

Servidor Qpid (8083)

Postgres Server (8084)

8,998

Comunicación entre el router y el procesador de mensajes

Router

Message Processor

9,000

Puerto predeterminado de la IU de administración perimetral

Navegador

Servidor de IU de administración

9042

Transporte nativo de CQL

Router

Message Processor

Servidor de administración

Cassandra

9,160

Cliente de segunda mano de Cassandra

Router

Message Processor

Servidor de administración

Cassandra

10,389

Puerto LDAP

Servidor de administración

OpenLDAP

15,999

Puerto de verificación de estado. Un balanceador de cargas usa este puerto para determinar si el router disponibles.

Balanceador de cargas Router
59,001 Puerto que usa la utilidad apigee-validate para probar la instalación de Edge apigee-validate Router

59,002

El puerto del router al que se envían las solicitudes de la página SmartDocs

SmartDocs

Router

Un procesador de mensajes mantiene un grupo de conexiones dedicado abierto a Cassandra, que se configura para que nunca se agote el tiempo de espera. Cuando un firewall se encuentra entre un procesador de mensajes y un servidor Cassandra, firewall puede agotar el tiempo de espera de la conexión. Sin embargo, el procesador de mensajes no está diseñado para restablecer conexiones con Cassandra.

Para evitar esta situación, Apigee recomienda que el servidor Cassandra, el procesador de mensajes y los routers estén en la misma subred, de modo que un firewall no esté involucrado en la implementación de estos o los componentes de la solución.

Si un firewall se encuentra entre el router y los procesadores de mensajes, y tiene configurado un tiempo de espera de TCP inactivo, nuestra recomendación es:

  1. Configura net.ipv4.tcp_keepalive_time = 1800 en la configuración de sysctl en SO Linux, donde 1800 debería ser menor que el firewall inactivo tiempo de espera de tcp. Esta configuración debe mantener la conexión en un estado establecido para que la firewall no desconecta la conexión.
  2. En todos los procesadores de mensajes, edita /&lt;inst_root&gt;/apigee/customer/application/message-processor.properties para agregar la siguiente propiedad. Si el archivo no existe, créalo.
    conf_system_cassandra.maxconnecttimeinmillis=-1
  3. Reinicia el Message Processor:
    &gt; /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor restart
  4. En todos los routers, edita /&lt;inst_root&gt;/apigee/customer/application/router.properties para agregar la siguiente propiedad. Si el archivo no existe, créalo.
    conf_system_cassandra.maxconnecttimeinmillis=-1
  5. Reinicia el router:
    &gt; /opt/apigee/apigee-service/bin/apigee-service Edge-router restart

Si instalas la configuración agrupada en clústeres de 12 hosts con dos centros de datos, asegúrate de que las los nodos de ambos centros de datos se pueden comunicar a través de los puertos que se muestran a continuación:

Requisitos del puerto de BaaS de la API

Si optas por instalar las BaaS de las APIs, debes agregar los componentes de la pila de BaaS de APIs y del portal de BaaS de APIs. Estos componentes usan los puertos que se muestran en la siguiente figura:

Notas sobre este diagrama:

  • El Portal de BaaS de la API nunca realiza solicitudes directamente a un nodo de pila de BaaS. Cuando un desarrollador accede al portal, la app del portal se descarga en el navegador. La app del portal que se ejecuta en el navegador luego envía solicitudes a los nodos de la pila de BaaS.
  • Una instalación de producción de la API BaaS usa un balanceador de cargas entre el nodo del portal de la API de BaaS y los nodos de pila BaaS de APIs. Al configurar el Portal y realizar llamadas a la API de BaaS, puedes especificar la dirección IP o el nombre de DNS del balanceador de cargas, no de los nodos de pila.
  • Todos los nodos de la pila deben abrir el puerto 2551 para acceder desde todos los demás nodos de la pila (indicado por el flecha de bucle en el diagrama anterior para el puerto 2551 en los nodos de pila). Si tienes varios datos Centros, el puerto debe ser accesible desde todos los nodos de pila en todos los centros de datos.
  • Debes configurar todos los nodos de la pila de Baas para enviar correos electrónicos a través de un servidor SMTP externo. Para que no sea SMTP por TLS, el número de puerto suele ser 25. Para SMTP habilitado por TLS, a menudo es 465, pero verifica con tu proveedor de SMTP.
  • Los nodos de Cassandra pueden dedicarse a las BaaS de las APIs o se pueden compartir con Edge.

En la siguiente tabla, se muestran los puertos predeterminados que se deben abrir en firewalls, por componente:

Componente

Puerto

Descripción

Portal de BaaS de la API

9000

Puerto para la IU de BaaS de la API

Pila de BaaS de API

8080

Puerto donde se recibe la solicitud a la API

2551

Puerto para la comunicación entre todos los nodos de la pila. Debe ser accesible para todas las demás plataformas en el control de datos.

Si tienes varios centros de datos, el puerto debe ser accesible desde todos los nodos de Stack en todos los centros de datos.

ElasticSearch

De 9,200 a 9,400

Para la comunicación con la pila BaaS de la API y para la comunicación entre ElasticSearch nodos

Licencias

Cada instalación de Edge requiere un archivo de licencia único que obtienes de Apigee. Lo que harás proporcionar la ruta al archivo de licencia cuando instalas el servidor de administración, por ejemplo, /tmp/license.txt.

El instalador copia el archivo de licencia en /&lt;inst_root&gt;/apigee/customer/conf/license.txt.

Si el archivo de licencia es válido, el servidor de administración valida el vencimiento y el mensaje permitido. de procesadores (MP). Si venció alguna de las configuraciones de licencia, puedes encontrar los registros en la la siguiente ubicación: /&lt;inst_root&gt;/apigee/var/log/edge-management-server/logs. En este caso, puedes comunicarte con el equipo de asistencia de Apigee para detalles de la migración.

Si aún no tienes una licencia, comunícate con Ventas aquí.