Requisitos de instalación

Edge para la nube privada v4.18.01

Requisitos de hardware

Debes cumplir con los siguientes requisitos mínimos de hardware para tener una infraestructura de alta disponibilidad en un entorno de nivel de producción. En todos los casos de instalación que se describen en Topologías de instalación, las siguientes tablas 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 que requiere el sistema operativo. Según tus aplicaciones y el tráfico de red, es posible que tu instalación requiera 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 enumeran los requisitos de hardware si deseas instalar API BaaS:

Requisitos del sistema operativo y del 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 en Software y versiones compatibles.

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 "apigee". Si es necesario, puedes ejecutar los componentes como un usuario diferente.

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 vínculo simbólico 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 /opt/apigee.

Crea un vínculo simbólico desde /opt/apigee

Antes de crear el vínculo simbólico, 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 vínculo simbólico, sigue estos pasos antes de descargar el archivo bootstrap_4.18.01.sh. Debes realizar todos estos pasos como administrador raíz:

1. Crea el usuario y el grupo "apigee":

   groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee

2. Crea un vínculo simbólico desde /opt/apigee hasta 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.

3. Cambia la propiedad de la raíz de instalación y el vínculo simbólico al usuario "apigee":

   chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

Antes de la instalación, debes tener instalada una versión compatible de Java 1.8 en cada máquina. Los JDK admitidos se enumeran en Software y versiones admitidos.

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 comenzar a usar los 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 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 el parámetro de configuración:

• hostname devuelve el nombre de la máquina
• hostname -i devuelve la dirección IP del nombre de host al 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. Para obtener más información, consulta la documentación de tu sistema operativo específico.

Si un servidor tiene varias tarjetas de interfaz, el comando "hostname -i" devuelve una lista de direcciones IP separadas por espacios. De forma predeterminada, el instalador de Edge usa la primera dirección IP que se devuelve, que podría no ser correcta en todas las situaciones. Como alternativa, puedes establecer la siguiente propiedad en el archivo de configuración de la instalación:

ENABLE_DYNAMIC_HOSTIP=y

Con esa propiedad establecida en "y", el instalador te solicita que selecciones la dirección IP que se usará como parte de la instalación. El valor predeterminado es "n". Consulta la Referencia del archivo de configuración de Edge para obtener más información.

TCP Wrappers

Los TCP Wrappers pueden bloquear la comunicación de algunos puertos y 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 requeridos de OpenLDAP, PostgreSQL y Cassandra.

iptables

Valida que no haya políticas de iptables que impidan la conectividad entre los nodos en los puertos de Edge requeridos. 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 del router perimetral y del portal de BaaS usan el router de Nginx y requieren acceso de lectura a /etc/rc.d/init.d/functions.

Si tu proceso de seguridad requiere que establezcas permisos en /etc/rc.d/init.d/functions, no los establezcas en 700, ya que, de lo contrario, el router no se iniciará. Los permisos se pueden establecer 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 Cassandra: factor de replicación y nivel de coherencia.

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

Después de instalar Edge para Private Cloud, puedes verificar que Cassandra esté configurado correctamente examinando el archivo /opt/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 haya establecido las siguientes propiedades:

• cluster_name
• initial_token
• partitioner
• seeds
• listen_address
• rpc_address
• snitch

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, haz lo siguiente:

1. Edita el archivo postgresql.properties:

   vi /opt/apigee/customer/application/postgresql.properties

   Si el archivo no existe, créalo.

2. Establece las propiedades mencionadas anteriormente.
3. Guarda los cambios.
4. Reinicia la base de datos de PostgreSQL:

   /opt/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 flexibles y estrictos de memlock, 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 unlimited
  apigee hard memlock unlimited
  apigee soft nofile 32768
  apigee hard nofile 65536
  apigee soft as unlimited
  apigee hard as unlimited

• En los nodos de Message Processor, 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
  apigee hard nofile 65536

  Si es necesario, puedes aumentar ese límite. Por ejemplo, si tienes una gran cantidad de archivos temporales abiertos en un momento determinado.

jsvc

"jsvc" es un requisito previo para usar la API de BaaS. 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 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, haz lo siguiente:

yum update nss

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

Inhabilita la búsqueda de DNS en IPv6 cuando se usa NSCD (Name Service Cache Daemon)

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, haz lo siguiente:

1. En cada nodo de Message Processor, edita /etc/nscd.conf
2. Establece la siguiente propiedad:

   enable-cache hosts no

Inhabilita IPv6 en Google Cloud Platform para RedHat/CentOS 7

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

Consulta la documentación de RedHat o CentOS para obtener instrucciones sobre cómo inhabilitar IPv6 en tu versión específica del SO. Por ejemplo, puedes hacer lo siguiente:

1. Abre /etc/hosts en un editor.
2. Inserta un carácter "#" en la primera columna de la siguiente línea para comentarla:

   #::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 que proporcionan EL5 o EL6.

ntpdate

Se recomienda que los tiempos de los servidores estén sincronizados. Si aún no está configurada, la utilidad ntpdate podría cumplir 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 configuraste la zona horaria del servidor en UTC.

openldap 2.4

La instalación local requiere OpenLDAP 2.4. Si tu servidor tiene 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 las instalaciones 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 el ámbito de TI, y lo mismo sucede con una implementación de Apigee Edge para la Nube Privada y los hosts virtuales. Para aclarar, hay dos usos principales del término virtual:

• Máquinas virtuales (VMs): No son obligatorias, pero algunas implementaciones usan 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.
• Hosts virtuales: Son 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).

Como ejemplo de nomenclatura, 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 la maquinaria de virtualización o un servidor DHCP de red le asignan la dirección IP 111.111.111.111. Luego, supongamos que VM2 expone una interfaz Ethernet virtual también denominada "eth0" y que se le asigna una dirección IP 111.111.111.222.

Es posible que tengamos un router de Apigee ejecutándose 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 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 (mismo nombre y puerto que los expuestos por VM1).

Es posible que el sistema operativo del host físico tenga un firewall de red. Si es así, ese firewall debe configurarse para que pase el tráfico de 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, es posible que el sistema operativo de cada VM proporcione su propio firewall en su interfaz eth0, y estos también deben 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 las llamadas a la API a diferentes proxies de API que puedes haber implementado. Los paquetes de proxies de API pueden compartir un endpoint si tienen diferentes rutas base. 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 Traffic Director 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. En el 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 /salesdemo, los usuarios accederán a esa API con http://api.mycompany.com:80/salesdemo. Si implementas tu API mycompany con la URL base /, tus usuarios accederán a la API con 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 la VM y del host físico deben permitir el tráfico para los puertos que requieren los componentes para comunicarse 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 el router acceda a él cuando configures TLS/SSL entre el router y el Message Processor. Si no configuras TLS/SSL entre el Router y el Message Processor, la configuración predeterminada, el puerto 8082, aún debe estar abierto en el Message Processor 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 él.
• 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 puerto de administración. Si tienes varios Message Processors, 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 Message Processor). Si tienes varios centros de datos, se debe poder acceder al puerto desde todos los procesadores de mensajes en todos los centros de datos.
• Si bien no es obligatorio, puedes abrir el puerto 4527 en el router para que cualquier Message Processor 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 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 Send 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 manera opcional, puedes configurar el acceso 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 principal en espera, debes abrir el puerto 22 en cada nodo para el acceso por SSH. De manera opcional, puedes abrir puertos en nodos individuales para permitir el acceso por 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 sin TLS, el número de puerto suele ser 25. Para 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 numéricamente, con los componentes de origen y 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 un 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 para que no se involucre un firewall en la implementación de estos componentes.

Si hay un firewall entre el router y los procesadores de mensajes, y tiene establecido un tiempo de espera 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 /opt/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 /opt/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 agrupada 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 la API de BaaS

Si decides instalar el BaaS de API, debes agregar los componentes de la pila de BaaS de API y el portal de BaaS de 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 la 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 realiza solicitudes a los nodos de la pila de BaaS.
• Una instalación de producción de API BaaS usa un balanceador de cargas entre el nodo del portal de API BaaS y los nodos de la pila de API BaaS. Cuando configuras el portal y cuando realizas 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 la pila.
• Todos los nodos de Stack deben abrir el puerto 2551 para permitir el acceso desde todos los demás nodos de Stack (indicado por la flecha de bucle en el diagrama anterior para el puerto 2551 en los nodos de Stack). Si tienes varios centros de datos, se debe poder acceder al puerto desde todos los nodos de la pila en todos los centros de datos.
• Debes configurar todos los nodos de BaaS Stack para que envíen 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. Para SMTP habilitado para TLS, suele ser 465, pero consulta con tu proveedor de SMTP.
• Los nodos de Cassandra pueden estar dedicados a API BaaS o compartirse con Edge.

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. 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 /opt/apigee/customer/conf/license.txt.

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

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