Requisitos de instalación

Edge para la nube privada v. 4.17.01

Requisitos de hardware

Debes cumplir con los siguientes requisitos mínimos de hardware para una infraestructura con alta disponibilidad en un entorno de producción. En todas las situaciones de instalación descritas en Topologías de instalación, las siguientes tablas muestran los requisitos mínimos de hardware para los componentes de instalación.

En estas tablas, los requisitos del disco duro se agregan al espacio que requiere el sistema operativo. Según las aplicaciones y el tráfico de red, la instalación puede requerir 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

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

Procesador/router de mensajes en la misma máquina

8/16GB

4 núcleos

100GB

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

16GB*

Núcleo de 8*

De 500 GB a 1 TB** de almacenamiento de red***, de preferencia con backend de SSD, que admite 1,000 IOPS o más*

Analytics: Postgres independiente

16GB*

Núcleo de 8*

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

Analytics: independiente de Qpid

8 GB

4 núcleos

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

Para instalaciones de más de 250 TPS, se recomienda usar HDD con almacenamiento local que admita 1,000 IOPS.

El tamaño predeterminado de la cola Qpid es de 20 GB. Si necesitas agregar más capacidad, agrega nodos Qpid adicionales.

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

4 GB

Dos núcleos

60 GB

† Ajustar los requisitos del sistema del procesador de mensajes según la capacidad de procesamiento:

La recomendación mínima es de 4 núcleos y de 8 núcleos para un sistema de capacidad de procesamiento alta. Puedes ejecutar pruebas de rendimiento a fin de determinar el tamaño óptimo para tus API.

*Ajuste 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 en red administrado*** que admite 1,000 IOPS o más
  • Más de 1,000 TPS: 16 GB, 8 núcleos, almacenamiento de red administrado*** que admite 2,000 IOPS o más
  • Más de 2,000 TPS: 32 GB, 16 núcleos, almacenamiento en red administrado*** que admite 2,000 IOPS o más
  • Más de 4,000 TPS: 64 GB, 32 núcleos, almacenamiento en red administrado*** que admite 4,000 IOPS o más

**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 estadísticas, estos valores deberían aumentarse según corresponda. Usa la siguiente fórmula para estimar el almacenamiento requerido:

(# 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 días/1 x 4 horas)

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

  • Ofrece la capacidad de escalar verticalmente el tamaño de almacenamiento de forma dinámica cuando sea necesario.
  • Las IOPS de red se pueden ajustar sobre la marcha en la mayoría de los subsistemas del entorno, almacenamiento y red actuales.
  • Las instantáneas a nivel del almacenamiento se pueden habilitar como parte de las soluciones de copia de seguridad y recuperación.

Además, a continuación, se enumeran los requisitos de hardware si deseas instalar los 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

De 500 GB a 1 TB de almacenamiento de red, preferentemente con backend SSD, que admite 1,000 IOPS o más, o usa la regla de la tabla anterior.

Analytics: Postgres independiente

16 GB

8 núcleos

De 500 GB a 1 TB de almacenamiento de red, preferentemente con backend SSD, que admite 1,000 IOPS o más, o usa la regla de la tabla anterior.

Analytics: independiente de Qpid

8 GB

4 núcleos

De 40 GB a 500 GB de almacenamiento local con SSD o HDD rápido
Para instalaciones de más de 250 TPS, se recomienda usar HDD con almacenamiento local que admita 1,000 IOPS.

A continuación, se enumeran los requisitos de hardware si deseas instalar el BaaS de la API:

Componente de BaaS de la 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

Dos núcleos

20GB

Cassandra (opcional, por lo general, se usa el mismo clúster de Cassandra para los servicios de Edge y de la API de BaaS)

16 GB

8 núcleos

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

* Puedes instalar ElasticSearch y la pila de BaaS de la API en el mismo nodo. Si lo haces, configura ElasticSearch para que use 4 GB de memoria (opción predeterminada). Si ElasticSearch está instalado en su propio nodo, configúralo 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 instalaste una versión anterior de Apigee Edge para la nube privada, asegúrate de borrar la carpeta /tmp/java antes de una instalación nueva.
  • La carpeta temporal del sistema /tmp necesita permisos de ejecución para iniciar Cassandra.
  • Si el usuario “apigee” se creó antes de la instalación, asegúrese de que “/home/apigee” exista como directorio principal y pertenezca a “apigee:apigee”.

Requisitos del sistema operativo y software de terceros

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

Crea el usuario de Apigee

El procedimiento de instalación crea un usuario del sistema Unix llamado “apigee”. Los directorios y archivos de Edge son propiedad de “apigee”, al igual que los procesos de Edge. Eso significa que los componentes de Edge se ejecutan como el usuario “apigee”. Si es necesario, puedes ejecutar componentes como un usuario diferente. Consulta "Cómo vincular el router a un puerto protegido" en Cómo instalar componentes de Edge en un nodo 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 esta ubicación del directorio. Si bien no puede cambiar este directorio, puede crear un symlink para asignar /opt/apigee a 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, donde /<inst_root> es /opt de forma predeterminada.

Cómo crear un symlink desde /opt/apigee

Antes de crear el symlink, primero debe crear un usuario y un grupo llamado "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 boot_4.17.01.sh. Debes realizar todos estos pasos como raíz:

  1. Cree el usuario y grupo “apigee”:
    > groupadd -r apigee
    > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
  2. Crea un symlink de /opt/apigee a la raíz de instalación que quieras:
    > ln -Ts /srv/myInstallDir /opt/apigee
    donde /srv/myInstallDir es la ubicación deseada de los archivos de Edge.
  3. Cambie la propiedad de la raíz de instalación y el symlink al usuario "apigee":
    > chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

Necesitas tener instalada una versión de Java 1.8 compatible 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 la configuración de SELinux, Edge puede tener problemas para instalar y, luego, iniciar componentes de Edge. Si es necesario, puedes inhabilitar SELinux o configurarlo en modo permisivo durante la instalación y, luego, volver a habilitarlo después de la instalación. Consulta Instala la utilidad de configuración de Apigee para obtener más información.

Configuración de red

Se recomienda verificar 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 el parámetro de configuración:

  • hostname muestra el nombre de la máquina
  • hostname -i muestra la dirección IP del nombre de host al que se puede acceder desde otras máquinas.

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

Envoltorios de TCP

Los contenedores de TCP pueden bloquear la comunicación de algunos puertos y pueden afectar la instalación de OpenLDAP, Postgres y Cassandra. En esos nodos, verifica /etc/hosts.allow y /etc/hosts.deny para asegurarte de que no haya restricciones de puertos en los puertos necesarios de OpenLDAP, Postgres y Cassandra.

iptables

Valida que no haya políticas de iptables que impidan la conectividad entre nodos en los puertos perimetrales obligatorios. Si es necesario, puedes detener iptables durante la instalación con el siguiente comando:

> sudo /etc/init.d/iptables stop

En CentOS 7.x:

> systemctl stop firewalld

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

Los nodos perimetrales y del portal de BaaS usan el router Nginx y requieren acceso de lectura a /etc/rc.d/init.d/functions.

Si el proceso de seguridad requiere que establezcas permisos en /etc/rc.d/init.d/functions, no los establezcas en 700, de lo contrario, el router no podrá iniciarse. Se pueden establecer los permisos en 744 para permitir el 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 varios nodos para garantizar la confiabilidad y la tolerancia a errores. La estrategia de replicación para cada espacio de claves de Edge determina los nodos de Cassandra en los que se colocan las réplicas. Para obtener más información,consulta Acerca de Factor de replicación y nivel de coherencia de Cassandra.

Cassandra ajusta automáticamente el tamaño del montón de Java en función de la memoria disponible. Para obtener más información, consulta Cómo ajustar los recursos de Java. En caso de que el rendimiento disminuya o el consumo de memoria sea alto.

Después de instalar el perímetro para la nube privada, puedes verificar que Cassandra esté configurado correctamente examinando el archivo /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml. Por ejemplo, asegúrate de que la secuencia de comandos de instalación de Edge para la nube privada establezca las siguientes propiedades:

  • nombre_clúster
  • token_inicial
  • particionador
  • semillas
  • listen_address
  • dirección_rpc
  • snitch

Advertencia: No edites este archivo.

Base de datos de PostgreSQL

Después de instalar Edge, puedes ajustar la siguiente configuración de la base de datos de PostgreSQL según la 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. Edite postgresql.properties:
    > vi /<inst_root>/apigee/customer/application/postgresql.properties

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

Límites del sistema

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

  • En los nodos de Cassandra, establece los límites de memlock duro, nofile y espacio de dirección (como) para el usuario de instalación (el valor predeterminado es "apigee") en /etc/security/limits.d/90-apigee-edge-limits.conf como se muestra a continuación:
    apigee soft memlock limited
    apigee hard memlock ilimitado
    apigee soft nofile 32768



  • En los nodos del procesador de mensajes, establece la cantidad máxima de descriptores de archivos abiertos en 64 K en /etc/security/limits.d/90-apigee-edge-limits.conf como se muestra a continuación:
    apigee soft nofile 32768


    Por ejemplo, si tienes una gran cantidad de archivos temporales abiertos a la vez.

JSVC

“jsvc” es un requisito previo para usar el BaaS de la API. La versión 1.0.15-dev se instala cuando instalas el BaaS de la API.

Servicios de seguridad de red (NSS)

Los servicios de seguridad de red (NSS) son un conjunto de bibliotecas que admite el desarrollo de aplicaciones cliente y de servidor habilitadas para la seguridad. Asegúrate de tener instalado NSS v3.19 o una versión posterior.

Sigue estos pasos para verificar la versión actual:

> yum info nss

Para actualizar el NSS, haz lo siguiente:

> yum update nss

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

Inhabilitar la búsqueda de DNS en IPv6 cuando se usa NSCD (daemon de caché de servicio de nombre)

Si instalaste y habilitaste NSCD (daemon de caché de servicio de nombre), Message Processor realiza dos búsquedas de DNS: una para IPv4 y otra para IPv6. Debes inhabilitar la búsqueda de DNS en IPv6 cuando uses NSCD.

Para inhabilitar la búsqueda de DNS en IPv6, sigue estos pasos:

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

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

Si instalas Edge en Red Hat 7 o CentOS 7 en Google Cloud Platform, debes inhabilitar IPv6 en todos los nodos de Qpid.

Consulta la documentación de Red Hat o CentOS para conocer la versión específica del SO a fin de obtener instrucciones sobre cómo inhabilitar IPv6.

AWS AMI

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, como las que proporcionan EL5 o EL6.

despierto

expr

enchufe de Lua

rpm

unzip

nombre base

grep

ls

rpm2cpio

agregar usuario

bash

Nombre de host

herramientas de red

sed

CM

bc

id

Perl (de procps)

sudo

wget

curl

biblioteca

pgrep (desde procps)

tar

XERCES-C

cirus-sasl
libdb-cxx
ps tr qué delicia

date

libibverbs

pwd

uuid

configuración de chk

dirname
librdmacm
python uname
echo
libinsertt

Nota:

  • El archivo 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, en general, se puede llamar a "sudo <command>" o "sudo PATH=$PATH:/usr/sbin:/sbin <command>".
  • Asegúrate de tener instalada la herramienta “patch” antes de la instalación de un paquete de servicios (parche).

ntpdate: Se recomienda sincronizar la hora de los servidores. Si aún no está configurado, la utilidad “ntpdate” puede servir para este fin, que verifica si los servidores están sincronizados con el tiempo. Puedes usar "yum install ntp" para instalar la utilidad. Esto es particularmente útil para replicar configuraciones de OpenLDAP. Ten en cuenta que configuraste la zona horaria del servidor en UTC.

openldap 2.4: La instalación local requiere OpenLDAP 2.4. Si tu servidor tiene una conexión a Internet, la secuencia de comandos de instalación de Edge descarga e instala OpenLDAP. Si tu servidor no tiene conexión a Internet, debes asegurarte de que OpenLDAP ya esté instalado antes de ejecutar la secuencia de comandos de instalación de Edge. En RHEL/CentOS, puedes ejecutar “yum install openldap-clients openldap-servers” para instalar OpenLDAP.

Para las instalaciones de 13 hosts y de 12 hosts con dos centros de datos, se requiere la replicación de OpenLDAP porque hay varios nodos que alojan OpenLDAP.

Firewalls y hosts virtuales

El término “virtual” suele sobrecargarse en la arena de la TI, por lo que se usa con una implementación de Apigee Edge para la nube privada y hosts virtuales. Para aclarar, hay dos usos principales del término "virtual":

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

Un router de una VM puede exponer varios hosts virtuales (siempre que sean distintos en su alias de host o en su puerto de interfaz).

Como ejemplo de nomenclatura, un solo servidor físico “A” puede ejecutar dos VM, llamadas “VM1” y “VM2”. Supongamos que la VM1 expone una interfaz de Ethernet virtual, que se llama eth0 dentro de la VM, y que la máquina virtual virtual DHC1 también tiene una dirección IP1.

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

El router de Apigee en la VM1 expone tres hosts virtuales en su interfaz eth0 (que tiene alguna 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 expone la VM1).

Es posible que el sistema operativo del host físico tenga un firewall de red. Si es así, ese firewall debe configurarse para pasar el tráfico de TCP vinculado a los puertos que se exponen en las interfaces virtualizadas (111.111.111.111:{80, 443} y 111.111.111.222:80). Además, el sistema operativo de cada VM puede proporcionar su propio firewall en su interfaz eth0, y estos también deben permitir la conexión de los puertos 80 y 443.

La ruta base es el tercer componente involucrado en el enrutamiento de llamadas a la API hacia diferentes proxies de API que puedas haber implementado. Los paquetes de proxy de API pueden compartir un extremo si tienen rutas base diferentes. Por ejemplo, una ruta base se puede definir como http://api.mycompany.com:80/ y otra definida 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 la dirección http://api.mycompany.com:80/ de tráfico entre las dos direcciones IP (111.111.111.111 en VM1 y 111.111.111.222 en VM2). Esta función es específica de la instalación en particular y la configura tu grupo de herramientas de redes local.

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

Sin embargo, si implementas la API testmycompany con la URL base de /salesdemo, los usuarios podrán acceder a la API con http://api.mycompany.com:80/salesdemo. Si implementas tu API miempresa con la URL base de /, tus usuarios acceden a la API mediante la URL http://api.mycompany.com:80/.

Requisitos de puertos perimetrales

La necesidad de administrar el firewall va más allá de los hosts virtuales. Los firewalls de VM y de host físico deben permitir que el tráfico de los puertos que requieren los componentes se comuniquen entre sí.

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

Notas sobre este diagrama:

  • *El puerto 8082 del Message Processor solo debe estar abierto para que acceda el router cuando configures 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 abierta en el procesador de mensajes para administrar el componente, pero el router no requiere acceso a él.
  • Los puertos con la prefijo “M” son puertos que se usan para administrar el componente y deben estar abiertos en el componente para que el servidor de administración pueda acceder a ellos.
  • Los siguientes componentes requieren acceso al puerto 8080 del servidor de administración: router, procesador de mensajes, IU, Postgres y Qpid.
  • Un Message Processor debe abrir el puerto 4528 como su puerto de administración. Si tiene varios Message Processor, deben poder acceder entre sí a través del puerto 4528 (indicado por la flecha de bucle en el diagrama anterior del puerto 4528 en el Message Processor). Si tienes varios centros de datos, el puerto debe ser accesible desde todos los procesadores de mensajes de todos los centros de datos.
  • Si bien no es obligatorio, puedes abrir el puerto 4527 en el router para que cualquier procesador de mensajes pueda acceder a él. De lo contrario, es posible que veas mensajes de error en los archivos de registro del 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 en el router).
  • La IU de Edge requiere acceso al router en los puertos que exponen los proxies de API, a fin de admitir el botón Enviar en la herramienta de seguimiento.
  • El servidor de administración requiere acceso al puerto JMX en los nodos de Cassandra.
  • Se puede configurar el acceso a los puertos JMX para que requieran un nombre de usuario y una contraseña. Consulta Cómo supervisar para obtener más información.
  • De forma opcional, puedes configurar el acceso a TLS/SSL para ciertas conexiones que pueden usar puertos diferentes. Consulta TLS/SSL para obtener más información.
  • Si configuras dos nodos de Postgres para usar la replicación de instancia principal en espera, debes abrir el puerto 22 en cada nodo a fin de acceder con SSH. De manera opcional, puedes abrir puertos en nodos individuales para permitir el acceso SSH.
  • Puedes configurar el servidor de administración y la IU de Edge para enviar correos electrónicos a través de un servidor SMTP externo. Si lo haces, debes asegurarte de que el servidor de administración y la IU puedan acceder al puerto necesario en el servidor SMTP. En el caso de SMTP que no es TLS, el número de puerto suele ser 25. Para SMTP habilitado con TLS, suele ser 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 y cualquier otro puerto que use para hosts virtuales

Servidor de administración

8080

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

1099

Puerto JMX

4526

Para llamadas de administración y caché distribuida

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 comunicaciones del router

8082

Puerto de administración predeterminado para el procesador de mensajes y debe estar abierto en el componente para que el servidor de administración pueda acceder.

Si configuras TLS/SSL entre el router y el procesador de mensajes, el router lo usará para realizar verificaciones de estado en el procesador de mensajes.

1101

Puerto JMX

4528

Para llamadas de administración y almacenamiento en caché distribuidos entre Message Processor y para comunicaciones del router

Router

8081

Puerto de administración predeterminado para el router y debe estar abierto en el componente para que el servidor de administración pueda acceder.

4527

Para llamadas de administración y caché distribuida

15999

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

Para obtener el estado de un router, el balanceador de cargas realiza 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 usa la utilidad apigee-validate para probar la instalación de Edge. 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

La usan otros componentes, como el servidor de administración, el router, el procesador de mensajes, etcétera.

2,888, 3,888

Se utiliza internamente para la comunicación del clúster de ZooKeeper (conocida como ensamble ZooKeeper)

Cassandra

7,000, 9,042 y 9,160

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

7199

Puerto JMX. Debe estar abierto para que acceda el servidor de administración.

Qpid

5672

Se usa para las comunicaciones del router y el procesador de mensajes al servidor Qpid

8083

Puerto de administración predeterminado en el servidor Qpid y debe estar abierto en el componente para que el servidor de administración pueda acceder.

1102

Puerto JMX

4529

Para llamadas de administración y caché distribuida

Postgres

5432

Se usa para la comunicación de Qpid/Management Server a Postgres

8084

Puerto de administración predeterminado en el servidor de Postgres y debe estar abierto en el componente para que el servidor de administración pueda acceder.

1103

Puerto JMX

4530

Para llamadas de administración y caché distribuida

22

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

LDAP

10,389

OpenLDAP

SmartDocs

59002

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

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

Número de puerto

Propósito

Componente de origen

Componente de destino

<puerto virtual del host#>

HTTP y cualquier otro puerto que use para el tráfico de llamadas a la API de host virtual. Los puertos 80 y 443 se usan con mayor frecuencia; el router de mensajes puede finalizar conexiones TLS/SSL.

Cliente externo (o balanceador de cargas)

Objeto de escucha en el router de mensajes

De 1099 a 1103

Administración de JMX

Cliente de JMX

Management Server (1099)

Message Processor (1101)

Qpid Server (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

Gestión del interno del zoológico

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 llamadas de administración y caché distribuida, y para comunicaciones entre routers

Servidor de administración

Router

Router

4,528

Para llamadas de caché distribuidas entre Message Processor y para comunicaciones del router

Servidor de administración

Router

Message Processor

Message Processor

4,529 Puerto de administración de RPC para caché distribuida y llamadas de administración Servidor de administración Servidor Qpid
4,530 Puerto de administración de RPC para caché distribuida y 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 el servidor de administración acceda al nodo de Cassandra.

Cliente JMX

Cassandra

8080

Puerto de la API de Management

Clientes de la API de Management

Servidor de administración

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 depende de la configuración, pero debe estar abierto en el componente para que el servidor de administración pueda acceder a él.

Clientes de la API de Management

Router (8081)

Procesador de mensajes (8082)

Qpid Server (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 de Edge

Navegador

Servidor de IU de administración

9,042

Transporte nativo de CQL

Router

Message Processor

Servidor de administración

Cassandra

9160

Cliente de segundas 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 está disponible.

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

59,002

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

SmartDocs

Router

Un procesador de mensajes mantiene un grupo de conexiones dedicado abierto a Cassandra, que está configurado para que nunca se agote el tiempo de espera. Cuando un firewall se encuentra entre un procesador de mensajes y un servidor Cassandra, el firewall puede agotar el tiempo de espera de la conexión. Sin embargo, el procesador de mensajes no está diseñado para restablecer las conexiones a 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 componentes.

Si un firewall está entre el router y los procesadores de mensajes, y tiene configurado un tiempo de espera de TCP inactivo, recomendamos lo siguiente:

  1. Configura net.ipv4.tcp_keepalive_time = 1800 en la configuración de sysctl en el SO Linux, en el que 1800 debe ser inferior al tiempo de espera de TCP inactivo del firewall. Esta configuración debe mantener la conexión en un estado establecido para que el firewall no la desconecte.
  2. En todos los Message Processor, edita /<inst_root>/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 procesador de mensajes:
    > /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. En todos los routers, edita /<inst_root>/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:
    > /opt/apigee/apigee-service/bin/apigee-service edge-router restart

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

Requisitos del puerto de BaaS de la API

Si eliges instalar el BaaS de la API, debes agregar los componentes de la pila de BaaS de la API y del portal de BaaS de la API. Estos componentes usan los puertos que se muestran en la siguiente imagen:

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, se descarga la app del portal en el navegador. Luego, la app del portal que se ejecuta en el navegador realiza solicitudes a los nodos de la pila de BaaS.
  • Una instalación de producción de BaaS de API usa un balanceador de cargas entre el nodo del portal de BaaS de la API y los nodos de la pila de BaaS de la API. Cuando configuras el portal y haces llamadas a la API de BaaS, debes especificar la dirección IP o el nombre de DNS del balanceador de cargas, no de los nodos de Stack.
  • Todos los nodos de Stack deben abrir el puerto 2551 para acceder desde todos los demás nodos de Stack (indicado por la flecha de bucle en el diagrama anterior del puerto 2551 en los nodos de Stack). Si tienes varios centros de datos, se debe poder acceder al puerto desde todos los nodos de pila de 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. En el caso de SMTP que no es TLS, el número de puerto suele ser 25. Para SMTP de TLS habilitado, suele ser 465, pero consulta con tu proveedor de SMTP.
  • Los nodos de Cassandra se pueden dedicar a BaaS de API o se pueden compartir con Edge.

En la siguiente tabla, se muestran los puertos predeterminados que deben abrirse 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 la API

8080

Puerto en el que se reciben las solicitudes a la API

2551

Puerto para la comunicación entre todos los nodos de Stack Todos los demás nodos de Stack del objeto deben poder acceder a ellos.

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

ElasticSearch

9,200 a 9,400

Para comunicarse con la pila de BaaS de la API y comunicarse entre los nodos de ElasticSearch

Licencias

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

El instalador copia el archivo de licencia en /<inst_root>/apigee/customer/conf/license.txt.

Si el archivo de licencia es válido, el servidor de administración valida el vencimiento y permite el recuento de procesador de mensajes (MP). Si alguno de los parámetros de configuración de licencia venció, puedes encontrar los registros en la siguiente ubicación: /<inst_root>/apigee/var/log/edge-management-server/logs. En este caso, puedes comunicarte con el equipo de asistencia de Apigee para obtener detalles sobre la migración.

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