Seleccione regiones de Azure para una migración

Al migrar un entorno existente a Azure, debe seleccionar una región de Azure o un conjunto de regiones para hospedar los componentes migrados. La selección de área implica los siguientes pasos de alto nivel:

• Revise la guía principal de selección de regiones de Azure para comprender cómo seleccionar regiones de Azure que cumplan con sus requisitos.
• Haga un inventario y documente el estado actual de su entorno.
• Implemente un enfoque general para su migración, incluido si ejecutarla en una sola región, usar múltiples zonas de disponibilidad o usar múltiples regiones.
• Evalúe los cambios de proceso que podrían ser necesarios.
• Planear un proceso de migración.
• Optimizar y promover los cambios de proceso.

En este artículo se proporcionan instrucciones sobre cómo elegir regiones de Azure que satisfagan sus necesidades de migración. Si aún no lo ha hecho, es posible que tenga que ampliar las regiones de la zona de aterrizaje para admitir enfoques de varias regiones.

Nota:

En este artículo se tratan las consideraciones específicas de las migraciones de cargas de trabajo. También debe comprender los principios generales para seleccionar regiones de Azure para cualquier organización o carga de trabajo. Para más información, consulte Seleccionar regiones de Azure.

Documentar la complejidad del escenario

Determine si su escenario requiere 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 la base de usuarios. ¿La migración a la nube afectará a los empleados, asociados o clientes del país o región identificados?
• Documente los centros de datos y los recursos. ¿Incluye el esfuerzo de migración algún recurso en el país o región identificados?
• Documente los requisitos de disponibilidad y conmutación por error de la versión regional del producto.
• Documente los requisitos de resistencia para determinar si se requieren zonas de disponibilidad. Normalmente, los requisitos de resistencia se consideran para todo el escenario, no para regiones individuales.
• Documenta los requisitos de soberanía y los requisitos de residencia de datos. Las cargas de trabajo que tienen requisitos específicos de soberanía o residencia de datos pueden influir en la elección de las regiones de Azure.

A lo largo del proceso de migración, considere cómo alinear los cambios en los distintos escenarios e inventarios. En la tabla siguiente se muestra un ejemplo de cómo documentar varios escenarios.

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

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

Las organizaciones que admiten usuarios de varios países o regiones desarrollan 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, los perfiles de uso de usuarios dispares pueden afectar a la estrategia de migración.

Por ejemplo, si una organización admite empleados, asociados y clientes en Alemania, pero actualmente no tiene centros de datos en Alemania, es probable que la organización implemente 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 una de las secciones siguientes, se incluye 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 en cada país o región es fundamental 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 de arquitectura: uno de los primeros pasos en el diseño de la estrategia de migración es determinar la región de destino. La ubicación de los activos existentes suele influir en esta determinación. Además, la disponibilidad de los servicios en la nube y el costo unitario de esos servicios puede variar entre regiones. Los requisitos de residencia de datos, incluidos los requisitos de soberanía, también pueden influir en la decisión de arquitectura. 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 del centro de datos: en la tabla de la sección Documentar la complejidad del escenario, los escenarios de ejemplo muestran que es probable que tenga que planear las dependencias entre varios centros de datos globales. Las organizaciones que operan a esta escala, puede que esas dependencias no se documenten 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 también debe explorar más pasos de evaluación que pueden ayudar a 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. Si el ámbito de migración abarca varias regiones, el equipo de adopción de la nube debe evaluar las consideraciones de preparación siguientes:

• Determine si puede cumplir los requisitos empresariales: utilice varias zonas de disponibilidad para lograr alta disponibilidad, resistencia, rendimiento y costo. Si no se cumplen estos requisitos, considere si necesita un enfoque de varias regiones.

• Evalúe la soberanía de los datos: la soberanía de datos puede requerir la localización de algunos recursos, pero muchos recursos no se rigen por esas restricciones de cumplimiento. Es posible que los servicios como el registro, los informes, la distribución de red, la identidad y otros servicios de TI centrales puedan hospedarse como servicios compartidos en suscripciones o regiones. Evalúe la soberanía de los datos mediante un modelo de servicio compartido para esos servicios. Para obtener un resumen de este enfoque, consulte la arquitectura de referencia para una topología radial con servicios compartidos.

• Asegúrese de que el entorno se escala: si implementa varias instancias de entornos similares, puede establecer un equipo dedicado para las migraciones del entorno para ayudar 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 se sienta cómodo con el enfoque de línea base y la preparación está alineado, tenga en cuenta estos 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 para cada país o región afectado: es importante entender la distribución de usuarios general en una etapa temprana del proceso de migración. Cambiar las líneas de concesión globales y agregar conexiones como Azure ExpressRoute a un centro de datos en la nube puede dar lugar a meses de retrasos en las redes. Aborde el enrutamiento de usuarios tan pronto como sea posible en el proceso.

• Complete la racionalización del patrimonio digital inicial: si introduce complejidad en una estrategia de migración, debe realizar una racionalización del patrimonio digital inicial. Para obtener 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. Asegúrese de que las etiquetas necesarias empiecen 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: si necesita 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. Este nivel superior de soporte técnico ejecutivo ayuda a acelerar el cambio liberando al equipo de estrategia para volver a escribir el trabajo pendiente y asegurarse de que los cambios de red no bloquean 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

Si su escenario de migración cuenta con complejidades de los recursos y la base de usuarios globales, agregue algunas actividades clave a la evaluación de los candidatos para la migración. Estas actividades producen datos para ayudarle a comprender bien los obstáculos y los resultados de los usuarios y recursos globales.

Acciones sugeridas durante el proceso de evaluación

Evaluación de las dependencias entre centros de datos: Las herramientas de análisis de dependencias de Azure Migrate pueden ayudarle a identificar las dependencias. Utilice estas herramientas antes de comenzar la migración. Si el escenario implica complejidad global, evaluar las dependencias es un paso necesario en el proceso de evaluación. Puede utilizar la agrupación de dependencias para visualizar dependencias e identificar los puertos y las direcciones IP de cualquiera de los recursos que se necesitan para admitir la carga de trabajo.

Importante

• Necesita un experto en la materia (SME) que comprenda los esquemas de ubicación de recursos y direcciones IP para identificar los recursos que se encuentran en un centro de datos secundario.
• Evalúe las dependencias de nivel inferior y los clientes en la visualización para comprender las dependencias bidireccionales.

Identificar el impacto global del usuario: la salida del análisis de perfiles de usuario previo debe identificar cualquier carga de trabajo afectada por los perfiles de usuario globales. Si un candidato de migración está en la lista de cargas de trabajo afectadas, el arquitecto de migración debe consultar las redes y las pymes de 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: la salida del análisis de perfiles de usuario previo también debe identificar cualquier carga de trabajo afectada por los requisitos de soberanía de datos. Durante las actividades de arquitectura del proceso de evaluación, el arquitecto asignado debe consultar a los SME de 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 siguientes arquitecturas de referencia pueden ayudar con el diseño:

• Aplicaciones web con redundancia de zona
• Aplicaciones web de varias regiones
• Aplicaciones de niveles N para varias regiones
• Plantillas de carga de trabajo para una zona de aterrizaje soberana

Advertencia

Si utiliza la arquitectura de referencia para ExpressRoute o las arquitecturas de referencia para aplicaciones, es posible que necesite excluir elementos de datos específicos de los procesos de replicación para cumplir con los requisitos de soberanía de los datos. La tarea de excluir elementos de datos específicos añade un paso al proceso de promoción.

Cambios del proceso de migración

Si 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. El diseño de almacenes y servidores de configuración y procesos de Azure Site Recovery son dos de esas consideraciones. Otros aspectos que se deben tener en cuenta son los diseños de ancho de banda de red y la sincronización de datos.

Acciones sugeridas durante el proceso de migración

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

Diseño del servidor de configuración y proceso: Recuperación del sitio funciona con una instancia local de un servidor de configuración y proceso, que está enlazado a un almacén de recuperación del sitio único. Al usar esta configuración, es posible que tenga que instalar segundas instancias 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 recuperación del sitio 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.

En algunos escenarios, el ancho de banda es limitado. En otros casos, una carga de trabajo implica una configuración o un desfase de datos considerables. En estos casos, la replicación de datos en una segunda región puede interferir con el tiempo necesario para completar la migración. Lo más importante es que estas restricciones pueden afectar a la experiencia de los usuarios o aplicaciones que todavía dependen del ancho de banda que estaba disponible en el centro de datos de origen.

Sincronización de datos: el mayor consumo de ancho de banda a menudo procede de la sincronización de la plataforma de datos. Si implementa en varias zonas de disponibilidad, es posible que pueda usar servicios de datos con redundancia de zona que sincronicen automáticamente los datos en varias zonas de disponibilidad. La implementación en varias regiones suele requerir la sincronización de datos para mantener las aplicaciones alineadas. Este enfoque se define en las arquitecturas de referencia para aplicaciones web de varias regiones y aplicaciones de niveles N de varias regiones.

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. Realice esta sincronización antes de migrar la aplicación y los recursos de nivel intermedio.

Recuperación ante desastres de Azure a Azure: una opción alternativa puede reducir aún más la complejidad. Si usa una implementación en dos pasos para satisfacer las necesidades de sincronización de datos y escala de tiempo, la recuperación ante desastres de Azure a Azure podría ser una solución aceptable. En este escenario, la carga de trabajo se migra al primer centro de datos de Azure con un solo almacén de recuperación del sitio y un diseño de servidor de configuración y 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. La recuperación ante desastres de Azure a Azure también aprovecha las velocidades de transferencia rápida y los límites de ancho de banda elevados 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 a través de mayores cargos de ancho de banda de salida.

Cambios en el proceso de versión

A medida que aborda la complejidad global durante la optimización y la promoción, puede requerir esfuerzos idénticos en cada región en la que se implemente. Si usa una sola región, es posible que tenga que replicar planes de cambio empresarial y pruebas empresariales.

Acciones sugeridas durante el proceso de lanzamiento

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 menores en la red o en el centro de datos de Azure elegidos pueden afectar al rendimiento.

Planes de cambios empresariales: cree un plan de cambio empresarial para cualquier escenario de migración complejo. Una utilización de un plan de cambio empresarial ayuda a garantizar una comunicación clara sobre los cambios en los procesos empresariales y las experiencias de usuario. El plan también ayuda a garantizar una comunicación clara sobre el tiempo de los esfuerzos necesarios 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: cada región también puede requerir pruebas empresariales. Las pruebas empresariales ayudan a garantizar el rendimiento adecuado y el cumplimiento de los patrones de enrutamiento de red modificados.

Paquetes piloto de promoción: la promoción a menudo 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 colecciones predefinidas de usuarios llamadas paquetes piloto. Los paquetes piloto de promoción proporcionan 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. Puede controlar los vuelos de promoción en el nivel de red. En concreto, puede cambiar el enrutamiento de intervalos IP específicos desde los recursos de carga de trabajo de origen a los recursos recién migrados. Una vez que migra una colección especificada de usuarios, puede volver a enrutar el grupo siguiente.

Optimización del paquete piloto: una ventaja de los paquetes piloto de promoción es que le dan 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.