Luster (filsystem)

"Cluster File Systems" omdirigerar hit. För den allmänna termen, se Klustrat filsystem . För programmeringsspråket, se Luster (programmeringsspråk) .
Lyster
Initial release 16 december 2003 ; 19 år sedan ( 2003-12-16 )
Stabil frisättning
2.15.0 (senaste större utgåvan),

2.15.2 (senaste underhållsversionen),

/ 11 januari 2023 ; 51 dagar sedan ( 2023-01-11 )
Förvar
Skrivet i C
Operativ system Linux kärna
Typ Distribuerat filsystem
Licens GPL v2 LGPL
Hemsida www .lustre .org Edit this at Wikidata
Cluster File Systems, Inc.
Typ Privat
Grundad 2001
Grundare Peter J. Braam
Huvudkontor
Boulder, Colorado
Nyckelpersoner
 Andreas Dilger, Eric Barton (HPC), Phil Schwan
Produkter Luster filsystem
Lyster
Introducerad December 2003 med Linux
Strukturer
Kataloginnehåll Hash, Interleaved Hash med DNE i 2.7+
Filtyp fil, katalog, hårdlänk, symbollänk, blockspecial, teckenspecial, socket, FIFO
Startbar Nej
Gränser
Min. volymstorlek 32 MB
Max. volymstorlek 700 PB (produktion), över 16 EB (teoretiskt)
Max. filstorlek 32 PB (ext4), 16 EB (ZFS)
Filstorlek granularitet 4 KB
Max. antal filer Per Metadata Target (MDT): 4 miljarder filer (ldiskfs backend), 256 biljoner filer (ZFS backend), upp till 128 MDTs per filsystem
Max. filnamnets längd 255 byte
Max. dirname längd 255 byte
Max. katalogdjup 4096 byte
Tillåtna tecken i filnamn Alla byte utom NUL ('\0') och '/' och de speciella filnamnen "." och ".."
Funktioner
Datum inspelade modification (mtime), attribut modification (ctime), access (atime), delete (dtime), create (crtime)
Datumintervall 2^34 bitar (ext4), 2^64 bitar (ZFS)
Datumupplösning 1 s
Gafflar Nej
Attribut 32bitapi, acl, checksum, flock, lazystatfs, localflock, lruresize, noacl, nochecksum, noflock, nolazystatfs, nolruresize, nouser_fid2path, nouser_xattr, user_fid2path, user_xattr
Filsystemsbehörigheter POSIX , POSIX.1e ACL , SELinux
Transparent kompression Ja (endast ZFS)
Transparent kryptering Ja (nätverk, lagring med ZFS 0.8+, fscrypt med Luster 2.14.0+)
Datadeduplicering Ja (endast ZFS)
Kopiera-på-skriva Ja (endast ZFS)
Övrig
Operativsystem som stöds Linux kärna

Luster är en typ av parallellt distribuerat filsystem som vanligtvis används för storskalig klusterberäkning . Namnet Luster är ett portmanteau-ord som kommer från Linux och kluster . Luster filsystemprogramvara är tillgänglig under GNU General Public License (endast version 2) och tillhandahåller högpresterande filsystem för datorkluster som sträcker sig i storlek från små arbetsgruppskluster till storskaliga system med flera platser. Sedan juni 2005 har Luster konsekvent använts av minst hälften av de tio bästa, och mer än 60 av de 100 snabbaste superdatorerna i världen, inklusive världens nummer 1 rankade TOP500 superdator i november 2022, Frontier , samt tidigare toppsuperdatorer som Fugaku , Titan och Sequoia .

Luster-filsystem är skalbara och kan ingå i flera datorkluster med tiotusentals klientnoder , tiotals petabyte (PB) lagringsutrymme på hundratals servrar och mer än en terabyte per sekund (TB/s) av aggregerad I/ O genomströmning . Detta gör Luster-filsystem till ett populärt val för företag med stora datacenter, inklusive de inom industrier som meteorologi , simulering , olja och gas, life science , rich media och finans. I/O-prestandan hos Luster har stor inverkan på dessa applikationer och har väckt stor uppmärksamhet.

Historia

Luster-filsystemarkitekturen startades som ett forskningsprojekt 1999 av Peter J. Braam , som var en personal vid Carnegie Mellon University (CMU) vid den tiden. Braam fortsatte med att grunda sitt eget företag Cluster File Systems 2001, med början från arbetet med InterMezzo-filsystemet i Coda-projektet vid CMU. Luster utvecklades under Accelerated Strategic Computing Initiative Path Forward-projektet finansierat av USA:s energidepartement, som inkluderade Hewlett-Packard och Intel . I september 2007 Sun Microsystems tillgångarna i Cluster File Systems Inc. inklusive dess "immateriella rättigheter". Sun inkluderade Luster med sina högpresterande datorhårdvaruerbjudanden, med avsikten att föra Luster-teknologier till Suns ZFS -filsystem och Solaris -operativsystemet . I november 2008 lämnade Braam Sun Microsystems och Eric Barton och Andreas Dilger tog kontroll över projektet. 2010 Oracle Corporation , genom sitt förvärv av Sun, hantera och släppa Lustre.

I december 2010 tillkännagav Oracle att de skulle upphöra med Luster 2.x-utvecklingen och placera Luster 1.8 i underhållsstöd, vilket skapar osäkerhet kring den framtida utvecklingen av filsystemet. Efter detta tillkännagivande växte flera nya organisationer upp för att ge stöd och utveckling i en modell för öppen gemenskapsutveckling, inklusive Whamcloud, Open Scalable File Systems, Inc. (OpenSFS), EUROPEAN Open File Systems (EOFS) och andra. I slutet av 2010 hade de flesta Luster-utvecklare lämnat Oracle. Braam och flera medarbetare gick med i det hårdvaruorienterade Xyratex när det förvärvade tillgångarna i ClusterStor, medan Barton, Dilger och andra bildade mjukvarustartupen Whamcloud, där de fortsatte att arbeta på Lustre.

I augusti 2011 tilldelade OpenSFS ett kontrakt för utveckling av Luster-funktioner till Whamcloud. Det här kontraktet täckte färdigställandet av funktioner, inklusive förbättrad skalning av prestanda för Single Server Metadata Performance, vilket gör att Luster bättre kan dra nytta av en metadataserver med många kärnor; Online Luster distributed filesystem checking (LFSCK), som tillåter verifiering av det distribuerade filsystemets tillstånd mellan data- och metadataservrar medan filsystemet är monterat och används; och Distributed Namespace Environment (DNE), tidigare Clustered Metadata (CMD), som gör att Luster-metadata kan distribueras över flera servrar. Utvecklingen fortsatte också på ZFS-baserad back-end- objektlagring vid Lawrence Livermore National Laboratory . Dessa funktioner fanns i Luster 2.2 till 2.4 community release roadmap. I november 2011 tilldelades Whamcloud ett separat kontrakt för underhåll av Luster 2.x-källkoden för att säkerställa att Luster-koden skulle få tillräcklig testning och felkorrigering medan nya funktioner utvecklades.

I juli 2012 förvärvades Whamcloud av Intel , efter att Whamcloud vunnit FastForward DOE-kontraktet för att förlänga Luster för exascale datorsystem under 2012 års tidsram. OpenSFS överförde sedan kontrakt för Luster-utveckling till Intel.

I februari 2013 meddelade Xyratex Ltd. att de förvärvat det ursprungliga varumärket Luster, logotypen, webbplatsen och tillhörande immateriella rättigheter från Oracle. I juni 2013 började Intel utöka användningen av Luster utöver traditionell HPC, som inom Hadoop . För 2013 som helhet OpenSFS begäran om förslag (RFP) för att täcka Luster-funktionsutveckling, verktyg för parallella filsystem, hantering av Luster tekniska skulder och parallella filsysteminkubatorer. OpenSFS etablerade också Luster Community Portal, en teknisk webbplats som tillhandahåller en samling information och dokumentation i ett område för referens och vägledning för att stödja Luster open source-gemenskapen. Den 8 april 2014 meddelade Ken Claffey att Xyratex/Seagate donerade lustre.org tillbaka till användargemenskapen, och detta slutfördes i mars 2015.

I juni 2018 förvärvades Luster-teamet och tillgångarna från Intel av DDN . DDN organiserade det nya förvärvet som en oberoende division, vilket återupplivade Whamcloud-namnet för den nya divisionen.

I november 2019 meddelade OpenSFS och EOFS vid SC19 Luster BOF att varumärket Luster hade överförts till dem gemensamt från Seagate .

Releasehistorik

Luster filsystem installerades först för produktionsanvändning i mars 2003 på MCR Linux Cluster vid Lawrence Livermore National Laboratory, en av de största superdatorerna vid den tiden.

Luster 1.0.0 släpptes i december 2003 och gav grundläggande Luster-filsystemfunktioner, inklusive serverfel och återställning.

Luster 1.2.0, som släpptes i mars 2004, fungerade på Linux-kärnan 2.6 och hade en "storleksglimt"-funktion för att undvika återkallande av lås på filer som genomgår skrivning och cacheredovisning för återskrivning av data på klientsidan (bevilja).

Luster 1.4.0, släppt i november 2004, tillhandahöll protokollkompatibilitet mellan versioner, kunde använda InfiniBand- nätverk och kunde exploatera omfattningar/mballoc i ldiskfs diskfilsystem.

Luster 1.6.0, släppt i april 2007, tillät monteringskonfiguration (“mountconf”) så att servrar kunde konfigureras med "mkfs" och "mount", tillät dynamiskt tillägg av objektlagringsmål (OSTs), aktiverade Luster distributed lock manager ( LDLM ) ) skalbarhet på symmetriska multiprocessing- servrar (SMP) och tillhandahöll ledigt utrymmeshantering för objektallokering.

Luster 1.8.0, släppt i maj 2009, gav OSS Read Cache, förbättrad återställning inför flera fel, tillagd grundläggande heterogen lagringshantering via OST-pooler, adaptiva nätverkstidsgränser och versionsbaserad återställning. Det var en övergångsutgåva som var interoperabel med både Luster 1.6 och Luster 2.0.

Luster 2.0, som släpptes i augusti 2010, baserades på betydande internt omstrukturerad kod för att förbereda för stora arkitektoniska framsteg. Luster 2.x - klienter kan inte samverka med 1.8 eller tidigare servrar . Luster 1.8.6 och senare klienter kan dock samverka med Luster 2.0 och senare servrar. Metadata Target (MDT) och OST på diskformatet från 1.8 kan uppgraderas till 2.0 och senare utan att filsystemet behöver formateras om.

Luster 2.1, som släpptes i september 2011, var ett gemenskapsomfattande initiativ som svar på att Oracle stoppade utvecklingen av Luster 2.x-utgåvor. Det lade till möjligheten att köra servrar på Red Hat Linux 6 och ökade den maximala ext4-baserade OST-storleken från 24 TB till 128 TB, samt ett antal prestanda- och stabilitetsförbättringar. Luster 2.1-servrar förblev interoperabla med 1.8.6 och senare klienter.

Luster 2.2, släppt i mars 2012, fokuserade på att tillhandahålla prestandaförbättringar för metadata och nya funktioner. Den lade till parallella katalogoperationer som gjorde det möjligt för flera klienter att gå igenom och modifiera en enda stor katalog samtidigt, snabbare återhämtning från serverfel, ökat antal remsor för en enskild fil (över upp till 2000 OSTs) och förbättrad prestanda för genomgång av kataloger för en klient.

Luster 2.3, som släpptes i oktober 2012, fortsatte att förbättra metadataserverkoden för att ta bort interna låsningsflaskhalsar på noder med många CPU-kärnor (över 16). Objektarkivet lade till en preliminär möjlighet att använda ZFS som stödfilsystem. Funktionen Luster File System Check (LFSCK) kan verifiera och reparera MDS Object Index (OI) medan filsystemet används, efter en säkerhetskopiering/återställning på filnivå eller i händelse av MDS-korruption. IO-statistiken på serversidan förbättrades för att möjliggöra integration med batch-jobbschemaläggare som SLURM för att spåra statistik per jobb. Programvara på klientsidan uppdaterades för att fungera med Linux-kärnor upp till version 3.0.

Luster 2.4, som släpptes i maj 2013, lade till ett stort antal viktiga funktioner, många finansierade direkt genom OpenSFS . Distributed Namespace Environment (DNE) tillåter horisontell metadatakapacitet och prestandaskalning för 2.4-klienter, genom att tillåta underkatalogträd för ett enda namnområde att placeras på separata MDT:er. ZFS kan nu användas som stödfilsystem för både MDT- och OST-lagring. LFSCK-funktionen lade till möjligheten att skanna och verifiera den interna konsistensen av MDT FID- och LinkEA-attributen. Network Request Scheduler (NRS) lägger till policyer för att optimera bearbetning av klientförfrågningar för diskbeställning eller rättvisa. Klienter kan valfritt skicka bulk-RPC:er upp till 4 MB i storlek. Programvara på klientsidan uppdaterades för att fungera med Linux-kärnor upp till version 3.6 och är fortfarande interoperabel med 1.8-klienter.

Luster 2.5, som släpptes i oktober 2013, lade till den mycket efterlängtade funktionen, Hierarchical Storage Management (HSM). Ett centralt krav i företagsmiljöer, HSM tillåter kunder att enkelt implementera nivåbaserade lagringslösningar i sin operativa miljö. Den här utgåvan är den nuvarande OpenSFS-designade underhållsutgåvan av Lustre. Den senaste underhållsversionen är 2.5.3 och släpptes i september 2014.

Luster 2.6, som släpptes i juli 2014, var en mer blygsam releasefunktion, och lade till LFSCK-funktionalitet för att göra lokala konsistenskontroller på OST såväl som konsistenskontroller mellan MDT- och OST-objekt. Policyn för NRS Token Bucket Filter (TBF) har lagts till. Enklients IO-prestanda förbättrades jämfört med tidigare utgåvor. Den här utgåvan lade också till en förhandsvisning av DNE-randiga kataloger, vilket gör att enstaka stora kataloger kan lagras på flera MDT:er för att förbättra prestanda och skalbarhet.

Luster 2.7, som släpptes i mars 2015, lade till LFSCK-funktionalitet för att verifiera DNE-konsistensen för fjärr- och randkataloger mellan flera MDT:er. Dynamic LNet Config lägger till möjligheten att konfigurera och ändra LNet-nätverksgränssnitt, rutter och routrar vid körning. En ny utvärderingsfunktion har lagts till för UID/GID-mappning för klienter med olika administrativa domäner, tillsammans med förbättringar av DNE-randiga katalogfunktioner.

Luster 2.8, som släpptes i mars 2016, avslutade funktionen DNE striped katalog, inklusive stöd för migrering av kataloger mellan MDT, och cross-MDT hård länk och byt namn. Dessutom inkluderade det förbättrat stöd för Security-Enhanced Linux ( SELinux ) på klienten, Kerberos -autentisering och RPC-kryptering över nätverket och prestandaförbättringar för LFSCK.

Luster 2.9 släpptes i december 2016 och innehöll ett antal funktioner relaterade till säkerhet och prestanda. Säkerhetssmaken Shared Secret Key använder samma GSSAPI- mekanism som Kerberos för att tillhandahålla klient- och servernodautentisering och RPC-meddelandeintegritet och säkerhet (kryptering). Nodemap-funktionen gör det möjligt att kategorisera klientnoder i grupper och sedan mappa UID/GID för dessa klienter, vilket tillåter fjärradministrerade klienter att transparent använda ett delat filsystem utan att ha en enda uppsättning UID/GID för alla klientnoder. Funktionen för montering av underkatalog tillåter klienter att montera en delmängd av filsystemets namnutrymme från MDS. Den här utgåvan lade också till stöd för upp till 16MiB RPC för effektivare I/O-överföring till disk, och lade till ladvise-gränssnittet för att låta klienter ge I/O-tips till servrarna för att förhämta fildata till serverns cache eller tömma fildata från servern cache. Det fanns förbättrat stöd för att specificera filsystemomfattande standard-OST-pooler, och förbättrat nedärvning av OST-pooler i kombination med andra fillayoutparametrar.

Luster 2.10 släpptes i juli 2017 och har ett antal betydande förbättringar. LNet Multi-Rail (LMR)-funktionen tillåter sammanfogning av flera nätverksgränssnitt ( InfiniBand , Omni-Path och/eller Ethernet ) på en klient och server för att öka den samlade I/O-bandbredden. Enskilda filer kan använda sammansatta fillayouter som är uppbyggda av flera komponenter, som är filregioner baserade på filförskjutningen, som tillåter olika layoutparametrar som ränder, OST-pool/lagringstyp, etc. Progressive File Layout (PFL ) är första funktionen att använda sammansatta layouter, men implementeringen är flexibel för användning med andra fillayouter som spegling och raderingskodning. NRS Token Bucket Filter (TBF) schemaläggare på serversidan har implementerat nya regeltyper, inklusive schemaläggning av RPC-typ och möjligheten att specificera flera parametrar som JobID och NID för regelmatchning. Verktyg för att hantera ZFS-ögonblicksbilder av Luster-filsystem har lagts till för att förenkla skapandet, monteringen och hanteringen av MDT- och OST ZFS-ögonblicksbilder som separata Luster-monteringspunkter.

Luster 2.11 släpptes i april 2018 och innehåller två betydande nya funktioner och flera mindre funktioner. Funktionen File Level Redundancy (FLR) utökar implementeringen av 2.10 PFL och lägger till möjligheten att specificera speglade fillayouter för förbättrad tillgänglighet i händelse av lagrings- eller serverfel och/eller förbättrad prestanda med mycket samtidiga läsningar. Data -on-MDT (DoM)-funktionen tillåter att små (få MiB) filer lagras på MDT för att utnyttja typisk flashbaserad RAID-10-lagring för lägre latens och minskad IO-konflikt, istället för den typiska HDD RAID-6-lagringen används på OST. LNet Dynamic Discovery-funktionen tillåter också automatisk konfiguration av LNet Multi-Rail mellan peers som delar ett LNet-nätverk. LDLM Lock Ahead-funktionen tillåter lämpligt modifierade applikationer och bibliotek att i förväg hämta DLM-omfattningslås från OST:erna för filer, om applikationen vet (eller förutsäger) att denna filomfattning kommer att ändras inom en snar framtid, vilket kan minska låskonflikter för flera klienter skriver till samma fil.

Luster 2.12 släpptes den 21 december 2018 och fokuserade på att förbättra Luster-användbarheten och stabiliteten, med förbättringar av prestanda och funktionalitet för FLR- och DoM-funktionerna som lagts till i Luster 2.11, såväl som mindre ändringar av NRS TBF , HSM , och JobStats . Den lade till LNet Network Health för att tillåta LNet Multi-Rail-funktionen från Luster 2.10 att bättre hantera nätverksfel när en nod har flera nätverksgränssnitt. Funktionen Lazy Size on MDT (LSOM) gör det möjligt att lagra en uppskattning av filstorleken på MDT för användning av policymotorer, filsystemskannrar och andra hanteringsverktyg som mer effektivt kan fatta beslut om filer utan en helt korrekt filstorlek eller blockräkning utan att behöva fråga OST för denna information. Den här utgåvan lade också till möjligheten att manuellt omforma en befintlig katalog över flera MDT:er, för att tillåta migrering av kataloger med ett stort antal filer för att använda kapaciteten och prestandan hos flera MDS-noder. Luster RPC-datakontrollsumman lade till SCSI T10-PI- datakontrollsummor från klienten till kärnblocklagret, SCSI- värdadaptern och T10-aktiverade hårddiskar .

Luster 2.13 släpptes den 5 december 2019 och lade till en ny prestandarelaterade funktioner Persistent Client Cache (PCC), som tillåter direkt användning av NVMe- och NVRAM- lagring på klientnoderna samtidigt som filerna behålls som en del av det globala filsystemets namnutrymme, och OST Overstriping som tillåter filer att lagra flera ränder på en enda OST för att bättre utnyttja snabb OSS-hårdvara. LNet Multi-Rail Network Health-funktionaliteten förbättrades också för att fungera med LNet RDMA-routernoder. PFL-funktionaliteten förbättrades med Self-Extending Layouts (SEL) för att tillåta filkomponenter att dimensioneras dynamiskt, för att bättre hantera flash-OST:er som kan vara mycket mindre än disk-OST:er inom samma filsystem. Utgåvan inkluderade också ett antal mindre förbättringar, som att balansera DNE-fjärrkatalogskapande över MDT:er, använda Lazy-size-on-MDT för att minska omkostnaderna för "lfs find", kataloger med 10 miljoner filer per skärva för ldiskfs och bulk-RPC storlekar upp till 64MB.

Luster 2.14 släpptes den 19 februari 2021 och innehåller tre huvudfunktioner. Client Data Encryption implementerar fscrypt för att tillåta att fildata krypteras på klienten före nätverksöverföring och beständig lagring på OST och MDT. OST Pool Quotas utökar kvotramverket för att möjliggöra tilldelning och upprätthållande av kvoter på basis av OST-lagringspooler. DNE Auto Retriping kan nu justera hur många MDT:er en stor katalog är randad över baserat på storlekströsklar definierade av administratören, liknande progressiva fillayouter för kataloger.

Luster 2.15 släpptes den 16 juni 2022 och innehåller tre huvudfunktioner. Klientkatalogkryptering utökar fscrypt-datakrypteringen i version 2.14 för att även tillåta att fil- och katalognamn krypteras på klienten före nätverksöverföring och beständig lagring på MDT. DNE MDT-utrymmesbalansering balanserar automatiskt skapande av ny katalog över MDT:er i filsystemet i round-robin och/eller baserat på tillgängliga inoder och utrymme, vilket i sin tur hjälper till att fördela klientens metadataarbetsbelastning över MDT:er jämnare. För applikationer som använder NVIDIA GPU Direct Storage Interface (GDS) kan Luster-klienten göra noll-copy RDMA- läsning och -skrivning från lagringsservern direkt in i GPU -minnet för att undvika en extra datakopia från CPU -minnet och extra bearbetningskostnader. User Defined Selection Policy (UDSP) gör det möjligt att ställa in policyer för val av gränssnitt för noder med flera nätverksgränssnitt.

Arkitektur

Ett Luster-filsystem har tre huvudsakliga funktionella enheter:

  • En eller flera metadataservrar (MDS) -noder som har en eller flera metadatamålenheter (MDT) per Luster-filsystem som lagrar namnutrymmesmetadata, såsom filnamn, kataloger, åtkomstbehörigheter och fillayout. MDT-data lagras i ett lokalt diskfilsystem. Men till skillnad från blockbaserade distribuerade filsystem, som GPFS och PanFS , där metadataservern kontrollerar all blockallokering, är Luster-metadataservern endast involverad i sökvägs- och behörighetskontroller och är inte involverad i några I/O-operationer för filer , undvika I/O-skalbarhetsflaskhalsar på metadataservern. Möjligheten att ha flera MDT:er i ett enda filsystem är en ny funktion i Luster 2.4, och tillåter katalogunderträd att finnas på de sekundära MDT:erna, medan 2.7 och senare tillåter stora enstaka kataloger att distribueras över flera MDT:er också.
  • En eller flera objektlagringsservernoder (OSS) som lagrar fildata på en eller flera objektlagringsmålenheter (OST) . Beroende på serverns hårdvara betjänar en OSS vanligtvis mellan två och åtta OSTs, där varje OST hanterar ett enda lokalt diskfilsystem. Kapaciteten hos ett Luster-filsystem är summan av kapaciteten som tillhandahålls av OST:erna.
  • Kund(er) som får åtkomst till och använder data. Luster presenterar alla klienter med ett enhetligt namnområde för alla filer och data i filsystemet, med hjälp av standard POSIX- semantik, och tillåter samtidig och sammanhängande läs- och skrivåtkomst till filerna i filsystemet.

MDT, OST och klient kan vara på samma nod (vanligtvis för teständamål), men i typiska produktionsinstallationer är dessa enheter på separata noder som kommunicerar över ett nätverk. Varje MDT och OST kan vara en del av endast ett enda filsystem, även om det är möjligt att ha flera MDT eller OST på en enda nod som är en del av olika filsystem. LNet- (Luster Network) kan använda flera typer av nätverksanslutningar, inklusive infödda InfiniBand- verb, Omni-Path , RoCE och iWARP via OFED , TCP/IP på Ethernet och andra proprietära nätverksteknologier som Cray Gemini-interconnect. I Luster 2.3 och tidigare stöddes även Myrinet , Quadrics , Cray SeaStar och RapidArray-nätverk, men dessa nätverksdrivrutiner fasades ut när dessa nätverk inte längre var kommersiellt tillgängliga och stödet togs bort helt i Luster 2.8. Luster kommer att dra fördel av överföringar av fjärrstyrd direkt minnesåtkomst ( RDMA ), när de är tillgängliga, för att förbättra genomströmningen och minska CPU-användningen.

Lagringen som används för MDT- och OST-stödfilsystemen tillhandahålls normalt av hårdvaru- RAID- enheter, men kommer att fungera med alla blockenheter. Sedan Luster 2.4 kan MDT och OST även använda ZFS för stödfilsystemet förutom ext4 , vilket gör att de effektivt kan använda JBOD- lagring istället för hårdvaru-RAID-enheter. Luster OSS- och MDS-servrarna läser, skriver och modifierar data i det format som påtvingas av stödfilsystemet och returnerar dessa data till klienterna. Detta gör att Luster kan dra fördel av förbättringar och funktioner i det underliggande filsystemet, såsom komprimering och datakontrollsummor i ZFS. Klienter har ingen direkt tillgång till den underliggande lagringen, vilket säkerställer att en felaktig eller skadlig klient inte kan korrumpera filsystemets struktur.

En OST är ett dedikerat filsystem som exporterar ett gränssnitt till byteintervall av filobjekt för läs-/skrivoperationer, med utsträckningslås för att skydda datakonsistens. En MDT är ett dedikerat filsystem som lagrar inoder, kataloger, POSIX och utökade filattribut , kontrollerar filåtkomstbehörigheter/ ACL:er och berättar för klienter layouten för objekten/objekten som utgör varje vanlig fil. MDT och OST använder för närvarande antingen en förbättrad version av ext4 som kallas ldiskfs eller ZFS /DMU för back-end datalagring för att lagra filer/objekt med öppen källkod ZFS-on-Linux-porten.

Klienten monterar Luster-filsystemet lokalt med en VFS- drivrutin för Linux- kärnan som ansluter klienten till servern/servrarna. Vid initial montering tillhandahålls klienten en filidentifierare (FID) för rotkatalogen för monteringspunkten. När klienten kommer åt en fil utför den en filnamnssökning på MDS . När MDS-filnamnssökningen är klar och användaren och klienten har tillstånd att komma åt och/eller skapa filen, returneras antingen layouten för en befintlig fil till klienten eller så skapas en ny fil på uppdrag av klienten, om så begärs. För läs- eller skrivoperationer tolkar klienten sedan fillayouten i det logiska objektvolymlagret (LOV), som mappar filens logiska förskjutning och storlek till ett eller flera objekt . Klienten låser sedan filområdet som opereras på och utför en eller flera parallella läs- eller skrivoperationer direkt till OSS-noderna som innehåller dataobjekten. Med detta tillvägagångssätt elimineras flaskhalsar för klient-till-OSS-kommunikation, så den totala bandbredden som är tillgänglig för klienterna att läsa och skriva data skalas nästan linjärt med antalet OSTs i filsystemet.

Efter den första uppslagningen av fillayouten är MDS normalt inte involverad i fil-IO-operationer eftersom all blockallokering och data-IO hanteras internt av OST. Klienter modifierar inte direkt objekten eller data på OST-filsystemen, utan delegerar istället denna uppgift till OSS-noder. Detta tillvägagångssätt säkerställer skalbarhet för storskaliga kluster och superdatorer, samt förbättrad säkerhet och tillförlitlighet. Däremot tillåter delade blockbaserade filsystem som GPFS och OCFS direkt åtkomst till den underliggande lagringen av alla klienter i filsystemet, vilket kräver ett stort back-end SAN kopplat till alla klienter, och ökar risken för korruption av filsystemet från missköter sig/defekta kunder.

Genomförande

I en typisk Luster-installation på en Linux-klient laddas en Luster filsystemdrivrutinmodul in i kärnan och filsystemet monteras som vilket annat lokalt eller nätverksfilsystem som helst. Klientapplikationer ser ett enda enhetligt filsystem även om det kan vara sammansatt av tiotusentals individuella servrar och MDT/OST-filsystem.

På vissa massivt parallella processorinstallationer (MPP) kan beräkningsprocessorer komma åt ett Luster-filsystem genom att omdirigera sina I/O-förfrågningar till en dedikerad I/O-nod konfigurerad som en Luster-klient. Detta tillvägagångssätt används i Blue Gene -installationen vid Lawrence Livermore National Laboratory .

Ett annat tillvägagångssätt som användes under de tidiga åren av Luster är liblustre -biblioteket på Cray XT3 som använder operativsystemet Catamount på system som Sandia Red Storm , som gav användarutrymmesapplikationer direkt åtkomst till filsystemet. Liblustre var ett bibliotek på användarnivå som tillåter beräkningsprocessorer att montera och använda Luster-filsystemet som en klient. Med hjälp av liblustre kunde beräkningsprocessorerna komma åt ett Luster-filsystem även om tjänstenoden där jobbet lanserades inte är en Linux-klient. Liblustre tillät dataförflyttning direkt mellan applikationsutrymmet och Luster OSS:erna utan att kräva en mellanliggande datakopia genom kärnan, vilket gav åtkomst från beräkningsprocessorer till Luster-filsystemet direkt i en begränsad operativ miljö. Liblustre-funktionaliteten togs bort från Luster 2.7.0 efter att ha varit inaktiverad sedan Luster 2.6.0, och var opröstad sedan Luster 2.3.0.

I Linux Kernel version 4.18 togs den ofullständiga porten av Luster-klienten bort från kärnans staging-område för att påskynda utvecklingen och porteringen till nyare kärnor. Luster-klienten och servern utanför trädet är fortfarande tillgänglig för RHEL-, SLES- och Ubuntu-distrokärnor, såväl som vaniljkärnor.

Dataobjekt och filstrimning

I ett traditionellt Unix-diskfilsystem innehåller en inoddatastruktur grundläggande information om varje fil, till exempel var data som finns i filen lagras. Luster-filsystemet använder också inoder, men inoder på MDT:er pekar på ett eller flera OST-objekt som är associerade med filen snarare än till datablock. Dessa objekt implementeras som filer på OST:erna. När en klient öppnar en fil överför filöppningsoperationen en uppsättning objektidentifierare och deras layout från MDS till klienten, så att klienten direkt kan interagera med OSS-noden där objektet är lagrat. Detta tillåter klienten att utföra I/O parallellt över alla OST-objekt i filen utan ytterligare kommunikation med MDS.

Om endast ett OST-objekt är associerat med en MDT-inod, innehåller det objektet all data i Luster-filen. När mer än ett objekt är associerat med en fil, "strippas" data i filen i bitar på ett round-robin -sätt över OST-objekt som liknar RAID 0 i bitar som vanligtvis är 1 MB eller större. Att strippa en fil över flera OST-objekt ger betydande prestandafördelar om det finns ett behov av hög bandbreddsåtkomst till en enda stor fil. När striping används begränsas den maximala filstorleken inte av storleken på ett enda mål. Kapacitet och sammanlagd I/O-bandbredd skala med antalet OST:er som en fil är randad över. Dessutom, eftersom låsningen av varje objekt hanteras oberoende för varje OST, skalas filens I/O-låsningskapacitet proportionellt genom att lägga till fler ränder (en per OST). Varje fil som skapas i filsystemet kan specificera olika layoutparametrar, såsom antalet ränder (antal OST-objekt som utgör filen), ränder (enhet av data som lagras på varje OST innan du flyttar till nästa) och OST-val, så att prestanda och kapacitet kan ställas in optimalt för varje fil. När många applikationstrådar läser eller skriver till separata filer parallellt, är det optimalt att ha en enda remsa per fil, eftersom applikationen ger sin egen parallellitet. När det finns många trådar som läser eller skriver en enda stor fil samtidigt, är det optimalt att ha en streck på varje OST för att maximera prestanda och kapacitet för den filen.

I Luster 2.10-versionen lades möjligheten att specificera sammansatta layouter till för att låta filer ha olika layoutparametrar för olika delar av filen. Funktionen Progressive File Layout (PFL) använder sammansatta layouter för att förbättra fil-IO-prestanda över ett bredare spektrum av arbetsbelastningar, samt förenkla användning och administration. Till exempel kan en liten PFL-fil ha en enda remsa på flash för låg åtkomstoverhead, medan större filer kan ha många ränder för hög sammanlagd bandbredd och bättre OST-belastningsbalansering. De sammansatta layouterna förbättras ytterligare i version 2.11 med File Level Redundancy (FLR), som gör att en fil kan ha flera överlappande layouter för en fil, vilket ger RAID 0+1- redundans för dessa filer samt förbättrad läsprestanda. Luster 2.11-versionen lade också till Data-on-Metadata (DoM), som gör att den första komponenten i en PFL-fil kan lagras direkt på MDT med inoden. Detta minskar omkostnader för åtkomst av små filer, både när det gäller utrymmesanvändning (inget OST-objekt behövs) såväl som nätverksanvändning (färre RPC:er behövs för att komma åt data). DoM förbättrar också prestanda för små filer om MDT är SSD -baserad, medan OST:erna är diskbaserade. I Luster 2.13 OST Overstriping -funktionen att en enstaka komponent har flera ränder på en OST, medan den Self-Extending Layout -funktionen tillåter att komponentstorleken är dynamisk under skrivning så att den kan hantera (flash) OSTs som tar slut på utrymme innan hela filsystemet är slut.

Metadataobjekt och DNE-fjärr- eller randiga kataloger

När en klient initialt monterar ett filsystem, tillhandahålls den 128-bitars Luster File Identifier (FID, sammansatt av 64-bitars sekvensnummer, 32-bitars objekt-ID och 32-bitars version) för rotkatalogen för monteringspunkten. När du gör en filnamnssökning utför klienten en sökning av varje sökvägskomponent genom att mappa den överordnade katalogens FID-sekvensnummer till en specifik MDT via FID Location Database (FLDB), och gör sedan en sökning på MDS som hanterar denna MDT med hjälp av den överordnade FID och filnamn. MDS returnerar FID för den begärda sökvägskomponenten tillsammans med ett DLM -lås. När väl MDT för den sista överordnade katalogen har bestämts, sker ytterligare katalogoperationer (för icke-randiga kataloger) uteslutande på den MDT, vilket undviker konflikter mellan MDT. För DNE-randiga kataloger tillhandahåller layouten per katalog som lagras i den överordnade katalogen en hashfunktion och en lista över MDT-katalog-FID:er över vilka katalogen är distribuerad. Den logiska metadatavolymen (LMV) på klienten hashar filnamnet och mappar det till en specifik MDT-katalogskärva, som kommer att hantera ytterligare operationer på den filen på ett identiskt sätt som en icke-randig katalog. För readdir() -operationer returneras posterna från varje katalogshard till klienten sorterade i den lokala MDT-katalogens hashordning, och klienten utför en sammanfogningssortering för att interfoliera filnamnen i hashordning så att en enda 64-bitars cookie kan används för att bestämma den aktuella offseten i katalogen.

Låsning

Luster distributed lock manager (LDLM), implementerad i OpenVMS- stilen, skyddar integriteten för varje fils data och metadata. Åtkomst och modifiering av en Luster-fil är helt cachekoherent bland alla klienter. Metadatalås hanteras av MDT som lagrar inoden för filen, med FID som resursnamn. Metadatalåsen är uppdelade i separata bitar som skyddar uppslagningen av filen (filägare och grupp, behörighet och läge, och åtkomstkontrolllista (ACL)), inodens tillstånd (katalogstorlek, kataloginnehåll, länkantal, tidsstämplar ), layout (filstrimning, sedan Luster 2.4) och utökade attribut (xattrs, sedan Luster 2.5). En klient kan hämta flera metadatalåsbitar för en enda inod med en enda RPC-begäran, men för närvarande beviljas de bara ett läslås för inoden. MDS hanterar alla modifieringar av inoden för att undvika konflikt med låsresurser och är för närvarande den enda noden som får skrivlås på inoder.

Fildatalås hanteras av OST där varje objekt i filen är randigt, med hjälp av byte- intervallslås . Klienter kan beviljas överlappande läslängdslås för delar av eller hela filen, vilket tillåter flera samtidiga läsare av samma fil, och/eller icke-överlappande skrivomfattningslås för oberoende regioner av filen. Detta gör att många Luster-klienter kan komma åt en enda fil samtidigt för både läsning och skrivning, vilket undviker flaskhalsar under fil-I/O. I praktiken, eftersom Linux-klienter hanterar sin datacache i enheter av sidor , kommer klienterna att begära lås som alltid är en heltalsmultipel av sidstorleken (4096 byte på de flesta klienter). När en klient begär en omfattningslåsning kan OST bevilja ett lås i större utsträckning än vad som ursprungligen begärdes, för att minska antalet låsförfrågningar som klienten gör. Den faktiska storleken på det beviljade låset beror på flera faktorer, inklusive antalet för närvarande beviljade lås på det objektet, om det finns motstridiga skrivlås för den begärda låsomfattningen och antalet väntande låsbegäranden på det objektet. Det beviljade låset är aldrig mindre än den ursprungligen begärda omfattningen. OST-omfattningslås använder Luster FID för objektet som resursnamn för låset. Eftersom antalet omfattningslåsservrar skalas med antalet OSTs i filsystemet, skalar detta också den samlade låsningsprestandan för filsystemet, och för en enda fil om den är randad över flera OST:er.

Nätverk

Kommunikationen mellan Luster-klienterna och servrarna implementeras med hjälp av Luster Networking (LENet), som ursprungligen baserades på Sandia Portals nätverksprogrammeringsapplikations gränssnitt . Disklagring är ansluten till Luster MDS- och OSS-servernoderna med hjälp av direktansluten lagring ( SAS , FC , iSCSI ) eller traditionella SAN- tekniker , som är oberoende av klient-till-server-nätverket.

LNet kan använda många vanliga nätverkstyper, såsom InfiniBand- och TCP-nätverk (vanligtvis Ethernet ), och tillåter samtidig tillgänglighet över flera nätverkstyper med routing mellan dem. Remote Direct Memory Access (RDMA) används för data- och metadataöverföring mellan noder när de tillhandahålls av de underliggande nätverken, såsom InfiniBand, RoCE , iWARP och Omni-Path , såväl som proprietära höghastighetsnätverk som Cray Aries och Gemini och Atos BXI. Hög tillgänglighet och återställningsfunktioner möjliggör transparent återställning i kombination med failover-servrar.

tillåter LNet Multi-Rail (MR)-funktionen länkaggregation av två eller flera nätverksgränssnitt mellan en klient och server för att förbättra bandbredden. LNet-gränssnittstyperna behöver inte vara samma nätverkstyp. I 2.12 förbättrades Multi-Rail för att förbättra feltoleransen om flera nätverksgränssnitt är tillgängliga mellan peers.

LNet tillhandahåller end-to-end-genomströmning över Gigabit Ethernet -nätverk som överstiger 100 MB/s, genomströmning upp till 11 GB/s med hjälp av InfiniBand Enhanced Data Rate-länkar (EDR) och genomströmning över 11 GB/s över 100 Gigabit Ethernet- gränssnitt.

Hög tillgänglighet

Luster-filsystemets högtillgänglighetsfunktioner inkluderar en robust failover- och återställningsmekanism, vilket gör serverfel och omstarter transparenta. Versionskompatibilitet mellan på varandra följande mindre versioner av Luster-programvaran gör det möjligt att uppgradera en server genom att ta den offline (eller misslyckas med den till en standby-server), utföra uppgraderingen och starta om den, medan alla aktiva jobb fortsätter att köras, med en fördröjning medan backupservern tar över lagringen.

Luster MDS:er konfigureras som ett aktivt/passivt par som exporterar en enstaka MDT, eller ett eller flera aktiva/aktiva MDS-par med DNE som exporterar två eller flera separata MDT:er, medan OSSe vanligtvis distribueras i en aktiv/aktiv konfiguration som exporterar separata OST:er för att tillhandahålla redundans utan extra systemoverhead. I enkel-MDT-filsystem är standby-MDS för ett filsystem MGS- och/eller övervakningsnoden, eller den aktiva MDS-en för ett annat filsystem, så inga noder är lediga i klustret.

HSM (Hierarchical Storage Management)

Luster ger möjligheten att ha flera lagringsnivåer inom ett enda filsystems namnutrymme. Den tillåter traditionell HSM-funktionalitet för att kopiera (arkivera) filer från det primära filsystemet till en sekundär arkivlagringsnivå. Arkivnivån är vanligtvis ett bandbaserat system, som ofta frontas av en diskcache. När en fil väl har arkiverats kan den släppas från huvudfilsystemet, vilket bara lämnar en stubb som refererar till arkivkopian. Om en frigiven fil öppnas, blockerar samordnaren öppningen, skickar en återställningsbegäran till ett kopieringsverktyg och slutför sedan öppningen när kopieringsverktyget har slutfört återställningen av filen.

Förutom extern lagringsnivå, är det möjligt att ha flera lagringsnivåer inom ett enda filsystems namnområde. OST av olika typer (t.ex. hårddisk och SSD) kan deklareras i namngivna lagringspooler. OST-poolerna kan väljas när du anger fillayouter, och olika pooler kan användas inom en enda PFL-fillayout. Filer kan migreras mellan lagringsnivåer antingen manuellt eller under kontroll av policymotorn. Sedan Luster 2.11 är det även möjligt att spegla en fil till olika OST-pooler med en FLR-fillayout, till exempel för att förstega filer till flash för ett datorjobb.

HSM inkluderar några ytterligare Luster-komponenter för att hantera gränssnittet mellan det primära filsystemet och arkivet:

  • Koordinator: tar emot arkiv- och återställningsförfrågningar och skickar dem till agentnoder.
  • Agent: kör ett kopieringsverktyg för att kopiera data från primär lagring till arkivet och vice versa.
  • Copytool: hanterar datarörelse och metadatauppdateringar. Det finns olika kopieringsverktyg för att samverka med olika arkivsystem. Ett generiskt POSIX-kopieringsverktyg är tillgängligt för arkiv som tillhandahåller ett POSIX-liknande front-end-gränssnitt. Copytools är också tillgängliga för High Performance Storage System (HPSS), Tivoli Storage Manager (TSM), Amazon S3 och Google Drive .
  • Policy Engine: bevakar filsystems ändringsloggar för nya filer att arkivera, tillämpar policyer för att släppa filer baserat på ålder eller utrymmesanvändning och kommunicerar med MDT och koordinator. Policymotorn kan också utlösa åtgärder som migrering mellan, rensning och borttagning. Den vanligaste policymotorn är RobinHood , men andra policymotorer kan också användas.

HSM definierar också nya tillstånd för filer inklusive:

  • Finns: Någon kopia, möjligen ofullständig, finns i en HSM.
  • Arkiv: En fullständig kopia finns på arkivsidan av HSM.
  • Dirty: Den primära kopian av filen har ändrats och skiljer sig från den arkiverade kopian.
  • Släppt: En stubbinod finns på en MDT, men dataobjekten har tagits bort och den enda kopian finns i arkivet.
  • Förlorad: arkivkopian av filen har gått förlorad och kan inte återställas
  • Ingen release: filen ska inte släppas från filsystemet
  • Inget arkiv: filen ska inte arkiveras

Utplaceringar

Luster används av många av TOP500 superdatorer och stora multi-kluster webbplatser. Sex av topp 10 och mer än 60 av topp 100 superdatorer använder Luster filsystem. Dessa inkluderar 700TB 5GB/s Orion-filsystemet för Frontier-superdatorn vid Oak Ridge National Laboratory (ORNL), Fugaku och K Computer vid RIKEN Advanced Institute for Computational Science, Tianhe-1A vid National Supercomputing Center i Tianjin, Kina , LUMI kl. CSC , Jaguar och Titan vid ORNL, Blue Waters vid University of Illinois , och Sequoia och Blue Gene /L vid Lawrence Livermore National Laboratory (LLNL).

Det finns också stora Luster-filsystem vid National Energy Research Scientific Computing Center , Pacific Northwest National Laboratory , Texas Advanced Computing Center , Brazilian National Laboratory of Scientific Computing och NASA i Nordamerika, i Asien vid Tokyo Institute of Technology , i Europa vid CEA , och många andra.

Kommersiell teknisk support

Kommersiell teknisk support för Luster levereras ofta tillsammans med datorsystemet eller lagringshårdvaran som säljs av leverantören. Vissa leverantörer inkluderar Hewlett-Packard (som HP StorageWorks Scalable File Share, cirka 2004 till 2008), ATOS , Fujitsu . Leverantörer som säljer lagringshårdvara med medföljande Luster-stöd inkluderar Hitachi Data Systems (2012), DataDirect Networks (DDN), Aeon Computing och andra. Det är också möjligt att få stöd för enbart programvara för Luster-filsystem från vissa leverantörer, inklusive Whamcloud.

Amazon Web Services erbjuder Amazon FSx for Lustre, en helt hanterad tjänst, vilket gör det enkelt att starta och köra högpresterande filsystem kostnadseffektivt i deras moln.

Se även

externa länkar

Dokumentation

Informationswikis

gemenskapsstiftelser

Hård-/mjukvaruleverantörer

  1. ^ Black, Doug (28 juli 2017). "Cray flyttar för att förvärva Seagate ClusterStor Line" . HPCWire . HPCWire . Hämtad 2017-12-01 .
Hämtad från " https://en.wikipedia.org/w/index.php?title=Lustre_(file_system)&oldid=1139390787 "