สำหรับผู้ที่ใช้งาน Proxmox VE และ มีการใช้งาน Local Storage ซึ่งเป็น LVM และ โดย default นั้น จะเป็น thin-LVM ด้วย ทั้งนี้เพราะว่า มันถูกออกแบบมา เพื่อให้ประหยัดเนื้อที่ในการเขียนไฟล์ เพราะเป็น thin provisioning แต่อย่างไร ก็ตาม หลายท่านอาจจะพบว่า เมื่อใช้งานแล้ว cpu นั้นขึ้นสูงขณะทำการติดตั้ง VM หรือ โอนถ่ายข้อมูลเข้า เช่น migrate จากระบบอื่น เข้ามา ก็จะพบว่าค่อนข้างช้า วันนี้เราจะพาไปพบกับคำตอบว่าทำไม Thin-LVM นั้นถึงค่อนข้างช้าในการทำงาน

การเขียนไฟล์บน Thin-LVM (LVM Thin Provisioning) มักจะ ช้ากว่า LVM แบบปกติ (Thick / Linear LVM) หลายเปอร์เซ็นต์หรืออาจจะเป็นเท่าตัว หรือหลายเท่าตัวขึ้นอยู่กับดิสก์แต่มันจะช้ากว่าอย่างแน่นอน โดยเฉพาะใน workload ที่มีการเขียนเยอะ เช่น VM disk หรือ database เพราะสาเหตุหลัก ๆ ดังนี้

1. มี Metadata เพิ่มขึ้นจำนวนมากในขณะเขียน
Thin-LVM ต้องเก็บ metadata mapping ระหว่าง Logical Block (ที่ VM เห็น) และ Physical Block (ที่ disk จริง)
ทุกครั้งที่มีการเขียน block ใหม่ ระบบต้องทำ 2 อย่าง

1.  allocate block ใหม่
2. update metadata mapping

จึงกลายเป็นว่า การเขียน จะต้องทำการเขียน ข้อมูลจริง + เขียน metadata ในขณะที่ LVM ปกตินั้นจะทำการเขียนข้อมูลจริงอย่างเดียวเท่านั้น

2. First Write Penalty (Allocate on Demand)
Thin-LVM ใช้หลักการ allocate space ตอนที่มีการเขียนจริง
ขั้นตอนเวลามี write ใหม่ จะเป็นดังนี้

1. ตรวจสอบ metadata
2. allocate block ใหม่
3. อัพเดท metadata
4. เขียนข้อมูล

ในขณะที่ LVM ปกติ block ถูก allocate ไว้แล้วตั้งแต่ตอน create volume

3. Metadata Bottleneck
Thin-LVM มี metadata device ถ้า metadata device ช้า (เช่นอยู่บน HDD) performance จะตกมาก เพราะ ทุก write ต้อง update metadata ใน production จึงนิยม data LV เขียนลง HDD/SSD และเก็บ metadata LV ใน NVMe/SSD

4. Fragmentation สูง
Thin provisioning ทำให้ block ถูก allocate แบบกระจัดกระจาย Logical blocks -> physical blocks scattered เพราะว่า allocate ใหม่ไปด้วยเขียนไปด้วย จึงทำให้เกิด

• fragmentation
• seek จะเพิ่มขึ้น
• write latency สูง

5. Copy-on-write (ในบางกรณี)

ถ้ามี snapshot หรือ thin snapshot จะเกิด copy-on-write ทำให้ write 1 ครั้ง อาจกลายเป็น ขั้นตอนดังนี้

• read old block
• copy
• write new block
• update metadata

6. Overcommit Management
Thin-LVM ต้องคอยตรวจสอบการใช้ thin pool หากใกล้เต็มจะเกิดการอ่านเขียนเกี่ยวกับ metadata และประสิทธิภาพจะยิ่งลดลง

ตัวอย่างโดยมาตรฐานคือ
LVM write = 100%
Thin-LVM write = 40-70%

วันนี้เราทำการทดสอบให้ท่านดูด้วย VM ขนาดเพียง 32GB และทำการ migrate จาก VMware มา โดยเราทำการ migrate และเขียนลงใน Thin-LVM ก่อน

จากรูปเราจะเห็นว่าใช้เวลา 22 นาที ในการ เขียน

สำหรับการใช้งาน CPU นั้นอยู่ที่ 12%

คราวนี้เรามาดู migrate ไปยัง LVM ปกติหรือว่า Thick-LVM บ้าง

จากรูปใช้เวลาไป 20 นาที

CPU ใช้เพียง 9% เท่านั้น ซึ่งท่านจะเห็นว่า CPU ก็ใช้น้อย และ เร็วกว่า แต่ความเร็วจะยิ่งห่างไปเรื่อยๆ เมื่อดิสก์ของท่าน ขนาดใหญ่ขึ้น และ Thin-LVM อาจจะช้ากว่าหลายเท่าตัวเลยก็มี ในกรณีดิสก์ขนาดใหญ่ๆ เพราะฉะนั้นท่านจะต้องระวังให้มาก ในเรื่องเวลาการ Migrate

แล้วคำถามต่อมาคือ ทำไมหลายระบบยังใช้ Thin-LVM เป็นค่า default

เพราะมันก็ยังมีข้อดี อยู่บางประการคือ

• Thin Provisioning
• Snapshot เร็ว
• Clone VM เร็ว
• ใช้ disk ประหยัด

ระบบที่ใช้ Thin-LVM เป็นค่า default

• Proxmox
• OpenStack
• Kubernetes CSI

สนใจงาน Migrate ไม่ว่าจาก VMware ไปเป็นระบบไหน ทั้ง Proxmox VE หรือ Hyper-V ติดต่อเราได้ทันที หรือ ปรึกษากับเราผ่าน Line OA @avesta.co.th หรืออีเมล์ [email protected]

• Facebook
• Twitter
• Line