Recomendaciones para el hosting de los componentes del servidor de Sage X3 V12

Recomendaciones generales sobre el hardware

A continuación, se indican algunas recomendaciones generales sobre el hardware que hay que utilizar para obtener el mayor rendimiento.

Se incluirán recomendaciones de tamaño adicionales en una actualización posterior de este documento.

Consideraciones sobre la CPU

CPU Intel®

Independientemente de si la solución Sage X3 V12 está alojada en servidores físicos o virtuales, el hardware utilizado se debe basar en las últimas generaciones de procesadores (Intel® Xeon® E5 v3 o posterior, E7 v3 o posterior).

Sage recomienda utilizar la última versión (tercera generación) o las generaciones anteriores (primera y segunda) de las ediciones Gold o Platinum de los procesadores escalables Intel® Xeon®.

CPU AMD™

Los procesadores Opteron™, optimizados para el punto flotante, son más lentos que los procesadores equivalentes Intel® Xeon® en la mayoría de los cálculos de Sage X3 basados en enteros DCB (para evitar la pérdida de precisión del punto flotante).

Los procesadores EPYC™ de primera generación (serie 7001) tienen un menor rendimiento que los procesadores Intel® Xeon® de la misma generación. No se recomienda utilizarlos.

Los procesadores EPYC™ de segunda generación (serie 7002) se pueden utilizar. Su rendimiento es similar al de los procesadores escalables Intel® Xeon® de la misma generación.

Velocidad del reloj de procesadores

Una velocidad del reloj de la CPU elevada aumenta el rendimiento de la aplicación en las operaciones individuales. Un elevado número de núcleos en la CPU mejora la tolerancia global ante una carga de trabajo multiusuario.

Hay que encontrar el equilibrio entre la gran velocidad del reloj y el alto número de núcleos. Solo los procesadores costosos permiten obtener ambos a la vez.

Evita los procesadores de bajo consumo con una velocidad del reloj baja (modelos Xeon® L); no tienen un buen rendimiento. Para obtener mejores resultados, utiliza procesadores a, al menos, 2,4 GHz.

Para cargas uniproceso elevadas (subproceso), también puedes utilizar un procesador con una velocidad del reloj de base de al menos 2,8 GHz.

Consideraciones sobre la memoria

La velocidad de bus de la memoria debe ser máxima, puesto que la arquitectura de Sage X3 requiere poco ancho de banda de la memoria.

Ten en cuenta que, en algunas generaciones de placas base, el ancho de banda real del bus de la memoria disminuye en función del número de tarjetas de memoria (chips) instaladas.

En este caso, se ralentiza la velocidad de bus de la memoria, puesto que la memoria global está compuesta por un gran número de pequeñas tarjetas de memoria (con pequeños chips de memoria). Es recomendable utilizar pocas tarjetas de memoria, pero con gran capacidad (con chips de gran tamaño). No obstante, esta configuración suele resultar más costosa.

Consulta la documentación técnica del servidor antes de elegir una configuración de componentes para la memoria RAM.

Consideraciones sobre la red

Redes entre servidores RDBMS y motor de ejecución/aplicación

Sage X3 es un producto altamente interactivo debido al número de comunicaciones que existen entre la capa de aplicación y la capa de base de datos.

Para obtener el mejor rendimiento y experiencia de usuario, asegúrate de que el tiempo de respuesta de la red es lo más corto posible entre ambas capas.

Cuando el RDBMS y las capas de aplicación/ejecución no se alojan en el mismo servidor, esto se consigue gracias a un equipamiento de red de alta calidad de 10 Gbit/s y prestando especial atención a la pila de red (controladores de adaptadores de red, firmware de conmutadores de red, tipos de tarjetas de red virtuales, etc.).

Redes entre motor de ejecución/aplicación y servidor Syracuse Sage X3

Este tipo de acceso de red es menos restringido: cuando la base de datos y la aplicación se alojan en el mismo servidor (sin ruta física de acceso a la red entre RDBMS y la ejecución), puedes utilizar un equipamiento de red de 1 Gbit/s.

Consideraciones sobre el almacenamiento

Almacenamiento de datos Oracle o SQL Server

La calidad del sistema de almacenamiento es fundamental para el rendimiento de la base de datos.

La configuración de tu almacenamiento debe permitir optimizar el rendimiento en IOPS de los volúmenes en los que se alojan los ficheros de datos, independientemente de si utilizas Oracle (espacio de tablas de sistema, de datos o de índice y Redo Logs) o SQL Server (ficheros de datos TempDB, grupos de ficheros de índice, de datos o de registros).

Para ello, puedes utilizar un almacenamiento SSD (con sistema de redundancia RAID-10, RAID-1, RAID-5 o RAID-6). También puedes utilizar una configuración RAID óptima con discos "giratorios" (número elevado de lectores de disco 15 krpm con redundancia RAID-10).

Es preferible utilizar un número elevado de pequeños lectores de disco que un número ilimitado de lectores de gran tamaño. La capacidad en IOPS depende del número, no del tamaño, de los lectores de una matriz RAID.

Nunca debes utilizar un lector 7.2 krpm y/o un sistema RAID-5 o RAID-6 para alojar una base de datos de producción.

Almacenamiento de la aplicación Sage X3

El almacenamiento de la aplicación Sage X3 no requiere tantas IOPS como el almacenamiento de la base de datos.

En la aplicación Sage X3, los componentes pueden utilizar un nivel de almacenamiento moderado en términos de IOPS, como los lectores de disco 10 krpm con una redundancia RAID-5 o RAID-6.

Los lectores 7.2 krpm no son recomendables, puesto que pueden afectar al rendimiento de las operaciones técnicas (integración del parche, creación del dossier, etc.

Almacenamiento de datos MongoDB

A menos que necesites un almacenamiento intensivo de archivos adjuntos de Sage X3 en MongoDB, las necesidades en IOPS suelen ser moderadas.

Puedes utilizar el mismo tipo de configuración de almacenamiento que para Sage X3.

Los lectores 7.2 krpm no son recomendables, puesto que pueden ralentizar las operaciones en el caso de una gran concurrencia de acceso a MongoDB. Por ejemplo, cuando se crean varias trazas de usuario en Sage X3 en un breve espacio de tiempo.

Almacenamiento de datos Elasticsearch

Si vas a realizar un uso masivo de la indexación Elasticsearch, se recomienda utilizar un nivel de almacenamiento efectivo para alojar los datos Elasticsearch.

Un disco SSD puede resultar excesivo. Para proporcionar una respuesta adecuada a las consultas de búsqueda de los usuarios y a las actualizaciones de los índices Elasticsearch, utiliza discos 10 krpm en RAID-10.

Otro almacenamiento de componentes Sage X3

La mayoría de los demás componentes de Sage son datos estadísticos, con acceso limitado al disco, que no requieren almacenamiento de gran nivel. Los discos 10 krpm en RAID-5 o RAID-6 son suficiente.

Los discos 7.2 krpm pueden afectar a las operaciones técnicas, como la actualización de componentes.

Consideraciones sobre la virtualización

La solución se puede implementar en servidores físicos o en un entorno virtual como VMware vSphere, Hyper-V, RedHat KVM, Citrix XenServer u Oracle VM.

Estos componentes de Sage X3 se pueden instalar en máquinas virtuales:

• servidores de procesos principales y de aplicación
• servidores de proceso adicionales
• servidores MongoDB
• servidores Elasticsearch
• servidores web Syracuse
• servidores de impresión
• servidores ADC (terminales móviles)

Para virtualizar la arquitectura, debes establecer una infraestructura física que esté adaptada a un entorno virtual con el objetivo de obtener el mejor rendimiento. Es recomendable utilizar recursos específicos asignados al entorno de Sage X3; no recursos compartidos.

Una arquitectura de virtualización de producción se suele componer de varios hosts físicos y está basada en un sistema de almacenamiento compartido (SAN) que responde a las necesidades (rendimiento y entrada/salida) de todas las máquinas virtuales y aplicaciones alojadas.

Excepto en entornos de pruebas, desarrollo o producción, NO es RECOMENDABLE ejecutar el RDBMS (SQL Server u Oracle) en un entorno virtualizado.

No obstante, si optas por ejecutar el RDBMS desde una máquina virtual, debes tomar todas las precauciones necesarias para garantizar que dicha máquina virtual pueda proporcionar una capacidad óptima de ejecución en cualquier momento y que no haya ningún cuello de botella en la CPU, la memoria o el almacenamiento entrada/salida por un exceso de recursos en la plataforma de virtualización.

Los cuellos de botella en la CPU por un exceso de recursos también tienen un gran impacto en el rendimiento de los servidores que alojan los motores de ejecución 4GL (motor de ejecución de Sage X3).

Para determinar la calidad de una infraestructura de cualquier tipo (física o virtual, de uno o varios niveles, Oracle o SQL Server, Unix-Linux o Windows, etc.), Sage proporciona el programa de pruebas AIOBENCH, que permite evaluar el rendimiento de Sage X3. Se realiza un conjunto de operaciones de entrada/salida de datos en el dossier de referencia para simular transacciones de alto nivel.

Los resultados de este programa permiten comparar el rendimiento medido con los sistemas de referencia estándar y la valoración de los clientes de otras infraestructuras de producción.

Consideraciones sobre la seguridad

Consideraciones importantes sobre el tamaño para la virtualización

En la mayoría de los casos, un entorno de Sage X3 completo ejecutado en un servidor físico de doble conector con 24 núcleos no funciona correctamente con una máquina virtual 24-vCPU de gran tamaño; hay que dividirla en varias máquinas virtuales más pequeñas.

Un límite máximo razonable sería de 4 a 6 vCPU por máquina virtual. Si la plataforma de virtualización contiene servidores con un alto número de núcleos Y no hay ningún exceso de CPU, o este es moderado, se puede aumentar el límite.

Buenas prácticas en la virtualización de MongoDB, Elasticsearch y Syracuse

El uso de varios servidores permite adaptar más fácilmente la configuración, ya que los distintos componentes no compiten para los mismos recursos (memoria, CPU, disco entrada/salida) en una misma máquina virtual. De esta forma, si se constata un cuello de botella en uno de los componentes, se puede modificar más fácilmente la implementación.

MongoDB suele requerir menos CPU y memoria que los componentes node.js. Puedes comenzar por una configuración de máquina virtual más restringida. Idealmente, debes parametrizar un clúster (conjunto de réplicas) con un número impar de núcleos (3 es un buen comienzo). Hay numerosos recursos en Internet sobre las herramientas y técnicas para sincronizar la implementación de MongoDB. Evita que el tamaño y la arquitectura sean demasiado grandes, a menos que MongoDB suponga un cuello de botella en el rendimiento. MongoDB está diseñado para permitir un número muy elevado de conjuntos de datos y tasas de transacción muy elevadas. Los recursos que solicita Sage X3 son insignificantes comparados con las páginas y aplicaciones web más voluminosas que utilizan MongoDB.

Elasticsearch utiliza más memoria y CPU que MongoDB, pero el uso puede variar considerablemente. Puedes comenzar por la misma configuración que MongoDB y, si es necesario, aumentarla. Un dato interesante sobre el componente Elasticsearch es, por ejemplo, que está desvinculado del resto. Si surge algún problema de rendimiento a este nivel, no afectará al resto de la aplicación; solo a la función de búsqueda. El componente se puede reutilizar fácilmente en una máquina virtual más voluminosa, ya que no contiene datos críticos. Es un índice que se puede reconstruir a partir de datos de una base MongoDB o Sage X3 (SQL u Oracle). También se puede agrupar en clúster (encontrarás recursos sobre la implementación del clúster en Internet).

Node.js (servidor Syracuse) es el elemento más difícil de configurar de los tres y el que suele causar más problemas de rendimiento.

Sugerencias para virtualizar el nivel de presentación

Consideraciones sobre la CPU y la memoria para Syracuse

Si se aplican los valores de configuración por defecto, un proceso node.js estándar debería requerir menos de 1,5 GB de RAM. En ese caso, el proceso lanza una recuperación de memoria agresiva, lo que suele saturar el subproceso de la CPU. Es importante mantener los procesos node.js individuales por debajo del 75 % de 1 CPU (20 % del total de la CPU en una máquina virtual de 4 núcleos) y por debajo de 1,5 GB.

Tienes que conservar recursos CPU para el sistema operativo, de modo que una máquina virtual Syracuse debe tener al menos 2 núcleos. Debe haber un mínimo de 2 GB de RAM disponible para el sistema operativo.

Se requiere un proceso node.js para aproximadamente 25 sesiones interactivas, según la actividad de dichas sesiones. Para un usuario de páginas clásicas, una sesión corresponde a una pestaña o una sección abierta. Para un usuario de funciones Syracuse, hace falta una sesión adicional para todas las pestañas o secciones abiertas.

Se requiere un núcleo de CPU para 2-4 procesos node.js (según su actividad).

Por ejemplo, una máquina virtual con 2 núcleos y 8 GB es suficiente para ejecutar 4 procesos node.js con los valores de tamaño por defecto.

Si quieres gestionar tablas voluminosas en las páginas clásicas, debes aumentar el tamaño de la memoria asociada al node.js (hasta 8 GB). Para más información, consulta la documentación sobre el tamaño de los node.js.

Recuerda estas normas:

• Node.js es uniproceso. Si tienes 4 núcleos y el proceso node.js solicita el 25 % de la CPU total, el subproceso de la CPU está saturado (no recomendable).
• Vigila el uso global de la memoria mientras la aplicación está en ejecución y aumenta el número de procesos de nodos antes de que el uso global de la memoria alcance el 75-80 %.

Tamaño de los servicios web

Si la mayoría de las transacciones utilizan servicios web, es recomendable implementar un clúster de node.js y dedicar uno o varios procesos de nodos del clúster a los servicios web.

En ese caso, asegúrate de no utilizar los servicios web y las sesiones interactivas en los mismos nodos.

Tamaño de MongoDB

Ten en cuenta estos elementos para la instancia MongoDB:

• El tamaño de la memoria MongoDB no está vinculado al tamaño de la memoria Syracuse. MongoDB suele utilizar menos de 1 GB, lo que permite utilizar una máquina virtual de 3 GB.
• Asigna siempre un 20 % menos de la CPU de la máquina virtual a MongoDB que a Syracuse.

Tamaño de Elasticsearch

Elasticsearch requiere al menos 2 núcleos y 4 GB de RAM, y se debe almacenar en una máquina virtual específica. Si indexas una base de datos muy voluminosa, puede que necesites más CPU y memoria.

Consideraciones sobre el almacenamiento

Syracuse realiza muy pocas entradas/salidas. Guarda los discos de MongoDB y Elasticsearch.