Produzione della topologia e della connettività di rete HPC

Queste linee guida si basa sulle considerazioni e sulle raccomandazioni definite nell'articolo Zona di destinazione di Azure per la topologia e la connettività di rete. Seguendo le indicazioni riportate in questo articolo, è possibile esaminare le principali considerazioni sulla progettazione e le procedure consigliate per la rete e la connettività da e verso le distribuzioni di Microsoft Azure e HPC.

Pianificare l'indirizzo IP, la rete virtuale e le subnet

È fondamentale pianificare le esigenze degli indirizzi IP in Azure per assicurarsi che:

  • Lo spazio di indirizzi IP non si sovrapponga tra i percorsi locali e le aree di Azure.
  • È possibile eseguire il peering di reti virtuali future a reti virtuali esistenti o pianificate.
  • La rete virtuale contenga lo spazio di indirizzi corretto.
  • La pianificazione appropriata per la configurazione della subnet venga eseguita in anticipo.
  • L'indirizzamento in eccesso sufficiente è considerato per l'espansione futura o altri servizi

Considerazioni sulla progettazione della produzione HPC

Prendere in considerazione la creazione di subnet separate per assegnare indirizzi IP tra i componenti funzionali dell'ambiente. Ad esempio, una rete virtuale HPC dedicata può includere le subnet seguenti:

  • Calcolo
  • Archiviazione
  • Infrastruttura
  • Visualizzazione
  • Accesso
  • ANF
  • Cache HPC

Diversi servizi, ad esempio Azure NetApp Files, azure Cache HPC e future offerte di archiviazione richiedono subnet delegate dedicate per il corretto funzionamento. Assicurarsi di pianificare lo spazio di indirizzamento appropriato se si sta valutando uno di questi servizi.

Configurare il DNS e la risoluzione dei nomi per le risorse in locale e di Azure

Domain Name System (DNS) è un aspetto fondamentale della progettazione nell'architettura generale della zona di destinazione di Azure. Alcune organizzazioni possono ritenere opportuno usare gli investimenti esistenti in DNS, mentre altre possono vedere l'adozione del cloud come un'opportunità per modernizzare l'infrastruttura DNS interna e usare le funzionalità native di Azure.

Considerazioni sulla progettazione della rete HPC

I consigli seguenti si riferiscono al caso in cui il nome DNS o virtuale di una macchina virtuale non cambia durante la migrazione.

Caso d'uso:

  • I nomi DNS e virtuali in background connettono molte interfacce di sistema negli ambienti HPC. I clienti sono a volte consapevoli solo delle interfacce definite dagli sviluppatori nel tempo. Le problematiche di connessione si verificano tra vari sistemi quando i nomi virtuali o DNS cambiano dopo le migrazioni. È consigliabile conservare gli alias DNS per evitare questi tipi di difficoltà.
  • Usare zone DNS diverse per distinguere gli ambienti (sandbox, sviluppo, pre-produzione e produzione) tra loro. L'eccezione riguarda le distribuzioni HPC con la propria rete virtuale. In questo caso, le zone DNS private potrebbero non essere necessarie.
  • Il supporto DNS è obbligatorio durante l'uso della cache HPC in modo che possa accedere all'archiviazione e ad altre risorse.

Servizi di rete ad alte prestazioni

Rete accelerata

Molti carichi di lavoro HPC (ad esempio, l'elaborazione sismica) richiedono l'elaborazione di una grande quantità di dati. I dati vengono archiviati in file system condivisi di grandi dimensioni, ad esempio BLOB di Azure, Azure NetApp Files, Lustre ClusterStor e altre soluzioni di archiviazione personalizzate a cui si accede tramite la rete. È fondamentale affidarsi a una rete ad alte prestazioni per ridurre il tempo necessario per i trasferimenti di dati.

L'abilitazione della rete accelerata offre alle macchine virtuali una connessione ad alta velocità effettiva e bassa latenza tra di essi e da e verso i servizi di Azure, insieme a un ridotto instabilità e un utilizzo minimo della CPU.

InfiniBand

Le applicazioni HPC parallele che si basano su librerie MPI (Message Passing Interface) potrebbero richiedere un trasferimento significativo di informazioni tra molte macchine virtuali. L'interconnessione InfiniBand disponibile nelle macchine virtuali serie H e serie N con supporto per RDMA offre la bassa latenza e la larghezza di banda elevata necessarie per ottimizzare le prestazioni e la scalabilità delle applicazioni HPC e intelligenza artificiale.

Alcuni esempi di processi MPI includono:

  • Dinamica molecolare
  • Fluidodinamica computazionale
  • Simulazione di petrolio e serbatoio di gas
  • Carichi di lavoro di Machine Learning distribuiti emergenti nella produzione

La connessione InfiniBand è possibile solo tra le macchine virtuali allocate all'interno dello stesso gruppo di posizionamento.

Azure ExpressRoute

  • Se è presente un'applicazione burst come una configurazione ibrida per la simulazione e la modellazione dei serbatoi, in cui i set di dati locali vengono condivisi e il calcolo di Azure diventa un'estensione, Express Route consente di connettere l'ambiente locale a Microsoft Cloud tramite una connessione privata con l'aiuto di un provider di connettività. Offre resilienza e disponibilità di livello aziendale e il vantaggio di un ecosistema di partner ExpressRoute globale. Per informazioni sulla procedura di connessione della rete a Microsoft tramite ExpressRoute, vedere Modelli di connettività di ExpressRoute.
  • Le connessioni ExpressRoute non usano la rete Internet pubblica e offrono maggiore affidabilità, velocità più elevate e latenze più basse rispetto alle connessioni Internet tradizionali. Per vpn da punto a sito e VPN da sito a sito, è possibile connettere dispositivi o reti locali a una rete virtuale usando qualsiasi combinazione di queste opzioni VPN e Azure ExpressRoute.

Definire una topologia di rete di Azure

Le zone di destinazione di livello aziendale supportano due topologie di rete: una basata su rete WAN virtuale di Azure e l'altra su una topologia di rete tradizionale con architettura hub-spoke. Questa sezione consiglia configurazioni e procedure HPC per entrambi i modelli di distribuzione.

Usare una topologia di rete basata sulla rete WAN virtuale se l'organizzazione prevede di:

  • Distribuire le risorse in diverse aree di Azure e connettere le località globali ad Azure e in locale.
  • Integrare completamente le distribuzioni WAN software-defined con Azure.
  • Distribuire fino a 50.000 carichi di lavoro di macchine virtuali in tutte le reti virtuali connesse a un unico hub rete WAN virtuale.

Le organizzazioni usano la rete WAN virtuale per soddisfare i requisiti di interconnettività su larga scala. Microsoft gestisce questo servizio, che consente di ridurre la complessità complessiva della rete e modernizzare la rete dell'organizzazione.

Usare una topologia di rete di Azure tradizionale basata sull'architettura hub-spoke se l'organizzazione:

  • Prevede di distribuire le risorse solo in aree di Azure selezionate.
  • Non è necessaria una rete globale interconnessa.
  • Dispone di poche località remote o di succursali per area e richiede meno di 30 tunnel di sicurezza IP (IPsec).
  • Richiede il controllo completo e la granularità per configurare manualmente la rete di Azure.
  • Usa il peering reti virtuali locali e globali per fornire la connettività. Il peering reti virtuali locali e globali è l'approccio preferito per garantire la connettività tra le zone di destinazione per le distribuzioni HPC in più aree di Azure.

Pianificare la connettività Internet in ingresso e in uscita

Questa sezione descrive i modelli per la connettività in ingresso e in uscita da e verso la rete Internet pubblica. I servizi di sicurezza di rete nativi di Azure, ad esempio Firewall di Azure, Azure Web application firewall in gateway applicazione e Frontdoor di Azure sono servizi completamente gestiti. Pertanto, non vengono addebitati i costi operativi e di gestione associati alle distribuzioni dell'infrastruttura, che possono diventare complessi su larga scala.

Suggerimenti per la progettazione per l'implementazione HPC:

  • Per i clienti con footprint globale, Frontdoor di Azure consente alle distribuzioni HPC di usare i criteri di Web application firewall di Azure per distribuire e proteggere le applicazioni HTTP/S globali tra aree di Azure.
  • Sfruttare i Web application firewall criteri in Frontdoor di Azure quando si usa questo servizio e gateway applicazione di Azure per proteggere le applicazioni HTTP/S. Bloccare il gateway applicazione di Azure per la ricezione del traffico solo dal servizio Frontdoor di Azure.

Definire i requisiti di crittografia di rete

Questa sezione illustra le raccomandazioni chiave per crittografare le reti tra l'ambiente locale e Azure e tra aree di Azure.

Considerazioni sulla progettazione per le implementazioni HPC:

  • Il traffico non è attualmente crittografato quando si usa Azure ExpressRoute per configurare il peering privato.
  • Non è necessario crittografare il traffico tramite ExpressRoute per le distribuzioni HPC. I tunnel IPsec crittografano il traffico Internet per impostazione predefinita. La crittografia o la decrittografia potrebbero influire negativamente sulle prestazioni del traffico.

Spetta al cliente determinare se il traffico HPC deve essere crittografato. Esaminare la connettività e la topologia di rete per comprendere le opzioni di crittografia di rete nelle zone di destinazione di livello aziendale.

È fondamentale pianificare le esigenze degli indirizzi IP in Azure per assicurarsi che:

  • Lo spazio di indirizzi IP non si sovrapponga tra i percorsi locali e le aree di Azure.
  • La rete virtuale contenga lo spazio di indirizzi corretto.
  • La pianificazione appropriata per la configurazione della subnet venga eseguita in anticipo.

Definire e requisiti di rete per la latenza della velocità effettiva

  • Sia HPC nel modello di distribuzione Cloud Only che HPC Cloud Hybrid hanno esigenze di latenza di rete e connettività e velocità effettiva a seconda del modo in cui si inviano ed eseguono i processi del flusso di lavoro di produzione e del carico di lavoro in locale rispetto al cloud. Gli utenti possono inviare processi HPC in molte modalità di distribuzione (da locale o cloud).
    • Processi singoli
      • Considerazioni sulla connettività locale per Azure se si usa desktop di visualizzazione remota
    • Processi burst
      • Considerazioni sulla rete di configurazione dell'utilità di pianificazione, che inviano i processi nel cloud
      • Azure Batch considerazioni sulla rete
    • Flussi di lavoro paralleli (sia locali che cloud)
    • Ibrido
      • Cache HPC
    • App native del cloud
      • Contenitori KS
      • Funzioni
  • Gli ambienti MPI sono dedicati in quanto hanno requisiti univoci con una necessità di comunicazioni a bassa latenza tra nodi. I nodi si connettono tramite l'interconnessione ad alta velocità e non possono essere condivisi con altri carichi di lavoro. Le applicazioni MPI usano l'intera interconnessione ad alte prestazioni tramite la modalità pass-through negli ambienti virtualizzati. L'archiviazione per i nodi MPI è in genere un file system parallelo come Lustre a cui viene eseguito l'accesso tramite l'interconnessione ad alta velocità.

Diagramma che mostra InfiniBand.

Passaggi successivi

Gli articoli seguenti forniscono indicazioni su ogni passaggio nel percorso di adozione del cloud per gli ambienti HPC di produzione.