หลังจากการพัฒนาที่เงียบงันมานานหนึ่งปี ทำงานในสาขาใหม่ของระบบไฟล์แบบกระจายที่ทนทานต่อข้อผิดพลาด и ผู้สมัครรุ่นที่สอง ล่าสุด การเปลี่ยนแปลงเจ้าของบริษัทที่กำลังพัฒนา LizardFS มีการนำการจัดการใหม่มาใช้ และนักพัฒนาถูกแทนที่ ในช่วงสองปีที่ผ่านมา โครงการนี้ได้ถูกถอนออกจากชุมชนและไม่ได้ให้ความสนใจมากพอ แต่ทีมงานใหม่ตั้งใจที่จะรื้อฟื้นความสัมพันธ์ก่อนหน้านี้กับชุมชนและสร้างปฏิสัมพันธ์อย่างใกล้ชิดกับชุมชน รหัสโครงการเขียนด้วยภาษา C และ C++ และ ภายใต้ใบอนุญาต GPLv3
จิ้งจก FS ระบบไฟล์คลัสเตอร์แบบกระจาย ซึ่งช่วยให้คุณสามารถกระจายข้อมูลไปยังเซิร์ฟเวอร์ต่างๆ ได้ แต่ให้การเข้าถึงข้อมูลเหล่านั้นในรูปแบบของพาร์ติชันขนาดใหญ่เพียงพาร์ติชันเดียว ซึ่งทำงานในลักษณะเดียวกันกับพาร์ติชันดิสก์แบบเดิม พาร์ติชันที่ติดตั้งด้วย LizardFS รองรับคุณลักษณะของไฟล์ POSIX, ACL, ล็อค, ซ็อกเก็ต, ไปป์, ไฟล์อุปกรณ์, ลิงก์สัญลักษณ์และฮาร์ดลิงก์ ระบบไม่มีจุดขัดข้องเพียงจุดเดียว ส่วนประกอบทั้งหมดซ้ำซ้อน รองรับการดำเนินการข้อมูลแบบขนาน (ไคลเอนต์หลายรายสามารถเข้าถึงไฟล์พร้อมกัน)
เพื่อให้มั่นใจถึงความทนทานต่อข้อผิดพลาด ข้อมูลจะถูกแบ่งออกเป็นแบบจำลองซึ่งกระจายไปตามโหนดต่างๆ โดยมีความซ้ำซ้อน (สำเนาหลายชุดถูกวางไว้บนโหนดที่แตกต่างกัน) หากโหนดหรือไดรฟ์ล้มเหลว ระบบจะยังคงทำงานต่อไปโดยไม่สูญเสียข้อมูลและจะแจกจ่ายข้อมูลโดยอัตโนมัติ โดยคำนึงถึงโหนดที่เหลือ หากต้องการขยายพื้นที่เก็บข้อมูล ก็เพียงพอที่จะเชื่อมต่อโหนดใหม่เข้ากับโหนดโดยไม่หยุดการทำงานเพื่อการบำรุงรักษา (ระบบจะจำลองข้อมูลบางส่วนไปยังเซิร์ฟเวอร์ใหม่และปรับสมดุลพื้นที่เก็บข้อมูลโดยคำนึงถึงเซิร์ฟเวอร์ใหม่) คุณสามารถทำเช่นเดียวกันเพื่อลดขนาดของคลัสเตอร์ - คุณสามารถปิดการใช้งานอุปกรณ์ล้าสมัยที่ถูกลบออกจากระบบได้
ข้อมูลและข้อมูลเมตาจะถูกจัดเก็บแยกกัน สำหรับการดำเนินการ ขอแนะนำให้ติดตั้งเซิร์ฟเวอร์ข้อมูลเมตาสองตัวที่ทำงานในโหมดมาสเตอร์-สเลฟ รวมถึงเซิร์ฟเวอร์จัดเก็บข้อมูลอย่างน้อยสองตัว (เซิร์ฟเวอร์ chunk) นอกจากนี้ ในการสำรองข้อมูลเมตาดาต้า เซิร์ฟเวอร์บันทึกสามารถใช้เพื่อจัดเก็บข้อมูลเกี่ยวกับการเปลี่ยนแปลงในข้อมูลเมตา และช่วยให้คุณสามารถกู้คืนการดำเนินการในกรณีที่เกิดความเสียหายต่อเซิร์ฟเวอร์เมตาดาต้าที่มีอยู่ทั้งหมด แต่ละไฟล์แบ่งออกเป็นบล็อก (ชิ้น) ขนาดสูงสุด 64 MB บล็อกถูกกระจายไปยังเซิร์ฟเวอร์จัดเก็บข้อมูลตามโหมดการจำลองแบบที่เลือก: มาตรฐาน (การกำหนดจำนวนสำเนาที่ชัดเจนที่จะวางบนโหนดที่แตกต่างกัน รวมถึงที่เกี่ยวข้องกับแต่ละไดเร็กทอรี - สำหรับข้อมูลสำคัญ สามารถเพิ่มจำนวนสำเนาได้ และสำหรับ ข้อมูลไม่สำคัญลดลง), XOR (RAID5 ) และ EC (RAID6)
พื้นที่เก็บข้อมูลสามารถขยายได้ถึงขนาดเพตะไบต์ ขอบเขตการใช้งานประกอบด้วยการเก็บถาวร การจัดเก็บอิมเมจเครื่องเสมือน ข้อมูลมัลติมีเดีย การสำรองข้อมูล ใช้เป็น DRC (Disaster Recovery Center) และเป็นที่จัดเก็บข้อมูลในคลัสเตอร์การประมวลผลประสิทธิภาพสูง LizardFS ให้ความเร็วในการอ่านที่สูงมากสำหรับไฟล์ทุกขนาด และเมื่อเขียน จะแสดงประสิทธิภาพที่ดีเมื่อเขียนไฟล์ขนาดใหญ่และขนาดกลางทั้งหมด เมื่อไม่มีการแก้ไขอย่างต่อเนื่อง การทำงานอย่างเข้มข้นกับไฟล์ที่เปิดอยู่ และการดำเนินการครั้งเดียวกับ ไฟล์เล็กๆ มากมาย
ในบรรดาคุณสมบัติของ FS เรายังสามารถสังเกตได้ว่ามีการรองรับสแน็ปช็อตซึ่งสะท้อนถึงสถานะของไฟล์ ณ เวลาหนึ่งและการใช้งาน "ถังรีไซเคิล" ในตัว (ไฟล์จะไม่ถูกลบทันทีและพร้อมใช้งานสำหรับ ฟื้นตัวได้ระยะหนึ่ง) การเข้าถึงพาร์ติชันอาจถูกจำกัดด้วยที่อยู่ IP หรือรหัสผ่าน (คล้ายกับ NFS) มีกลไกการจัดการโควต้าและคุณภาพของบริการที่ช่วยให้คุณสามารถจำกัดขนาดและแบนด์วิดท์สำหรับผู้ใช้บางประเภทได้ เป็นไปได้ที่จะสร้างสถานที่จัดเก็บข้อมูลแบบกระจายตามพื้นที่ทางภูมิศาสตร์ ซึ่งส่วนต่างๆ จะตั้งอยู่ในศูนย์ข้อมูลที่แตกต่างกัน
โครงการ LizardFS ก่อตั้งขึ้นในปี 2013 โดยเป็นทางแยก และแตกต่างกันโดยหลักเมื่อมีโหมดการจำลองแบบตามรหัสแก้ไขข้อผิดพลาด Reed-Solomon (คล้ายกับ raidzN), การสนับสนุน ACL แบบขยาย, การมีอยู่ของไคลเอนต์สำหรับแพลตฟอร์ม Windows, การเพิ่มประสิทธิภาพเพิ่มเติม (ตัวอย่างเช่น เมื่อรวมไคลเอนต์และ เซิร์ฟเวอร์จัดเก็บข้อมูล บล็อก (ถ้าเป็นไปได้) จะถูกส่งไปพร้อมกับโหนดปัจจุบัน และข้อมูลเมตาจะถูกแคชไว้ในหน่วยความจำ) ระบบการกำหนดค่าที่ยืดหยุ่นมากขึ้น รองรับการอ่านข้อมูลล่วงหน้า โควต้าไดเรกทอรี และการทำงานซ้ำภายใน
LizardFS 3.13.0 มีกำหนดเปิดตัวปลายเดือนธันวาคม นวัตกรรมหลักของ LizardFS 3.13 คือการใช้อัลกอริธึมที่เป็นเอกฉันท์เพื่อให้แน่ใจว่าทนทานต่อข้อผิดพลาด (การสลับเซิร์ฟเวอร์หลักในกรณีที่เกิดความล้มเหลว) (ใช้การใช้งาน uRaft ของเราเอง ซึ่งก่อนหน้านี้เคยใช้ในผลิตภัณฑ์เชิงพาณิชย์) การใช้ uRaft ช่วยลดความยุ่งยากในการกำหนดค่าและลดความล่าช้าในการกู้คืนความล้มเหลว แต่ต้องมีโหนดทำงานอย่างน้อยสามโหนด โดยหนึ่งในนั้นใช้สำหรับองค์ประชุม
การเปลี่ยนแปลงอื่นๆ: ไคลเอนต์ใหม่ที่ใช้ระบบย่อย FUSE3 การแก้ปัญหาด้วยการแก้ไขข้อผิดพลาด ปลั๊กอิน nfs-ganesha ได้รับการเขียนใหม่ในภาษา C อัปเดต 3.13.0-rc2 แก้ไขข้อบกพร่องสำคัญหลายประการที่ทำให้การทดสอบรุ่นก่อนหน้าของสาขา 3.13 ไม่สามารถใช้งานได้ (การแก้ไขสำหรับสาขา 3.12 ยังไม่ได้เผยแพร่ และการอัปเดตจาก 3.12 ถึง 3.13 ยังคงทำให้ข้อมูลสูญหายโดยสิ้นเชิง)
ในปี 2020 งานจะเน้นการพัฒนา
ซึ่งเป็นเคอร์เนล LizardFS ที่เขียนใหม่ทั้งหมด ซึ่งตามที่นักพัฒนาระบุไว้ จะให้ประสิทธิภาพเพิ่มขึ้นสามเท่าเมื่อเทียบกับสาขา 3.12 Agama จะเปลี่ยนไปใช้สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ ซึ่งอิงตามอินพุต/เอาท์พุตแบบอะซิงโครนัส ทำงานในพื้นที่ผู้ใช้เป็นหลัก (เพื่อลดการพึ่งพากลไกการแคชเคอร์เนล) นอกจากนี้ จะมีการเสนอระบบย่อยการดีบักใหม่และตัววิเคราะห์กิจกรรมเครือข่ายที่รองรับการปรับแต่งประสิทธิภาพอัตโนมัติ
ไคลเอนต์ LizardFS จะเพิ่มการรองรับเต็มรูปแบบสำหรับการดำเนินการเขียนการกำหนดเวอร์ชัน ซึ่งจะปรับปรุงความน่าเชื่อถือของการกู้คืนความเสียหาย แก้ปัญหาที่เกิดขึ้นเมื่อไคลเอนต์ที่แตกต่างกันแชร์การเข้าถึงข้อมูลเดียวกัน และช่วยให้มีการปรับปรุงประสิทธิภาพที่สำคัญ ไคลเอนต์จะถูกถ่ายโอนไปยังระบบย่อยเครือข่ายของตนเองที่ทำงานในพื้นที่ผู้ใช้ ต้นแบบการทำงานชุดแรกของ LizardFS ที่ใช้ Agama มีแผนที่จะพร้อมใช้งานในไตรมาสที่สองของปี 2020 ในเวลาเดียวกัน พวกเขาสัญญาว่าจะใช้เครื่องมือสำหรับการบูรณาการ LizardFS เข้ากับแพลตฟอร์ม Kubernetes
ที่มา: opennet.ru