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 Lustre file system per computing ad alte prestazioni (HPC) carichi di lavoro con scale out impegnativi. Fornisce inoltre una panoramica della procedura di deployment di un file Lustre. in Google Cloud utilizzando DDN EXAScaler.

Lustre è un file system parallelo open source che fornisce velocità effettiva elevata e archiviazione a bassa latenza carichi di lavoro HPC a stretto accoppiamento. Puoi scalare 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 offerto da DDN un partner di Google. Puoi eseguire il deployment di EXAScaler Cloud in un'architettura cloud ibrida per aumentare la capacità dell'HPC on-premise. EXAScaler Cloud può anche fungere da per l'archiviazione di asset a lungo termine da un sistema EXAScaler on-premise e deployment continuo.

Le linee guida di questo documento sono rivolte ai business architect e tecnici che progettano, eseguono il provisioning e gestiscono l'archiviazione per l'HPC (computing ad alte prestazioni) carichi di lavoro con scale out impegnativi nel cloud. Il documento presuppone che tu abbia un'idea la comprensione dei file system paralleli. Dovresti anche avere compreso i casi d'uso dell'HPC (computing ad alte prestazioni) per cui sono ideali i file system paralleli come Lustre. Per ulteriori informazioni, vedi 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): il servizio MGS archivia e gestisce le informazioni di configurazione su uno o più file Lustre sistemi diversi. Il diagramma mostra il servizio MGS che gestisce un singolo file system Lustre. Il servizio MGS fornisce informazioni di configurazione agli altri componenti Lustre. in tutti i file system che gestisce. MGS registra il file system di configurazione nei dispositivi di archiviazione chiamati MGT.

  • Server dei metadati (MDS) e target dei metadati (MDT): i nodi MDS. gestire l'accesso client allo spazio dei nomi di un file system Lustre. Questo include tutti i metadati del file system, come gerarchia delle directory, data e ora di creazione dei file e autorizzazioni di accesso. La I metadati vengono archiviati in dispositivi di archiviazione chiamati MDT. Un file Lustre ha almeno un MDS e un MDT associato. Per migliorare il per carichi di lavoro ad alta intensità di metadati, ad esempio di clienti creano e accedono a milioni di piccoli file, puoi aggiungere altri MDS nodi al file system.

  • Server di archiviazione di oggetti (OSS) e destinazioni di archiviazione di oggetti (OST): I nodi OSS gestiscono l'accesso client ai dati dei file archiviati in un File system Lustre. Ogni file viene archiviato come uno o più oggetti Lustre. Gli oggetti vengono archiviati in un unico dispositivo di archiviazione (denominato OST) o a righe su più nodi OSS e OST. Un file system Lustre ha almeno uno OSS e un OST associato. Puoi scalare la capacità di archiviazione delle prestazioni del file system aggiungendo più nodi OSS e OST. Il totale di archiviazione del file system è la somma delle capacità di archiviazione le OST collegate a tutti i nodi OSS nel file system.

  • Client: un client Lustre è un nodo di computing, ad esempio un client (VM) che accede a un file system Lustre tramite una 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 di oltre 10.000 clienti. I client Lustre accedono a tutti i nodi MDS e OSS in un cluster Lustre in parallelo. Questo accesso parallelo consente di massimizzare le prestazioni del file system. L'accesso parallelo aiuta anche a ridurre hotspot di archiviazione, ovvero posizioni di archiviazione a cui si accede molto spesso rispetto ad altre località. Gli hotspot sono comuni nei file non paralleli e può causare uno squilibrio tra le prestazioni dei client.

    Per accedere a un file system Lustre, un client ottiene la directory richiesta e i metadati di un file MDS, quindi legge o scrive i dati comunicando con uno o più nodi OSS. Lustre consente di chiudere conformità alla semantica di POSIX, e consente a tutti i client l'accesso completo e parallelo al file system.

Per ulteriori informazioni sul file system Lustre e su come funziona, consulta Documentazione Luustre.

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 risorse seguenti. Tutti i il deployment delle risorse in un unico progetto Google Cloud. Le risorse di computing e archiviazione viene eseguito il provisioning delle risorse all'interno di una singola zona.

  • Compute Engine Le VM 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 di eseguire il deployment del file system sulle VM di Compute Engine.

  • L'architettura include le seguenti risorse di networking:

    • Un singolo Subnet Virtual Private Cloud (VPC) usato per tutte le VM.
    • Un'intestazione facoltativa Cloud NAT un gateway e un oggetto Router Cloud per il traffico in uscita dalle VM private a internet.
    • Facoltativa regole firewall per consentire le 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.

  • Dischi permanenti forniscono capacità di archiviazione per i nodi MGS, MDS e OSS. Se non ti serve di archiviazione permanente, puoi creare graffio utilizzando dischi SSD locali, che vengono collegati alle VM.

    Google ha inviato IO500 voci che dimostrano le prestazioni delle funzioni Lustre persistenti e scratchpad file system in-app. Scopri di più sulle Invio di Google Cloud che dimostra un file system temporaneo basato su Lustre da oltre 10 Tbps su IO500 dei sistemi di archiviazione HPC.

Linee guida per il layout

Utilizza le seguenti linee guida per progettare un file system Lustre che soddisfi le per i tuoi carichi di lavoro HPC. Le linee guida di questa sezione non sono esaustivi. Forniscono un framework per aiutarti a valutare i requisiti di archiviazione dei tuoi carichi di lavoro HPC, valuta le opzioni di archiviazione disponibili e dimensiona File system Lustre.

Requisiti per i carichi di lavoro

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

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

Opzioni di archiviazione

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

  • I dischi permanenti standard (pd-standard) sono i più convenienti quando la capacità di archiviazione è il principale obiettivo di progettazione. Forniscono archiviazione a blocchi efficiente e affidabile mediante unità a disco rigido (HDD).
  • I dischi permanenti SSD (pd-ssd) sono l'opzione più conveniente quando l'obiettivo è massimizzare le IOPS. Forniscono archiviazione a blocchi rapida e affidabile utilizzando le unità SSD.
  • I dischi permanenti bilanciati (pd-balanced) sono i più convenienti per massimizzare la velocità effettiva. Sono convenienti e affidabili l'archiviazione a blocchi tramite SSD.

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

Per ulteriori informazioni sulle prestazioni dei dischi permanenti, vedi Blocca le prestazioni dello spazio di archiviazione.

Per l'archiviazione temporanea, puoi usare SSD locali. Le unità SSD locali sono fisicamente collegate al server che ospita le VM. A livello locale Gli SSD offrono una velocità effettiva superiore e una latenza inferiore rispetto ai dischi permanenti. Ma i dati archiviati su un SSD locale vengono mantenuti solo fino all'arresto della VM eliminati.

Server di archiviazione di oggetti

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

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

    • Utilizza pd-standard per i carichi di lavoro con i seguenti requisiti:
      • Il carico di lavoro necessita di un'elevata capacità di archiviazione (ad esempio, più di 10 TB) o necessita di un'elevata velocità effettiva di lettura e capacità di archiviazione.
      • La latenza dell'I/O non è importante.
      • Una bassa velocità effettiva di scrittura è accettabile.
    • Utilizza pd-balanced per i carichi di lavoro con uno qualsiasi dei seguenti elementi 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 (piccoli richieste I/O o file di piccole dimensioni).

  • Esegui il provisioning di una capacità di archiviazione sufficiente per raggiungere le IOPS richieste. Prendi in considerazione il IOPS in lettura e scrittura forniti 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 previsioni ed economicamente convenienti.

  • Alloca abbastanza vCPUs per raggiungere la velocità effettiva Persistent Disk richiesta. Il valore massimo La velocità effettiva Persistent Disk per VM è di 1, 2 GBps e può essere con 16 vCPU. Inizia con un tipo di macchina con 16 vCPU. Monitora il rendimento, e allocare più vCPU quando devi scalare le IOPS.

Server metadati

I nodi MDS non hanno bisogno di un'elevata capacità di archiviazione per fornire i metadati, richiedono uno spazio di archiviazione che supporti un numero elevato di IOPS. Quando si progetta l'infrastruttura Nodi MDS, consigliamo quanto segue:

  • Per l'archiviazione, usa pd-ssd perché questo tipo di Persistent Disk fornisce IOPS elevate (30 IOPS per GB) anche in caso di scarsa capacità di archiviazione.
  • Esegui il provisioning di una capacità di archiviazione sufficiente per raggiungere le IOPS richieste.
  • Per le VM, utilizza un tipo di macchina della famiglia di macchine N2 o N2D. Questi tipi di macchine offrono previsioni ed economicamente convenienti.
  • Alloca un numero sufficiente di vCPU per raggiungere gli IOP richiesti:
    • Per carichi di lavoro con metadati ridotti, utilizza 16 vCPU.
    • Per carichi di lavoro con metadati medi, utilizza 32 vCPU.
    • Per carichi di lavoro ad alta intensità di metadati, utilizza 64 vCPU. Monitora il rendimento, e allocare più vCPU quando necessario.

Server di gestione

L'MGS ha bisogno di risorse di calcolo minime. Non è un servizio ad alta intensità di archiviazione. Inizia con un tipo di macchina di piccole dimensioni per la VM (ad esempio, n2-standard-2) e un Disco da 128 GB pd-ssd per l'archiviazione e monitorarne le prestazioni. Se la risposta è lenta, alloca più vCPU e aumenta la dimensione del disco.

Disponibilità e durabilità

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

Se hai bisogno solo di archiviazione temporanea per un deployment temporaneo, usa local SSD come dischi dati per Nodi OSS e MDS. Questo design offre prestazioni elevate con il minor numero di delle VM OSS. Questa progettazione consente inoltre di ottenere un rapporto rapporto costo-prestazioni ottimale rapporto rispetto alle altre opzioni.

Esempio di dimensionamento delle VM OSS

La strategia consigliata per il dimensionamento e il provisioning del file system Lustre è per eseguire il provisioning di un numero di VM OSS sufficiente a soddisfare il requisito di velocità effettiva complessivo. Poi, aumentare la capacità di archiviazione dei dischi OST fino a raggiungere la e capacità di archiviazione. Il carico di lavoro di esempio utilizzato in questa sezione mostra come implementare questa strategia seguendo questa procedura:

  1. Determinare i requisiti del carico di lavoro.
  2. Scegli un tipo di Persistent Disk.
  3. Calcola il numero di VM OSS.
  4. Calcolare 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 GBps.

Scegli un tipo di Persistent Disk

Come discusso nel Opzioni di archiviazione pd-standard è l'opzione più conveniente quando la capacità di archiviazione è il principale obiettivo di progettazione e pd-balanced è l'opzione più conveniente per massimizzare la velocità effettiva. La velocità effettiva massima è diversa per ogni tipo di disco e la velocità effettiva scala con la dimensione del disco.

Per ogni tipo di Persistent Disk che può essere utilizzato per questo carico di lavoro, calcola la capacità di archiviazione necessaria per scalare la velocità effettiva di lettura verso il target di 30 Gbps.

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

Per raggiungere la velocità effettiva di lettura target di 30 Gbps utilizzando pd-standard, eseguire il provisioning di 250 TB di capacità di archiviazione. Questo importo è superiore a tre moltiplicata per la capacità richiesta di 80 TB. Per il carico di lavoro in questo esempio, pd-balanced offre uno spazio di archiviazione conveniente che soddisfa le prestazioni i tuoi requisiti.

Calcolare il numero di VM OSS

La velocità effettiva di lettura massima per VM di Compute Engine è 1,2 GBps. A raggiungere la velocità effettiva di lettura target di 30 GBps, dividere 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.

Calcolare la dimensione del disco per VM

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

   107 TB / 25 VMs = 4.3

Sono necessari 4,3 TB di pd-balanced capacità per VM.

Determina il numero di vCPU per VM

La velocità effettiva di lettura di una VM viene scalata in base al numero di vCPU allocate VM. La velocità effettiva di lettura raggiunge il picco di 1,2 Gbps per 16 (o più) vCPU. È necessaria una tipo di macchina che fornisce almeno 16 vCPU. Scegli quindi un tipo di macchina tra N2 o N2D famiglia di macchine, come n2-standard-32.

Riepilogo configurazione

Il carico di lavoro di esempio prevede i seguenti requisiti:

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

Per soddisfare i requisiti di questo carico di lavoro, sono necessarie le seguenti risorse di computing di archiviazione di Google Cloud:

  • 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
  • Dimensione 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 temporaneo su scala estrema che utilizza Lustre e il deployment viene eseguito su Google Cloud:

Parametro di configurazione MDS OSS Clienti
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
Spazio di archiviazione SSD locale NVMe da 9 TB
(24 dischi)		 NVMe da 9 TB
(24 dischi)		 Nessuno

La configurazione precedente forniva le seguenti prestazioni:

Metrica delle prestazioni Risultato
Velocità effettiva di scrittura 700 Gbps (5,6 Tbps)
Velocità effettiva di lettura 1270 GBps (10,16 Tbps)
Operazioni stat() sui file 1,9 milioni al secondo
Letture di file di piccole dimensioni (3901 byte) 1,5 milioni al secondo

Opzioni di implementazione

Questa sezione fornisce una panoramica dei metodi che puoi usare per eseguire il deployment File system EXAScaler Cloud in Google Cloud. Questa sezione illustra inoltre i passaggi da seguire quando esegui il deployment delle VM client.

Deployment del file system EXAScaler Cloud

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

Con entrambi i metodi, puoi personalizzare il file system quando ne esegui il deployment. Per Ad esempio, puoi specificare il numero di VM OSS, il tipo di macchina i tipi di Persistent Disk e la capacità di archiviazione.

Quando scegli un metodo, considera le seguenti differenze:

  • Modifica post-deployment: se utilizzi Cluster Toolkit, puoi modificare in modo efficiente il file system dopo il deployment. Ad esempio, per aggiungi capacità di archiviazione, puoi aumentare il numero di nodi OSS aggiornando il progetto di Cluster Toolkit e applicando il modello configurazione di Terraform. Per un elenco dei parametri che puoi specifica nel progetto, controlla Input nel file README del modulo Terraform. Per modificare un file system di cui viene eseguito il deployment tramite la soluzione Cloud Marketplace, devi le modifiche per ogni risorsa di computing e archiviazione singolarmente utilizzando la console Google Cloud, gcloud CLI o l'API.

  • Assistenza: la soluzione Cloud Marketplace utilizza Deployment Manager, che non è supportato da Controlli di servizio VPC. Per ulteriori informazioni su questa limitazione, consulta: Prodotti supportati e limitazioni per i Controlli di servizio VPC.

Deployment client

Puoi utilizzare uno dei due metodi descritti in Deployment del file system Cloud EXAScaler per il deployment delle VM client. Tuttavia, Google consiglia di eseguire il provisioning e gestire le VM client separatamente dal file system. Metodo consigliato per il deployment dei tuoi clienti consiste nell'utilizzare lo strumento Immagine VM HPC ottimizzato per carichi di lavoro HPC.

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

  1. Crea una VM utilizzando Immagine VM HPC.
  2. Installare i pacchetti client Lustre sulla VM.
  3. Personalizza per la VM in base alle esigenze.
  4. Crea un immagine personalizzata dalla VM.
  5. Esegui il provisioning delle VM client di Lustre utilizzando l'immagine personalizzata che hai creato. Per automatizzare il provisioning e la gestione delle VM client, puoi utilizzare un'istanza Compute Engine gruppo di istanze gestite 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 al file system. La tabella seguente mostra i metodi che puoi per spostare i dati nel file system Lustre. Scegli il metodo che corrisponde al volume dei dati da spostare e alla posizione dei dati di origine (on-premise o in Cloud Storage).

Origine dati Dimensioni dei dati Metodo di trasferimento dati consigliato
On-premise Piccolo (ad es. meno di 1 TB) Crea temporaneamente i dati in Cloud Storage utilizzando Google Cloud CLI. Quindi, scarica i dati al file system Lustre tramite Storage Transfer Service o gcloud CLI.
On-premise Grande Spostare i dati nel file system Lustre utilizzando Storage Transfer Service. Segui le istruzioni riportate in Trasferire dati tra file POSIX. Google Cloud.

Questo metodo comporta l'utilizzo di un intermediario nel bucket Cloud Storage. Dopo aver completato il job di trasferimento, Storage Transfer Service elimina i dati nell'intermediario di sincronizzare la directory di una VM con un bucket.
Cloud Storage Grande o piccola Scarica i dati da Cloud Storage nel file Lustre utilizzando Storage Transfer Service o gcloud CLI.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: