Netzwerktopologie und -konnektivität für Azure HPC im Energiesektor
Die Anleitungen in diesem Artikel helfen Ihnen bei der Untersuchung von Entwurfsüberlegungen und bewährten Methoden in Bezug auf Netzwerke und Konnektivität für Microsoft Azure- und HPC-Bereitstellungen (High Performance Computing). Die folgenden Vorschläge bauen auf den im Artikel über die Azure-Zielzonen für Netzwerktopologie und -konnektivität definierten Überlegungen und Empfehlungen auf.
IP-Adressierung, virtuelle Netzwerke und Subnetze
Es ist wichtig, die IP-Adressierung in Azure zu planen, um Folgendes sicherzustellen:
- Der IP-Adressraum weist keine Überlappungen in Bezug auf lokale Standorte und Azure-Regionen auf.
- Peering virtueller Netzwerke (VNet) ist in der Zukunft mit vorhandenen oder geplanten VNets möglich.
- Das VNet enthält den richtigen Adressraum.
- Die richtige Planung für die Subnetzkonfiguration erfolgt bereits im Voraus.
- Für eine zukünftige Erweiterung oder andere Dienste ist eine ausreichende überzählige Adressierung berücksichtigt worden.
Überlegungen zum Entwurf
Erwägen Sie das Erstellen separater Subnetze, um IP-Adressen über funktionale Komponenten der Umgebung hinweg zuzuweisen. Ein dediziertes HPC-VNet könnte beispielsweise die folgenden Subnetze enthalten:
- Compute
- Storage
- Infrastruktur
- Visualisierung
- Anmelden
- Azure NetApp Files
- Azure HPC Cache
Dienste wie Azure NetApp Files, Azure HPC Cache und zukünftige Speicherangebote erfordern dedizierte delegierte Subnetze für den ordnungsgemäßen Betrieb. Stellen Sie sicher, dass ein geeigneter Adressraum geplant ist, wenn einer dieser Dienste in Betracht gezogen wird.
DNS und Namensauflösung für lokale Ressourcen und Azure-Ressourcen
Domain Name System (DNS) ist ein wichtiges Entwurfsthema in der allgemeinen Architektur von Azure-Zielzonen. Einige Organisationen möchten möglicherweise ihre vorhandenen Investitionen in DNS nutzen, während andere möglicherweise ihre interne DNS-Infrastruktur modernisieren und native Azure-Funktionen nutzen möchten.
Entwurfsüberlegungen für DNS: Befolgen Sie diese Empfehlungen, wenn sich der DNS- oder virtuelle Name eines virtuellen Computers während der Migration nicht ändert.
- Per Hintergrund-DNS und mit virtuellen Namen werden viele Systemschnittstellen in HPC-Umgebungen verbunden, und Kunden kennen nicht immer alle Schnittstellen, die von Entwicklern im Laufe der Zeit definiert werden. Es kann zu Verbindungsproblemen zwischen den verschiedenen Systemen kommen, wenn sich virtuelle oder DNS-Namen nach Migrationen ändern. Sie sollten also DNS-Aliase verwenden, um diese Art von Problemen zu verhindern.
- Verwenden Sie unterschiedliche DNS-Zonen, um Umgebungen wie Sandbox, Entwicklung, Präproduktion und Produktion voneinander zu unterscheiden. Die Ausnahme sind HPC-Bereitstellungen mit einem eigenen VNet, für die möglicherweise keine privaten DNS-Zonen erforderlich sind.
- DNS-Unterstützung ist bei der Verwendung eines HPC-Caches obligatorisch, damit der Zugriff auf Speicher und andere Ressourcen gewährleistet ist.
Hochleistungsnetzwerkdienste
Beschleunigter Netzwerkbetrieb: Viele HPC-Workloads, z. B. seismische Verarbeitung, verarbeiten große Mengen von Daten, die in freigegebenen Dateisystemen wie Azure Blob, Azure NetApp Files, Lustre ClusterStor und anderen benutzerdefinierten Speicherlösungen gespeichert sind, auf die über das Netzwerk zugegriffen wird. Ein Hochleistungsnetzwerk ist entscheidend, um die Dauer von Datenübertragungen zu verkürzen.
Beschleunigter Netzwerkbetrieb bietet eine Verbindung mit hohem Durchsatz und geringen Wartezeiten zwischen den VMs und mit Azure-Diensten. Weitere Vorteile sind weniger Jitter und minimale CPU-Auslastung.
InfiniBand: Parallele HPC-Anwendungen, die auf MPI-Bibliotheken (Message Passing Interface) basieren, müssen möglicherweise beträchtliche Mengen an Daten zwischen vielen VMs übertragen. Die InfiniBand-Verbindung, die auf RDMA-fähigen VMs der H-Serie und der N-Serie verfügbar ist, stellt eine Verbindung mit niedrigen Wartezeiten und hoher Bandbreite bereit, um die Leistung und Skalierbarkeit von HPC- und Deep Learning-Anwendungen zu maximieren.
Beispiele für MPI-Aufträge sind Moleküldynamik, numerische Strömungsdynamik (Computational Fluid Dynamics, CFD), Simulation von Öl- und Gasreservoirs und sich neu entwickelnde verteilte Machine Learning-Workloads.
InfiniBand-Verbindungen sind nur zwischen virtuellen Computern möglich, die innerhalb derselben Platzierungsgruppe zugeordnet sind.
Azure ExpressRoute: Im Falle einer Burstanwendung wie einer Hybrideinrichtung für die Reservoirsimulation und -modellierung, bei der lokale Datasets gemeinsam genutzt werden und die Azure-Compute-Instanz zu einer Erweiterung wird, verbindet Express Route Ihre lokale Umgebung über eine private Verbindung mit der Microsoft Cloud. ExpressRoute bietet Resilienz und Verfügbarkeit auf Unternehmensniveau sowie den Vorteil eines globalen ExpressRoute-Partnerökosystems. Informationen zum Verbinden Ihres Netzwerks mit Microsoft mithilfe von ExpressRoute finden Sie unter ExpressRoute-Konnektivitätsmodelle.
ExpressRoute-Verbindungen werden nicht über das öffentliche Internet hergestellt und zeichnen sich im Vergleich zu herkömmlichen Internetverbindungen durch eine höhere Zuverlässigkeit und Geschwindigkeit sowie durch kürzere Wartezeiten aus. Für Point-to-Site-VPN und Site-to-Site-VPN können Sie lokale Geräte oder Netzwerke mit einem virtuellen Netzwerk verbinden, indem Sie eine beliebige Kombination dieser VPN-Optionen und Azure ExpressRoute verwenden.
Definieren einer Azure-Netzwerktopologie
Für Zielzonen auf Unternehmensebene werden zwei Netzwerktopologien unterstützt: eine basiert auf Azure Virtual WAN, und die andere (herkömmliche) Netzwerktopologie basiert auf der Hub-and-Spoke-Architektur. In diesem Abschnitt werden HPC-Konfigurationen und -Methoden für beide Bereitstellungsmodelle empfohlen.
Azure Virtual WAN: Verwenden Sie eine auf einem Virtual WAN basierende Netzwerktopologie, wenn Ihre Organisation Folgendes plant:
- Bereitstellen von Ressourcen in mehreren Azure-Regionen und Verbinden der globalen Standorte sowohl mit Azure als auch mit der lokalen Umgebung.
- Vollständiges Integrieren von softwaredefinierten WAN-Bereitstellungen mit Azure
- Bereitstellen von bis zu 2.000 VM-Workloads in allen VNets, die mit einem Virtual WAN-Hub verbunden sind.
Organisationen nutzen Azure Virtual WAN, um die Anforderungen an die Interkonnektivität im großen Stil zu erfüllen. Microsoft verwaltet diesen Dienst, um für Sie die allgemeine Komplexität des Netzwerks zu verringern und eine Modernisierung des Netzwerks Ihrer Organisation zu erzielen.
Hub-and-Spoke-Architektur: Verwenden Sie eine herkömmliche Azure-Netzwerktopologie, die auf der Hub-and-Spoke-Architektur basiert, wenn Ihre Organisation Folgendes plant:
- Bereitstellung von Ressourcen nur in ausgewählten Azure-Regionen.
- Kein globales verbundenes Netzwerk erforderlich.
- Wenige Remote- oder Zweigstandorte pro Region und weniger als 30 benötigte IP-Sicherheitstunnel (IPsec).
- Vollständige Kontrolle und Granularität für die manuelle Konfiguration des Azure-Netzwerks.
Die Konnektivität kann per lokalem und globalem VNET-Peering hergestellt werden. Dies sind die bevorzugten Ansätze, mit denen die Konnektivität zwischen Zielzonen für HPC-Bereitstellungen über mehrere Azure-Regionen hinweg sichergestellt werden kann.
Eingehende und ausgehende Internetkonnektivität
Da es sich bei nativen Azure-Netzwerksicherheitsdiensten, z. B. Azure Firewall, Azure Web Application Firewall in Application Gateway und Azure Front Door, um vollständig verwaltete Dienste handelt, fällt für Sie nicht der operative und verwaltungsbezogene Aufwand an, der mit Infrastrukturbereitstellungen verbunden ist und bei einem großen Umfang sehr komplex werden kann.
Entwurfsempfehlungen für die HPC-Implementierung:
- Für Kunden mit globaler Abdeckung dient Azure Front Door zur Unterstützung von HPC-Bereitstellungen, indem Richtlinien von Azure Web Application Firewall verwendet werden, um globale HTTP/S-Anwendungen für Azure-Regionen übergreifend bereitzustellen und zu schützen.
- Nutzen Sie Web Application Firewall-Richtlinien in Azure Front Door, wenn Sie diesen Dienst und Application Gateway verwenden, um HTTP/S-Anwendungen zu schützen. Sperren Sie Application Gateway so, dass nur Datenverkehr von Azure Front Door empfangen werden kann.
Anforderungen an die Netzwerkverschlüsselung
Entwurfsüberlegungen für HPC-Implementierungen:
- Datenverkehr wird derzeit nicht verschlüsselt, wenn Azure ExpressRoute zum Konfigurieren des privaten Peerings verwendet wird.
- Datenverkehr über ExpressRoute für HPC-Bereitstellungen muss nicht verschlüsselt sein. Für IPsec-Tunnel wird Internetdatenverkehr standardmäßig verschlüsselt, und die Ver- und Entschlüsselung kann eine negative Auswirkung auf die Leistung des Datenverkehrs haben.
Wichtige Empfehlungen für die Verschlüsselung von Netzwerken zwischen lokalen Umgebungen und Azure sowie in Azure-Regionen:
- Bestimmen Sie, ob HPC-Datenverkehr verschlüsselt werden soll. Machen Sie sich unter Netzwerktopologie und -konnektivität: Übersicht mit den Optionen für die Netzwerkverschlüsselung in Zielzonen auf Unternehmensebene vertraut.
- Planen Sie die IP-Adressierung in Azure, um Folgendes sicherzustellen:
- Der IP-Adressraum weist keine Überlappungen in Bezug auf lokale Standorte und Azure-Regionen auf.
- Das VNet enthält den richtigen Adressraum.
- Die richtige Planung für die Subnetzkonfiguration erfolgt bereits im Voraus.
Anforderungen an die Netzwerkbandbreite für Durchsatz und Wartezeiten
Sowohl ein reines „HPC in der Cloud“-Bereitstellungsmodell als auch das Hybrid Cloud-Bereitstellungsmodell hat seine eigenen Anforderungen an Wartezeiten und Durchsatz, je nachdem, wie die Workloads im Energiesektor lokal im Vergleich zu in der Cloud übermittelt und ausgeführt werden. Benutzer können HPC-Aufträge in vielen Bereitstellungsmodi – lokal oder in der Cloud – übermitteln.
- Einzelne Aufträge
- Überlegungen zur Konnektivität zwischen lokalem Standort und Azure bei Verwendung des Remotevisualisierungsdesktops
- Burstaufträge
- Überlegungen zum Einrichten des Netzwerks des Schedulers, der die Aufträge in der Cloud übermittelt
- Überlegungen zum Azure Batch-Netzwerk
- Parallele Workflows, sowohl lokal als auch in der Cloud
- Hybrid
- HPC-Cache
- Cloudbasiert
- Azure Kubernetes Service-Container
- Functions
MPI-Umgebungen sind dediziert, da sie einzigartige Anforderungen mit der Notwendigkeit einer Kommunikation mit geringen Wartezeiten zwischen Knoten haben. Die Knoten sind über eine Hochgeschwindigkeitsverbindung verbunden und können nicht für andere Workloads freigegeben werden. MPI-Anwendungen nutzen die gesamten Hochleistungsverbindungen mithilfe des Passthrough-Modus in virtualisierten Umgebungen. Speicher für MPI-Knoten ist in der Regel ein paralleles Dateisystem wie Lustre, auf das auch über die Hochgeschwindigkeitsverbindung zugegriffen wird.
Nächste Schritte
Die folgenden Artikel enthalten Anleitungen zu jedem Schritt der Journey zur Cloudeinführung für HPC-Umgebungen im Energiesektor.
- Azure-Abrechnung und Microsoft Entra-Mandanten für HPC im Energiesektor
- Identitäts- und Zugriffsverwaltung für Azure HPC im Energiesektor
- Verwaltung von Azure HPC im Energiesektor
- Plattformautomatisierung und DevOps für Azure HPC im Energiesektor
- Ressourcenorganisation für HPC im Energiesektor
- Governance für HPC in der Energiebranche
- Sicherheit für Azure HPC im Energiesektor
- Berechnen umfangreicher HPC-Anwendungsworkloads auf Azure-VMs
- Speicher für HPC-Umgebungen im Energiesektor
- Zielzonenbeschleuniger für Azure High Performance Computing (HPC)