En esta entrada expongo mi idea de los conceptos de alta disponibilidad y resiliencia en los sistemas informáticos. Es una entrada más teórica y filosófica que práctica a la que estáis acostumbrados, pero que permite asentar bases a la hora de diseñar y desarrollar sistemas informáticos productivos en cuanto a la tolerancia a fallos del mismo. Sobre todo cuando se habla de los montajes de las diferentes tecnologías: Hyper-V, VMware, SQL Server, Exchange, servidores de ficheros, frontales web, etc … Siempre teniendo en cuenta que la seguridad o disponibilidad al 100% no existe nunca, los castillos más grandes también han caído. Una sistema es seguro o disponible en cuando lo sea su componente más débil.
ALTA DISPONIBILIDAD
La alta disponibilidad es un concepto que indica que un sistema (en este caso informático) estará disponible la mayor parte del tiempo posible. ¿Pero cuánto tiempo es casi siempre posible? Si miramos documentaciones y publicidad empiezan a salir números del tipo:
Guau! ¿Qué pasada no ?, pero no te dejes deslumbrar por estos valores, no dejan de serestrategias de marketing que quedan muy bien sobre el papel. Es correcto ir a buscardispositivos que me ofrecen muchos decimales, se supone que sufriré menos en las paradas. No obstante, que un dispositivo tenga muchos decimales no es sinónimo de quetodo mi sistema tiene todos estos decimales. Al igual que en seguridad, el sistema estarátan disponible como su componente más débil lo permita.
Pongamos un ejemplo, imaginemos que tenemos un único servidor físico que tiene unadisponibilidad del 99,999% (5 minutos de parada anuales). Este servidor estávirtualizando dos servidores, un Active Directory y una base de datos a la que accedenlos usuarios para trabajar. El sistema funciona a la perfección, pero tengo una alta disponibilidad del 99,999%? No rotundo.
Revisando supuestos de la instalación:
•Resulta que el servidor físico dispone de dos fuentes de alimentación que estánconectadas al mismo SAI o, exagerando, en la misma línea de alimentación con un interruptor. ¿Cuántas veces lo habré visto esto?. En que el operario de turno o tú mismo(poner aquí el nombre que desee) involuntariamente ha tocado o se ha enganchado conel enchufe sin querer y ha desconectado el servidor. No serán 5 minutos de parada al año para volver a poner en funcionamiento todo el entorno, ¿verdad? ¿Ya tiene los enchufesdel servidor conectados a dos líneas eléctricas independientes? ¿Los cables estánatados para que no se puedan estirar involuntariamente verdad? ¿Por los dos lados? ¿También tiene protegido el botón de apagar la regleta? … Y ya no digamos qué les puede haber pasado a los dos servidores virtuales que estaban a pleno rendimientocuando se les para de golpe …
• El servidor físico dispone de diferentes componentes que tienen un firmware que loshacen funcionar. Este firmware no está libre de errores y, de vez en cuando, se tiene que actualizar. Algunas actualizaciones requieren reiniciar el servidor. Volvemos…, ¿puedo parar el servidor? Estaré más de 5 minutos para actualizarlo … Los servidoresvirtuales se deberán apagar correctamente,¿cuanto tardan? …
• ¿Y la configuración de almacenamiento? ¿Me permite perder discos sin parar elservidor? Los típicos RAIDs. ¿Puedo cambiar el disco sin tener que parar el servidor? ¿Tengo todas las herramientas a mano para gestionar las reconstrucciones de lossistemas RAID?
• Volviendo al tema de las actualizaciones, pasa lo mismo con el hipervisor, el sistema operativo del servidor de Active Directory y la de base de datos y con el propio motor de base de datos … ¿Están contempladas ?, ¿cuánto tiempo de parada me supone? …
•Y no digamos de la red. ¿Cuántas conexiones de red tiene el servidor? ¿Al mismoconmutador (switch)? Que sólo tiene una fuente de alimentación? ¿que está conectado a la regleta … que se apaga el conmutador y ya no se puede llegar al servidor? En este caso, el servidor sigue funcionando, pero no está disponible para los usuarios. Para elloses como si estuviera parado. ¿Se ha contemplado disponer de conexiones de redredundadas? ¿En un mismo conmutador? ¿Con un nivel de disponibilidad del 99,999% o del 80%? …
• ¿Y la seguridad? ¿Los servicios están protegidos correctamente de posibles ataques externos que los tiren al suelo? T¿enemos un buen diseño de la red? ¿Controlamos losaccesos internos y externos al sistema? …
• La más “chula”,¿ el servidor está ubicado en un lugar adecuado y protegido? No estará por debajo los tubos del desagüe, ¿verdad? ¿Ni por debajo del aparato de aire acondicionado que puede condensar agua? Es accesible para cualquier persona, sobre una estantería cualquiera, bien ventilado, …
• Y si… poned todo lo que os pase por la cabeza, porqué puede pasar.
• etc…
Son algunos ejemplos de preguntas que debes hacer cuando se diseña un sistema de alta disponibilidad.
Naturalmente, la alta disponibilidad NO es igual para todos ni para todos los servicios. Algunos sistemas deben estar disponibles las 24 horas del día, los 7 días de la semana y los 365 días al año. Otros, pueden estar 8 horas al día (de 8 a 14 y de 15 a 18) de lunes a viernes. También puede ser que la base de datos tenga que estar disponible las 24x7x365, mientras que el sistema de archivos sólo lo requiere en horario laboral y el entorno de conexiones remotas fuera del horario laboral. Son las pequeñas ventanas de trabajo en que se pueden llevar a cabo las tareas de mantenimiento de los mismos. En caso de que el servicio no pueda disponer de esta ventana de tiempo para las tareas de mantenimiento, es cuando hablamos de redundar el servicio. Es decir, que dos máquinas hagan exactamente lo mismo, para poder pasar el servicio de una a la otra sin afectar o afectando al mínimo los usuarios. Así, se pueden realizar tranquilamente las tareas de mantenimiento en la máquina liberada. Una vez terminadas, se vuelve a poner el servicio en activo en ambas o en la que corresponda. Por ejemplo:
• El Active Directory es un servicio crítico para mantener la seguridad y el funcionamiento de los servicios de la red. Para un entorno con un grado de alta disponibilidad elevado es un servicio que deberán efectuar dos o más servidores. El diseño del servicio ya lo permite hacer. Cuando los dos servidores funcionan, lo hacen de forma activa los dos. En caso de caída o parada de uno de los servidores del otro asume toda la carga.
• El servicio de bases de datos Microsoft SQL Server permite el montaje con la base de datos redundada en dos servidores. Uno de los servidores tiene una copia de la base de datos de forma activa (recibe las peticiones de los usuarios). Mientras el otro servidor tiene otra copia (me protejo de la corrupción del almacenamiento de datos) de forma pasiva. De esta forma puedo pasar la base de datos activa de un servidor a otro sin afectar a los usuarios.
• Los frontales de aplicaciones web permiten crear granjas de servidores en que si uno de los servidores cae, el tráfico se deriva hacia los otros que están vivos.
• El servicio de correo electrónico Microsoft Exchange permite disponer de las bases de datos redundadas y los servidores de acceso balanceados en granjas. Es como una combinación del método de la base de datos y los frontales de aplicaciones.
• También tengo los famosos clústers de toda la vida. El servicio, normalmente, se controla por dos servidores, uno lo tiene de forma activa y el otro de forma pasiva. Similar en el caso del SQL Server a excepción que requiere de un almacenamiento compartido entre los servidores y donde sólo hay una copia de los datos. En este caso no me estoy protegiendo ante una corrupción o fallo de las mismas. Actualmente sigue siendo bastante habitual en los entornos de servidores de virtualización y ficheros.
• etc …
Se debe analizar cada servicio según las necesidades del mismo y el que se quieraofrecer, para terminar aplicando la estrategia más ventajosa. Sin embargo, a mí no me gusta hablar de alta disponibilidad, sino más bien de RESILIENCIA.
RESILIENCIA
La resiliencia es la capacidad que tiene un sistema de recuperarse ante un imprevisto. Mientras que la alta disponibilidad asegura el funcionamiento, la resiliencia es la capacidad de recuperar el servicio ante un imprevisto. Un ejemplo. Dispongo de dos servidores físicos de virtualización trabajando en clúster. Uno de los dos cae inesperadamente. Los servidores virtuales que tenía el servidor que cae, naturalmente, se detienen de golpe. El segundo servidor se da cuenta, coge los servidores virtuales y los vuelve a poner en marcha encima de él. El sistema no ha estado disponible durante un periodo de tiempo, pero ha sido resiliente al recuperar rápidamente el servicio que estaba ofreciendo. Mientras que el servidor con alta disponibilidad del 99,999%, etc … continúa parado, el diseño global del sistema ha permitido la recuperación del servicio. No obstante, hay que reparar el servidor que ha fallado para volver al estado inicial. Continuando con el ejemplo, una alta disponibilidad, se produciría en caso de que fallara una fuente de alimentación de uno de los servidores físicos. La fuente de alimentación dejaría de funcionar, pero el servidor continuaría operativo sin una pérdida del servicio, con la segunda fuente de alimentación. En este caso, no se produciría ningún corte en el servicio como ha ocurrido en el caso anterior.
CENTRO DE CONTINGENCIA
El centro de contingencia nos sirve en caso de un desastre total donde tenemos los servidores con los datos y servicios. Vamos, que lo hemos perdido todo: inundación, incendio, robo, derrumbes, etc … Me he quedado con una mano delante y otra detrás. Se trata de recuperar el servicio lo antes y de la mejor forma posible, ser resiliente ante este tipo de incidente. El centro de contingencia puede estar dentro de la propia empresa, en edificios prudencialmente separados, o disponer de un entorno de cloud público donde enviar una réplica de los datos. Normalmente, los centros de contingencia dentro de la propia empresa me permitirán una recuperación rápida con un menor tiempo de pérdida datos (la última réplica de datos). Mientras que los centros de contingencia públicos el tiempo de pérdida de datos será más elevado debido a los anchos de banda disponibles y la cantidad de información que se mueve. Pensad que en el centro de contingencia tengo los datos y servicios, pero ¿y los usuarios? ¿Habéis contemplado cómo los usuarios podrán acceder a estos datos? ¿Tendré usuarios? ¿Tendrán dispositivos para conectarse? Al final vuelve a ser una balanza donde todo dependerá del dinero que nos gastamos y lo que pasa si dejo de estar disponible. Cada caso es un mundo y aplicar el sentido común no está de más.