แก้ไขปัญหาพื้นที่ไม่เพียงพอในการจัดสรรทรัพยากรแบบ LVM Thin Provisioning บน SUSE Linux Enterprise อย่างปลอดภัย

คุณควรพิจารณาอะไรบ้างก่อนที่จะเปลี่ยนแปลงสิ่งใดๆ?

ขั้นแรก ให้ตรวจสอบว่า thin pool นั้นมีพื้นที่ข้อมูลพื้นที่เมตาเดตาหรือทั้งสองอย่างหมดแล้วหรือไม่ ความแตกต่างนี้จะส่งผลต่อแผนการกู้คืน thin pool ประกอบด้วย LV ข้อมูลที่เก็บบล็อกที่จัดสรรไว้ และ LV เมตาเดตาที่ติดตามการจัดสรรเหล่านั้น ขนาดเสมือนของวอลุ่มลอจิกแบบ thin สามารถเกินความจุทางกายภาพของ pool ได้ ซึ่งเป็นจุดประสงค์ของ thin provisioning แต่ก็เป็นเหตุผลที่ต้องตรวจสอบ overcommit อยู่เสมอ

เอกสารประกอบของ SUSE Linux Enterprise Server 15 SP7 ยืนยันว่าวอลุ่มแบบ Thin จะจัดสรรพื้นที่จากพูลแบบ Thin ตามความต้องการ และขนาดเสมือนรวมอาจเกินพื้นที่จัดเก็บข้อมูลทางกายภาพที่มีอยู่ เอกสารประกอบของ LVM thin-pool ต้นฉบับได้เพิ่มกฎการทำงานที่สำคัญอีกข้อหนึ่งคือ ขยายพูลก่อนที่ค่าใดค่าหนึ่งData%จะMeta%ถึง 100% โปรดดูคู่มือการดูแลระบบจัดเก็บข้อมูลของ SUSE Linux Enterprise Server 15 SP7และคู่มือการจัดสรรพื้นที่แบบ Thin ของ LVM

1. พื้นที่เก็บข้อมูลเต็ม หรือเมตาเดต้าเต็ม?

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

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent

คำบรรยายภาพ: ต้องระบุ thin pool ด้วยค่า Data% และ Meta% เท่านั้น พื้นที่ว่างในระบบไฟล์เพียงอย่างเดียวไม่แสดงถึงการหมดลงของ thin pool ทางกายภาพ

หากData%ค่าอยู่ที่หรือใกล้เคียง 100 แสดงว่าพูลข้อมูลหมดพื้นที่สำหรับเขียนข้อมูลใหม่แล้ว เอกสาร LVM ต้นฉบับเตือนว่าการเขียนข้อมูลอาจส่งคืนข้อผิดพลาดเมื่อพูลข้อมูลหมด ซึ่งอาจทำให้ระบบไฟล์เสียหายได้ หากMeta%ค่าถึง 100 การตอบสนองจะระมัดระวังมากขึ้นเนื่องจากการหมดของเมตาเดต้าอาจทำให้เมตาเดต้าของพูลแบบบางและระบบไฟล์ไม่สอดคล้องกัน

2. กลุ่มปริมาตรยังมีขอบเขตทางกายภาพที่ว่างอยู่หรือไม่?

นี่คือจุดตัดสินใจถัดไป พูลแบบบางจะขยายได้ก็ต่อเมื่อกลุ่มวอลุ่มมีพื้นที่ว่างเหลืออยู่ เว้นแต่คุณจะเพิ่มพื้นที่จัดเก็บข้อมูลทางกายภาพให้กับกลุ่มวอลุ่มนั้นก่อน

vgs -o vg_name,vg_size,vg_free
vgdisplay VG_NAME

คำบรรยายภาพ: การตรวจสอบพื้นที่ว่างใน VG ช่วยแยกแยะระหว่างการขยายระบบแบบ thin-pool อย่างง่าย กับกรณีที่ต้องเพิ่มพื้นที่จัดเก็บข้อมูลก่อน

หาก VG มีพื้นที่ว่างเพียงพอ คุณสามารถขยาย thin pool ได้โดยตรง แต่ถ้าVFreeพื้นที่ว่างเป็นศูนย์หรือน้อยเกินไป อย่าพยายามขยายซ้ำlvextendให้ตัดสินใจว่าจะลบ thin volume หรือ snapshot ที่ไม่จำเป็น เรียกคืนบล็อกด้วยคำสั่ง discard หรือเพิ่ม physical volume ใหม่

3. คุณควรปิดแอปพลิเคชันก่อนทำการกู้คืนหรือไม่?

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

systemctl stop YOUR_APPLICATION.service
systemctl status YOUR_APPLICATION.service

คำบรรยายภาพ: การระงับการทำงานของแอปพลิเคชันจะจำกัดการเขียนเพิ่มเติมในขณะที่กำลังกู้คืนพูลข้อมูลแบบบางที่เต็มหรือเสียหาย

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

4. หาก Data% เต็มแล้ว แต่ VG ยังมีพื้นที่ว่างอยู่ จะขยายพูลได้อย่างไร?

ขยายพูลแบบบาง (thin pool) จริงๆ ไม่ใช่ LV แบบบางเสมือน (virtual thin LV) เพราะปัญหาอยู่ที่ความจุของพูลทางกายภาพไม่เพียงพอ ตัวอย่างเช่น:

lvextend -L +20G VG_NAME/THIN_POOL
lvs -o lv_name,vg_name,lv_size,data_percent,metadata_percent VG_NAME/THIN_POOL

คำบรรยายภาพ: การขยายพูลที่มีขนาดเล็กจะเพิ่มความจุทางกายภาพ ส่งผลให้เปอร์เซ็นต์ข้อมูลลดลงเมื่อพื้นที่ใหม่พร้อมใช้งาน

คู่มือlvextendอธิบายถึงการขยาย thin-pool โดยตรงและ--poolmetadatasizeตัวเลือกแยกต่างหากสำหรับเมตาเดต้า เลือกขนาดเพิ่มขึ้นตามอัตราการเติบโตจริงและความจุพื้นที่จัดเก็บที่คุณสามารถสำรองไว้ได้ ตัวอย่างที่กำหนดไว้เช่นนี้+20Gไม่ใช่คำแนะนำในการกำหนดขนาดสำหรับทุกระบบ

5. จะทำอย่างไรหากกลุ่มวอลุ่มไม่มีพื้นที่ว่างเหลืออยู่?

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

lsblk
blkid

pvcreate /dev/NEW_DEVICE
vgextend VG_NAME /dev/NEW_DEVICE
vgs -o vg_name,vg_size,vg_free

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

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

6. จะเกิดอะไรขึ้นถ้า Meta% ถึง 100%?

ควรพิจารณาปัญหาเมตาเดต้าหมดเป็นกรณีการซ่อมแซมแบบออฟไลน์ แทนที่จะเพิ่มความจุข้อมูลเพียงอย่างเดียว คู่มือการใช้งาน LVM thin-pool ระบุไว้อย่างชัดเจนว่า เมตาเดต้าหมดอาจทำให้เมตาเดต้าและระบบไฟล์ของ thin-pool ไม่สอดคล้องกัน ลำดับการกู้คืนที่ระบุไว้ในเอกสารคือ การปิดใช้งานพูล ซ่อมแซมด้วยคำสั่ง `repair` lvconvert --repairขยายเมตาเดต้า แล้วตรวจสอบระบบไฟล์อีกครั้ง

หลังจากหยุดการทำงานของแอปพลิเคชันแล้ว ให้ยกเลิกการเมานต์ระบบไฟล์หรือปิดใช้งาน Thin LV ที่ใช้พูล จากนั้นให้ปฏิบัติตามขั้นตอนการบำรุงรักษาที่กำหนดไว้ ซึ่งคล้ายกับ:

lvchange -an VG_NAME/THIN_LV
lvconvert --repair VG_NAME/THIN_POOL
lvextend --poolmetadatasize +1G VG_NAME/THIN_POOL

คำบรรยายภาพ: สภาวะที่มีเมตาเดตาเต็มนั้น จำเป็นต้องซ่อมแซม thin-pool แบบออฟไลน์และเพิ่มพื้นที่เมตาเดตา ไม่ใช่แค่เพิ่มส่วนขยายข้อมูลเท่านั้น

รูปภาพ นี้+1Gเป็นเพียงตัวอย่างเท่านั้น ขนาดของเมตาเดต้าขึ้นอยู่กับขนาดของพูล ขนาดของชิ้นส่วน การใช้งานสแนปช็อต และพฤติกรรมการจัดสรร หลังจากซ่อมแซมแล้ว ให้ตรวจสอบบันทึกระบบและใช้ขั้นตอนการตรวจสอบหรือซ่อมแซมที่รองรับเฉพาะระบบไฟล์หากเกิดข้อผิดพลาด I/O อย่าเรียกใช้เครื่องมือซ่อมแซมระบบไฟล์โดยไม่ตรวจสอบให้ดีก่อนบนระบบไฟล์ที่ติดตั้งอยู่

การลบไฟล์สามารถทำให้พื้นที่จัดเก็บข้อมูลว่างเปล่าได้ทันทีหรือไม่?

ไม่เสมอไป การลบไฟล์จะทำให้พื้นที่ว่างในระบบไฟล์เพิ่มขึ้น แต่ thin pool จะเรียกคืนพื้นที่จริงก็ต่อเมื่อข้อมูลการทิ้ง (discard information) มาถึง pool เท่านั้น เอกสารของ LVM ระบุว่า trim fstrimสามารถเรียกคืนบล็อกเหล่านั้นได้ ในขณะที่ snapshot อาจยังคงอ้างอิงถึงบล็อกและป้องกันไม่ให้บล็อกเหล่านั้นว่างลง หาก pool ถูกกำหนดค่าให้ไม่สนใจข้อมูลการทิ้ง (discard information) trim จะไม่สามารถเรียกคืนบล็อกเหล่านั้นได้

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

lvs -o lv_name,discards VG_NAME/THIN_POOL
fstrim -v /mount/point

การลบสแนปช็อตแบบบาง (thin snapshots) เก่าๆ อาจช่วยเพิ่มพื้นที่จัดเก็บข้อมูลได้ หากสแนปช็อตเหล่านั้นเป็นข้อมูลอ้างอิงที่เหลืออยู่ของบล็อกข้อมูล ตรวจสอบข้อกำหนดการสำรองข้อมูลและการเก็บรักษาข้อมูลก่อนลบสแนปช็อต

7. จะป้องกันไม่ให้เหตุการณ์นี้เกิดขึ้นอีกได้อย่างไร?

เปิดใช้งานและตรวจสอบการตรวจสอบ LVM thin-pool และกำหนดค่าการขยายอัตโนมัติโดยมีพื้นที่ว่างเพียงพอใน VG LVM ต้นทางจะใช้ กลไกนี้ dmeventdโดยปกติผ่านทางlvm2-monitorบริการ เพื่อตอบสนองเมื่อการใช้งานข้อมูลหรือเมตาเดต้าเกินเกณฑ์ที่กำหนดไว้

systemctl status lvm2-monitor.service
lvs -o+seg_monitor VG_NAME/THIN_POOL
lvchange --monitor y VG_NAME/THIN_POOL

lvmconfig --type full activation/thin_pool_autoextend_threshold
lvmconfig --type full activation/thin_pool_autoextend_percent

คำบรรยายภาพ: การขยายอัตโนมัติขึ้นอยู่กับการตรวจสอบอย่างต่อเนื่อง เกณฑ์ที่เหมาะสม และขอบเขตว่างที่เหลืออยู่ในกลุ่มปริมาตร

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

ตัวอย่างการกำหนดค่าที่เป็นไปได้/etc/lvm/lvm.confมีดังนี้:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

ค่าเหล่านั้นเป็นเพียงตัวอย่าง ไม่ใช่ค่าเริ่มต้นสากล ควรปรับขนาดระยะปลอดภัยตามอัตราการเขียนข้อมูลแบบเป็นชุด ช่วงเวลาการตรวจสอบ ระยะเวลาในการจัดสรรพื้นที่จัดเก็บ และพื้นที่ว่างใน VG ที่มีอยู่ การขยายอัตโนมัติจะไม่ช่วยอะไรหาก VG เต็มอยู่แล้ว

8. คุณแน่ใจได้อย่างไรว่าการฟื้นฟูได้ผลจริง?

ตรวจสอบสัญญาณมากกว่าหนึ่งสัญญาณ พูลควรมีพื้นที่เหลือเฟือ VG ควรมีพื้นที่ว่างเพียงพอสำหรับการเติบโตที่คาดการณ์ไว้ แอปพลิเคชันควรสามารถเขียนข้อมูลได้ตามปกติ และบันทึกไม่ควรแสดงข้อผิดพลาด I/O หรือเมตาเดต้าของพูลแบบบางอย่างต่อเนื่อง

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent
vgs -o vg_name,vg_size,vg_free
journalctl -u lvm2-monitor.service --since "30 minutes ago"

คำบรรยายภาพ: การกู้คืนได้รับการยืนยันเมื่อการใช้งานพูลมีพื้นที่เหลือเฟือ VG ยังคงมีพื้นที่ว่างที่ใช้งานได้ และรายงานการตรวจสอบไม่พบข้อผิดพลาด I/O อย่างต่อเนื่อง

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

เมื่อใดที่คุณควรหยุดและใช้วิธีการกู้คืนอื่น?

คุณควรหลีกเลี่ยงอะไรบ้าง?

• อย่าสันนิษฐานdf -hว่าสระน้ำบาง ๆ นั้นมีพื้นที่จัดเก็บทางกายภาพฟรี
• อย่าเริ่มต้นใช้งานอุปกรณ์ใหม่pvcreateจนกว่าคุณจะแน่ใจแล้วว่าอุปกรณ์นั้นยังไม่เคยถูกใช้งานมาก่อน
• อย่ามองว่าปัญหาเมตาเดต้าหมดเหมือนกับปัญหาข้อมูลหมดทั่วไป
• อย่าใช้การขยายอัตโนมัติโดยไม่สำรองพื้นที่ว่างใน VG ไว้ก่อน
• อย่าใช้คำสั่งซ่อมแซมระบบไฟล์กับระบบไฟล์ที่ถูกเมานต์อยู่ เว้นแต่ว่าผู้จำหน่ายระบบไฟล์จะรองรับการดำเนินการนั้นอย่างชัดเจน
• อย่าปิดการตรวจสอบเพียงเพื่อระงับคำเตือน เพราะคำเตือนมักเป็นโอกาสสุดท้ายในการขยายพูลก่อนที่การเขียนจะล้มเหลว

เอกสารอ้างอิงอย่างเป็นทางการและหลัก

• คู่มือการบริหารจัดการระบบจัดเก็บข้อมูลสำหรับ SUSE Linux Enterprise Server 15 SP7
• เอกสารประกอบการใช้งาน SUSE SLES 15 SP7 Expert Partitioner
• คู่มือการจัดสรรทรัพยากรแบบบาง (Thin Provisioning) ของ LVM
• คู่มือ LVM lvextend