Utilizar OpenCms en sitios de alto tráfico
Thu Jun 25 19:15:00 CEST 2009 Technology for Solutions Administración, OpenCms
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 losfactores 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 navegantespueden 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 nocompitan 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 Workplaceno 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 llamadassticky 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.