Conectividad de la zona de aterrizaje de datos de una sola región

La zona de aterrizaje de administración de datos, las zonas de aterrizaje de datos y todos los servicios dentro de ellas se configuran en la misma región, si se trata de una configuración de una sola región. Todas las zonas de aterrizaje están dentro de la misma suscripción del centro de conectividad. Esta suscripción hospeda recursos de red compartidos, que pueden incluir una aplicación virtual de red (como Azure Firewall), una puerta de enlace de ExpressRoute, una puerta de enlace de red privada virtual (VPN), una red virtual de centro de conectividad o una WAN virtual (centro de vWAN).

Figura 1: Conectividad de una sola región.

En función de las capacidades actuales de los Servicios de redes de Azure, se recomienda usar una arquitectura de red en malla. Debería configurar el emparejamiento de Vnet entre:

• El Centro de conectividad y la Zona de administración de datos
• El Centro de conectividad y cada Zona de aterrizaje de datos
• La Zona de administración de datos y cada Zona de aterrizaje de datos
• Cada Zona de aterrizaje de datos

En este artículo se describen las ventajas y desventajas de cada opción de arquitectura de red que hemos considerado para el análisis a escala de la nube.

La primera sección de este artículo se centra en un patrón de una sola región, donde la Zona de administración de datos y todas las Zonas de aterrizaje de datos se hospedan en la misma región.

Cada patrón de diseño se evalúa con los siguientes criterios:

• Coste
• Administración de acceso de usuario
• Administración de servicios
• Ancho de banda
• Latencia

Analizaremos cada opción de diseño, teniendo en cuenta el siguiente caso de uso de la zona de aterrizaje entre datos:

Nota

La máquina virtual B (VM B), hospedada en la zona de aterrizaje de datos B, carga un conjunto de datos de la cuenta de almacenamiento A hospedada en la zona de aterrizaje de datos A. Después, la VM B procesa el conjunto de datos y lo almacena en la Cuenta de almacenamiento B, que está hospedada en la zona de aterrizaje de datos B.

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.

Arquitectura de red en malla (recomendado)

Se recomienda usar una arquitectura de malla de red al adoptar el análisis a escala de la nube. Además del diseño de red en estrella tipo hub-and-spoke, que ya está configurado en el inquilino, debe hacer dos cosas para implementar una arquitectura de malla de red:

• Agregue emparejamientos de Vnet entre todas las Vnet de zonas de aterrizaje de datos.
• Agregue emparejamientos de Vnet entre la zona de aterrizaje de administración de datos y todas las zonas de aterrizaje de datos.

En nuestro escenario de ejemplo, los datos cargados desde la Cuenta de almacenamiento A transitan una conexión de emparejamiento de Vnet (2) configurada entre las dos Vnet de las zonas de aterrizaje de datos. Se carga y procesa mediante la VM B ((3) y (4)), y después se envía a través del Punto de conexión privado local (5), para que se almacene en la Cuenta de almacenamiento B.

En este escenario, los datos no pasan por el Centro de conectividad. Permanecen dentro de la Plataforma de datos, que consta de una zona de aterrizaje de administración de datos y una o varias zonas de aterrizaje de datos.

Figura 2: Arquitectura de red en malla.

Administración del acceso de usuario en la arquitectura de red en malla

En un diseño de arquitectura de red en malla, los equipos de aplicaciones de datos solo necesitan dos cosas para poder crear nuevos servicios (incluidos los Puntos de conexión privados):

• Acceso de escritura a su grupo de recursos dedicado en la zona de aterrizaje de datos
• Unión del acceso a su subred designada

En este diseño, los equipos de aplicaciones de datos pueden, por sí mismos, implementar los Puntos de conexión privados. Siempre que tengan los derechos de acceso necesarios para conectar Puntos de conexión privados a una subred en un radio determinado, los equipos no necesitan asistencia al configurar la conectividad necesaria.

Resumen:

Administración de servicios en la arquitectura de red en malla

En un diseño de arquitectura de red en malla, ninguna aplicación virtual de red actúa como un único punto de error o limitación. La falta de conjuntos de datos que se envían a través del Centro de conectividad reduce la sobrecarga del equipo central de la plataforma de Azure, siempre que no sea necesario escalar horizontalmente esa aplicación virtual.

Esto tiene la implicación de que el equipo central de la plataforma de Azure ya no puede inspeccionar y registrar todo el tráfico que se envía entre las zonas de aterrizaje de datos. Sin embargo, el análisis a escala de la nube es una plataforma coherente que abarca varias suscripciones, lo que permite escalar y superar las limitaciones a nivel de plataforma, por lo que no es una desventaja.

A esto se suma que, con todos los recursos hospedados en una sola suscripción, el equipo central de la plataforma de Azure ya no inspecciona todos los datos del Centro de conectividad central. Todavía puede capturar registros de red mediante el Grupo de seguridad de red Registros de flujo. 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.

Este diseño también permite crear una solución DNS nativa de Azure, basada en Zonas DNS privadas. Puede automatizar el ciclo de vida de los registros D de DNS, a través de las definiciones de Azure Policy para grupos DNS privados.

Resumen:

Costo de la arquitectura de red en malla

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 este diseño de red, solo paga por:

• Los Puntos de conexión privados (por hora)
• El tráfico de entrada y salida, enviado a través de los Puntos de conexión privados, para cargar el conjunto de datos sin procesar (1) y almacenar el conjunto de datos procesado (6)

El emparejamiento de Vnet no se cobrará (2), por lo que esta opción tiene un coste mínimo.

Resumen:

Ancho de banda y latencia en una arquitectura de red en malla

Este diseño no tiene limitaciones de ancho de banda o latencia, porque ninguna aplicación virtual de red limita el rendimiento para su intercambio de datos de zona de aterrizaje entre datos. El único factor de limitación del diseño es el límite físico de nuestros centros de datos (la velocidad de los cables de fibra óptica).

Resumen:

Resumen de la arquitectura de red en malla

Si planea adoptar análisis a escala de la nube, se recomienda usar el diseño de red en malla. Una red en malla ofrece un ancho de banda máximo y una baja latencia a un coste mínimo, pero sin poner en peligro la administración del acceso de los usuarios o la capa DNS.

Si necesita aplicar otras directivas de red dentro de la plataforma de datos, use Grupos de seguridad de red en lugar de aplicaciones virtuales de red central.

Arquitectura tradicional en estrella tipo hub-and-spoke (no recomendada)

El diseño de la arquitectura de red en estrella tipo hub-and-spoke es la opción más obvia y muchas empresas la han elegido. En esta opción, la transitividad de red se configura en el Centro de conectividad para acceder a los datos de la Cuenta de almacenamiento A desde la VM B. Los datos recorren dos emparejamientos de Vnet ((2) y (5)) y una aplicación virtual de red, hospedada dentro del Centro de conectividad ((3) y (4)). Después, la máquina virtual (6) carga los datos, que se almacenan de nuevo en la Cuenta de almacenamiento B (8).

Figura 3: Arquitectura en estrella tipo hub-and-spoke.

Administración del acceso de usuarios en la arquitectura tradicional en estrella tipo hub-and-spoke

En un diseño tradicional en estrella tipo hub-and-spoke, los equipos de aplicaciones de datos solo necesitan dos cosas para poder crear nuevos servicios (incluidos los Puntos de conexión privados):

• Acceso de escritura a su grupo de recursos en la zona de aterrizaje de datos
• Unión del acceso a su subred designada

En este diseño, los equipos de aplicaciones de datos pueden, por sí mismos, implementar los Puntos de conexión privados. Siempre que tengan los derechos de acceso necesarios para conectar Puntos de conexión privados a una subred en un radio determinado, los equipos no necesitan asistencia al configurar la conectividad necesaria.

Resumen:

Administración de servicios en la arquitectura tradicional en estrella tipo hub-and-spoke

Este diseño de red es bien conocido y coherente con la configuración de red existente de la mayoría de las organizaciones. Esto facilita la explicación e implementación del diseño. También puede usar una solución DNS centralizada y nativa de Azure, con zonas DNS privadas para proporcionar la resolución FQDN dentro del inquilino de Azure. El uso de Zonas DNS privadas le permite automatizar el ciclo de vida de los registros D de DNS, a través de las Directivas de Azure.

Otra ventaja de este diseño es que el tráfico se enruta mediante una aplicación virtual de red central, por lo que el tráfico de red que se envía de un radio a otro se puede registrar e inspeccionar.

Una desventaja de este diseño es que el equipo central de la plataforma de Azure tiene que administrar manualmente las Tablas de rutas. Esto es necesario para garantizar la transitividad entre radios, lo que permite el uso compartido de recursos de datos en varias zonas de aterrizaje de datos. La administración de rutas puede volverse compleja y propensa a errores con el tiempo y debe pensarse bien desde el principio.

Otra desventaja de esta configuración de red es la forma en que se configura la aplicación virtual de red central. La aplicación virtual de red actúa como un único punto de error, y puede provocar un tiempo de inactividad grave dentro de la plataforma de datos si se produce un error. Además, a medida que los tamaños del conjunto de datos crezcan dentro de la plataforma de datos, y a medida que suba el número de casos de uso de las zonas de aterrizaje entre datos, se enviará más tráfico a través de la aplicación virtual de red central.

Con el tiempo, esto puede dar lugar a gigabytes o incluso terabytes de datos enviándose a través de la instancia central. Dado que el ancho de banda de las aplicaciones virtuales de red existentes suele limitarse a un rendimiento de gigabytes de uno o dos dígitos, la aplicación virtual de red central puede convertirse en un cuello de botella, que limita críticamente el flujo de tráfico entre las zonas de aterrizaje de datos, y limita la capacidad de uso compartido de recursos de datos.

La única manera de evitar este problema es escalar horizontalmente la aplicación virtual de red central en varias instancias, lo que tiene importantes implicaciones de coste para este diseño.

Resumen:

Coste de la arquitectura tradicional en estrella tipo hub-and-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?.

Para esta red, se le cobra por hora por los Puntos de conexión privados de las cuentas de almacenamiento. También se le cobra por el tráfico de entrada y salida, enviado a través de los Puntos de conexión privados, para cargar un conjunto de datos sin procesar (1) y almacenar el conjunto de datos procesado (8).

Se le cobrará a su cliente por la entrada y salida de un emparejamiento de Vnet (5). Como se mencionó anteriormente, el primer emparejamiento de Vnet no se cobra (2).

Terminará con un alto coste para la aplicación virtual de red central si usa este diseño de red ((3) y (4)). Tiene que comprar licencias adicionales y escalar horizontalmente la aplicación virtual de red central en función de la demanda, o pagar el cargo procesado por gigabyte, como ya se hace con Azure Firewall.

Resumen:

Ancho de banda y latencia en la arquitectura tradicional en estrella tipo hub-and-spoke

Este diseño de red tiene limitaciones graves de ancho de banda. La aplicación virtual de red central se convierte en un cuello de botella crítico a medida que crece la plataforma, lo que limita los casos de uso de las zonas de aterrizaje entre datos y el uso compartido de conjuntos de datos. También es probable que cree varias copias de conjuntos de datos a lo largo del tiempo.

Este diseño también afecta en gran medida a la latencia, lo que resulta especialmente crítico en escenarios de análisis en tiempo real.

Resumen:

Resumen de la arquitectura tradicional en estrella tipo hub-and-spoke

Este diseño de red en estrella tipo hub-and-spoke tiene ventajas de administración de acceso y algunas ventajas de administración de servicios, pero debido a limitaciones críticas de la administración de servicios, del ancho de banda y de la latencia, no se puede recomendar este diseño de red para casos de uso de las zonas de aterrizaje entre datos.

Arquitectura de proyección de Punto de conexión privado (no recomendada)

Otra opción de diseño es la proyección de Puntos de conexión privados en cada una de las zonas de aterrizaje. En este diseño, se crea un Punto de conexión privado para la Cuenta de almacenamiento A en cada zona de aterrizaje. Esto lleva a un primer Punto de conexión privado en la zona de aterrizaje de datos A, conectado a la Vnet de la zona de aterrizaje de datos A, un segundo Punto de conexión privado conectado a la Vnet de la zona de aterrizaje de datos B, y así sucesivamente.

Lo mismo se aplica a la Cuenta de almacenamiento B, y posiblemente a otros servicios dentro de las zonas de aterrizaje de datos. Si definimos el número de zonas de aterrizaje de datos como n, terminamos con n Puntos de conexión privados para, como mínimo, todas las cuentas de almacenamiento y también, potencialmente, para otros servicios dentro de las zonas de aterrizaje de datos. Esto lleva a un aumento exponencial del número de Puntos de conexión privados.

Figura 4: arquitectura de proyección de Punto de conexión privado.

Dado que todos los Puntos de conexión privados de un servicio determinado (por ejemplo, la Cuenta de almacenamiento A) tienen el mismo FQDN (como storageaccounta.privatelink.blob.core.windows.net), esta solución crea desafíos en la capa DNS, que no se pueden resolver con Zonas DNS privadas. En su lugar, necesita una solución DNS personalizada, capaz de resolver nombres DNS en función del origen o la dirección IP del solicitante. Esto le permite hacer que VMA se conecte a los Puntos de conexión privados conectados a la Vnet en la zona de aterrizaje de datos A, y que la VM B se conecte a los Puntos de conexión privados conectados a la Vnet en la zona de aterrizaje de datos B. Puede hacerlo con una configuración basada en servidores de Windows, mientras que puede automatizar el ciclo de vida de registros D de DNS a través de una combinación de Registro de actividad y Azure Functions.

En esta configuración, puede cargar el conjunto de datos sin procesar de la Cuenta de almacenamiento A en la VM B, accediendo al conjunto de datos mediante el Punto de conexión privado local (1). Después de cargar y procesar el conjunto de datos ((2) y (3)), puede almacenarlo en la Cuenta de almacenamiento B accediendo directamente al Punto de conexión privado local (4). En este escenario, los datos no deben recorrer ningún emparejamiento de Vnet.

Administración del acceso de usuarios en la arquitectura de proyección de punto de conexión privado

Este enfoque de diseño para la administración del acceso de los usuarios es similar al de la arquitectura de red en malla. Sin embargo, en este diseño, puede requerir derechos de acceso para otras zonas de aterrizaje de datos, para crear Puntos de conexión privados, no solo dentro de una zona de aterrizaje de datos designada y una Vnet, sino también en otras zonas de aterrizaje de datos y sus respectivas Vnet.

Por este motivo, los equipos de aplicaciones de datos requieren tres cosas, no dos, para poder crear nuevos servicios:

• Acceso de escritura a un grupo de recursos en una zona de aterrizaje de datos designada
• Unión del acceso a su subred designada
• Acceso a un grupo de recursos y una subred dentro de todas las demás zonas de aterrizaje de datos, para crear sus respectivos Puntos de conexión privados locales

Este diseño de red aumenta la complejidad de la capa de administración de acceso, ya que los equipos de aplicaciones de datos requieren permisos en cada zona única de aterrizaje de datos. El diseño también puede resultar confuso y dar lugar a un RBAC incoherente a lo largo del tiempo.

Si a los equipos de la zona de aterrizaje de datos y a los equipos de aplicaciones de datos no se les conceden los derechos de acceso necesarios, se producirán los problemas descritos en la arquitectura tradicional en estrella tipo hub-and-spoke (no recomendada).

Resumen:

Administración de servicios en la arquitectura de proyección de punto de conexión privado

Aunque de nuevo es similar al diseño de la arquitectura de red en malla, este diseño de red tiene la ventaja de que ninguna aplicación virtual de red actúe como un único punto de error o rendimiento de limitación. También reduce la sobrecarga de administración para el equipo central de la plataforma de Azure, al no enviar conjuntos de datos a través del Centro de conectividad, ya que no es necesario escalar horizontalmente la aplicación virtual. Esto tiene la implicación de que el equipo central de la plataforma de Azure ya no puede inspeccionar y registrar todo el tráfico que se envía entre las zonas de aterrizaje de datos. Sin embargo, el análisis a escala de la nube es una plataforma coherente que abarca varias suscripciones, lo que permite escalar y superar las limitaciones a nivel de plataforma, por lo que no es una desventaja.

Con todos los recursos hospedados en una suscripción única, el tráfico no se inspecciona en el Centro de conectividad central. Los registros de red todavía se pueden capturar mediante el uso de Registros de flujo de Grupos de seguridad de red, y puede consolidar y almacenar otros registros de nivel de servicio y de aplicación, mediante la Configuración de diagnóstico específica de cada servicio. Puede capturar todos estos registros a gran escala usando Directivas de Azure. Por otro lado, el espacio de direcciones de red requerido por la plataforma de datos aumenta, debido al aumento exponencial en los Puntos de conexión privados necesarios, lo que no es óptimo.

Las principales preocupaciones relacionadas con esta arquitectura de red son sus desafíos de DNS mencionados anteriormente. No se puede usar una solución nativa de Azure en forma de Zonas DNS privadas, por lo que esta arquitectura requiere una solución de terceros capaz de resolver FQDNS en función del origen o la dirección IP del solicitante. También tiene que desarrollar y mantener herramientas y flujos de trabajo para automatizar registros D de DNS privados, lo que aumenta drásticamente la sobrecarga de administración, en comparación con la propuesta de solución controlada por Azure Policy.

Puede crear una infraestructura DNS distribuida mediante Zonas DNS privadas, pero esto crea islas DNS, lo que, en última instancia, provoca problemas al intentar acceder a los servicios de vínculo privado hospedados en otras zonas de aterrizaje del inquilino. Por lo tanto, este diseño no es una opción viable.

Resumen:

Coste de la arquitectura de proyección de punto de conexión privado

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 este diseño de red, solo se le cobra por los Puntos de conexión privados (por hora) y por el tráfico de entrada y salida, enviado a través de esos Puntos de conexión privados, para cargar conjuntos de datos sin procesar (1) y almacenar conjuntos de datos procesados (4). Sin embargo, se deben esperar costes adicionales, debido al aumento exponencial del número de Puntos de conexión privados de la plataforma de datos. Dado que se le cobra por hora, la cantidad de coste adicional depende en gran medida del número de Puntos de conexión privados que se crean.

Resumen:

Ancho de banda y latencia en la arquitectura de proyección de punto de conexión privado

Este diseño no tiene limitaciones de ancho de banda y latencia, porque no tiene ninguna aplicación virtual de red limitando el rendimiento del intercambio de datos de zona de aterrizaje entre datos. El único factor de limitación del diseño es el límite físico de nuestros centros de datos (la velocidad de los cables de fibra óptica).

Resumen:

Resumen de la arquitectura de proyección de punto de conexión privado

El crecimiento exponencial de los Puntos de conexión privados en esta arquitectura de red puede hacer que pierda el propósito o la ubicación de determinados Puntos de conexión privados. También está limitado por problemas de administración de acceso y complejidades de la capa DNS. Debido a estos problemas, no se puede recomendar este diseño de red para casos de uso de zonas de aterrizaje entre datos.

Puntos de conexión privados en la arquitectura del Centro de conectividad (opción no recomendada)

Otra opción de red es hospedar Puntos de conexión privados en el Centro de conectividad y conectarlos a la Vnet de dicho centro. En esta solución, hospedará un único Punto de conexión privado para cada servicio de la Vnet corporativa. La transitividad no es necesaria, ya que en la mayoría de las empresas la arquitectura de red es de estrella tipo hub-and-spoke. Además, en esta solución, el Centro de conectividad hospeda los Puntos de conexión privados. El emparejamiento de Vnet entre el Centro de conectividad y las zonas de aterrizaje de datos permite un acceso directo.

Los datos recorren un único emparejamiento de Vnet, entre el Centro de conectividad y la zona de aterrizaje de datos, para cargar un conjunto de datos almacenado de la Cuenta de almacenamiento A en la VM B. Una vez que ese conjunto de datos se carga y procesa ((3) y (4)), recorre el mismo emparejamiento de Vnet una segunda vez (5), antes de almacenarse definitivamente en la Cuenta de almacenamiento B, a través del Punto de conexión privado conectado a la Vnet del Centro de conectividad (6).

Figura 5: Puntos de conexión privados en la arquitectura del Centro de conectividad.

Administración del acceso de usuarios en la arquitectura del Centro de conectividad

En este diseño de red, los equipos de la zona de aterrizaje de datos y los equipos de aplicaciones de datos necesitan dos cosas para poder conectar Puntos de conexión privados a la Vnet del Centro de conectividad:

• Permisos de escritura en un grupo de recursos en la suscripción del Centro de conectividad
• Permisos de unión a la Vnet del Centro de conectividad

El Centro de conectividad está designado para el equipo de la plataforma de Azure de su organización, y está dedicado a hospedar la infraestructura de red necesaria y compartida de la organización (incluidos firewalls, puertas de enlace y herramientas de administración de red). Esta opción de red hace que el diseño sea incoherente, ya que no sigue los principios de administración de acceso de los principios base de las Zonas de aterrizaje a escala empresarial. Por lo tanto, la mayoría de los equipos de la plataforma Azure no aprobarán esta opción de diseño.

Resumen:

Administración de servicios en la arquitectura del Centro de conectividad

Aunque es similar al diseño de la arquitectura de red en malla, este diseño no tiene ninguna aplicación virtual de red que actúe como un único punto de error o rendimiento de limitación. También reduce la sobrecarga de administración para el equipo central de la plataforma de Azure, al no enviar conjuntos de datos a través del Centro de conectividad, ya que no es necesario escalar horizontalmente la aplicación virtual. Esto tiene la implicación de que el equipo central de la plataforma de Azure ya no puede inspeccionar y registrar todo el tráfico que se envía entre las zonas de aterrizaje de datos. Sin embargo, el análisis a escala de la nube es una plataforma coherente que abarca varias suscripciones, lo que permite escalar y superar las limitaciones a nivel de plataforma, por lo que no es una desventaja.

Con todos los recursos hospedados en una suscripción única, el tráfico no se inspecciona en el Centro de conectividad central. Los registros de red todavía se pueden capturar mediante el uso de Registros de flujo de Grupos de seguridad de red, y puede consolidar y almacenar otros registros de nivel de servicio y de aplicación, mediante la Configuración de diagnóstico específica de cada servicio. Puede capturar todos estos registros a gran escala usando Directivas de Azure.

Este diseño también le permite crear una solución DNS nativa de Azure, basada en Zonas DNS privadas, y le permite automatizar el ciclo de vida de los registros D de DNS, a través de las Directivas de Azure.

Resumen:

Coste de la arquitectura del Centro de conectividad

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 este diseño de red, solo se le cobra por los Puntos de conexión privados (por hora) y por el tráfico de entrada y salida, enviado a través de esos Puntos de conexión privados, para cargar un conjunto de datos sin procesar (1) y almacenar el conjunto de datos procesados (6).

Resumen:

Ancho de banda y latencia en la arquitectura del Centro de conectividad

Este diseño no tiene limitaciones de ancho de banda y latencia, porque no tiene ninguna aplicación virtual de red limitando el rendimiento del intercambio de datos de zona de aterrizaje entre datos. El único factor de limitación del diseño es el límite físico de nuestros centros de datos (la velocidad de los cables de fibra óptica).

Resumen:

Puntos de conexión privados en el resumen de la arquitectura del Centro de conectividad

Aunque este diseño de arquitectura de red tiene varias ventajas, sus incoherencias de administración de acceso, mencionadas anteriormente, hacen que sea subpar. Por lo tanto, no se puede recomendar este enfoque de diseño.

Conclusión de la conectividad de la zona de aterrizaje de datos de una sola región

De todas las opciones de arquitectura de red revisadas, con sus ventajas y desventajas, la arquitectura de red en malla es la clara ganadora. Tiene enormes ventajas en el rendimiento, el coste y la administración, por lo que se recomienda usarlo al implementar análisis a escala de la nube. Las redes virtuales de radio de emparejamiento no han sido habituales en el pasado, y esto ha provocado problemas en el uso compartido de conjuntos de datos entre dominios y unidades de negocio.

Puede ver el análisis a escala de la nube como una solución coherente que abarca varias suscripciones. En una única configuración de suscripción, el flujo de tráfico de red es igual al flujo de la arquitectura de red en malla. Dentro de una única configuración de suscripción, es probable que los usuarios alcancen los límites y cuotas del nivel de suscripción de la plataforma, algo que el análisis a escala en la nube pretende evitar.

Pasos siguientes

• Conectividad de zonas de aterrizaje de datos entre regiones