Topologia di rete e connettività per Azure HPC in energia

  • Articolo

Le linee guida contenute in questo articolo consentono di esaminare le considerazioni di progettazione e le procedure consigliate correlate alla rete e alla connettività per le distribuzioni di Microsoft Azure e HPC (High Performance Computing). I suggerimenti seguenti si basano sulle considerazioni e sulle raccomandazioni definite nell'articolo Zona di destinazione di Azure per la topologia e la connettività di rete.

Indirizzamento IP, reti virtuali e subnet

È fondamentale pianificare l'indirizzamento IP in Azure per garantire 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 contiene lo spazio indirizzi corretto.
  • La pianificazione appropriata per la configurazione della subnet venga eseguita in anticipo.
  • Un numero sufficiente di indirizzi in eccesso è considerato per l'espansione futura o altri servizi.

Considerazioni relative alla progettazione

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
  • Storage
  • Infrastruttura
  • Visualizzazione
  • Eseguire l'accesso
  • Azure NetApp Files
  • Cache HPC di Azure

I servizi come Azure NetApp Files, Azure Cache HPC e future offerte di archiviazione richiedono subnet delegate dedicate per il corretto funzionamento. Assicurarsi che lo spazio di indirizzamento appropriato sia pianificato se uno di questi servizi è in considerazione.

Risoluzione dei nomi e DNS per le risorse locali e di Azure

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

Considerazioni sulla progettazione DNS: seguire queste indicazioni quando il nome DNS o virtuale di una macchina virtuale non cambia durante la migrazione.

  • I nomi DNS e virtuali in background connettono molte interfacce di sistema in ambienti HPC e i clienti sono a volte consapevoli solo delle interfacce definite dagli sviluppatori nel tempo. Connessione problemi si verificano tra vari sistemi quando i nomi DNS o virtuali cambiano dopo le migrazioni, pertanto è consigliabile conservare gli alias DNS per evitare questi tipi di difficoltà.
  • Usare zone DNS diverse per distinguere gli ambienti tra loro, ad esempio sandbox, sviluppo, preproduzione e produzione. L'eccezione riguarda le distribuzioni HPC con la propria rete virtuale, che potrebbe non richiedere zone DNS private.
  • Il supporto DNS è obbligatorio quando si usa la cache HPC in modo da poter 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, elaborano grandi quantità di dati archiviati in file system condivisi come BLOB di Azure, Azure NetApp Files, Lustre ClusterStor e altre soluzioni di archiviazione personalizzate accessibili tramite la rete. Una rete ad alte prestazioni è fondamentale per ridurre il tempo per i trasferimenti di dati.

    La rete accelerata offre una connessione a bassa latenza e velocità effettiva elevata tra le macchine virtuali e i servizi di Azure. Altri vantaggi includono una riduzione dell'instabilità e un utilizzo minimo della CPU.

  • InfiniBand: applicazioni HPC parallele che si basano su librerie MPI (Message Passing Interface) potrebbero dover trasferire quantità significative di dati tra molte macchine virtuali. L'interconnessione InfiniBand, disponibile nelle macchine virtuali serie H e serie N compatibili con RDMA, offre una connessione a bassa latenza e larghezza di banda elevata per ottimizzare le prestazioni e la scalabilità delle applicazioni HPC e deep learning.

    Diagram of InfiniBand connection between VMs.

    Alcuni esempi di processi MPI includono dinamiche molecolari, fluidodinamica computazionale, simulazione di serbatoi di petrolio e gas e carichi di lavoro di Machine Learning distribuiti emergenti.

    Le connessioni InfiniBand sono possibili solo tra le macchine virtuali allocate all'interno dello stesso gruppo di posizionamento.

  • Azure ExpressRoute: nel caso di un'applicazione burst come una configurazione ibrida per la simulazione e la modellazione del serbatoio, in cui i set di dati locali vengono condivisi e il calcolo di Azure diventa un'estensione, ExpressRoute connette l'ambiente locale al cloud Microsoft tramite una connessione privata. ExpressRoute 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 passano sulla rete Internet pubblica e offrono maggiore affidabilità, velocità più veloci e una latenza inferiore rispetto alle connessioni Internet tipiche. 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.

Definizione di una topologia di rete di Azure

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

  • Azure rete WAN virtuale: usare una topologia di rete basata su una 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 2.000 carichi di lavoro di macchine virtuali in tutte le reti virtuali connesse a un hub della rete WAN virtuale.

    Le organizzazioni usano Azure rete WAN virtuale per soddisfare 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.

  • Architettura hub-spoke: 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 e interconnessa.
    • Include poche posizioni remote o di succursali per area e richiede meno di 30 tunnel di sicurezza IP (IPsec).
    • Richiede controllo completo e granularità per configurare manualmente la rete di Azure.

    Il peering di reti virtuali locali e globali offre connettività e sono gli approcci preferiti per garantire la connettività tra le zone di destinazione per le distribuzioni HPC in più aree di Azure.

Connettività Internet in ingresso e in uscita

Poiché i servizi di sicurezza di rete nativi di Azure, come Firewall di Azure, Web application firewall di Azure nel gateway applicazione e Frontdoor di Azure, sono servizi completamente gestiti, non si incorre nei costi operativi e di gestione associati alle distribuzioni dell'infrastruttura, che può diventare complessa su larga scala.

Consigli di progettazione per l'implementazione HPC:

  • Per i clienti con footprint globale, Frontdoor di Azure aiuta le distribuzioni HPC usando i criteri di Web application firewall di Azure per distribuire e proteggere le applicazioni HTTP/S globali tra aree di Azure.
  • Sfruttare i criteri di Web application firewall di Azure nel servizio Frontdoor di Azure quando si usano quest'ultimo e il gateway applicazione per proteggere le applicazioni HTTP/S. Bloccare il gateway applicazione per la ricezione del traffico solo dal servizio Frontdoor di Azure.

Requisiti di crittografia di rete

Considerazioni sulla progettazione per le implementazioni HPC:

  • Quando Azure ExpressRoute viene usato per configurare il peering privato, il traffico non è crittografato.
  • Non è necessario crittografare il traffico tramite ExpressRoute per le distribuzioni HPC. I tunnel IPsec crittografano il traffico Internet per impostazione predefinita e la crittografia o la decrittografia può influire negativamente sulle prestazioni del traffico.

Raccomandazioni chiave per la crittografia delle reti tra l'ambiente locale e Azure e tra aree di Azure:

  • 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.
  • Pianificare l'indirizzamento 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 contiene lo spazio indirizzi corretto.
    • La pianificazione appropriata per la configurazione della subnet venga eseguita in anticipo.

Requisiti di rete per la latenza della velocità effettiva

Sia HPC nel cloud che nei modelli di distribuzione cloud ibrido hanno requisiti di latenza e velocità effettiva specifici, a seconda del modo in cui i carichi di lavoro energetici vengono inviati ed eseguiti in locale rispetto agli ambienti cloud. Gli utenti possono inviare processi HPC in molte modalità di distribuzione, dall'ambiente locale o nel cloud.

  • Processi singoli
    • Considerazioni sulla connettività da locale ad Azure se viene usato desktop di visualizzazione remota
  • Processi burst
    • Considerazioni sulla rete per l'installazione dell'utilità di pianificazione che inviano i processi nel cloud
    • Considerazioni sulla rete di Azure Batch
  • Flussi di lavoro paralleli, sia locali che nel cloud
  • Ibrido
    • Cache HPC
  • Nativo del cloud
    • contenitori servizio Azure Kubernetes
    • Funzioni

Gli ambienti MPI sono dedicati in quanto hanno requisiti univoci con la necessità di comunicazioni a bassa latenza tra nodi. I nodi sono connessi tramite interconnessione ad alta velocità e non possono essere condivisi con altri carichi di lavoro. Le applicazioni MPI usano intere interconnessioni ad alte prestazioni usando la modalità pass-through in ambienti virtualizzati. Archiviazione per i nodi MPI è in genere un file system parallelo come Lustre, accessibile anche tramite l'interconnessione ad alta velocità.

Passaggi successivi

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