Requisitos de instalación

Edge for Private Cloud v. 4.16.05

Requisitos de hardware

Debes cumplir con los siguientes requisitos mínimos de hardware para obtener una infraestructura de alta disponibilidad en un entorno de nivel de producción. En las siguientes tablas, se indican los requisitos mínimos de hardware para los componentes de instalación para todos los casos de instalación descritos en Topologías de instalación.

En estas tablas, los requisitos de disco duro se suman al espacio en disco duro 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.

Además, a continuación, se indican los requisitos de hardware si deseas instalar los servicios de monetización:

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

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 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” exista como directorio principal y sea propiedad de “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 el software de terceros que se indican 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. 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.

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.

Java

Debes tener instalada una versión compatible de Java 1.8 en cada máquina antes de la instalación. Los JDK compatibles se indican 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.

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 abordar 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 se configuró correctamente. Consulta la documentación de tu sistema operativo específico para obtener más información.

Cassandra

Todos los nodos de Cassandra deben estar conectados a un anillo.

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 degradación del rendimiento o consumo elevado de memoria.

Después de instalar Edge para la nube privada, puedes verificar que Cassandra esté configurada 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:

• cluster_name
• initial_token
• particionador
• semillas
• listen_address
• rpc_address
• delator

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. Edita postgresql.properties:
   > vi /<inst_root>/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:
   > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

jsvc

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

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 servidor habilitadas para la seguridad. Debes asegurarte de haber instalado NSS v3.19 o una versión posterior.

Para verificar tu versión actual, sigue estos pasos:

> yum info nss

Para actualizar NSS, sigue estos pasos:

> yum update nss

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

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 que proporciona EL5 o EL6.

Nota:

• El ejecutable de la herramienta "useradd" se encuentra en /usr/sbin y el de chkconfig en /sbin.
• Con el acceso sudo, puedes obtener acceso a través del entorno del usuario que realiza la llamada. Por ejemplo, por lo general, deberías llamar “sudo <command>” o “sudo PATH=$PATH:/usr/sbin:/sbin <command>”.
• Asegúrate de tener instalada la herramienta de “parche” antes de instalar un service pack (parche).

ntpdate: Se recomienda que la hora de los servidores esté sincronizada. Si aún no está configurada, la utilidad “ntpdate” podría servir para este propósito, ya 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 configuraciones de OpenLDAP. Ten en cuenta que debes configurar 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 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 estar sobrecargado en el ámbito de TI, y lo mismo sucede con una implementación de Apigee Edge para la nube privada y los hosts virtuales. A modo de aclaración, existen dos usos principales del término “virtual”:

• Máquinas virtuales (VM): No es obligatorio, pero algunas implementaciones usan la tecnología de VM para 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. Estas instrucciones de instalación no admiten específicamente las instalaciones de VM.
• Hosts virtuales: Extremos web, análogos a un host virtual de Apache.

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

A modo de ejemplo de nombres, un solo servidor físico “A” podría ejecutar dos VMs, llamadas “VM1” y “VM2”. Supongamos que VM1 expone una interfaz Ethernet virtual, que se denomina eth0 dentro de la VM y a la que se le asigna la dirección IP 111.111.111.111 por el mecanismo de virtualización o un servidor DHCP de red. Luego, supongamos que VM2 expone una interfaz Ethernet virtual también 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 extremos de host virtual como en este ejemplo hipotético:

El router de Apigee en la 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 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 se debe configurar para pasar el tráfico TCP destinado 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 el tráfico de los puertos 80 y 443 se conecte.

La ruta base es el tercer componente involucrado en el enrutamiento de llamadas a la API a diferentes proxies de API que puedes haber implementado. Los paquetes de proxy de API pueden compartir un extremo si tienen diferentes rutas de acceso básicas. Por ejemplo, una ruta de acceso base se puede definir como http://api.miempresa.com:80/ y otra como http://api.miempresa.com:80/demoventas.

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

La ruta base se establece cuando implementas una API. A partir del ejemplo anterior, puedes implementar dos APIs, 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 sabrá a qué API enviar las solicitudes entrantes.

Sin embargo, si implementas la API testmycompany con la URL base de /salesdemo, los usuarios acceden a esa API con http://api.mycompany.com:80/salesdemo. Si implementas tu API mycompany con la URL base de /, tus usuarios accederán a la API a través de 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; los firewalls de VM y de host físico deben permitir que el tráfico a 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 en Message Processor solo debe estar abierto para que el router pueda acceder a él 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, aún debe estar abierto en el procesador de mensajes para administrar el componente, pero el router no requiere acceso a él.
• Los puertos con el prefijo “M” son los 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 en el servidor de administración: router, procesador de mensajes, IU, Postgres y Qpid.
• Un procesador de mensajes 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 que cualquier procesador de mensajes pueda acceder a él. 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 del router).
• La IU de Edge requiere acceso al router, en los puertos expuestos por los proxies de API, para admitir el botón Send en la herramienta de seguimiento.
• El servidor de administración requiere acceso al puerto JMX en los nodos de Cassandra.
• El acceso a los puertos JMX se puede configurar para que requiera un nombre de usuario o una contraseña. Consulta Cómo supervisar para obtener más información.
• De manera opcional, puedes configurar el acceso a TLS/SSL para ciertas conexiones, que pueden usar diferentes puertos. Consulta TLS/SSL para obtener más información.
• 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 acceder con SSH. De manera opcional, puedes abrir puertos en nodos individuales para permitir el acceso mediante 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 es así, debes asegurarte de que el servidor de administración y la IU puedan acceder al puerto necesario en el servidor SMTP. Para el SMTP sin TLS, el número de puerto suele ser 25. Para el SMTP habilitado para TLS, suele ser 465, pero consulta con tu proveedor de SMTP.

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

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

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

Un procesador de mensajes mantiene abierto un grupo de conexiones dedicado a Cassandra, que está configurado para que nunca se agote el tiempo de espera. Cuando hay un firewall entre un procesador de mensajes y el servidor de 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 con Cassandra.

Para evitar esta situación, Apigee recomienda que el servidor de 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 hay un firewall entre el router y los procesadores de mensajes, y se configuró un tiempo de espera de TCP inactivo, te recomendamos que hagas lo siguiente:

1. Establece net.ipv4.tcp_keepalive_time = 1800 en la configuración de sysctl en el SO Linux, donde 1800 debe ser inferior al tiempo de espera de TCP inactivo del firewall. Este parámetro de configuración debería mantener la conexión en un estado establecido para que el firewall no la desconecte.
2. 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_casssandra.maxconnecttimeinmillis=-1
3. Reinicia el Message Processor:
   > /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_casssandra.maxconnecttimeinmillis=-1
5. Reinicia el router:
   > /opt/apigee/apigee-service/bin/apigee-service edge-router restart

Si instalas la configuración de clúster 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 de puertos de BaaS de la API

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

Notas sobre este diagrama:

• Los nodos de Cassandra se pueden dedicar a la BaaS de API o se pueden compartir con Edge.
• Una instalación de producción de la BaaS de API usa un balanceador de cargas entre el nodo del portal de la BaaS de API y los nodos de la pila de la BaaS de API. Cuando configures el portal y realices 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 pila.
• Debes configurar todos los nodos de la pila de Baas para enviar correos electrónicos a través de un servidor SMTP externo. Para SMTP que no sea TLS, el número de puerto suele ser 25. En el caso del SMTP habilitado para TLS, suele ser 465, pero verifica con tu proveedor de SMTP.

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

Licencias

Cada instalación de Edge requiere un archivo de licencia único que obtienes de Apigee. Debes 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 permitido de procesadores de mensajes (MP). Si alguna de las configuraciones de licencia venció, puedes encontrar los registros en 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 obtener detalles sobre la migración.