Prerequisiti del file system gestito di Lustre di Azure
Questo articolo illustra i prerequisiti che è necessario configurare prima di creare un file system lustre gestito di Azure.
Prerequisiti di rete
I file system lustre gestiti di Azure esistono in una subnet di rete virtuale. La subnet contiene il servizio gestione lustre (MGS) e gestisce tutte le interazioni client con il cluster lustre virtuale.
Non è possibile spostare un file system da una rete o subnet a un'altra dopo aver creato il file system.
Lustre gestito di Azure accetta solo indirizzi IPv4. IPv6 non è supportato.
Requisiti delle dimensioni di rete
Le dimensioni della subnet necessarie dipendono dalle dimensioni del file system creato. La tabella seguente fornisce una stima approssimativa delle dimensioni minime della subnet per i file system lustre gestiti di Azure con dimensioni diverse.
| Capacità di archiviazione | Valore del prefisso CIDR consigliato |
|---|---|
| Da 4 TiB a 16 TiB | /27 o superiore |
| Da 20 TiB a 40 TiB | /26 o superiore |
| Da 44 TiB a 92 TiB | /25 o superiore |
| Da 96 TiB a 196 TiB | /24 o superiore |
| Da 200 TiB a 400 TiB | /23 o superiore |
Altre considerazioni sulle dimensioni della rete
Quando si pianifica la rete virtuale e la subnet, tenere conto dei requisiti per tutti gli altri servizi da individuare all'interno della subnet o della rete virtuale di Lustre gestita di Azure. Si considerino ad esempio i fattori seguenti.
Se si usa un cluster servizio Azure Kubernetes (servizio Azure Kubernetes) con il file system lustre gestito di Azure:
È possibile individuare il cluster del servizio Azure Kubernetes nella stessa subnet del sistema Lustre gestito. In tal caso, è necessario fornire indirizzi IP sufficienti per i nodi e i pod del servizio Azure Kubernetes oltre allo spazio indirizzi per il file system Lustre.
Se si usano più cluster del servizio Azure Kubernetes all'interno della rete virtuale, assicurarsi che la rete virtuale abbia una capacità sufficiente per tutte le risorse in tutti i cluster.
Per altre informazioni sulle strategie di rete per il servizio Azure Managed Lustre e il servizio Azure Kubernetes, vedere Accesso alla subnet del servizio Azure Kubernetes.
Se si prevede di usare un'altra risorsa per ospitare le macchine virtuali di calcolo nella stessa rete virtuale, verificare i requisiti per tale processo prima di creare la rete virtuale e la subnet per il sistema Lustre gestito di Azure.
Quando si pianificano più cluster all'interno della stessa subnet, è necessario usare uno spazio indirizzi sufficientemente grande per soddisfare i requisiti totali per tutti i cluster.
Accesso alla subnet e autorizzazioni
Per impostazione predefinita, non è necessario apportare modifiche specifiche per abilitare Lustre gestito di Azure. Se l'ambiente include criteri di sicurezza o di rete con restrizioni, è necessario considerare le indicazioni seguenti:
| Tipo di accesso | Impostazioni di rete necessarie |
|---|---|
| Accesso DNS | Usare il server DNS predefinito basato su Azure. |
| Accesso al servizio cloud di Azure | Configurare il gruppo di sicurezza di rete per consentire al file system lustre gestito di Azure di accedere ai servizi cloud di Azure dall'interno della subnet del file system. Aggiungere una regola di sicurezza in uscita con le proprietà seguenti: - Porta: qualsiasi - Protocollo: Qualsiasi - Origine: Rete virtuale - Destinazione: tag del servizio "AzureCloud" - Azione: Consenti Nota: la configurazione del servizio cloud di Azure abilita anche la configurazione necessaria del servizio di accodamento di Azure. Per altre informazioni, vedere Tag del servizio di rete virtuale. |
| Accesso alla porta di rete Lustre | Il gruppo di sicurezza di rete deve consentire l'accesso in ingresso e in uscita sulla porta 988 e sulle porte 1019-1023. Le regole predefinite 65000 AllowVnetInBound e 65000 AllowVnetOutBound soddisfano questo requisito. |
Limitazioni note
Le limitazioni seguenti si applicano alle subnet di rete virtuale per i file system lustre gestiti di Azure:
- Le risorse gestite da Lustre e Azure NetApp Files di Azure non possono condividere una subnet. Se si usa il servizio Azure NetApp Files, è necessario creare il file system lustre gestito di Azure in una subnet separata. La distribuzione ha esito negativo se si tenta di creare un file system lustre gestito di Azure in una subnet che attualmente contiene o contiene in precedenza risorse Azure NetApp Files.
Nota
Dopo aver creato il file system lustre gestito di Azure, nel gruppo di risorse del file system vengono visualizzate diverse nuove interfacce di rete. I nomi iniziano con amlfs- e terminano con -snic. Non modificare le impostazioni di queste interfacce. In particolare, lasciare abilitato il valore predefinito per l'impostazione Rete accelerata. La disabilitazione della rete accelerata in queste interfacce di rete riduce le prestazioni del file system.
Prerequisiti di integrazione BLOB (facoltativo)
Se si prevede di integrare il file system lustre gestito di Azure con Archiviazione BLOB di Azure, completare i prerequisiti seguenti prima di creare il file system.
Un contenitore BLOB integrato consente di importare automaticamente i file nel sistema Managed Lustre di Azure quando si crea il file system. È quindi possibile creare processi di archiviazione per esportare i file modificati dal file system lustre gestito di Azure a tale contenitore.
Se non si aggiunge un contenitore BLOB integrato quando si crea il sistema Lustre, è possibile scrivere script o comandi client personalizzati per spostare i file tra il file system lustre gestito di Azure e altre risorse di archiviazione.
Quando si pianifica l'integrazione blob per il file system, è importante comprendere le differenze seguenti nella gestione dei metadati in base al fatto che uno spazio dei nomi gerarchico sia abilitato per un account di archiviazione:
Per un contenitore in un account di archiviazione con spazio dei nomi gerarchico abilitato, Lustre gestito di Azure legge gli attributi POSIX dall'intestazione BLOB.
Per un contenitore in un account di archiviazione con uno spazio dei nomi flat (non gerarchico), Lustre gestito di Azure legge gli attributi POSIX dai metadati del BLOB. Viene creato un file vuoto separato con lo stesso nome del contenuto del contenitore BLOB per contenere i metadati. Questo file è di pari livello alla directory dei dati effettiva nel file system lustre gestito di Azure.
Per integrare Archiviazione BLOB di Azure con il file system lustre gestito di Azure, è necessario creare gli elementi seguenti prima di creare il file system:
- Account di archiviazione
- Tipo di account : tipo di account di archiviazione compatibile. Vedere Tipi di account di archiviazione supportati.
- Ruoli di accesso : devono avere ruoli che consentono al sistema Lustre gestito di Azure di modificare i dati. Vedere Ruoli di accesso necessari.
- Chiavi di accesso: l'account di archiviazione deve avere l'impostazione di accesso alla chiave dell'account di archiviazione impostata su Abilitato.
- Contenitori di dati
- File per Lustre : contenitore di dati nell'account di archiviazione che contiene i file da usare nel file system lustre gestito di Azure.
- Log di importazione/esportazione : secondo contenitore per i log di importazione/esportazione nell'account di archiviazione. È necessario archiviare i log in un contenitore diverso dal contenitore di dati.
Nota
È possibile aggiungere file al file system in un secondo momento dai client. Tuttavia, i file aggiunti al contenitore BLOB originale dopo aver creato il file system non verranno importati nel file system lustre gestito di Azure.
Tipi di account di archiviazione supportati
I tipi di account di archiviazione seguenti possono essere usati con i file system lustre gestiti di Azure.
| Tipo di account di archiviazione | Ridondanza |
|---|---|
| Standard | Archiviazione con ridondanza locale (LRS), archiviazione con ridondanza geografica Archiviazione con ridondanza della zona (ZRS), archiviazione con ridondanza geografica e accesso in lettura(RAGRS), archiviazione con ridondanza geografica della zona ,archiviazione con ridondanza geografica della zona in lettura (RA-GZRS) |
| Premium - BLOB in blocchi | LRS, ZRS |
Per altre informazioni sui tipi di account di archiviazione, vedere Tipi di account di archiviazione.
Ruoli di accesso per l'integrazione dei BLOB
Lustre gestito di Azure richiede l'autorizzazione per accedere all'account di archiviazione. Usare il controllo degli accessi in base al ruolo di Azure per concedere al file system l'accesso all'archiviazione BLOB.
Un proprietario dell'account di archiviazione deve aggiungere questi ruoli prima di creare il file system:
Importante
È necessario aggiungere questi ruoli prima di creare il file system lustre gestito di Azure. Se il file system non riesce ad accedere al contenitore BLOB, la creazione del file system ha esito negativo. La convalida eseguita prima della creazione del file system non è in grado di rilevare i problemi di autorizzazione di accesso al contenitore. La propagazione delle impostazioni del ruolo nell'ambiente di Azure può richiedere fino a cinque minuti.
Per aggiungere i ruoli per l'entità servizio Cache HPC provider di risorse, seguire questa procedura:
Aprire l'account di archiviazione e selezionare Controllo di accesso (IAM) nel riquadro di spostamento a sinistra.
Selezionare Aggiungi aggiungi>assegnazione di ruolo per aprire la pagina Aggiungi assegnazione di ruolo .
Assegnare il ruolo.
Aggiungere quindi il provider di risorse Cache HPC a tale ruolo.
Suggerimento
Se non è possibile trovare il provider di risorse Cache HPC, cercare invece storagecache. storagecache Resource Provider era il nome dell'entità servizio prima della disponibilità generale del prodotto.
Ripetere i passaggi 3 e 4 per aggiungere ogni ruolo.
Per la procedura dettagliata, vedere Assegnare ruoli di Azure usando il portale di Azure.
Endpoint privati (facoltativo)
Se si usa un endpoint privato con la configurazione del BLOB, per assicurarsi che Lustre gestito di Azure possa risolvere il nome dell'amministratore di sistema, è necessario abilitare l'impostazione dell'endpoint privato Integrare con la zona DNS privata durante la creazione di un nuovo endpoint.
- Integrazione con DNS privato zona: deve essere impostata su Sì.
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per