Architettura: file system Lustre in Google Cloud utilizzando DDN EXAScaler

Last reviewed 2023-11-15 UTC

Questo documento fornisce indicazioni sull'architettura per aiutarti a progettare e dimensionare un file system Lustre per carichi di lavoro di computing ad alte prestazioni (HPC). Fornisce inoltre una panoramica del processo per il deployment di un file system Lustre in Google Cloud utilizzando DDN EXAScaler.

Lustre è un file system parallelo open source che offre archiviazione ad alta velocità effettiva e bassa latenza per carichi di lavoro HPC a stretto accoppiamento. Scala un file system Lustre per supportare decine di migliaia di client HPC e petabyte di spazio di archiviazione. EXAScaler Cloud è una versione aziendale di Lustre offerta da DDN, un partner di Google. Puoi eseguire il deployment di EXAScaler Cloud in un'architettura cloud ibrida per aumentare la capacità HPC on-premise. EXAScaler Cloud può anche fungere da repository per l'archiviazione di asset a lungo termine da un deployment EXAScaler on-premise.

Le indicazioni contenute in questo documento sono rivolte agli enterprise architect e ai professionisti tecnici che progettano, eseguono il provisioning e gestiscono l'archiviazione per i carichi di lavoro HPC nel cloud. Il documento presuppone che tu abbia una comprensione concettuale dei file system paralleli. Dovresti anche conoscere i casi d'uso dell'HPC (computing ad alte prestazioni) per cui i file system paralleli come Lustre sono ideali. Per ulteriori informazioni, consulta File system paralleli per carichi di lavoro HPC.

Panoramica del file system Lustre

Il seguente diagramma mostra l'architettura di un file system Lustre:

Architettura di un file system Lustre

Come mostrato nel diagramma, l'architettura contiene i seguenti componenti:

  • Server di gestione (MGS) e target di gestione (MGT): MGS archivia e gestisce le informazioni di configurazione relative a uno o più file system Lustre. Il diagramma mostra l'MGS che gestisce un singolo file system Lustre. MGS fornisce informazioni di configurazione agli altri componenti Lustre in tutti i file system che gestisce. MGS registra i log di configurazione del file system nei dispositivi di archiviazione chiamati MGT.

  • Server di metadati (MDS) e target di metadati (MDT): i nodi MDS gestiscono l'accesso client allo spazio dei nomi di un file system Lustre. Questo spazio dei nomi include tutti i metadati del file system, come la gerarchia delle directory, data e ora di creazione del file e autorizzazioni di accesso. I metadati sono memorizzati in dispositivi di archiviazione chiamati MDT. Un file system Lustre ha almeno un MDS e un MDT associato. Per migliorare le prestazioni per i carichi di lavoro che richiedono un uso intensivo dei metadati, ad esempio quando migliaia di client creano e accedono a milioni di file di piccole dimensioni, puoi aggiungere altri nodi MDS al file system.

  • Server di archiviazione di oggetti (OSS) e target di archiviazione di oggetti (OST): i nodi OSS gestiscono l'accesso client ai dati dei file archiviati in un file system Luustre. Ogni file è archiviato come uno o più oggetti Lustre. Gli oggetti vengono archiviati in un singolo dispositivo di archiviazione (chiamato OST) o a righe su più nodi OSS e OST. Un file system Lustre ha almeno un OSS e una OST associata. Puoi scalare la capacità di archiviazione e le prestazioni del file system aggiungendo altri nodi OSS e OST. La capacità di archiviazione totale del file system è la somma delle capacità di archiviazione delle OST collegate a tutti i nodi OSS nel file system.

  • Client: un client Lustre è un nodo di computing, ad esempio una macchina virtuale (VM), che accede a un file system Lustre tramite un punto di montaggio. Il punto di montaggio fornisce uno spazio dei nomi unificato per l'intero file system. Puoi scalare un file system Lustre per supportare l'accesso simultaneo da parte di oltre 10.000 client. I client Lustre accedono in parallelo a tutti i nodi MDS e OSS in un file system Lustre. Questo accesso parallelo consente di massimizzare le prestazioni del file system. L'accesso parallelo consente inoltre di ridurre gli hotspot di archiviazione, a cui si accede con maggiore frequenza rispetto ad altre località di archiviazione. Gli hotspot sono comuni nei file system non paralleli e possono causare squilibri delle prestazioni tra i client.

    Per accedere a un file system Lustre, un client riceve da un MDS i metadati della directory e del file richiesti, quindi legge o scrive dati comunicando con uno o più nodi OSS. Lustre fornisce una stretta conformità con la semantica dei POSIX e consente a tutti i client l'accesso completo e parallelo al file system.

Per ulteriori informazioni sul file system Lustre e sul suo funzionamento, consulta la documentazione di Lustre.

Architettura di Lustre in Google Cloud

Il seguente diagramma mostra un'architettura per il deployment di un file system Lustre in Google Cloud:

Architettura del file system Lustre in Google Cloud

L'architettura mostrata in questo diagramma contiene le seguenti risorse. Il deployment di tutte le risorse viene eseguito in un unico progetto Google Cloud. Il provisioning delle risorse di computing e archiviazione viene eseguito all'interno di una singola zona.

  • Le VM di Compute Engine ospitano i nodi MGS, MDS e OSS e i client Lustre. Puoi anche scegliere di eseguire il deployment dei client Lustre in un cluster Google Kubernetes Engine e del file system su VM di Compute Engine.

  • L'architettura include le seguenti risorse di networking:

    • Un'unica subnet Virtual Private Cloud (VPC) utilizzata per tutte le VM.
    • Un gateway Cloud NAT facoltativo e un router Cloud facoltativo per il traffico in uscita dalle VM private a internet.
    • Regole firewall facoltative per consentire connessioni SSH in entrata a tutte le VM nella topologia.
    • Una regola firewall facoltativa per consentire l'accesso HTTP da internet alla console web DDN EXAScaler su MGS.
    • Un firewall per consentire le connessioni TCP tra tutte le VM.

  • I dischi permanenti forniscono capacità di archiviazione per i nodi MGS, MDS e OSS. Se non hai bisogno di archiviazione permanente, puoi creare un file system di scratch utilizzando dischi a stato solido (SSD) locali, collegati alle VM.

    Google ha inviato voci IO500 che dimostrano le prestazioni dei file system Lustre sia permanenti che temporanei. Scopri di più sull'invio di Google Cloud che dimostra un file system di lavoro basato su Lustre superiore a 10 Tbps con il ranking IO500 dei sistemi di archiviazione HPC.

Linee guida per il layout

Utilizza le seguenti linee guida per progettare un file system Lustre che soddisfi i requisiti dei carichi di lavoro HPC. Le linee guida in questa sezione non sono esaustive. Forniscono un framework per aiutarti a valutare i requisiti di archiviazione dei carichi di lavoro HPC, a valutare le opzioni di archiviazione disponibili e a dimensionare il file system Luustre.

Requisiti del carico di lavoro

Identifica i requisiti di archiviazione dei tuoi carichi di lavoro HPC. Definisci i requisiti nel modo più granulare possibile e considera le tue esigenze future. Utilizza le seguenti domande come punto di partenza per identificare i requisiti del tuo carico di lavoro:

  • Quali sono i tuoi requisiti per la velocità effettiva e le operazioni di I/O al secondo (IOPS)?
  • Di quanta capacità di archiviazione hai bisogno?
  • Qual è il tuo obiettivo di progettazione più importante: velocità effettiva, IOPS o capacità di archiviazione?
  • Hai bisogno di archiviazione permanente, archiviazione temporanea o entrambe?

Opzioni di archiviazione

Per le opzioni di archiviazione più convenienti, puoi scegliere tra i seguenti tipi di dischi permanenti:

  • I dischi permanenti standard (pd-standard) sono l'opzione più conveniente quando la capacità di archiviazione è l'obiettivo di progettazione principale. Offrono un'archiviazione a blocchi efficiente e affidabile grazie all'uso di unità a disco rigido (HDD).
  • I dischi permanenti SSD (pd-ssd) sono l'opzione più conveniente se l'obiettivo è massimizzare il numero di IOPS. Offrono archiviazione a blocchi rapida e affidabile tramite SSD.
  • I dischi permanenti bilanciati (pd-balanced) sono l'opzione più conveniente per massimizzare la velocità effettiva. Offrono archiviazione a blocchi conveniente e affidabile grazie all'uso di SSD.

I dischi permanenti con carico estremo (pd-extreme) possono fornire prestazioni più elevate rispetto agli altri tipi di disco e puoi scegliere le IOPS richieste. Ma pd-extreme costa più degli altri tipi di disco.

Per ulteriori informazioni sulle prestazioni dei dischi permanenti, consulta Prestazioni dell'archiviazione a blocchi.

Per l'archiviazione temporanea, puoi utilizzare SSD locali temporanee. Le unità SSD locali sono fisicamente collegate al server che ospita le VM. Per questo motivo, le unità SSD locali garantiscono una velocità effettiva superiore e una latenza più bassa rispetto ai dischi permanenti. Tuttavia, i dati archiviati su un SSD locale vengono mantenuti solo fino a quando la VM non viene arrestata o eliminata.

Server di archiviazione di oggetti

Quando progetti l'infrastruttura per i nodi OSS, ti consigliamo quanto segue:

  • Per l'archiviazione, scegli un tipo di Persistent Disk appropriato in base ai tuoi requisiti di capacità di archiviazione, velocità effettiva e IOPS.

    • Utilizza pd-standard per carichi di lavoro che hanno i seguenti requisiti:
      • Il carico di lavoro richiede un'elevata capacità di archiviazione (ad esempio, più di 10 TB) oppure un'elevata velocità effettiva di lettura e un'elevata capacità di archiviazione.
      • La latenza I/O non è importante.
      • È accettabile una bassa velocità effettiva di scrittura.
    • Utilizza pd-balanced per i carichi di lavoro che hanno uno dei seguenti requisiti:
      • Velocità effettiva elevata a bassa capacità.
      • La bassa latenza offerta dai dischi basati su SSD.
    • Utilizza pd-ssd per i carichi di lavoro che richiedono un numero elevato di IOPS (richieste di I/O di piccole dimensioni o file di piccole dimensioni).

  • Esegui il provisioning di una capacità di archiviazione sufficiente per raggiungere il numero di IOPS richiesto. Considera le IOPS di lettura e scrittura fornite da ogni tipo di disco.

  • Per le VM, utilizza un tipo di macchina della famiglia di macchine N2 o N2D. Questi tipi di macchine offrono prestazioni prevedibili ed economicamente convenienti.

  • Alloca un numero sufficiente di vCPUs per raggiungere la velocità effettiva Persistent Disk richiesta. La velocità effettiva massima Persistent Disk per VM è 1, 2 GB/s e si può ottenere con 16 vCPU. Inizia quindi con un tipo di macchina con 16 vCPU. Monitora le prestazioni e alloca più vCPU quando hai bisogno di scalare le IOPS.

Server dei metadati

I nodi MDS non hanno bisogno di un'elevata capacità di archiviazione per la pubblicazione dei metadati, ma hanno bisogno di uno spazio di archiviazione in grado di supportare un numero elevato di IOPS. Durante la progettazione dell'infrastruttura per i nodi MDS, è consigliabile:

  • Per l'archiviazione, utilizza pd-ssd perché questo tipo di Persistent Disk fornisce un numero elevato di IOPS (30 IOPS per GB) anche con una capacità di archiviazione ridotta.
  • Esegui il provisioning di una capacità di archiviazione sufficiente per raggiungere il numero di IOPS richiesto.
  • Per le VM, utilizza un tipo di macchina della famiglia di macchine N2 o N2D. Questi tipi di macchine offrono prestazioni prevedibili ed economicamente convenienti.
  • Alloca un numero sufficiente di vCPU per raggiungere gli IOP richiesti:
    • Per i carichi di lavoro con pochi metadati, utilizza 16 vCPU.
    • Per i carichi di lavoro di metadati medi, utilizza 32 vCPU.
    • Per i carichi di lavoro che richiedono un uso intensivo di metadati, utilizza 64 vCPU. Monitora le prestazioni e alloca più vCPU quando necessario.

Server di gestione

MGS ha bisogno di risorse di calcolo minime. Non è un servizio che richiede un uso intensivo dello spazio di archiviazione. Inizia con un tipo di macchina di piccole dimensioni per la VM (ad esempio, n2-standard-2) e un disco pd-ssd da 128 GB per l'archiviazione e monitora le prestazioni. Se la risposta è lenta, alloca più vCPU e aumenta le dimensioni del disco.

Disponibilità e durabilità

Se hai bisogno di un'archiviazione permanente, i tipi di Persistent Disk pd-standard e pd-balanced offrono uno spazio di archiviazione a disponibilità elevata e durevole all'interno di una zona. Per la persistenza tra zone o regioni, puoi copiare i dati in Cloud Storage a basso costo utilizzando Google Cloud CLI o Storage Transfer Service. Per ridurre i costi di archiviazione dei dati in Cloud Storage, puoi archiviare i dati a cui si accede raramente in un bucket della classe Nearline Storage o Coldline Storage.

Se hai bisogno solo di spazio di archiviazione temporaneo per un deployment temporaneo, utilizza le SSD locali come dischi dati per i nodi OSS e MDS. Questo design offre prestazioni elevate con il minor numero di VM OSS. Inoltre, questa struttura consente di raggiungere un rapporto costo/prestazioni ottimale rispetto alle altre opzioni.

Esempio di dimensionamento per le VM OSS

La strategia consigliata per dimensionare e eseguire il provisioning del file system Lustre è eseguire il provisioning di un numero sufficiente di VM OSS per soddisfare il requisito di velocità effettiva complessivo. Quindi, aumenta la capacità di archiviazione dei dischi OST fino a raggiungere la capacità di archiviazione richiesta. Il carico di lavoro di esempio utilizzato in questa sezione mostra come implementare questa strategia tramite i seguenti passaggi:

  1. Determinare i requisiti del carico di lavoro.
  2. Scegli un tipo di Persistent Disk.
  3. Calcola il numero di VM OSS.
  4. Calcola la dimensione del disco per VM.
  5. Determina il numero di vCPU per VM.

Determina i requisiti del carico di lavoro

In questo esempio, il carico di lavoro richiede 80 TB di capacità di archiviazione permanente con una velocità effettiva di lettura di 30 GB/s.

Scegli un tipo di Persistent Disk

Come discusso nella sezione Opzioni di archiviazione, pd-standard è l'opzione più conveniente quando la capacità di archiviazione è l'obiettivo di progettazione principale, mentre pd-balanced è l'opzione più conveniente per massimizzare la velocità effettiva. La velocità effettiva massima varia per ogni tipo di disco e la velocità effettiva viene scalata in base alle dimensioni del disco.

Per ogni tipo di Persistent Disk utilizzabile per questo carico di lavoro, calcola la capacità di archiviazione necessaria per scalare la velocità effettiva di lettura fino al target di 30 GB/s.

Tipo di disco Velocità effettiva di lettura per TB Capacità di archiviazione richiesta per raggiungere la velocità effettiva target
pd-standard 0,12 GB/s 30 diviso per 0,12 = 250 TB
pd-balanced 0,28 GB/s 30 diviso per 0,28 = 107 TB

Per raggiungere una velocità effettiva di lettura target di 30 Gbps utilizzando pd-standard, dovresti eseguire il provisioning di 250 TB di capacità di archiviazione. Questo importo è il triplo della capacità richiesta di 80 TB. Quindi per il carico di lavoro in questo esempio, pd-balanced offre uno spazio di archiviazione conveniente che soddisfa i requisiti delle prestazioni.

Calcola il numero di VM OSS

La velocità effettiva di lettura massima per VM di Compute Engine è 1,2 GB/s. Per ottenere una velocità effettiva di lettura target di 30 GB/s, dividi la velocità effettiva di lettura target per la velocità effettiva massima per VM come segue:

   30 GBps / 1.2 GBps = 25

Sono necessarie 25 VM OSS per raggiungere la velocità effettiva di lettura target.

Calcola la dimensione disco per VM

Per calcolare la dimensione del disco per VM, dividi la capacità (107 TB) necessaria per raggiungere la velocità effettiva target (30 GB/s) per il numero di VM come segue:

   107 TB / 25 VMs = 4.3

Hai bisogno di 4,3 TB di capacità pd-balanced per VM.

Determina il numero di vCPU per VM

La velocità effettiva di lettura di una VM scala con il numero di vCPU allocate alla VM. La velocità effettiva di lettura raggiunge un picco di 1,2 Gbps per 16 (o più) vCPU. È necessario un tipo di macchina con almeno 16 vCPU. Scegli quindi un tipo di macchina dalla famiglia di macchine N2 o N2D, ad esempio n2-standard-32.

Riepilogo configurazione

Il carico di lavoro di esempio ha i seguenti requisiti:

  • 80 TB di capacità di archiviazione permanente
  • Velocità effettiva di lettura 30 Gbps

Per soddisfare i requisiti di questo carico di lavoro, sono necessarie le seguenti risorse di calcolo e archiviazione:

  • Numero di VM OSS: 25
  • Famiglia di macchine VM: N2 o N2D
  • Numero di vCPU per VM: 16 o più
  • Tipo di disco permanente: pd-balanced
  • Dimensioni disco per VM: 4,3 TB

Esempio di configurazione per un file system temporaneo

La seguente configurazione si basa su un invio di Google Cloud a IO500 che dimostra le prestazioni di un file system di archiviazione di grandi dimensioni su scala estrema che utilizza Lustre e ne viene eseguito il deployment su Google Cloud:

Parametro di configurazione MDS OSS Client
Numero di VM 50 200 1000
Tipo di macchina n2-standard-80 n2-standard-64 c2-standard-16
Numero di vCPU per VM 80 vCPU 64 vCPU 16 vCPU
RAM per VM 320 GB 256 GB 64 GB
Sistema operativo CentOS 8 CentOS 8 CentOS 8
Larghezza di banda della rete 100 Gbps 75 Gbit/s 32 Gbit/s
Archiviazione SSD locale NVMe da 9 TB
(24 dischi)		 NVMe da 9 TB
(24 dischi)		 Nessuna

La configurazione precedente ha fornito le seguenti prestazioni:

Metrica delle prestazioni Risultato
Velocità effettiva di scrittura 700 GBps (5,6 Tbps)
Velocità effettiva di lettura 1.270 GB/s (10,16 Tbps)
Operazioni stat() su file 1,9 milioni al secondo
Lettura di file di piccole dimensioni (3901 byte) 1,5 milioni al secondo

Opzioni di relative al deployment

Questa sezione fornisce una panoramica dei metodi che puoi utilizzare per eseguire il deployment di un file system EXAScaler Cloud in Google Cloud. Questa sezione descrive anche i passaggi da seguire per il deployment delle VM client.

Deployment del file system EXAScaler Cloud

Puoi scegliere tra i seguenti metodi per eseguire il deployment di un file system EXAScaler Cloud in Google Cloud:

Entrambi i metodi ti consentono di personalizzare il file system quando esegui il deployment. Ad esempio, puoi specificare il numero di VM OSS, il tipo di macchina per le VM, i tipi di Persistent Disk e la capacità di archiviazione.

Quando scegli un metodo, considera le seguenti differenze:

  • Modifica post-deployment: se utilizzi Cloud HPC Toolkit, puoi modificare in modo efficiente il file system dopo il deployment. Ad esempio, per aggiungere capacità di archiviazione, puoi aumentare il numero di nodi OSS aggiornando il progetto base di Cloud HPC Toolkit e applicando di nuovo la configurazione Terraform generata. Per un elenco dei parametri che puoi specificare nel progetto base, consulta la sezione Inputs nel file README per il modulo Terraform. Per modificare un file system di cui è stato eseguito il deployment utilizzando la soluzione Cloud Marketplace, devi apportare singolarmente le modifiche per ogni risorsa di calcolo e archiviazione utilizzando la console Google Cloud, gcloud CLI o l'API.

  • Assistenza: la soluzione Cloud Marketplace utilizza Deployment Manager, che non è supportato dai Controlli di servizio VPC. Per ulteriori informazioni su questa limitazione, consulta la pagina relativa a prodotti supportati e limitazioni di Controlli di servizio VPC.

Deployment client

Puoi utilizzare uno dei metodi descritti nella sezione Deployment del file system EXAScaler Cloud per eseguire il deployment delle VM client. Tuttavia, Google consiglia di eseguire il provisioning e la gestione delle VM client separatamente dal file system. Il modo consigliato per eseguire il deployment dei client è utilizzare l'immagine VM HPC fornita da Google, ottimizzata per i carichi di lavoro HPC.

Di seguito è riportata una panoramica del processo di utilizzo dell'immagine VM HPC per il deployment dei client Lustre:

  1. Crea una VM utilizzando l'immagine VM HP.
  2. Installare i pacchetti client Lustre sulla VM.
  3. Personalizza la VM in base alle tue esigenze.
  4. Crea un'immagine personalizzata dalla VM.
  5. Esegui il provisioning delle VM client Lustre utilizzando l'immagine personalizzata che hai creato. Per automatizzare il provisioning e la gestione delle VM client, puoi utilizzare un gruppo di istanze gestite di Compute Engine o uno strumento di terze parti come Gestore carichi di lavoro di Slurm.
  6. Monta il file system Lustre sulle VM client.

Opzioni di trasferimento dati

Dopo aver eseguito il deployment di un file system Lustre in Google Cloud, devi spostare i dati nel file system. La seguente tabella mostra i metodi che puoi utilizzare per spostare i dati nel file system Lustre. Scegli il metodo che corrisponde al volume di dati che devi spostare e alla località dei dati di origine (on-premise o in Cloud Storage).

Origine dati Dimensioni dei dati Metodo di trasferimento dei dati consigliato
On-premise Piccolo (ad esempio, meno di 1 TB) Conservare temporaneamente i dati in Cloud Storage utilizzando lo strumento gsutil. Quindi, scarica i dati nel file system Lustre utilizzando Storage Transfer Service o gcloud CLI.
On-premise Large Sposta i dati nel file system Lustre utilizzando Storage Transfer Service. Segui le istruzioni riportate in Trasferire dati tra file system POSIX.

Questo metodo prevede l'utilizzo di un bucket Cloud Storage intermediario. Dopo aver completato il job di trasferimento, Storage Transfer Service elimina i dati nel bucket intermedio.
Cloud Storage Grande o piccolo Scarica i dati da Cloud Storage nel file system Lustre utilizzando Storage Transfer Service o gcloud CLI.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Cross-Product Solution Developer

Altri collaboratori: