Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Il servizio Microsoft Discovery integra l'intelligenza artificiale, i dati e l'hpc computing ad alte prestazioni in una singola piattaforma di ricerca. Il supercomputer Microsoft Discovery fornisce il livello HPC di questa piattaforma. Insieme ai pool di nodi, il Supercomputer esegue simulazioni, elaborazione di dati su larga scala e altri carichi di lavoro a elevato utilizzo di calcolo per conto degli agenti di individuazione e degli utenti umani.
Overview
Microsoft Discovery Supercomputer consente di accedere alle risorse HPC Microsoft che si estendono su migliaia di core in più architetture, incluse CPU e GPU. I pool di nodi raggruppano queste risorse in modo che i carichi di lavoro possano essere pianificati in base all'hardware adatto ai requisiti del carico di lavoro. Gli agenti di individuazione inviano carichi di lavoro al supercomputer, che seleziona un pool di nodi appropriato e gestisce l'esecuzione.
Funzionalità principali
- Esecuzione parallela. Il supercomputer esegue contemporaneamente carichi di lavoro fino a un limite configurabile. I processi successivi vengono accodati e avviati man mano che si rende disponibile capacità.
- Sicurezza e conformità aziendali. Tutti i processi vengono eseguiti all'interno del tenant Azure ed ereditano i controlli di conformità e sicurezza esistenti. I dati di origine, i modelli e i risultati intermedi rimangono nella sottoscrizione.
- Capacità elastica. Le risorse vengono ridimensionate su richiesta entro limiti definiti, da alcuni processi simultanei a decine di migliaia.
- Diversità hardware. L'hardware supportato comprende GPU, processori x86 di Intel e AMD e processori basati su ARM. I nuovi tipi di processori Azure diventano disponibili senza ritardi nell'approvvigionamento.
Pool di nodi
Un pool di nodi è l'unità granulare che Discovery utilizza per organizzare un insieme di risorse di calcolo simili. Ogni pool di nodi definisce la configurazione di calcolo e di memoria dei propri membri, in modo che Discovery possa allocare i carichi di lavoro sul cluster appropriato. Ogni pool imposta anche il limite di parallelismo per i carichi di lavoro pianificati.
Un pool di nodi specifica gli attributi seguenti:
- Profilo hardware (dimensione) indica i tipi di macchina virtuale (VM) di Azure utilizzati da tutti i nodi del pool. Ad esempio, un pool di GPU potrebbe usare macchine virtuali serie ND con GPU NVIDIA Blackwell Ultra e CPU Grace per carichi di lavoro di intelligenza artificiale, mentre un pool di CPU potrebbe usare processori AMD, Intel o Cobalt ARM per HPC tradizionale. Discovery Supercomputer supporta un'ampia gamma di Azure HPC per carichi di lavoro specializzati, ad esempio carichi di lavoro gpu, memoria elevata e tipi di vm con scalabilità orizzontale leggera.
- La capacità indica il numero massimo di macchine virtuali che il pool può eseguire. Un pool può avere zero nodi quando è inattivo e aumentare fino al massimo configurato. La capacità è soggetta ai limiti del tuo abbonamento.
- La rete e la posizione definiscono il modo in cui i nodi in un pool si collegano a una subnet di rete virtuale designata che consente loro di raggiungere i servizi della piattaforma, ad esempio l'archiviazione e il sistema di orchestrazione supercomputer. Un pool di nodi si trova nella stessa area Azure e nella rete virtuale del supercomputer per fornire un'interconnessione a bassa latenza per carichi di lavoro MPI (Message Passing Interface) e condivisione dei dati.
- Assegnazione del carico di lavoro. Un pool di nodi può essere dedicato a un carico di lavoro, a un team o a un progetto specifico per supportare l'isolamento e il rilevamento dei processi.
Poiché le risorse di Azure sono virtuali, dimensionare un pool per un carico di lavoro di picco non comporta sprechi di risorse quando il pool è inattivo. Gli amministratori possono applicare limiti di concorrenza per pool e utenti e agenti inviano carichi di lavoro al pool più adatti alle proprie esigenze.
Configurazioni del pool di nodi
I carichi di lavoro hanno caratteristiche di elaborazione diverse. Alcuni sono ottimizzati per le operazioni vettoriali o tensori; altri sono ottimizzati per il calcolo scalare. I pool di nodi consentono di associare l'hardware al carico di lavoro.
Categorie di hardware
- Pool di nodi con accelerazione GPU Macchine virtuali dotate di GPU, adatte al training di Deep Learning, alle dinamiche molecolari e ad altri algoritmi che traggono vantaggio dall'accelerazione GPU. Un pool di serie ND con GPU NVIDIA Blackwell, ad esempio, offre una velocità effettiva elevata nei calcoli di matrice ed è particolarmente adatto per la chimica computazionale, genomica ed elaborazione delle immagini.
- Pool di nodi ottimizzati per la CPU Macchine virtuali con CPU ad alte prestazioni per carichi di lavoro che scalano con core o memoria, ma che non traggono vantaggio dalle GPU, come i carichi di lavoro HPC tradizionali e di Electronic Design Automation (EDA), l'analisi statistica e l'elaborazione dei dati. Le macchine virtuali CPU a basso costo sono appropriate anche per la pre-elaborazione, l'orchestrazione e il controllo dei carichi di lavoro.
- Pool di nodi specializzati. Dimensioni delle macchine virtuali che soddisfano requisiti hardware specializzati, ad esempio FPGA.
Un singolo supercomputer può combinare più categorie hardware per supportare diversi calcoli scientifici su una sola piattaforma. Ad esempio, un'organizzazione farmaceutica potrebbe gestire un pool GPU per la generazione di molecole guidate dall'intelligenza artificiale, un secondo pool GPU per la simulazione e un pool di CPU per l'elaborazione di dati sperimentali. Un team di ingegneria del processore potrebbe associare un pool GPU per la simulazione elettromagnetica a un pool di CPU per la verifica della progettazione.
Ridimensionamento dei modelli
- Pool di nodi con scalabilità automatica (su richiesta). Configurazione predefinita. Il pool non ha nodi in esecuzione quando è inattivo. Il provisioning dei nodi viene effettuato quando i carichi di lavoro vengono inviati e deallocati al termine dei processi, fino al massimo configurato. Questo modello è conveniente in termini di costi per carichi di lavoro intermittenti o sporadici.
- Pool di nodi persistenti (sempre attivi). Configurato con un numero minimo di nodi maggiore di zero. I pool persistenti garantiscono la capacità disponibile per i carichi di lavoro sensibili alla latenza al costo del consumo di macchine virtuali inattive.
Prerequisiti e artefatti
Per una distribuzione supercomputer sono necessari gli artefatti seguenti: rete virtuale e subnet, identità gestite, immagini del contenitore e definizioni di risorse per gli strumenti.
Infrastruttura di rete
Il supercomputer viene eseguito nell'ambiente Azure, quindi si fornisce la configurazione di rete che integra il cluster HPC con i controlli di sicurezza e rete aziendali.
Il supercomputer richiede una rete virtuale Azure e usa due subnet, una per i componenti di orchestrazione e gestione del sistema e una seconda per i nodi di calcolo. Entrambe le subnet devono trovarsi nella stessa rete virtuale e la subnet di sistema deve avere connettività alle subnet del pool di nodi in modo che il piano di controllo possa coordinare la pianificazione e i controlli di integrità.
CIDR dei Pod e CIDR dei Service
Il cluster AKS sottostante del Supercomputer utilizza intervalli separati di indirizzi IP per i pod e per i servizi Kubernetes, denominati Pod CIDR e Service CIDR. Questi intervalli vengono configurati intenzionalmente all'esterno dello spazio degli indirizzi della rete virtuale e vengono usati esclusivamente per la rete Kubernetes interna.
CIDR pod
Il CIDR pod è l'intervallo di indirizzi IP da cui Kubernetes assegna indirizzi IP ai pod dell'applicazione in esecuzione nel cluster. Ogni pod riceve un indirizzo IP dall'intervallo CIDR pod, abilitando la comunicazione diretta da pod a pod all'interno del cluster.
CIDR del servizio
Il CIDR del servizio è l'intervallo di indirizzi IP usato per i servizi Kubernetes (servizi ClusterIP). A ogni servizio viene assegnato un indirizzo IP virtuale da questo intervallo. Questi IP virtuali forniscono un endpoint stabile per l'accesso alle applicazioni, indipendentemente da quali pod stiano attualmente gestendo il traffico.
Perché questi intervalli CIDR non rientrano nello spazio di indirizzi della rete virtuale
Nel cluster AKS del supercomputer, il CIDR dei pod e il CIDR dei servizi sono configurati all'esterno dello spazio di indirizzi della VNet per i motivi seguenti:
- Separazione dell'infrastruttura e della rete Kubernetes. Lo spazio di indirizzi della VNet viene utilizzato per risorse dell'infrastruttura quali nodi di AKS, macchine virtuali, bilanciatori del carico, endpoint privati e altri servizi di Azure. Intervalli CIDR separati impediscono conflitti tra gli indirizzi IP dell'infrastruttura e gli indirizzi IP gestiti da Kubernetes.
- Miglioramento dell'utilizzo degli indirizzi IP. I pod possono essere ridimensionati rapidamente e utilizzare un numero elevato di indirizzi IP. Un CIDR per pod dedicato supporta carichi di lavoro su larga scala senza esaurire lo spazio degli indirizzi della rete virtuale. Ciò è particolarmente utile quando si usa la rete Azure CNI Overlay, in cui gli indirizzi IP dei pod vengono gestiti in modo indipendente dalla VNet.
- Gestione semplificata della rete. Mantenere separati i CIDR dei pod e dei servizi semplifica la pianificazione dell'allocazione degli indirizzi di rete, evitare l'esaurimento, gestire la crescita del cluster e risolvere i problemi di rete.
- Prevenzione dei conflitti di instradamento. Il CIDR dei Pod e il CIDR dei servizi non devono sovrapporsi allo spazio degli indirizzi della rete virtuale di AKS, alle reti virtuali connesse tramite peering, alle reti locali on-premises connesse tramite VPN o ExpressRoute o ad altri intervalli di rete dei cluster AKS. L'uso di intervalli di indirizzi dedicati e non sovrapposti garantisce un comportamento di routing prevedibile.
Configurazione di esempio
| Componente | Intervallo CIDR |
|---|---|
| VNet | 10.100.0.0/16 |
| Subnet del nodo AKS | 10.100.1.0/24 |
| CIDR pod | 10.244.0.0/16 |
| CIDR del servizio | 10.0.0.0/16 |
In questo esempio, i nodi AKS ricevono indirizzi IP dalla subnet della rete virtuale (10.100.1.0/24), i pod ricevono indirizzi IP dal CIDR dei pod (10.244.0.0/16) e i servizi Kubernetes ricevono indirizzi IP virtuali dal CIDR dei servizi (10.0.0.0/16).
Importante
La pianificazione corretta degli intervalli CIDR non sovrapposti è essenziale per le distribuzioni di Supercomputer riuscite e la crescita futura del cluster. Assicurarsi che gli intervalli Pod CIDR e Service CIDR non siano in conflitto con alcuna rete raggiungibile dalla VNet.
Sicurezza e identità
Il supercomputer usa Azure identità gestite per interagire con altri servizi di Azure e per gestire le macchine virtuali.
- Identità del cluster. Identità gestita assegnata dall'utente che si assegna al Supercomputer durante la distribuzione. Il piano di controllo utilizza questa identità per eseguire operazioni sul cluster, ad esempio il montaggio dello spazio di archiviazione e il recupero delle immagini del contenitore da Registro Azure Container (ACR).
- Identità del nodo (kubelet). Una seconda identità gestita, assegnata alle macchine virtuali del nodo, che concede loro l'accesso a risorse come ACR per le immagini degli strumenti. L'identità kubelet può avere un ambito più ristretto rispetto all'identità del cluster, ma deve avere il ruolo Managed Identity Operator sull'identità del cluster. Questa disposizione consente alle macchine virtuali del nodo di usare privilegi di identità del cluster per operazioni specifiche senza esporre le credenziali, mantenendo la separazione tra il piano di controllo e il piano del nodo.
- Identità dei carichi di lavoro. Discovery supporta identità separate per i piani di elaborazione, amministrazione e gestione del supercomputer. Le identità del carico di lavoro consentono agli strumenti di usare Azure gestione delle identità senza dover gestire i segreti.
- Accesso al Registro di immagini. Le immagini dei contenitori degli strumenti sono in genere archiviate in ACR o in un altro registro di contenitori. Le identità di Supercomputer richiedono l'accesso in modalità pull. Configurare ACR affinché consideri attendibile l'identità gestita del Supercomputer tramite Microsoft Entra ID, anziché gestire direttamente le credenziali Docker.
- Gruppo di risorse gestite. La creazione di un supercomputer crea un gruppo di risorse gestite nella sottoscrizione che contiene le risorse Azure sottostanti, ad esempio set di scalabilità di macchine virtuali. Discovery gestisce questo gruppo di risorse per conto dell'utente, distinto dagli altri gruppi di risorse. Assicurarsi che la sottoscrizione disponga di una quota sufficiente per le dimensioni della macchina virtuale che si prevede di usare. L'eliminazione del supercomputer rimuove il gruppo di risorse gestite.
Immagini del contenitore degli strumenti e ambiente software
Gli strumenti di individuazione vengono eseguiti in Supercomputer usando contenitori Docker. L'immagine deve contenere i file binari, le librerie e il codice richiesti da uno strumento. Le immagini devono essere compatibili con il sistema operativo del nodo, che è Linux per impostazione predefinita. Quando viene eseguito uno strumento, la piattaforma scarica la relativa immagine dal registry configurato sul nodo assegnato. Gli strumenti Bring Your Own devono includere tutti i driver che non sono presenti nell'immagine di base.
Sequenza di distribuzione
La sequenza seguente illustra come vengono distribuiti e usati i componenti.
- Creare il supercomputer (piano di controllo). Un amministratore distribuisce una risorsa Supercomputer tramite il portale di Azure, l'interfaccia della riga di comando di Azure (interfaccia della riga di comando di Azure) o un modello ARM. La distribuzione specifica un nome e un'area, collega la subnet richiesta e assegna le identità gestite.
- Effettuare il provisioning del cluster HPC (piano dati). L'individuazione crea automaticamente un gruppo di risorse gestito e distribuisce le risorse per il cluster, richiede la configurazione della subnet e l'ambiente di base.
- Definire i pool di nodi (piano di controllo). L'amministratore crea uno o più pool di nodi per il supercomputer, specificando le dimensioni della macchina virtuale, la subnet del nodo e i parametri di ridimensionamento. Individuazione gestisce i set di scalabilità di macchine virtuali corrispondenti nel gruppo di risorse gestito. I pool possono iniziare con zero nodi quando la scalabilità automatica è abilitata o con il minimo configurato quando persistente.
- Registrare strumenti e agenti (piano di controllo). Gli autori degli strumenti registrano gli strumenti nel catalogo Discovery, fornendo l'ubicazione dell'immagine del container e i requisiti di risorse di ciascuno strumento. Gli agenti possono quindi richiamare gli strumenti registrati.
- Eseguire i carichi di lavoro (piano dati). Quando un utente avvia un'attività tramite Copilot o un workflow dell'agente, Discovery orchestra l'esecuzione e invoca gli strumenti necessari nei pool di nodi appropriati.
- Monitorare e completare le attività. Il piano di controllo monitora i processi in esecuzione tramite code di processi, log e controlli di integrità. Gli utenti ricevono gli aggiornamenti dello stato tramite Copilot. Quando un'attività termina, i risultati vengono scritti nello spazio di archiviazione designato e il contenitore si arresta. I nodi inattivi vengono deallocati nei pool con scalabilità automatica.
- Iterare e scalare. Gli utenti possono esaminare i risultati e avviare esecuzioni successive, se necessario. I pool di nodi si ridimensionano su richiesta e gli amministratori possono ridimensionare i pool esistenti o aggiungerne di nuovi man mano che i carichi di lavoro si evolvono.
Integrazione con Microsoft. Individuazione/archiviazione
Discovery integra il Supercomputer con l'archiviazione HPC di Azure tramite il tipo di risorsa Microsoft.Discovery/storages. Per i carichi di lavoro che richiedono l'archiviazione file ad alte prestazioni, Azure NetApp Files è un'opzione appropriata.
DataContainers e risorse di dati
Oltre all'infrastruttura di archiviazione, Discovery gestisce i dati scientifici tramite DataContainers e asset di dati. Entrambi sono integrali alla pipeline di esecuzione degli strumenti e sono definiti in Progetti di individuazione.
Contenitori di dati
Un DataContainer è un archivio logico di dati che astrae la tecnologia di archiviazione sottostante e fornisce un'interfaccia coerente agli agenti IA in Archiviazione BLOB di Azure, Discovery Storage e altri backend. DataContainers forniscono:
- Astrazione di archiviazione. Accesso unificato tra back-end di archiviazione.
- Controllo dell'accesso. Gestione delle credenziali per l'accesso sicuro.
- Integrazione. Punto di integrazione definito tra risorse di archiviazione e strumenti di ricerca.
DataContainers sono rappresentati come risorse Microsoft.Discovery.DataContainer collegate a specifici account di archiviazione o volumi.
Asset di dati
Un asset di dati rappresenta un singolo file, un set di dati o una raccolta all'interno di un Oggetto DataContainer. Gli asset di dati forniscono:
- Organizzazione. Raggruppamento per attività, processo o progetto.
- Provenienza. Una registrazione dell'origine e delle trasformazioni dei dati.
- Metadati. Attributi descrittivi che migliorano l'individuabilità.
- I/O dello strumento. Meccanismo strutturato per gli strumenti per l'utilizzo e la produzione di dati.
I metadati degli asset di dati descrivono il contenuto, il formato e le relazioni di un asset, consentendo agli asset di partecipare a flussi di lavoro complessi.