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. Para todos los casos de instalación descritos 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 del disco duro se suman al espacio que requiere el sistema operativo. Según las aplicaciones y el tráfico de red, tu 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 |
Almacenamiento local de 250 GB con SSD o HDD rápido que admite 2,000 IOPS |
Procesador de mensajes o router en la misma máquina |
8/16GB |
4 núcleos† |
100GB |
Analytics: Postgres/Qpid en el mismo servidor (no se recomienda para la producción) |
16GB* |
8 núcleos* |
Entre 500 GB y 1 TB** de almacenamiento en red***, preferentemente con backend SSD, que admite 1,000 IOPS o más.* |
Analytics: Postgres independiente |
16GB* |
8 núcleos* |
Entre 500 GB y 1 TB** de almacenamiento en red***, preferentemente con backend SSD, que admite 1,000 IOPS o más*. |
Analytics: Qpid independiente |
8 GB |
4 núcleos |
Almacenamiento local de 30 GB a 50 GB 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 de Qpid es de 20 GB. Si necesitas agregar más capacidad, agrega nodos de Qpid adicionales. |
Otro (OpenLDAP, IU, Management Server) |
4 GB |
2 núcleos |
60 GB |
† Ajusta los requisitos del sistema de Message Processor según la capacidad de procesamiento: La recomendación mínima es de 4 núcleos y 8 núcleos para un sistema de alta capacidad de procesamiento. Puedes ejecutar pruebas de rendimiento para determinar el tamaño óptimo para tus APIs. |
|||
*Ajusta los requisitos del sistema de Postgres según la capacidad de procesamiento:
|
|||
**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 deben aumentar en consecuencia. Usa la siguiente fórmula para estimar el almacenamiento requerido: |
|||
*** Se recomienda el almacenamiento en red para la base de datos Postgresql por los siguientes motivos:
|
Además, a continuación se enumeran los requisitos de hardware si desea 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 |
Almacenamiento en red de 500 GB a 1 TB, preferentemente con backend SSD que admita desde 1, 000 IOPS o más, o usa la regla de la tabla anterior. |
Analytics: Postgres independiente |
16 GB |
8 núcleos |
Almacenamiento en red de 500 GB a 1 TB, preferentemente con backend SSD que admita desde 1, 000 IOPS o más, o usa la regla de la tabla anterior. |
Analytics: Qpid independiente |
8 GB |
4 núcleos |
Almacenamiento local de 40 GB a 500 GB 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 API BaaS:
Componente de la BaaS de la API |
RAM |
CPU |
Disco duro |
---|---|---|---|
ElasticSearch* |
8 GB |
4 núcleos |
De 60 a 80 GB |
Pila de API BaaS * |
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, se usa el mismo clúster de Cassandra para los servicios perimetrales y de BaaS de la API) |
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 la API de BaaS Stack en el mismo nodo. Si es así, configura ElasticSearch para usar 4 GB de memoria (predeterminado). 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 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 realizar una instalación nueva.
- La carpeta temporal /tmp de todo el sistema 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” exista como directorio principal y sea propiedad de “apigee:apigee”.
Requisitos de 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 el software de terceros que se enumeran aquí: 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. Esto significa que los componentes de Edge se ejecutan como el usuario de “Apigee”. Si es necesario, puedes ejecutar componentes como un usuario diferente. Consulta "Vincula el router a un puerto protegido" en Instala 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 la ubicación de este directorio. Si bien no puedes cambiar este directorio, puedes 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.
Crea un symlink desde /opt/apigee
Antes de crear el symlink, primero debes crear un usuario y un 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 boot_4.17.01.sh. Debes realizar todos estos pasos como raíz:
- Crea el usuario y grupo de “apigee”:
> groupadd -r apigee
> useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c “Apigee platform user” apigee - Crea un symlink desde /opt/apigee a la raíz de instalación deseada:
> ln -Ts /srv/myInstallDir /opt/apigee
donde /srv/myInstallDir es la ubicación deseada de los archivos de Edge. - Cambiar la propiedad de la raíz de instalación y el symlink al usuario de “apigee”:
> chown -h apigee:apigee /srv/myInstallDir /opt/apigee
Java
Necesitas tener una versión compatible de Java1.8 instalada 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 del usuario que realiza la instalación.
SELinux
Según la configuración de SELinux, Edge puede tener problemas al instalar y, luego, iniciar los componentes de Edge. Si es necesario, puedes inhabilitar SELinux o configurarlo en el modo permisivo durante la instalación y, luego, volver a habilitarlo después de la instalación. Consulta Instala la utilidad apigee-setup de Edge 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 la configuración:
- hostname muestra el nombre de la máquina.
- hostname -i muestra la dirección IP del nombre de host que se puede acceder 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 está configurado correctamente. Consulta la documentación de tu sistema operativo específico para obtener más información.
Wrappers de TCP
Los wrappers 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 obligatorios de OpenLDAP, Postgres y Cassandra.
iptables
Valida que no haya políticas de iptables que impidan la conectividad entre los 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 Edge Router pueda acceder a /etc/rc.d/init.d/functions
Los nodos del router perimetral 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 se iniciará. Los permisos se pueden configurar 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 múltiples nodos para garantizar la confiabilidad y la tolerancia a errores. La estrategia de replicación de cada espacio de claves de Edge determina los nodos de Cassandra en los que se ubican las réplicas. Para obtener más información,consulta Acerca del factor de replicación de Cassandra y el nivel de coherencia.
Cassandra ajusta automáticamente el tamaño de su montón de Java según la memoria disponible. Para obtener más información, consulta Ajusta los recursos de Java. En caso de una degradación del rendimiento o un alto consumo de memoria
Después de instalar Edge para la nube privada, puedes verificar que Cassandra esté configurado de forma correcta si examinas 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:
- cluster_name
- initial_token
- particionador
- semillas
- listen_address
- rpc_address
- sorpresa
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:
- Edita postgresql.properties:
> vi /<inst_root>/apigee/customer/application/postgresql.properties
Si el archivo no existe, créalo. - Configura las propiedades mencionadas anteriormente.
- Guarda los cambios.
- 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 de Cassandra y Message Processor:
- En los nodos de Cassandra, establece límites de memlock soft y hard, nofile y espacio de direcciones (as) 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 podrá generar acceso ilimitado
apigee softmemlock shared
apigee soft nofile 327.
- En los nodos de Message Processor, establece la cantidad máxima de descriptores de archivos abiertos en 64K en /etc/security/limits.d/90-apigee-edge-limits.conf , como se muestra a continuación:
Apigee soft nofile 32768
Apigee hard nofile 65536
Si es necesario, puedes aumentar ese límite. Por ejemplo, si tienes una gran cantidad de archivos temporales abiertos a la vez.
JSVC
“jsvc” es un requisito previo para usar BaaS de 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 admiten el desarrollo de aplicaciones cliente y de servidor con seguridad habilitada. Debes asegurarte de tener instalado NSS v3.19 o una versión posterior.
Para verificar tu versión actual, haz lo siguiente:
> yum info nss
Para actualizar el 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é de servicio de nombres)
Si instalaste y habilitaste NSCD (daemon de caché de servicio de nombres), los procesadores de mensajes realizan 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:
- En cada nodo de Message Processor, edita /etc/nscd.conf
- Configura 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 correspondiente a la versión específica del SO para obtener instrucciones para inhabilitar IPv6.
AMI de AWS
Si instalas Edge en una imagen de máquina (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 que proporcionan EL5 o EL6.
awk |
expr |
LUA-socket |
rpm |
unzip |
basename |
grep |
ls |
rpm2cpio |
usuarioagregar |
bash |
Nombre de host |
net-tools |
sed |
wc |
bc |
id |
perl (de procps) |
sudo |
wget |
curl |
libaio |
pgrep (de procps) |
tar |
xerces-c |
cyrus-sasl
|
libdb-cxx
|
ps | tr | qué delicia |
date |
libibverbs
|
pwd |
uuid |
chkconfig |
dirname |
librdmacm
|
python | uname | |
echo |
libxslt
|
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 a través del entorno del usuario que realiza la llamada. Por ejemplo, generalmente llamarías “sudo <command>” o “sudo PATH=$PATH:/usr/sbin:/sbin <command>”.
- Asegúrate de tener la herramienta de “parche” instalada antes de instalar un Service Pack (parche).
ntpdate: se recomienda sincronizar la hora de los servidores. Si aún no se configuró, la utilidad “ntpdate” podría cumplir con este propósito, que verifica si los servidores están sincronizados con la hora. Puedes usar “yum install ntp” para instalar la utilidad. Esto es particularmente útil para replicar las configuraciones de OpenLDAP. Ten en cuenta que la zona horaria del servidor se configura 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 perimetral 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 perimetral. En RHEL/CentOS, puedes ejecutar “yum install openldap-clients openldap-servers” para instalar el OpenLDAP.
En el caso de las instalaciones de 13 hosts y las de 12 hosts con dos centros de datos, necesitas la replicación de OpenLDAP, ya que hay varios nodos que alojan OpenLDAP.
Firewalls y hosts virtuales
Por lo general, el término “virtual” se sobrecarga en el ámbito de la TI, por lo que ocurre con Apigee Edge para la implementación de la nube privada y los hosts virtuales. Cabe aclarar que el término “virtual” se usa en los siguientes dos usos principales:
- Máquinas virtuales (VM): No es necesario, pero algunas implementaciones usan la tecnología de VM a fin de crear servidores aislados para 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 difieren entre sí en su alias de host o en su puerto de interfaz).
Como ejemplo de un nombre, un único servidor físico “A” podría ejecutar dos VM, llamadas “VM1” y “VM2”. Supongamos que VM1 expone una interfaz Ethernet virtual, que recibe el nombre eth0 dentro de la VM, a la que se le asigna la dirección IP 111.111.111.111 por la máquina de virtualización, o bien a una red DHCP1, y luego expone una interfaz DHCP de la VM1.1.
Es posible que tengamos un router de Apigee que se ejecute en cada una de las dos VMs. Los routers exponen extremos de host virtuales como en este ejemplo hipotético:
El router de Apigee en VM1 expone tres hosts virtuales en su interfaz eth0 (que tiene una dirección IP específica), api.mycompany.com:80, api.mycompany.com:443 y test.mycompany.com:80.
El router en VM2 expone api.mycompany.com:80 (el mismo nombre y puerto que lo expone VM1).
El sistema operativo del host físico puede tener 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 que se conecten 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 podrías 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 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 tráfico 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ífica de tu instalación en particular y la configura el grupo de redes local.
La ruta base se establece cuando implementas una API. En el ejemplo anterior, puedes implementar dos API, mycompany y testmycompany, para la organización mycompany-org con el host virtual que tiene el alias de host api.mycompany.com y el puerto configurado en 80. Si no declaras una ruta base en la implementación, el router no sabe a qué API enviar las solicitudes entrantes.
Sin embargo, si implementas la API testmycompany con la URL base /salesdemo, los usuarios acceden a esa API con http://api.mycompany.com:80/salesdemo. Si implementas tu API mycompany con la URL base de / entonces tus usuarios accederán a la API mediante la URL http://api.mycompany.com:80/.
Requisitos del puerto perimetral
La necesidad de administrar el firewall va más allá de los hosts virtuales. Tanto los firewalls de host físicos como los de VM deben permitir el tráfico para que los puertos requeridos por 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 el acceso del router cuando se configura TLS/SSL entre el router y el 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 procesador de mensajes de todos modos para administrar el componente, pero el router no requiere acceso a él.
- Los puertos con el prefijo “M” son puertos que se usan para administrar el componente y deben estar abiertos en el componente a fin de que el servidor de administración pueda acceder a él.
- Los siguientes componentes requieren acceso al puerto 8080 en el 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 tienes varios procesadores de mensajes, todos deben poder acceder entre sí a través del puerto 4528 (indicado por la flecha de bucle en el diagrama anterior para el puerto 4528 en el procesador de mensajes). Si tienes varios 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 obligatorio, puedes abrir el puerto 4527 en el router para acceder a cualquier procesador de mensajes. 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, todos 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 expuestos por los proxies de API, para 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 requiera un nombre de usuario o contraseña. Consulta Cómo supervisar para obtener más información.
- De manera opcional, puedes configurar el acceso 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 para el acceso 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 un SMTP sin TLS, el número de puerto suele ser 25. En el caso de SMTP habilitado para TLS, suele ser 465, pero consulta con tu proveedor de SMTP.
En la siguiente tabla, se muestra que los puertos se deben abrir en firewalls, por componente de Edge:
Componente |
Puerto |
Descripción |
---|---|---|
Puertos HTTP estándar |
80, 443 |
HTTP y 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 el 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 Management |
9000 |
Puerto para que el navegador acceda a la IU de administración |
Message Processor |
8998 |
Puerto de Message Processor para las comunicaciones del router |
8082 |
Es un puerto de administración predeterminado para Message Processor. Además, debe estar abierto en el componente a fin de que el servidor de administración pueda acceder a él.
Si configuras TLS/SSL entre el router y el procesador de mensajes, que el router usará para realizar verificaciones de estado en el procesador de mensajes.
|
|
1101 |
Puerto JMX |
|
4528 |
Para caché distribuida y llamadas de administración entre procesadores de mensajes y para la comunicación desde el router |
|
Router |
8081 |
Es un puerto de administración predeterminado para el router, que debe estar abierto en el componente para que el servidor de administración pueda acceder. |
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 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 se usa para probar la instalación de Edge por medio 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 en el puerto 59001. |
|
ZooKeeper |
2181 |
Lo usan otros componentes, como el servidor de administración, el router, el procesador de mensajes, etcétera. |
2888 y 3888 |
Lo usa ZooKeeper de forma interna para la comunicación del clúster de ZooKeeper (conocido como ensamble de ZooKeeper). |
|
Cassandra |
7000, 9042 y 9160 |
Puertos de Apache Cassandra para la comunicación entre los nodos de Cassandra y el acceso a través de otros componentes de Edge |
7199 |
Puerto JMX. Debe estar abierto para que el servidor de administración tenga acceso. |
|
Qpid |
5672 |
Se usa para las comunicaciones del router y el procesador de mensajes con el servidor Qpid |
8083 |
Es el 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 caché distribuida y llamadas de administración |
|
Postgres |
5432 |
Se usa para la comunicación de Qpid/Management Server a Postgres |
8084 |
Es el 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 caché distribuida y llamadas de administración |
|
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 para el acceso SSH. |
|
LDAP |
10,389 |
OpenLDAP |
SmartDocs |
59002 |
Es el puerto del router 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 fuente |
Componente de destino |
---|---|---|---|
<puerto de host virtual#> |
HTTP más cualquier otro puerto que uses para el tráfico de llamadas a la API del host virtual. Los puertos 80 y 443 son los más usados; el router de mensajes puede finalizar las 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 JMX |
Management Server (1099) Procesador de mensajes (1101) Servidor Qpid (1102) Servidor Postgres (1103) |
2,181 |
Comunicación con el cliente de Zookeeper |
Servidor de administración Router Procesador de mensajes Servidor Qpid Servidor Postgres |
Zookeeper |
2888 y 3888 |
Administración de nodos de los cuidadores 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 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é distribuida entre procesadores de mensajes y para la comunicación desde el router |
Servidor de administración Router Procesador de mensajes |
Procesador de mensajes |
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 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 Procesador de mensajes |
Servidor Qpid |
7000 |
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 que se usa depende de la configuración, pero debe estar abierto en el componente para que el servidor de administración pueda acceder |
Clientes de la API de Management |
Router (8081) Procesador de mensajes (8082) Servidor Qpid (8083) Servidor Postgres (8084) |
8,998 |
Comunicación entre el router y el procesador de mensajes |
Router |
Procesador de mensajes |
9,000 |
Puerto predeterminado de la IU de administración perimetral |
Navegador |
Servidor de IU de administración |
9,042 |
Transporte nativo de CQL |
Router Procesador de mensajes Servidor de administración |
Cassandra |
9,160 |
Cliente de segunda mano de Cassandra |
Router Procesador de mensajes 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 | apigee-validate | 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 para 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 de Cassandra, es posible que el firewall agote 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 para 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, sigue estas recomendaciones:
- Establece net.ipv4.tcp_keepalive_time = 1800 en la configuración de sysctl en SO Linux, donde 1800 debe ser menor que el 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.
- En todos los procesadores de mensajes, 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 - Reinicia el procesador de mensajes:
> /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor reiniciar - 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 - Reinicia el router:
> /opt/apigee/apigee-service/bin/apigee-service perimetral-router reiniciación
Si instalas la configuración agrupada en clústeres de 12 hosts con dos centros de datos, asegúrate de que los nodos de los dos centros de datos puedan comunicarse a través de los puertos que se muestran a continuación:
Requisitos para los puertos de la API de BaaS
Si optas por instalar el BaaS de la API, agregas los componentes de la pila de BaaS de la API y del portal de la BaaS de la API. 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. Luego, la app del portal que se ejecuta en el navegador realiza solicitudes a los nodos de pila BaaS.
- Una instalación de producción de BaaS de la 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 configures el portal y realices llamadas a la API de BaaS, especifica la dirección IP o el nombre de DNS del balanceador de cargas, no de los nodos de pila.
- Todos los nodos de pila deben abrir el puerto 2551 para acceder desde todos los demás nodos de pila (indicado por la flecha de bucle en el diagrama anterior para el puerto 2551 en los nodos de pila). Si tienes varios centros de datos, se debe poder acceder al puerto desde todos los nodos de pila en todos los centros de datos.
- Debes configurar todos los nodos de pila de Baas para enviar correos electrónicos a través de un servidor SMTP externo. En el caso de SMTP sin TLS, el número de puerto suele ser 25. A menudo, el estándar de SMTP habilitado para TLS es 465, pero consulta con tu proveedor de SMTP.
- Los nodos de Cassandra pueden dedicarse al BaaS de la API 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 API de BaaS |
8080 |
Puerto en el que se recibe la solicitud a la API |
2551 |
Puerto para la comunicación entre todos los nodos de pila. Debe ser accesible para todos los demás nodos de pila en el generador de datos. Si tienes varios centros de datos, se debe poder acceder al puerto desde todos los nodos de pila 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 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 el recuento de procesadores de mensajes (MP). Si alguna de las opciones de configuración de licencias 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í.