Confiabilidad del servicio de desidentificación de Azure Health Data Services (versión preliminar)
En este artículo, se describe la compatibilidad con la confiabilidad del servicio de desidentificación (versión preliminar). Para obtener información general más detallada sobre los principios de confiabilidad de Azure, consulte Confiabilidad de Azure.
Recuperación ante desastres entre regiones
La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.
En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.
Cada servicio de desidentificación (versión preliminar) se implementa en una sola región de Azure. Si una región completa no está disponible o el rendimiento está significativamente degradado:
- La funcionalidad del plano de control de ARM se limita a solo lectura durante la interrupción. Microsoft siempre hace una copia de seguridad de los metadatos del servicio (como las propiedades de los recursos) fuera de la región. Una vez finalizada la interrupción, puede leer y escribir en el plano de control.
- Todas las solicitudes del plano de datos producen un error durante la interrupción, como las solicitudes de la API de desidentificación o de trabajos. No se pierden datos del cliente, pero existe la posibilidad de que se pierdan los metadatos del progreso del trabajo. Una vez finalizada la interrupción, puede leer y escribir en el plano de datos.
Tutorial de recuperación ante desastres
Si toda una región de Azure no está disponible, aún puede garantizar una alta disponibilidad de las cargas de trabajo. Puede implementar dos o más servicios de desidentificación en una configuración activo-activo mediante el uso de Azure Front Door para enrutar el tráfico a ambas regiones.
Con esta arquitectura de ejemplo:
- Se implementan servicios de desidentificación idénticos en dos regiones independientes.
- Se utiliza Azure Front Door para enrutar el tráfico a ambas regiones.
- Durante un desastre, una región se queda sin conexión y Azure Front Door enruta el tráfico exclusivamente a la otra región. El objetivo de tiempo de recuperación durante esta conmutación por error geográfica se limita al tiempo que tarda Azure Front Door en detectar que un servicio está en estado incorrecto.
RTO y RPO
Si adopta la configuración activo-activo, debe esperar un objetivo de tiempo de recuperación (RTO) de 5 minutos. En cualquier configuración, debe esperar un objetivo de punto de recuperación (RPO) de 0 minutos (no se perderán datos del cliente).
Validación del plan de recuperación ante desastres
Requisitos previos
Si no tiene una suscripción a Azure, cree una cuenta gratuita de Azure antes de empezar.
Para completar este tutorial:
Use el entorno de Bash en Azure Cloud Shell. Para más información, consulte Inicio rápido para Bash en Azure Cloud Shell.
Si prefiere ejecutar comandos de referencia de la CLI localmente, instale la CLI de Azure. Si utiliza Windows o macOS, considere la posibilidad de ejecutar la CLI de Azure en un contenedor Docker. Para más información, vea Ejecución de la CLI de Azure en un contenedor de Docker.
Si usa una instalación local, inicie sesión en la CLI de Azure mediante el comando az login. Siga los pasos que se muestran en el terminal para completar el proceso de autenticación. Para ver otras opciones de inicio de sesión, consulte Inicio de sesión con la CLI de Azure.
En caso de que se le solicite, instale las extensiones de la CLI de Azure la primera vez que la use. Para más información sobre las extensiones, consulte Uso de extensiones con la CLI de Azure.
Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes que están instaladas. Para realizar la actualización a la versión más reciente, ejecute az upgrade.
Crear un grupo de recursos
Para este tutorial, necesita dos instancias de un servicio de desidentificación (versión preliminar) en diferentes regiones de Azure. El tutorial usa las regiones Este de EE. UU. y Oeste de EE. UU. 2, pero no dude en elegir sus propias regiones.
Para simplificar la administración y la limpieza, usará un único grupo de recursos para todos los recursos de este tutorial. Considere la posibilidad de usar grupos de recursos distintos para cada región o recurso con el fin de aislar aún más los recursos en una situación de recuperación ante desastres.
Ejecute el comando siguiente para crear el grupo de recursos.
az group create --name my-deid --location eastus
Creación de servicios de desidentificación (versión preliminar)
Siga los pasos descritos en Inicio rápido: Implementación del servicio de desidentificación (versión preliminar) para crear dos servicios independientes, uno en Este de EE. UU. y otro en Oeste de EE. UU 2.
Tome nota de la dirección URL del servicio de cada servicio de desidentificación para que pueda definir las direcciones de backend al implementar Azure Front Door en el paso siguiente.
Crear una instancia de Azure Front Door
Una implementación de varias regiones puede usar una configuración activa-activa o activa-pasiva. Una configuración activa-activa distribuye las solicitudes entre varias regiones activas. Una configuración activa-pasiva mantiene en ejecución las instancias de la región secundaria, pero no les envía tráfico a menos que la región primaria no pueda atenderlo. Azure Front Door tiene una característica integrada que permite habilitar estas configuraciones. Para más información sobre el diseño de aplicaciones con alta disponibilidad y tolerancia a errores, consulte Diseño de aplicaciones de Azure para lograr resistencia y disponibilidad.
Creación de un perfil de Azure Front Door
Ahora, creará una instancia de Azure Front Door Premium para enrutar el tráfico a los servicios.
Ejecute az afd profile create para crear un perfil de Azure Front Door.
Nota:
Si quiere implementar la versión Estándar de Azure Front Door en lugar de la Premium, sustituya el valor del parámetro --sku por Standard_AzureFrontDoor. No puede implementar reglas administradas con la directiva de WAF si elige el nivel estándar. Para ver una comparación detallada de los planes de tarifa, consulte Comparación de niveles de Azure Front Door.
az afd profile create --profile-name myfrontdoorprofile --resource-group my-deid --sku Premium_AzureFrontDoor
| Parámetro | Valor | Descripción |
|---|---|---|
profile-name |
myfrontdoorprofile |
Nombre del perfil de Azure Front Door, que es único dentro del grupo de recursos. |
resource-group |
my-deid |
El grupo de recursos que contiene los recursos de este tutorial. |
sku |
Premium_AzureFrontDoor |
El plan de tarifa del perfil de Azure Front Door. |
Adición de un punto de conexión de Azure Front Door
Ejecute az afd endpoint create para crear un punto de conexión en el perfil de Azure Front Door. Este punto de conexión enruta las solicitudes a los servicios. Puede crear varios puntos de conexión en el perfil después de finalizar esta guía.
az afd endpoint create --resource-group my-deid --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| Parámetro | Valor | Descripción |
|---|---|---|
endpoint-name |
myendpoint |
Nombre del punto de conexión en el perfil, que es único globalmente. |
enabled-state |
Enabled |
Si se va a habilitar este punto de conexión. |
Creación de un grupo de origen de Azure Front Door
Ejecute az afd origin-group create para crear un grupo de origen que contenga los dos servicios de desidentificación.
az afd origin-group create --resource-group my-deid --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Https --probe-interval-in-seconds 60 --probe-path /health --sample-size 1 --successful-samples-required 1 --additional-latency-in-milliseconds 50 --enable-health-probe
| Parámetro | Valor | Descripción |
|---|---|---|
origin-group-name |
myorigingroup |
Nombre del grupo de orígenes. |
probe-request-type |
GET |
El tipo de solicitud de sondeo de estado que se realiza. |
probe-protocol |
Https |
Protocolo que se va a usar para el sondeo de estado. |
probe-interval-in-seconds |
60 |
Número de segundos entre sondeos de estado. |
probe-path |
/health |
La ruta de acceso relativa al origen que se usa para determinar el estado del origen. |
sample-size |
1 |
Número de muestras para tener en cuenta para las decisiones de equilibrio de carga. |
successful-samples-required |
1 |
El número de muestras dentro del período de muestreo que deben realizarse correctamente. |
additional-latency-in-milliseconds |
50 |
Latencia adicional en milisegundos para que los sondeos se ubiquen en el cubo de latencia más bajo. |
enable-health-probe |
Cambie para controlar el estado del sondeo de estado. |
Adición de orígenes al grupo de orígenes de Azure Front Door
Ejecute az afd origin create para agregar un origen al grupo de origen. Para los parámetros --host-name y --origin-host-header, reemplace el valor de marcador de posición <service-url-east-us> por la dirección URL del servicio de Este de EE. UU., dejando fuera el esquema (https://). Debe tener un valor similar a abcdefghijk.api.eastus.deid.azure.com.
az afd origin create --resource-group my-deid --host-name <service-url-east-us> --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name deid1 --origin-host-header <service-url-east-us> --priority 1 --weight 1000 --enabled-state Enabled --https-port 443
| Parámetro | Valor | Descripción |
|---|---|---|
host-name |
<service-url-east-us> |
Nombre de host del servicio de desidentificación principal. |
origin-name |
deid1 |
Nombre del origen. |
origin-host-header |
<service-url-east-us> |
El encabezado host para enviar las solicitudes a este origen. |
priority |
1 |
Establezca este parámetro en 1 para dirigir todo el tráfico al servicio de desidentificación principal. |
weight |
1000 |
Peso del origen en un grupo de orígenes determinado para el equilibrio de carga. Debe estar entre 1 y 1000. |
enabled-state |
Enabled |
Si se va a habilitar este origen. |
https-port |
443 |
El puerto usado para las solicitudes HTTPS al origen. |
Repita este paso para agregar el segundo origen. Para los parámetros --host-name y --origin-host-header, reemplace el valor de marcador de posición <service-url-west-us-2> por la dirección URL del servicio de Oeste de EE. UU. 2, dejando fuera el esquema (https://).
az afd origin create --resource-group my-deid --host-name <service-url-west-us-2> --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name deid2 --origin-host-header <service-url-west-us-2> --priority 1 --weight 1000 --enabled-state Enabled --https-port 443
Preste atención a los parámetros --priority en ambos comandos. Dado que ambos orígenes se han establecido en prioridad 1, Azure Front Door trata ambos orígenes como activos y dirige el tráfico a ambas regiones. Si la prioridad de un origen se establece en 2, Azure Front Door trata ese origen como secundario y dirige todo el tráfico al otro origen a menos que deje de funcionar.
Adición de una ruta de Azure Front Door
Ejecute az afd route create para asignar el punto de conexión al grupo de origen. Esta ruta reenvía las solicitudes del punto de conexión al grupo de origen.
az afd route create --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --origin-group myorigingroup --supported-protocols Https --link-to-default-domain Enabled
| Parámetro | Valor | Descripción |
|---|---|---|
endpoint-name |
myendpoint |
Nombre del punto de conexión. |
forwarding-protocol |
MatchRequest | Protocolo que usa esta regla al reenviar el tráfico a los servidores back-end. |
route-name |
route |
Nombre de la ruta. |
supported-protocols |
Https |
Lista de protocolos admitidos para esta ruta. |
link-to-default-domain |
Enabled |
Si esta ruta se vincula al dominio de punto de conexión predeterminado. |
Espere unos 15 minutos a que se complete este paso, ya que este cambio tarda algún tiempo en propagarse globalmente. Después de este período, la instancia de Azure Front Door será totalmente funcional.
Prueba de Front Door
Cuando se crea el perfil de Azure Front Door Estándar/Premium, la configuración tarda unos minutos en implementarse globalmente. Cuando haya finalizado, puede acceder al host de front-end que ha creado.
Ejecute az afd endpoint show para obtener el nombre de host del punto de conexión de Front Door. El aspecto será parecido al siguiente: abddefg.azurefd.net
az afd endpoint show --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
En un explorador, vaya al nombre de host del punto de conexión que devolvió el comando anterior: <endpoint>.azurefd.net/health. La solicitud se debe enrutar automáticamente al servicio de desidentificación principal en Este de EE. UU.
Para probar la conmutación por error global instantánea:
Abra un explorador y vaya al nombre de host del punto de conexión:
<endpoint>.azurefd.net/health.Siga los pasos descritos en Configuración del acceso privado para deshabilitar el acceso de red pública para el servicio de desidentificación de Este de EE. UU.
Actualice el explorador. Debería ver la misma página de información porque ahora el tráfico se dirige al servicio de desidentificación de Oeste de EE. UU 2.
Sugerencia
Es posible que tenga que actualizar la página varias veces para que se complete la conmutación por error.
Ahora deshabilite el acceso de red pública para el servicio de desidentificación de Oeste de EE. UU 2.
Actualice el explorador. Esta vez debería aparecer un mensaje de error.
Vuelva a habilitar el acceso de red pública de uno de los servicios de desidentificación. Actualice el explorador y debería volver a ver el estado de mantenimiento.
Ahora, ha validado que puede acceder a los servicios mediante Azure Front Door y que la conmutación por error funciona según lo previsto. Habilite el acceso de red pública en el otro servicio si ha terminado con las pruebas de la conmutación por error.
Limpieza de recursos
En los pasos anteriores, creó recursos de Azure en un grupo de recursos. Si prevé que no necesitará estos recursos en el futuro, ejecute el siguiente comando para eliminar el grupo de recursos:
az group delete --name my-deid
Este comando puede tardar unos minutos en completarse.
Inicio de la recuperación
Para comprobar el estado de recuperación del servicio, puede enviar solicitudes a <service-url>/health.