Prerequisiti del file system gestito di Azure
Questo articolo illustra i prerequisiti che è necessario configurare prima di creare un file system di Lustre gestito di Azure.
- Prerequisiti di rete
- Prerequisiti di integrazione BLOB(facoltativo)
Prerequisiti di rete
I file system di Lustre gestiti di Azure esistono in una subnet di rete virtuale. La subnet contiene il servizio di gestione lustre (MGS) e gestisce tutte le interazioni client con il cluster Lustre virtuale.
Non è possibile spostare un file system da una rete o una subnet a un'altra dopo aver creato il file system.
Lustre gestito di Azure accetta solo indirizzi IPv4. IPv6 non è supportato.
Requisiti delle 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 i file system lustre gestiti di Azure di dimensioni diverse.
| Capacità di archiviazione | Valore del prefisso CIDR consigliato |
|---|---|
| 4 TiB a 16 TiB | /27 o maggiore |
| 20 TiB a 40 TiB | /26 o maggiore |
| 44 TiB a 92 TiB | /25 o maggiore |
| 96 TiB a 196 TiB | /24 o maggiore |
| 200 TiB a 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 che si desidera individuare all'interno della subnet di Lustre gestita di Azure o della rete virtuale.
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 file system. In questo 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 Azure Managed Lustre e 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, controllare 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 abbastanza 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 rete o sicurezza con restrizioni, è necessario considerare le indicazioni seguenti:
| Tipo di accesso | Impostazioni di rete necessarie |
|---|---|
| Accesso DNS | Usare il server DNS basato su Azure predefinito. |
| 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 dalla 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 consente anche la configurazione necessaria del servizio Coda 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 le porte 1019-1023. Le regole 65000 AllowVnetInBound predefinite e 65000 AllowVnetOutBound soddisfano questo requisito. |
Limitazioni note
Le limitazioni seguenti si applicano alle subnet di rete virtuale per i file system di Lustre gestiti di Azure:
- Le risorse di 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 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, Azure NetApp Files risorse.
Nota
Dopo aver creato il file system lustre gestito di Azure, vengono visualizzate diverse nuove interfacce di rete nel gruppo di risorse del file system. I loro nomi iniziano con amlfs- e terminano con -snic. Non modificare le impostazioni in queste interfacce. In particolare, lasciare il valore predefinito, abilitato, per l'impostazione Di 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 di Azure con Archiviazione BLOB di Azure, completare i prerequisiti seguenti prima di creare il file system.
Per altre informazioni sull'integrazione dei BLOB, vedere Usare l'archiviazione BLOB di Azure con un file system lustre gestito di Azure.
La lustre gestita di Azure funziona con gli account di archiviazione che dispongono di account di spazio dei nomi gerarchici abilitati e di archiviazione con uno spazio dei nomi non gerarchico o flat. Le differenze minori seguenti si applicano:
- 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 che non dispone di spazio dei nomi gerarchico abilitato, Azure Managed Lustre legge gli attributi POSIX dai metadati DEL BLOB. Un file separato e vuoto con lo stesso nome del contenuto del contenitore BLOB viene creato per contenere i metadati. Questo file è un elemento di pari livello nella directory 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 o configurare le risorse seguenti prima di creare il file system:
Account di archiviazione
È necessario creare un account di archiviazione o usare uno esistente. L'account di archiviazione deve avere le impostazioni seguenti:
- Tipo di account: tipo di account di archiviazione compatibile. Per altre informazioni, vedere Tipi di account di archiviazione supportati.
- Ruoli di accesso : assegnazioni di ruolo che consentono al sistema Lustre gestito di Azure di modificare i dati. Per altre informazioni, vedere Ruoli di accesso obbligatori.
- Chiavi di accesso : l'account di archiviazione deve avere l'impostazione di accesso alla chiave dell'account di archiviazione impostata su Abilitato.
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 (GRS) Archiviazione con ridondanza della zona ( ZRS), archiviazione con ridondanza geografica (RAGRS), archiviazione con ridondanza geografica della zona , archiviazione con ridondanza geografica (RA-GZRS), archiviazione con ridondanza geografica (RA-GZRS) |
| Premium - Blocca BLOB | LRS, ZRS |
Per altre informazioni sui tipi di account di archiviazione, vedere Tipi di account di archiviazione.
Ruoli di accesso per l'integrazione blob
Azure Managed Lustre necessita dell'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 può accedere al contenitore BLOB, la creazione del file system non riesce. La convalida eseguita prima della creazione del file system non riesce a rilevare i problemi di autorizzazione di accesso ai contenitori. Può richiedere fino a cinque minuti per propagare le impostazioni del ruolo tramite l'ambiente di Azure.
Per aggiungere i ruoli per l'entità servizio Cache HPC provider di risorse, seguire questa procedura:
- Spostarsi nell'account di archiviazione e selezionare Controllo di accesso (IAM) nel riquadro di spostamento a sinistra.
- SelezionareAggiungi assegnazione di ruolo per aprire la pagina Aggiungi>assegnazione di ruolo.
- Assegnare il ruolo.
- Aggiungere Cache HPC provider di risorse 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.
Contenitori BLOB
È necessario disporre di due contenitori BLOB separati nello stesso account di archiviazione, usati ai fini seguenti:
- Contenitore dati: contenitore BLOB nell'account di archiviazione contenente i file che si desidera usare nel file system gestito di Azure.
- Contenitore di registrazione: un secondo contenitore per i log di importazione/esportazione nell'account di archiviazione. È necessario archiviare i log in un contenitore diverso dal contenitore 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 gestito 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 garantire che Azure Managed Lustre possa risolvere il nome sa, è necessario abilitare l'impostazione dell'endpoint privato Integrare con la zona DNS privata durante la creazione di un nuovo endpoint.
- Integrare con DNS privato zona: deve essere impostato 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