Veamos un ejemplo algo diferente al anterior. En el anterior estábamos valorando la virtualización y la alta disponibilidad de forma local en un CPD corporativo por ejemplo. En este caso vamos a comentar un caso algo mas particular de base dedatos en alta disponibilidad pero en la nube de Microsoft: Azure.
Azure SQL Database es una base de datos relacional pero constituida como un servicio en la nube. Utiliza una versión especial de Microsoft SQL Server como su backend que es casi idéntico a SQL Server. Aunque el uso de bases de datos SQL sobre SQL Server ofrece muchas ventajas, vamos a comentar los diversos tipos de opciones de alta disponibilidad y recuperación ante desastres que son mucho más fáciles de configurar que SQL Server.
Cuando se utiliza el portal Azure para crear una base de datos SQL existen distintos planes con diferentes precios que incluyen tres niveles de servicio: Básico, Estándar y Premium. Veamos sus características con sus opciones de alta disponibilidad y recuperación de desastres:
- Básico: Copias de seguridad automáticas, restauración puntual hasta 7 días, recuperación de desastres: Geo-restauración, restauración en cualquier región de Azure.
- Estándar: Copias de seguridad automáticas, restauración puntual hasta 14 días, recuperación de desastres: Geo-replicación estándar, secundario fuera de línea.
- Premium: Copias de seguridad automáticas, restauración puntual hasta 35 días, recuperación de desastres: Geo-replicación activa, hasta 4 copias de seguridad secundarias en línea.
En cuanto a la alta disponibilidad cada base de datos posee una base de datos primaria y dos réplicas locales almacenadas en LRS Azure Blob Storage que residen en el mismo centro de datos, lo que proporciona una alta disponibilidad dentro de ese centro de datos. Al menos dos de esas bases de datos están sincronizadas. El hardware en el que residen estas bases de datos se encuentra en subsistemas completamente separados físicamente. Así que si el hardware falla, su base de datos fallará automáticamente y sin problemas a la copia sincrónica.
Todas las bases de datos básicas, estándar y premium están protegidas por copias de seguridad automáticas. Se realizan copias de seguridad completas cada semana, copias de seguridad diferenciales cada día y copias de seguridad de registro cada 5 minutos. La primera copia de seguridad completa se programa inmediatamente después de crear una base de datos. Normalmente esto se completa en 30 minutos, pero puede tomar más tiempo. Si una base de datos se crea grande, por ejemplo, si se crea como resultado de la copia o restauración de una base de datos grande, entonces la primera copia de seguridad completa puede tardar más tiempo en completarse. Después de la primera copia de seguridad completa, todas las demás copias de seguridad se programan automáticamente y se gestionan de forma silenciosa en segundo plano. La sincronización exacta de las copias de seguridad completas y diferenciales es determinada por el sistema para equilibrar la carga total. Los archivos de copia de seguridad se almacenan localmente en almacenamiento en masa en el mismo centro de datos que las bases de datos con redundancia local. Cuando se restaura una base de datos, se recuperan y aplican los archivos de copia de seguridad necesarios. Las copias de seguridad completas, diferenciales y de registro también se copian en el almacenamiento de notas en la región secundaria emparejada en la misma área geo-política con fines de recuperación ante desastres. Estas copias geo-redundantes se utilizan para permitir la geo-restauración como se explica a continuación.
Point In Time Restore está diseñado para devolver la base de datos a un punto anterior en el tiempo. Utiliza las copias de seguridad de la base de datos, las copias de seguridad incrementales y las copias de seguridad del registro de transacciones que el servicio mantiene automáticamente para cada base de datos del usuario. Cuando se realice una restauración, obtendrá una nueva base de datos en el mismo servidor.
Geo-restauración: Al crear un servidor de base de datos SQL, se elige la región en la que desea que se encuentre, por ejemplo en los Estados Unidos, y ésta es su región principal. Si hay un incidente en esta región y una base de datos no está disponible, se puede restaurar desde la copia de seguridad geo-redundante en la región secundaria a cualquier región, utilizando la misma tecnología que la restauración puntual y, por lo tanto, las bases de datos son resistentes a las interrupciones de almacenamiento en la región primaria. Hay que tener en cuenta que con esta opción, los datos podrían estar atrasados hasta una hora.
Geo-replicación estándar: Aquí es donde una copia de los datos en la base de datos primaria está siendo constantemente escrita asincrónicamente a una base de datos secundaria no legible en un servidor en una región diferente. En el caso de un desastre puesto que la copia es asincrónica, los datos de la base de datos secundaria estarán detrás de la primaria, pero no más de cinco segundos.
Geo-replicación activa: Similar a la geo-replicación estándar, los datos están siendo escritos asincrónicamente excepto que están en un máximo de cuatro servidores secundarios en diferentes regiones, y estos secundarios son legibles, es decir, cada copia continua es referida como una base de datos secundaria en línea. También puede saltar a un secundario en caso de desastre de la misma manera que la geo-replicación estándar. Además, la geo-replicación activa puede utilizarse para soportar escenarios de actualización o reubicación de aplicaciones.
CONCLUSIONES
Como puede verse en esta breve descripción de las características de alta disponibilidad y recuperación ante desastre que ofrece SQL Server en Azure, podemos jugar con factores de geo-localización, geo-replicación y geo-restauración que mejoran totalmente el servicio y la disponibilidad de una base de datos hacia una organización.
No solo damos una alta disponibilidad, sino que además ante una restauración o recuperación total estamos totalmente cubiertos.
Es un escenario que difiere mucho de las prestaciones que ofrece un CPD centralizado o replicado por sedes corporativas. Evitamos la inversión en infraestructura y en servicios y aplicaciones de copias de seguridad y restauración. Eso si, hay que analizar correctamente si queremos dotar a nuestro sistema de una alta disponibilidad de forma local en nuestra organización o en la nube dependiendo del servicio que ofrece un tercero como Microsoft.
Una opción muy utilizada a nivel empresarial son entornos híbridos que combinan diferentes soluciones de alta disponibilidad, infraestructura, recuperación ante desastres, etc.
Si nos inclinamos por la modalidad tradicional o también llamada On Premise, ubicaremos las aplicaciones en los servidores que ya poseemos, es decir, en una infraestructura o recursos ya asentados en un CPD propio.
Por el contrario, el formato SaaS implica establecer las aplicaciones en la nube. Nos olvidaremos por tanto del mantenimiento de la infraestructura y posibles perdidas de información por problemas en nuestras instalaciones.
Cuando nos decidimos por una solución On Premise, estaremos adquiriendo las licencias necesarias para instalar el software en los propios servidores, sin que intervengan proveedores externos del servicio.
El modelo SaaS está ganando cada vez mas adeptos debido a que no se realiza una gran inversión al implementarlo en un principio, sin embargo, el sistema On Premise engloba otras ventajas que sin duda, compensan la inversión inicial, no existirá dependencia de terceros.
LINKS CONSULTADOS
https://es.wikipedia.org/wiki/Hyper-V
https://technet.microsoft.com/es-es/library/mt697594(v=exchg.160).aspx
https://technet.microsoft.com/es-es/library/dn632408.aspx
https://technet.microsoft.com/es-es/library/bb510695(v=sql.105).aspx
https://docs.microsoft.com/es-es/sql/sql-server/failover-clusters/high-availability-solutions-sql-server
https://docs.microsoft.com/es-es/azure/sql-database/sql-database-high-availability
https://www.microsoft.com/es-es/cloud-platform/server-virtualization
SaluDOS
No hay comentarios:
Publicar un comentario