Alta disponibilidad para el conector de servicio
El conector de servicio admite zonas de disponibilidad de Azure para ayudarle a lograr resistencia y confiabilidad en las cargas de trabajo críticas para la empresa. El objetivo de la arquitectura de alta disponibilidad en el conector de servicio es garantizar que las conexiones de servicio estén en funcionamiento al menos el 99,9 % del tiempo, de modo que no tenga que preocuparse por los efectos de las posibles operaciones de mantenimiento y interrupciones. Service Conectar or está diseñado para proporcionar compatibilidad de alta disponibilidad para todos los tipos de aplicaciones que se ejecutan en Azure.
Los usuarios pueden distribuir los servicios de proceso de Azure entre zonas de disponibilidad en muchas regiones. El conector de servicio es un proveedor de recursos de extensión para estos servicios de proceso. Al crear una conexión de servicio en un servicio de proceso con zonas de disponibilidad habilitadas, Azure también configurará automáticamente la zona de disponibilidad de conexión de servicio correspondiente para la conexión de servicio. Microsoft es responsable de configurar zonas de disponibilidad y recuperación ante desastres para las conexiones de servicio.
Redundancia de zona en el conector de servicio
El conector de servicio es un proveedor de recursos de extensión de Azure. Amplía Azure App Service, Azure Spring Apps y Azure Container Apps. Al crear una nueva conexión de servicio en uno de estos servicios de proceso con Service Conectar or, se aprovisiona un recurso de conexión como parte del servicio de proceso primario de nivel superior.
Para habilitar la redundancia de zona para la conexión, debe habilitar la redundancia de zona para el servicio de proceso. Una vez configurado el servicio de proceso con redundancia de zona, las conexiones de servicio también se convertirán automáticamente en redundantes de zona. Por ejemplo, si tiene un servicio de aplicaciones con redundancia de zona habilitada, la plataforma distribuye automáticamente las instancias de App Service en tres zonas de la región seleccionada. Al crear una conexión de servicio en este servicio de aplicaciones con el conector de servicio, el recurso de conexión de servicio también se crea automáticamente en las tres zonas correspondientes de la región seleccionada. El tráfico se enruta a todos los recursos de conexión disponibles. Si una zona está fuera de servicio, la plataforma detecta las instancias perdidas e intenta encontrar automáticamente nuevas instancias de reemplazo y distribuir el tráfico según sea necesario.
Nota:
Para crear, actualizar, validar y enumerar conexiones de servicio, el conector de servicio llama a las API desde un servicio de proceso y un servicio de destino. Como service Conectar or se basa en las respuestas del servicio de proceso y del servicio de destino, es posible que las solicitudes a Service Conectar or en un escenario de zona abajo no se realicen correctamente si no se puede acceder al servicio de destino. Esta limitación se aplica a App Service, Azure Container Apps y Azure Spring Apps.
Creación de una conexión de servicio con redundancia de zona con el conector de servicio
Siga las instrucciones siguientes para crear una conexión de servicio con redundancia de zona en App Service mediante la CLI de Azure o Azure Portal. El mismo proceso se puede usar para crear una conexión con redundancia de zona para los servicios de proceso de Azure Spring Apps y Azure Container Apps.
Para habilitar la redundancia de zona para una conexión de servicio mediante la CLI de Azure, empiece por crear una instancia de App Service con redundancia de zona.
Cree un plan de App Service e incluya un parámetro
--zone-redundant. También puede incluir el parámetro--number-of-workerspara especificar la capacidad. Obtenga más información en Implementación de una instancia de App Service con redundancia de zona.az appservice plan create --resource-group MyResourceGroup --name MyPlan --zone-redundant --number-of-workers 6Cree una aplicación en App Service y una conexión a la cuenta de Blob Storage u otro servicio de destino que prefiera.
az webapp create --name MyApp --plan MyPlan resource-group MyResourceGroup az webapp connection create storage-blob
A medida que ha habilitado la redundancia de zona para App Service, la conexión de servicio también es redundante de zona.
Sugerencia
Se recomienda habilitar la redundancia de zona para el servicio de destino. En un escenario de zona fuera de servicio, el tráfico a la conexión se distribuirá automáticamente a otras zonas. Sin embargo, la creación, validación y actualización de conexiones se basan en las API de administración del servicio de destino. Si un servicio de destino no admite redundancia de zona o no la tiene habilitada, se producirá un error en estas operaciones.
Descripción de la recuperación ante desastres y la resistencia en el conector de servicio
La recuperación ante desastres es el proceso de restaurar la funcionalidad de una aplicación después de una pérdida catastrófica.
En la nube somos conscientes de antemano de que se producirán errores. En lugar de intentar evitar todos los errores, el objetivo es minimizar los efectos que pueden provocar los errores de un único componente. Si se produce un desastre, el conector de servicio conmutará por error a la región emparejada. Los clientes no necesitan hacer nada si el equipo del conector de servicio decide o declara la interrupción.
Usaremos los términos RTO (objetivo de tiempo de recuperación) para indicar el tiempo entre el principio de una interrupción que afecta a Service Conectar or y la recuperación a la disponibilidad completa. Usaremos RPO (objetivo de punto de recuperación) para indicar el tiempo entre la última operación restaurada correctamente y la hora del inicio de la interrupción que afecta al servicio Conectar or. El RPO esperado y máximo es de 24 horas y el RTO es de 24 horas.
Las operaciones con service Conectar or pueden producir errores durante el tiempo de desastre, antes de que se produzca la conmutación por error. Una vez completada la conmutación por error, los datos se restaurarán y el cliente no tendrá que realizar ninguna acción.
El conector de servicio controla la continuidad empresarial y la recuperación ante desastres (BCRD) para el almacenamiento y el proceso. La plataforma se esfuerza por tener el menor impacto posible en caso de problemas en el almacenamiento o el proceso, en cualquier región. El diseño de la capa de datos prioriza la disponibilidad sobre la latencia en caso de desastre, lo que significa que si una región está fuera de servicio, el conector de servicio intentará atender la solicitud del usuario final de su región emparejada.
Durante la acción de conmutación por error, el conector de servicio controla la reasignación de DNS a las regiones disponibles. Todos los datos y la acción de la vista del cliente sirven como de costumbre después de la conmutación por error. El conector de servicio cambiará su DNS en aproximadamente una hora. La realización de una conmutación por error manual tardaría más tiempo. Como el conector de servicio es un proveedor de recursos basado en otros servicios de Azure, el tiempo real depende del tiempo de conmutación por error de los servicios subyacentes.
Compatibilidad con la región de recuperación ante desastres
El conector de servicio admite actualmente los siguientes pares de regiones. En caso de que se produzca un error en la región primaria, Azure Storage conmutará por error a la región secundaria.
| Principal | Secundario |
|---|---|
| EUAP de Este de EE. UU. 2 | Este de EE. UU. |
| Centro-Oeste de EE. UU. | Centro-oeste de EE. UU. 2 |
| Oeste de Europa | Norte de Europa |
| Norte de Europa | Oeste de Europa |
| Este de EE. UU. | Oeste de EE. UU. 2 |
| Oeste de EE. UU. 2 | Este de EE. UU. |
Conmutación por error entre regiones
Microsoft es responsable de controlar las conmutaciones por error entre regiones. El conector de servicio ejecuta comprobaciones de estado cada 10 minutos y se detectan y controlan las conmutaciones por error regionales en el back-end del conector de servicio. El proceso de conmutación por error no requiere ningún cambio en las aplicaciones del cliente ni en las configuraciones del servicio de proceso. El conector de servicio usa una configuración de clúster activo-pasivo con conmutación automática por error. Después de una recuperación ante desastres, los clientes pueden usar las funcionalidades completas proporcionadas por el conector de servicio.
La comprobación de estado que se ejecuta cada 10 minutos simula el comportamiento del usuario mediante la creación, validación y actualización de conexiones a servicios de destino en cada uno de los servicios de proceso admitidos por el conector de servicio. Microsoft comenzará a analizar e iniciar una conmutación por error del conector de servicio si se cumple alguna de las condiciones siguientes:
- Se produce un error en la comprobación de estado del servicio tres veces en una fila.
- Los servicios dependientes del conector de servicio declaran una interrupción.
- Los clientes notifican una interrupción de la región.
Las solicitudes a las conexiones de servicio se ven afectadas durante una conmutación por error. Una vez completada la conmutación por error, se restauran los datos de conexión de servicio. Puede comprobar la página de estado de Azure para comprobar el estado de todos los servicios de Azure.
Pasos siguientes
Vaya al artículo de concepto siguiente para obtener más información sobre el conector de servicio.