Conectividad de zonas de aterrizaje de datos entre regiones
Si tiene presencia en más de una región Azure y necesita alojar su plataforma de datos y aplicaciones de datos en varias geografías, la conectividad se complica un poco más.
Las implementaciones multirregión suelen tener una suscripción de concentrador de conectividad en cada ubicación individual de Azure. Por ejemplo, si tiene servicios que se ejecutan tanto en el Este de EE. UU. como en el Oeste de Europa, configurará una suscripción de concentrador de conectividad con recursos de red compartidos en cada región. Los recursos de red compartidos incluyen:
- Aplicaciones virtuales de red (como Azure Firewall)
- Puertas de enlace de ExpressRoute
- Puertas de enlace de VPN
- Centros de redes virtuales (en una arquitectura de centro y radio) o centros vWAN (en una configuración vWan)
Figura 1: Conectividad entre regiones.
En la arquitectura hub-spoke-spoke-hub, las redes virtuales de los hubs de conectividad suelen conectarse mediante el emparejamiento de red virtual global. Para entornos más grandes, una alternativa común es utilizar ExpressRoute Global Reach. Sea cual sea la opción de conectividad que elija, puede conseguir un enrutamiento global y conectividad entre redes de radio en múltiples ubicaciones geográficas. Esto significa que puede mover datos entre regiones mediante aplicaciones virtuales de red, grupos de seguridad de red y tablas de rutas, dado que su tráfico no se bloquea en ninguna de las dos suscripciones de conectividad.
Importante
En este artículo y en otros artículos de la sección de redes se describen las unidades de negocio cruzadas que comparten datos. Sin embargo, es posible que esta no sea la estrategia inicial y que tenga que empezar primero en un nivel base.
Diseñe las redes para que, llegado el momento, pueda implementar la configuración recomendada entre zonas de aterrizaje de datos. Asegúrese de que tiene las zonas de aterrizaje de administración de datos conectadas directamente a las zonas de aterrizaje para la gobernanza.
Emparejamiento de red virtual global (recomendado)
Puede conectar zonas de aterrizaje de datos entre regiones utilizando emparejamiento de red virtual global. En esta configuración, si continuamos con nuestro escenario de ejemplo anterior, la máquina virtual del Oeste de Europa accede directamente al punto de conexión privado de la cuenta de almacenamiento de Este de EE. UU., sin depender de ninguna arquitectura de red hub and spoke o vWAN. La máquina virtual carga directamente los datos a través de un punto de conexión privado, los procesa y, a continuación, los vuelve a almacenar en la cuenta de almacenamiento de Oeste de Europa.
Administración del acceso de usuarios en el emparejamiento de red virtual global.
No hay pros ni contras particulares para ninguna de las opciones propuestas de conectividad de zona de aterrizaje de datos entre regiones.
Resumen: 
/
Administración de servicios en emparejamiento de red virtual global.
El emparejamiento de red virtual global no tiene ninguna aplicación virtual de red que actúe como único punto de error o limitación del rendimiento. Los datos no se envían a través de los centros de conectividad, por lo que no es necesario escalar las aplicaciones virtuales y las puertas de enlace dentro de los centros de conectividad. Esta falta de escalado reduce la sobrecarga de administración de su equipo central de la plataforma Azure. Tampoco necesita permitir conexiones individuales entre regiones. Sus equipos de datos pueden acceder a los datos desde zonas de aterrizaje de datos de otras regiones sin tener que esperar cambios en la tabla de rutas.
En este diseño de red, su equipo central de la plataforma Azure ya no puede inspeccionar y registrar todo el tráfico mediante un firewall de capa 7. Sin embargo, el escenario de análisis a escala de la nube es una plataforma coherente que abarca varias suscripciones, lo que permite la escala y supera las limitaciones a nivel de plataforma, por lo que no es una desventaja. Puede capturar registros de red mediante los registros de flujo del grupo de seguridad de red. Puede consolidar y almacenar otros registros de nivel de aplicación y servicio mediante la Configuración de diagnóstico específica de cada servicio.
Puede capturar todos estos registros a gran escala mediante las definiciones de Azure Policy para la configuración de diagnóstico.
En algunos escenarios, es necesario limitar debido a las implicaciones reglamentarias o legales. Por ejemplo, puede que tenga una normativa local que exija que determinados conjuntos de datos permanezcan dentro de un centro de datos determinado, por lo que no se le permite transferirlos entre regiones. Puede confiar en los grupos de seguridad de red para que le ayuden a cumplir este tipo de normas, permitiendo que el tráfico se mueva solo en una dirección, desde el Este de EE. UU. al Oeste de Europa, y no al revés. Dentro de sus grupos de seguridad de red, puede asegurarse de que el tráfico procedente del Este de EE.UU. está denegado mientras que el tráfico procedente del Oeste de Europa está permitido.
Este enfoque de solución no afecta al ancho de banda ni a la latencia, y permite a los clientes seguir cumpliendo la normativa sin dejar de combinar conjuntos de datos de varias regiones. Esta opción tampoco afecta a su arquitectura DNS y le permite utilizar una solución nativa de Azure basada en Azure Private DNS Zones.
Resumen:
Coste del emparejamiento de red virtual global
Nota
Al acceder a un punto de conexión privado en una red emparejada, solo se le cobrará por el propio punto de conexión privado, no por el emparejamiento de VNet. Puede leer la declaración oficial en P+F: ¿Cómo funcionará la facturación cuando se acceda a un punto de conexión privado desde una red emparejada?.
Con este diseño de red, se le cobra por sus puntos de conexión privados (por hora) y por todo el tráfico de entrada y salida que se envía a través de ellos. También tiene que pagar un coste de transferencia de datos por el tráfico entre regiones. Sin embargo, NO se le cobrará ningún coste de entrada y salida de emparejamiento de red virtual global. Por este motivo, la opción de emparejamiento de red virtual global presenta notables ventajas en cuanto a costes respecto a la opción tradicional spoke-hub-hub-spoke que se describe más adelante en este artículo.
Resumen:
Ancho de banda y latencia en emparejamiento de red virtual global
El impacto sobre el ancho de banda y la latencia es mucho menor en emparejamiento de red virtual global que en la opción tradicional spoke-hub-hub-spoke. El emparejamiento de red virtual global contiene un menor número de saltos para el intercambio de datos entre zonas de aterrizaje de datos entre regiones y no tiene aplicaciones virtuales de red que limiten el rendimiento. Lo único que dicta el ancho de banda y la latencia que puede conseguir para el tráfico entre regiones son los límites físicos de nuestros centros de datos (velocidad de los cables de fibra óptica, puerta de enlace y routers).
Resumen:
Resumen del emparejamiento de red virtual global
El emparejamiento de red virtual global entre zonas de aterrizaje de datos de distintas regiones ofrece enormes ventajas, especialmente a medida que aumenta el tráfico de datos entre regiones dentro de su plataforma de datos. Simplifica la administración de servicios para su equipo central de la plataforma Azure, y beneficia especialmente a los casos de uso que requieren baja latencia y gran ancho de banda. También ofrece importantes ventajas de costes en comparación con la opción de diseño tradicional de radio-hub-hub-espiga.
Diseño tradicional spoke-hub-hub-spoke (no recomendado)
Su otra opción para las transferencias de datos entre regiones es el diseño tradicional spoke-hub-hub-spoke. En nuestro escenario de ejemplo, si una máquina virtual en la zona de aterrizaje de datos A alojada en el Oeste de Europa carga un conjunto de datos almacenado en una cuenta de almacenamiento de la zona de aterrizaje de datos B alojada en el Este de EE.UU., los datos atraviesan dos emparejamiento de red virtual locales (conectividad entre hub y radios), un emparejamiento de red virtual global (conectividad entre hubs) y dos Gateways o dispositivos virtuales de red antes de ser cargados por la máquina virtual y luego trasladados de nuevo a la cuenta de almacenamiento local.
Administración del acceso de usuarios en el diseño tradicional de spoke-hub-hub-spoke
No hay pros ni contras particulares para ninguna de las opciones propuestas de conectividad de zona de aterrizaje de datos entre regiones.
Resumen:
/
Administración de servicios en el diseño tradicional de spoke-hub-hub-spoke
Este enfoque de solución es bien conocido y coherente con otros patrones de conectividad entre regiones, lo que facilita su adopción y aplicación. Además, no afecta a la arquitectura DNS y permite utilizar una solución nativa de Azure basada en Azure Private DNS Zones.
Aunque esta opción de conectividad funciona a la perfección si se configura correctamente, tiene sus desventajas. El tráfico entre regiones suele denegarse de manera predeterminada y debe habilitarse caso por caso. Esto significa que hay que enviar una solicitud al equipo central de la plataforma Azure para cada requisito de acceso a datos entre regiones para que el equipo pueda permitir cada conexión específica entre una máquina virtual y una cuenta de almacenamiento entre regiones. Este proceso aumenta significativamente la sobrecarga de administración. También ralentiza sus equipos de proyectos de datos, ya que no pueden acceder a los datos que necesitan.
También debe tener en cuenta que, en esta opción, los concentradores de conectividad actúan como únicos puntos de error. En caso de inactividad de la aplicación virtual de red o de la puerta de enlace, fallan la conectividad y las plataformas de datos correspondientes. También existe un alto riesgo de que se configuren mal las rutas en los concentradores de conectividad. Esta mala configuración puede causar un tiempo de inactividad más grave en su plataforma de datos y provocar una serie de errores en el flujo de trabajo dependiente y en los productos de datos.
Debe supervisar la cantidad de datos que necesita transferir entre regiones mientras utiliza este enfoque de solución. Con el tiempo, esta supervisión puede implicar gigabytes o terabytes de datos que se mueven a través de sus instancias centrales. Dado que el ancho de banda de las aplicaciones virtuales de red suele limitarse a un rendimiento de uno o dos gigabytes, las aplicaciones pueden actuar como un cuello de botella crítico que limite el flujo de tráfico entre regiones y la compartibilidad de sus activos de datos. Debido a esto, sus recursos de red compartidos pueden requerir mecanismos de escalado, que a menudo son lentos y costosos, y pueden afectar a otras cargas de trabajo de su inquilino.
Resumen:
Coste del diseño tradicional spoke-hub-hub-spoke
Nota
Al acceder a un punto de conexión privado en una red emparejada, solo se le cobrará por el propio punto de conexión privado, no por el emparejamiento de VNet. Puede leer la declaración oficial en P+F: ¿Cómo funcionará la facturación cuando se acceda a un punto de conexión privado desde una red emparejada?.
En el diseño tradicional spoke-hub-hub-spoke, se le cobran los puntos de conexión privados de sus dos cuentas de almacenamiento (por hora) y todo el tráfico de entrada y salida que se envía a través de ellos. También se le cobra por el tráfico de entrada y salida de un emparejamiento de red virtual local y el emparejamiento de red virtual global entre sus concentradores de conectividad. Sin embargo, no se le cobrará por el primer emparejamiento de red virtual, como explicamos en la nota anterior.
Sus aplicaciones virtuales de red central también supondrán un coste significativo si elige este diseño de red. Esto se debe a que, o bien tiene que adquirir licencias adicionales para escalar los dispositivos en función de la demanda, o bien tiene que pagar el cargo por gigabyte procesado, como ocurre con Azure Firewall.
Resumen:
Ancho de banda y latencia en el diseño tradicional spoke-hub-hub-spoke
Este diseño de red tiene limitaciones graves de ancho de banda. Sus aplicaciones virtuales de red central se convierten en cuellos de botella críticos a medida que crece su plataforma, lo que limita los casos de uso de zonas de aterrizaje de datos entre regiones y el uso compartido de sus conjuntos de datos. También hace probable que se creen múltiples copias de sus conjuntos de datos a lo largo del tiempo. Este diseño también afecta en gran medida a la latencia, que es especialmente crítica para los escenarios de análisis en tiempo real, ya que sus datos atraviesan muchos saltos.
Resumen:
Resumen del diseño tradicional spoke-hub-hub-spoke
El diseño spoke-hub-hub-spoke es bien conocido y está establecido en muchas organizaciones, lo que facilita su implantación en un entorno existente. Sin embargo, presenta desventajas significativas en cuanto a administración de servicios, costes, ancho de banda y latencia. Estos problemas son especialmente evidentes a medida que aumenta el número de casos de uso interregional.
Conclusión
Emparejamiento de red virtual global tiene muchas ventajas sobre el diseño tradicional spoke-hub-hub-spoke, ya que es rentable, fácil de administrar y ofrece una conectividad fiable entre regiones. Aunque el diseño tradicional spoke-hub-hub-spoke puede ser una opción viable mientras su volumen de datos y la necesidad de intercambio de datos entre regiones sea baja, le recomendamos que utilice el enfoque emparejamiento de red virtual global a medida que aumente la cantidad de datos que necesite intercambiar entre regiones.