Ciao a tutti e bentornati.
Nel video di oggi parleremo in modo più dettagliato di Amazon FS for Luster.
In una panoramica di alto livello, sappiamo già che il volto di Amazon per Luster è un file system completamente
gestito basato su Luster.
Ora, se si guarda a questo diagramma, esso indica fondamentalmente il flusso di lavoro orale.
Quindi cosa fare?
In genere si crea il file system luster.
Quindi è possibile collegarlo o integrarlo con un servizio, principalmente Amazon S3, dove è possibile effettuare
la sincronizzazione e quindi associare o montare questo file system specifico su più risorse.
Può trattarsi di due istanze X e X on premise, ecc. Una volta montato il file system, è possibile eseguire
le attività HPC di apprendimento automatico.
Questo è il flusso di lavoro complessivo.
Quindi, nell'ambito di Luster, ci sono alcuni casi d'uso che dovete ricordare e cioè che viene utilizzato principalmente per
casi d'uso di apprendimento automatico.
I casi di utilizzo dell'HPC per l'analisi dei big data e persino per i VFX.
Quindi, come parte del flusso di lavoro complessivo, supponiamo che il vostro FS quattro lustri sia integrato con il bucket S3.
Quindi il primo passo primario è che i dati archiviati in S3 vengano caricati sul vostro FS quattro lustri per essere
elaborati.
Quindi ci sarebbero dei dati da elaborare, che si trovano nel bucket S3.
Quindi si caricano i dati sul file system Luster.
Il file system Luster viene a sua volta montato su un insieme di due istanze EC.
Quindi, una volta che i file sono montati in Luster, l'elaborazione dei file può avvenire nell'insieme delle
due istanze EC e l'output finale del processo può essere restituito alle tre istanze S per la conservazione complessiva.
Ora, una parte specifica da ricordare è che FS four luster è integrato in modo nativo con i repository
di dati come Amazon S3. Quindi, se guardate questa schermata specifica, avete l'integrazione
del repository di dati, di tipo tre, e poi specificate il bucket S3.
Si tratta quindi del bucket specifico da cui i dati verranno aggiunti al file system Luster.
Ora vi mostrerò rapidamente che ho già il file system Luster disponibile in questo file system specifico,
se guardate al repository dei dati, avete il bucket Amazon S3, avete il percorso di importazione, avete
la parte di esportazione.
In questo modo è possibile associare un bucket S3 specifico a Luster.
Infatti, ogni volta che si crea un file system Luster, andiamo un po' più in basso.
È disponibile un'opzione specifica relativa al repository dei dati in cui è possibile importare i dati e anche
esportarli in S3.
Perciò, se vedete, dovrete specificare i tre secchi.
E ancora, ci sono alcune impostazioni di importazione e di esportazione.
Nelle impostazioni di importazione è possibile specificare tre opzioni principali.
È quindi necessario scegliere quali aggiornamenti apportare all'archivio dati.
In questo caso, tre dovrebbero essere propagati al file system.
Quindi, in pratica, ogni volta che effettuiamo degli aggiornamenti al bucket S3, in base al tipo di aggiornamenti che devono essere
propagati al file system, soprattutto perché saranno collegati.
Allo stesso modo, sono disponibili anche le impostazioni di esportazione, in cui è possibile scegliere quali aggiornamenti
che fanno parte del file system devono essere propagati al repository dei dati, ovvero S3.
Va bene.
Spero che a questo punto abbiate capito cosa si intende per archivio dati.
È necessario comprendere il concetto di base del caricamento pigro dei dati.
In sintesi, il caricamento pigro è una pratica che consiste nel ritardare il caricamento o l'inizializzazione di risorse o oggetti fino
a quando non sono effettivamente necessari.
Questo può essere compreso meglio con questo diagramma: supponiamo di avere un bucket
contenente petabyte di dati e di avere il file system FS per Lustre.
Ora, quando si integra il FS con l'S3, è necessario che tutti i petabyte di dati presenti nell'S3 facciano parte
del lustro?
La risposta è no nella maggior parte dei casi, ed è per questo motivo che si caricano solo i dati necessari.
Su questa base, i dati necessari saranno elaborati dalle due istanze CE.
In questo modo non solo si migliorano le prestazioni complessive, ma si risparmiano anche molte risorse.
Quando si parla di opzioni di distribuzione complessive, le opzioni principali sono
due.
Uno è il graffio e il secondo è il persistente.
Quindi, se vedete anche nel diagramma del tipo di distribuzione e di archiviazione, avete il persistente
e lo scratch.
A seconda dell'opzione scelta, cambiano anche la capacità di archiviazione complessiva e la velocità
di trasmissione.
Pertanto, la prima opzione di distribuzione che verrà esplorata è quella di scratch.
In sintesi, i file system scratch sono progettati principalmente per l'archiviazione temporanea e l'elaborazione
dei dati a breve termine.
Il vantaggio è che fornisce un elevato throughput di burst.
Tuttavia, essendo progettato per casi d'uso temporanei, i dati non vengono replicati e non persistono in caso
di guasto del file server.
Il secondo tipo di opzione di distribuzione è.
Persistente, consigliato per l'archiviazione e i carichi di lavoro a lungo termine.
Il vantaggio è che i file server sono altamente disponibili e i dati vengono replicati automaticamente
all'interno della stessa struttura in cui si trova il file system.
Ora esploriamo anche questo aspetto.
Quindi, se si scende un po' nella configurazione di lustre, si ha l'SSD persistente e l'HDD
persistente.
Sempre in modo persistente, avete sia l'HDD che l'SSD e avete l'SSD scratch.
Si noti che il throughput cambia.
Ad esempio, nell'SSD scratch sono presenti 200.
Per le unità SSD persistenti sono disponibili diverse opzioni.
Prima di concludere, ci sono alcune indicazioni importanti di cui dovete prendere nota.
Il primo è che è possibile configurare FS for lustre per mantenere il contenuto sincronizzato sia in direzione
del file system che dei bucket S3 collegati.
In alternativa, è possibile importare ed esportare batch di dati nuovi e modificati tra il file system
e S3, per ottenere un controllo globale a grana fine sulla sincronizzazione dei dati.
Quindi entrambe le opzioni sono disponibili a seconda del caso d'uso.
Ora, prima di concludere, volevo anche mostrarvi una panoramica di alto livello su come il file
system è collegato a una risorsa specifica come l'istanza EC2.
Quindi la parola più accurata sarebbe montaggio.
Ora, in questa fase abbiamo un file system del cluster e questo file system Leicester, come sappiamo, uno dei repository
di dati qui è il bucket del set di campioni del laboratorio AP.
Ora vogliamo associare questo file system all'istanza EC due che abbiamo.
Quindi è necessario eseguire il comando mount a specific e all'interno di questo dovrete
specificare il DNS del file system.
Ad esempio.
Se si torna indietro, si ottiene il nome DNS.
Copiamo il nome denso.
Copio questo, copiamo questo qui.
E poi dovrete sostituire anche il nome del supporto.
Copiamo il nome del montaggio.
Lo aggiungerò qui e poi si potrà specificare la directory in cui verrà montato il file system.
Ad esempio, creiamo una nuova directory.
Copierò la correzione dei laboratori sulla radice.
Va bene.
È quindi possibile specificare la directory, che è CPU Labs F6, ed eseguire il comando, e
questo è tutto.
Se si esegue mount, si dovrebbe vedere che il nostro file system è montato sulla directory CPU labs F6 e
se si esplora il contenuto della cartella CPU labs FS, si dovrebbero vedere i file che fanno parte del
bucket S3.
Va bene.
Spero che questo vi abbia chiarito meglio il modo in cui i file system creati nell'ambito di PHS vengono
associati o montati nell'ambito di EC.
Due casi.
Con questo si conclude il video di oggi.