สรุป
ความเสี่ยงในการใช้ LVM:
- ช่องโหว่ในการเขียนปัญหาการแคชด้วย SSD หรือ VM hypervisor
- กู้คืนข้อมูลได้ยากขึ้นเนื่องจากโครงสร้างบนดิสก์ที่ซับซ้อนกว่า
- ปรับขนาดระบบไฟล์ได้ยากขึ้น
- ภาพสแนปชอตนั้นยากต่อการใช้งานช้าและบั๊ก
- ต้องใช้ทักษะบางอย่างในการกำหนดค่าอย่างถูกต้องเนื่องจากปัญหาเหล่านี้
ปัญหา LVM สองรายการแรกนั้นรวมกัน: หากการเขียนแคชไม่ทำงานอย่างถูกต้องและคุณสูญเสียพลังงาน (เช่น PSU หรือ UPS ล้มเหลว) คุณอาจต้องกู้คืนจากการสำรองข้อมูลซึ่งหมายถึงการหยุดทำงานที่สำคัญ เหตุผลสำคัญสำหรับการใช้ LVM คือสถานะการออนไลน์ที่สูงขึ้น (เมื่อเพิ่มดิสก์การปรับขนาดระบบไฟล์ ฯลฯ ) แต่สิ่งสำคัญคือการตั้งค่าการเขียนแคชให้ถูกต้องเพื่อหลีกเลี่ยง LVM จริงลดเวลาทำงาน
- อัปเดตเมื่อธันวาคม 2561: อัพเดตสแนปชอตของวัสดุรวมถึงความเสถียรของ ZFS และ btrfs เป็นทางเลือกแทนสแนปชอตของ LVM
การลดความเสี่ยง
LVM ยังคงทำงานได้ดีหากคุณ:
- รับการตั้งค่าแคชการเขียนของคุณในไฮเปอร์ไวเซอร์เคอร์เนลและ SSD
- หลีกเลี่ยงภาพรวม LVM
- ใช้ LVM เวอร์ชันล่าสุดเพื่อปรับขนาดระบบไฟล์
- มีการสำรองข้อมูลที่ดี
รายละเอียด
ฉันเคยวิจัยเรื่องนี้มาบ้างแล้วในอดีตที่เคยประสบกับข้อมูลสูญหายที่เกี่ยวข้องกับ LVM ความเสี่ยงและปัญหา LVM หลักที่ฉันทราบคือ:
ช่องโหว่ในการเขียนแคชฮาร์ดดิสก์เนื่องจาก VM hypervisors, การแคชดิสก์หรือเคอร์เนล Linux เก่าและทำให้การกู้คืนข้อมูลยากขึ้นเนื่องจากโครงสร้างบนดิสก์ที่ซับซ้อนยิ่งขึ้น - ดูรายละเอียดด้านล่าง ฉันได้เห็นการตั้งค่า LVM ที่สมบูรณ์ในดิสก์หลายตัวได้รับความเสียหายโดยไม่มีโอกาสในการกู้คืนใด ๆ และ LVM พร้อมการแคชการเขียนฮาร์ดดิสก์เป็นการรวมกันที่เป็นอันตราย
- การเขียนแคชและเขียนการสั่งซื้อใหม่โดยฮาร์ดไดรฟ์มีความสำคัญต่อประสิทธิภาพที่ดี แต่อาจล้มเหลวในการล้างบล็อกในดิสก์อย่างถูกต้องเนื่องจาก VM hypervisors, ฮาร์ดไดรฟ์เขียนแคช, เคอร์เนล Linux เก่าเป็นต้น
- อุปสรรคในการเขียนหมายถึงเคอร์เนลรับประกันว่าจะเสร็จสิ้นการเขียนดิสก์บางอย่างก่อนการเขียนดิสก์ "barrier" เพื่อให้แน่ใจว่าระบบไฟล์และ RAID สามารถกู้คืนได้ในกรณีที่ไฟฟ้าดับหรือเกิดความผิดพลาดฉับพลัน อุปสรรคดังกล่าวสามารถใช้การดำเนินการFUA (การเข้าถึงหน่วยกำลังงาน)เพื่อเขียนบล็อกบางอย่างลงในดิสก์ได้ทันทีซึ่งมีประสิทธิภาพมากกว่าการล้างแคชแบบเต็ม ปัญหาและอุปสรรคที่สามารถใช้ร่วมกับประสิทธิภาพที่ติดแท็ก / พื้นเมืองคำสั่งเข้าคิว (ออกดิสก์หลายร้องขอ I / O ในครั้งเดียว) เพื่อเปิดใช้ฮาร์ดไดรฟ์ที่จะดำเนินการเขียนอัจฉริยะใหม่สั่งซื้อโดยไม่มีความเสี่ยงที่เพิ่มขึ้นของการสูญเสียข้อมูล
- VM hypervisorsสามารถมีปัญหาที่คล้ายกัน: การเรียกใช้ LVM ใน Linux guest ที่ด้านบนของ VM hypervisor เช่น VMware, Xen , KVM, Hyper-V หรือ VirtualBox สามารถสร้างปัญหาที่คล้ายกันกับเคอร์เนลได้โดยไม่ต้องเขียนอุปสรรคเนื่องจากเขียนแคชและเขียนใหม่ -ordering ตรวจสอบเอกสารประกอบไฮเปอร์ไวเซอร์ของคุณอย่างละเอียดเพื่อหาตัวเลือก "ล้างดิสก์" หรือเขียนผ่าน (มีอยู่ในKVM , VMware , Xen , VirtualBoxและอื่น ๆ ) - และทดสอบด้วยการตั้งค่าของคุณ ไฮเปอร์ไวเซอร์บางตัวเช่น VirtualBox มีการตั้งค่าเริ่มต้นซึ่งจะไม่สนใจดิสก์ใด ๆ จากแขก
- เซิร์ฟเวอร์องค์กรที่มี LVM ควรใช้ตัวควบคุม RAID ที่สำรองแบตเตอรี่และปิดใช้งานแคชการเขียนฮาร์ดดิสก์ (ตัวควบคุมมีแคชการเขียนสำรองแบตเตอรี่ซึ่งรวดเร็วและปลอดภัย) - ดูความคิดเห็นนี้โดยผู้เขียนรายการคำถามที่พบบ่อย XFSนี้ มันอาจจะปลอดภัยที่จะปิดการเขียนอุปสรรคในเคอร์เนล แต่แนะนำให้ทำการทดสอบ
- หากคุณไม่มีตัวควบคุม RAID ที่สำรองแบตเตอรี่การปิดใช้งานการแคชการเขียนฮาร์ดไดรฟ์จะทำให้การเขียนช้าลงอย่างมาก แต่ทำให้ LVM ปลอดภัย คุณควรใช้
data=orderedตัวเลือกext3 (หรือdata=journalเพื่อความปลอดภัยเป็นพิเศษ) รวมทั้งbarrier=1เพื่อให้แน่ใจว่าการแคชเคอร์เนลไม่ส่งผลกระทบต่อความสมบูรณ์ (หรือใช้ ext4 ซึ่งเปิดใช้งานสิ่งกีดขวางโดยค่าเริ่มต้น ) นี่เป็นตัวเลือกที่ง่ายที่สุดและให้ความสมบูรณ์ของข้อมูลที่ดีในราคาที่คุ้มค่า (ลีนุกซ์เปลี่ยนตัวเลือก ext3 เริ่มต้นเป็นอันตรายไปdata=writebackอีกสักพักดังนั้นอย่าพึ่งพาการตั้งค่าเริ่มต้นสำหรับ FS)
- หากต้องการปิดใช้งานการเขียนแคชฮาร์ดไดรฟ์ : เพิ่ม
hdparm -q -W0 /dev/sdXสำหรับไดรฟ์ทั้งหมดใน/etc/rc.local(สำหรับ SATA) หรือใช้ sdparm สำหรับ SCSI / SAS อย่างไรก็ตามตามรายการใน XFS FAQ (ซึ่งดีมากในหัวข้อนี้) ไดรฟ์ SATA อาจลืมการตั้งค่านี้หลังจากการกู้คืนข้อผิดพลาดของไดรฟ์ - ดังนั้นคุณควรใช้ SCSI / SAS หรือถ้าคุณต้องใช้ SATA แล้วใส่ คำสั่ง hdparm ในงาน cron รันทุก ๆ นาที
- เพื่อให้ SSD / ฮาร์ดไดรฟ์เขียนแคชเปิดใช้งานเพื่อประสิทธิภาพที่ดีขึ้น: นี่คือพื้นที่ที่ซับซ้อน - ดูส่วนด้านล่าง
- หากคุณใช้ไดรฟ์ฟอร์แมทขั้นสูงเช่น 4 KB ฟิสิคัลเซกเตอร์โปรดดูด้านล่าง - การปิดใช้งานการแคชการเขียนอาจมีปัญหาอื่น
- UPSมีความสำคัญสำหรับทั้งองค์กรและ SOHO แต่ไม่เพียงพอที่จะทำให้ LVM ปลอดภัย: สิ่งใดก็ตามที่ทำให้เกิดความผิดพลาดอย่างหนักหรือการสูญเสียพลังงาน (เช่นความล้มเหลวของ UPS, ความล้มเหลวของ PSU หรือการสิ้นเปลืองแบตเตอรี่แล็ปท็อป)
- เคอร์เนล Linux เก่ามาก (2.6.x จาก 2009) : มีการรองรับการเขียนกั้นที่ไม่สมบูรณ์ในเคอร์เนลรุ่นเก่ามาก, 2.6.32 และรุ่นก่อนหน้า ( 2.6.31 มีการสนับสนุนบางส่วนในขณะที่2.6.33 ใช้ได้กับเป้าหมายอุปกรณ์ทุกประเภท) - RHEL 6 ใช้ 2.6.32กับแพตช์มากมาย หากเคอร์เนลเก่า 2.6 เหล่านี้ไม่ได้รับการแก้ไขสำหรับปัญหาเหล่านี้เมตาดาต้า FS จำนวนมาก (รวมถึงวารสาร) อาจสูญหายได้เนื่องจากความผิดพลาดอย่างหนักซึ่งทำให้ข้อมูลในบัฟเฟอร์การเขียนฮาร์ดไดรฟ์ (32 MB ต่อไดรฟ์สำหรับไดรฟ์ SATA ทั่วไป) การสูญเสียข้อมูลเมตาดาต้า FS และข้อมูลเจอร์นัลที่เขียนไปล่าสุด 32MB ซึ่งเคอร์เนลคิดว่ามีอยู่ในดิสก์อยู่แล้วมักจะหมายถึงความเสียหายของ FS จำนวนมากและทำให้ข้อมูลสูญหาย
- สรุป:คุณต้องระมัดระวังในระบบไฟล์, RAID, VM hypervisor และการตั้งค่าฮาร์ดไดรฟ์ / SSD ที่ใช้กับ LVM คุณต้องมีการสำรองข้อมูลที่ดีมากหากคุณใช้ LVM และต้องสำรองข้อมูลเมตาดาต้า LVM โดยเฉพาะการตั้งค่าฟิสิคัลพาร์ติชัน MBR และบูตเซกเตอร์สำหรับโวลุ่ม นอกจากนี้ยังแนะนำให้ใช้ไดรฟ์ SCSI / SAS เนื่องจากมีโอกาสน้อยที่จะโกหกเกี่ยวกับวิธีการเขียนแคช - ต้องใช้ความระมัดระวังมากขึ้นในการใช้ไดรฟ์ SATA
การเปิดใช้งานการแคชการเขียนไว้เพื่อประสิทธิภาพ (และการรับมือกับไดรฟ์ที่วางอยู่)
ตัวเลือกที่ซับซ้อนยิ่งขึ้น แต่มีประสิทธิภาพคือการเปิดใช้งานการแคชการเขียน SSD / ฮาร์ดไดรฟ์และพึ่งพาการเขียนเคอร์เนลที่ทำงานกับ LVM บนเคอร์เนล 2.6.33+ (ตรวจสอบซ้ำโดยการค้นหาข้อความ "สิ่งกีดขวาง" ในบันทึก)
คุณควรตรวจสอบให้แน่ใจว่าการตั้งค่า RAID, การตั้งค่า VM hypervisor และระบบไฟล์ใช้อุปสรรคการเขียน (เช่นต้องการไดรฟ์เพื่อล้างการเขียนที่รอดำเนินการก่อนและหลังคีย์เมทาดาทา / เจอร์นัลเขียน) XFS จะใช้สิ่งกีดขวางเป็นค่าเริ่มต้น แต่ ext3 ไม่ได้ดังนั้นด้วย ext3 คุณควรใช้barrier=1ในตัวเลือกการเมานท์และยังคงใช้data=orderedหรือdata=journalตามข้างบน
- แต่น่าเสียดายที่บางฮาร์ดดิสก์และ SSDs โกหกเกี่ยวกับว่าพวกเขาได้ล้างแคชของพวกเขาจริงๆไปยังดิสก์ (ไดรฟ์โดยเฉพาะอย่างยิ่งเก่า แต่รวมถึงบางส่วนไดรฟ์ SATA และบาง SSDs องค์กร ) - รายละเอียดเพิ่มเติมได้ที่นี่ มีเป็นบทสรุปที่ดีจากนักพัฒนา XFS
- มีเครื่องมือทดสอบอย่างง่ายสำหรับการวางไดรฟ์ (สคริปต์ Perl) หรือดูพื้นหลังนี้ด้วยการทดสอบเครื่องมืออื่นสำหรับการสั่งซื้อการเขียนซ้ำอันเป็นผลมาจากแคชไดรฟ์ คำตอบนี้ครอบคลุมถึงการทดสอบที่คล้ายกันของไดรฟ์ SATA ที่เปิดปัญหาการเขียนกั้นในซอฟต์แวร์ RAID - การทดสอบเหล่านี้ใช้หน่วยเก็บข้อมูลทั้งหมด
- ไดรฟ์ SATA ล่าสุดที่สนับสนุนNative Command Queuing (NCQ) อาจมีแนวโน้มที่จะโกหกน้อยลงหรืออาจทำงานได้ดีโดยไม่ต้องเขียนแคชเนื่องจาก NCQ และไดรฟ์จำนวนน้อยมากที่ไม่สามารถปิดใช้งานการเขียนแคช
- โดยทั่วไปแล้วไดรฟ์ SCSI / SAS นั้นใช้งานได้เนื่องจากไม่จำเป็นต้องเขียนแคชเพื่อให้ทำงานได้ดี (ผ่าน SCSI Tagged Command Queuingคล้ายกับ SATA ของ NCQ)
- หากฮาร์ดไดรฟ์หรือ SSD ของคุณโกหกเกี่ยวกับการล้างแคชไปยังดิสก์คุณจะไม่สามารถพึ่งพาอุปสรรคการเขียนและต้องปิดใช้งานการเขียนแคช นี่เป็นปัญหาสำหรับระบบไฟล์ฐานข้อมูลตัวจัดการโวลุ่มและRAID ซอฟต์แวร์ทั้งหมดไม่ใช่แค่ LVM
SSDมีปัญหาเนื่องจากการใช้แคชการเขียนมีความสำคัญกับอายุการใช้งานของ SSD วิธีที่ดีที่สุดคือใช้ SSD ที่มีตัวเก็บประจุ supercapacitor (เพื่อเปิดใช้งานการล้างแคชเมื่อเกิดไฟฟ้าขัดข้องและด้วยเหตุนี้จึงทำให้แคชไม่สามารถเขียนซ้ำได้
การตั้งค่าไดรฟ์ฟอร์แมตฟอร์แมตขั้นสูง - การเขียนแคชการจัดตำแหน่ง RAID, GPT
- ด้วยไดรฟ์รูปแบบขั้นสูงที่ใหม่กว่าซึ่งใช้เซกเตอร์กายภาพ 4 KiB อาจเป็นเรื่องสำคัญที่จะต้องเปิดใช้งานแคชการเขียนไดรฟ์ไว้เนื่องจากปัจจุบันไดรฟ์ส่วนใหญ่จำลองแบบเซกเตอร์ตรรกะ 512 ไบต์ ( "512 emulation" ) และบางคนก็อ้างว่า ภาคในขณะที่ใช้ 4 KiB จริงๆ
- การปิดการเขียนแคชของไดรฟ์ฟอร์แมตขั้นสูงอาจส่งผลกระทบต่อประสิทธิภาพการทำงานขนาดใหญ่มากหากแอปพลิเคชัน / เคอร์เนลทำการเขียน 512 ไบต์เนื่องจากไดรฟ์ดังกล่าวต้องใช้แคชเพื่อสะสม 8 x 512- ไบต์ก่อนที่จะทำการเขียน เขียน. แนะนำให้ทำการทดสอบเพื่อยืนยันผลกระทบใด ๆ หากคุณปิดการใช้งานแคช
- การจัดแนว LVs ในขอบเขต 4 KiBนั้นมีความสำคัญต่อประสิทธิภาพ แต่ควรเกิดขึ้นโดยอัตโนมัติตราบใดที่พาร์ทิชันพื้นฐานสำหรับ PV นั้นสอดคล้องกันเนื่องจาก LVM Physical Extents (PEs) เป็น 4 MiB โดยค่าเริ่มต้น ต้องพิจารณา RAID ที่นี่ - หน้าการตั้งค่า RAID แบบ LVM และซอฟต์แวร์นี้แนะนำให้วาง RAID superblock ที่ส่วนท้ายของโวลุ่มและ (หากจำเป็น) โดยใช้ตัวเลือกใน
pvcreateการจัดแนว PV เธรดรายการอีเมล LVM นี้ชี้ไปที่งานที่ทำในเมล็ดในช่วงปี 2011 และปัญหาของการเขียนบล็อกบางส่วนเมื่อผสมดิสก์ที่มี 512 ไบต์และ 4 ภาค KiB ใน LV เดียว
- การแบ่งพาร์ติชัน GPT ด้วยรูปแบบขั้นสูงจำเป็นต้องได้รับการดูแลเป็นพิเศษโดยเฉพาะอย่างยิ่งสำหรับบูต + ดิสก์รูท
กู้คืนข้อมูลได้ยากขึ้นเนื่องจากโครงสร้างบนดิสก์ที่ซับซ้อนกว่า :
- การกู้คืนข้อมูล LVM ใด ๆ ที่ต้องการหลังจากเกิดความผิดพลาดอย่างหนักหรือการสูญเสียพลังงาน (เนื่องจากการแคชการเขียนที่ไม่ถูกต้อง) เป็นกระบวนการที่ดีที่สุดเนื่องจากไม่มีเครื่องมือที่เหมาะสม LVM นั้นดีสำหรับการสำรองข้อมูลเมตาของมัน
/etc/lvmซึ่งสามารถช่วยคืนค่าโครงสร้างพื้นฐานของ LVs, VGs และ PV แต่จะไม่ช่วยเมตาดาต้าระบบไฟล์ที่สูญหาย
- ดังนั้นการคืนค่าจากการสำรองข้อมูลทั้งหมดจึงเป็นสิ่งจำเป็น สิ่งนี้เกี่ยวข้องกับการหยุดทำงานมากกว่า fsck ที่ใช้เจอร์นัลอย่างรวดเร็วเมื่อไม่ได้ใช้ LVM และข้อมูลที่เขียนตั้งแต่การสำรองข้อมูลล่าสุดจะสูญหาย
- TestDisk , ext3grep , ext3undelและเครื่องมืออื่น ๆ สามารถกู้คืนพาร์ติชันและไฟล์จากดิสก์ที่ไม่ใช่ LVM แต่ไม่สนับสนุนการกู้คืนข้อมูล LVM โดยตรง TestDisk สามารถค้นพบว่าฟิสิคัลพาร์ติชันที่หายไปมี LVM PV แต่เครื่องมือเหล่านี้ไม่เข้าใจโลจิคัลวอลุ่ม LVM เครื่องมือการแกะสลักไฟล์เช่น PhotoRecและอื่น ๆ อีกมากมายจะทำงานเมื่อพวกเขาข้ามระบบไฟล์เพื่อรวบรวมไฟล์จากบล็อกข้อมูลอีกครั้ง แต่นี่เป็นวิธีสุดท้ายที่ใช้วิธีการระดับต่ำสำหรับข้อมูลที่มีค่าและทำงานได้ดีกับไฟล์ที่มีการแยกส่วน
- การกู้คืน LVM แบบแมนนวลเป็นไปได้ในบางกรณี แต่มีความซับซ้อนและใช้เวลานาน - ดูตัวอย่างนี้และนี่ , สิ่งนี้และสิ่งนี้สำหรับวิธีการกู้คืน
ยากที่จะปรับขนาดระบบไฟล์อย่างถูกต้อง - การปรับขนาดระบบไฟล์ง่ายมักจะได้รับประโยชน์จาก LVM แต่คุณต้องใช้คำสั่งเชลล์ครึ่งโหลเพื่อปรับขนาด FSM ตาม FSM - ซึ่งสามารถทำได้กับเซิร์ฟเวอร์ทั้งหมดและในบางกรณี ด้วยการติดตั้ง FS แต่ฉันจะไม่เสี่ยงต่อการสำรองข้อมูลล่าสุดและใช้คำสั่งทดสอบล่วงหน้าบนเซิร์ฟเวอร์ที่เทียบเท่า (เช่นการกู้คืนความเสียหายจากโคลนเซิร์ฟเวอร์การผลิต)
- อัปเดต:
lvextendรองรับเวอร์ชันล่าสุดเพิ่มเติมของตัวเลือก-r( --resizefs) - ถ้ามีให้ใช้นี่เป็นวิธีที่ปลอดภัยและรวดเร็วกว่าในการปรับขนาด LV และระบบไฟล์โดยเฉพาะอย่างยิ่งถ้าคุณลดขนาด FS และคุณสามารถข้ามส่วนนี้ได้
- คำแนะนำส่วนใหญ่จะปรับขนาด LVM-based FSs ไม่คำนึงถึงความจริงที่ว่า FS จะต้องค่อนข้างมีขนาดเล็กกว่าขนาดของ LV นี้: คำอธิบายรายละเอียดที่นี่ เมื่อการหดตัวของระบบแฟ้มที่คุณจะต้องระบุขนาดใหม่เครื่องมือ FS ปรับขนาดเช่น
resize2fsสำหรับ ext3 และหรือlvextend lvreduceขนาดอาจแตกต่างกันเล็กน้อยเนื่องจากความแตกต่างระหว่าง 1 GB (10 ^ 9) และ 1 GiB (2 ^ 30) หรือวิธีการที่เครื่องมือต่าง ๆ ปัดขึ้นหรือลง
- หากคุณไม่คำนวณอย่างถูกต้อง (หรือใช้ขั้นตอนพิเศษบางอย่างนอกเหนือจากขั้นตอนที่ชัดเจนที่สุด) คุณอาจจบลงด้วย FS ที่ใหญ่เกินไปสำหรับ LV ทุกอย่างจะดูดีเป็นเดือนหรือเป็นปีจนกว่าคุณจะกรอกข้อมูล FS จนครบถ้วนซึ่งเป็นจุดที่คุณจะได้รับความเสียหายอย่างร้ายแรง - และหากคุณไม่ตระหนักถึงปัญหานี้มันก็ยากที่จะหาสาเหตุเพราะคุณอาจมีข้อผิดพลาดดิสก์จริงด้วย นั่นทำให้สถานการณ์แย่ลง (อาจเป็นไปได้ว่าปัญหานี้ส่งผลกระทบต่อการลดขนาดของระบบแฟ้มเท่านั้นอย่างไรก็ตามเป็นที่ชัดเจนว่าการปรับขนาดระบบไฟล์ในทิศทางใดทิศทางหนึ่งจะเพิ่มความเสี่ยงของการสูญหายของข้อมูลซึ่งอาจเกิดจากข้อผิดพลาดของผู้ใช้)
ดูเหมือนว่าขนาด LV ควรใหญ่กว่าขนาด FS โดย 2 เท่าของขนาดทางกายภาพ LVM (PE) - แต่ตรวจสอบลิงค์ด้านบนเพื่อดูรายละเอียดเนื่องจากแหล่งที่มาสำหรับสิ่งนี้ไม่ได้มีสิทธิ์ บ่อยครั้งที่อนุญาตให้ 8 MiB นั้นเพียงพอ แต่อาจดีกว่าถ้าอนุญาตมากกว่าเช่น 100 MiB หรือ 1 GiB เพื่อความปลอดภัย วิธีตรวจสอบขนาด PE และโลจิคัลวอลุ่ม + ขนาด FS ของคุณโดยใช้บล็อก 4 KiB = 4096 ไบต์:
แสดงขนาด PE ในหน่วย KiB:
vgdisplay --units k myVGname | grep "PE Size"
ขนาดของ LVs ทั้งหมด:
lvs --units 4096b
ขนาดของ (ext3) FS ถือว่าขนาดบล็อก 4 KiB FS:
tune2fs -l /dev/myVGname/myLVname | grep 'Block count'
ในทางตรงกันข้ามการตั้งค่าที่ไม่ใช่ LVM ทำให้การปรับขนาด FS นั้นน่าเชื่อถือมากและใช้งานง่ายGpartedและปรับขนาด FSs ที่ต้องการแล้วมันจะทำทุกอย่างให้คุณ บนเซิร์ฟเวอร์คุณสามารถใช้partedจากเชลล์
- บ่อยครั้งที่ดีที่สุดที่จะใช้Gparted Live CDหรือParted Magicเนื่องจากสิ่งเหล่านี้มี Gparted & kernel ที่ปราศจากข้อผิดพลาดบ่อยกว่ารุ่น distro - ฉันเคยสูญเสีย FS ทั้งหมดเนื่องจาก Gparted ของ distro ไม่ได้อัปเดตพาร์ติชั่นอย่างเหมาะสมในการทำงาน เมล็ด หากใช้ Gparted ของ distro โปรดรีบูตทันทีหลังจากเปลี่ยนพาร์ทิชันเพื่อให้มุมมองของเคอร์เนลถูกต้อง
ภาพรวมมีความยากในการใช้งานช้าและรถ - ถ้าภาพรวมหมดก่อนการจัดสรรพื้นที่มันจะลดลงโดยอัตโนมัติ แต่ละสแน็ปช็อตของ LV ที่กำหนดคือเดลต้าเทียบกับ LV นั้น (ไม่ใช่กับสแนปชอตก่อนหน้า) ซึ่งอาจต้องการพื้นที่จำนวนมากเมื่อสแน็ปช็อตระบบไฟล์ที่มีกิจกรรมการเขียนที่สำคัญ (ทุกสแน็ปช็อต มีความปลอดภัยในการสร้างสแน็ปช็อต LV ที่มีขนาดเดียวกับ LV ดั้งเดิมเนื่องจากสแนปชอตจะไม่มีพื้นที่ว่างเหลืออยู่เลย
ภาพรวมยังสามารถที่จะช้ามาก (หมายถึง 3-6 ครั้งโดยไม่ต้องช้ากว่า LVM สำหรับการทดสอบ MySQL เหล่านี้ ) - ดูคำตอบนี้ครอบคลุมปัญหาภาพรวมต่างๆ ช้าส่วนหนึ่งเป็นเพราะภาพรวมต้องเขียนหลายซิงโคร
ภาพรวมมีข้อบกพร่องบางอย่างที่สำคัญเช่นในบางกรณีพวกเขาสามารถบูตได้ช้ามากหรือทำให้การบูตล้มเหลวอย่างสมบูรณ์ (เนื่องจากเคอร์เนลสามารถหมดเวลา รอรูท FS ได้เมื่อเป็นสแน็ปช็อต LVM [แก้ไขใน Debian initramfs-toolsupdate มีนาคม 2015] )
- อย่างไรก็ตามข้อผิดพลาดสภาพการแข่งขันสแนปช็อตจำนวนมากได้รับการแก้ไขโดย 2015
- LVM ที่ไม่มีสแนปชอตโดยทั่วไปดูเหมือนจะบั๊กค่อนข้างดีบางทีอาจเป็นเพราะสแนปชอตไม่ได้ใช้งานมากเท่ากับฟีเจอร์หลัก
ทางเลือกภาพรวม - ระบบไฟล์และ VM hypervisors
VM / คลาวด์สแนปชอต:
- หากคุณใช้ VM hypervisor หรือผู้ให้บริการคลาวด์ของ IaaS (เช่น VMware, VirtualBox หรือ Amazon EC2 / EBS) สแนปชอตของพวกเขามักจะเป็นทางเลือกที่ดีกว่าสแน็ปช็อต LVM คุณสามารถถ่ายภาพสแนปชอตเพื่อการสำรองข้อมูลได้อย่างง่ายดาย (แต่ควรพิจารณาการแช่แข็ง FS ก่อนที่จะทำ)
ภาพรวมระบบไฟล์:
สแน็ปช็อตสำหรับการสำรองข้อมูลออนไลน์และ fsck
สามารถใช้สแนปชอตเพื่อจัดหาแหล่งข้อมูลที่สอดคล้องกันสำหรับการสำรองข้อมูลตราบใดที่คุณระมัดระวังในการจัดสรรพื้นที่ (สแนปชอตจะมีขนาดเท่ากับการสำรองข้อมูล LV) ดีrsnapshot (ตั้งแต่ 1.3.1) ยังจัดการการสร้างภาพรวม LVM / ลบสำหรับคุณ - เห็นนี้HOWTO บน rsnapshot ใช้ LVM อย่างไรก็ตามโปรดทราบถึงปัญหาทั่วไปเกี่ยวกับสแนปชอตและสแนปชอตไม่ควรถูกพิจารณาว่าเป็นการสำรอง
คุณยังสามารถใช้ LVM snapshots เพื่อทำ fsck ออนไลน์: snapshot LV และ fsck snapshot ในขณะที่ยังคงใช้ FS ไม่ใช่ snapshot หลัก - อธิบายไว้ที่นี่ - อย่างไรก็ตามมันไม่ตรงไปตรงมาทั้งหมดดังนั้นควรใช้e2croncheckตามที่อธิบายโดย Ted Ts 'ผู้ดูแลของ ext3
คุณควร"หยุด" ระบบไฟล์ชั่วคราวขณะทำการถ่ายภาพ - ระบบไฟล์บางอย่างเช่น ext3 และ XFS จะทำเช่นนี้โดยอัตโนมัติเมื่อ LVM สร้างสแน็ปช็อต
สรุปผลการวิจัย
แม้จะมีทั้งหมดนี้ฉันยังคงใช้ LVM ในบางระบบ แต่สำหรับการตั้งค่าเดสก์ท็อปฉันชอบพาร์ติชันดิบ ประโยชน์หลักที่ฉันเห็นได้จาก LVM คือความยืดหยุ่นในการเคลื่อนย้ายและปรับขนาด FS เมื่อคุณต้องมีเวลาในการทำงานสูงบนเซิร์ฟเวอร์ - หากคุณไม่ต้องการระบบ gparted นั้นง่ายกว่าและมีความเสี่ยงในการสูญหายของข้อมูลน้อยกว่า
LVM ต้องการการดูแลการเขียนแคชเนื่องจาก VM hypervisors, ฮาร์ดไดรฟ์ / SSD เขียนแคชและอื่น ๆ - แต่การใช้แคชกับ Linux เป็นเซิร์ฟเวอร์ฐานข้อมูล การขาดการสนับสนุนจากเครื่องมือส่วนใหญ่ ( gpartedรวมถึงการคำนวณขนาดวิกฤตและtestdiskอื่น ๆ ) ทำให้ใช้งานได้ยากกว่าที่ควร
หากใช้ LVM โปรดใช้สแน็ปช็อตอย่างระมัดระวัง: ใช้ VM / cloud snapshots หากเป็นไปได้หรือตรวจสอบ ZFS / btrfs เพื่อหลีกเลี่ยง LVM อย่างสมบูรณ์ - คุณอาจพบว่า ZFS หรือ btrs นั้นโตเต็มที่เมื่อเทียบกับ LVM ด้วยสแน็ปช็อต
ที่บรรทัดด้านล่าง: หากคุณไม่ทราบเกี่ยวกับปัญหาที่ระบุไว้ข้างต้นและวิธีแก้ไขปัญหาดังกล่าวจะเป็นการดีที่สุดที่จะไม่ใช้ LVM