Partager via

Topologie et connectivité réseau pour Azure HPC

  • Article

Les conseils de cet article peuvent vous aider à examiner les considérations relatives à la conception et aux meilleures pratiques relatives à la mise en réseau et à la connectivité pour les déploiements de Microsoft Azure et de calcul haute performance (HPC).

Planifier l’adressage IP

Il est essentiel que vous planifiez l’adressage IP dans Azure pour vous assurer que :

  • L’espace d’adressage IP ne chevauche pas les emplacements locaux et les régions Azure.
  • Le peering futur de réseaux virtuels avec des réseaux virtuels existants ou planifiés est possible.
  • Le réseau virtuel contient l’espace d’adressage approprié.
  • Une planification appropriée de la configuration du sous-réseau se produit à l’avance.
  • L’adressage excédentaire suffisant est envisagé pour l’expansion future ou d’autres services.

Considérations et recommandations relatives à la conception

  • 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
    • Se connecter
    • Azure NetApp Files
    • Azure HPC Cache

  • Plusieurs services tels qu’Azure NetApp Files, HPC Cache et les offres de stockage futures nécessitent des sous-réseaux délégués dédiés pour une opération appropriée. Si vous envisagez d’utiliser l’un de ces services, veillez à planifier l’espace d’adressage approprié. Les sous-réseaux délégués sont requis si vous souhaitez implémenter Azure NetApp Files, qui est fréquemment utilisé dans les déploiements HPC avec des systèmes de fichiers partagés. Vous pouvez dédier et déléguer des sous-réseaux à des services spécifiques, puis créer des instances de ces services au sein de sous-réseaux.

  • Azure vous aide à créer plusieurs sous-réseaux délégués dans un réseau virtuel, mais un seul sous-réseau délégué peut exister dans un réseau virtuel pour Azure NetApp Files. Les tentatives de création d’un volume échouent si vous utilisez plusieurs sous-réseaux délégués pour Azure NetApp Files. Si vous utilisez HPC Cache pour le stockage, créez un sous-réseau dédié. Pour plus d’informations sur ce prérequis de sous-réseau, consultez Sous-réseau de cache. Pour en savoir plus sur la création d’un sous-réseau, consultez Ajouter un sous-réseau de réseau virtuel.

Dns et résolution de noms pour les ressources locales et Azure

Le système de noms de domaine (DNS) est un élément de conception crucial dans l’architecture globale de la zone d’atterrissage Azure. Certaines organisations peuvent souhaiter utiliser leurs investissements existants dans DNS. D’autres organisations peuvent considérer l’adoption du cloud comme une opportunité de moderniser leur infrastructure DNS interne et d’utiliser des fonctionnalités Azure natives. Les recommandations suivantes s’appliquent quand le DNS ou le nom virtuel d’une machine virtuelle ne change pas lors de la migration.

Considérations et recommandations relatives à la conception

  • Les noms DNS en arrière-plan et virtuels connectent plusieurs 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. Les problèmes de connexion peuvent se produire entre différents systèmes lorsque les noms virtuels ou DNS changent après les migrations. Vous devez donc conserver les alias DNS pour éviter ces types de problèmes.

  • Utilisez différentes zones DNS pour distinguer les environnements les uns des autres. Ces environnements incluent le bac à sable, le développement, la préproduction et la production. L’exception concerne les déploiements HPC qui ont leur propre réseau virtuel, ce qui peut ne pas nécessiter de zones DNS privées.

  • La prise en charge DNS est obligatoire lorsque vous utilisez HPC Cache afin qu’ils puissent accéder au stockage et à d’autres ressources.

  • DNS et la résolution de noms sont essentiels dans le secteur financier, notamment lorsque vous utilisez la localisation des ressources et les enregistrements de service. Nous vous recommandons d’utiliser la résolution DNS que le contrôleur de domaine Microsoft Entra Domain Services fournit. Pour plus d’informations, consultez Déployer Microsoft Entra Domain Services dans un réseau virtuel Azure.

Services réseau hautes performances

  • mise en réseau accélérée : de nombreuses charges de travail HPC, notamment le traitement sismique, gèrent de grandes quantités de données stockées dans des systèmes de fichiers partagés tels qu’Azure Blob, Azure NetApp Files et Lustre ClusterStor. Ces solutions de stockage et solutions personnalisées sont accessibles via le réseau. Un réseau hautes performances est essentiel pour réduire le temps des transferts de données. mise en réseau accélérée fournit une connexion à débit élevé et à faible latence entre les machines virtuelles et les services Azure. D’autres avantages incluent une diminution de la gigue et une utilisation minimale du processeur.

  • InfiniBand : applications HPC parallèles qui s’appuient sur des bibliothèques MPI (Message Passing Interface) peuvent avoir besoin de transférer des quantités importantes de données entre plusieurs machines virtuelles. L’interconnexion InfiniBand, accessible sur les machines virtuelles des séries H et N compatibles avec l’accès à la mémoire directe à distance (RDMA), offre une connexion à faible latence et à bande passante élevée pour maximiser les performances et l’évolutivité des applications de calcul haute performance (HPC) et de deep learning.

    • Si vous exécutez des applications financières nécessitant une faible latence entre les machines et des informations doivent être transférées entre les nœuds pour obtenir des résultats, utilisez des interconnexions à faible latence et à débit élevé. série H compatible RDMA et série N les machines virtuelles communiquent sur le réseau InfiniBand à faible latence et à bande passante élevée. La fonctionnalité réseau RDMA sur une telle connexion est essentielle pour améliorer la scalabilité et les performances des charges de travail HPC et IA à nœud distribué. Ce réseau peut améliorer les performances des applications qui s’exécutent sous Microsoft MPI ou Intel MPI. Parmi les exemples de travaux MPI, citons la dynamique moléculaire, la dynamique des fluides de calcul, la simulation de réservoir de pétrole et de gaz et les charges de travail de Machine Learning distribuées émergentes.

    • Les connexions InfiniBand sont possibles uniquement entre les machines virtuelles allouées au sein du même groupe de placement . Pour plus d’informations, consultez Activer InfiniBand. Pour savoir comment configurer MPI, consultez Configurer l’interface de transmission de messages pour HPC.

    diagramme montrant la connexion InfiniBand entre les machines virtuelles.

  • Azure ExpressRoute : connexions ExpressRoute n’utilisent pas l’Internet public, et elles fournissent plus de fiabilité, de vitesses plus rapides et de latences inférieures à celles des connexions Internet classiques. Pour un VPN de point à site et un VPN de 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 ExpressRoute.

    • Pour les applications 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 le calcul Azure devient une extension, ExpressRoute connecte votre environnement local au cloud Microsoft via une connexion privée. ExpressRoute offre une résilience et une disponibilité de niveau entreprise, ainsi que l’avantage d’un écosystème partenaire Global ExpressRoute. Pour plus d’informations sur la connexion de votre réseau à Microsoft à l’aide d’ExpressRoute, consultez modèles de connectivité ExpressRoute.

    • Pour les applications hybrides telles que les solutions de calcul de grille de risque, où vos systèmes de négociation et analyses locaux sont fonctionnels et Azure devient une extension, vous pouvez utiliser ExpressRoute pour connecter votre environnement local à Azure via une connexion privée, avec l’aide d’un fournisseur de connectivité. ExpressRoute offre une résilience et une disponibilité de niveau entreprise et l’avantage d’un écosystème partenaire ExpressRoute global. Pour plus d’informations sur la connexion de votre réseau à Azure à l’aide d’ExpressRoute, consultez modèles de connectivité ExpressRoute.

Définir une topologie de réseau Azure

Les zones d’atterrissage à l’échelle de l’entreprise prennent en charge deux topologies réseau. Une topologie est 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 les configurations et pratiques HPC pour les deux modèles de déploiement.

Utilisez une topologie de réseau basée sur un réseau étendu virtuel si votre organisation prévoit :

  • Déployez des ressources dans plusieurs régions Azure et connectez vos emplacements globaux aux environnements Azure et locaux.

  • Intégrez entièrement les déploiements WAN définis par logiciel à Azure.

  • Déployez jusqu’à 2 000 charges de travail de machine virtuelle sur tous les réseaux virtuels connectés à un hub virtual WAN.

Les organisations utilisent Azure Virtual WAN pour répondre aux exigences 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 l’architecture hub-and-spoke si votre organisation :

  • Envisage de déployer des ressources uniquement dans certaines régions Azure.

  • N’a pas besoin d’un réseau global interconnecté.

  • Possède peu d’emplacements distants ou de succursales par région et nécessite 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 et globaux assure la connectivité et 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. Documentez vos règles de topologie et de pare-feu réseau. Les groupes de sécurité réseau (NSG) sont souvent implémentés avec une complexité considérable. Utilisez des groupes de sécurité d’application lorsqu’il est judicieux d’étiqueter le trafic à une plus grande granularité que les réseaux virtuels peuvent fournir. Comprendre les règles de hiérarchisation des groupes de sécurité réseau (NSG) et celles qui prennent la priorité sur les autres.

Connectivité Internet entrante et sortante

La section suivante décrit les modèles de connectivité recommandés pour la connectivité entrante et sortante vers et depuis l’Internet public. Étant donné que les services de sécurité réseau natifs Azure comme le Pare-feu Azure, le Pare-feu d’applications web Azure sur Azure Application Gateway et Azure Front Door sont des services entièrement managés, vous n’entraînez pas les coûts opérationnels et de gestion associés aux déploiements d’infrastructure, ce qui peut devenir complexe à grande échelle.

Considérations et recommandations relatives à la conception

  • Envisagez d’utiliser Azure Front Door pour votre déploiement HPC si votre organisation a une empreinte globale. Azure Front Door utilise les politiques Azure Web Application Firewall pour fournir et aider à protéger les applications HTTP et HTTPS globales à travers les régions Azure.

  • Profitez des stratégies de pare-feu pour les applications web lorsque vous utilisez Azure Front Door et Application Gateway afin d'aider à protéger les applications HTTP et HTTPS. Verrouiller Application Gateway pour recevoir le trafic uniquement à partir d’Azure Front Door. Pour plus d’informations, consultez Comment verrouiller l’accès ?.

  • Utiliser la connectivité de peering local ou mondial des réseaux virtuels. Ces méthodes sont recommandées pour garantir la connectivité entre les zones d’atterrissage pour les déploiements HPC dans plusieurs régions Azure.

Définir la configuration requise pour le chiffrement réseau

La section suivante fournit des recommandations clés pour chiffrer les réseaux entre les environnements locaux et Azure, et entre les régions Azure.

Considérations et recommandations relatives à la conception

  • Prenez en compte les performances du trafic lorsque vous activez le chiffrement. Les tunnels IPsec chiffrent le trafic Internet par défaut. Tout chiffrement ou déchiffrement supplémentaire peut affecter négativement les performances. Lorsque vous utilisez ExpressRoute, le trafic n’est pas chiffré par défaut. Déterminez si vous devez chiffrer le trafic HPC. Pour plus d’informations sur les options de chiffrement réseau dans les zones d’atterrissage à l’échelle de l’entreprise, consultez topologie de réseau et connectivité.

Les recommandations suivantes concernent le chiffrement des réseaux entre des régions Azure locales et Azure :

  • Déterminez si le trafic HPC doit être chiffré. Pour plus d’informations, consultez topologie et connectivité réseau.

  • Planifiez l’adressage IP dans Azure pour vous assurer que :

    • L’espace d’adressage IP ne chevauche pas les emplacements locaux et les régions Azure.
    • Le réseau virtuel contient l’espace d’adressage approprié.
    • Une planification appropriée de la configuration du sous-réseau se produit à l’avance.

Définir les exigences réseau de débit, de latence et de bande passante.

HPC dans le cloud uniquement et les modèles de déploiement hybride HPC Cloud ont chacun leurs propres besoins en matière de réseau et de connectivité et de débit. Ces besoins dépendent de la façon dont vous envoyez et exécutez le flux de travail de fabrication et les travaux de charge de travail locaux par rapport au cloud. Les utilisateurs peuvent soumettre des travaux HPC dans de nombreux modes de déploiement à partir d’un environnement local ou du cloud.

  • Travaux uniques

    • Considérations relatives à la connectivité locale vers Azure si vous utilisez le Bureau de visualisation à distance

  • Tâches en rafale

    • Considérations relatives à la configuration du réseau du planificateur, qui envoient les travaux dans le cloud
    • Considérations relatives au réseau Azure Batch

  • Flux de travail parallèles pour les environnements locaux et cloud

  • Hybride

    • Cache HPC

  • Cloud natif

    • Conteneurs KS
    • Fonctions

Les environnements MPI sont dédiés, car ils ont des exigences uniques qui nécessitent des communications à faible latence entre les nœuds. Les nœuds se connectent via une interconnexion haute vitesse 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 haute vitesse.

Étapes suivantes

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