Lustre เป็น ระบบไฟล์แบบกระจายขนานชนิดหนึ่ง ซึ่งโดยทั่วไปใช้สำหรับการ ^{ประมวล}ผลคลัสเตอร์ขนาดใหญ่ชื่อ Lustre เป็นคำผสมที่มาจากLinuxและcluster ^{[ 4} ] ซอฟต์แวร์ระบบไฟล์ Lustre มีให้ใช้งานภายใต้GNU General Public License (เฉพาะเวอร์ชัน 2 เท่านั้น) และให้บริการระบบไฟล์ประสิทธิภาพสูงสำหรับคลัสเตอร์คอมพิวเตอร์ที่มีขนาดตั้งแต่ คลัสเตอร์ เวิร์กกรุ๊ป ขนาดเล็กไปจนถึงระบบขนาดใหญ่หลายไซต์ ตั้งแต่เดือนมิถุนายน พ.ศ. 2548 Lustre ได้ถูกใช้งานอย่างต่อเนื่องโดย ซูเปอร์คอมพิวเตอร์ที่เร็วที่สุดอย่างน้อยครึ่งหนึ่งในสิบอันดับแรก และมากกว่า 60 ใน 100 อันดับแรกของโลก^{[ 5 ] [ 6 ] [ 7 ]} รวมถึงซูเปอร์คอมพิวเตอร์อันดับ 1 ของโลก^ใน TOP500ในเดือนพฤศจิกายน พ.ศ. 2565 Frontier [ ^{2 ] ตลอดจนซูเปอร์ คอมพิวเตอร์ ชั้นนำก่อนหน้า นี้}เช่นFugaku [ ^{8 ] [ 9 ]} Titan ^{[ 10 ]}และSequoia [ ^{11 ]}

ระบบไฟล์ Lustre สามารถปรับขนาดได้และสามารถเป็นส่วนหนึ่งของคลัสเตอร์คอมพิวเตอร์หลายเครื่องที่มี โหนดไคลเอ็นต์หลายหมื่นโหนด พื้นที่จัดเก็บข้อมูลหลายร้อยเพตาไบต์ (PB) บนเซิร์ฟเวอร์หลายร้อยเครื่อง และปริมาณงานI/Oรวม หลายสิบ เทราไบต์ ต่อวินาที ( TB/s) ^{[ 12 ] [ 13 ] ทำให้ระบบไฟล์ Lustre เป็นตัวเลือกยอดนิยมสำหรับธุรกิจที่มีศูนย์ข้อมูลขนาดใหญ่ รวมถึงธุรกิจในอุตสาหกรรม ต่างๆ}เช่นอุตุนิยมวิทยา [ ^{14 ] [ 15 ]}การจำลองปัญญาประดิษฐ์และ การเรียนรู้ ^ของเครื่อง [ ^{16 ] [ 17 ]}น้ำมันและก๊าซ^{[ 18 ]}วิทยาศาสตร์ชีวภาพ^{[ 19 ] [ 20 ]}สื่อมัลติมีเดียและการเงิน^{[ 21 ] ประสิทธิภาพ I /} O ของ Lustre มีผลกระทบอย่างกว้างขวางต่อแอปพลิเคชันเหล่านี้และได้รับความสนใจอย่างกว้างขวาง[ ^{22 ] [ 23 ] [ 24 ]}

สถาปัตยกรรมระบบไฟล์ Lustre เริ่มต้นจากโครงการวิจัยในปี 1999 โดยPeter J. Braamซึ่งเป็นบุคลากรของมหาวิทยาลัย Carnegie Mellon (CMU) ในขณะนั้น Braam ได้ก่อตั้งบริษัท Cluster File Systems ของตนเองในปี 2001 ^{[ 25 ]}โดยเริ่มต้นจากการทำงานเกี่ยวกับระบบไฟล์ InterMezzoในโครงการ Codaที่ CMU ^{[ 26 ]} Lustre ได้รับการพัฒนาภายใต้ โครงการ Accelerated Strategic Computing Initiative Path Forward ซึ่งได้รับทุนสนับสนุนจากกระทรวงพลังงานของสหรัฐอเมริกาโดยมีHewlett-PackardและIntel เข้าร่วมด้วย ^{[ 27} ] ในเดือนกันยายน 2007 Sun Microsystemsได้เข้าซื้อสินทรัพย์ของ Cluster File Systems Inc. รวมถึง "ทรัพย์สินทางปัญญา" ^{[ 28 ] [ 29 ]} Sun ได้รวม Lustre ไว้ใน ข้อเสนอฮาร์ดแวร์ คอมพิวเตอร์ประสิทธิภาพสูงโดยมีเจตนาที่จะนำเทคโนโลยี Lustre มาใช้กับระบบไฟล์^ZFSของ Sun และระบบปฏิบัติการSolarisในเดือนพฤศจิกายนปี 2008 บรามลาออกจากซันไมโครซิสเต็มส์ และเอริค บาร์ตันกับแอนเดรียส ดิลเกอร์เข้ามารับช่วงดูแลโครงการต่อ ในปี 2010 บริษัทออราเคิลคอร์ปอเรชั่นได้เริ่มบริหารจัดการและวางจำหน่าย Lustre ผ่านการเข้าซื้อกิจการของซัน

ในเดือนธันวาคม 2010 Oracle ประกาศว่าจะยุติการพัฒนา Lustre 2.x และให้ Lustre 1.8 อยู่ในสถานะการสนับสนุนการบำรุงรักษาเท่านั้น ซึ่งสร้างความไม่แน่นอนเกี่ยวกับการพัฒนาระบบไฟล์ในอนาคต^{[ 30 ]} หลังจากการประกาศนี้ องค์กรใหม่หลายแห่งได้เกิดขึ้นเพื่อให้บริการสนับสนุนและพัฒนาในรูปแบบการพัฒนาชุมชนแบบเปิด รวมถึง Whamcloud ^{[ 31 ]} Open Scalable File Systems, Inc. (OpenSFS) EUROPEAN Open File Systems (EOFS) และอื่นๆ ภายในสิ้นปี 2010 นักพัฒนา Lustre ส่วนใหญ่ได้ออกจาก Oracle Braam และเพื่อนร่วมงานหลายคนเข้าร่วม Xyratexซึ่งเน้นด้านฮาร์ดแวร์เมื่อบริษัทเข้าซื้อสินทรัพย์ของ ClusterStor ^{[ 32 ] [ 33 ]} ในขณะที่ Barton, Dilger และคนอื่นๆ ได้ก่อตั้งบริษัทสตาร์ทอัพด้านซอฟต์แวร์ Whamcloud ซึ่งพวกเขายังคงทำงานเกี่ยวกับ Lustre ต่อไป^{[ 34 ]}

ในเดือนสิงหาคม พ.ศ. 2554 OpenSFSได้มอบสัญญาการพัฒนาฟีเจอร์ Lustre ให้กับ Whamcloud ^{[ 35 ]}สัญญานี้ครอบคลุมการพัฒนาฟีเจอร์ต่างๆ ให้เสร็จสมบูรณ์ รวมถึงการปรับขนาดประสิทธิภาพเมตาเดตาเซิร์ฟเวอร์เดี่ยวที่ดีขึ้น ซึ่งช่วยให้ Lustre สามารถใช้ประโยชน์จากเซิร์ฟเวอร์เมตาเดตาแบบหลายคอร์ได้ดียิ่งขึ้น การตรวจสอบระบบไฟล์แบบกระจาย Lustre ออนไลน์ (LFSCK) ซึ่งช่วยให้สามารถตรวจสอบสถานะระบบไฟล์แบบกระจายระหว่างเซิร์ฟเวอร์ข้อมูลและเมตาเดตาในขณะที่ระบบไฟล์ถูกติดตั้งและใช้งานอยู่ และสภาพแวดล้อมเนมสเปซแบบกระจาย (DNE) ซึ่งเดิมเรียกว่าเมตาเดตาแบบคลัสเตอร์ (CMD) ซึ่งช่วยให้เมตาเดตาของ Lustre สามารถกระจายไปยังเซิร์ฟเวอร์หลายเครื่องได้ การพัฒนายังคงดำเนินต่อไปบนพื้นที่จัดเก็บวัตถุ แบ็กเอนด์แบบ ZFS ที่ ห้องปฏิบัติการแห่งชาติ ลอว์เรนซ์ลิเวอร์มอร์^{[ 11 ]}ฟีเจอร์เหล่านี้อยู่ในแผนงานการเผยแพร่ชุมชนของ Lustre เวอร์ชัน 2.2 ถึง 2.4 ^{[ 36 ]} ในเดือนพฤศจิกายน พ.ศ. 2554 ได้มีการมอบสัญญาแยกต่างหากให้กับ Whamcloud เพื่อดูแลรักษารหัสต้นฉบับของ Lustre 2.x เพื่อให้มั่นใจว่ารหัส Lustre จะได้รับการทดสอบและแก้ไขข้อบกพร่องอย่างเพียงพอในขณะที่กำลังพัฒนาฟีเจอร์ใหม่ๆ^{[ 37 ]}

ในเดือนกรกฎาคม พ.ศ. 2555 Whamcloud ถูกซื้อกิจการโดยIntel [ ^{38 ] [ 39 ]}หลังจากที่ Whamcloud ชนะสัญญา FastForward DOE เพื่อเตรียม Lustre ให้พร้อมใช้งานกับ^ระบบคอมพิวเตอร์ระดับ exascaleในช่วงเวลา พ.ศ. 2561 ^{[ 40 ]} จากนั้น OpenSFSก็โอนสัญญาการพัฒนา Lustre ให้กับ Intel

ในเดือนกุมภาพันธ์ พ.ศ. 2556 Xyratex Ltd. ประกาศว่าได้ซื้อเครื่องหมายการค้า โลโก้ เว็บไซต์ และทรัพย์สินทางปัญญา ที่เกี่ยวข้องกับ Lustre จาก Oracle ^{[ 32 ]}ในเดือนมิถุนายน พ.ศ. 2556 Intel เริ่มขยายการใช้งาน Lustre นอกเหนือจาก HPC แบบดั้งเดิม เช่น ภายในHadoop ^{[ 41} ] สำหรับปี พ.ศ. 2556 OpenSFSประกาศขอข้อเสนอ (RFP) เพื่อครอบคลุมการพัฒนาคุณสมบัติของ Lustre เครื่องมือ ระบบไฟล์แบบขนานการแก้ไขปัญหาทางเทคนิคของ Lustre และศูนย์บ่มเพาะระบบไฟล์แบบขนาน^{[ 42 ]} OpenSFSยังได้จัดตั้ง Lustre Community Portal ซึ่งเป็นเว็บไซต์ทางเทคนิคที่รวบรวมข้อมูลและเอกสารไว้ในที่เดียวเพื่อใช้อ้างอิงและให้คำแนะนำเพื่อสนับสนุนชุมชน^โอเพนซอร์ส ของ Lustre เมื่อวันที่ 8 เมษายน พ.ศ. 2557 Ken Claffey ประกาศว่า Xyratex/Seagate บริจาคโดเมน lustre.org คืนให้กับชุมชนผู้ใช้^{[ 43 ]}และการดำเนินการนี้เสร็จสมบูรณ์ในเดือนมีนาคม พ.ศ. 2558

ในเดือนมิถุนายน พ.ศ. 2561 ทีมและสินทรัพย์ของ Lustre ถูกซื้อจาก Intel โดยDDN DDN จัดตั้งการซื้อกิจการใหม่เป็นแผนกอิสระ และนำชื่อ Whamcloud กลับมาใช้สำหรับแผนกใหม่นี้^{[ 44 ]}

ในเดือนพฤศจิกายน 2019 OpenSFSและ EOFS ประกาศในงานSC19 Lustre BOF ว่าเครื่องหมายการค้า Lustre ได้ถูกโอนให้กับพวกเขาร่วมกันจากSeagate ^{[ 45 ]}

ระบบไฟล์ Lustre ได้รับการติดตั้งเพื่อใช้งานจริงครั้งแรกในเดือนมีนาคม พ.ศ. 2546 บนคลัสเตอร์ MCR Linux ที่ห้องปฏิบัติการแห่งชาติลอว์เรนซ์ลิเวอร์มอร์^[ 46 ^{] ซึ่ง}เป็นซูเปอร์คอมพิวเตอร์ที่ใหญ่เป็นอันดับสามในรายชื่อ Top500 ในขณะนั้น^{[ 47 ]}

Lustre 1.0.0 เปิดตัวในเดือนธันวาคม พ.ศ. 2546 ^{[ 1 ]}และให้ฟังก์ชันการทำงานของระบบไฟล์ Lustre ขั้นพื้นฐาน รวมถึงการสลับเซิร์ฟเวอร์และการกู้คืน

Lustre 1.2.0 ซึ่งวางจำหน่ายในเดือนมีนาคม พ.ศ. 2547 ทำงานบนเคอร์เนล Linux 2.6 และมีฟีเจอร์ "size glimpse" เพื่อหลีกเลี่ยงการเพิกถอนการล็อกไฟล์ที่กำลังเขียน และการบัญชีแคชการเขียนข้อมูลกลับฝั่งไคลเอ็นต์ (grant)

Lustre 1.4.0 ซึ่งวางจำหน่ายในเดือนพฤศจิกายน 2004 ได้เพิ่มความเข้ากันได้ของโปรโตคอลระหว่างเวอร์ชันต่างๆ สามารถใช้ เครือข่าย InfiniBandและสามารถใช้ประโยชน์จาก extents/mballoc ในระบบไฟล์บนดิสก์ldiskfs ได้

Lustre 1.6.0 ซึ่งวางจำหน่ายในเดือนเมษายน 2550 อนุญาตให้กำหนดค่าการเมานต์ ("mountconf") ซึ่งช่วยให้สามารถกำหนดค่าเซิร์ฟเวอร์ด้วย "mkfs" และ "mount" อนุญาตให้เพิ่มเป้าหมายการจัดเก็บอ็อบเจ็กต์ (OST) แบบไดนามิก เปิดใช้งานความสามารถในการปรับขนาดของตัวจัดการการล็อกแบบกระจายของ Lustre (LDLM) บน เซิร์ฟเวอร์ มัลติโปรเซสซิ่งแบบสมมาตร (SMP) และให้การจัดการพื้นที่ว่างสำหรับการจัดสรรอ็อบเจ็กต์

Lustre 1.8.0 ซึ่งวางจำหน่ายในเดือนพฤษภาคม พ.ศ. 2552 มี OSS Read Cache ปรับปรุงการกู้คืนเมื่อเผชิญกับความล้มเหลวหลายครั้ง เพิ่มการจัดการพื้นที่จัดเก็บข้อมูลแบบเฮเทอโรจีนัสขั้นพื้นฐานผ่าน OST Pools การหมดเวลาเครือข่ายแบบปรับได้ และการกู้คืนตามเวอร์ชัน เป็นเวอร์ชันเปลี่ยนผ่านที่สามารถทำงานร่วมกันได้ทั้งกับ Lustre 1.6 และ Lustre 2.0 ^{[ 48 ]}

Lustre 2.0 ซึ่งเปิดตัวในเดือนสิงหาคม 2010 นั้น พัฒนาขึ้นจากการปรับโครงสร้างโค้ดภายในครั้งสำคัญ เพื่อเตรียมพร้อมสำหรับความก้าวหน้าทางสถาปัตยกรรมครั้งใหญ่ไคลเอนต์ Lustre 2.x ไม่สามารถทำงานร่วมกับ เซิร์ฟเวอร์เวอร์ชัน 1.8 หรือก่อนหน้าได้ อย่างไรก็ตาม ไคลเอนต์ Lustre 1.8.6 และเวอร์ชันที่ใหม่กว่า สามารถทำงานร่วมกับเซิร์ฟเวอร์ Lustre 2.0 และเวอร์ชันที่ใหม่กว่าได้ รูปแบบ Metadata Target (MDT) และ OST บนดิสก์ของเวอร์ชัน 1.8 สามารถอัปเกรดเป็นเวอร์ชัน 2.0 และเวอร์ชันที่ใหม่กว่าได้โดยไม่ต้องฟอร์แมตระบบไฟล์ใหม่

Lustre 2.1 ซึ่งเปิดตัวในเดือนกันยายน พ.ศ. 2554 เป็นโครงการริเริ่มของชุมชนเพื่อตอบสนองต่อการที่ Oracle ระงับการพัฒนา Lustre 2.x ^{[ 49 ]}โดยเพิ่มความสามารถในการรันเซิร์ฟเวอร์บนRed Hat Linux 6 และเพิ่มขนาด OST สูงสุดที่ใช้ ext4 จาก 24  TB เป็น 128  TB ^{[ 50 ]}รวมถึงการปรับปรุงประสิทธิภาพและความเสถียรอีกหลายประการ เซิร์ฟเวอร์ Lustre 2.1 ยังคงสามารถทำงานร่วมกับไคลเอ็นต์เวอร์ชัน 1.8.6 และเวอร์ชันที่ใหม่กว่าได้

Lustre 2.2 ซึ่งวางจำหน่ายในเดือนมีนาคม พ.ศ. 2555 มุ่งเน้นไปที่การปรับปรุงประสิทธิภาพเมตาเดตาและคุณสมบัติใหม่^{[ 51 ]}โดยเพิ่มการดำเนินการไดเร็กทอรีแบบขนานที่อนุญาตให้ไคลเอนต์หลายรายสามารถสำรวจและแก้ไขไดเร็กทอรีขนาดใหญ่เดียวกันได้พร้อมกัน การกู้คืนจากความล้มเหลวของเซิร์ฟเวอร์ที่เร็วขึ้น จำนวนแถบที่เพิ่มขึ้นสำหรับไฟล์เดียว (ครอบคลุม OST สูงสุด 2,000 รายการ) และประสิทธิภาพการสำรวจไดเร็กทอรีของไคลเอนต์เดียวที่ดีขึ้น

Lustre 2.3 ซึ่งวางจำหน่ายในเดือนตุลาคม 2012 ได้ปรับปรุงโค้ดเซิร์ฟเวอร์เมตาเดตาอย่างต่อเนื่อง เพื่อขจัดปัญหาคอขวดด้านการล็อกภายในบนโหนดที่มีซีพียูหลายคอร์ (มากกว่า 16 คอร์) ระบบจัดเก็บข้อมูลแบบอ็อบเจ็กต์ได้เพิ่มความสามารถเบื้องต้นในการใช้ZFSเป็นระบบไฟล์หลัก ฟีเจอร์ Lustre File System ChecK (LFSCK) สามารถตรวจสอบและซ่อมแซมดัชนีอ็อบเจ็กต์ MDS (OI) ในขณะที่ระบบไฟล์กำลังใช้งานอยู่ หลังจากการสำรองข้อมูล/กู้คืนระดับไฟล์ หรือในกรณีที่ MDS เสียหาย สถิติ IO ฝั่งเซิร์ฟเวอร์ได้รับการปรับปรุงเพื่อให้สามารถทำงานร่วมกับตัวกำหนดตารางเวลางานแบบแบตช์ เช่นSLURMเพื่อติดตามสถิติต่องาน ซอฟต์แวร์ฝั่งไคลเอ็นต์ได้รับการอัปเดตให้ทำงานร่วมกับเคอร์เนล Linux เวอร์ชันสูงสุด 3.0

Lustre 2.4 ซึ่งเปิดตัวในเดือนพฤษภาคม 2013 ได้เพิ่มคุณสมบัติหลักจำนวนมาก ซึ่งหลายอย่างได้รับทุนสนับสนุนโดยตรงจากOpenSFS Distributed Namespace Environment (DNE) ช่วยให้สามารถเพิ่มความจุของเมตาเดต้าและประสิทธิภาพการทำงานในแนวนอนสำหรับไคลเอ็นต์ 2.4 โดยอนุญาตให้โครงสร้างไดเร็กทอรีย่อยของเนมสเปซเดียวอยู่บน MDT ที่แยกจากกันได้ขณะนี้สามารถใช้ZFS เป็นระบบไฟล์สำรองสำหรับทั้งการจัดเก็บ MDT และ OST ได้แล้ว คุณสมบัติ LFSCK เพิ่มความสามารถในการสแกนและตรวจสอบความสอดคล้องภายในของแอตทริบิวต์ MDT FID และ LinkEA Network Request Scheduler ^{[ 52 ] [ 53 ]} (NRS) เพิ่มนโยบายเพื่อเพิ่มประสิทธิภาพการประมวลผลคำขอไคลเอ็นต์สำหรับการจัดลำดับดิสก์หรือความเป็นธรรม ไคลเอ็นต์สามารถส่ง RPC จำนวนมากได้สูงสุด 4  MB ซอฟต์แวร์ฝั่งไคลเอ็นต์ได้รับการอัปเดตให้ทำงานร่วมกับเคอร์เนล Linux เวอร์ชันสูงสุด 3.6 และยังคงสามารถทำงานร่วมกับไคลเอ็นต์ 1.8 ได้

Lustre 2.5 ซึ่งวางจำหน่ายในเดือนตุลาคม 2013 ได้เพิ่มคุณสมบัติที่รอคอยมานานอย่าง การจัดการพื้นที่จัดเก็บข้อมูลแบบลำดับชั้น ( Hierarchical Storage Managementหรือ HSM) ซึ่งเป็นข้อกำหนดหลักในสภาพแวดล้อมขององค์กร HSM ช่วยให้ลูกค้าสามารถนำโซลูชันการจัดเก็บข้อมูลแบบหลายระดับไปใช้ในสภาพแวดล้อมการทำงานได้อย่างง่ายดาย รุ่นนี้ถือเป็นสาขาการบำรุงรักษาของ Lustre ที่กำหนดโดย OpenSFS ในปัจจุบัน^{[ 54 ] [ 55 ] [ 56 ] [ 57 ]}เวอร์ชันการบำรุงรักษาล่าสุดคือ 2.5.3 ซึ่งวางจำหน่ายในเดือนกันยายน 2014 ^{[ 58 ]}

Lustre 2.6 ซึ่งวางจำหน่ายในเดือนกรกฎาคม พ.ศ. 2557 ^{[ 59 ]}เป็นเวอร์ชันที่มีฟีเจอร์น้อยลง โดยเพิ่มฟังก์ชัน LFSCK เพื่อทำการตรวจสอบความสอดคล้องภายในเครื่องบน OST รวมถึงการตรวจสอบความสอดคล้องระหว่างวัตถุ MDT และ OST นโยบาย NRS Token Bucket Filter ^{[ 60 ]} (TBF) ถูกเพิ่มเข้ามา ประสิทธิภาพ IO ของไคลเอ็นต์เดี่ยวได้รับการปรับปรุงให้ดีขึ้นกว่าเวอร์ชันก่อนหน้า^{[ 61 ]}เวอร์ชันนี้ยังเพิ่มการแสดงตัวอย่างไดเร็กทอรีแบบแถบ DNE ซึ่งอนุญาตให้จัดเก็บไดเร็กทอรีขนาดใหญ่เพียงไดเร็กทอรีเดียวบน MDT หลายตัวเพื่อปรับปรุงประสิทธิภาพและความสามารถในการขยายขนาด

Lustre 2.7 ซึ่งวางจำหน่ายในเดือนมีนาคม พ.ศ. 2558 ^{[ 62 ]}ได้เพิ่มฟังก์ชัน LFSCK เพื่อตรวจสอบความสอดคล้องของ DNE ของไดเร็กทอรีระยะไกลและไดเร็กทอรีแบบแถบระหว่าง MDT หลายตัว Dynamic LNet Config เพิ่มความสามารถในการกำหนดค่าและแก้ไขอินเทอร์เฟซเครือข่าย LNet เส้นทาง และเราเตอร์ในขณะทำงาน มีการเพิ่มคุณสมบัติการประเมินใหม่สำหรับ การแมป UID / GIDสำหรับไคลเอ็นต์ที่มีโดเมนการดูแลระบบที่แตกต่างกัน พร้อมกับการปรับปรุงฟังก์ชันไดเร็กทอรีแบบแถบ DNE

Lustre 2.8 ซึ่งวางจำหน่ายในเดือนมีนาคม พ.ศ. 2559 ^{[ 63 ]}ได้ปรับปรุงคุณสมบัติไดเร็กทอรีแบบแถบ DNE ให้สมบูรณ์ รวมถึงการสนับสนุนการย้ายไดเร็กทอรีระหว่าง MDT และ การสร้าง ฮาร์ดลิงก์และการเปลี่ยนชื่อข้าม MDT นอกจากนี้ยังรวมถึงการปรับปรุงการสนับสนุนSecurity-Enhanced Linux ( SELinux ) บนไคลเอ็นต์ การตรวจสอบสิทธิ์ Kerberosและการเข้ารหัส RPC ผ่านเครือข่าย และการปรับปรุงประสิทธิภาพสำหรับ LFSCK

Lustre 2.9 เปิดตัวในเดือนธันวาคม 2016 ^{[ 64 ]} และมีคุณสมบัติหลายอย่างที่เกี่ยวข้องกับความปลอดภัยและประสิทธิภาพ รูปแบบการรักษาความปลอดภัย Shared Secret Key ใช้ กลไก GSSAPI เดียวกัน กับ Kerberos เพื่อให้การตรวจสอบสิทธิ์โหนดไคลเอ็นต์และเซิร์ฟเวอร์ รวมถึงความสมบูรณ์และความปลอดภัยของข้อความ RPC (การเข้ารหัส) คุณสมบัติ Nodemap อนุญาตให้จัดหมวดหมู่โหนดไคลเอ็นต์เป็นกลุ่ม จากนั้นแมป UID/GID สำหรับไคลเอ็นต์เหล่านั้น ทำให้ไคลเอ็นต์ที่ได้รับการจัดการจากระยะไกลสามารถใช้ระบบไฟล์ที่ใช้ร่วมกันได้อย่างโปร่งใสโดยไม่ต้องมีชุด UID/GID ชุดเดียวสำหรับโหนดไคลเอ็นต์ทั้งหมด คุณสมบัติการเมานต์ไดเร็กทอรีย่อยอนุญาตให้ไคลเอ็นต์เมานต์ส่วนย่อยของเนมสเปซระบบไฟล์จาก MDS การเปิดตัวครั้งนี้ยังเพิ่มการสนับสนุน RPC สูงสุด 16 MiB เพื่อการส่ง I/O ไปยังดิสก์ที่มีประสิทธิภาพมากขึ้น และเพิ่มladviseอินเทอร์เฟซเพื่อให้ไคลเอ็นต์สามารถให้คำแนะนำ I/O แก่เซิร์ฟเวอร์เพื่อดึงข้อมูลไฟล์ล่วงหน้าลงในแคชของเซิร์ฟเวอร์หรือล้างข้อมูลไฟล์จากแคชของเซิร์ฟเวอร์ มีการปรับปรุงการสนับสนุนสำหรับการระบุพูล OST เริ่มต้นทั่วทั้งระบบไฟล์ และการปรับปรุงการสืบทอดพูล OST ร่วมกับพารามิเตอร์เค้าโครงไฟล์อื่นๆ และขนาด OST สูงสุดที่รองรับโดย ldiskfs เพิ่มขึ้นเป็น 256 TiB

Lustre 2.10 เปิดตัวในเดือนกรกฎาคม 2017 ^{[ 65 ]} และมีการปรับปรุงที่สำคัญหลายประการ คุณสมบัติ LNet Multi-Rail (LMR) ช่วยให้สามารถรวมอินเทอร์เฟซเครือข่ายหลายตัว ( InfiniBand , Omni-Pathและ/หรือEthernet ) บนไคลเอ็นต์และเซิร์ฟเวอร์เพื่อเพิ่มแบนด์วิดท์ I/O โดยรวม ไฟล์แต่ละไฟล์สามารถใช้เลย์เอาต์ไฟล์แบบคอมโพสิตที่สร้างขึ้นจากส่วนประกอบหลายส่วน ซึ่งเป็นพื้นที่ไฟล์ตามออฟเซ็ตไฟล์ ที่อนุญาตให้ใช้พารามิเตอร์เลย์เอาต์ที่แตกต่างกัน เช่น จำนวนแถบ ประเภทพูล/พื้นที่จัดเก็บ OST เป็นต้นProgressive File Layout (PFL) เป็นคุณสมบัติแรกที่ใช้เลย์เอาต์แบบคอมโพสิต แต่การใช้งานมีความยืดหยุ่นสำหรับการใช้กับเลย์เอาต์ไฟล์อื่นๆ เช่น การทำมิเรอร์และการเข้ารหัสแบบลบ NRS Token Bucket Filter (TBF) ตัวกำหนดตารางเวลาฝั่งเซิร์ฟเวอร์ได้นำประเภทกฎใหม่มาใช้ รวมถึงการกำหนดตารางเวลาแบบ RPC และความสามารถในการระบุพารามิเตอร์หลายตัว เช่น JobID และ NID สำหรับการจับคู่กฎ ได้เพิ่มเครื่องมือสำหรับการจัดการสแนปช็อต ZFS ของระบบไฟล์ Lustre เพื่อลดความซับซ้อนในการสร้าง การเมานต์ และการจัดการสแนปช็อต ZFS ของ MDT และ OST ในฐานะจุดเมานต์ Lustre แยกต่างหาก ขนาดสูงสุดที่รองรับสำหรับ ldiskfs OST เพิ่มขึ้นเป็น 512 TiB

Lustre 2.11 เปิดตัวในเดือนเมษายน 2018 ^{[ 66 ]} และมีคุณสมบัติใหม่ที่สำคัญสองประการ และคุณสมบัติย่อยอีกหลายประการ คุณสมบัติ File Level Redundancy (FLR) ขยายการใช้งาน PFL ในเวอร์ชัน 2.10 โดยเพิ่มความสามารถในการระบุ เค้าโครงไฟล์ แบบมิเรอร์เพื่อเพิ่มความพร้อมใช้งานในกรณีที่เกิดความล้มเหลวของพื้นที่จัดเก็บหรือเซิร์ฟเวอร์ และ/หรือปรับปรุงประสิทธิภาพด้วยการอ่านพร้อมกันจำนวนมาก คุณสมบัติ Data-on-MDT (DoM) อนุญาตให้จัดเก็บไฟล์ขนาดเล็ก (ไม่กี่ MiB) บน MDT เพื่อใช้ประโยชน์จาก พื้นที่จัดเก็บ RAID-10 แบบแฟลชทั่วไป เพื่อลดความหน่วงและลดการแย่งชิง IO แทนที่จะ ใช้พื้นที่จัดเก็บ RAID-6 แบบHDD ทั่วไป ที่ใช้ใน OST นอกจากนี้ คุณสมบัติ LNet Dynamic Discovery ยังอนุญาตให้กำหนดค่า LNet Multi-Rail โดยอัตโนมัติระหว่างอุปกรณ์ที่ใช้เครือข่าย LNet ร่วมกัน คุณสมบัติ LDLM Lock Ahead ช่วยให้แอปพลิเคชันและไลบรารีที่ได้รับการแก้ไขอย่างเหมาะสมสามารถดึงล็อกส่วนขยาย DLM จาก OST สำหรับไฟล์ล่วงหน้าได้ หากแอปพลิเคชันทราบ (หรือคาดการณ์) ว่าส่วนขยายของไฟล์นี้จะถูกแก้ไขในอนาคตอันใกล้ ซึ่งจะช่วยลดการแย่งชิงล็อกสำหรับไคลเอนต์หลายรายที่เขียนไปยังไฟล์เดียวกัน

Lustre 2.12 เปิดตัวเมื่อวันที่ 21 ธันวาคม 2018 ^{[ 67 ]}โดยเน้นที่การปรับปรุงความสามารถในการใช้งานและความเสถียรของ Lustre พร้อมทั้งปรับปรุงประสิทธิภาพและฟังก์ชันการทำงานของฟีเจอร์ FLR และ DoM ที่เพิ่มเข้ามาใน Lustre 2.11 รวมถึงการเปลี่ยนแปลงเล็กน้อยใน NRS TBF , HSMและ JobStats นอกจากนี้ยังเพิ่มLNet Network Health Archived 2019-02-12 ที่Wayback Machineเพื่อให้ฟีเจอร์ LNet Multi-Rail จาก Lustre 2.10 สามารถจัดการกับข้อผิดพลาดของเครือข่ายได้ดีขึ้นเมื่อโหนดมีอินเทอร์เฟซเครือข่ายหลายตัว ฟีเจอร์ Lazy Size on MDT ^{[ 68 ]} (LSOM) ช่วยให้สามารถจัดเก็บค่าประมาณขนาดไฟล์บน MDT เพื่อใช้โดยเครื่องมือการกำหนดนโยบาย เครื่องสแกนระบบไฟล์ และเครื่องมือการจัดการอื่นๆ ที่สามารถตัดสินใจเกี่ยวกับไฟล์ได้อย่างมีประสิทธิภาพมากขึ้นโดยไม่ต้องทราบขนาดไฟล์หรือจำนวนบล็อกที่ถูกต้องทั้งหมดโดยไม่ต้องสอบถามข้อมูลนี้จาก OST การเผยแพร่ครั้งนี้ยังเพิ่มความสามารถในการจัดเรียงไดเร็กทอรีที่มีอยู่ใหม่ด้วยตนเองข้าม MDT หลายตัว เพื่ออนุญาตให้การย้ายไดเร็กทอรีที่มีไฟล์จำนวนมากใช้ความจุและประสิทธิภาพของโหนด MDS หลายตัว การตรวจสอบผลรวมข้อมูล Lustre RPC เพิ่มการตรวจสอบผลรวมข้อมูลแบบบูรณาการSCSI T10-PI ^{[ 69 ]}จากไคลเอ็นต์ไปยังเลเยอร์บล็อกเคอร์เนลอะแดปเตอร์โฮสต์ SCSI และฮาร์ดไดรฟ์ ที่เปิดใช้งาน T10

Lustre 2.13 เปิดตัวเมื่อวันที่ 5 ธันวาคม 2019 ^{[ 70 ]}และเพิ่มคุณสมบัติใหม่ที่เกี่ยวข้องกับประสิทธิภาพ ได้แก่ Persistent Client Cache ^{[ 71 ]} (PCC) ซึ่งอนุญาตให้ใช้ พื้นที่จัดเก็บข้อมูล NVMeและNVRAMบนโหนดไคลเอ็นต์โดยตรง ในขณะที่ยังคงเก็บไฟล์ไว้ในเนมสเปซของระบบไฟล์ส่วนกลาง และ OST Overstriping ^{[ 72 ]}ซึ่งอนุญาตให้ไฟล์จัดเก็บแถบหลายแถบใน OST เดียว เพื่อใช้ประโยชน์จากฮาร์ดแวร์ OSS ที่รวดเร็วได้ดียิ่งขึ้น นอกจากนี้ ฟังก์ชัน LNet Multi-Rail Network Health ยังได้รับการปรับปรุงให้ทำงานร่วมกับโหนดเราเตอร์ LNet RDMA ฟังก์ชัน PFL ได้รับการปรับปรุงด้วย Self-Extending Layouts ^{[ 73 ]} (SEL) เพื่ออนุญาตให้ส่วนประกอบของไฟล์มีขนาดแบบไดนามิก เพื่อจัดการกับ flash OST ที่อาจมีขนาดเล็กกว่า disk OST ภายในระบบไฟล์เดียวกันได้ดียิ่งขึ้น การเผยแพร่ครั้งนี้ยังรวมถึงการปรับปรุงเล็กๆ น้อยๆ อีกหลายประการ เช่น การปรับสมดุลการสร้างไดเร็กทอรีระยะไกล DNE ทั่ว MDT การใช้ Lazy-size-on-MDT เพื่อลดภาระของ "lfs find" ไดเร็กทอรีที่มีไฟล์ 10 ล้านไฟล์ต่อชาร์ดสำหรับ ldiskfs และขนาด RPC จำนวนมากสูงสุด 64  MB ^{[ 74 ]}

Lustre 2.14 เปิดตัวเมื่อวันที่ 19 กุมภาพันธ์ 2021 ^{[ 75 ]}และมีคุณสมบัติหลักสามประการ การเข้ารหัสข้อมูลไคลเอ็นต์ใช้ fscrypt เพื่ออนุญาตให้เข้ารหัสข้อมูลไฟล์บนไคลเอ็นต์ก่อนการถ่ายโอนเครือข่ายและการจัดเก็บถาวรบน OST และ MDT โควต้าพูล OST ขยายกรอบงานโควต้าเพื่ออนุญาตให้กำหนดและบังคับใช้โควต้าตามพูลจัดเก็บ OST และขนาด OST ldiskfs ที่รองรับสูงสุดเพิ่มขึ้นเป็น 1024TiB การแบ่งส่วนอัตโนมัติของ DNE สามารถปรับจำนวน MDT ที่ไดเร็กทอรีขนาดใหญ่จะถูกแบ่งส่วนตามเกณฑ์ขนาดที่กำหนดโดยผู้ดูแลระบบ คล้ายกับเค้าโครงไฟล์แบบก้าวหน้าสำหรับไดเร็กทอรี

Lustre 2.15 เปิดตัวเมื่อวันที่ 16 มิถุนายน 2022 ^{[ 76 ]}และมีคุณสมบัติหลักสามประการ การเข้ารหัสไดเร็กทอรีไคลเอ็นต์^{[ 77 ]} ขยายการเข้ารหัสข้อมูล fscrypt ในเวอร์ชัน 2.14 เพื่อให้สามารถเข้ารหัสชื่อไฟล์และไดเร็กทอรีบนไคลเอ็นต์ก่อนการถ่ายโอนเครือข่ายและการจัดเก็บถาวรบน MDT การปรับสมดุลพื้นที่ DNE MDT จะปรับสมดุลการสร้างไดเร็กทอรีใหม่โดยอัตโนมัติใน MDT ต่างๆ ในระบบไฟล์แบบวนรอบและ/หรือตาม inode และพื้นที่ว่าง ซึ่งจะช่วยกระจายภาระงานเมตาเดตาไคลเอ็นต์ไปยัง MDT อย่างสม่ำเสมอยิ่งขึ้น สำหรับแอปพลิเคชันที่ใช้NVIDIA GPU Direct Storage interface (GDS) ไคลเอ็นต์ Lustre สามารถ อ่านและเขียน RDMA แบบ zero-copy จากเซิร์ฟเวอร์จัดเก็บข้อมูลโดยตรงไปยัง หน่วยความจำ GPUเพื่อหลีกเลี่ยงการคัดลอกข้อมูลเพิ่มเติมจาก หน่วยความจำ CPUและโอเวอร์เฮดการประมวลผลเพิ่มเติม^{[ 78 ]}นโยบายการเลือกที่ผู้ใช้กำหนด (UDSP) อนุญาตให้ตั้งค่านโยบายการเลือกอินเทอร์เฟซสำหรับโหนดที่มีอินเทอร์เฟซเครือข่ายหลายตัว

Lustre 2.16 เปิดตัวเมื่อวันที่ 8 พฤศจิกายน 2024 ^{[ 79 ]}และมีคุณสมบัติหลักสามประการ การสนับสนุนการกำหนดแอดเดรสเครือข่ายขนาดใหญ่^{[ 80 ]}อนุญาตให้ใช้IPv6และอาจใช้รูปแบบแอดเดรสขนาดใหญ่อื่นๆ เช่นInfiniband GUIDs สำหรับการกำหนดแอดเดรสโหนดไคลเอ็นต์และเซิร์ฟเวอร์ นอกเหนือจาก แอดเดรส IPv4 มาตรฐาน คุณสมบัติ Unaligned and Hybrid Direct IO ช่วยปรับปรุงประสิทธิภาพสำหรับแอปพลิเคชันที่ทำการอ่าน/เขียนข้อมูลแบบบัฟเฟอร์และแบบตรงขนาดใหญ่โดยหลีกเลี่ยงค่าใช้จ่ายเพิ่มเติมในแคชเพจไคลเอ็นต์^{[ 81 ]}คุณสมบัติ Optimized Directory Traversal (batched statahead) ช่วยปรับปรุงภาระงานของแอปพลิเคชันที่สำรวจลำดับชั้นของไดเร็กทอรีและเข้าถึงแอตทริบิวต์ไฟล์ในรูปแบบการเข้าถึงที่เป็นระบบโดยการดึงแอตทริบิวต์ไฟล์ล่วงหน้าแบบขนานจาก MDS(es) โดยใช้ bulk RPCs ^{[ 82 ]}

Lustre 2.17 เปิดตัวเมื่อวันที่ 28 ธันวาคม พ.ศ. 2568 ^{[ 83 ]}และประกอบด้วยคุณสมบัติหลัก 3 ประการ พร้อมกับการปรับปรุงอื่นๆ อีกมากมาย การกำหนดค่า NID แบบไดนามิกช่วยให้เซิร์ฟเวอร์สามารถกำหนดค่าและประกาศอินเทอร์เฟซเครือข่ายชั่วคราวให้กับไคลเอนต์บนเครือข่ายเสมือน ( VLAN ) โดยไม่ต้องเปลี่ยนการกำหนดค่าอย่างถาวรหรือขัดจังหวะบริการที่กำลังทำงานอยู่ การปรับปรุง Nodemaps ช่วยลดความซับซ้อนของการแยกไคลเอนต์และให้การควบคุมการเข้าถึงไคลเอนต์แบบละเอียดเพิ่มเติม อนุญาตให้ส่งออกชุดไฟล์หลายชุด (อ่านอย่างเดียวได้) ต่อ nodemap และรวมถึงการแยกสิทธิ์รูทภายใน nodemap ^{[ 84 ]} คุณสมบัติเหล่านี้มีประโยชน์สำหรับการจำลองเสมือนระบบไฟล์ในสภาพแวดล้อมการประมวลผลแบบคลาวด์และแบบใช้ร่วมกัน การปรับปรุงการใช้งาน Hybrid IO ช่วยเพิ่มประสิทธิภาพและความยืดหยุ่นสำหรับแอปพลิเคชันที่ดำเนินการ IO จำนวนมาก

ระบบไฟล์ Lustre ประกอบด้วยหน่วยการทำงานหลักสามหน่วย:

• ระบบไฟล์ Lustre ประกอบด้วยโหนด เซิร์ฟเวอร์เมตาเดตา (MDS)อย่างน้อยหนึ่ง โหนด ซึ่งแต่ละโหนดจะมีอุปกรณ์ เป้าหมายเมตาเดตา (MDT) อย่างน้อยหนึ่งตัวสำหรับจัดเก็บข้อมูลเมตาของเนมสเปซ เช่น ชื่อไฟล์ ไดเร็กทอรี สิทธิ์การเข้าถึง และโครงสร้างไฟล์ ข้อมูล MDT จะถูกจัดเก็บไว้ในระบบไฟล์ดิสก์ภายในเครื่อง อย่างไรก็ตาม แตกต่างจากระบบไฟล์แบบกระจายที่ใช้บล็อก เช่นGPFSและPanFSซึ่งเซิร์ฟเวอร์เมตาเดตาควบคุมการจัดสรรบล็อกทั้งหมด เซิร์ฟเวอร์เมตาเดตาของ Lustre จะเกี่ยวข้องเฉพาะกับการตรวจสอบพาธเนมและสิทธิ์การเข้าถึงเท่านั้น และจะไม่เกี่ยวข้องกับการดำเนินการI/O ไฟล์ใดๆ ซึ่งช่วยหลีกเลี่ยงปัญหาคอขวดด้านความสามารถในการขยายขนาด I/Oบนเซิร์ฟเวอร์เมตาเดตา ความสามารถในการมี MDT หลายตัวในระบบไฟล์เดียวเป็นคุณสมบัติใหม่ใน Lustre 2.4 และอนุญาตให้โครงสร้างย่อยของไดเร็กทอรีอยู่บน MDT รอง ในขณะที่เวอร์ชัน 2.7 และเวอร์ชันต่อมาอนุญาตให้กระจายไดเร็กทอรีขนาดใหญ่ไปยัง MDT หลายตัวได้เช่นกัน
• เซิร์ฟเวอร์จัดเก็บข้อมูลแบบอ็อบเจ็กต์ (OSS)อย่างน้อยหนึ่งโหนดจะจัดเก็บข้อมูลไฟล์บน อุปกรณ์ จัดเก็บข้อมูลแบบอ็อบเจ็กต์ (OST) อย่างน้อยหนึ่ง อุปกรณ์ โดยทั่วไปแล้ว OSS จะให้บริการ OST ระหว่างสองถึงแปดอุปกรณ์ ขึ้นอยู่กับฮาร์ดแวร์ของเซิร์ฟเวอร์ โดยแต่ละ OST จะจัดการระบบไฟล์ดิสก์ภายในเครื่องเพียงระบบเดียว ความจุของระบบไฟล์ Lustre คือผลรวมของความจุที่ OST ต่างๆ จัดสรรให้
• ไคลเอ็นต์ที่เข้าถึงและใช้งานข้อมูล Lustre นำเสนอเนมสเปซที่เป็นหนึ่งเดียวสำหรับไฟล์และข้อมูลทั้งหมดในระบบไฟล์แก่ไคลเอ็นต์ทั้งหมด โดยใช้ความหมายมาตรฐานPOSIXและอนุญาตให้เข้าถึงการอ่านและการเขียนไฟล์ในระบบไฟล์พร้อมกันและสอดคล้องกันได้

MDT, OST และไคลเอ็นต์อาจอยู่บนโหนดเดียวกัน (โดยปกติเพื่อวัตถุประสงค์ในการทดสอบ) แต่ในการติดตั้งใช้งานจริงทั่วไป อุปกรณ์เหล่านี้จะอยู่บนโหนดที่แยกจากกันและสื่อสารกันผ่านเครือข่าย MDT และ OST แต่ละตัวอาจเป็นส่วนหนึ่งของระบบไฟล์เดียวเท่านั้น แม้ว่าจะเป็นไปได้ที่จะมี MDT หรือ OST หลายตัวบนโหนดเดียวซึ่งเป็นส่วนหนึ่งของระบบไฟล์ที่แตกต่างกัน เลเยอร์เครือข่าย Lustre (LNet)สามารถใช้การเชื่อมต่อเครือข่ายได้หลายประเภท รวมถึงInfiniBand verbs ดั้งเดิม, Omni-Path , RoCEและiWARPผ่านOFED , TCP/IPบนEthernetและเทคโนโลยีเครือข่ายที่เป็นกรรมสิทธิ์อื่นๆ เช่น การเชื่อมต่อ Cray Gemini ใน Lustre 2.3 และรุ่นก่อนหน้า เครือข่าย Myrinet , Quadrics , Cray SeaStar และ RapidArray ก็ได้รับการสนับสนุนเช่นกัน แต่ไดรเวอร์เครือข่ายเหล่านี้ถูกยกเลิกเมื่อเครือข่ายเหล่านี้ไม่มีจำหน่ายในเชิงพาณิชย์อีกต่อไป และการสนับสนุนถูกลบออกอย่างสมบูรณ์ใน Lustre 2.8 Lustre จะใช้ประโยชน์จากการถ่ายโอนข้อมูลผ่านการเข้าถึงหน่วยความจำโดยตรงจากระยะไกล ( RDMA ) เมื่อมีให้ใช้งาน เพื่อปรับปรุงปริมาณงานและลดการใช้งาน CPU

พื้นที่จัดเก็บข้อมูลที่ใช้สำหรับระบบไฟล์พื้นฐานของ MDT และ OST โดยปกติจะใช้ฮาร์ดแวร์RAIDแต่ก็สามารถใช้งานได้กับอุปกรณ์บล็อกใดๆ ก็ได้ ตั้งแต่ Lustre เวอร์ชัน 2.4 เป็นต้นมา MDT และ OST สามารถใช้ZFSเป็นระบบไฟล์พื้นฐานได้นอกเหนือจากext4ทำให้สามารถใช้ พื้นที่จัดเก็บข้อมูล JBODแทนฮาร์ดแวร์ RAID ได้อย่างมีประสิทธิภาพ เซิร์ฟเวอร์ Lustre OSS และ MDS จะอ่าน เขียน และแก้ไขข้อมูลในรูปแบบที่กำหนดโดยระบบไฟล์พื้นฐาน และส่งข้อมูลนี้กลับไปยังไคลเอนต์ これにより Lustre สามารถใช้ประโยชน์จากข้อดีและคุณสมบัติต่างๆ ในระบบไฟล์พื้นฐาน เช่น การบีบอัดและการตรวจสอบความถูกต้องของข้อมูลใน ZFS ได้ ไคลเอนต์ไม่สามารถเข้าถึงพื้นที่จัดเก็บข้อมูลพื้นฐานได้โดยตรง ซึ่งทำให้มั่นใจได้ว่าไคลเอนต์ที่ทำงานผิดพลาดหรือเป็นอันตรายจะไม่สามารถทำลายโครงสร้างของระบบไฟล์ได้

OST คือระบบไฟล์เฉพาะที่ส่งออกอินเทอร์เฟซไปยังช่วงไบต์ของวัตถุไฟล์สำหรับการดำเนินการอ่าน/เขียน โดยมี การล็อก ส่วนขยายเพื่อปกป้องความสอดคล้องของข้อมูล MDT คือระบบไฟล์เฉพาะที่จัดเก็บ inode, ไดเร็กทอรี, คุณลักษณะไฟล์POSIXและ แบบขยาย ควบคุมสิทธิ์การเข้าถึงไฟล์/ ACLและบอกไคลเอนต์ถึงเค้าโครงของวัตถุที่ประกอบขึ้นเป็นไฟล์ปกติแต่ละไฟล์ ปัจจุบัน MDT และ OST ใช้ext4 เวอร์ชันปรับปรุง ที่เรียกว่าldiskfsหรือZFS /DMU สำหรับการจัดเก็บข้อมูลแบ็กเอนด์เพื่อจัดเก็บไฟล์/วัตถุ^{[ 85 ]}โดยใช้พอร์ต ZFS-on-Linux แบบโอเพนซอร์ส^{[ 86 ]}

ไคลเอนต์จะทำการเมานต์ระบบไฟล์ Lustre ในเครื่องโดยใช้ ไดรเวอร์ VFSสำหรับ เคอร์เนล Linuxซึ่งจะเชื่อมต่อไคลเอนต์กับเซิร์ฟเวอร์ เมื่อทำการเมานต์ครั้งแรก ไคลเอนต์จะได้รับตัวระบุไฟล์ (FID) สำหรับไดเร็กทอรีรากของจุดเมานต์ เมื่อไคลเอนต์เข้าถึงไฟล์ ไคลเอนต์จะทำการค้นหาชื่อไฟล์ใน MDSเมื่อการค้นหาชื่อไฟล์ใน MDS เสร็จสมบูรณ์ และผู้ใช้และไคลเอนต์มีสิทธิ์ในการเข้าถึงและ/หรือสร้างไฟล์ ระบบจะส่งโครงสร้างของไฟล์ที่มีอยู่กลับไปยังไคลเอนต์ หรือสร้างไฟล์ใหม่ในนามของไคลเอนต์หากมีการร้องขอ สำหรับการดำเนินการอ่านหรือเขียน ไคลเอนต์จะตีความโครงสร้างไฟล์ในเลเยอร์วอลุ่มออบเจ็กต์เชิงตรรกะ (LOV)ซึ่งจะแมปออฟเซ็ตเชิงตรรกะและขนาดของไฟล์ไปยังออบเจ็กต์หนึ่งรายการหรือมากกว่าจากนั้นไคลเอนต์จะล็อกช่วงไฟล์ที่กำลังดำเนินการอยู่ และดำเนินการอ่านหรือเขียนแบบขนานอย่างน้อยหนึ่งรายการโดยตรงไปยังโหนด OSS ที่เก็บออบเจ็กต์ข้อมูล ด้วยวิธีการนี้ ปัญหาคอขวดในการสื่อสารระหว่างไคลเอ็นต์กับ OSS จะถูกกำจัดออกไป ทำให้แบนด์วิดท์โดยรวมที่ไคลเอ็นต์ใช้ในการอ่านและเขียนข้อมูลเพิ่มขึ้นเกือบเป็นเส้นตรงตามจำนวน OST ในระบบไฟล์

หลังจากตรวจสอบโครงสร้างไฟล์เบื้องต้นแล้ว MDS จะไม่เกี่ยวข้องกับการดำเนินการอ่านเขียนไฟล์โดยตรง เนื่องจาก OST จะจัดการการจัดสรรบล็อกและการอ่านเขียนข้อมูลภายในทั้งหมด ลูกค้าจะไม่แก้ไขวัตถุหรือข้อมูลบนระบบไฟล์ OST โดยตรง แต่จะมอบหมายงานนี้ให้กับโหนด OSS แทน วิธีการนี้ช่วยให้มั่นใจได้ถึงความสามารถในการขยายขนาดสำหรับคลัสเตอร์ขนาดใหญ่และซูเปอร์คอมพิวเตอร์ รวมถึงความปลอดภัยและความน่าเชื่อถือที่ดียิ่งขึ้น ในทางตรงกันข้าม ระบบไฟล์แบบบล็อกที่ใช้ร่วมกัน เช่นGPFSและOCFS อนุญาตให้ลูกค้าทั้งหมดในระบบไฟล์เข้าถึงพื้นที่จัดเก็บข้อมูลพื้นฐานได้โดยตรง ซึ่งต้องใช้ SANขนาดใหญ่ที่เชื่อมต่อกับลูกค้าทั้งหมด และเพิ่มความเสี่ยงต่อความเสียหายของระบบไฟล์จากลูกค้าที่ทำงานผิดปกติ/มีข้อบกพร่อง

ในการติดตั้ง Lustre บนเครื่องไคลเอ็นต์ Linux ทั่วไป โมดูลไดรเวอร์ระบบไฟล์ Lustre จะถูกโหลดเข้าไปในเคอร์เนล และระบบไฟล์จะถูกเมานต์เหมือนกับระบบไฟล์ภายในเครื่องหรือเครือข่ายอื่นๆ แอปพลิเคชันไคลเอ็นต์จะมองเห็นระบบไฟล์เดียวที่รวมเป็นหนึ่งเดียว แม้ว่าระบบไฟล์นั้นอาจประกอบด้วยเซิร์ฟเวอร์แต่ละตัวและระบบไฟล์ MDT/OST นับสิบถึงหลายพันตัวก็ตาม

ใน การติดตั้ง โปรเซสเซอร์แบบขนานขนาดใหญ่ (MPP) บางส่วน โปรเซสเซอร์การคำนวณสามารถเข้าถึงระบบไฟล์ Lustre ได้โดยการเปลี่ยนเส้นทางการร้องขอ I/O ไปยังโหนด I/O เฉพาะที่กำหนดค่าเป็นไคลเอ็นต์ Lustre วิธีนี้ใช้ในการติดตั้งBlue Gene ^{[ 87 ]}ที่ห้องปฏิบัติการแห่งชาติ Lawrence Livermore

แนวทางอื่นที่ใช้ในช่วงแรกๆ ของ Lustre คือไลบรารีliblustre บนCray XT3โดยใช้ระบบปฏิบัติการ Catamount บนระบบ ^{ต่างๆ}เช่นSandia Red Storm [ ^{88 ]}ซึ่งให้ แอปพลิ เคชันในพื้นที่ผู้ใช้เข้าถึงระบบไฟล์ได้โดยตรง Liblustre เป็นไลบรารีระดับผู้ใช้ที่อนุญาตให้โปรเซสเซอร์คำนวณติดตั้งและใช้ระบบไฟล์ Lustre ในฐานะไคลเอ็นต์ การใช้ liblustre ทำให้โปรเซสเซอร์คำนวณสามารถเข้าถึงระบบไฟล์ Lustre ได้แม้ว่าโหนดบริการที่เริ่มงานจะไม่ใช่ไคลเอ็นต์ Linux ก็ตาม Liblustre อนุญาตให้เคลื่อนย้ายข้อมูลโดยตรงระหว่างพื้นที่แอปพลิเคชันและ Lustre OSS โดยไม่ต้องมีการคัดลอกข้อมูลผ่านเคอร์เนล ทำให้โปรเซสเซอร์คำนวณสามารถเข้าถึงระบบไฟล์ Lustre ได้โดยตรงในสภาพแวดล้อมการทำงานที่จำกัด ฟังก์ชัน liblustre ถูกลบออกจาก Lustre 2.7.0 หลังจากถูกปิดใช้งานตั้งแต่ Lustre 2.6.0 และไม่ได้ทดสอบอีกเลยตั้งแต่ Lustre 2.3.0

ใน Linux Kernel เวอร์ชัน 4.18 พอร์ตที่ไม่สมบูรณ์ของไคลเอ็นต์ Lustre ถูกลบออกจากพื้นที่จัดเตรียมเคอร์เนลเพื่อเร่งการพัฒนาและการพอร์ตไปยังเคอร์เนลเวอร์ชันใหม่กว่า^{[ 89 ]}ไคลเอ็นต์และเซิร์ฟเวอร์ Lustre ที่อยู่นอกโครงสร้างหลักยังคงมีให้ใช้งานสำหรับเคอร์เนลของ RHEL, SLES และUbuntuรวมถึงเคอร์เนลมาตรฐานด้วย

ในระบบไฟล์ดิสก์Unix แบบดั้งเดิม โครงสร้างข้อมูล inodeจะประกอบด้วยข้อมูลพื้นฐานเกี่ยวกับแต่ละไฟล์ เช่น ตำแหน่งที่จัดเก็บข้อมูลในไฟล์นั้น ระบบไฟล์ Lustre ก็ใช้ inode เช่นกัน แต่ inode บน MDT จะชี้ไปยังอ็อบเจ็กต์ OST อย่างน้อยหนึ่งรายการที่เกี่ยวข้องกับไฟล์ แทนที่จะชี้ไปยังบล็อกข้อมูล อ็อบเจ็กต์เหล่านี้ถูกนำไปใช้เป็นไฟล์บน OST เมื่อไคลเอนต์เปิดไฟล์ การดำเนินการเปิดไฟล์จะถ่ายโอนชุดตัวระบุอ็อบเจ็กต์และโครงสร้างของอ็อบเจ็กต์เหล่านั้นจาก MDS ไปยังไคลเอนต์ เพื่อให้ไคลเอนต์สามารถโต้ตอบโดยตรงกับโหนด OSS ที่เก็บอ็อบเจ็กต์เหล่านั้นได้ ซึ่งช่วยให้ไคลเอนต์สามารถดำเนินการ I/O แบบขนานกับอ็อบเจ็กต์ OST ทั้งหมดในไฟล์ได้โดยไม่ต้องสื่อสารกับ MDS เพิ่มเติม หลีกเลี่ยงการแย่งชิงทรัพยากรจากการจัดการบล็อกและการล็อกแบบรวมศูนย์

หากมีการเชื่อมโยงอ็อบเจ็กต์ OST เพียงหนึ่งเดียวกับ inode ของ MDT อ็อบเจ็กต์นั้นจะประกอบด้วยข้อมูลทั้งหมดในไฟล์ Lustre แต่หากมีการเชื่อมโยงอ็อบเจ็กต์มากกว่าหนึ่งรายการกับไฟล์ ข้อมูลในไฟล์จะถูก "แบ่ง" ออกเป็นส่วนๆ ใน ลักษณะ หมุนเวียนไปทั่วอ็อบเจ็กต์ OST คล้ายกับRAID 0โดยแต่ละส่วนจะมีขนาดประมาณ 1  MB หรือมากกว่า การแบ่งไฟล์ออกเป็นหลายส่วนจะช่วยเพิ่มประสิทธิภาพได้อย่างมากหากต้องการเข้าถึงไฟล์ขนาดใหญ่ด้วยแบนด์วิดท์สูง เมื่อใช้การแบ่งไฟล์ ขนาดไฟล์สูงสุดจะไม่ถูกจำกัดด้วยขนาดของเป้าหมายเดียว ความจุและแบนด์วิดท์ I/O โดยรวมจะแปรผันตามจำนวน OST ที่ไฟล์ถูกแบ่งออก นอกจากนี้ เนื่องจากมีการล็อกอ็อบเจ็กต์แต่ละรายการแยกกันสำหรับแต่ละ OST การเพิ่มส่วนต่างๆ (หนึ่งส่วนต่อ OST) จะเพิ่มความจุในการล็อก I/O ของไฟล์ตามสัดส่วนด้วย แต่ละไฟล์ที่สร้างขึ้นในระบบไฟล์อาจระบุพารามิเตอร์เค้าโครงที่แตกต่างกัน เช่น จำนวนแถบ (จำนวนอ็อบเจ็กต์ OST ที่ประกอบกันเป็นไฟล์นั้น) ขนาดแถบ (หน่วยข้อมูลที่จัดเก็บในแต่ละ OST ก่อนที่จะย้ายไปยัง OST ถัดไป) และการเลือก OST เพื่อให้สามารถปรับแต่งประสิทธิภาพและความจุให้เหมาะสมที่สุดสำหรับแต่ละไฟล์ เมื่อมีเธรดแอปพลิเคชันจำนวนมากอ่านหรือเขียนไฟล์ที่แยกจากกันพร้อมกัน การมีแถบเดียวต่อไฟล์จึงเหมาะสมที่สุด เนื่องจากแอปพลิเคชันนั้นให้การทำงานแบบขนานของตัวเองอยู่แล้ว เมื่อมีเธรดจำนวนมากอ่านหรือเขียนไฟล์ขนาดใหญ่ไฟล์เดียวพร้อมกัน การมีแถบอย่างน้อยหนึ่งแถบในแต่ละ OST จึงเหมาะสมที่สุดเพื่อเพิ่มประสิทธิภาพและความจุของไฟล์นั้นให้สูงสุด

ในเวอร์ชัน Lustre 2.10 ได้เพิ่มความสามารถในการระบุเลย์เอาต์แบบผสมเพื่อให้ไฟล์มีพารามิเตอร์เลย์เอาต์ที่แตกต่างกันสำหรับแต่ละส่วนของไฟล์ คุณสมบัติ Progressive File Layout (PFL) ใช้เลย์เอาต์แบบผสมเพื่อปรับปรุงประสิทธิภาพการอ่านเขียนไฟล์ (IO) ในช่วงปริมาณงานที่กว้างขึ้น รวมถึงลดความซับซ้อนในการใช้งานและการจัดการ ตัวอย่างเช่น ไฟล์ PFL ขนาดเล็กสามารถมีแถบเดียวบนแฟลชเพื่อลดค่าใช้จ่ายในการเข้าถึง ในขณะที่ไฟล์ขนาดใหญ่สามารถมีหลายแถบเพื่อแบนด์วิดท์รวมสูงและการกระจายโหลด OST ที่ดีขึ้น เลย์เอาต์แบบผสมได้รับการปรับปรุงเพิ่มเติมในเวอร์ชัน 2.11 ด้วย คุณสมบัติ File Level Redundancy (FLR) ซึ่งอนุญาตให้ไฟล์มีเลย์เอาต์ที่ซ้อนทับกันหลายแบบ ทำให้เกิด ความซ้ำซ้อนแบบ RAID 0+1สำหรับไฟล์เหล่านี้ รวมถึงประสิทธิภาพการอ่านที่ดีขึ้น เวอร์ชัน Lustre 2.11 ยังเพิ่ม คุณสมบัติ Data-on-Metadata (DoM) ซึ่งอนุญาตให้ ส่วนประกอบ แรกของไฟล์ PFL ถูกจัดเก็บโดยตรงบน MDT พร้อมกับ inode วิธีนี้ช่วยลดภาระในการเข้าถึงไฟล์ขนาดเล็ก ทั้งในแง่ของการใช้พื้นที่ (ไม่จำเป็นต้องมีอ็อบเจ็กต์ OST) และการใช้งานเครือข่าย (ต้องการ RPC น้อยลงในการเข้าถึงข้อมูล) DoM ยังช่วยปรับปรุงประสิทธิภาพสำหรับไฟล์ขนาดเล็กหาก MDT ใช้ SSDในขณะที่ OST ใช้ดิสก์ ใน Lustre 2.13 คุณสมบัติ OST Overstripingช่วยให้ส่วนประกอบเดียวมีหลายแถบใน OST เดียวเพื่อปรับปรุงการทำงานแบบขนานของการล็อกให้ดียิ่งขึ้น ในขณะที่ ฟีเจอร์ Self-Extending Layoutช่วยให้ขนาดของส่วนประกอบเปลี่ยนแปลงได้ระหว่างการเขียน เพื่อให้สามารถรับมือกับ OST แต่ละตัว (แฟลช) ที่พื้นที่หมดก่อนที่ระบบไฟล์ทั้งหมดจะหมดพื้นที่

เมื่อไคลเอ็นต์เชื่อมต่อกับระบบไฟล์เป็นครั้งแรก ระบบจะส่งตัวระบุไฟล์ Lustre (FID ซึ่งประกอบด้วยหมายเลขลำดับ 64 บิต, รหัสวัตถุ 32 บิต และเวอร์ชัน 32 บิต) ขนาด 128 บิต ของไดเร็กทอรีรากสำหรับจุดเชื่อมต่อให้ไคลเอ็นต์ เมื่อทำการค้นหาชื่อไฟล์ ไคลเอ็นต์จะทำการค้นหาส่วนประกอบของพาธเนมแต่ละส่วนโดยการแมปหมายเลขลำดับ FID ของไดเร็กทอรีแม่ไปยัง MDT เฉพาะผ่านฐานข้อมูลตำแหน่ง FID (FLDB) จากนั้นจะทำการค้นหาบน MDS ที่จัดการ MDT นี้โดยใช้ FID ของไดเร็กทอรีแม่และชื่อไฟล์ MDS จะส่งคืน FID สำหรับส่วนประกอบของพาธเนมที่ร้องขอพร้อมกับ การล็อก DLMเมื่อกำหนด MDT ของไดเร็กทอรีสุดท้ายในพาธแล้ว การดำเนินการกับไดเร็กทอรีเพิ่มเติม (สำหรับไดเร็กทอรีที่ไม่ใช่แบบ striped) โดยปกติจะเกิดขึ้นบน MDT นั้น ซึ่งจะช่วยหลีกเลี่ยงการแย่งชิงทรัพยากรระหว่าง MDT ต่างๆ

สำหรับไดเร็กทอรีแบบแถบ DNE โครงสร้างต่อไดเร็กทอรีที่จัดเก็บไว้ในไดเร็กทอรีแม่จะให้ฟังก์ชันแฮชและรายการ FID ของไดเร็กทอรี MDT ที่กระจายไดเร็กทอรีนั้นไปLogical Metadata Volume (LMV) บนไคลเอ็นต์จะทำการแฮชชื่อไฟล์และแมปไปยังชาร์ด ไดเร็กทอรี MDT เฉพาะ ซึ่งจะจัดการการดำเนินการเพิ่มเติมกับไฟล์นั้นในลักษณะเดียวกันกับไดเร็กทอรีที่ไม่ใช่แบบแถบ สำหรับ การดำเนินการ readdir()รายการจากชาร์ดไดเร็กทอรีแต่ละอันจะถูกส่งกลับไปยังไคลเอ็นต์โดยเรียงลำดับตามลำดับแฮชของไดเร็กทอรี MDT ในเครื่อง และไคลเอ็นต์จะทำการเรียงลำดับแบบผสานเพื่อสลับชื่อไฟล์ตามลำดับแฮช เพื่อให้สามารถใช้คุกกี้ 64 บิตเดียวในการกำหนดออฟเซ็ตปัจจุบันภายในไดเร็กทอรีได้

ใน Lustre 2.15 ไคลเอนต์ LMV ใช้การจัดวางไดเร็กทอรีเริ่มต้นแบบ round-robin และสมดุลพื้นที่ เพื่อให้ไคลเอนต์สามารถใช้ MDT จำนวนมากในระบบไฟล์เดียวได้อย่างมีประสิทธิภาพมากขึ้น เมื่อมีการสร้างไดเร็กทอรีย่อยใหม่ใกล้กับรากของระบบไฟล์ (โดยค่าเริ่มต้นคือสามระดับไดเร็กทอรีบนสุด) ไคลเอนต์จะสร้างไดเร็กทอรีนั้นโดยอัตโนมัติเป็นไดเร็กทอรีระยะไกลบน MDT ที่ใช้งานได้ (เลือกตามลำดับ) เพื่อปรับสมดุลการใช้พื้นที่และโหลดระหว่างเซิร์ฟเวอร์ หากพื้นที่ว่างบน MDT ไม่สมดุล (ความแตกต่างระหว่างพื้นที่ว่างและ inode มากกว่า 5%) ไคลเอนต์ที่สร้างไดเร็กทอรีจะเลือกสร้างบน MDT ที่มีพื้นที่ว่างมากกว่าเพื่อคืนความสมดุล^{[ 90 ]}

ตัวจัดการการล็อกแบบกระจายของ Lustre (LDLM) ซึ่งใช้งานใน รูปแบบ OpenVMSช่วยปกป้องความสมบูรณ์ของข้อมูลและเมตาเดตาของแต่ละไฟล์ การเข้าถึงและการแก้ไขไฟล์ Lustre นั้นมีความสอดคล้องกันอย่างสมบูรณ์ในแคชระหว่างไคลเอนต์ทั้งหมด การล็อกเมตาเดตาได้รับการจัดการโดย MDT ซึ่งจัดเก็บinodeสำหรับไฟล์ โดยใช้ FID เป็นชื่อทรัพยากร การล็อกเมตาเดตาจะถูกแบ่งออกเป็นบิตแยกต่างหากที่ปกป้องการค้นหาไฟล์ (เจ้าของไฟล์และกลุ่ม สิทธิ์และโหมด และรายการควบคุมการเข้าถึง (ACL)) สถานะของ inode (ขนาดไดเร็กทอรี เนื้อหาไดเร็กทอรี จำนวนลิงก์ การประทับเวลา) เค้าโครง (การแบ่งไฟล์ ตั้งแต่ Lustre 2.4) และคุณลักษณะเพิ่มเติม (xattrs ตั้งแต่ Lustre 2.5) ไคลเอนต์สามารถดึงบิตการล็อกเมตาเดตาหลายบิตสำหรับ inode เดียวด้วยคำขอ RPC เดียว แต่ปัจจุบันจะได้รับสิทธิ์การล็อกแบบอ่านสำหรับ inode เท่านั้น MDS ทำหน้าที่จัดการการแก้ไขทั้งหมดที่เกิดขึ้นกับ inode เพื่อหลีกเลี่ยงการแย่งชิงทรัพยากร ล็อก และปัจจุบันเป็นโหนดเดียวที่ได้รับล็อกการเขียนบน inode

การล็อกข้อมูลไฟล์จะถูกจัดการโดย OST ซึ่งแต่ละอ็อบเจ็กต์ของไฟล์จะถูกแบ่งออกเป็นส่วนๆ โดยใช้การล็อกแบบช่วงไบต์ ไคลเอนต์สามารถได้รับการล็อกแบบช่วงการอ่านที่ทับซ้อนกันสำหรับส่วนใดส่วนหนึ่งหรือทั้งหมดของไฟล์ ทำให้สามารถอ่านไฟล์เดียวกันได้พร้อมกันหลายคน และ/หรือได้รับการล็อกแบบช่วงการเขียนที่ไม่ทับซ้อนกันสำหรับส่วนต่างๆ ของไฟล์ วิธีนี้ช่วยให้ไคลเอนต์ Lustre จำนวนมากสามารถเข้าถึงไฟล์เดียวพร้อมกันได้ทั้งการอ่านและการเขียน หลีกเลี่ยงปัญหาคอขวดระหว่างการอ่านเขียนไฟล์ ในทางปฏิบัติ เนื่องจากไคลเอนต์ Linux จัดการแคชข้อมูลในหน่วยของเพจไคลเอนต์จะร้องขอการล็อกที่มีขนาดเป็นจำนวนเต็มเท่าของขนาดเพจเสมอ (4096 ไบต์ในไคลเอนต์ส่วนใหญ่) เมื่อไคลเอนต์ร้องขอการล็อกแบบช่วง OST อาจให้การล็อกสำหรับช่วงที่ใหญ่กว่าที่ร้องขอไว้ในตอนแรก เพื่อลดจำนวนการร้องขอการล็อกที่ไคลเอนต์ทำ ขนาดจริงของการล็อกที่ได้รับจะขึ้นอยู่กับหลายปัจจัย รวมถึงจำนวนการล็อกที่ได้รับในปัจจุบันบนอ็อบเจ็กต์นั้น ว่ามีการล็อกการเขียนที่ขัดแย้งกันสำหรับช่วงการล็อกที่ร้องขอหรือไม่ และจำนวนการร้องขอการล็อกที่รอดำเนินการบนอ็อบเจ็กต์นั้น ขนาดของล็อกที่ได้รับอนุญาตจะไม่น้อยกว่าขอบเขตที่ร้องขอไว้แต่แรก ล็อกขอบเขต OST ใช้ Lustre FID ของวัตถุเป็นชื่อทรัพยากรสำหรับล็อก เนื่องจากจำนวนเซิร์ฟเวอร์ล็อกขอบเขตจะเพิ่มขึ้นตามจำนวน OST ในระบบไฟล์ ดังนั้นประสิทธิภาพการล็อกโดยรวมของระบบไฟล์และของไฟล์เดียวหากมีการกระจายข้อมูลไปยัง OST หลายตัวก็จะเพิ่มขึ้นตามไปด้วย

การสื่อสารระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ของ Lustre นั้นดำเนินการโดยใช้ Lustre Networking (LNet) ซึ่งเดิมทีนั้นอิงตามอินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชันเครือข่ายSandia Portals การจัดเก็บข้อมูลบนดิสก์เชื่อมต่อกับโหนดเซิร์ฟเวอร์ Lustre MDS และ OSS โดยใช้เทคโนโลยีการจัดเก็บข้อมูลแบบเชื่อมต่อโดยตรง ( NVM_Express#NVMe-oF , SAS , FC , iSCSI ) หรือ เทคโนโลยี เครือข่ายพื้นที่จัดเก็บข้อมูล แบบดั้งเดิม (SAN) ซึ่งเป็นอิสระจากเครือข่ายไคลเอ็นต์-เซิร์ฟเวอร์

LNet สามารถใช้เครือข่ายประเภททั่วไปได้หลายประเภท เช่นInfiniBandและEthernet ( ซ็อกเก็ต TCPบนพอร์ต 988) และช่วยให้สามารถใช้งานได้พร้อมกันในเครือข่ายหลายประเภทด้วยการกำหนดเส้นทางระหว่างกัน การเข้าถึงหน่วยความจำโดยตรงระยะไกล (RDMA) ใช้สำหรับการถ่ายโอนข้อมูลและเมตาเดต้าระหว่างโหนดเมื่อเครือข่ายพื้นฐานรองรับ เช่น InfiniBand Open Fabrics Enterprise Distribution (OFED Verbs), RoCEและOmni-Pathรวมถึงเครือข่ายความเร็วสูงที่เป็นกรรมสิทธิ์ เช่นCray Aries และ Gemini, Atos BullSequana eXascale Interconnect ( BXI ) และAmazon Web Services Elastic Fabric Adapter ( EFA ) คุณสมบัติความพร้อมใช้งานสูงและการกู้คืนช่วยให้สามารถกู้คืนได้อย่างโปร่งใสร่วมกับเซิร์ฟเวอร์สำรอง

ตั้งแต่ Lustre 2.10 คุณสมบัติ LNet Multi-Rail (MR) ^{[ 91 ]} อนุญาตให้รวมลิงก์ของอินเทอร์เฟซเครือข่ายสองรายการขึ้นไประหว่างไคลเอ็นต์และเซิร์ฟเวอร์เพื่อปรับปรุงแบนด์วิดท์ ประเภทอินเทอร์เฟซ LNet ไม่จำเป็นต้องเป็นประเภทเครือข่ายเดียวกัน ในเวอร์ชัน 2.12 Multi-Rail ได้รับการปรับปรุงเพื่อเพิ่มความทนทานต่อความผิดพลาดหากมีอินเทอร์เฟซเครือข่ายหลายรายการระหว่างคู่ค้า

LNet ให้ปริมาณงานแบบ end-to-end ผ่าน เครือข่าย Gigabit Ethernetเกิน 100  MB/s ^{[ 92 ]}ปริมาณงานสูงสุด 11  GB/s โดยใช้ลิงก์ InfiniBand enhanced data rate (EDR) และปริมาณงานมากกว่า 11  GB/s ผ่านอินเทอร์เฟซGigabit Ethernet 100 ^{[ 93 ]}

คุณสมบัติความพร้อมใช้งานสูงของระบบไฟล์ Lustre ประกอบด้วยกลไกการสลับการทำงานและการกู้คืนที่แข็งแกร่ง ทำให้การทำงานผิดพลาดและการรีบูตของเซิร์ฟเวอร์เป็นไปอย่างราบรื่น ความสามารถในการทำงานร่วมกันระหว่างเวอร์ชันย่อยที่ต่อเนื่องกันของซอฟต์แวร์ Lustre ช่วยให้สามารถอัปเกรดเซิร์ฟเวอร์ได้โดยการปิดเซิร์ฟเวอร์ (หรือสลับการทำงานไปยังเซิร์ฟเวอร์สำรอง) ดำเนินการอัปเกรด และเริ่มต้นใหม่ ในขณะที่งานที่ใช้งานอยู่ทั้งหมดจะยังคงทำงานต่อไป โดยจะมีเวลาหน่วงในขณะที่เซิร์ฟเวอร์สำรองเข้ามารับช่วงการจัดเก็บข้อมูล

ระบบไฟล์ Lustre MDS ถูกกำหนดค่าเป็นคู่แบบแอคทีฟ/พาสซีฟ โดยส่งออก MDT เดียว หรือเป็นคู่ MDS แบบแอคทีฟ/แอคทีฟหนึ่งคู่ขึ้นไป โดย DNE จะส่งออก MDT แยกกันสองชุดขึ้นไป ในขณะที่ระบบไฟล์ OSS มักจะถูกใช้งานในรูปแบบแอคทีฟ/แอคทีฟ โดยส่งออก OST แยกกัน เพื่อให้เกิดความซ้ำซ้อนโดยไม่เพิ่มภาระให้กับระบบ ในระบบไฟล์ที่มี MDT เดียว MDS สำรองสำหรับระบบไฟล์หนึ่งจะเป็น MGS และ/หรือโหนดตรวจสอบ หรือเป็น MDS แอคทีฟสำหรับระบบไฟล์อื่น ดังนั้นจึงไม่มีโหนดใดในคลัสเตอร์ที่ไม่ได้ใช้งาน

Lustre มีความสามารถในการจัดเก็บข้อมูลหลายระดับภายในเนมสเปซของระบบไฟล์เดียว โดยอนุญาตให้ฟังก์ชัน HSM แบบดั้งเดิมคัดลอก (เก็บถาวร) ไฟล์จากระบบไฟล์หลักไปยังระดับการจัดเก็บข้อมูลสำรอง ระดับการเก็บถาวรโดยทั่วไปจะเป็นระบบที่ใช้เทป ซึ่งมักจะมีแคชดิสก์อยู่ด้านหน้า เมื่อไฟล์ถูกเก็บถาวรแล้ว ก็สามารถปล่อยไฟล์นั้นออกจากระบบไฟล์หลักได้ โดยเหลือเพียงส่วนที่อ้างอิงถึงสำเนาที่เก็บถาวรไว้ หากมีการเปิดไฟล์ที่ถูกปล่อยออกมา ตัวประสานงานจะบล็อกการเปิด ส่งคำขอการกู้คืนไปยังเครื่องมือคัดลอก และดำเนินการเปิดให้เสร็จสมบูรณ์เมื่อเครื่องมือคัดลอกกู้คืนไฟล์เสร็จแล้ว

นอกเหนือจากการจัดลำดับชั้นการจัดเก็บข้อมูลภายนอกแล้ว ยังสามารถมีลำดับชั้นการจัดเก็บข้อมูลหลายระดับภายในเนมสเปซของระบบไฟล์เดียวได้อีกด้วย สามารถประกาศ OST ประเภทต่างๆ (เช่น HDD และ SSD) ในกลุ่มจัดเก็บข้อมูลที่มีชื่อได้ สามารถเลือกกลุ่ม OST ได้เมื่อระบุเค้าโครงไฟล์ และสามารถใช้กลุ่มต่างๆ ภายในเค้าโครงไฟล์ PFL เดียวกันได้ สามารถย้ายไฟล์ระหว่างลำดับชั้นการจัดเก็บข้อมูลได้ทั้งแบบด้วยตนเองหรือภายใต้การควบคุมของ Policy Engine ตั้งแต่ Lustre เวอร์ชัน 2.11 เป็นต้นไป ยังสามารถจำลองไฟล์ไปยังกลุ่ม OST ต่างๆ ด้วยเค้าโครงไฟล์ FLR ได้ เช่น เพื่อเตรียมไฟล์ลงในแฟลชสำหรับงานประมวลผล

HSM มีส่วนประกอบ Lustre เพิ่มเติมบางส่วนเพื่อจัดการอินเทอร์เฟซระหว่างระบบไฟล์หลักและไฟล์เก็บถาวร:

• ผู้ประสานงาน: รับคำขอจัดเก็บและกู้คืนข้อมูล และส่งต่อไปยังโหนดเอเจนต์
• เอเจนต์: เรียกใช้เครื่องมือคัดลอกเพื่อคัดลอกข้อมูลจากที่จัดเก็บหลักไปยังที่เก็บถาวร และในทางกลับกัน
• Copytool: จัดการการเคลื่อนย้ายข้อมูลและการอัปเดตเมตาเดต้า มี copytool ที่แตกต่างกันเพื่อเชื่อมต่อกับระบบจัดเก็บข้อมูลที่แตกต่างกัน มี copytool POSIX ทั่วไปสำหรับระบบจัดเก็บข้อมูลที่มีอินเทอร์เฟซส่วนหน้าคล้าย POSIX นอกจากนี้ยังมี copytool สำหรับ^High Performance Storage System ^{[ 94 ]} (HPSS), Tivoli Storage Manager ^{[ 95 ]} (TSM), Amazon S3 [ ^{96 ]}และGoogle Drive ^{[ 97 ]}
• เอ็นจิ้นนโยบาย: คอยตรวจสอบ Changelog ของระบบไฟล์เพื่อหาไฟล์ใหม่ที่จะเก็บถาวร ใช้นโยบายเพื่อปล่อยไฟล์ตามอายุหรือการใช้พื้นที่ และสื่อสารกับ MDT และ Coordinator เอ็นจิ้นนโยบายยังสามารถเรียกใช้งานต่างๆ เช่น การย้ายข้อมูลระหว่างกัน การล้างข้อมูล และการลบ เอ็นจิ้นนโยบายที่ใช้กันทั่วไปคือ RobinHood ^{[ 98 ]}แต่ก็สามารถใช้เอ็นจิ้นนโยบายอื่นๆ ได้เช่นกัน

HSM ยังกำหนดสถานะใหม่สำหรับไฟล์ต่างๆ รวมถึง: ^{[ 99 ]}

• มีอยู่: มีสำเนาบางส่วนอยู่ใน HSM ซึ่งอาจไม่สมบูรณ์
• เอกสารฉบับเต็มอยู่ในส่วนเก็บถาวรของ HSM
• สถานะผิดปกติ: ไฟล์ต้นฉบับถูกแก้ไขและแตกต่างจากไฟล์ที่จัดเก็บไว้
• เผยแพร่แล้ว: มี inode ที่เป็น stub อยู่ใน MDT แต่ข้อมูลอ็อบเจ็กต์ถูกลบออกไปแล้ว และมีสำเนาเพียงชุดเดียวอยู่ในไฟล์เก็บถาวร
• สูญหาย: สำเนาไฟล์ในคลังเก็บข้อมูลสูญหายและไม่สามารถกู้คืนได้
• ห้ามปล่อยไฟล์: ไฟล์นั้นไม่ควรถูกปล่อยออกจากระบบไฟล์
• ไม่ต้องเก็บถาวร: ไม่ควรเก็บไฟล์นี้ไว้ในที่เก็บถาวร

Lustre ถูกใช้โดยซู เปอร์คอมพิวเตอร์ TOP500 จำนวนมาก และไซต์มัลติคลัสเตอร์ขนาดใหญ่ ซูเปอร์คอมพิวเตอร์ 6 ใน 10 อันดับแรกและมากกว่า 60 ใน 100 อันดับแรกใช้ระบบไฟล์ Lustre ซึ่งรวมถึง ระบบไฟล์ Orion ขนาด 700PB 13 TB/s สำหรับซูเปอร์คอมพิวเตอร์ Frontierที่ห้องปฏิบัติการแห่งชาติ Oak Ridge ( ORNL) ^{[ 2 ] [ 100 ]} FugakuและK Computer ^{[ 11 ]}ที่สถาบันวิทยาศาสตร์การคำนวณขั้นสูงRIKEN Tianhe-1Aที่ศูนย์ซูเปอร์คอมพิวเตอร์แห่งชาติใน เทียนจิ นประเทศจีน LUMI ที่CSC Jaguar และTitanที่ ORNL Blue Watersที่มหาวิทยาลัยอิลลินอยส์และSequoiaและBlue Gene /L ที่ห้องปฏิบัติการแห่งชาติ Lawrence Livermore (LLNL)

นอกจากนี้ยังมีระบบไฟล์ Lustre ขนาดใหญ่ที่ศูนย์วิจัยการคำนวณทางวิทยาศาสตร์พลังงานแห่งชาติห้องปฏิบัติการแห่งชาติแปซิฟิกตะวันตกเฉียงเหนือศูนย์การคำนวณขั้นสูงของเท็กซัส^ห้องปฏิบัติการการคำนวณทางวิทยาศาสตร์แห่งชาติของบราซิล^{[ 101 ]}และNASA ^{[ 102 ]}ในอเมริกาเหนือ ในเอเชียที่สถาบันเทคโนโลยีโตเกียว [ ^{103 ] ใน}ยุโรปที่CEA [ ^{104 ] [ 105 ]}และอีกหลายแห่ง

การสนับสนุนทางเทคนิคเชิงพาณิชย์สำหรับ Lustre มักจะรวมอยู่ในระบบคอมพิวเตอร์หรือฮาร์ดแวร์จัดเก็บข้อมูลที่จำหน่ายโดยผู้ขาย ผู้ขายบางราย ได้แก่Hewlett-Packard (ในชื่อ HP StorageWorks Scalable File Share ตั้งแต่ปี 2004 ถึง 2008) ^{[ 106 ]} ATOS , Fujitsu ^{[ 107} ] ผู้ขายที่จำหน่ายฮาร์ดแวร์จัดเก็บข้อมูลพร้อมการสนับสนุน Lustre ที่รวมอยู่ในแพ็คเกจ ได้แก่Hitachi Data Systems (2012) ^{[ 108 ]} DataDirect Networks (DDN) ^{[ 109 ]} Aeon Computing ^และอื่นๆ นอกจากนี้ยังสามารถรับการสนับสนุนเฉพาะซอฟต์แวร์สำหรับระบบไฟล์ Lustre จากผู้ขายบางราย รวมถึง Whamcloud ได้อีกด้วย^{[ 110 ]}

Amazon Web Servicesเสนอ Amazon FSx สำหรับ Lustre ^{[ 111 ]}ซึ่งเป็นบริการที่มีการจัดการอย่างเต็มรูปแบบ ทำให้สามารถเปิดใช้งานและใช้งานระบบไฟล์ประสิทธิภาพสูงได้อย่างคุ้มค่าในระบบคลาวด์ของพวกเขา

Microsoft Azureนำเสนอ Azure Managed Lustre (AMLFS) ^{[ 112 ]} Azure Managed Lustre เป็นระบบไฟล์แบบจ่ายตามการใช้งานเต็มรูปแบบสำหรับการประมวลผลประสิทธิภาพสูง (HPC) และเวิร์กโหลด AI ในระบบคลาวด์

• รายชื่อระบบไฟล์ ส่วนระบบไฟล์แบบกระจายขนานที่ทนต่อความผิดพลาด

• Lustre บนGitHub