Prerequisiti del file system lustre gestito di Azure
Questo articolo illustra i prerequisiti che è necessario configurare prima di creare un file system lustre gestito di Azure.
- Prerequisiti di rete
- Prerequisiti di integrazione BLOB (facoltativo)
Prerequisiti di rete
I file system Managed Lustre di Azure risiedono in una subnet di rete virtuale. La subnet contiene il servizio di gestione Lustre (MGS) e gestisce tutte le interazioni dei 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.
Managed Lustre di Azure accetta solo indirizzi IPv4. IPv6 non è supportato.
Requisiti di dimensioni della 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 file system Managed Lustre di Azure di dimensioni diverse.
| Capacità di archiviazione | Valore consigliato del prefisso CIDR |
|---|---|
| 4 TiB - 16 TiB | /27 o maggiore |
| 20 TiB - 40 TiB | /26 o maggiore |
| 44 TiB - 92 TiB | /25 o maggiore |
| 96 TiB - 196 TiB | /24 o maggiore |
| 200 TiB - 400 TiB | /23 o maggiore |
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 Lustre gestita di Azure o della rete virtuale.
Se si usa un cluster servizio Azure Kubernetes (AKS) con il file system lustre gestito di Azure, è possibile individuare il cluster del servizio Azure Kubernetes nella stessa subnet del file system. In questo caso, è necessario fornire un numero sufficiente di indirizzi IP 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 di tutti i cluster. Per altre informazioni sulle strategie di rete per Managed Lustre di Azure 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 e autorizzazioni per la subnet
Per impostazione predefinita, non è necessario apportare modifiche specifiche per abilitare Managed Lustre 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 tra host | Consentire l'accesso in ingresso e in uscita tra gli host all'interno della subnet di Managed Lustre di Azure. Ad esempio, l'accesso alla porta TCP 22 (SSH) è necessario per la distribuzione del cluster. |
| Accesso ai servizi cloud di Azure | Configurare il gruppo di sicurezza di rete per consentire al file system Managed Lustre di Azure di accedere ai servizi cloud di Azure dalla subnet del file system. Aggiungere una regola di sicurezza in uscita con seguenti 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 alle porte 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. Nessun altro servizio può riservare o usare queste porte nei client Lustre. Le regole predefinite 65000 AllowVnetInBound e 65000 AllowVnetOutBound soddisfare questo requisito. |
Per indicazioni dettagliate sulla configurazione di un gruppo di sicurezza di rete per i file system Managed Lustre di Azure, vedere Creare e configurare un gruppo di sicurezza di rete.
Limitazioni note
Le limitazioni note seguenti si applicano alle impostazioni di rete virtuale per i file system lustre gestiti di Azure:
- Le risorse lustre gestite di Azure e Azure NetApp Files non possono condividere una subnet. Se si usa il servizio Azure NetApp Files, è necessario creare il file system Managed Lustre di Azure in una subnet separata. La distribuzione non riesce se si tenta di creare un file system lustre gestito di Azure in una subnet che attualmente contiene o contiene risorse di Azure NetApp Files in precedenza.
- Se si usa il daemon nei client per gestire le
ypbindinformazioni di associazione di Network Information Services (NIS), è necessario assicurarsi cheypbindnon riserva la porta 988. È possibile modificare manualmente le porte cheypbindriserva o assicurarsi che l'infrastruttura di avvio del sistema avvii il montaggio del client Lustre prima di avviareypbind.
Nota
Dopo aver creato il file system Managed Lustre di Azure, nel relativo gruppo di risorse vengono visualizzate diverse nuove interfacce di rete. I nomi iniziano con amlfs- e terminano con -snic. Non cambiare alcuna impostazione in queste interfacce. In particolare, lasciare il valore predefinito, abilitato, 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 Managed Lustre di Azure con Archiviazione BLOB di Azure, completare i prerequisiti seguenti prima di creare il file system.
Per altre informazioni sull'integrazione di BLOB, vedere Usare l'archiviazione BLOB di Azure con un file system Managed Lustre di Azure.
Lustre gestito di Azure funziona con gli account di archiviazione con spazio dei nomi gerarchico abilitato e account di archiviazione con uno spazio dei nomi non gerarchico o flat. Si applicano le differenze minori seguenti:
- Per un account di archiviazione con spazio dei nomi gerarchico abilitato, Azure Managed Lustre legge gli attributi POSIX dall'intestazione blob.
- Per un account di archiviazione in cui non è abilitato lo spazio dei nomi gerarchico, Azure Managed Lustre 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 è un elemento di pari livello della directory di dati effettiva nel file system lustre gestito di Azure.
Per integrare Archiviazione BLOB di Azure con il file system Managed Lustre di Azure, è necessario creare o configurare le risorse seguenti prima di creare il file system:
Account di archiviazione
È necessario creare un account di archiviazione o usarne uno esistente. L'account di archiviazione deve avere le impostazioni seguenti:
- Tipo di account: un tipo di un account di archiviazione compatibile. Per altre informazioni, vedere Tipi di account di archiviazione supportati.
- Ruoli di accesso: assegnazioni di ruolo che consentano a Managed Lustre di Azure di modificare i dati. Per altre informazioni, vedere Ruoli di accesso necessari.
- Chiavi di accesso: l'accesso alla chiave dell'account di archiviazione deve essere impostato su Abilitato.
Tipi di account di archiviazione supportati
I tipi di account di archiviazione seguenti possono essere usati con i file system Managed Lustre di Azure:
| Storage account type | Ridondanza |
|---|---|
| Standard | Archiviazione con ridondanza locale, archiviazione con ridondanza geografica Archiviazione con ridondanza della zona, archiviazione con ridondanza geografica e accesso in lettura, archiviazione con ridondanza geografica della zona, archiviazione con ridondanza geografica della zona e accesso in lettura |
| BLOB in blocchi Premium | LRS, ZRS |
Per altre informazioni sui tipi di account di archiviazione, vedere Tipi di account di archiviazione.
Ruoli di accesso per l'integrazione di BLOB
Managed Lustre 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 non riesce. 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 provider di risorse Cache HPC, seguire questa procedura:
- Passare all'account di archiviazione e selezionare controllo di accesso (IAM) nel riquadro di spostamento sinistro.
- Selezionare Aggiungi>Aggiungi assegnazione di ruolo per aprire la pagina Aggiungi assegnazione di ruolo.
- Assegnare il ruolo .
- Aggiungere Provider di risorse Cache HPC a tale ruolo.
Suggerimento
Se non è possibile trovare il provider di risorse Cache HPC, cercare invece storagecache. Provider di risorse storagecache 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.
Contenitori BLOB
È necessario avere due contenitori di BLOB separati nello stesso account di archiviazione, che vengono usati per gli scopi seguenti:
- Contenitore di dati: un contenitore di BLOB nell'account di archiviazione che contiene i file da usare nel file system Managed Lustre di Azure.
- Contenitore di log: un secondo contenitore per i log di importazione/esportazione nell'account di archiviazione. È necessario archiviare i log in un contenitore diverso rispetto al contenitore di dati.
Nota
È possibile aggiungere file al file system in un secondo momento dai client. Tuttavia, i file aggiunti al contenitore di BLOB originale dopo aver creato il file system non verranno importati nel file system Managed Lustre di Azure, a meno che non si crei un processo di importazione.
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 Integrate with private DNS Zone durante la creazione di un nuovo endpoint.
- Integrazione con DNS privato zona: deve essere impostata su Sì.
