Requisitos de instalación

Requisitos de hardware

Debes cumplir con los siguientes requisitos mínimos de hardware para una infraestructura con alta disponibilidad en un entorno de grado de producción.

En el siguiente video, se proporcionan instrucciones de alto nivel sobre el tamaño para la instalación:

En todas las situaciones de instalación descritas en Topologías de instalación, en las siguientes tablas, se enumeran los requisitos mínimos de hardware para los componentes de instalación.

En estas tablas, los requisitos del disco duro se agregan al espacio que requiere el sistema operativo. Según las aplicaciones y el tráfico de red, es posible que la instalación requiera más o menos recursos que 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 para admitir 2,000 IOPS
Procesador o router de mensajes en la misma máquina 16 GB 8 núcleos 100GB
Procesador de mensajes (independiente) 16 GB 8 núcleos 100GB
Router (independiente) 16 GB 8 núcleos 100GB
Analytics: Postgres/Qpid en el mismo servidor 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: Principal o en espera de 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 De 30 GB a 50 GB de almacenamiento local con SSD

El tamaño predeterminado de la cola de Qpid es de 1 GB, que se puede aumentar a 2 GB. Si necesitas más capacidad, agrega nodos de Qpid adicionales.

OpenLDAP, IU o servidor de administración 8 GB 4 núcleos 60 GB
Servidor de administración o IU 4 GB 2 núcleos 60 GB
OpenLDAP (independiente) 4 GB 2 núcleos 60 GB

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

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

** El valor del disco duro de Postgres se basa en los análisis listos para usar que capturó Edge. Si agregas valores personalizados a los datos de estadísticas, estos valores deben aumentarse en consecuencia. Usa la siguiente fórmula para calcular el almacenamiento requerido:

bytes of storage needed =

  (# bytes of analytics data/request) *

  (requests/second) *

  (seconds/hour) *

  (hours of peak usage/day) *

  (days/month) *

  (months of data retention)

Por ejemplo:

(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.4 GB of storage needed

*** Network Storage se recomienda para la base de datos Postgresql por los siguientes motivos:

  • Permite escalar verticalmente el tamaño de almacenamiento de forma dinámica, si es necesario.
  • Las IOPS de red se pueden ajustar sobre la marcha en la mayoría de los subsistemas de entorno, almacenamiento y red actuales.
  • Las instantáneas de nivel de 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 por si deseas instalar los Servicios de monetización (no compatibles con la instalación Todo en uno):

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 Entre 500 GB y 1 TB de almacenamiento en red, preferiblemente con backend SSD, que admite 1,000 IOPS o más, o usa la regla de la tabla anterior.
Analytics: instancia principal o en espera independiente de Postgres 16 GB 8 núcleos Entre 500 GB y 1 TB de almacenamiento en red, preferiblemente con backend SSD, que admite 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.

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 en Software y versiones compatibles.

Java

Debes tener instalada una versión compatible de Java 1.8 en cada equipo antes de la instalación. Los JDK compatibles se enumeran en Software y versiones compatibles.

Asegúrate de que la variable de entorno 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 para instalar e iniciar componentes de Edge. Si es necesario, puedes inhabilitar SELinux o configurarlo en modo permisivo durante la instalación y volver a habilitarlo después de la instalación. Consulta Instala la utilidad de apigee-setup de Edge para obtener más información.

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 de “apigee”. Si es necesario, puedes ejecutar 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 esta ubicación del directorio. Si bien no puedes cambiar este directorio, puedes crear un symlink para asignar /opt/apigee a otra ubicación, como se describe en Crea un symlink desde /opt/apigee.

En las instrucciones de esta guía, el directorio de instalación se anota como /opt/apigee.

Antes de crear el symlink, primero debes 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.52.01.sh. Debes realizar todos estos pasos con permisos de administrador:

  1. Crea el usuario y el grupo de “apigee”:
    groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
  2. Crea un symlink desde /opt/apigee hacia la raíz de instalación que desees:
    ln -Ts /srv/myInstallDir /opt/apigee

    En el ejemplo anterior, /srv/myInstallDir es la ubicación deseada de los archivos de Edge.

  3. 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

Configuración de la red

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

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 muestra, lo 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 configurada en "y", el instalador te pide que selecciones la dirección IP que usarás como parte de la instalación. El valor predeterminado es "n". Consulta la Referencia del archivo de configuración perimetral para obtener más información.

Wrappers TCP

Los wrappers de TCP 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 puerto en los puertos requeridos 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 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

Acceso al directorio

En la siguiente tabla, se enumeran los directorios de los nodos de Edge que tienen requisitos especiales de los procesos de Edge:

Servicio Directorio Descripción
Router /etc/rc.d/init.d/functions

El router perimetral usa el router Nginx y requiere 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á.

Puedes establecer los permisos en 744 para permitir el acceso de lectura a /etc/rc.d/init.d/functions.

Zookeeper /dev/random La biblioteca cliente de Zookeeper requiere acceso de lectura al generador de números aleatorios /dev/random. Si se bloquea /dev/random durante la lectura, es posible que el servicio de Zookeeper no se inicie.

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 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 montón de Java en función de la memoria disponible. Para obtener más información, consulta Ajusta los recursos de Java en caso de una degradación del rendimiento o de 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 /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 establezca 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 en función de 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 el archivo postgresql.properties:
    vi /opt/apigee/customer/application/postgresql.properties

    Si el archivo no existe, créalo.

  2. Configura 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 de memoria simple y fija, noarchivo y espacio de direcciones (as) para el usuario de instalación (la configuración predeterminada 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
    apigee soft nproc 32768
    apigee hard nproc 65536
  • En los nodos de Message Processor, establece la cantidad máxima de descriptores de archivos abiertos en 64,000 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.

  • Si alguna vez ves el siguiente error en un router o procesador de mensajes system.log, es posible que los límites del descriptor de archivo sean demasiado bajos:

    "java.io.IOException: Too many open files"
    

    Para verificar tus límites de usuarios, ejecuta lo siguiente:

    # su - apigee
    $ ulimit -n
    100000
    

    Si sigues alcanzando los límites de archivos abiertos después de configurar los límites del descriptor de archivos en 100000, abre un ticket con la Asistencia de Apigee Edge para obtener más soluciones de problemas.

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. Debes asegurarte de tener instalado NSS v3.19 o una versión posterior.

Para consultar 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.

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

Si instalaste y habilitaste NSCD (Name Service Cache Daemon), los procesadores de mensajes realizan dos búsquedas de DNS: una para IPv4 y otra para IPv6. Se debe 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 de Message Processor, edita /etc/nscd.conf.
  2. Establece la siguiente propiedad:
    enable-cache hosts no

Inhabilitar 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 de la versión específica de tu SO para obtener instrucciones para inhabilitar IPv6. Por ejemplo, puedes hacer lo siguiente:

  1. Abre /etc/hosts en un editor.
  2. Inserta un carácter "#" en la columna uno de la siguiente línea para marcarla como comentario:
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. Guarda el archivo.

AWS AMI

Si instalas Edge en una Amazon Machine Image (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

libxslt

rpm

unzip

basename

grep

zócalo lua

rpm2cpio

usuarioadd

bash

Nombre de host

ls

sed

wc

bc

id

net-tools

sudo

wget

curl

libaio

perl (de procedimientos)

tar

Xerces‐c

cyrus-sasl libdb4 pgrep (de procps) tr qué delicia

date

libdb-cxx

ps

uuid

chkconfig

dirname libibverbos pwd uname  
echo librdmacm python    

ntpdate

Apigee recomienda que los tiempos de tus servidores estén sincronizados. Si aún no está configurada, la utilidad ntpdate podría cumplir con este propósito, que verifica si los servidores están sincronizados en el tiempo. 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 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, se requiere 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, como sucede con Apigee Edge para la implementación de la nube privada y los hosts virtuales. A modo de aclaración, el término virtual tiene dos usos principales:

  • Máquinas virtuales (VM): No es necesario, pero algunas implementaciones usan tecnología de VM con el fin de crear servidores aislados para sus componentes de Apigee. Los hosts de VM, como los 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 y cuando 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, a la que se llama “eth0” dentro de la VM, y a la que la maquinaria de virtualización o un servidor DHCP de red le asigna la dirección IP 111.111.111.111. Luego, suponemos 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 un router de Apigee ejecutándose en cada una de las dos VM. 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 de VM2 expone api.mycompany.com:80 (el mismo nombre y puerto que expone VM1).

El sistema operativo del host físico podría tener un firewall de red. Si es así, se debe configurar ese firewall para que pase 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 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 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 para 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 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 como 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 mediante http://api.mycompany.com:80/salesdemo. Si implementas la API mycompany con la URL base de /, los usuarios accederán a la API mediante la URL http://api.mycompany.com:80/.

Licencias

Cada instalación de Edge requiere un archivo de licencia único que obtienes de Apigee. Deberás proporcionar la ruta 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 el vencimiento y el recuento de procesadores de mensajes (MP) permitido. Si alguna de las configuraciones de 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.