Guía de decisiones sobre regiones de Azure

Al diseñar la estrategia para migrar a Azure, puede elegir entre muchas regiones de Azure de todo el mundo. Cada región de Azure tiene características específicas que hacen que la elección de la región correcta para los recursos de Azure sea esencial. Entre los aspectos a tener en cuenta se incluyen los servicios disponibles, capacidad, restricciones y soberanía:

  • Servicios disponibles: los servicios de Azure que puede implementar en cada región difieren en función de varios factores. Seleccione una región para el servicio que necesite de la carga de trabajo. Para más información, consulte Productos disponibles por región.
  • Capacidad: cada región tiene una capacidad máxima. La capacidad máxima de una región puede influir en qué tipos de suscripciones pueden implementar qué tipos de servicios y en qué circunstancias. La capacidad regional es diferente de una cuota de suscripción. Si planea realizar una migración a gran escala de un centro de datos a Azure, puede que quiera consultarlo con el equipo de campo local o con el administrador de cuentas de Azure para confirmar que puede realizar la implementación a la escala que necesita.
  • Restricciones: la implementación de servicios en determinadas regiones está sujeta a ciertas restricciones. Por ejemplo, algunas regiones solo están disponibles para la copia de seguridad o 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 aisladas del resto de Azure. Microsoft no las administra necesariamente y podrían estar restringidas a determinados tipos de clientes. Estas regiones soberanas son:

Funcionamiento en varias regiones geográficas

Una organización puede funcionar en varias regiones geográficas para lograr una resistencia esencial para sus operaciones. Tener operaciones en varias regiones geográficas presenta una complejidad potencial en las siguientes áreas:

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

La selección de la región es una parte clave de la estrategia general 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 diferencias entre las regiones de Azure. Se deben tener en cuenta los siguientes factores:

  • Las regiones de Azure se implementan por pares. Cada región está emparejada con otra región en el mismo límite geopolítico para proporcionar resistencia si se produce un error catastrófico en la región. Una excepción es Brazil South, que está emparejada con South Central US.

    La implementación en regiones emparejadas debe considerarse una estrategia de resistencia principal y secundaria. Esta es otra información que se debe tener en cuenta:

    • Azure Storage admite almacenamiento con redundancia geográfica (GRS). En el GRS de Azure Storage 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. Las aplicaciones y la red deben configurarse para que admitan regiones emparejadas.
    • 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 usar GRS de Azure Storage para copias de seguridad o recuperación de máquinas virtuales. En vez de eso, use Azure Backup, Azure Site Recovery y Azure Managed Disks, para respaldar la resistencia de las cargas de trabajo de infraestructura como servicio (IaaS).

    Para más información, consulte Regiones emparejadas de Azure.

  • 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 que tienen implementaciones globales pueden usar en su lugar Azure 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 las regiones de Azure. Pero, a menudo, los recursos de un grupo de recursos suelen abarcar varias regiones. 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 de ese grupo de recursos sigan funcionando. La resistencia del grupo de recursos por región puede afectar a la forma en que diseña la red y el grupo de recursos.

  • Muchos servicios de plataforma como servicio (PaaS) de Azure admiten puntos de conexión de servicio o Azure Private Link. Ambas soluciones pueden influir significativamente en cómo diseñará la red a medida que considere la resistencia regional, la migración y la gobernanza.

  • Muchos servicios de PaaS se basan en sus propias soluciones de resistencia regional. Por ejemplo, en implementaciones de Azure SQL Database y Azure Cosmos DB puede realizar fácilmente réplicas en más regiones. Algunos servicios de Azure, como Azure DNS, no tienen dependencias regionales. A la hora de considerar qué servicios va a utilizar en el proceso de adopción de la nube, 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 que use.

  • 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. Las ventajas de usar un patrón activo-activo incluyen equilibrio de carga global, mayor tolerancia a errores y aumentos 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. Los contratos de nivel de servicio de Azure se aplican a los servicios que se ejecutan en regiones específicas. Nunca debe realizar implementaciones con dependencia de una sola región en las aplicaciones críticas. Disponga siempre de algún plan contra errores regionales y practique medidas de recuperación y de mitigación.

Documentar la complejidad del escenario

Después de considerar la topología de red, determine si se requiere más documentación y alineación de procesos. El enfoque siguiente puede ayudar a evaluar las posibles dificultades 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 y regiones identificados tienen requisitos de cumplimiento que gobiernen 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 o región identificado?
  • Documente los centros de datos y los recursos. ¿En el país o región 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 a lo largo del proceso de migración para dirigir el inventario inicial. En la tabla siguiente se muestran escenarios de ejemplo que pueden ayudarle a documentar los resultados:

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

Conocimiento de los requisitos de soberanía de datos

En todo el mundo, las organizaciones gubernamentales han empezado a establecer la soberanía de los datos y las regulaciones de privacidad de los datos. Estos tipos de requisitos de cumplimiento suelen requerir la localización en un país o región específicos para proteger a los ciudadanos que residen en esa ubicación. En algunos casos, los datos que pertenecen a clientes, empleados o asociados se deben almacenar en una plataforma en la nube en la misma región que el usuario.

Sortear esta dificultad ha sido una motivación importante para que las organizaciones que operan a escala global realicen la migración a la nube. Para mantener el cumplimiento con la soberanía de datos, algunas organizaciones han optado por implementar recursos de TI duplicados en los proveedores de nube de la región. En la tabla anterior, el escenario de Alemania constituye un buen ejemplo. En este escenario se incluyen clientes, asociados y empleados, pero no los recursos de TI actuales de Alemania. Esta organización puede optar por implementar algunos recursos en un centro de datos dentro del área de regulación de la soberanía de datos, posiblemente incluso usando los centros de datos de Azure Alemania. Una descripción de los datos afectados por las regulaciones regionales de soberanía de datos ayudaría al equipo de adopción de la nube a conocer el mejor enfoque de migración para la organización.

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

Las organizaciones que admiten usuarios de varios países o regiones han desarrollado soluciones técnicas que permiten afrontar el tráfico de los usuarios. En algunos casos, las soluciones implican la localización de los recursos. En otros escenarios, la organización puede optar por implementar soluciones globales de red de área extensa (WAN) para afrontar bases de usuarios dispares mediante 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.

Si una organización admite empleados, asociados y clientes de Alemania sin tener allí actualmente centros de datos, es probable que la organización 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 o regiones. 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 y a los procesos de evaluación, migración y optimización. Comprender los perfiles de usuario de cada país o región 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. Tenga en cuenta los siguientes factores:

Decisiones sobre la arquitectura: determinar la región de destino es uno de los primeros pasos que se incluyen en el diseño de la estrategia de migración. Esta determinación a menudo se ve afectada 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 pueden variar entre regiones. Conocer 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 escenarios de ejemplo de la tabla de Complejidad de documentos muestran que es probable que tenga que planear las dependencias entre varios centros de datos globales. En muchas organizaciones que operan a esta escala, es posible que esas dependencias no estén documentadas o que no se comprendan bien. El enfoque de la organización para evaluar los perfiles de usuario ayuda a identificar algunas de estas dependencias en la organización. El equipo debe explorar otros pasos de evaluación que puedan mitigar los riesgos y las complejidades que surgen de las dependencias.

Implementación de un 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 regiones. El equipo de adopción de la nube debe evaluar la soberanía de datos mediante un modelo de servicio compartido para esos servicios, como se describe en la arquitectura de referencia para una topología de red en estrella tipo hub-and-spoke con servicios compartidos.
  • Cuando se implementan varias instancias de entornos similares, el uso de 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.

Requisitos previos controlados por datos

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

  • Finalización de la detección general: complete la tabla de Complejidad de documentos para evaluar la complejidad de la estrategia de adopción de la nube.
  • Analice los perfiles de usuario en cada país o región afectado: es importante entender el enrutamiento de usuarios 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 el enrutamiento de usuarios tan pronto como sea posible en el proceso.
  • Complete la 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. Para más información, consulte ¿Qué es un patrimonio digital?
  • Use el etiquetado para los requisitos 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 de topología de red en estrella tipo hub-and-spoke: a menudo, los sistemas distribuidos comparten dependencias comunes. A menudo, puede abordar las dependencias compartidas mediante la implementación de un modelo de topología de red en estrella tipo hub-and-spoke. Aunque la implementación de este modelo está fuera del ámbito del proceso de migración, marque el modelo 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 la nube debe realizar un seguimiento de las escalaciones que resulten de esos cambios en la red y administrarlas. 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 asegurarse de que los cambios en la red no bloqueen las cargas de trabajo globales. Priorice las cargas de trabajo globales solo cuando finalicen los cambios de red.

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

Evaluación de los cambios en el proceso

Cuando la organización se enfrenta a las complejidades de los recursos y la base de usuarios globales de un escenario 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 ayudarle a identificar las dependencias. Un procedimiento recomendado es usar estas herramientas antes de comenzar la migración. Cuando existe una complejidad global, este se convierte en un paso necesario en el proceso de evaluación. Mediante una agrupación de dependencias, la visualización de la dependencia puede ayudarle 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 se encuentran 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 los requisitos previos 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 de la migración debe consultar a los expertos en redes y operaciones. Estos expertos ayudarán a 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 ayudarle a configurar las conexiones de red necesarias.

Diseño para el cumplimiento: las salidas del análisis de perfiles de usuario de los requisitos previos 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 Estos expertos pueden ayudar al arquitecto a 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 ayudarle con el diseño.

Advertencia

Al usar la arquitectura de referencia para ExpressRoute o las arquitecturas de referencia para las aplicaciones, es posible que tenga que excluir elementos de datos específicos de los procesos de replicación para cumplir con los requisitos de soberanía de datos. La tarea de excluir elementos de datos específicos agrega un paso en el 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 adicionales. Estas consideraciones incluyen 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. Esta configuración 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. El proceso de replicación y sincronización consume ancho de banda. La duplicación de la carga de trabajo en una segunda región duplicará la cantidad de ancho de banda que se consume. Si el ancho de banda está limitado o si una carga de trabajo implica una configuración sustancial o un desfase de datos, la replicación de datos en una segunda región podría interferir con el tiempo necesario para completar la migración. Y lo que es más importante, estas restricciones pueden afectar a la experiencia de los usuarios o aplicaciones que siguen dependiendo del ancho de banda disponible del centro de datos de origen.

Sincronización de datos: a menudo, el mayor consumo de ancho de banda procede de 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 mantener sincronizadas las aplicaciones es el estado operativo que desea para las aplicaciones, es posible que desee sincronizar la plataforma de datos de origen con cada plataforma en la 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 implican que puede necesitar 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, puede recuperarla en un segundo centro de recursos de Azure desde los recursos migrados. Este enfoque reduce el efecto en los recursos del centro de datos de origen y aprovecha las velocidades de transferencia más rápidas y los límites altos de ancho de banda entre los centros de datos de Azure.

Nota

El enfoque de recuperación ante desastres de Azure a Azure puede aumentar los costos de migración a corto plazo debido a los mayores cargos 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, puede que requiera unos esfuerzos idénticos en cada una de las demás regiones. Aunque sea aceptable una sola implementación, podría tener que replicar los planes de cambios y pruebas empresariales.

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. Otros cambios de configuración menores en la red o en el centro de datos de Azure que elija podrían afectar al rendimiento.

Planes de cambios empresariales: en cualquier escenario de migración complejo, cree un plan de cambio empresarial. El uso de un plan de cambio empresarial 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 un proceso de migración global, el plan debe incluir las consideraciones para los usuarios de cada geografía afectada.

Pruebas empresariales: además del plan de cambio empresarial, es posible que se requieran pruebas empresariales en cada región. Las pruebas empresariales en cada región ayudan a garantizar un rendimiento adecuado y el cumplimiento de los patrones de enrutamiento de red modificados.

Paquetes piloto de promoción: a menudo, la promoción se realiza como una actividad única, y el tráfico de producción se vuelve a enrutar inmediatamente a las cargas de trabajo migradas. En un trabajo de publicación global, la promoción debe realizarse en paquetes piloto, que son colecciones predefinidas de usuarios. El uso de paquetes piloto de promoción proporciona al equipo de estrategia de la nube y al equipo de adopción de la nube la oportunidad de observar un mejor rendimiento y mejorar el soporte técnico de los usuarios de cada región. Por lo general, los paquetes piloto 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, es posible volver a enrutar el grupo siguiente.

Optimización del paquete piloto: una de las ventajas de usar paquetes piloto de promoción es que dispone de una capacidad de observación más profunda y una oportunidad para optimizar los recursos implementados. Después de que el primer paquete piloto use correctamente la producción durante un breve tiempo, puede refinar los recursos migrados si los procedimientos de operaciones de TI lo admiten.