Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describe cómo se usan los pares de regiones y las regiones no emparejadas en Azure.
Las regiones de Azure son independientes entre sí. Sin embargo, Microsoft asocia algunas regiones de Azure con otras y suelen estar ambas en la misma geografía. Juntas, estas regiones forman un par de regiones. A continuación, estos pares de regiones se usan en un pequeño número de servicios de Azure para admitir la replicación geográfica y la redundancia geográfica. Los pares también se utilizan para apoyar algunos aspectos de la recuperación ante desastres en el improbable caso de que una región experimente un fallo catastrófico y no recuperable.
Sin embargo, muchas regiones no están emparejadas y, en su lugar, usan zonas de disponibilidad como medio principal de redundancia. Además, muchos servicios de Azure admiten redundancia geográfica si las regiones están emparejadas o no.
Puede diseñar una solución altamente resistente si usa regiones emparejadas, regiones no emparejadas o una combinación.
Regiones emparejadas
Algunos servicios de Azure usan regiones emparejadas para crear su estrategia de replicación geográfica y redundancia geográfica de varias regiones. Por ejemplo, el almacenamiento con redundancia geográfica de Azure (GRS) puede replicar automáticamente los datos en una región emparejada.
Si se encuentra en una región emparejada, el uso de su par como región secundaria proporciona varias ventajas:
- Secuencia de recuperación de regiones. En el improbable caso de que se dieran interrupciones en toda la geografía, la recuperación de una región se prioriza fuera de cada par de regiones. En el caso de componentes que se implementan en regiones emparejadas, se prioriza una de las regiones para la recuperación.
- Actualización secuencial. Las actualizaciones planeadas del sistema de Azure se escalonan entre pares de regiones para minimizar el impacto de errores o errores lógicos en el caso poco frecuente de una actualización errónea y para evitar el tiempo de inactividad en las soluciones diseñadas para usar regiones emparejadas juntas para lograr resistencia.
- Residencia de datos. Para cumplir con los requisitos de residencia de datos, casi todas las regiones residen dentro de la misma geografía que su par. Para obtener información sobre las excepciones, consulte la lista de regiones de Azure.
Importante
La implementación de recursos en una región en un par no la hace automáticamente más resistente, ni proporciona funcionalidades automáticas de alta disponibilidad, de recuperación ante desastres o conmutación por error. Resulta fundamental el desarrollo de sus propios planes de alta disponibilidad y recuperación ante desastres, independientemente de si se usan regiones emparejadas o no.
Incluso aunque se configuren características de servicio para usar pares de regiones, no confíe en la conmutación por error administrada por Microsoft entre esos pares como enfoque de recuperación ante desastres principal. Por ejemplo, la conmutación por error administrada por Microsoft de las cuentas de almacenamiento habilitadas para GRS solo se realiza en situaciones catastróficas y después de repetidos intentos de recuperación erróneos.
No se encuentra limitado al uso de servicios dentro de una sola región o dentro del par de la región. Aunque un servicio de Azure dependiera de un par regional específico para algunas de sus funcionalidades de confiabilidad, sería posible hospedar los servicios en cualquier región que satisfaga sus necesidades empresariales. Por ejemplo: una solución de Azure podría usar Azure Storage en la región Centro de Canadá con almacenamiento GRS para replicar datos en la región emparejada, Este de Canadá, mientras usa recursos de proceso de Azure ubicados en Este de EE. UU. y recursos de Azure OpenAI ubicados en Oeste de EE. UU.
Para ver una lista de regiones que incluye todos los pares de regiones, consulte Lista de regiones de Azure.
Regiones emparejadas asimétricamente
La mayoría de los pares de regiones son simétricas, lo que significa que cada región está emparejada bidireccionalmente con otra región. Por ejemplo, Oeste de EE. UU. está emparejado con Este de EE. UU. y Este de EE. UU. está emparejado con Oeste de EE. UU.
Los pares de regiones asimétricas implican regiones que no están emparejadas bidireccionalmente. La lista siguiente incluye pares de regiones asimétricas públicas:
- Sur de Brasil está emparejado con Centro-Sur de Estados Unidos, que no se encuentra dentro de la geografía de Brasil. Centro-sur de EE. UU. no está emparejado con el Sur de Brasil.
- El Gobierno de los Estados Unidos de Arizona está emparejado con el Gobierno de los Estados Unidos de Texas. El Gobierno de EE. UU. de Texas está emparejado de manera bidireccional con el Gobierno de EE. UU. de Virginia.
- La India Occidental está emparejada con el Sur de la India, pero la India del Sur está emparejada con Centro de la India.
- La región Oeste de EE. UU. 3 está emparejada en una dirección con Este de EE. UU. La región Este de EE UU está emparejada bidireccionalmente con Oeste de EE. UU.
Para ver una lista de regiones que incluye todos los pares de regiones asimétricas, consulte Pares de regiones de Azure.
Regiones no emparejadas
Azure se continúa expandiendo globalmente y muchas de las regiones más recientes proporcionan varias zonas de disponibilidad para lograr una mayor resistencia y no tienen un par de regiones.
Muchos servicios de Azure admiten la replicación geográfica y la redundancia geográfica entre cualquier conjunto arbitrario de regiones y no se basan en pares de regiones. Es importante comprender cómo funciona la compatibilidad con varias regiones para los servicios concretos que se usen. Para obtener más información sobre los detalles de cada servicio, consulte las guías de confiabilidad del servicio de Azure.
Para ver una lista de regiones que incluye todas las regiones no emparejadas, consulte Pares de regiones de Azure.