Conectividad de zona de aterrizaje de datos entre regiones
Si tiene presencia en más de una región de Azure y necesita hospedar la plataforma de datos y las aplicaciones de datos en varias zonas geográficas, la conectividad se complica ligeramente.
Las implementaciones de varias regiones suelen tener una suscripción del centro de conectividad en cada ubicación de Azure individual. Por ejemplo, si tiene servicios que se ejecutan en Este de EE. UU. y Oeste de Europa, configure una suscripción del centro de conectividad con recursos de red compartidos en cada región. Entre los recursos de red compartidos se 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 radial) 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 centros de conectividad a menudo se conectan mediante el emparejamiento global de redes virtuales. Para entornos más grandes, una alternativa común es usar Global Reach de ExpressRoute. La opción de conectividad que elija, puede lograr el enrutamiento global y la conectividad entre redes de radio en varias zonas 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 el tráfico no se bloquea en ninguna suscripción de conectividad.
Importante
En este artículo y otros artículos de la sección redes se describen las unidades de negocio cruzadas que comparten datos. Sin embargo, es posible que no sea la estrategia inicial y que tenga que empezar primero en un nivel base.
Diseñe su red de redes de manera que eventualmente pueda implementar nuestra configuración recomendada entre las zonas de recepción de datos. Asegúrese de que tiene las zonas de aterrizaje para la gestió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 mediante el emparejamiento global directo de redes virtuales. En esta configuración, si continuamos nuestro escenario de ejemplo anterior, la máquina virtual en Europa Occidental accede directamente al punto de conexión privado de la cuenta de almacenamiento en el Este de EE. UU., sin depender de ninguna arquitectura de red tipo hub-and-spoke o vWAN. La máquina virtual carga directamente los datos a través de un punto de conexión privado, se procesa y, a continuación, se almacena de nuevo en la cuenta de almacenamiento de Oeste de Europa.
Administración del acceso de usuarios en emparejamiento de red virtual global
No hay ventajas o desventajas particulares para cualquiera 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 un único punto de error o de límite del rendimiento. Los datos no se envían a través de los centros de conectividad, por lo que no es necesario escalar las puertas de enlace y las aplicaciones virtuales dentro de los centros de conectividad. Esta falta de escalado reduce la sobrecarga de administración del equipo principal de la plataforma De Azure. Tampoco es necesario permitir las conexiones individuales entre regiones. Los equipos de datos pueden acceder a datos desde zonas de aterrizaje de datos en otras regiones sin tener que esperar a cambios en la tabla de rutas.
En este diseño de red, el equipo de la plataforma central de Azure ya no puede inspeccionar y registrar todo el tráfico mediante un firewall de nivel 7. Sin embargo, el escenario de análisis a escala en la nube es una plataforma coherente que abarca varias suscripciones, lo que permite escalar y superar las limitaciones de nivel de plataforma, por lo que no es una desventaja. Puede capturar registros de red mediante registros de flujo del grupo de seguridad de red. Puede consolidar y almacenar otros registros de nivel de servicio y de aplicación mediante la configuración de diagnóstico específica del 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, debe limitarse debido a implicaciones legales o normativas. Por ejemplo, puede tener una regulación local que requiera que determinados conjuntos de datos permanezcan dentro de un centro de datos de partículas, por lo que no podrá transferirlos entre regiones. Puede confiar en los grupos de seguridad de red para ayudarle a cumplir este tipo de regla, solo permitiendo que el tráfico se mueva en una dirección de Este de EE. UU. a Oeste de Europa y no viceversa. Dentro de los grupos de seguridad de red, puede asegurarse de que se deniega el tráfico procedente de Este de EE. UU. mientras se permite el tráfico procedente de Oeste de Europa.
Este enfoque de solución no afecta al ancho de banda y la latencia, y permite a los clientes seguir siendo compatibles mientras se combinan conjuntos de datos de varias regiones. Esta opción tampoco afecta a la arquitectura DNS y le permite usar una solución nativa de Azure basada en zonas DNS privadas de Azure.
Resumen:
Coste de 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 FAQ: ¿Cómo funcionará la facturación cuando se accede a un punto de conexión privado desde una red emparejada?.
Con este diseño de red, se le cobra por los puntos de conexión privados (por hora) y todo el tráfico de entrada y salida enviado 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 costo de entrada y salida de emparejamiento de red virtual global y tiene importantes ventajas de costo en comparación con la opción tradicional spoke-hub-hub-spoke.
Resumen:
Ancho de banda y latencia en emparejamiento de red virtual global
El impacto sobre el ancho de banda y la latencia es menor en emparejamiento de red virtual global que en la opción tradicional spoke-hub-hub-spoke. El emparejamiento global de redes virtuales reduce el número de saltos para el intercambio de datos entre regiones en la zona de recepción de datos y no tiene aplicaciones virtuales de red que limiten el rendimiento. Las únicas cosas que dictan el ancho de banda y la latencia que puede lograr para el tráfico entre regiones son los límites físicos de nuestros centros de datos (velocidad de cables de fibra óptica, puertas de enlace y enrutadores).
Resumen:
Resumen de 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 el equipo principal de la plataforma Azure y, especialmente, los casos de uso que requieren baja latencia y ancho de banda alto. También ofrece importantes ventajas de costes en comparación con la opción de diseño tradicional spoke-hub-hub-spoke.
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 de la zona de aterrizaje de datos A, hospedada en Europa Occidental, carga un conjunto de datos almacenado en una cuenta de almacenamiento de la zona de aterrizaje de datos B, hospedada en el Este de los EE. UU., los datos atraviesan dos emparejamientos de red virtual locales (conectividad entre concentradores y radios), un emparejamiento de red global (conectividad entre centros) y dos puertas de enlace o aplicaciones virtuales de red antes de ser cargados por la máquina virtual y, a continuación, se mueven de nuevo a la cuenta de almacenamiento local.
Administración del acceso de usuarios en el diseño tradicional spoke-hub-hub-spoke
No hay ventajas o desventajas particulares para cualquiera de las opciones propuestas de conectividad de zona de aterrizaje de datos entre regiones.
Resumen: /
Administración de servicios en el diseño tradicional spoke-hub-hub-spoke
Este enfoque de solución es conocido y coherente con otros patrones de conectividad entre regiones, lo que facilita la adopción e implementación. También no tiene ningún impacto en la arquitectura DNS y le permite usar una solución nativa de Azure basada en zonas DNS privadas de Azure.
Aunque esta opción de conectividad funciona sin problemas si la configura correctamente, tiene desventajas. El tráfico entre regiones a menudo se deniega de forma predeterminada y tiene que habilitarse en cada caso. Un ticket debe enviarse al equipo central de la plataforma Azure por cada requerimiento de acceso a datos entre regiones, para que el equipo pueda autorizar cada conexión específica entre una máquina virtual y una cuenta de almacenamiento en otra región. Este proceso aumenta significativamente la sobrecarga de administración. También ralentiza los equipos del proyecto de datos, ya que no pueden acceder a los datos que necesitan.
También debe tener en cuenta que en esta opción, los centros de conectividad actúan como puntos únicos 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 tiene un alto riesgo de mal configurar rutas en los centros de conectividad. Esta configuración incorrecta puede provocar un tiempo de inactividad más grave en la plataforma de datos y provocar una serie de errores de producto de datos y flujo de trabajo dependientes.
Debe supervisar la cantidad de datos que necesita transferir entre regiones al usar 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 las instancias centrales. Dado que el ancho de banda de las aplicaciones virtuales de red se limita a menudo a un rendimiento de gigabytes de uno o dos dígitos, los dispositivos pueden actuar como un cuello de botella crítico que limita el flujo de tráfico entre regiones y la capacidad de uso compartido de los recursos de datos. Debido a este cuello de botella, los recursos de red compartidos pueden requerir mecanismos de escalado, que a menudo consumen mucho tiempo y son costosos, y pueden afectar a otras cargas de trabajo del 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 el comunicado oficial en Preguntas Frecuentes: ¿Cómo funcionará la facturación al acceder 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.
Las aplicaciones virtuales de red central también incurren en costos significativos si elige este diseño de red. Este costo se debe a que tiene que comprar licencias adicionales para escalar los dispositivos en función de la demanda o pagar el cargo por gigabyte procesado, como 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. Los dispositivos virtuales de red central se convierten en cuellos de botella críticos a medida que crece tu plataforma, lo que limita los casos de uso de zonas de recepción de datos entre regiones y el uso compartido de tus conjuntos de datos. También es probable que se creen varias copias de los conjuntos de datos a lo largo del tiempo. Este diseño también afecta en gran medida a la latencia, que es especialmente fundamental para escenarios de análisis en tiempo real, ya que los datos atraviesan muchos saltos.
Resumen:
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, tiene desventajas significativas para la administración de servicios, el costo, el ancho de banda y la latencia. Estos problemas son especialmente perceptibles a medida que crece el número de casos de uso entre regiones.
Conclusión
El 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.