Distribuire un file system scalabile e distribuito utilizzando Lustre

Lustre è un file system open source, parallelo e distribuito utilizzato per cluster e ambienti di calcolo ad alte prestazioni (HPC). Il nome Lustre è un portmanteau di Linux e cluster.

Utilizzando Lustre, è possibile creare un file server HPC su Oracle Cloud Infrastructure bare metal Compute e storage a blocchi collegato in rete o SSD NVMe collegati localmente ai nodi di calcolo. Un modello Terraform fornisce un modo semplice per distribuire Lustre su Oracle Cloud Infrastructure.

Scala cluster Lustre per un throughput più elevato, una capacità di storage più elevata o entrambi per il file system. Costi solo pochi centesimi per gigabyte al mese per Compute e storage combinati.

Il modello di distribuzione Terraform esegue il provisioning delle risorse Oracle Cloud Infrastructure, tra cui Compute, storage, reti cloud virtuali e subnet. Fornisce inoltre il provisioning del software Lustre, tra cui un Management Server (MGS), un Metadata Server (MDS), un Object Storage Server (OSS) e i nodi client Lustre.

Architettura

Questa architettura di riferimento utilizza un'area con un singolo dominio di disponibilità e subnet regionali. È possibile utilizzare la stessa architettura di riferimento in un'area con più domini di disponibilità. Si consiglia di utilizzare subnet regionali per la distribuzione, indipendentemente dal numero di domini di disponibilità.

Il seguente diagramma illustra questa architettura di riferimento.

Segue una descrizione dell'immagine lustre-oci.png
Descrizione dell'immagine lustre-oci.png

L'architettura Lustre scalabile ha i seguenti componenti:

  • Management Server (MGS)

    Un MGS memorizza le informazioni di configurazione per uno o più file system Lustre e fornisce queste informazioni ad altri host Lustre. Questa risorsa globale può supportare più file system.

  • Server di metadati (MDS)

    Un MDS fornisce l'indice o lo spazio di nomi per un file system Lustre. Il contenuto dei metadati viene memorizzato nei volumi denominati MDT (Metadata Targets). La struttura delle directory e i nomi dei file, le autorizzazioni, gli attributi estesi e i layout dei file di un file system Lustre vengono registrati negli MDT. Ogni file system Lustre deve avere almeno un MDT.

  • Server di memorizzazione oggetti (OSS)

    Un OSS fornisce la memorizzazione dei dati di massa per tutti i contenuti di file in un file system Lustre. Ogni OSS fornisce l'accesso a un set di volumi di memorizzazione, denominati OST (Object Storage Target). Ogni OST contiene diversi oggetti binari che rappresentano i dati per i file in Lustre. I file in Lustre sono composti da uno o più oggetti OST, oltre all'inode di metadati memorizzato sul MDS.

  • Clienti Lustre

    I client sono istanze di calcolo che accedono al file system Lustre.

  • Rete cloud virtuale (VCN) e subnet

    Un VCN è una rete definita dal software impostata in un'area Oracle Cloud Infrastructure. I VCN possono essere segmentati in subnet, che possono essere specifiche di un'area o di un dominio di disponibilità. Sia le subnet specifiche dell'area che quelle specifiche del dominio di disponibilità possono coesistere nello stesso VCN. Una subnet può essere pubblica o privata.

  • Liste di sicurezza

    Per ogni subnet è possibile creare regole di sicurezza che specifichino l'origine, la destinazione e il tipo di traffico che devono essere consentiti all'interno e all'esterno della subnet.

  • Domini di disponibilità

    I domini di disponibilità sono data center indipendenti e autonomi all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità vengono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono infrastrutture quali l'alimentazione o il raffreddamento o la rete di dominio di disponibilità interna. È improbabile che l'eventuale guasto di un dominio di disponibilità influenzi gli altri domini di disponibilità della regione.

Suggerimenti

Le vostre esigenze potrebbero differire dall'architettura descritta qui. Utilizzare i suggerimenti riportati di seguito come punto di partenza.

  • Forma di calcolo, host bastione

    Un host bastione viene utilizzato per accedere a qualsiasi nodo della subnet privata. Utilizzare la forma VM.Standard.E2.1 o VM.Standard.E2.2.

  • Calcola forma, MGS e MDS

    Poiché l'MGS non è ad alta intensità di risorse, è possibile ospitare l'MGS e l'MDS nella stessa istanza. Per garantire che un'interruzione di livello node non influenzi il file system, utilizzare un'istanza Bare Metal con elevata disponibilità.

  • Bare metal Compute con volume a blocchi e elevata disponibilità

    Utilizzare BM.Standard2.52. Due nodi sono configurati in una coppia. I due controller di interfaccia di rete fisica (NIC) ciascuno con velocità di rete 25-Gbps. Utilizzare un NIC per tutto il traffico per bloccare la memorizzazione e utilizzare l'altro NIC per i dati in entrata sui nodi OSS e MDS dai nodi client.

    Utilizzare la memorizzazione del volume a blocchi (dimensione e numero per requisito di distribuzione) con l'allegato a più istanze per collegare un volume a entrambi i nodi di calcolo.

  • Forma di calcolo, OSS

    La nostra raccomandazione per OSS è la stessa per MGS e MDS.

  • Forma di calcolo, cliente Lustre

    Scegliere una forma VM (Virtual Machine) in base ai piani di distribuzione, in particolare ai requisiti di larghezza di banda della rete.

    Il throughput sui singoli clienti dipende dalla capacità. Se si distribuiscono 10 client con larghezza di banda di rete 2.5-Gbps, la larghezza di banda aggregata è di 25 Gbps.

  • Configurazione RAID

    Facoltativamente, è possibile configurare le forme DenseIO con RAID 0.

    Utilizzare RAID durante la creazione di un OST per OSS.

    Se si utilizza un OST per OSS, si consiglia di utilizzare otto volumi a blocchi per OSS per massimizzare il throughput (RAID 0 è facoltativo).

    Nota:

    Il modello Terraform crea una forma Bare Metal con DenseIO o con volumi a blocchi.
  • VCN

    Quando si crea VCN, determinare il numero di indirizzi IP necessari per le risorse cloud in ogni subnet. Utilizzando la notazione CIDR (Classless Inter-Domain Routing), specificare una maschera subnet e un intervallo di indirizzi di rete sufficientemente grande per gli indirizzi IP richiesti. Utilizzare uno spazio di indirizzi all'interno dei blocchi di indirizzi IP privati standard.

    Selezionare un intervallo di indirizzi che non si sovrapponga alla rete in locale, in modo da poter impostare una connessione tra VCN e la rete in locale, se necessario.

    Dopo aver creato un VCN, non è possibile modificarne l'intervallo di indirizzi.

    Quando si progettano le subnet, prendere in considerazione le funzionalità e i requisiti di sicurezza. Allegare tutte le istanze di calcolo all'interno dello stesso livello o ruolo alla stessa subnet, che può fungere da limite di sicurezza.

    Utilizzare subnet regionali.

  • Liste di sicurezza

    Utilizzare gli elenchi di sicurezza per definire le regole di ingresso e uscita applicabili all'intera subnet. Ad esempio, questa architettura consente a ICMP internamente per l'intera subnet privata.

Considerazioni

  • Prestazioni

    Per ottenere le migliori prestazioni, scegliere la forma di calcolo corretta con larghezza di banda appropriata.

  • Disponibilità

    Prendere in considerazione l'utilizzo di un'opzione ad alta disponibilità in base al requisito di distribuzione.

  • Costo

    Il servizio Bare Metal offre prestazioni più elevate sulla larghezza di banda della rete per un costo maggiore. Valuta le tue esigenze per scegliere la forma di calcolo appropriata.

  • Monitoraggio e avvisi

    Impostare il monitoraggio e gli avvisi sull'uso della CPU e della memoria per i nodi MGS, MDS e OSS in modo da scalare la forma della VM su o giù in base alle esigenze.

Distribuisci

Il codice Terraform per questa architettura di riferimento è disponibile come stack di esempio in Oracle Cloud Infrastructure Resource Manager. È inoltre possibile scaricare il codice da GitHub e personalizzarlo in base alle specifiche esigenze.

  • Distribuire utilizzando lo stack di esempio in Oracle Cloud Infrastructure Resource Manager:
    1. Fare clic suDistribuire in Oracle Cloud.

      Se non si è già connessi, immettere la tenancy e le credenziali utente.

    2. Rivedere e accettare i termini e le condizioni.
    3. Selezionare l'area in cui distribuire lo stack.
    4. Seguire i prompt e le istruzioni visualizzate sullo schermo per creare lo stack.
    5. Dopo aver creato lo stack, fare clic su Azioni Terraform e selezionare Piano.
    6. Attendere il completamento del job e rivedere il piano.

      Per apportare eventuali modifiche, tornare alla pagina Dettagli stack, fare clic su Modifica stack e apportare le modifiche necessarie. Eseguire nuovamente l'azione Piano.

    7. Se non sono necessarie ulteriori modifiche, tornare alla pagina Dettagli stack, fare clic su Azioni Terraform e selezionare Applica.
  • Distribuire utilizzando il codice Terraform in GitHub:
    1. Andare a GitHub.
    2. Duplicare o scaricare il repository nel computer locale.
    3. Seguire le istruzioni contenute nel documento README.