Requisitos de instalación

Requisitos de hardware

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

En el siguiente video, se proporciona una guía de alto nivel para el dimensionamiento de tu instalación:

En todas las situaciones de instalación que se describen 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 de disco duro se suman al espacio en el disco duro que requiere el sistema operativo. Según tus aplicaciones y el tráfico de red, es posible que la instalación requiera más o menos recursos de los que se indican a continuación.

bytes of storage needed =
  (# bytes of analytics data/request) *
  (requests/second) *
  (seconds/hour) *
  (hours of peak usage/day) *
  (days/month) *
  (months of data retention)

(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

Además, a continuación, se enumeran los requisitos de hardware si deseas instalar los servicios de monetización (no se admiten en la instalación todo en uno):

Requisitos de ancho de banda de la red de Cassandra

Cassandra usa el protocolo Gossip para intercambiar información con otros nodos sobre la topología de red. El uso de Gossip, combinado con la naturaleza distribuida de Cassandra, que implica comunicarse con varios nodos para operaciones de lectura y escritura, da como resultado una transferencia de datos significativa a través de la red.

Cassandra requiere un ancho de banda de red mínimo de 1 Gbps por nodo. Para las instalaciones de producción, se recomienda un ancho de banda más alto.

La latencia máxima o el percentil 99° para Cassandra debe ser inferior a 100 milisegundos.

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

Requisito previo: Habilita el repositorio de EPEL

Antes de continuar con la instalación, asegúrate de que el repositorio de EPEL (paquetes adicionales para Enterprise Linux) esté habilitado. Los comandos que uses dependen de tu versión de Red Hat Enterprise Linux (RHEL), Rocky Linux o Oracle Linux:

• Para RHEL 8.x, Rocky Linux 8.x u Oracle Linux 8.x:

  wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

  sudo rpm -ivh epel-release-latest-8.noarch.rpm

• Para RHEL 9.x, Rocky Linux 9.x o Oracle Linux 9.x:

  wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

  sudo rpm -ivh epel-release-latest-9.noarch.rpm

Java

Debes tener instaladas las versiones compatibles de Java 17 y Java 21 en cada máquina 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 para el usuario que realiza la instalación.

SELinux

Según la configuración de SELinux, Edge puede tener problemas para instalar e iniciar 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.

Crea el usuario "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 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 en Crea un vínculo simbólico desde /opt/apigee.

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

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 bootstrap_4.54.00.sh. Debes realizar todos estos pasos como 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 symlink de /opt/apigee a la raíz de instalación que desees:

   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 symlink al usuario "apigee":

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

Configuración de la red

Apigee recomienda que verifiques 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 del 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 muestra, que puede 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 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 de Edge requeridos. Si es necesario, puedes detener iptables durante la instalación con el siguiente comando:

sudo/etc/init.d/iptables stop

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:

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 del factor de replicación y el nivel de coherencia de Cassandra.

Cassandra ajusta automáticamente el tamaño del montón de Java según la memoria disponible. Para obtener más información, consulta Ajusta los recursos de Java en caso de que se produzca una degradación del rendimiento o un consumo de memoria alto.

Después de instalar Edge para nube privada, 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 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 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 que se mencionaron anteriormente.
3. Guarda los cambios.
4. Reinicia la base de datos de PostgreSQL:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Configuración regional para Rocky 9.X

Si usas Rocky 9.X, asegúrate de que tu sistema esté configurado con LANG=en_US.utf8 en la configuración regional de todo el sistema. Para configurar esto, ejecuta los siguientes comandos:

dnf -y -q install langpacks-en
localectl set-locale LANG=en_US.utf8
reboot

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 los límites de bloqueo de memoria, nofile y espacio de direcciones (as) flexibles y rígidos 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
  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 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 al mismo tiempo.

• Si alguna vez ves el siguiente error en un router o Message Processor system.log, es posible que los límites del descriptor de archivos estén configurados con un valor demasiado bajo:

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

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

  # su - apigee
  $ ulimit -n
  100000
  

  Si aún alcanzas los límites de archivos abiertos después de establecer los límites de descriptores de archivos en 100000, abre un ticket con el equipo de asistencia de Apigee Edge para solucionar problemas.

Servicios de seguridad de red (NSS)

Network Security Services (NSS) es un conjunto de bibliotecas que admite el desarrollo de aplicaciones cliente y de servidor con seguridad habilitada. 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

Inhabilita la búsqueda de DNS en IPv6 cuando uses NSCD (daemon de almacenamiento en caché del servicio de nombres)

Si instalaste y habilitaste NSCD (daemon de almacenamiento en caché del servicio de nombres), los Message Processors 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 RHEL 8 y versiones posteriores

Si instalas Edge en RHEL 8 o versiones posteriores en Google Cloud Platform, debes inhabilitar IPv6 en todos los nodos de Qpid.

Para obtener instrucciones sobre cómo inhabilitar IPv6, consulta la documentación que proporciona el proveedor de tu SO. Por ejemplo, puedes encontrar información pertinente en la documentación de Red Hat Enterprise Linux.

Requisitos previos para Amazon Linux

Antes de realizar una instalación nueva en Amazon Linux 2023.9/2023.10/2023.11 o de actualizar de la versión 4.53.01 a la 4.54.00 (en Amazon Linux 2023.9/2023.10/2023.11), edita el archivo /etc/yum.repos.d/amazonlinux.repo. La sección que contiene [amazonlinux] debe incluir lo siguiente para garantizar que los paquetes se descarguen de apigee-thirdparty y no de Amazon:exclude=postgresql18,luajit*.

Herramientas

El instalador usa las siguientes herramientas de UNIX en la versión estándar que proporciona EL5 o EL6.

Sincronización temporal

Apigee recomienda que los tiempos de tus servidores estén sincronizados. Si aún no está configurada, la utilidad ntpdate o una herramienta equivalente puede servir para este propósito, ya que verifica si los servidores están sincronizados en el tiempo. Por ejemplo, puedes usar yum install ntp o un comando equivalente para instalar la utilidad. Esto es particularmente útil para replicar configuraciones de LDAP. Ten en cuenta que debes configurar la zona horaria del servidor en UTC.

Firewalls y hosts virtuales

El término virtual suele sobrecargarse en el ámbito de TI, y lo mismo ocurre con una implementación de Apigee Edge para la nube privada y los hosts virtuales. Para aclarar, 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.
• Hosts virtuales: Son extremos web, similares 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 asignación de nombres, un solo servidor físico A podría ejecutar dos VMs, llamadas "VM1" y "VM2". Supongamos que "VM1" expone una interfaz de Ethernet virtual, 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, supongamos que VM2 expone una interfaz de 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 VMs. Los routers exponen los 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 VM2 expone api.mycompany.com:80 (mismo nombre y puerto que expone VM1).

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

La ruta de acceso 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 rutas de acceso base diferentes. Por ejemplo, una ruta de acceso 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 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 particular y la configura tu grupo de redes local.

La ruta de acceso 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 de api.mycompany.com y el puerto configurado en 80. Si no declaras una ruta de acceso 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 accederán 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/.

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 el vencimiento y el recuento permitido de Message Processor (MP). 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 de la migración.

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