Alta disponibilidad

31 marzo 2015
Opinión
Josep Ma Solanes 0
| |

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 desplegar 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 archivos, 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. Un sistema es seguro o disponible en tanto 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 cuanto tiempo es la mayoría del tiempo posible? Si miramos documentaciones y publicidad comienzan a salir números del tipo:

Disponibilidad Minutos anuales Minutos mensuales
99,9% 518 (8,6 horas) 43
99,99% 52 4
99,999% 5 0,4

¡Guau! ¿que pasada no?, pero no os dejéis iluminar por estos valores, no dejan de ser estrategias de marketing que quedan muy bien sobre el papel.

Es correcto ir a buscar dispositivos que me ofrecen muchos decimales, se supone que sufriré menos en las paradas. Sin embargo, que un dispositivo tenga muchos decimales no es sinónimo que todo 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 una disponibilidad 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 acceden los 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án conectadas al mismo SAI o, exagerando, en la misma regleta de enchufes con un interruptor. Cuantas veces lo habré visto esto. En que el operario de turno o vosotros mismos (poner aquí el nombre que queráis) involuntariamente ha tocado o se ha enganchado con el 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 tenéis los enchufes del servidor conectados a dos líneas eléctricas independientes? ¿Los cables estan atados para que no se puedan estirar involuntariamente verdad? ¿Por los dos lados? ¿También tenéis protegido el botón de apagar la regleta? etc… Y no digamos que les puede haber pasado a los dos servidores virtuales que estaban en pleno rendimiento cuando se les para de golpe…

 

  • El servidor físico dispone de diferentes componentes que tienen un firmware que los hace funcionar. Este firmware no está libre de errores y, de vez en cuando, se debe actualizar. Algunas actualizaciones requieren de reiniciar el servidor. Vuelta a empezar, ¿puedo parar el servidor? Estaré más de 5 minutos para actualizarlo… Los servidores virtuales se tendrán que apagar correctamente, ¿cuanto tardan?, etc…

 

  • ¿Y la configuración de almacenamiento? ¿Me permite perder discos sin parar el servidor? 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 los sistemas RAID?

 

  • Volviendo al tema de las actualizaciones, pasa lo mismo con el hipervisor, el sistema operativo del servidor de Active Directory y el de base de datos y con el propio motor de base de datos… ¿Están contempladas?, ¿cuanto tiempo de parada me supone? etc…

 

  • Y no hablemos de la red. ¿Cuántas conexiones de red tiene el servidor? ¿En el mismo conmutador (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 acceder al servidor? En este caso, el servidor sigue funcionando, pero no está disponible para los usuarios. Para ellos es como si estuviera parado. ¿Se ha contemplado disponer de conexiones de red redundadas? ¿En un mismo conmutador? ¿Con un nivel de disponibilidad del 99,999% o del 80%? etc…

 

  • ¿Y la seguridad? ¿Los servicios están protegidos correctamente de posibles ataques externos que los tiren al suelo? ¿Tenemos un buen diseño de la red? ¿Controlamos los accesos internos y externos al sistema? etc…

 

  • La más «chula», ¿el servidor está ubicado en un lugar adecuado y protegido? ¿No estará bajo los tubos del desagüe, verdad? ¿Ni bajo el aparato de aire acondicionado que puede condensar agua? Es accesible para cualquier persona, encima de una estantería cualquiera, bien ventilado, etc…

 

  • Y si… poned lo que os pase por la cabeza, porque puede pasar.

 

  • etc…

Son algunos ejemplos de preguntas que os tenéis que 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 tienen que estar disponibles las 24 horas del día, los 7 días de la semana y los 365 días del 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 el caso 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 otra sin afectar o afectando al mínimo a 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 las dos 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 tendrán que efectuar dos o más servidores. Por diseño el servicio ya lo permite hacer. Cuando los dos servidores funcionan, lo hacen de manera activa los dos. En caso de caída o parada de uno de los servidores el 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 manera activa (recibe las peticiones de los usuarios). Mientras el otro servidor tiene otra copia (me resguardo de la corrupción del almacenamiento de datos) de manera pasiva. De esta manera 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 que la forman 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ústeres de toda la vida. En que el servicio, normalmente, se controla por dos servidores, uno lo tiene de manera activa y el otro de manera pasiva. Parecido 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 un fallo de los mismos. Actualmente sigue siendo bastante habitual en los entornos de servidores de virtualización y archivos.

 

  • etc…

Se tiene que analizar cada servicio según las necesidades del mismo y lo que se quiera ofrecer, para terminar aplicando la estrategia más ventajosa.

Sin embargo, a mi 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 frente a un imprevisto.

Mientras que la alta disponibilidad asegura el funcionamiento, la resiliencia es la capacidad de recuperar el servicio frente a 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 paran de golpe. El segundo servidor se da cuenta, coge los servidores virtuales y los vuelve a arrancar sobre él. El sistema no ha estado disponible durante un período de tiempo, pero ha estado resiliente al recuperar rápidamente el servicio que estaba ofreciendo. Mientras que el servidor con alta disponibilidad del 99,999%, etc… sigue parado, el diseño global del sistema ha permitido la recuperación del servicio. Sin embargo, hay que reparar el servidor que ha fallado para volver al estado inicial.

Siguiendo con el ejemplo, una alta disponibilidad, se produciría en el caso que fallase una fuente de alimentación de uno de los servidores físicos. La fuente de alimentación dejaría de funcionar, pero el servidor seguirí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 pasado 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. Vaya, 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 más pronto y de la mejor manera posible, ser resiliente frente a 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 de 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.

Pensar que en el centro de contingencia tengo los datos y servicios, pero ¿y los usuarios? ¿Habéis contemplado como 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 dejemos ahí y de lo que pasa si dejo de estar disponible. Cada caso es un mundo y aplicar el sentido común no está de más.

¿Te ha gustado el artículo? Lo puedes compartir en las redes sociales. También puedes dejar tu opinión, comentario o sugerencia. ¡Gracias!

Similar Posts by The Author: