Guía de decisiones sobre regiones de Azure

Azure abarca muchas regiones de todo el mundo. Cada una de las regiones de Azure tiene unas características concretas, lo que hace que elegir cuál de ellas se usa sea algo extraordinariamente importante. Estas incluyen servicios disponibles, capacidad, restricciones y soberanía:

  • Servicios disponibles: los servicios que se implementan en cada región varían en función de varios factores. Seleccione para la carga de trabajo una región que contenga el servicio que desea. Para más información, consulte Productos disponibles por región.
  • Capacidad: cada región tiene una capacidad máxima. Esto puede afectar a los tipos de suscripciones que pueden implementar los tipos de servicios y en qué circunstancias. La capacidad es diferente a las cuotas de suscripción. Si planea una migración a gran escala del centro de datos a Azure, puede que quiera consultarlo con el equipo de campo local de Azure o con el administrador de cuentas para confirmar que puede realizar la implementación a la escala necesaria.
  • Restricciones: la implementación de servicios en determinadas regiones está sujeta a ciertas restricciones. Por ejemplo, algunas regiones solo están disponibles como destino de copia de seguridad o de conmutación por error. Otras restricciones que se deben tener en cuenta son los requisitos de soberanía de los datos.
  • Soberanía: determinadas regiones están dedicadas a entidades soberanas concretas. Aunque todas las regiones son regiones de Azure, estas regiones soberanas están completamente aisladas del resto de Azure. Microsoft no las administra necesariamente y podrían estar restringidas a determinados tipos de clientes. Estas regiones soberanas son:
    • Azure China 21Vianet
    • Azure Alemania: Azure Alemania está en desuso en favor de regiones de Azure no soberanas estándar en Alemania.
    • Azure Gobierno de EE. UU.
    • Microsoft administra dos regiones de Australia, pero se proporcionan para el gobierno australiano y sus clientes y contratistas. Por lo tanto, estas regiones llevan unas restricciones del cliente similares a las demás nubes soberanas.

Funcionamiento en varias regiones geográficas

Cuando las empresas operan en diversas regiones geográficas, lo que puede ser esencial para lograr resistencia, se introduce una complejidad potencial en los siguientes aspectos:

  • Distribución de los recursos
  • Perfiles de acceso de los usuarios
  • Requisitos de cumplimiento
  • Resistencia regional

La selección regional es muy importante para la estrategia global de adopción de la nube. Empecemos por las consideraciones sobre la red.

Consideraciones sobre la red

Cualquier implementación sólida en la nube requiere una red bien ponderada que tenga en cuenta las regiones de Azure. Se debe tener en cuenta lo siguiente:

  • Las regiones de Azure se implementan por pares. Si se produce un error grave en una región, se designa otra región dentro del mismo límite geopolítico como su región emparejada. La implementación en regiones emparejadas debe considerarse una estrategia de resistencia principal y secundaria. Una excepción a esta estrategia es Brazil South, que está emparejada con South Central US. Para más información, consulte Regiones emparejadas de Azure.

    • Azure Storage admite almacenamiento con redundancia geográfica (GRS). Esto significa que se almacenan tres copias de los datos en la región primaria y otras tres copias en la región emparejada. En el almacenamiento con redundancia geográfica no se puede cambiar el emparejamiento del almacenamiento.
    • Los servicios que se basan en este tipo de almacenamiento de Azure Storage pueden sacar el máximo partido a esta funcionalidad de región emparejada. Para ello, se deben orientar las aplicaciones y la red para que admitan dicha funcionalidad.
    • Si no planea usar el almacenamiento con redundancia geográfica para apoyar sus necesidades de resistencia regional, no debe utilizar la región emparejada como secundaria. En caso de error regional, los recursos de la región emparejada estarán sometidos a una gran presión mientras se migran los recursos. Para evitarlo, se puede realizar la recuperación en un sitio alternativo y conseguir una mayor velocidad durante la recuperación.

    Advertencia

    No intente utilizar el almacenamiento con redundancia geográfica de Azure para las operaciones de copia de seguridad o recuperación de máquinas virtuales. Use mejor Azure Backup y Azure Site Recovery, junto con Azure Managed Disks, para respaldar la resistencia de las cargas de trabajo de infraestructura como servicio (IaaS).

  • Azure Backup y Azure Site Recovery funcionan de forma conjunta con el diseño de la red para facilitar la resistencia regional para sus necesidades de IaaS y de copia de seguridad de datos. Asegúrese de que la red está optimizada para que las transferencias de datos permanezcan en la red troncal de Microsoft, y use el emparejamiento de redes virtuales si es posible. Algunas organizaciones de mayor tamaño con implementaciones globales pueden usar en su lugar ExpressRoute Premium para enrutar el tráfico entre regiones y ahorrarse los posibles costos de salida regionales.

  • Los grupos de recursos de Azure son específicos de cada región. Sin embargo, es normal que los recursos de un grupo de recursos abarquen varias regiones. Tenga en cuenta que, en caso de error en una región, las operaciones del plano de control en un grupo de recursos producirán un error en la región afectada, aunque los recursos de otras regiones (dentro de ese grupo de recursos) sigan funcionando. Esto puede afectar tanto al diseño de la red como al del grupo de recursos.

  • Muchos servicios de plataforma como servicio (PaaS) dentro de Azure admiten puntos de conexión de servicio o Azure Private Link. Ambas soluciones afectan notablemente a aspectos de la red como la resistencia, la migración y la gobernanza regionales.

  • Muchos servicios de PaaS se basan en sus propias soluciones de resistencia regional. Por ejemplo, tanto Azure SQL Database como Azure Cosmos DB permiten realizar fácilmente réplicas en regiones adicionales. Los servicios como Azure DNS no tienen dependencias regionales. A la hora de considerar qué servicios va a utilizar en el proceso de adopción, asegúrese de que conoce a la perfección las funcionalidades de la conmutación por error y los pasos de recuperación que puede necesitar cada servicio de Azure.

  • Además de realizar la implementación en varias regiones para permitir la recuperación ante desastres, muchas organizaciones deciden usar un patrón activo-activo en la implementación para que no sea necesaria ninguna conmutación por error. Este método ofrece las ventajas adicionales de equilibrio de carga global, tolerancia a errores adicional y mejoras del rendimiento de la red. Para sacar el máximo partido a este patrón, las aplicaciones deben admitir la ejecución activa-activa en varias regiones.

Advertencia

Las regiones de Azure son construcciones de alta disponibilidad a las que se ha aplicado un Acuerdo de Nivel de Servicio a los servicios que se ejecutan en ellas. Pero nunca debe haber dependencia de una sola región en las aplicaciones con misiones críticas. Disponga siempre de algún plan contra errores regionales y practique medidas de recuperación y de mitigación.

Después de tener en cuenta la topología de red, es necesario consultar la documentación adicional y la alineación de los procesos que podría ser necesaria. El enfoque siguiente puede ayudar a evaluar los desafíos posibles y a establecer una línea de acción general:

  • Considere una implementación de disponibilidad y gobernanza más sólida.
  • Realice un inventario de las geografías afectadas. Cree una lista de las regiones y los países afectados.
  • Documente los requisitos de soberanía de datos. ¿Los países identificados tienen requisitos de cumplimiento que rigen la soberanía de datos?
  • Documente la base de usuarios. ¿La migración a la nube afectará a los empleados, asociados o clientes del país identificado?
  • Documente los centros de datos y los recursos. ¿En el país identificado hay recursos que se podrían incluir en el trabajo de migración?
  • Documente los requisitos de disponibilidad y conmutación por error de la SKU regional.

Alinee los cambios en el proceso de migración para dirigir el inventario inicial.

Complejidad de documentos

La tabla siguiente puede ayudar a documentar los resultados de los pasos anteriores:

Region Country Empleados locales Usuarios externos locales Centros de datos o recursos locales Requisitos de soberanía de datos
Norteamérica Estados Unidos Asociados y clientes No
Norteamérica Canadá No Clientes
Europa Alemania Asociados y clientes No, solo red
Asia Pacífico Corea del Sur Asociados No

Importancia de la soberanía de datos

En todo el mundo, las organizaciones gubernamentales han empezado a establecer requisitos de soberanía de datos, como el Reglamento general de protección de datos (RGPD). Con frecuencia, los requisitos de cumplimiento de esta naturaleza requieren localización dentro de una región específica o, incluso, dentro de un país específico para proteger a sus ciudadanos. En algunos casos, los datos que pertenecen a clientes, empleados o asociados se deben almacenar en una plataforma en la nube dentro de la misma región en que se encuentra el usuario final.

Abordar este desafío ha sido una motivación importante para que las empresas que operan a escala global realicen la migración a la nube. Para mantener los requisitos de cumplimiento, algunas empresas han optado por implementar recursos de TI duplicados en los proveedores de nube dentro de la región. En la tabla anterior, Alemania es un buen ejemplo de este escenario. En este ejemplo se incluyen clientes, asociados y empleados, pero no los recursos de TI actuales de Alemania. Esta empresa puede optar por implementar algunos recursos en un centro de datos dentro del área del RGPD, posiblemente incluso usando los centros de datos de Azure Alemania. Entender cuáles son los datos a los que afectará el RGPD podría ayudar al equipo de adopción de la nube a comprender cuál es el mejor enfoque de migración en este caso.

¿Por qué es importante la ubicación de los usuarios finales?

Las empresas que admiten usuarios finales en varios países han desarrollado soluciones técnicas para abordar el tráfico de usuario final. En algunos casos, esto implica la localización de los recursos. En otros escenarios, la empresa puede optar por implementar soluciones globales de red de área extensa (WAN) para abordar bases de usuarios dispares a través de soluciones centradas en la red. En cualquier caso, la estrategia de migración se puede ver afectada por los perfiles de uso de esos distintos usuarios finales.

Dado que la empresa admite empleados, asociados y clientes de Alemania sin tener actualmente allí centros de datos, es probable que esta empresa haya implementado una solución de línea alquilada. Este tipo de solución enruta el tráfico a los centros de datos de otros países. Este enrutamiento existente presenta un riesgo importante al rendimiento percibido de las aplicaciones migradas. Insertar saltos adicionales en una WAN global establecida y ajustada puede crear la percepción de que las aplicaciones bajan su rendimiento después de la migración. Buscar y corregir estos problemas puede agregar retrasos importantes a un proyecto.

En cada uno de los procesos siguientes, se incluyen instrucciones para abordar esta complejidad en lo referente a los requisitos previos, los recursos, la migración y los procesos de optimización. Comprender los perfiles de usuario de cada país resulta crítico para administrar correctamente esta complejidad.

¿Por qué es importante la ubicación de los centros de datos?

La ubicación de los centros de datos existentes puede afectar a una estrategia de migración. Por ejemplo:

Decisiones sobre la arquitectura: la región de destino es uno de los primeros pasos que se incluyen en el diseño de la estrategia de migración. Suele verse afectado por la ubicación de los recursos existentes. Además, la disponibilidad de los servicios en la nube y el costo unitario de esos servicios puede variar de una región a otra. Entender dónde se encuentran los recursos actuales y futuros afecta a las decisiones en materia de arquitectura y puede influir en las estimaciones de presupuesto.

Dependencias de los centros de datos: los datos de la tabla anterior muestran que es probable que existan dependencias entre varios centros de datos globales. En muchas organizaciones que operan en este tipo de escala, es posible que esas dependencias no estén documentadas o que no se comprendan bien. El enfoque de la empresa para evaluar los perfiles de usuario ayuda a identificar algunas de estas dependencias en la organización. Además, el equipo debe explorar otros pasos de evaluación que puedan mitigar los riesgos y las complejidades que surgen de las dependencias.

Implementación del enfoque general

El enfoque siguiente usa un modelo controlado por datos para abordar las complejidades de la migración global. Cuando el ámbito de una migración abarca varias regiones, el equipo de adopción de la nube debe evaluar las consideraciones de preparación siguientes:

  • Es posible que la soberanía de datos requiera localizar algunos recursos, pero puede que muchos de los recursos no estén regulados por esas restricciones de cumplimiento. Aspectos como el registro, la creación de informes, el enrutamiento de red, la identidad y otros servicios centrales de TI pueden ser elegibles para hospedarlos como servicios compartidos entre varias suscripciones o, incluso, varias regiones. Al realizar la evaluación, el equipo de adopción de la nube debería usar un modelo de servicio compartido para esos servicios, como se describe en la arquitectura de referencia para una topología radial con servicios compartidos.
  • Cuando se implementan varias instancias de entornos similares, un generador de entornos podría crear coherencia, mejorar la gobernanza y acelerar la implementación. La guía de gobernanza de empresas complejas establece un enfoque que crea un entorno que se escala en varias regiones.

Cuando el equipo esté cómodo con el enfoque de línea de base y la preparación esté alineada, deberían tenerse en cuenta algunos requisitos previos controlados por datos:

  • Detección general: complete la tabla de documentación de la complejidad.
  • Realice un análisis de los perfiles de usuario en cada país afectado: es importante entender el enrutamiento del usuario final general en una etapa temprana del proceso de migración. Cambiar las líneas alquiladas globales y agregar conexiones como ExpressRoute a un centro de datos en la nube pueden requerir meses de retrasos en la red. Aborde esta complejidad tan pronto como sea posible en el proceso.
  • Racionalización del patrimonio digital inicial: cada vez que se introducen complejidades en una estrategia de migración, se debe realizar una racionalización del patrimonio digital inicial. Consulte las instrucciones sobre racionalización del patrimonio digital.
    • Requisitos adicionales del patrimonio digital: establezca directivas de etiquetado para identificar todas las cargas de trabajo afectadas por los requisitos de soberanía de datos. Las etiquetas necesarias deben empezar en la racionalización del patrimonio digital y pasar a los recursos migrados.
  • Evaluación de un modelo radial: a menudo, los sistemas distribuidos comparten dependencias comunes. Por lo general, esas dependencias se pueden abordar mediante la implementación de un modelo radial. Si bien ese tipo de modelo está fuera del ámbito del proceso de migración, se debe marcar para considerarlo durante las iteraciones futuras de los procesos de preparación.
  • Asignación de prioridades de los trabajos pendientes de migración: cuando se necesitan cambios en la red para respaldar la implementación en producción de una carga de trabajo que admite varias regiones, el equipo de estrategia de nube debe realizar un seguimiento de las escalaciones y administrarlas con respecto a esos cambios en la red. El nivel más alto de respaldo ejecutivo ayuda a acelerar el cambio, ya que se libera al equipo de estrategia del trabajo de cambiar las prioridades del trabajo pendiente y de que los cambios en la red no bloquean las cargas de trabajo globales. La prioridad de dichas cargas de trabajo solo se debe establecer una vez que se completen los cambios en la red.

Estos requisitos previos ayudan a establecer procesos que puedan abordar esta complejidad durante la ejecución de la estrategia de migración.

Evaluación de los cambios en el proceso

Al enfrentarse a las complejidades de los recursos y la base de usuarios globales de los escenarios de migración, se deben agregar algunas actividades clave a la evaluación de los candidatos para la migración. Estas actividades producen datos para comprender bien los obstáculos y los resultados de los usuarios y recursos globales.

Acción sugerida durante el proceso de evaluación

Evaluación de las dependencias entre centros de datos: Las herramientas de visualización de dependencias de Azure Migrate pueden ayudar a identificar las dependencias. El uso de estas herramientas antes de la migración es un procedimiento recomendado. Cuando existe una complejidad global, pasa a ser un paso necesario para el proceso de evaluación. A través de una agrupación de dependencias, la visualización puede ayudar a identificar los puertos y las direcciones IP de cualquiera de los recursos que se necesitan para admitir la carga de trabajo.

Importante

  • En primer lugar, es necesario que un experto en la materia que entienda los esquemas de dirección IP y la ubicación de los recursos identifique los recursos que residen en un centro de datos secundario.
  • Evalúe tanto las dependencias de nivel inferior como los clientes en la visualización para comprender las dependencias bidireccionales.

Identificación del impacto en el usuario global: las salidas del análisis de perfiles de usuario de requisito previo deben identificar las cargas de trabajo afectadas por los perfiles de usuario globales. Cuando un candidato a la migración se encuentra en la lista de cargas de trabajo afectadas, el arquitecto que prepara la migración debe consultar a los expertos en redes y operaciones para validar las expectativas de enrutamiento y rendimiento de la red. Como mínimo, la arquitectura debe incluir una conexión ExpressRoute entre el centro de operaciones de red más cercano y Azure. La arquitectura de referencia para las conexiones de ExpressRoute puede ayudar a configurar la conexión necesaria.

Diseño para el cumplimiento: las salidas del análisis de perfiles de usuario de requisito previo deben identificar las cargas de trabajo afectadas por los requisitos de soberanía de datos. Durante las actividades de arquitectura del proceso de evaluación, el arquitecto asignado debe consultar a expertos en cumplimiento para comprender los requisitos de migración e implementación en varias regiones. Esos requisitos afectan considerablemente a las estrategias de diseño. Las arquitecturas de referencia para aplicaciones web de varias regiones y aplicaciones de n niveles de varias regiones pueden contribuir al diseño.

Advertencia

Al usar cualquiera de las arquitecturas de referencia anteriores, puede ser necesario excluir elementos de datos específicos de los procesos de replicación para cumplir con los requisitos de soberanía de datos. Esto agregará un paso adicional al proceso de promoción.

Cambios del proceso de migración

Al migrar una aplicación que se debe implementar en varias regiones, el equipo de adopción de la nube debe considerar algunos aspectos. Por ejemplo, el diseño del almacén de Azure Site Recovery, el diseño del servidor de configuración y proceso, los diseños del ancho de banda de la red y la sincronización de datos.

Acción sugerida durante el proceso de migración

Diseño del almacén de Azure Site Recovery: Azure Site Recovery es la herramienta sugerida para la replicación nativa de la nube y la sincronización de recursos digitales en Azure. Site Recovery replica los datos sobre el recurso en un almacén de Site Recovery, que está enlazado a una suscripción específica en un centro de datos de Azure y una región específicos. Al replicar recursos en una segunda región, es posible que también se necesite un segundo almacén de Site Recovery.

Diseño del servidor de configuración y proceso: Site Recovery funciona con una instancia local de un servidor de configuración y proceso, que está enlazado a un almacén de Site Recovery único. Esto significa que es posible que sea necesario instalar una segunda instancia de estos servidores en el centro de datos de origen para facilitar la replicación.

Diseño del ancho de banda de la red: durante la replicación y la sincronización en curso, los datos binarios se mueven a través de la red, desde el centro de datos de origen al almacén de Site Recovery en el centro de datos de Azure de destino. Este proceso consume ancho de banda. La duplicación de la carga de trabajo en una segunda región duplicará la cantidad de ancho de banda consumido. Cuando el ancho de banda es limitado o una carga de trabajo implica una gran cantidad de configuración o la desviación de los datos, puede interferir con el tiempo que se necesita para completar la migración. Lo que es más importante, puede afectar a la experiencia de los usuarios o aplicaciones que siguen dependiendo del ancho de banda del centro de datos de origen.

Sincronización de datos: a menudo, el mayor consumo de ancho de banda se origina en la sincronización de la plataforma de datos. Tal como se define en las arquitecturas de referencia de las aplicaciones web de varias regiones y las aplicaciones de n niveles de varias regiones, a menudo se requiere la sincronización de datos para mantener alineadas las aplicaciones. Si este es el estado operativo deseado de la aplicación, puede ser aconsejable realizar una sincronización entre la plataforma de datos de origen y cada una de las plataformas de nube. Hágalo antes de migrar los recursos de la aplicación y de nivel intermedio.

Recuperación ante desastres de Azure a Azure: una opción alternativa puede reducir aún más la complejidad. Si las estrategias de sincronización de datos y escalas de tiempo van orientadas a una implementación en dos pasos, una solución aceptable podría ser la recuperación ante desastres de Azure a Azure. En este escenario, la carga de trabajo se migra al primer centro de datos de Azure con un solo almacén de Site Recovery y un diseño de servidor de configuración o proceso. Después de probar la carga de trabajo, se puede recuperar en un segundo centro de recursos de Azure desde los recursos migrados. Este enfoque reduce el impacto en los recursos del centro de datos de origen y usa las velocidades de transferencia más rápidas y los límites altos de ancho de banda disponibles entre los centros de datos de Azure.

Nota

Este enfoque puede aumentar los costos de migración a corto plazo debido a los cargos adicionales de ancho de banda de salida.

Optimización y promoción de los cambios del proceso

A medida que se enfrenta a la complejidad global durante la optimización y la promoción, podría ser necesario duplicar los esfuerzos en cada una de las regiones adicionales. Cuando es aceptable una sola implementación, aun así, podría tener que duplicar los planes de cambio y prueba empresarial.

Acción sugerida durante el proceso de optimización y promoción

Prueba preliminar de optimización: una prueba de automatización inicial puede identificar posibles oportunidades de optimización, como con cualquier trabajo de migración. En el caso de cargas de trabajo globales, pruebe la carga de trabajo en cada región de forma independiente. Los cambios de configuración secundarios en la red o en el centro de datos de Azure de destino pueden afectar al rendimiento.

Planes de cambios empresariales: en cualquier escenario de migración complejo, cree un plan de cambio empresarial. Este plan garantiza una comunicación clara con respecto a cualquier cambio en los procesos empresariales, las experiencias de usuario y la temporización de las tareas necesarias para integrar los cambios. En el caso de los trabajos de migración global, el plan debe incluir las consideraciones para los usuarios finales de cada geografía afectada.

Pruebas empresariales: junto con el plan de cambio empresarial, es posible que se requieran pruebas empresariales en cada región. Estas pruebas garantizan un rendimiento adecuado y el cumplimiento de los patrones de enrutamiento de red modificados.

Pilotos de promoción: a menudo, la promoción se realiza como una actividad única, reenrutando el tráfico de producción a las cargas de trabajo migradas. En el caso de los trabajos de liberación globales, la promoción debe realizarse en paquetes piloto (o colecciones predefinidas de usuarios). Esto permite que el equipo de estrategia de la nube y el equipo de adopción de la nube observen un mejor rendimiento y mejoren el respaldo de los usuarios de cada región. Por lo general, los pilotos de promoción se controlan en el nivel de red al cambiar el enrutamiento de intervalos IP específicos desde los recursos de carga de trabajo de origen a los recursos migrados recientemente. Una vez que se migra una colección especificada de usuarios finales, es posible volver a enrutar el grupo siguiente.

Optimización de pilotos: una de las ventajas de los paquetes piloto de promoción es que permiten observaciones más profundas y la optimización adicional de los recursos implementados. Después de un período breve de uso de producción por parte del primer piloto, se sugiere perfeccionar más los recursos migrados cuando así lo permitan los procedimientos de operaciones de TI.