En esta época en que muchas organizaciones están inmersas en procesos de transformación digital, automatización de procesos, implantación de sistemas de BI, etc. es probable que sus servidores de bases de datos adquieran cada vez más importancia y criticidad dentro del funcionamiento de la organización. Por ello es conveniente pararse a pensar si el plan de recuperación ante desastres que diseñamos hace unos años para proteger nuestros datos, nos sigue resultando válido y óptimo a día de hoy. Por ejemplo, si sólo contamos con backups y copias de seguridad de nuestras bases de datos, debemos preguntarnos si en caso de producirse un fallo en el sistema, nuestra organización a día de hoy puede permitirse o no estar «offline» sin acceso a los datos el tiempo necesario para restablecer el sistema y restaurar las copias de seguridad que podrá ser más o menos dependiendo si ha fallado un disco, el servidor entero o ha habido un incendio en las oficinas.
Si lo que necesitamos es que nuestro sistema se encuentre online cercano a 24×7 y pueda sobreponerse a este tipo de incidentes, tendríamos que plantearnos implantar un sistema de alta disponibilidad en nuestros servidores de datos, las soluciones de alta disponibilidad tienen como finalidad impedir las interrupciones del servicio mediante el mantenimiento de uno o más servidores secundarios de respaldo que entrarían a sustituir al principal en caso de fallo del sistema.
En este punto repasemos las principales soluciones de alta disponibilidad que nos ofrece SQL Server de más básicas a más completas dependiendo de la versión y edición:
- Log Shipping: se trata de la solución más básica, disponible en todas las versiones superiores a Express, implementa un sistema automatizado para mantener uno o varios servidores secundarios con una copia de seguridad restaurándose automáticamente de forma asíncrona cada x minutos, en caso de fallo necesita intervención manual para poner en línea la Base de Datos secundaria.
- Database Mirroring: disponible a partir de la versión Standard, permite configurar una base de datos reflejada a un único servidor secundario, la sincronización de datos puede ser síncrona o asíncrona (sólo Enterprise), puede configurarse con una tercera instancia testigo para que en caso de fallo de la principal cambie automáticamente como activa la del servidor secundario. Esta solución desaparecerá en futuras versiones siendo sustituida por grupos disponibilidad básica Always On.
- Grupos de disponibilidad Always On: la solución más completa, disponible sólo en versión Enterprise en SQL Server 2012 o superior, permite configurar un grupo de bases de datos para estar replicado en hasta 8 servidores secundarios, pueden combinarse replicas síncronas y asíncronas, en caso de fallo soporta failover tanto automático como manual. Otra ventaja importante de esta solución es que es posible definir réplicas activas a las que se pueden dirigir conexiones que vayan a realizar procesos de sólo lectura o copias de seguridad consiguiendo así aprovechar la réplica secundaria para liberar de ciertas cargas de trabajo al servidor principal.
Dentro del modelo de alta disponibilidad que elijamos, es posible también combinarlo con servidores en la nube, teniendo así las réplicas secundarias distribuidas geográficamente dándonos mayor cobertura ante posibles desastres. Por ejemplo, podríamos tener los servidores principales en nuestras oficinas con una primera réplica síncrona en un CPD de nuestra provincia y una segunda réplica asíncrona en la nube de Microsoft Azure, o por el contrario si trabajamos con el servidor principal en Azure podríamos tener una réplica secundaria en local sobre la que continuar trabajando en casos de cortes de comunicaciones, caídas de la nube, etc.
También hay que tener presente como se adapta el software que utilizamos ante estos cambios de servidor de Base de Datos activa, porque si tenemos un sistema de alta disponibilidad y frente a un fallo del sistema el servidor de Base de Datos activo pasa de ser A a ser B, lo ideal es que nuestro ERP pueda ser configurado para ser capaz de detectar el cambio y conectarse al servidor que actúe como principal en cada momento. Por tanto a la hora de adoptar una estrategia de alta disponibilidad será necesario también evaluar las posibilidades que nos da el software que estamos utilizando para ver si es posible configurarlo, va a necesitar adaptarlo o necesitará de intervención manual en caso de producirse un cambio.
En resumen, a la hora de implantar una estrategia de alta disponibilidad, posibilidades y soluciones hay muchas, cada organización deberá estudiar cuáles son sus necesidades concretas y sopesar los costes de uno u otro modelo para elegir la solución más eficiente en su caso.
