Capítulo 2 - Infraestructura
Configuración de una infraestructura de almacenamiento en caché
En el capítulo 1 de esta serie presentamos la topología básica de un sistema de publicación y un despachante. Un conjunto de servidores de publicación y Dispatcher se puede configurar en muchas variaciones, según la carga esperada, la topología de los centros de datos y las propiedades de conmutación por error deseadas.
Esbozaremos las topologías más comunes y describiremos las ventajas y dónde se quedan cortas. La lista, por supuesto, nunca puede ser exhaustiva. El único límite es tu imaginación.
La configuración "heredada"
En los primeros tiempos, el número de visitantes potenciales era pequeño, el hardware era caro y los servidores web no se veían tan críticos para el negocio como lo son hoy en día. Una configuración común era tener una Dispatcher que sirviera como equilibrador de carga y caché delante de dos o más sistemas de publicación. El servidor Apache en el núcleo de Dispatcher era muy estable y, en la mayoría de los ajustes, lo suficientemente capaz como para servir una cantidad decente de solicitudes.
Configuración de Dispatcher "heredada" de
Configuración de Dispatcher "heredada" de : no muy común según los estándares actuales
Aquí es desde donde el despachante recibió su nombre: básicamente enviaba solicitudes. Esta configuración ya no es muy común, ya que no puede satisfacer las mayores exigencias de rendimiento y estabilidad requeridas hoy en día.
Configuración de varias piernas
Hoy en día, una topología ligeramente diferente es más común. Una topología de varias patas tendría una Dispatcher por servidor de publicación. Un equilibrador de carga (hardware) específico se encuentra delante de la infraestructura de AEM que envía las solicitudes a estos dos (o más) componentes:
Configuración moderna "estándar" de Dispatcher: fácil de manejar y mantener
Estas son las razones para este tipo de configuración,
-
Los sitios web en promedio sirven mucho más tráfico que en el pasado. Por lo tanto, existe la necesidad de ampliar la "infraestructura Apache".
-
La configuración "Heredada" no proporcionaba redundancia a nivel de Dispatcher. Si el servidor Apache se desactivaba, todo el sitio web estaba inaccesible.
-
Los servidores Apache son baratos. Se basan en código abierto y, dado que tiene un centro de datos virtual, se pueden aprovisionar muy rápido.
-
Esta configuración proporciona una forma sencilla de realizar una actualización "móvil" o "escalonada". Simplemente apague Dispatcher 1 mientras instala un nuevo paquete de software en Publish 1. Cuando finalice la instalación y haya probado suficientemente el humo Publish 1 desde la red interna, limpie la caché de Dispatcher 1 y vuelva a iniciarla mientras elimina Dispatcher 2 para el mantenimiento de Publish 2.
-
La invalidación de la caché se vuelve muy fácil y determinista en esta configuración. Como solo hay un sistema de publicación conectado a un Dispatcher, solo hay que invalidar un Dispatcher. El orden y el momento de la invalidación es trivial.
La configuración "Escalar fuera"
Los servidores Apache son baratos y fáciles de aprovisionar, ¿por qué no aumentar un poco más el escalado? ¿Por qué no tener dos o más Dispatcher delante de cada servidor de publicación?
Configuración de "Escalado horizontal" de
Configuración de "Escalado horizontal" de : tiene algunas áreas de aplicación, pero también limitaciones y advertencias
¡Puedes hacer eso! Y hay muchos escenarios de aplicación válidos para esa configuración. Pero también hay algunas limitaciones y complejidades que debe tener en cuenta.
Invalidación
Cada sistema de publicación está conectado a una multitud de distribuidores, cada uno de los cuales debe invalidarse cuando se cambie el contenido.
Mantenimiento
Huelga decir que la configuración inicial de los sistemas Dispatcher y Publish es un poco más compleja. Pero también tenga en cuenta que el esfuerzo de una versión "móvil" también es un poco mayor. Los sistemas AEM pueden y deben actualizarse mientras se ejecuta. Pero es aconsejable no hacerlo mientras estén atendiendo solicitudes activamente. Por lo general, solo desea actualizar una parte de los sistemas de publicación, mientras que los demás siguen sirviendo tráfico de forma activa y luego, después de probar, cambiar a la otra parte. Si tiene suerte y puede acceder al equilibrador de carga en su proceso de implementación, puede desactivar el enrutamiento a los servidores que se encuentran en mantenimiento aquí. Si está en un equilibrador de carga compartido sin acceso directo, preferiría cerrar los distribuidores de la publicación que desea actualizar. Cuanto más haya, más tendrás que cerrar. Si hay un gran número y planea actualizaciones frecuentes, se recomienda algo de automatización. Si no tiene herramientas de automatización, escalar es una mala idea de todos modos.
En un proyecto anterior utilizábamos un truco diferente para eliminar un sistema de publicación del equilibrio de carga sin tener acceso directo al propio equilibrador de carga.
El equilibrador de carga suele "pings", una página en particular para ver si el servidor está en funcionamiento. Una opción trivial suele ser hacer ping en la página principal. Pero si desea utilizar el ping para indicar al equilibrador de carga que no equilibre el tráfico, debe elegir otra cosa. Usted crea una plantilla o servlet dedicado que se puede configurar para responder con "up" o "down" (en el cuerpo o como código de respuesta http). La respuesta de esa página, por supuesto, no debe almacenarse en caché en Dispatcher; por lo tanto, siempre se obtiene del sistema de publicación. Ahora, si configura el equilibrador de carga para que compruebe esta plantilla o servlet, puede fácilmente dejar que el botón Publicar "pretenda" esté caído. No formaría parte del equilibrio de carga y se puede actualizar.
Distribución mundial
"Distribución mundial" es una configuración de "Escalado horizontal" en la que tiene varios Dispatcher delante de cada sistema de publicación, ahora distribuidos por todo el mundo para estar más cerca del cliente y proporcionar un mejor rendimiento. Por supuesto, en ese escenario no se tiene un equilibrador de carga central sino un esquema de equilibrio de carga basado en DNS y geo-IP.
Escala horizontal
Incluso en un centro de datos local, una topología "Escalar hacia fuera" con varios Dispatcher delante de cada sistema de publicación tiene algunas ventajas. Si ve cuellos de botella de rendimiento en los servidores Apache debido al alto tráfico (y una buena tasa de aciertos de caché) y ya no puede escalar el hardware (agregando CPU, RAM y discos más rápidos), puede mejorar el rendimiento agregando Dispatchers. Esto se denomina "escala horizontal". Sin embargo, esto tiene límites, especialmente cuando se invalida el tráfico con frecuencia. Describiremos el efecto en la siguiente sección.
Límites de la topología de escalado horizontal
La adición de servidores proxy debería aumentar el rendimiento. Sin embargo, hay escenarios en los que añadir servidores puede reducir el rendimiento. ¿Cómo? Considere que tiene un portal de noticias, donde introduce nuevos artículos y páginas cada minuto. Una Dispatcher invalida mediante "invalidación automática": cada vez que se publica una página, todas las páginas de la caché del mismo sitio se invalidan. Esta es una función útil - la cubrimos en Capítulo 1 de esta serie - pero también significa que cuando tiene cambios frecuentes en su sitio web está invalidando la caché con bastante frecuencia. Si solo tiene una instancia de Dispatcher por publicación, el primer visitante que solicita una página almacena en déclencheur una nueva caché de esa página. El segundo visitante ya obtiene la versión en caché.
Si tiene dos instancias de Dispatcher, el segundo visitante tiene una probabilidad del 50 % de que la página no se almacene en caché y, a continuación, experimentaría una latencia mayor cuando se represente esa página. Tener aún más distribuidores por publicación empeora las cosas. Lo que sucede es que el servidor de publicación recibe más carga porque tiene que volver a procesar la página para cada Dispatcher por separado.
Se ha reducido el rendimiento en un escenario de ampliación con vaciados frecuentes de la caché.
Mitigación de problemas de sobreescala
Puede considerar la posibilidad de utilizar un almacenamiento compartido central para todos los Dispatcher o sincronizar los sistemas de archivos de los servidores Apache para mitigar los problemas. Podemos proporcionar solo una experiencia de primera mano limitada, pero estar preparados para que esto sume la complejidad del sistema y pueda introducir una nueva clase de errores.
Hemos realizado algunos experimentos con NFS, pero NFS presenta enormes problemas de rendimiento debido al bloqueo de contenido. De hecho, esto redujo el rendimiento general.
Conclusión: NO se recomienda compartir un sistema de archivos común entre varios distribuidores.
Si tiene problemas de rendimiento, escale las instancias de Publish y Dispatcher de la misma manera para evitar la carga máxima en las instancias de Publisher. No hay una regla de oro sobre la proporción Publicación / Dispatcher: depende en gran medida de la distribución de las solicitudes y la frecuencia de las publicaciones y las invalidaciones de caché.
Si también le preocupa la latencia que experimenta un visitante, considere la posibilidad de usar una red de distribución de contenido, recuperar la caché de forma anticipada, calentar la caché de forma preventiva, establecer un tiempo de gracia tal como se describe en Capítulo 1 de esta serie o consulte algunas ideas avanzadas de Parte 3.
La configuración de "Conexión cruzada"
Otra configuración que hemos visto de vez en cuando es la configuración de "conexión cruzada": las instancias de publicación no tienen instancias de Dispatcher dedicadas, pero todas las instancias de Dispatcher están conectadas a todos los sistemas de publicación.
Topología interconectada: mayor redundancia y complejidad.
A primera vista, esto proporciona algo más de redundancia para un presupuesto relativamente pequeño. Cuando uno de los servidores Apache esté inactivo, aún puede tener dos sistemas de publicación haciendo el trabajo de procesamiento. Además, si uno de los sistemas de publicación se bloquea, aún tiene dos Dispatcher que sirven a la carga en caché.
Sin embargo, esto tiene un precio.
En primer lugar, sacar una pierna para el mantenimiento es bastante engorroso. En realidad, para esto fue diseñado este esquema; para ser más resiliente y mantenerse en marcha por todos los medios posibles. Hemos visto planes de mantenimiento complicados sobre cómo lidiar con esto. Vuelva a configurar primero Dispatcher 2 y elimine la conexión cruzada. Reinicio de Dispatcher 2. Cierre de Dispatcher 1, actualización de Publish 1, … etc. Debe considerar cuidadosamente si eso se escala hasta más de dos patas. Llegarán a la conclusión de que en realidad aumenta la complejidad, los costos y es una fuente formidable de errores humanos. Lo mejor sería automatizar esto. Así que mejor verifíquelo, si realmente tiene los recursos humanos para incluir esta tarea de automatización en la programación de su proyecto. Aunque puede ahorrar algunos costes de hardware con esto, puede gastar el doble en personal de TI.
En segundo lugar, podría tener alguna aplicación de usuario en ejecución en AEM que requiera un inicio de sesión. Las sesiones fijas se utilizan para garantizar que siempre se proporciona a un usuario desde la misma instancia de AEM para que pueda mantener el estado de la sesión en esa instancia. Con esta configuración de conexión cruzada, debe asegurarse de que las sesiones fijas funcionen correctamente en el equilibrador de carga y en los Dispatchers. No es imposible, pero debe tener en cuenta esto y añadir algunas horas de configuración y prueba adicionales, que - de nuevo - podrían nivelar los ahorros que había planeado ahorrando hardware.
Conclusión
No se recomienda utilizar este esquema de conexión cruzada como opción predeterminada. Sin embargo, si decide usarlo, deberá evaluar cuidadosamente los riesgos y los costes ocultos y planificar la inclusión de la automatización de la configuración como parte del proyecto.