Netwerktopologie en -connectiviteit voor Azure HPC
De richtlijnen in dit artikel kunnen u helpen bij het onderzoeken van ontwerpoverwegingen en aanbevolen procedures die betrekking hebben op netwerken en connectiviteit voor Microsoft Azure en HPC-implementaties (High Performance Computing).
IP-adressering plannen
Het is van cruciaal belang dat u IP-adressering in Azure plant om ervoor te zorgen dat:
- De IP-adresruimte overlapt niet tussen on-premises locaties en Azure-regio's.
- Toekomstige peering van virtuele netwerken naar bestaande of geplande virtuele netwerken is mogelijk.
- Het virtuele netwerk bevat de juiste adresruimte.
- De juiste planning voor subnetconfiguratie vindt van tevoren plaats.
- Voldoende extra adresruimte wordt overwogen voor toekomstige uitbreiding of andere diensten.
Ontwerpoverwegingen en aanbevelingen
Overweeg om afzonderlijke subnetten te maken om IP-adressen toe te wijzen aan functionele onderdelen van de omgeving. Een toegewezen virtueel HPC-netwerk kan bijvoorbeeld de volgende subnetten bevatten:
- Berekenen
- Opslag
- Infrastructuur
- Visualisatie
- Aanmelden
- Azure NetApp Files
- Azure HPC Cache
Voor verschillende services zoals Azure NetApp Files, HPC Cache en toekomstige opslagaanbiedingen zijn toegewezen gedelegeerde subnetten vereist voor de juiste werking. Als u een van deze services wilt gebruiken, moet u ervoor zorgen dat u de juiste adresseringsruimte plant. Gedelegeerde subnetten zijn vereist als u Azure NetApp Files wilt implementeren. Deze wordt vaak gebruikt in HPC-implementaties met gedeelde bestandssystemen. U kunt toewijzen en subnetten delegeren aan specifieke services en vervolgens exemplaren van deze services binnen subnetten maken.
Azure helpt u bij het maken van meerdere gedelegeerde subnetten in een virtueel netwerk, maar slechts één gedelegeerd subnet kan bestaan in een virtueel netwerk voor Azure NetApp Files. Pogingen om een nieuw volume te maken mislukken als u meer dan één gedelegeerd subnet voor Azure NetApp Files gebruikt. Als u HPC Cache voor opslag gebruikt, maakt u een toegewezen subnet. Zie Cache-subnetvoor meer informatie over deze subnetvereisten. Zie Een subnet toevoegenvoor meer informatie over het maken van een subnet.
DNS en naamomzetting voor on-premises en Azure-resources
Domain Name System (DNS) is een cruciaal ontwerpelement in de algehele Architectuur van de Azure-landingszone. Sommige organisaties willen mogelijk hun bestaande investeringen in DNS gebruiken. Andere organisaties kunnen cloudimplementatie zien als een mogelijkheid om hun interne DNS-infrastructuur te moderniseren en systeemeigen Azure-mogelijkheden te gebruiken. De volgende aanbevelingen zijn van toepassing wanneer de DNS- of virtuele naam van een virtuele machine niet wordt gewijzigd tijdens de migratie.
Ontwerpoverwegingen en aanbevelingen
Achtergrond-DNS- en virtuele namen verbinden meerdere systeeminterfaces in HPC-omgevingen. Klanten zijn slechts soms op de hoogte van de interfaces die ontwikkelaars in de loop van de tijd definiëren. Verbindingsuitdagingen kunnen optreden tussen verschillende systemen wanneer virtuele of DNS-namen na migraties veranderen, dus u moet DNS-aliassen behouden om dit soort problemen te voorkomen.
Gebruik verschillende DNS-zones om omgevingen van elkaar te onderscheiden. Deze omgevingen omvatten sandbox, ontwikkeling, preproductie en productie. De uitzondering hierop is voor HPC-implementaties met een eigen virtueel netwerk, waarvoor mogelijk geen privé-DNS-zones nodig zijn.
DNS-ondersteuning is verplicht wanneer u HPC Cache gebruikt, zodat deze toegang hebben tot opslag en andere resources.
DNS en naamresolutie zijn van cruciaal belang in de financiële sector bij het gebruik van resourcelocaties en servicerecords. U wordt aangeraden de DNS-omzetting te gebruiken die de Microsoft Entra Domain Services-domeincontroller biedt. Zie Microsoft Entra Domain Services implementeren in een virtueel Azure-netwerkvoor meer informatie.
Krachtige netwerkservices
versneld netwerken: veel HPC-workloads, waaronder seismische verwerking, verwerken grote hoeveelheden gegevens die zijn opgeslagen in gedeelde bestandssystemen, zoals Azure Blob, Azure NetApp Files en Lustre ClusterStor. Deze opslagoplossingen en aangepaste oplossingen worden via het netwerk geopend. Een netwerk met hoge prestaties is van cruciaal belang om de tijd voor gegevensoverdracht te verkorten. Versnelde netwerken biedt een verbinding met hoge doorvoer en lage latentie tussen de virtuele machines (VM's) en Azure-services. Andere voordelen zijn verminderde jitter en minimaal CPU-gebruik.
InfiniBand: Parallelle HPC-toepassingen die afhankelijk zijn van MPI-bibliotheken (Message Passing Interface) moeten mogelijk aanzienlijke hoeveelheden gegevens overdragen tussen meerdere VM's. De InfiniBand-interconnect, beschikbaar op RDMA-compatibele (Remote Direct Memory Access)-compatibele H-serie en N-serie VM's, biedt een verbinding met lage latentie, hoge bandbreedte om de prestaties en schaalbaarheid van HPC- en Deep Learning-toepassingen te maximaliseren.
Als u financiële toepassingen uitvoert waarvoor een lage latentie tussen machines is vereist en informatie moet worden overgedragen tussen knooppunten om resultaten te verkrijgen, gebruikt u verbindingen met lage latentie en hoge doorvoer. met RDMA-compatibele H-serie en N-serie VM's communiceren via het InfiniBand-netwerk met lage latentie en hoge bandbreedte. De RDMA-netwerkmogelijkheid via een dergelijke verbinding is van cruciaal belang om de schaalbaarheid en prestaties van HPC- en AI-workloads op gedistribueerd knooppunten te verbeteren. Dit netwerk kan de prestaties verbeteren van toepassingen die worden uitgevoerd onder Microsoft MPI of Intel MPI. Enkele voorbeelden van MPI-taken zijn moleculaire dynamics, computationele vloeistofdynamiek, simulatie van olie- en gasreservoirs en opkomende gedistribueerde machine learning-workloads.
InfiniBand-verbindingen zijn alleen mogelijk tussen VM's die zijn toegewezen binnen dezelfde plaatsingsgroep. Zie InfiniBand inschakelenvoor meer informatie. Zie Message Passing Interface instellen voor HPCvoor meer informatie over het instellen van MPI.
Azure ExpressRoute: ExpressRoute-verbindingen maken geen gebruik van het openbare internet en bieden ze meer betrouwbaarheid, snellere snelheden en lagere latenties dan gewone internetverbinding. Voor punt-naar-site-VPN en site-naar-site-VPN kunt u on-premises apparaten of netwerken verbinden met een virtueel netwerk met behulp van een combinatie van deze VPN-opties en ExpressRoute.
Voor burst-toepassingen zoals een hybride installatie voor reservoirsimulatie en -modellering, waarbij on-premises gegevenssets worden gedeeld en Azure Compute een extensie wordt, verbindt ExpressRoute uw on-premises omgeving met de Microsoft-cloud via een privéverbinding. ExpressRoute biedt tolerantie en beschikbaarheid op bedrijfsniveau en het voordeel van een global ExpressRoute-partnerecosysteem. Zie ExpressRoute-connectiviteitsmodellenvoor meer informatie over het verbinden van uw netwerk met Microsoft met behulp van ExpressRoute.
Voor hybride toepassingen zoals oplossingen voor risicorastercomputing, waarbij uw on-premises handelssystemen en analyses functioneel zijn en Azure een uitbreiding wordt, kunt u ExpressRoute gebruiken om uw on-premises omgeving te verbinden met Azure via een privéverbinding, met behulp van een connectiviteitsprovider. ExpressRoute biedt tolerantie en beschikbaarheid op ondernemingsniveau en het voordeel van een wereldwijd ExpressRoute-partnerecosysteem. Zie ExpressRoute-connectiviteitsmodellenvoor meer informatie over het verbinden van uw netwerk met Azure met behulp van ExpressRoute.
Een Azure-netwerktopologie definiëren
Landingszones op ondernemingsniveau ondersteunen twee netwerktopologieën. De ene topologie is gebaseerd op Azure Virtual WAN en de andere op een traditionele netwerktopologie die is gebaseerd op hub-and-spoke-architectuur. In deze sectie worden HPC-configuraties en -procedures aanbevolen voor beide implementatiemodellen.
Gebruik een netwerktopologie die is gebaseerd op een virtueel WAN als uw organisatie van plan is om:
Implementeer resources in verschillende Azure-regio's en verbind uw globale locaties met zowel Azure- als on-premises omgevingen.
Integreer softwaregedefinieerde WAN-implementaties volledig met Azure.
Implementeer maximaal 2000 VM-workloads in alle virtuele netwerken die zijn verbonden met één virtuele WAN-hub.
Organisaties gebruiken Azure Virtual WAN om te voldoen aan grootschalige interconnectiviteitsvereisten. Microsoft beheert deze service, waarmee de algehele netwerkcomplexiteit wordt verminderd en het netwerk van uw organisatie wordt gemoderniseerd. Gebruik een traditionele Azure-netwerktopologie op basis van de hub-and-spoke-architectuur als uw organisatie:
Plannen voor het implementeren van resources in alleen bepaalde Azure-regio's.
Heeft geen behoefte aan een wereldwijd, onderling verbonden netwerk.
Heeft weinig externe of vertakkingslocaties per regio en heeft minder dan 30 IP-beveiligingstunnels (IPsec).
Vereist volledig beheer en granulariteit om uw Azure-netwerk handmatig te configureren.
Maakt gebruik van lokale en wereldwijde peering van virtuele netwerken om connectiviteit te bieden.
Peering voor lokale en wereldwijde virtuele netwerken biedt connectiviteit en zijn de voorkeursmethoden om de connectiviteit tussen landingszones voor HPC-implementaties in meerdere Azure-regio's te garanderen. Documenteer uw netwerktopologie en firewallregels. Netwerkbeveiligingsgroepen (NSG's) worden vaak met een aanzienlijke complexiteit geïmplementeerd. Gebruik toepassingsbeveiligingsgroepen wanneer het zinvol is om verkeer met een grotere granulariteit te labelen dan virtuele netwerken kunnen bieden. Informatie over NSG-prioriteitsregels en welke regels voorrang hebben op anderen.
Inkomende en uitgaande internetverbinding
In de volgende sectie worden aanbevolen connectiviteitsmodellen beschreven voor binnenkomende en uitgaande connectiviteit van en naar het openbare internet. Omdat systeemeigen netwerkbeveiligingsservices van Azure, zoals Azure Firewall, Azure Web Application Firewall op Azure Application Gateway en Azure Front Door volledig beheerde services zijn, worden er geen operationele en beheerkosten in rekening gebracht die zijn gekoppeld aan infrastructuurimplementaties, wat complex kan worden op schaal.
Ontwerpoverwegingen en aanbevelingen
Overweeg het gebruik van Azure Front Door- voor uw HPC-implementatie als uw organisatie een wereldwijde footprint heeft. Azure Front Door maakt gebruik van Azure Web Application Firewall-beleid om wereldwijde HTTP- en HTTPS-toepassingen in Azure-regio's te leveren en te beveiligen.
Profiteer van Web Application Firewall-beleid wanneer u Azure Front Door en Application Gateway gebruikt om HTTP- en HTTPS-toepassingen te beveiligen. Vergrendel Application Gateway om alleen verkeer van Azure Front Door te ontvangen. Voor meer informatie, zie Hoe kan ik de toegang vergrendelen?.
Lokale en wereldwijde peeringconnectiviteit voor virtuele netwerken gebruiken. Deze methoden hebben de voorkeur om te zorgen voor connectiviteit tussen landingszones voor HPC-implementaties in meerdere Azure-regio's.
Vereisten voor netwerkversleuteling definiëren
De volgende sectie bevat belangrijke aanbevelingen voor het versleutelen van netwerken tussen on-premises omgevingen en Azure, en in verschillende Azure-regio's.
Ontwerpoverwegingen en aanbevelingen
- Houd rekening met de prestaties van verkeer wanneer u versleuteling inschakelt. IPsec-tunnels versleutelen internetverkeer standaard. Elke extra versleuteling of ontsleuteling kan de prestaties negatief beïnvloeden. Wanneer u ExpressRoute gebruikt, wordt verkeer niet standaard versleuteld. Bepaal of u HPC-verkeer moet versleutelen. Zie voor meer informatie over netwerkversleutelingsopties in landingszones op ondernemingsniveau netwerktopologie en connectiviteit.
De volgende aanbevelingen zijn bedoeld voor het versleutelen van netwerken tussen on-premises en Azure en tussen Azure-regio's:
Bepaal of HPC-verkeer moet worden versleuteld. Zie Netwerktopologie en -connectiviteitvoor meer informatie.
Plan IP-adressering in Azure om ervoor te zorgen dat:
- De IP-adresruimte overlapt niet tussen on-premises locaties en Azure-regio's.
- Het virtuele netwerk bevat de juiste adresruimte.
- De juiste planning voor subnetconfiguratie vindt van tevoren plaats.
Netwerkeisen voor latentie, bandbreedte en doorvoer definiëren
HPC in de cloud en hybride HPC Cloud-implementatiemodellen hebben elk hun eigen netwerk- en connectiviteitslatentie- en doorvoerbehoeften. Deze behoeften zijn afhankelijk van hoe u de productiewerkstroom en workloadtaken on-premises verzendt en uitvoert ten opzichte van de cloud. Gebruikers kunnen HPC-taken in veel implementatiemodi verzenden vanuit on-premises of de cloud.
Eén taak
- Overwegingen voor connectiviteit tussen on-premises en Azure bij gebruik van een remote visualisatie-desktop
Burst-opdrachten
- Overwegingen voor het instellen van het netwerk van Scheduler, waarmee de taken in de cloud worden verzonden
- Overwegingen voor Azure Batch-netwerken
Parallelle werkstromen voor on-premises en cloudomgevingen
Hybride
- HPC-cache
Cloud native
- KS-containers
- Functies
MPI-omgevingen zijn toegewezen omdat ze unieke vereisten hebben die communicatie met lage latentie tussen knooppunten nodig hebben. De knooppunten zijn verbonden via een snelle verbinding en zijn niet geschikt om te delen met andere workloads. MPI-toepassingen maken gebruik van de volledige high-performance interconnects via de passthrough-modus in gevirtualiseerde omgevingen. Opslag voor MPI-knooppunten is meestal een parallel bestandssysteem zoals Lustre dat ook toegankelijk is via de snelle interconnect.
Volgende stappen
De volgende artikelen bevatten richtlijnen voor elke stap in het cloudacceptatietraject voor HPC-omgevingen.
- Azure Billing en Microsoft Entra-huurders voor energie HPC
- Resourceorganisatie voor HPC in de energiesector
- Governance voor HPC in de energiesector
- Beveiliging voor Azure HPC in de energiesector
- Bereken grootschalige HPC-toepassingsworkloads in Azure-VM's
- Storage voor HPC-energieomgevingen
- Azure high-performance computing (HPC) landingszone-versneller