Partager via


Fabrication de la topologie et de la connectivité de réseau HPC

Ces conseils s’appuient sur les considérations et recommandations définies dans l'article sur la zone d’atterrissage Azure concernant la topologie et la connectivité du réseau. En suivant les conseils de cet article, vous pourrez examiner les principales considérations de conception et les meilleures pratiques pour la mise en réseau et la connectivité vers, depuis et dans les déploiements Microsoft Azure et HPC.

Planifier l’adresse IP, le réseau virtuel et les sous-réseaux

Il est essentiel de planifier les besoins en matière d’adresses IP dans Azure pour s’assurer que :

  • Il n’existe pas de chevauchement des espaces d’adressage IP des emplacements locaux et des régions Azure concernés.
  • Le peering futur VNet avec des réseaux virtuels existants ou planifiés est possible.
  • Le réseau virtuel (VNet) contient l’espace d’adressage correct.
  • Une bonne planification de la configuration du sous-réseau se fait à l’avance.
  • L’adressage excédentaire suffisant est envisagé pour l’expansion future ou d’autres services

Considérations relatives à la conception de la fabrication HPC

Envisagez de créer des sous-réseaux distincts pour affecter des adresses IP entre les composants fonctionnels de l’environnement. Par exemple, un réseau virtuel HPC dédié peut inclure les sous-réseaux suivants :

  • Calcul
  • Stockage
  • Infrastructure
  • Visualisation
  • Connexion
  • ANF
  • HPC Cache

Plusieurs services tels que Azure NetApp Files, Azure HPC Cache et les offres de stockage futures nécessitent des sous-réseaux délégués dédiés pour un bon fonctionnement. Veillez à planifier l’espace d’adressage approprié si vous envisagez l’un de ces services.

Configurer le DNS et la résolution de noms pour les ressources locales et Azure

Le DNS (Domain Name System) est un aspect de conception critique dans l’architecture globale de la zone d’atterrissage Azure. Certaines organisations peuvent préférer utiliser leurs investissements en DNS existants. D’autres peuvent considérer l’adoption du cloud comme une opportunité de moderniser leur infrastructure DNS interne et d’utiliser des fonctionnalités Azure natives.

Considérations relatives à la conception du réseau HPC

Les recommandations suivantes concernent le moment où le nom DNS ou virtuel d’un ordinateur virtuel ne change pas au cours de la migration.

Cas d’usage

  • Les noms DNS d’arrière-plan et virtuels connectent de nombreuses interfaces système dans les environnements HPC. Les clients ne connaissent que parfois les interfaces que les développeurs définissent au fil du temps. Des problèmes de connexion surviennent entre différents systèmes lorsque des noms virtuels ou DNS changent après des migrations. Il est recommandé de conserver les alias DNS pour éviter ces types de difficultés.
  • Utilisez des zones DNS différentes pour distinguer chaque environnement (bac à sable, développement, préproduction et production). L’exception concerne les déploiements HPC avec leur propre réseau virtuel. Ici, les zones DNS privées peuvent ne pas être nécessaires.
  • La prise en charge DNS est obligatoire lors de l’utilisation du cache HPC afin qu’ils puissent accéder au stockage et à d’autres ressources.

Services réseau hautes performances

Mise en réseau accélérée

De nombreuses charges de travail HPC (par exemple, le traitement sismique) nécessitent le traitement d’une grande quantité de données. Les données sont stockées dans de grands systèmes de fichiers partagés comme Azure Blob, Azure NetApp Files, Lustre ClusterStor et d’autres solutions de stockage personnalisées auxquelles vous accédez via le réseau. Il est primordial de s’appuyer sur un réseau hautes performances pour réduire le temps nécessaire aux transferts de données.

L’activation de la mise en réseau accélérée fournit aux machines virtuelles une connexion à haut débit et à faible latence entre elles et vers et depuis les services Azure, ainsi qu’une gigue réduite et une utilisation minimale du processeur.

InfiniBand

Les applications HPC parallèles qui s’appuient sur des bibliothèques MPI (Message Passing Interface) peuvent nécessiter le transfert d’une quantité importante d’informations entre de nombreuses machines virtuelles. L’interconnexion InfiniBand disponible sur les machines virtuelles compatibles RDMA série H et série N fournit la faible latence et la bande passante élevée requises pour optimiser les performances et l’extensibilité des applications HPC et IA.

Voici quelques exemples de travaux MPI :

  • Dynamique moléculaire
  • Mécanique des fluides numérique
  • Simulation de réservoir de pétrole et de gaz
  • Charges de travail de Machine Learning distribuées émergentes dans la fabrication

La connexion InfiniBand n’est possible qu’entre les machines virtuelles allouées au sein du même groupe de placement.

Azure ExpressRoute

  • S’il existe une application en rafale comme une configuration hybride pour la simulation et la modélisation de réservoirs, où les jeux de données locaux sont partagés et où le calcul Azure devient une extension, Express Route vous aide à connecter votre environnement local au cloud Microsoft via une connexion privée à l’aide d’un fournisseur de connectivité. Il offre une résilience et une disponibilité de niveau entreprise, ainsi que l’avantage d’un écosystème de partenaires ExpressRoute global. Pour plus d’informations sur la connexion de votre réseau à Microsoft à l’aide d’ExpressRoute, consultez Modèles de connectivité ExpressRoute.
  • Les connexions ExpressRoute ne sont pas établies via l’internet public et elles offrent une plus grande fiabilité, des débits plus importants et des latences moindres par rapport aux connexions Internet classiques. Pour un VPN point à site et un VPN site à site, vous pouvez connecter des appareils ou des réseaux locaux à un réseau virtuel à l’aide de n’importe quelle combinaison de ces options VPN et d’Azure ExpressRoute.

Définir une topologie de réseau Azure

Les zones d’atterrissage à l’échelle de l’entreprise prennent en charge deux topologies de réseau : l’une basée sur Azure Virtual WAN et l’autre sur une topologie de réseau traditionnelle basée sur l’architecture hub-and-spoke. Cette section recommande des configurations et des pratiques HPC pour les deux modèles de déploiement.

Utilisez une topologie de réseau basée sur Virtual WAN si votre organisation prévoit d’effectuer les opérations suivantes :

  • Votre organisation envisage de déployer des ressources dans plusieurs régions Azure et doit connecter vos emplacements mondiaux à Azure et localement.
  • Intégrez entièrement les déploiements de réseaux étendus à définition logicielle avec Azure.
  • Déployez jusqu'à 50 000 charges de travail de machines virtuelles sur tous les réseaux virtuels connectés à un hub Virtual WAN.

Les organisations utilisent Virtual WAN pour répondre aux besoins d’interconnexion à grande échelle. Microsoft gère ce service, ce qui permet de réduire la complexité globale du réseau et de moderniser le réseau de votre organisation.

Utilisez une topologie de réseau Azure traditionnelle basée sur une architecture hub-and-spoke si votre organisation :

  • Prévoit de déployer des ressources dans les régions Azure sélectionnées uniquement.
  • N’a pas besoin d’un réseau interconnecté global.
  • Dispose de quelques sites distants ou succursales par région et a besoin de moins de 30 tunnels de sécurité IP (IPsec).
  • Nécessite un contrôle total et une granularité pour configurer manuellement votre réseau Azure.
  • Utilise le peering de réseaux virtuels locaux et globaux pour fournir une connectivité. Le peering de réseaux virtuels locaux constitue l’approche préférée pour garantir la connectivité entre les zones d’atterrissage pour les déploiements HPC dans plusieurs régions Azure.

Planifier la connectivité Internet entrante et sortante

Cette section recommande des modèles de connectivité pour la connectivité entrante et sortante vers et depuis l’Internet public. Les services de sécurité réseau natifs d’Azure, comme Pare-feu Azure, Azure Web Application Firewall on Application Gateway et Azure Front Door, sont des services entièrement gérés. Vous n’avez donc pas à payer les coûts d’exploitation et de gestion associés à des déploiements d’infrastructure qui peuvent devenir complexe à grande échelle.

Recommandations de conception pour l’implémentation HPC :

  • Pour les clients disposant d’un encombrement global, Azure Front Door permet les déploiements HPC à l’aide de stratégies de Azure Web Application Firewall pour distribuer et protéger des applications HTTP/S globales dans des régions Azure.
  • Tirez parti des stratégies Web Application Firewall dans Azure Front Door lorsque vous utilisez ce service et Azure Application Gateway pour protéger les applications HTTP/S. Verrouillez Azure Application Gateway pour recevoir le trafic uniquement d’Azure Application Gateway.

Définir des exigences de chiffrement de réseau

Cette section explore les principales recommandations relatives au chiffrement des réseaux entre les sites locaux et Azure, et entre les régions Azure.

Considérations relatives à la conception pour les implémentations HPC :

  • Le trafic n’est pas actuellement chiffré quand vous utilisez Azure ExpressRoute pour configurer le peering privé.
  • Il n’est pas nécessaire de chiffrer le trafic sur ExpressRoute pour les déploiements HPC. Les tunnels IPsec chiffrent le trafic Internet par défaut. Le chiffrement ou le déchiffrement peut affecter négativement les performances du trafic.

C’est à l’utilisateur de déterminer si le trafic HPC doit être chiffré. Explorez la topologie et la connectivité du réseau pour comprendre les options de chiffrement réseau dans les zones d’atterrissage à l’échelle de l’entreprise.

Il est essentiel de planifier les besoins en matière d’adresses IP dans Azure pour s’assurer que :

  • Il n’existe pas de chevauchement des espaces d’adressage IP des emplacements locaux et des régions Azure concernés.
  • Le réseau virtuel (VNet) contient l’espace d’adressage correct.
  • Une bonne planification de la configuration du sous-réseau se fait à l’avance.

Définir et les exigences réseau en matière de latence de débit

  • Le modèle de déploiement HPC dans le cloud uniquement et le modèle de déploiement HPC cloud hybride ont leurs propres besoins en matière de latence et de débit de réseau et de connectivité, selon la façon dont vous envoyez et exécutez le workflow de fabrication et les travaux de charge de travail en local et dans le cloud. Les utilisateurs peuvent envoyer des travaux HPC dans de nombreux modes de déploiement (localement ou dans le cloud).
    • Travaux uniques
      • Considérations relatives à la connectivité locale à Azure si vous utilisez le bureau de visualisation à distance
    • Tâches en rafale
      • Considérations relatives à la configuration réseau du planificateur, qui envoient les travaux dans le cloud
      • Considérations relatives au réseau Azure Batch
    • Workflows parallèles (locaux et cloud)
    • Hybride
      • Cache HPC
    • Cloud natif
      • Conteneurs KS
      • Fonctions
  • Les environnements MPI sont dédiés, car ils ont des exigences uniques avec un besoin de communications à faible latence entre les nœuds. Les nœuds se connectent via une interconnexion à haut débit et ne peuvent pas être partagés avec d’autres charges de travail. Les applications MPI utilisent l’ensemble des interconnexions hautes performances en mode pass-through dans les environnements virtualisés. Le stockage pour les nœuds MPI est généralement un système de fichiers parallèle comme Lustre qui est également accessible via l’interconnexion à haut débit.

Diagramme montrant InfiniBand.

Étapes suivantes

Les articles suivants fournissent des conseils sur chaque étape du parcours d’adoption du cloud pour les environnements HPC de fabrication.