Compartir a través de

Topología de red y conectividad para HPC de Azure en el sector energético

  • Artículo

Las instrucciones de este artículo pueden ayudarle a examinar las consideraciones de diseño y los procedimientos recomendados relacionados con las redes y la conectividad para Microsoft Azure y las implementaciones de informática de alto rendimiento (HPC). Las siguientes sugerencias se basan en las consideraciones y recomendaciones que se definen en el artículo sobre la zona de aterrizaje de Azure para la topología de red y la conectividad.

Direccionamiento IP, redes virtuales y subredes

Para planear el direccionamiento IP en Azure, es fundamental asegurarse de que:

  • El espacio de direcciones IP no se superpone entre las ubicaciones locales y las regiones de Azure.
  • El emparejamiento futuro de la red virtual (VNet) con VNet existentes o planeadas es posible.
  • La VNet contiene el espacio de direcciones adecuado.
  • El planeamiento adecuado de la configuración de la subred tiene lugar de antemano.
  • Se considera suficiente exceso de direccionamiento para futuras expansiones u otros servicios.

Consideraciones de diseño

Considere la posibilidad de crear subredes independientes para asignar direcciones IP a través de componentes funcionales del entorno. Por ejemplo, una VNet de HPC dedicada podría incluir las siguientes subredes:

  • Proceso
  • Storage
  • Infraestructura
  • Visualización
  • Iniciar sesión
  • Azure NetApp Files
  • Azure HPC Cache

Los servicios como Azure NetApp Files, Azure HPC Cache y futuras ofertas de almacenamiento requieren subredes delegadas dedicadas para una operación adecuada. Asegúrese de que se planee el espacio de direccionamiento adecuado si se tiene en cuenta alguno de estos servicios.

Resolución de DNS y nombres para los recursos locales y de Azure

El sistema de nombres de dominio (DNS) es un tema de diseño fundamental en la arquitectura general de la zona de aterrizaje de Azure. Es posible que algunas organizaciones quieran usar sus inversiones existentes en DNS, mientras que otras podrían ver la adopción de la nube como una oportunidad para modernizar su infraestructura de DNS interna y usar las funcionalidades nativas de Azure.

Consideraciones de diseño de DNS: siga estas recomendaciones cuando el nombre virtual o el DNS de una máquina virtual no cambie durante la migración.

  • Los nombres DNS y virtuales en segundo plano conectan muchas interfaces del sistema en entornos HPC y los clientes solo reconocen en algunas ocasiones las interfaces que los desarrolladores definen a lo largo del tiempo. Cuando los nombres DNS o virtuales cambian después de las migraciones, surgen desafíos de conexión entre varios sistemas, por lo que se deben conservar los alias DNS para evitar este tipo de dificultades.
  • Use diferentes zonas DNS para distinguir los entornos entre sí, como espacio aislado, desarrollo, preproducción y producción. La excepción es para las implementaciones de HPC con su propia VNet, lo que podría no requerir zonas DNS privadas.
  • La compatibilidad con DNS es obligatoria cuando se usa la memoria caché HPC para poder acceder al almacenamiento y a otros recursos.

Servicios de red de alto rendimiento

  • Redes aceleradas: muchas cargas de trabajo de HPC, como el procesamiento sísmico, procesan grandes cantidades de datos almacenados en sistemas de archivos compartidos como Azure Blob, Azure NetApp Files, Lustre ClusterStor y otras soluciones de almacenamiento personalizadas a las que se accede a través de la red. Una red de alto rendimiento es fundamental para reducir el tiempo de transferencias de datos.

    Las redes aceleradas proporcionan una conexión de alto rendimiento y baja latencia entre las VM y los servicios de Azure. Otras ventajas incluyen la inestabilidad reducida y el uso mínimo de la CPU.

  • InfiniBand: las aplicaciones de HPC paralelas que se basan en bibliotecas de interfaz de paso de mensajes (MPI) puede que necesiten transferir cantidades importantes de datos entre muchas VM. La interconexión InfiniBand, disponible en VM de la serie H y la serie N compatibles con RDMA, proporciona una conexión de baja latencia y alto ancho de banda para maximizar el rendimiento y la escalabilidad de las aplicaciones de HPC y el aprendizaje profundo.

    Diagram of InfiniBand connection between VMs.

    Algunos ejemplos de trabajos de MPI incluyen dinámica molecular, dinámica computacional de fluidos, simulación de yacimientos de petróleo y gas y cargas de trabajo emergentes de aprendizaje automático distribuido.

    Las conexiones InfiniBand solo son posibles entre VM asignadas dentro del mismo grupo de ubicación.

  • Azure ExpressRoute: en el caso de una aplicación de ráfaga como una configuración híbrida para la simulación y el modelado de yacimientos, donde se comparten conjuntos de datos locales y el proceso de Azure se convierte en una extensión, ExpressRoute conecta el entorno local a la nube Microsoft a través de una conexión privada. ExpressRoute proporciona resistencia y disponibilidad de nivel empresarial, así como la ventaja de un ecosistema global de asociados de ExpressRoute. Para información sobre cómo conectar la red a Microsoft mediante ExpressRoute, consulte ExpressRoute connectivity models (Modelos de conectividad de ExpressRoute).

    Las conexiones ExpressRoute no usan la red de Internet pública y ofrecen más confiabilidad, velocidades más altas y menor latencia que las conexiones a Internet habituales. Para las conexiones de punto a sitio y de sitio a sitio, puede conectar dispositivos o redes locales a una red virtual mediante cualquier combinación de estas opciones de VPN y Azure ExpressRoute.

Definición de una topología de red de Azure

Las zonas de aterrizaje a escala empresarial admiten dos topologías de red: una basada en Azure Virtual WAN y la otra en una topología de red tradicional basada en la arquitectura en estrella tipo hub-and-spoke. En esta sección se recomiendan las configuraciones y procedimientos de HPC para ambos modelos de implementación.

  • Azure Virtual WAN: use una topología de red basada en una WAN virtual si la organización planea:

    • Implementar recursos en varias regiones de Azure y conectar las ubicaciones globales a Azure y al entorno local.
    • Integrar totalmente implementaciones de WAN definidas por software con Azure.
    • Implementar hasta 2000 cargas de trabajo de VM en todas las VNet conectadas a un centro de conectividad de Virtual WAN.

    Las organizaciones usan Azure Virtual WAN para cumplir los requisitos de interconectividad a gran escala. Microsoft administra este servicio, lo que ayuda a reducir la complejidad general de la red y a modernizar la red de la organización.

  • Arquitectura en estrella tipo hub-and-spoke: use una topología de red de Azure tradicional basada en la arquitectura en estrella tipo hub-and-spoke si la organización:

    • Planea implementar recursos solo en regiones de Azure seleccionadas.
    • No necesita una red interconectada global.
    • Tiene pocas ubicaciones remotas o sucursales por cada región y necesita menos de 30 túneles de seguridad IP (IPsec).
    • Requiere control total y granularidad para configurar manualmente la red de Azure.

    El emparejamiento de red virtual local y global proporciona conectividad y es el enfoque preferido para garantizar la conectividad entre las zonas de aterrizaje para implementaciones de HPC en varias regiones de Azure.

Conectividad de Internet entrante y saliente

Los servicios de seguridad de red nativos de Azure, como Azure Firewall, Azure Web Application Firewall en Azure Application Gateway y Azure Front Door, son servicios totalmente administrados. Por lo tanto, no incurre en los costos operativos y de administración asociados con las implementaciones de infraestructura, lo que puede resultar complejo a gran escala.

Recomendaciones de diseño para la implementación de HPC:

  • En el caso de los clientes con una superficie global, Azure Front Door ayuda en las implementaciones de HPC mediante directivas de Azure Web Application Firewall para ofrecer y proteger aplicaciones HTTP/S globales entre regiones de Azure.
  • Aproveche las ventajas de las directivas de Web Application Firewall en Azure Front Door cuando use este servicio y Application Gateway para proteger las aplicaciones HTTP/S. Bloquee Application Gateway para recibir tráfico únicamente desde Azure Front Door.

Requisitos de cifrado de red

Consideraciones de diseño para las implementaciones de HPC:

  • Actualmente, el tráfico no se cifra cuando se usa Azure ExpressRoute para configurar el emparejamiento privado.
  • No es necesario cifrar el tráfico a través de ExpressRoute para implementaciones de HPC. Los túneles IPsec cifran el tráfico de Internet de manera predeterminada y el cifrado o descifrado podría afectar negativamente al rendimiento del tráfico.

Principales recomendaciones para cifrar redes entre el entorno local y Azure, y entre regiones de Azure:

  • Determinar si se debe cifrar el tráfico de HPC. Consulte Definición de los requisitos de cifrado de red para conocer las opciones de cifrado de red en zonas de aterrizaje a escala empresarial.
  • Plan para el direccionamiento IP en Azure para asegurarse de que:
    • El espacio de direcciones IP no se superpone entre las ubicaciones locales y las regiones de Azure.
    • La VNet contiene el espacio de direcciones adecuado.
    • El planeamiento adecuado de la configuración de la subred tiene lugar de antemano.

Requisitos de red de ancho de banda de latencia de rendimiento

Tanto los modelos de implementación de HPC solo en la nube como los de nube híbrida tienen sus propios requisitos de rendimiento y latencia en función de cómo se envíen y ejecuten las cargas de trabajo de energía en los entornos locales en comparación con los entornos de nube. Los usuarios pueden enviar trabajos de HPC en muchos modos de implementación, desde el entorno local o en la nube.

  • Trabajos únicos
    • Consideraciones de conectividad local a Azure si se usa el escritorio de visualización remota
  • Trabajos de ráfaga
    • Consideraciones de red de configuración del programador que envían los trabajos en la nube
    • Consideraciones sobre la red de Azure Batch
  • Flujos de trabajo paralelos, tanto locales como en la nube
  • Híbrido
    • Caché de HPC
  • Nativo en la nube
    • Contenedores de Azure Kubernetes Service
    • Functions

Los entornos de MPI están dedicados, ya que tienen requisitos únicos con la necesidad de comunicaciones de baja latencia entre nodos. Los nodos están conectados a través de la interconexión de alta velocidad y no se pueden compartir con otras cargas de trabajo. Las aplicaciones MPI usan todas las interconexiones de alto rendimiento mediante el modo de tránsito en entornos virtualizados. El almacenamiento para nodos MPI suele ser un sistema de archivos paralelo como Lustre, al que también se accede a través de la interconexión de alta velocidad.

Pasos siguientes

En los artículos siguientes se proporcionan instrucciones para cada paso del recorrido de adopción de la nube para entornos de HPC del sector energético.