ระบบไฟล์ Linux สำหรับเซิร์ฟเวอร์ไฟล์ขนาดใหญ่

ฉันต้องการทราบจากผู้ที่มีประสบการณ์มากขึ้นสิ่งที่จะเป็นทางเลือกที่ดีที่สุดของระบบไฟล์เพื่อใช้สำหรับเซิร์ฟเวอร์ไฟล์ที่มีฮาร์ดดิสก์มากกว่า 20TB โดยส่วนตัวฉันมักใช้ EXT3 (ย้อนหลังไปหลายวัน) และ EXT4 (ตั้งแต่มีให้ใช้งาน) [และครั้งหนึ่ง ReiserFS 3 ถึงแม้ว่ามันจะทำให้ข้อมูลเสียหายจำนวนมาก] บนคอมพิวเตอร์ส่วนบุคคลของฉันและบนดิสก์ "บูตเซิร์ฟเวอร์" และ ROOT

อย่างไรก็ตามในฐานะที่เป็นเครื่องมือ EXT4 (แม้ว่าจะไม่ใช่ EXT4 ตัวเอง) จำกัด อยู่ที่ 16TB พาร์ทิชันนี่อาจไม่ใช่ทางออกที่ดีที่สุดของฉัน การแจกจ่ายจะเป็น Debian 6.0 (Squeeze) และ / หรือ Gentoo (เวอร์ชั่นล่าสุด) ดังนั้นเคอร์เนลควรจะค่อนข้างใหม่ล่าสุด (บน Debian อย่างน้อยกับ backport) หมายถึงเคอร์เนล linux> = 2.6.32

ไฟล์เซิร์ฟเวอร์จะถูกใช้เพื่อจุดประสงค์สาม maily (และแยกพาร์ติชันเช่นกันเพราะวัตถุประสงค์คือเพื่อรักษาข้อมูล "ปลอดภัย" และไม่สนใจค่าใช้จ่ายมากนัก) ดิสก์ทั้งหมดจะถูกเข้ารหัสโดยใช้ LUKS :

1. สื่อการดาวน์โหลดและที่เก็บเดเบียนท้องถิ่น [ฉันมีเครื่องอย่างน้อย 6 เครื่องที่ใช้ Debian]> 20TB (อาจแยกเพิ่มเติมระหว่างสื่อ, การดาวน์โหลดและที่เก็บ Debian)
2. ข้อมูล (เอกสาร, ภาพถ่าย, ... ) ~ 4TB SAFE (หมายถึง raid1 หรือ raid6 + ดิสก์สำรอง)
3. การสำรองข้อมูล> = 20 TB สำหรับการสำรองข้อมูลของคอมพิวเตอร์เครื่องอื่นใน gigabit lan ของฉัน (คุณสามารถแนะนำซอฟต์แวร์ที่สำรองข้อมูลทั้งระบบปฏิบัติการแม้ว่าจะเป็น Windows หรือไม่ก็ตาม BackupPC ระบุว่าเป็นตัวเลือกอื่น ๆ )

ความเร็วที่รวดเร็วนั้นไม่จำเป็นจริงๆ (การเข้าถึงพร้อมกัน: สูงสุด 2 หรือ 3 ไฟล์ขนาดใหญ่, พูดวิดีโอ) แม้ว่าจะเป็น "เพียง" 200MB / s อ่านจาก 10 HDD Raid6 ฉันสามารถอยู่กับมันได้

โดยสรุปฉันมองหาระบบไฟล์ที่เชื่อถือได้และปรับขนาดได้ (เช่นขยายได้ง่าย) ที่รองรับมากกว่า 20TB / พาร์ติชัน FS ที่ปลอดภัยและเชื่อถือได้ยิ่งดียิ่งขึ้น ฮาร์ดแวร์ที่ใช้จะต้องเป็น quad core อย่างน้อย (amd x4 630 หรือ intel i5-2500k) และ RAM มากมาย (> 8GB, อาจ> 16GB) ดังนั้นจึงควรปฏิบัติตามข้อกำหนดด้านฮาร์ดแวร์

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

ผู้คนจำนวนมากกำลังแนะนำ ZFS แต่ ZFS นั้นไม่สามารถใช้งานได้ใน Linux ยกเว้นผ่านฟิวส์ ฉันจะไม่แนะนำสิ่งนี้สำหรับสถานการณ์ของคุณที่ประสิทธิภาพมีความสำคัญ

น่าเสียดายที่ ZFS จะไม่สามารถใช้งานได้ในฐานะเคอร์เนลเนทีฟเว้นแต่ว่ามีปัญหาเรื่องใบอนุญาตถูกแยกออก

XFS ดี แต่มีบางคนรายงานปัญหาการทุจริตและฉันไม่สามารถแสดงความคิดเห็นได้ ฉันเล่นกับพาร์ติชัน XFS ขนาดเล็กและไม่มีปัญหาเหล่านี้ แต่ไม่ใช่ในการผลิต

ZFS มีข้อดีและคุณลักษณะที่มีประโยชน์มากเกินไปซึ่งไม่สามารถเพิกเฉยได้ โดยสรุปพวกเขาคือ (ดูZFS Wikiสำหรับคำอธิบายแบบเต็มของความหมาย):

• ความสมบูรณ์ของข้อมูล
• พูลหน่วยเก็บข้อมูล
• L2ARC
• ความจุสูง
• คัดลอกเมื่อเขียน
• สแนปชอต & โคลน
• การสตริปแบบไดนามิก
• ขนาดบล็อกแปรผัน
• การสร้างระบบไฟล์น้ำหนักเบา
• การจัดการแคช
• การปรับเปลี่ยน endianness
• การขจัดข้อมูลซ้ำซ้อน
• Encrypion

แล้วเราจะไปรอบ ๆ มันได้อย่างไร ทางเลือกที่แนะนำของเราซึ่งอาจจะเหมาะกับสถานการณ์ของคุณคือการพิจารณาNexenta นี่คือเคอร์เนล Open Solaris พร้อมกับเครื่องมือของผู้ใช้ GNU ที่ทำงานอยู่ด้านบน การมีเคอร์เนล Open Solaris หมายถึงการมี ZFS ให้ใช้งานจริง

คุณควรทดลองใช้ XFS ให้เหมาะสมกับความต้องการของคุณ:

XFS เป็นระบบไฟล์ 64 บิต สนับสนุนขนาดระบบไฟล์สูงสุด 8 exbibytes ลบหนึ่งไบต์แม้ว่าจะขึ้นอยู่กับข้อ จำกัด การบล็อกที่กำหนดโดยระบบปฏิบัติการโฮสต์ บนระบบ Linux 32 บิตสิ่งนี้ จำกัด ขนาดไฟล์และระบบไฟล์เป็น 16 tebibytes

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

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

แนวคิดทางเลือกคือเพียงใช้ ext3 ที่ปลอดภัยและน่าเบื่อยอมรับขีด จำกัด 16TB และแบ่งพาร์ติชันให้ดีขึ้นดังนั้นจึงไม่มีระบบไฟล์เดียวที่มีขนาดใหญ่

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

ไดรฟ์ดูด อาร์เรย์ RAID ดูด ระบบไฟล์ดูด ความล้มเหลวหลายอย่างเกิดขึ้น ฉันดีใจที่เห็นว่าคุณกำลังคิดเกี่ยวกับการสำรองข้อมูลอยู่แล้ว การเพิ่มจากความน่าเชื่อถือที่ดีไปจนถึงการจัดเก็บที่ดีนั้นต้องการมากกว่า RAID และไดรฟ์สำรองบางตัว ความซ้ำซ้อนมีค่าใช้จ่ายบางอย่างในทุกระดับและเงินสำหรับฮาร์ดแวร์กับความซับซ้อนของซอฟต์แวร์นั้นเป็นเรื่องยากที่จะนำทาง และดูการคาดการณ์ประสิทธิภาพของคุณ ในขณะที่อาร์เรย์ RAID อย่างที่คุณกำลังพิจารณาจะทำหลายร้อย MB / s ทั้งหมดที่ใช้คือผู้อ่านสองคนพร้อมกันที่ค้นหาดิสก์รอบ ๆ อย่างต่อเนื่อง ฉันสามารถบดขยี้อาร์เรย์ RAID10 ดิสก์ 24 ดิสก์ได้อย่างง่ายดายซึ่งจะให้ <5MB / s เทียบกับภาระงานมาตรฐานเท่านั้น สิ่งหนึ่งที่ช่วยให้มีเพื่อให้แน่ใจว่าคุณปรับแต่ง readahead ขึ้นถ้าผู้อ่านหลายสตรีมเป็นไปได้

การปรับใช้ ZFS โดยใช้ FreeBSD อาจเกิดขึ้นที่นี่โดยใช้gbdeสำหรับการเข้ารหัส ZFS ตัวเองจะเป็นผู้ให้บริการซอฟต์แวร์ RAID ผ่านRAIDZ ความซับซ้อนในการจัดการพื้นที่เก็บข้อมูลของการสร้าง zpools นั้นไม่แตกต่างจากสิ่งที่ Linux จะนำมาให้คุณด้วย mdadm และในบางกรณีจะง่ายกว่าจริง ๆ ZFS ครั้งแรกของฉันติดตั้ง (บน Solaris 10 ประมาณ 3 ปีที่แล้ว) มีระบบไฟล์ 17TB มากกว่า 48 ไดรฟ์ ฉันรอดพ้นจากความล้มเหลวหลายครั้งโดยไม่มีปัญหาเรียนรู้การจัดการ ZFS เมื่อฉันไป

ข้อได้เปรียบหลักคือการตรวจสอบของ ZFS นั้นให้การตรวจจับข้อผิดพลาดที่ดีกว่า Linux ซึ่งเป็นวิธีการป้องกันฮาร์ดแวร์ที่มีมูลค่าไม่ดี ข้อเสียหลักอยู่ที่ FreeBSD ซึ่งเป็นที่นิยมน้อยกว่า คุณยังไม่รู้วิธีจัดการมันการสนับสนุนฮาร์ดแวร์นั้นอ่อนแอกว่าลินุกซ์เล็กน้อยและเนื่องจากเป็นแพลตฟอร์มที่ได้รับความนิยมน้อยกว่าจึงไม่มีคนจำนวนมากที่ขอความช่วยเหลือหากคุณประสบปัญหา

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

จากหน้าเปรียบเทียบระบบไฟล์ของวิกิพีเดียมีระบบไฟล์ที่โดดเด่นมากมายที่เหมาะกับความต้องการของคุณเช่น JFS, XFS, UDF, ZFS, GPFS และ Btrfs เพียงคลิกขนาดไฟล์สูงสุดเพื่อจัดเรียงและเลือกไฟล์ที่อนุมัติที่สุด