Parallele verteilte Dateisysteme - Hochleistungs-Ein-/Ausgabe · ParalleleverteilteDateisysteme Quellen ParalleleverteilteDateisysteme Hochleistungs-Ein-/Ausgabe MichaelKuhn Wissenscha˝lichesRechnen

Parallele verteilte Dateisysteme Quellen

Parallele verteilte DateisystemeHochleistungs-Ein-/Ausgabe

Michael Kuhn

Wissenscha�liches RechnenFachbereich Informatik

Universität Hamburg

2016-04-29

Michael Kuhn Parallele verteilte Dateisysteme 1 / 60


1 Parallele verteilte DateisystemeOrientierungKonzepteLeistungsüberlegungenLustreOrangeFSLeistungsanalyseAusblick und ZusammenfassungLustre-Tutorial

2 Quellen



Orientierung

E/A-Schichten

Anwendung

Bibliotheken

Speichergerät/-verbund

Paralleles verteiltes Dateisystem

Dateisystem

Leis

tung

sana

lyse

Opt

imie

rung

en

Date

nred

uktio

n

Abbildung: E/A-Schichten



Konzepte

Definition

Parallele DateisystemeErlauben parallelen Zugri� auf gemeinsame RessourcenZugri� soll möglichst e�izient erfolgen können

Verteilte DateisystemeDaten und Metadaten sind über mehrere Server verteiltEinzelne Server haben keine vollständige Sicht

Benennung uneinheitlichO� nur „paralleles Dateisystem“ oder „Clusterdateisystem“



Konzepte

Definition. . .

Im Hochleistungsrechnen werden üblicherweise immerparallele verteilte Dateisysteme eingesetzt

NFS nur für nicht leistungskritische AnwendungenLokale Dateisysteme erlauben auch parallelen Zugri�

Sperren z.B. via flock oder lockf


• Home-Verzeichnisse können beispielsweise über NFS realisiertwerden

• Paralleler Zugri� ist in lokalen Dateisystem relativ einfach zuhandhaben

– Alle Zugri�e laufen über das VFS


Konzepte

Definition. . .

Storage Area Network (SAN)Stellt nur Blockgeräte über das Netzwerk bereitDarauf kann beliebiges Dateisystem verwendet werdenParallele verteile Dateisysteme können SANs nutzen

Network Attached Storage (NAS)Abstrahiert von SpeichergerätenStellt direkt ein Dateisystem bereit

Üblicherweise NFS oder SMB



Konzepte

Grundlagen

Daten

Clients

Server

Datei

Abbildung: Paralleler Zugri� und Datenverteilung

Clients greifen parallel auf eine gemeinsame Datei zuDatei ist über mehrere Server und Speichergeräte verteilt

Hoher Durchsatz und hohe Kapazität



Konzepte

Architektur

Netzwerk

Clients

Server

Abbildung: Paralleles verteiltes Dateisystem



Konzepte

Architektur. . .

Clients und ServerClients führen parallele Anwendungen ausHaben über das Netzwerk Zugri� auf DateisystemÜblicherweise kein lokaler Speicher und kein direkter Zugri� aufSpeichergeräteKeine gegenseitige Beeinflussung

Daten- und Metadatenserver„Einfache“ Controller oder vollwertige ServerUnterschiedliche Server für Daten und Metadaten

Produzieren unterschiedliche Zugri�smuster



Konzepte

Architektur. . .

Unterschiedliche KommunikationsansätzeClients kennen zuständigen Server (verbreiteter)Clients kontaktieren einen zufälligen Server

Unterschiedliche SerververhaltenServer teilen Clients zuständigen Server mitServer leiten Anfrage transparent weiter

In beiden Fällen Vor- und Nachteile



Konzepte

Architektur. . .

Clients kennen zuständigen ServerVorteile: Einfaches Kommunikationsprotokoll (eins zu eins),keine Kommunikation zwischen ServernNachteile: Verteilungslogik muss von Clients implementiertwerden, zusätzliche clientseitige Informationen notwendig

Clients kontaktieren einen zufälligen ServerVorteile: Clients müssen Daten-/Metadatenverteilung nichtkennen, Last-Balancierung einfacher umzusetzenNachteile: Zugri�e erfordern zusätzliche Nachrichten,komplexeres Kommunikationsprotokoll



Konzepte

Schnittstelle

Zugri� auf das Dateisystem über E/A-SchnittstelleÜblicherweise standardisiertProprietäre für mehr Funktionen und Leistung

Schnittstelle besteht aus Syntax und SemantikSyntax legt verfügbare Operation festSemantik legt Verhalten der Operationen fest

Häufig POSIX-SchnittstelleStandardisiert und portabel



Konzepte

Schnittstelle. . .

Parallele Anwendung

NetCDF

Lustre

Abbildung: E/A-Stack aus Anwendungssicht

Anwendungen nutzen höher abstrahierende SchnittstellenNetCDF bietet selbst-beschreibendes Datenformat

Paralleles verteiltes Dateisystem kümmert sich um e�izientenZugri� und Verteiltung



Konzepte

Semantik

POSIX hat strenge KonsistenzanforderungenÄnderungen müssen nach write global sichtbar seinE/A soll atomar geschehen

POSIX für lokale DateisystemeAnforderungen dort einfach zu unterstützenAlles über das VFS abgewickelt

Kleinigkeiten änderbarstrictatime, relatime und noatime für Verhaltenbezüglich Zugri�szeitstempelposix_fadvise für Ankündigung des Zugri�smusters



Konzepte

Semantik. . .

Gegensatz: Network File System (NFS)Selbe Syntax, deutlich unterschiedliche Semantik

Sogenannte SitzungssemantikÄnderung für andere Clients nicht sichtbar

Nur innerhalb der SitzungFür andere Clients erst nach deren Endeclose schreibt Änderungen und liefert eventuelle Fehler

Später: MPI-IOWeniger strikt für höhere Skalierbarkeit



Konzepte

Realität

Parallele Anwendung

NetCDF

MPI-IO

Speichergerät/-verbund

ADIO

HDF5

Lustre

ldiskfs

Kernel-Space

User-Space

Abbildung: E/A-Stack im HPC

DatenumwandlungTransport durch alle SchichtenVerlust von Information

Komplexes ZusammenspielOptimierungen undWorkarounds pro SchichtInformationen über andereSchichten

Komfort vs. LeistungStrukturierte Daten inAnwendungBytestrom in POSIX



Konzepte

Realität. . .

Abstraktion

Hoch

Niedrig

~wwwwwwww�

Schnittstelle Datentypen Kontrolle

NetCDF Strukturen Grobgranular

MPI-IO Elemente

POSIX Bytes Feingranular

Abbildung: Abstraktionsstufen

Hohe Abstraktion bietet viel Komfort aber wenig KontrolleNiedrige Abstraktion erlaubt genaues Tuning



Konzepte

Beispiele

GPFS (IBM)LustreOrangeFS (früher PVFS)CephFS (Red Hat)BeeGFS (Fraunhofer, früher FhGFS)GlusterFS (Red Hat)



Leistungsüberlegungen

Generelles

E/A ist im Vergleich zu Berechnung teuerKontextwechsel, langsame Speichergeräte etc.

Parallele verteilte Dateisystem müssen E/A über das Netzwerkabwickeln

Einschränkungen bezüglich Durchsatz und LatenzNeuartige Konzepte wie Burst-Bu�er

Nehmen Daten temporär aufGleichförmiges Weiterreichen an DateisystemZ.B. knoten-lokale nichtflüchtige Speicher (NVRAM)




Daten

Daten werden potentiell von mehreren Clients zugegri�enÜberlappend vs. nicht überlappendLesezugri�e meist unproblematisch

Überlappende Schreibzugri�eStark abhängig von der E/A-SemantikBenötigt üblicherweise SperrenDaher häufig verteilte Sperrenverwaltung




Daten. . .

Datenverteilung relevant für LeistungAnzahl der zu kontaktierenden DatenserverRealisiert über Verteilungsfunktionen

Üblicherweise simples Round-RobinManchmal durch Benutzer steuerbarZ.B. zur Unterstützung heterogener Zugri�smuster




Daten. . .

Blöcke

Server

Streifen

B1B0 B5 B6B3 B4B2 B7

B1

B7B5 B6

B3B2B0B4

Abbildung: Round-Robin-Datenverteilung

Datei aus Blöcken, wird in Streifen auf Server verteiltIn diesem Fall entspricht Blockgröße der Streifengröße

Verteiltung muss nicht auf dem ersten Server startenMichael Kuhn Parallele verteilte Dateisysteme 22 / 60



Metadaten

Metadaten werden von mehreren Clients zugegri�enLesezugri�e üblicherweise wieder unproblematischParallele Änderungen an Größe, Zeitstempel etc.

Metadaten für eine Datei von einem Server verwaltetAktualisierungen daher meist auch seriell

Potentiell mehrere Millionen ClientsDDoS durch Clients auf Metadatenserver




Metadaten. . .

Verteilte Ansätze zur MetadatenverwaltungVeränderliche Metadaten nicht zentral speichern

Z.B. Größe und ZeitstempelBerechnung zur Laufzeit

Client kontaktiert alle relevanten DatenserverAktualisierung auf Kosten der Abfrage beschleunigt

Metadatenverteilung analog zu DatenverteilungBestimmung des Servers z.B. durch Hashing des PfadesMuss üblicherweise deterministisch sein

Clients müssen autonom zuständige Server ermitteln könnenEin Objekt üblicherweise von einem Server verwaltet

Neuerdings Ausnahmen bei Verzeichnissen




Metadaten. . .

Viele Metadatenoperationen sind inhärent seriellZ.B. Pfadauflösung

1 /foo/bar1 Inode des Wurzelverzeichnisses lesen2 Zugri�srechte überprüfen3 Wurzelverzeichnis lesen und nach foo durchsuchen

2 /foo/bar1 Inode des Verzeichnisses lesen2 Zugri�srechte überprüfen3 Verzeichnis lesen und nach bar durchsuchen

3 /foo/bar1 Inode der Datei lesen2 Zugri�srechte überprüfen3 Auf Datei zugreifen




Metadaten. . .

Technologie Gerät IOPS

HDD7.200 RPM 75–100

10.000 RPM 125–15015.000 RPM 175–210

SSDIntel X25-M G2 8.600OCZ Vertex 4 85.000–90.000

Fusion-io ioDrive Octal 1.000.000+

Tabelle: IOPS für ausgewählte HDDs und SSDs [3]

Getrennte Server erlauben gezielte OptimierungZ.B. Festplatten für Daten, Flashspeicher für MetadatenUnterschiedliche Preise (Faktor ≥ 10)Metadaten machen ca. 5 % der Gesamtdaten aus




Leistungsgrößen

Parallele verteilte Dateisysteme erlauben riesige undhochperformante SpeichersystemeBlizzard (DKRZ, GPFS)

Größe: 7 PBDurchsatz: 30 GB/s

Mistral (DKRZ, Lustre)Größe: 50 PBDurchsatz: 400 GB/sIOPS: 80.000 Operationen/s

Titan (ORNL, Lustre)Größe: 40 PBDurchsatz: 1,4 TB/s



Lustre

Übersicht

Eines der bekanntesten parallelen verteilten DateisystemenOpen Source (GPLv2)

> 550.000 Zeilen CodeUnterstützung für Linux

Name abgeleitet von Linux und ClusterSehr weit verbreitet

Mehr als die Häl�e der TOP100Mehr als ein Drittel der TOP500



Lustre

Geschichte

1999: EntwicklungsbeginnForschungsprojekt an der Carnegie Mellon University, geleitetvon Peter Braam

2001: Gründung Cluster File Systems2007: Kauf durch Sun

Integration in HPC-HardwareKombination mit ZFS

2010: Kauf durch OracleEinstellung der Entwicklung

Weiterentwicklung durch CommunityIntel (ehemals Whamcloud), Seagate (ehemals Xyratex),OpenSFS, EOFS etc.



Lustre

Geschichte. . . [1]

Version 2.3 (Oktober 2012)Experimentelle Unterstützung für ZFS

Version 2.4 (Mai 2013)Distributed Namespace (DNE)ZFS für Daten und Metadaten

Version 2.5 (Oktober 2013)Hierarchical Storage Management (HSM)

Version 2.6 (Juli 2014)Experimentelle Unterstützung für verteilte Verzeichnisse

Version 2.7 (März 2015)Bessere Unterstützung für verteilte Verzeichnisse (experimentell)Objektplatzierung via lfs setstripe

Aktuell Version 2.8 (März 2016)



Lustre

Geschichte. . .

1 $ lfs mkdir --index 0 /lustre/home2 $ lfs mkdir --index 1 /lustre/scratch3 $ lfs mkdir --count 3 /lustre/striped

Listing 1: DNE in Lustre

DNE erlaubt unterschiedliche Verzeichnisse aufunterschiedliche Metadatenserver zu verteilen

/scratch für große Dateien/home üblicherweise mit vielen kleinerenStatischer Ansatz, manuelle Konfiguration

Experimentelle Unterstützung für verteilte Verzeichnisse/striped über drei Metadatenserver verteilt



Lustre

Architektur

Netzwerk

Clients

MDSsMDTs

OSSsOSTs

Abbildung: Lustre-Architektur



Lustre

Architektur. . .

Object Storage Servers (OSSs)Verwalten DatenObjekt-basierter Zugri� auf Byte-EbeneEin oder mehrere Object Storage Targets (OSTs)

Metadata Servers (MDSs)Verwalten MetadatenNicht in eigentliche E/A involviertEin oder mehrere Metadata Targets (MDTs)

Verteilung über Targets, nicht über Server



Lustre

Architektur. . .

Daten- und Metadatenserver nutzen lokales DateisystemÜblicherweise ldiskfs (ext4-Fork)Alternativ ZFS (Data Management Unit)

Dadurch kein POSIX-Overhead

Kein direkter Zugri� auf Speichergeräte durch ClientsClients senden Anfragen an ServerServer führen Operationen durchServer schicken Ergebnisse an Clients



Lustre

Architektur. . .

Netzwerk

Clients

MDSMDTs

OSSsOSTs

(a) Metadatenzugri�

Netzwerk

Clients

MDSMDTs

OSSsOSTs

(b) Datenzugri�

Metadatenserverzugri� nur für initiales Ö�nenDanach direkter paralleler Zugri� auf Datenserver



Lustre

Unterstützung

Lustre ist ein Kernel-DateisystemSowohl Client als auch Server

Client unterstützt (relativ) aktuelle KernelSeit 3.12 direkt in den Kernel integriert (aber veraltet)Unterstützung neuer Kernel dauert manchmal eine Weile

Server unterstützt nur ausgewählte Enterprise-KernelZ.B. Red Hat Enterprise Linux (oder CentOS)Hauptsächlich verursacht durch ldiskfsMit ZFS auch Unterstützung des Standard-Kernels



Lustre

Funktionalität

Verteilte SperrenverwaltungSowohl für Daten als auch MetadatenÜberlappende Lesesperren und nicht-überlappendeSchreibsperren auf Byte-EbeneMountoptionen flock bzw. localflock

POSIX-konformPOSIX-Schnittstelle durch VFSKeine native Unterstützung für MPI-IO



Lustre

Funktionalität. . .

Hierarchical Storage ManagementWichtige Anforderung für große SpeichersystemeUnterstützt mehrere „Tiers“

Festplatten, Tapes etc.Metadaten werden weiterhin durch Lustre verwaltetDaten werden transparent in andere Tiers verschoben

HochverfügbarkeitUnterstützung von Failover-MechanismenAktiv/Passiv- und Aktiv/Aktiv-Konfigurationen



Lustre


Server

Target

Server

Target

Abbildung: Aktiv/Aktiv-Failover-Konfiguration

Server können jeweils Rolle des anderen übernehmenKann für unterbrechungsfreie Upgrades genutzt werden



OrangeFS

Überblick

Open Source (LGPL)> 250.000 Zeilen Code

Entwicklung durch Clemson University, Argonne NationalLaboratory und OmnibondWeiterentwicklung von PVFS

2007: Start als Entwicklungszweig2010: Ersetzt PVFS als Hauptversion



OrangeFS

Funktionalität [2]

Verteilte Metadaten und VerzeichnisseVerteilte Verzeichnisse seit Version 2.9

Läu� komplett im User-SpaceSehr gute MPI-IO-Unterstützung

Natives Backend in ROMIOUnterstützung für POSIX-Schnittstelle

FUSE-DateisystemOptionales Kernelmodul



OrangeFS


OrangeFS ist nicht POSIX-konformGarantiert atomare Ausführung nicht-zusammenhängender undnicht-überlappender Zugri�eBezieht sich auf Lese- und SchreiboperationenUnterstützt somit (nicht-atomares) MPI-IO

Ausreichend für viele AnwendungsfälleStriktere Semantik allerdings nicht unterstütztMPI-IO-Atomic-Modus mangels Sperren nicht verfügbar



Leistungsanalyse

Lustre

0

200

400

600

800

1,000

1,2001/1 1/2 1/4 1/8 1/12 2/24 3/36 4/48 5/60 6/72 7/84 8/96 9/108 10/120

Lese

n

0

200

400

600

800

1,000

1/1 1/2 1/4 1/8 1/12 2/24 3/36 4/48 5/60 6/72 7/84 8/96 9/108 10/120

Durc

hsat

z [M

iB/s

]

Schr

eibe

n

Konfiguration (Knoten/Prozesse)

4 KiB 16 KiB 64 KiB 256 KiB 1,024 KiB

Abbildung: Lustre mit prozess-lokalen Dateien



Leistungsanalyse

Lustre. . .

0

200

400

600

800

1,000

1,2001/1 1/2 1/4 1/8 1/12 2/24 3/36 4/48 5/60 6/72 7/84 8/96 9/108 10/120

Lese

n

0

200

400

600

800

1,000

1/1 1/2 1/4 1/8 1/12 2/24 3/36 4/48 5/60 6/72 7/84 8/96 9/108 10/120

Durc

hsat

z [M

iB/s

]

Schr

eibe

n



Abbildung: Lustre mit gemeinsamer Datei



Leistungsanalyse

Lustre. . .

Lustre hochoptimiert für viele parallele ClientsKein Leistungseinbruch mit wachsender Clientzahl

Allerdings nur für prozess-lokale DateienGemeinsame Dateien skalieren nichtAuswirkung der POSIX-EinschränkungenHohe Leistung möglich aber kompliziert

Diverse OptimierungenAggregiert Schreibzugri�e im HauptspeicherFührt Readahead durch


• Für hohe Leistung mit gemeinsamen Dateien ist es notwendig dieZugri�e an den Streifengrenzen auszurichten

– Außerdem möglichst 1:1-Zugri�e, d.h. ein Client kommuniziertmit nur einem Server


Leistungsanalyse

OrangeFS

0

200

400

600

800

1,000

1,2001/1 1/2 1/4 1/8 1/12 2/24 3/36 4/48 5/60 6/72 7/84 8/96 9/108 10/120

Lese

n

0

200

400

600

800

1,000

1/1 1/2 1/4 1/8 1/12 2/24 3/36 4/48 5/60 6/72 7/84 8/96 9/108 10/120

Durc

hsat

z [M

iB/s

]

Schr

eibe

n



Abbildung: OrangeFS mit prozess-lokalen Dateien



Leistungsanalyse

OrangeFS. . .

0

200

400

600

800

1,000

1,2001/1 1/2 1/4 1/8 1/12 2/24 3/36 4/48 5/60 6/72 7/84 8/96 9/108 10/120

Lese

n

0

200

400

600

800

1,000

1/1 1/2 1/4 1/8 1/12 2/24 3/36 4/48 5/60 6/72 7/84 8/96 9/108 10/120

Durc

hsat

z [M

iB/s

]

Schr

eibe

n



Abbildung: OrangeFS mit gemeinsamer Datei



Leistungsanalyse

OrangeFS. . .

OrangeFS ist optimiert für nicht-konfligierende Zugri�eDadurch keine Sperren notwendigHohe Leistung auch bei gemeinsamen Dateien

Leistungsprobleme durch darunter liegendes DateisystemAußerdem geringe Metadatenleistung



Leistungsanalyse

Lustre

0

5,000

10,000

15,000

20,000

25,000

30,000

35,000

40,000

45,000

1/1 1/2 1/4 1/8 1/12 2/24 3/36 4/48 5/60 6/72 7/84 8/96 9/108 10/120

Durc

hsat

z [O

pera

tione

n/s]

Konfiguration (Knoten/Prozesse)Create Delete Open Stat

Abbildung: Lustre mit prozess-lokalen Verzeichnissen



Leistungsanalyse

Lustre. . .

0

5,000

10,000

15,000

20,000

25,000

30,000

35,000

40,000

45,000

1/2 1/4 1/8 1/12 2/24 3/36 4/48 5/60 6/72 7/84 8/96 9/108 10/120

Durc

hsat

z [O

pera

tione

n/s]

Konfiguration (Knoten/Prozesse)Create Delete Open Stat

Abbildung: Lustre mit gemeinsamem Verzeichnis



Leistungsanalyse

Lustre. . .

Deutliche unterschiede zwischen prozess-lokalen undgemeinsamen VerzeichnissenPassable Leistung für DateierzeugungLeistungsprobleme beim Ö�nen und Löschen

Interessanterweise ist Ö�nen langsamer als Erzeugen



Ausblick und Zusammenfassung

Ausblick

E/A-Bibliotheken bieten Komfortfunktionen auf Basis vonparallelen verteilen Dateisystemen

Z.B. selbst-beschreibende Daten mit NetCDF und HDFSemantiken haben großen Einfluss auf erreichbare Leistung

Forschungsthema: Dynamisch anpassbare Semantiken



Ausblick und Zusammenfassung

Zusammenfassung

Parallele verteilte Dateisysteme bieten gleichzeitigen Zugri� fürviele Clients

Skalierbarer gleichzeitiger Zugri� schwierigVerteilen außerdem Daten und Metadaten für erhöhtenDurchsatz und Kapazität

Üblicherweise Au�eilung in Daten- und MetadatenserverZugri� über E/A-Schnittstelle

Häufig POSIX oder MPI-IOWichtige Vertreter sind Lustre und GPFS

OrangeFS bietet alternativen Ansatz



Lustre-Tutorial

Abhängigkeiten

1 systemctl stop firewalld2 systemctl disable firewalld3 sed -i ’/^SELINUX=/s/.*/SELINUX=disabled/’

↪→ /etc/selinux/config4 setenforce 0

Listing 2: System vorbereiten

1 yum -y upgrade2 yum -y groupinstall ’Development Tools’3 yum -y install xmlto asciidoc elfutils-libelf-devel

↪→ zlib-devel binutils-devel newt-devel python-devel↪→ hmaccalc perl-ExtUtils-Embed bison elfutils-devel↪→ audit-libs-devel python-docutils sg3_utils expect↪→ attr lsof quilt libselinux-devel

Listing 3: Abhängigkeiten installieren



Lustre-Tutorial

ZFS

1 URL=’http://archive.zfsonlinux.org’23 yum -y install epel-release4 yum -y install --nogpgcheck

↪→ $URL/epel/zfs-release.el7.noarch.rpm5 yum -y install zfs zfs-dkms libzfs2-devel libuuid-devel67 systemctl start zfs.target

Listing 4: ZFS installieren



Lustre-Tutorial

Lustre

1 git clone --depth 1↪→ git://git.hpdd.intel.com/fs/lustre-release.git

2 cd lustre-release3 sh ./autogen.sh4 ./configure --disable-ldiskfs5 make rpms6 yum -y install *.$(arch).rpm

Listing 5: Lustre kompilieren und installieren



Lustre-Tutorial

Lustre-Konfiguration

1 mkfs.lustre --mgs --backfstype=zfs --fsname=lustre↪→ --device-size=1048576 lustre-mgs/mgs↪→ /tmp/lustre-mgs

2 mkfs.lustre --mdt --backfstype=zfs --fsname=lustre↪→ --index=0 --mgsnode=$(hostname)@tcp↪→ --device-size=1048576 lustre-mdt0/mdt0↪→ /tmp/lustre-mdt0

3 mkfs.lustre --ost --backfstype=zfs --fsname=lustre↪→ --index=0 --mgsnode=$(hostname)@tcp↪→ --device-size=1048576 lustre-ost0/ost0↪→ /tmp/lustre-ost0

Listing 6: Geräte formatieren


• Um normale Speichergeräte zu nutzen, müssen statt Dateien in /tmpeinfach Geräte in /dev angegeben werden

– Außerdem sollte dann der device-size-Parameterweggelassen werden

• Bei mehreren MDTs bzw. OSTs muss der Index jeweils erhöht werden


Lustre-Tutorial

Lustre-Konfiguration. . .

1 echo "$(hostname) - mgs zfs:lustre-mgs/mgs" >>↪→ /etc/ldev.conf

2 echo "$(hostname) - mdt0 zfs:lustre-mdt0/mdt0" >>↪→ /etc/ldev.conf

3 echo "$(hostname) - ost0 zfs:lustre-ost0/ost0" >>↪→ /etc/ldev.conf

45 systemctl daemon-reload6 systemctl start lustre

Listing 7: Dienste starten

1 mkdir -p /mnt/lustre/client2 mount -t lustre $(hostname):/lustre /mnt/lustre/client

Listing 8: Lustre mounten


• Der beim Mounten angegebene Pfad /lustre entspricht demDateisystemnamen (fsname)


1 Parallele verteilte DateisystemeOrientierungKonzepteLeistungsüberlegungenLustreOrangeFSLeistungsanalyseAusblick und ZusammenfassungLustre-Tutorial

2 Quellen



Quellen I

[1] OpenSFS and EOFS. Lustre. http://lustre.org/.

[2] OrangeFS Development Team. OrangeFS.http://www.orangefs.org/.

[3] Wikipedia. IOPS.http://en.wikipedia.org/wiki/IOPS.


http://lustre.org/

http://www.orangefs.org/

http://en.wikipedia.org/wiki/IOPS

Documents

Parallele verteilte Dateisysteme - Hochleistungs-Ein-/Ausgabe · ParalleleverteilteDateisysteme Quellen ParalleleverteilteDateisysteme Hochleistungs-Ein-/Ausgabe MichaelKuhn Wissenscha˝lichesRechnen