Artículo
Alberto Fuentes · Mar 12 Lectura de 12 min

Configuración del servidor web Apache HTTPD para HealthShare

Una cuestión muy común es cuál es la configuración ideal para el servidor web Apache HTTPD cuando se utiliza con HealthShare. El propósito de este artículo es describir la configuración inicial recomendada del servidor web para cualquier producto HealthShare. 

Como punto de partida, se recomienda la versión 2.4.x (64-bit) de Apache HTTPD. Existen versiones anteriores como la 2.2.x, pero no se recomienda esta versión por rendimiento y escalabilidad de HealthShare.

Configuración de Apache

Módulo de la API de Apache sin NSD

HealthShare requiere la opción de instalación del módulo de la API de Apache sin NSD. La versión de los módulos vinculados de forma dinámica depende de la versión de Apache:

  • CSPa24.so (Apache versión 2.4.x)

Es mejor dejar que la configuración de las Caché Server Pages (CSP) en el httpd.conf de Apache sea realizada por la instalación de HealthShare, la cual se explica en detalle más adelante en este documento. Sin embargo, la configuración puede realizarse manualmente. Para más información, consulta la Guía de Configuración de Apache que se encuentra en la documentación de InterSystems:  Opción recomendada: módulo de la API de Apache sin NSD (CSPa24.so)

Recomendaciones del Módulo de multiprocesamiento (MPM) de Apache

MPM Prefork de Apache vs. MPM Worker

El servidor web de Apache HTTPD incluye tres módulos de multiprocesamiento (Multi-Processsing Modules - MPM): Prefork, Worker y Event. Los MPM son responsables de conectar los equipos con los puertos de red, aceptar solicitudes y generar procesos hijos o secundarios que se encarguen de administrarlos. Por defecto, Apache se suele configurar con MPM Prefork, que no escala muy bien para un número de transacciones elevadas o altas cargas de trabajo de usuarios concurrentes.

En los sistemas de producción de HealthShare, el MPM Worker de Apache debería habilitarse por razones de rendimiento y escalabilidad. Se prefiere el MPM Worker por las siguientes razones:

  • El MPM Prefork utiliza varios procesos secundarios con un hilo de ejecución (thread) cada uno, y cada proceso controla una conexión a la vez. Al utilizar Prefork, las solicitudes concurrentes se ven afectadas porque como cada proceso solo puede manejar una sola solicitud a la vez, las solicitudes se quedan esperando en cola hasta que se libere un proceso del servidor. Además, para escalar, son necesarios más procesos secundarios de Prefork, que consumen una gran cantidad de memoria.
  • El MPM Worker utiliza varios procesos secundarios con muchos hilos de ejecución (thread) cada uno. Cada hilo de ejecución maneja una conexión al mismo tiempo, lo que es de gran ayuda para la concurrencia y reduce el uso de la memoria. Worker gestiona mejor la concurrencia que Prefork, ya que generalmente habrá hilos de ejecución libres disponibles para atender las solicitudes, en lugar de los procesos de Prefork con un solo hilo que podría estar ocupado.

Parámetros del MPM Worker de Apache

Utilizando hilos de ejecución para atender las solicitudes, Worker puede atender una gran cantidad de solicitudes empleando menos recursos del sistema que el Prefork utilizando procesos. 
Las directivas más importantes utilizadas para controlar el MPM Worker son ThreadsPerChild, que controla el número de hilos de ejecución desplegados por cada proceso hijo y MaxRequestWorkers, que controla el número total máximo de hilos que se pueden lanzar.
Los valores comunes de la directiva que se recomiendan para el MPM Worker se especifican en la siguiente tabla:

Parámetros recomendados para el servidor web Apache HTTPD
Directivas del MPM Worker de Apache Valor recomendado Comentarios
MaxRequestWorkers  Número máximo de usuarios simultáneos en el Visor Clínico de HealthShare, o el de otros componentes de HealthShare que se configuraron como la suma de todos los tamaños de grupo (*Pool Size*) de Business Services entrantes a todos los productos definidos por las producciones.
* Nota: Si no se cuenta con esta información al momento de realizar la configuración, podemos comenzar con un valor de “1000”
  MaxRequestWorkers establece el límite en la cantidad de solicitudes concurrentes que se atenderán, es decir, limita la cantidad total de hilos de ejecución que estarán disponibles para atender a los clientes. Es importante configurar correctamente MaxRequestWorkers porque si se ajusta con un nivel muy bajo, entonces se desperdiciarán los recursos; y si se configura con un nivel muy alto, entonces el rendimiento del servidor se verá afectado. Hay que tener en cuenta que cuando se intentan más conexiones que workers disponibles, las conexiones se situarán en una cola de espera. La cola de espera predeterminada se puede ajustar con la directiva ListenBackLog.  
MaxSpareThreads 250   MaxSpareThreads atiende los hilos de ejecución inactivos en todo el servidor. Si hay demasiados hilos inactivos en el servidor, se finalizan los procesos secundarios hasta que el número de hilos inactivos sea menor que este número. El aumento en la cantidad de hilos libres por encima de los predeterminados, tiene como objetivo reducir la probabilidad de que se tengan que recrear procesos.  
MinSpareThreads 75   MinSpareThreads atiende los hilos inactivos del servidor. Si no hay suficientes hilos inactivos en el servidor, se crean procesos hijo hasta que el número de hilos inactivos sea mayor que este número. La reducción en la cantidad de hilos libres por debajo del valor predeterminado, tiene como objetivo reducir la probabilidad de que se tengan que recrear procesos.  
ServerLimit MaxRequestWorkers se divide por ThreadsPerChild   El valor máximo de MaxRequestWorkers durante la vida útil del servidor. ServerLimit es un límite estricto en el número de procesos secundarios activos, y debe ser mayor o igual que la directiva MaxRequestWorkers dividida por la directiva ThreadsPerChild. Con worker, sólo se usa esta directiva si la configuración de MaxRequestWorkers y ThreadsPerChild necesita más de 16 procesos en el servidor (predeterminado).  
StartServers 20   La directiva StartServers establece el número de procesos del servidor secundario creados al inicio. Como la cantidad de procesos es controlada de forma dinámica dependiendo de la carga, por lo general hay pocas razones para ajustar este parámetro, excepto para asegurar que el servidor esté listo para administrar una gran cantidad de conexiones justo cuando se inicia.  
ThreadsPerChild 25   Esta directiva establece el número de hilos creados por cada proceso secundario, 25 de forma predeterminada. Se recomienda mantener el valor predeterminado, porque si aumenta podría llevar a la dependencia excesiva de un solo proceso.  

Para más información, consulta la documentación correspondiente a la versión de Apache:

Ejemplo para configurar el MPM Worker de Apache 2.4

En esta sección se especifica cómo configurar el MPM Worker para un servidor web Apache 2.4 de RHEL7, necesario para permitir hasta 500 usuarios simultáneos de TrakCare.

  1. Primero, verificar el MPM mediante el siguiente comando:
  2. Edita el archivo de configuración /etc/httpd/conf.modules.d/00-mpm.conf cuando sea necesario, agregando y eliminando el signo # para que solo se carguen los módulos MPM Worker. Modifica la sección MPM Worker con los siguientes valores, en el mismo orden que se indica a continuación:
  3. Reinicia Apache
  4. Después de que reinicie Apache correctamente, valida los procesos de worker ejecutando los siguientes comandos. Deberías ver algo parecido a lo siguiente, validando el proceso httpd.worker:

Fortalecimiento de Apache

Módulos requeridos de Apache

La instalación del paquete de distribución oficial de Apache habilitará, por defecto, un conjunto específico de módulos de Apache. Esta configuración predeterminada de Apache cargará estos módulos en cada proceso httpd. Se recomienda deshabilitar todos los módulos que no sean necesarios para HealthShare, por las siguientes razones:

  • reducir el consumo de recursos del proceso httpd daemon,
  • reducir la posibilidad de que falle la segmentación desde un módulo problemático,
  • reducir las vulnerabilidades de la seguridad.

En la siguiente tabla se describen los módulos de Apache recomendados para HealthShare. Cualquier módulo que no se encuentre en la lista, se puede deshabilitar:

Nombre del módulo Descripción
alias Mapea diferentes partes del sistema de archivos al equipo principal en el árbol de documentos y redirecciona la URL.
authz_host Proporciona un control de acceso basado en el nombre del equipo principal del cliente y la dirección IP.
dir Proporciona una redirección de la barra final que aloja un directorio con archivos índice.
headers Controla y modifica los encabezados de las solicitudes y respuestas de HTTP
log_config Registra las solicitudes que se le hicieron al servidor.
mime Asocia las extensiones para los nombres de los archivos solicitados con el comportamiento y el contenido de los mismos
negotiation Permite seleccionar el contenido del documento que mejor se ajuste a las funciones del cliente.
setenvif Permite configurar variables de entorno basadas en las características de la solicitud
status Muestra el estado del servidor y las estadísticas de rendimiento

Cómo deshabilitar los módulos

Los módulos que no sean necesarios deben deshabilitarse para fortalecer la configuración y de esta manera reducir los puntos vulnerables en la seguridad. El cliente es responsable de las políticas de seguridad del servidor web. Por lo menos, deben deshabilitarse los siguientes módulos.

Nombre del módulo Descripción
asis Envía archivos que contienen sus propios encabezados HTTP
autoindex Genera un directorio con índices, y muestra la lista de directorios cuando ningún archivo index.html está presente
env Modifica la variable de entorno que se transfirió a los scripts CGI y a las páginas SSI
cgi cgi, ejecución de scripts CGI
actions Ejecuta scripts CGI basados en el tipo de medios o método solicitado, o una acción que se desencadena en las solicitudes
include Documentos HTML analizados por el servidor (incluidos los que están del lado del servidor)
filter Filtrado inteligente de solicitudes
version Manejo de la información en las versiones de los archivos de configuración mediante IfVersion
userdir Mapeo de solicitudes a directorios específicos de los usuarios. Es decir, el ~username que se encuentra en la URL se traducirá a un directorio en el servidor

Apache SSL/TLS {#ApacheWebServer-ApacheSSL/TLS}

InterSystems recomienda que todas las comunicaciones que se realizan mediante TCP/IP entre los servidores y los clientes de HealthShare se cifren con SSL/TLS para proteger los datos durante las transferencias y garantizar la confidencialidad y la autenticación. Además, InterSystems también recomienda que se utilice HTTPS para llevar a cabo las comunicaciones entre los navegadores (clientes) de los usuarios y la capa del servidor web de la arquitectura propuesta. Asegúrate de consultar las políticas de seguridad de tu empresa, para garantizar que cumple con cualquier requisito de seguridad específico que tenga. 

El cliente es responsable de suministrar y administrar los certificados SSL/TLS.
Si utilizas certificados SSL, agrega ssl_module (mod_ssl.so).

Parámetros adicionales para el fortalecimiento de Apache

Para fortalecer aún más la configuración de Apache, realiza los siguientes cambios en httpd.conf:

  • TraceEnable debe desactivarse para evitar posibles problemas de seguimiento entre sitios.

  • ServerSignature debe desactivarse para que no se visualice la versión del servidor web.

Parámetros de configuración suplementarios de Apache

Keep-Alive

La configuración de Apache Keep-Alive permite utilizar la misma conexión TCP para la comunicación mediante HTTP, en vez de abrir una nueva conexión para cada nueva solicitud, es decir, Keep-Alive mantiene una conexión persistente entre el cliente y el servidor. Cuando la opción Keep-Alive está habilitada, la mejora en el desempeño proviene de la descongestión de la red, la reducción de la latencia en las subsiguientes solicitudes y el menor uso del CPU ocasionado por la apertura simultánea de las conexiones. Keep-Alive está ACTIVO por defecto y el estándar HTTP v1.1 requiere que se asuma.

Sin embargo, hay ciertas condiciones para habilitar Keep-Alive; Internet Explorer debe ser la versión 10 o superior para evitar problemas como el tiempo de espera, que se presenta en las versiones anteriores de Internet Explorer. Además, intermediarios como firewalls, balanceadores de cargas y proxies, etc., pueden interferir con las “conexiones TCP persistentes” y pueden ocasionar el cierre imprevisto de las conexiones.  

Cuando se habilita Keep-Alive, su tiempo de espera también debe ser ajustarse. El tiempo de espera predeterminado de Keep-Alive para Apache es excesivamente bajo, y debe aumentarse en la mayoría de las configuraciones debido a que pueden surgir incidencias asociadas con la interrupción de las solicitudes AJAX (es decir, hipereventos). Estas incidencias pueden evitarse si se asegura que el tiempo de espera de Keep-Alive en el servidor es mayor que para el cliente.  En otras palabras, el cliente debe cumplir con el tiempo de espera y cerrar la conexión en vez de que lo haga el servidor.  La mayoría de las veces los problemas ocurren (en Internet Explorer más que en otros navegadores), cuando el navegador intenta utilizar una conexión (particularmente para una PUBLICACIÓN) que se supone que estaría abierta. 

Consulta los siguientes valores recomendados de KeepAlive y KeepAliveTimeout para un servidor web HealthShare.

Para habilitar KeepAlive en Apache, realiza los siguientes cambios en httpd.conf:

CSP Gateway

Para el parámetro KeepAlive de CSP Gateway, deja el valor predeterminado de No Action, porque el estado de KeepAlive se determina por los encabezados de respuesta HTTP de cada solicitud.

00
2 0 0 611
Log in or sign up to continue