Creación de servicios de datos resistentes
La organización tiene varias cargas de trabajo distribuidas entre diferentes entornos. Todas las cargas de trabajo dependen de datos que se mantienen seguros y del modo oportuno. Existen diversas medidas que se pueden tomar para generar resistencia en los datos.
En esta unidad, vemos cómo Grupos de disponibilidad Always On ayuda a replicar los datos. Vemos cómo las copias de seguridad automatizadas y la conmutación por error automática en Azure SQL Database contribuyen a mantener los datos seguros. También aprende a usar la característica de replicación geográfica de Azure Cosmos DB para replicar datos de forma transparente en otras regiones y hacer que estén accesibles para su lectura y escritura.
Replicación de bases de datos con Grupos de disponibilidad Always On
Grupos de disponibilidad Always On ayuda a lograr alta disponibilidad en las bases de datos de SQL Server que se ejecutan en máquinas virtuales.
Puede almacenar los grupos que se especifiquen de las bases de datos en réplicas de disponibilidad:
- La réplica principal contiene las bases de datos principales,
- mientras que la réplica secundaria contiene las copias secundarias sincronizadas de esas bases de datos principales.
Si se produce un error, la réplica secundaria es un destino de la conmutación por error. La réplica principal permite acciones de lectura y escritura. Los datos se sincronizan entre cada base de datos principal y cada base de datos secundaria asociada correspondiente.
Las réplicas secundarias también se pueden configurar para ser legibles; De esta manera, los clientes pueden acceder a los datos de varias bases de datos, y una mayor demanda se puede distribuir entre varias réplicas.
Grupos de disponibilidad Always On se ejecuta en un clúster de conmutación por error de Windows Server que consta de un grupo de máquinas que trabajan a la vez. Esta arquitectura proporciona alta disponibilidad en las cargas de trabajo que se ejecutan en esas máquinas. Con Grupos de disponibilidad Always On, cada nodo (máquina) del clúster hospeda una réplica, ya sea principal o secundaria. Cada réplica contiene un grupo de bases de datos.
Puede configurar Grupos de disponibilidad AlwaysOn en Azure mediante la creación de dos conjuntos de disponibilidad: uno para nodos de clúster de conmutación por error de Windows Server y otro para controladores de dominio.
El clúster de conmutación por error de Windows Server debe contener al menos tres máquinas. En el clúster, debe haber una máquina de SQL Server para la réplica principal y otra para la réplica secundaria. Un tercer servidor debe actuar como testigo del recurso compartido de archivos, pero también tiene la posibilidad de utilizar un recurso compartido de archivos de Azure como testigo.
Conmutación por error de bases de datos de Azure SQL Database
Se pueden usar grupos de conmutación por error automática de SQL Database para configurar la conmutación por error y la replicación de grupos de bases de datos en un servidor de SQL Database. Hay que elaborar las directivas definidas que permitan realizar conmutaciones por error en función de sus necesidades. Si es necesario, también se pueden desencadenar conmutaciones por error manualmente. Cuando se produce un error, SQL Database puede conmutar por error automáticamente las bases de datos en un servidor secundario ubicado en una región secundaria.
Las bases de datos secundarias de conmutación por error automática de SQL Database se pueden usar como bases de datos legibles. Puede usar estas bases de datos secundarias para atender el acceso de lectura a los datos de los clientes que conectan y propagan el uso y la demanda entre las bases de datos principales y secundarias.
Si usa directivas de conmutación por error automáticas y se produce un error en al menos una base de datos del grupo de bases de datos principal, se desencadena una conmutación automática por error en las bases de datos secundarias. Los puntos de conexión siguen siendo los mismos durante la conmutación por error. Cuando el problema que ha causado el error esté solucionado y todo esté en orden, se puede conmutar por recuperación a la ubicación original. Puede conmutar por error los grupos a su ubicación original manualmente.
Las bases de datos de un servidor de base de datos se pueden incluir en un solo grupo de conmutación por error automática. También se podrían poner todas las bases de datos de un grupo elástico en un solo grupo de conmutación por error. Cuando las bases de datos principales forman parte de un grupo elástico, las bases de datos secundarias también se aprovisionan en un grupo elástico. Este grupo secundario tiene el mismo nombre que el grupo elástico principal.
Copia de seguridad automatizada de Azure SQL Database
Azure SQL Database puede hacer copias de seguridad de las bases de datos almacenadas entre 7 y 35 días. SQL Database usa el almacenamiento con redundancia geográfica para almacenar copias de seguridad y proporcionar acceso de lectura a los datos en otra región. Las bases de datos están seguras, incluso si hay problemas en un centro de datos.
Puede ampliar la retención de copia de seguridad durante hasta 10 años estableciendo directivas de retención a largo plazo en bases de datos únicas o grupos elásticos. Todas las copias de seguridad de las bases de datos de SQL Database se cifran en reposo. Todas las bases de datos SQL que cree tienen el cifrado de datos transparente habilitado de manera predeterminada.
SQL Database hace copias de seguridad automáticamente en segundo plano. Crea copias de seguridad de las bases de datos en diferentes intervalos, en función del tipo de copia de seguridad. Por ejemplo, crea los siguientes tipos de copia de seguridad:
- Copias de seguridad de los registros de transacciones en un intervalo de 5 a 10 minutos.
- Copias de seguridad completas de las bases de datos cada semana. La primera copia de seguridad completa se realiza en cuanto se crea la base de datos. El tiempo necesario para realizar una copia de seguridad completa de SQL Database depende del tamaño de la base de datos.
- Copias de seguridad diferenciales cada 12 horas para cualquier dato que haya cambiado desde la última copia de seguridad completa.
SQL Database mantiene copias de seguridad en blobs de almacenamiento que proporcionan acceso de lectura. A continuación, copia esas copias de seguridad en un centro de datos emparejado.
Las bases de datos pueden restaurarse a una versión de la que se haya hecho copia de seguridad. Si ha configurado la retención a largo plazo, esta copia de seguridad podría estar disponible hasta 10 años. Las bases de datos eliminadas se pueden restaurar hasta el momento de su eliminación y hasta el límite de retención establecido en la directiva de retención.
SQL Database puede restaurar bases de datos en una región geográfica diferente. Este proceso se realiza a través de la restauración geográfica, que permite recuperar bases de datos de una región en otra en caso de que se produzca algún problema en una región completa.
Replicación geográfica con Azure Cosmos DB
Azure Cosmos DB es un servicio de base de datos de varios modelos y baja latencia que permite distribuir datos de forma global, sencilla, elástica y rápida.
En Azure Cosmos DB, todos los datos se replican de forma transparente en las regiones que se hayan establecido en la cuenta de Azure Cosmos DB. Azure Cosmos DB guarda los datos en contenedores que componen la base de datos, y se crean particiones en todos esos contenedores.
Todas las particiones se replican en cada región. Dentro de cada región, las particiones se copian antes de que cada copia se distribuya entre distintos dominios de error.
Los datos se replican al menos cuatro veces. Puede configurar una cuenta de Azure Cosmos DB y configurar la base de datos de Azure Cosmos DB para que se distribuya en cinco regiones. Si configura esta base de datos en cinco regiones, Azure Cosmos DB garantiza que haya al menos 4x5 copias de todos los datos.
Conviene configurar la base de datos de Azure Cosmos DB para que se extienda al menos en dos regiones. Cuantas más regiones haya, más resistentes serán los datos. También debe establecer explícitamente la base de datos de Azure Cosmos DB para que tenga varias regiones de escritura, de modo que pueda realizar operaciones de lectura y escritura desde todas las regiones.
También puede configurar la redundancia de zona en algunas regiones. Con la redundancia de zona, Azure Cosmos DB coloca réplicas de datos en varias zonas de disponibilidad en cualquier región única para una resistencia adicional.