El presente artículo busca presentar a administradores y usuarios una serie de consideraciones a tener en cuenta al momento de utilizar OpenCMS en sitios de alto tráfico.
Este artículo aplica a situaciones donde la instalación de OpenCMS utiliza las extensiones corporativas de Alkacon OCEE con el módulo de Cluster activo con al menos 2 nodos.
1. Arquitectura
OpenCMS nos permite elegir entre diferentes arquitecturas posibles:
1. OCEE Módulo Cluster con base de datos única para Workplace y nodos
2. OCEE Módulo Cluster con base de datos local en cada nodo
3. OCEE Módulo Cluster + OCEE Replicator
4. OCEE Módulo de Cluster con 1 base de datos dedicada para Workplace y 1 base de datos dedicada para nodos (replicación MySQL)
La elección de la arquitectura es sin lugar a dudas uno de los factores de éxito clave. En otro artículo especialmente dedicado a este tema, detallaremos los pros y contras de cada escenario.
2. Modalidad para servir contenido
La forma mediante la cual OpenCMS entrega el contenido a los navegantes define una serie de factores a revisar según el escenario. En el artículo Opencms: Servidor contenido de forma estática, dinámica o mixta exploramos este tema.
3. Conectividad del Workplace
En situaciones de alto tráfico, los accesos de los navegantes pueden saturar los enlaces. Por tal motivo, es muy importante contar con un acceso dedicado al Workplace que nos permita tener acceso a las herramientas de administración.
Es altamente recomendable que los usuarios del sistema no compitan por el ancho de banda con los navegantes y que el Workplace no esté sirviendo páginas a navegantes.
Desde el punto de vista de seguridad, es ideal que el Workplace no se encuentre publicado en Internet.
4. Balanceo de Carga
Los módulos de OpenCMS poseen requerimientos especiales respecto del balanceo de carga. Es importante que el balanceador utilice sesiones persistentes (también llamadas sticky sessions). De esta forma, cuando un usuario está navegando el sitio, quedará asociado a un nodo en particular por el lapso de su sesión.
De otra forma, si un usuario recibiese páginas de diferentes miembros del cluster, todos aquellos módulos que hacen uso del ingreso (login) del usuario pueden funcionar de forma anormal.
5. Frecuencia de Publicación
La publicación continua del contenido es el peor enemigo del alto tráfico. Cada vez que un usuario publica un nuevo contenido, los sistemas de cache deben regenerarse total o parcialmente, con la consecuente perdida de performance.
Cuando un sistema de administración de contenidos recibe publicaciones continuas, la efectividad de estos sistemas se reduce drásticamente. Esto aplica a cualquier publicación, ya sea modificación de contenidos existentes o la incorporación de nuevos contenidos al proyecto online.
Como buena práctica, es recomendable publicar contenidos a intervalos de 5 minutos o más.
6. Prepararse para la crisis
Existen 2 cuestiones esenciales que nos van a permitir administrar correctamente una crisis de tráfico:
TEMPLATES DE EMERGENCIA: tener un juego de templates alternativos para las páginas más visitadas que sean muy livianos. Es importante que estos templates sean lo más simple posibles, quitando todos los elementos gráficos que no sean indispensables.
DESHABILITAR FUNCIONALIDAD DINÁMICA: ingresos de usuarios registrados, encuestas, búsquedas, valoración, comentarios y otras funcionalidades dinámicas implican un esfuerzo extra.
Durante una situación de crisis, un posible camino de acción es deshabilitar estos servicios para reducir la cantidad de elementos a regenerarse en el cache y evitar la mayor cantidad posible de consultas a la base de datos.
7. Monitoreo Continuo
El último punto, y no menos importante que los anteriores, es conocer su infraestructura. Tener mecanismos de monitoreo activo de servicios, enlaces y servidores como NAGIOS va a permitir detectar fallas de forma temprana y corregirlas sin mayores dificultades para los navegantes.
Por otro lado, tener estadísticas de utilización de los recursos (procesador, memoria, acceso a discos, tráfico de red) como lo ofrecido por MUNIN nos va a permitir identificar rápidamente las posibles fuentes del problema.
June 1st, 2009 - 5:39 pm
Una pregunta, comentais el hecho de desactivar elementos dinámicos en momentos de alto tráfico, esta solución parace lógica, pero, como se hace esto realmente?? que es lo que hacéis exactamente??
Podéis comentar un poco mejor el sistema de monitorización como funciona concretamente?
Y sobre la frecuencia de publicación, que aconsejais? hacer una publicación de muchos contenidos editados en lugar de ir publicando conforme se vayan editando?
Un saludo.
June 1st, 2009 - 5:54 pm
Hola Sergio! Te contesto punto por punto.
1) Respecto de deshabilitar la funcionalidad dinámica:
Cuando un TEMPLATE está bien construido, va a estar conformado por diferentes ELEMENTOS (JSP que los componen). Una forma fácil de remover funcionalidad dinámica es quitando la llamado del template principal a esos elementos. Esto aplica por ejemplo al BUSCADOR y a las ENCUESTAS.
En muchos módulos, como en el caso de COMENTARIOS o VALORACIÓN basta con cambiar en caliente un parámetro de configuración y forzar un reload de la configuración de Opencms para que el módulo se deshabilite.
2) Con relación al MONITOREO ACTIVO nosotros usamos mucho NAGIOS y MUNIN. Te dejo algunos links: http://www.tfsla.com/soluciones_monitoreo.php
http://www.nagios.org
http://munin.ping.uio.no/ping.uio.no/comparison-week.html
El NAGIOS se utiliza principalmente para ALERTAS TEMPRANAS sobre falla de servicios, enlaces o servidores. Desde lo más simple que es monitorear haciendo PING a los equipos hasta implementaciones complejas con PLUG-INs que te permiten consultar valores de aplicativos como el estado de la REPLICACION DE MYSQL o el LOAD AVERAGE de los servidores.
Por su parte, el MUNIN grafica diferentes indicadores y guarda información histórica (diaria, semanal, mensual). Te paso un URL donde podés ver un ejemplo:
http://munin.ping.uio.no/ping.uio.no/bimbo.ping.uio.no.html
Con esto, uno puede comparar períodos y ver como responde la infraestructura a cambios.
3) Finalmente respecto a la frecuencia de publicación, en tanto se respeten los tiempos mínimos de publicación, de igual hacerlo de forma individual o grupal. La clave es dejar FUNCIONAR a la Flexcache por el mayor tiempo posible.
En DIARIOS Y REVISTAS nosotros ofrecemos una PLANILLA DE ADMINISTRACIÓN que permite seleccionar N recursos y lanzar una publicación grupal. También es posible programar publicación diferida. De esta forma, se puede remover el derecho de PUBLICACIÓN DIRECTA a los usuarios y darle el control a un ROL dentro de la organización que sea el PUBLICADOR.