Recuperación ante desastres para servicios PaaS

La recuperación ante desastres de los servicios IaaS (VM) suele implicar Azure Site Recovery para replicar todo el sistema operativo y los discos de datos en una región secundaria. Los servicios PaaS tienen modelos de DR diferentes porque Microsoft administra la infraestructura subyacente. En PaaS, la DR suele configurarse en la capa de datos: los datos se replican en una región secundaria mientras la propia plataforma se inicia automáticamente.

Azure SQL Database proporciona alta disponibilidad integrada a nivel de zona dentro de una sola región. Para la DR entre regiones, ofrece dos funcionalidades clave: geo-replicación activa (bases de datos secundarias legibles en hasta otras cuatro regiones) y grupos de conmutación por error automática (conmutación por error automatizada con un único punto de conexión de escucha). Estas funcionalidades se configuran en el nivel de base de datos o de servidor, sin necesidad de Azure Site Recovery.

Los grupos de conmutación por error automática añaden automatización y un único punto de conexión de conexión sobre la geo-replicación. Configure un grupo en el servidor principal, agregue el servidor secundario y defina un período de gracia: el tiempo que Azure espera a que se recupere el servidor principal antes de activar la conmutación por error automática. Las aplicaciones se conectan al punto de conexión de escucha (por ejemplo, mygroup.database.windows.net) y se redirigen automáticamente después de la conmutación por error sin cambiar las cadenas de conexión.

La geo-replicación de Azure SQL Database es asíncrona: las transacciones se confirman en el servidor principal y después se replican en el secundario. Esto implica un pequeño retraso de replicación, normalmente inferior a 5 segundos en condiciones normales. Por tanto, el RPO de la geo-replicación de SQL es aproximadamente de 5 segundos en la mayoría de los escenarios, lo que la hace adecuada para cargas de trabajo de nivel 1 y nivel 2 que requieren una pérdida de datos muy reducida.

Todos los niveles de Azure SQL Database incluyen copias de seguridad automatizadas: copias completas semanales, copias diferenciales cada 12 horas y copias del registro de transacciones cada 5-12 minutos. Esto permite la restauración a un momento dado (Point-in-Time Restore, PITR): restaurar la base de datos a cualquier segundo dentro del período de retención (7-35 días para Standard/General Purpose y hasta 35 días para Business Critical). La PITR resulta útil para recuperarse de la eliminación o corrupción accidental de datos.

Azure Cosmos DB con escrituras en varias regiones proporciona un RPO casi nulo para las aplicaciones globales. Todas las regiones configuradas pueden aceptar operaciones de escritura simultáneamente, y Cosmos DB sincroniza los datos automáticamente mediante su protocolo de replicación propietario. Si una región falla, el tráfico se enruta automáticamente a las regiones restantes que estén en buen estado, sin necesidad de una conmutación por error manual, lo que permite lograr valores de RTO y RPO cercanos a cero.

Azure App Service es sin estado (el código de la aplicación se implementa desde un sistema de control de código fuente o un archivo ZIP). Para la DR, el foco está en la capa de datos (la base de datos y el almacenamiento de blobs). App Service se puede volver a implementar rápidamente en una región secundaria mediante una canalización de CI/CD. Sin embargo, debe asegurarse de que el dominio personalizado, los certificados TLS y la configuración de la aplicación se repliquen o se incluyan en scripts para poder recrearlos rápidamente en la región secundaria.

Azure Blob Storage con almacenamiento con redundancia geográfica (GRS) replica automáticamente los datos en una región secundaria situada a cientos de kilómetros. Los datos se replican de forma asíncrona (el RPO suele ser inferior a 15 minutos). Read-Access GRS (RA-GRS) permite leer desde el punto de conexión secundario incluso antes de activar la conmutación por error, lo que resulta útil para cargas de trabajo de análisis y generación de informes durante una interrupción de la región primaria.

Azure Functions no tiene estado por diseño, por lo que resulta fácil volver a implementarlas. Para la DR, implemente la misma aplicación de funciones en una región secundaria y use Traffic Manager para enrutar los desencadenadores HTTP entre regiones. Para los desencadenadores que no son HTTP (Service Bus, Event Grid), configure el origen de mensajes para distribuirlos a ambas regiones o haga que la región secundaria consulte el mismo origen. El estado de las Durable Functions se almacena en Azure Storage; asegúrese de que dicho almacenamiento use GRS.

Use la replicación geográfica activa cuando necesite un control detallado; por ejemplo, para dirigir el tráfico de lectura a una réplica secundaria por motivos de rendimiento o para administrar de forma independiente varias réplicas secundarias en distintas regiones. Use los grupos de conmutación por error automática cuando busque simplicidad: un único punto de conexión de escucha, conmutación por error automática según un temporizador y orquestación integrada del proceso de conmutación por error sin intervención manual.

La recuperación ante desastres en PaaS suele ser más barata que la recuperación ante desastres basada en máquinas virtuales por varias razones. La replicación geográfica de SQL Database solo cobra por el almacenamiento y el cómputo de la réplica secundaria; no tiene que pagar la licencia del sistema operativo de una máquina virtual completa. Azure Cosmos DB cobra por las RU aprovisionadas en cada región. Azure Storage GRS añade aproximadamente el doble del coste de almacenamiento. En cambio, las máquinas virtuales replicadas mediante ASR requieren costes completos de cómputo, almacenamiento y licencias en la región secundaria.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que la recuperación ante desastres en PaaS se centra en la capa de datos en lugar de en la replicación de máquinas virtuales; los grupos de conmutación por error automática de Azure SQL proporcionan un único punto de conexión de escucha con conmutación por error automatizada; y las escrituras en varias regiones de Cosmos DB ofrecen valores de RTO y RPO casi nulos para aplicaciones globales. A continuación, exploraremos los marcos de cumplimiento de Azure y el modelo de responsabilidad compartida.