ถัดจาก ตอนที่ ๑ ได้เกริ่นเริ่มว่า OpenVZ คืออะไร อยู่ตรงไหนของ Virtualization
ตอนที่ ๒ นี้จะพามารู้จักทั้งสามส่วนที่ได้ทิ้งท้ายไว้เมื่อครั้งที่แล้วให้มากขึ้น ซึ่งได้แก่
- Virtualization และ Isolation ที่ได้พูดไปว่า สามารถมีได้หลาย Virtual Environment (ต่อไปขอเรียกสั้นๆ ว่า VE) ใน physical server เพียงเครื่องเดียว
- Resource management ซึ่งคือส่วนที่ OpenVZ เอาไว้จัดการทรัยากรทั้งหลายให้กับแต่ละ VE
- Checkpointing ส่วนนี้ จะเกี่ยวข้องกับการทำ Live Migration ซึ่งจะเป็นยังไง ในโพสนี้มีบอกเช่นกัน
Virtualization และ Isolation
แต่ละ VE จะมีเซ็ตของทรัพยากร เป็นของตัวเอง (isolate) ซึ่งได้มาจาก kernel ของตัวโฮส OS ซึ่งทรัพยากรเหล่านั้นจะแยกเป็นเอกเทศน์ไม่เกี่ยวข้องกับ VE อื่นๆ แต่อย่างใด ซึ่งทรัพยากรดังกล่าวจะมีดังนี้
- ไฟล์ -- ไม่ว่าจะเป็น ไลบรารี่ของระบบ, แอพพลิเคชัน, /proc และ /sys, หรือการ lock ไฟล์
- ผู้ใช้ และ กลุ่มผู้ใช้ -- แต่ละ VE จะมี root เป็นของตัวเอง รวมไปถึง ผู้ใช้และกลุ่มผู้ใช้ด้วย
- โครงสร้างโปรเซส -- VE จะมองเห็นเฉพาะโปรเซสของตัวเอง โดยเริ่มตั้งแต่ init เหมือนกับลินุกซ์ทั่วไป และหมายเลยโปรเซส(PID) ของ init คือหมายเลข 1 นั่นเอง
- เน็ตเวิร์ก -- VE จะได้อุปกรณ์เน็ตเวิร์ก เสมือน ซึ่งจะทำให้ VE สามารถมีหมายเลยไอพี เป็นของตัวเอง และรวมไปถึงกฏของ netfilter (iptables) และการ routing
- อุปกรณ์ -- บางอุปกรณ์จะเป็นอุปกรณ์เสมือน ในบางกรณี หากต้องการให้ VE สามารถเข้าถึงอุปกรณ์จริงๆ บนเครื่องโฮส ก็สามารถทำได้ เช่น NIC, serial port เป็นต้น
- IPC ออปเจ็กต์ -- ได้แก่ shared memory, semaphores และ mesages
Resource management
การจัดการทรัพยากร ถือเป็นเรื่องที่สำคัญที่สุดของ Virtualization ประเภท OS-Level เพราะทรัพยากรที่มีอยู่จำกัดได้ถูกแชร์โดย kernel เดียว ผ่านไปยัง VE หลายๆ ตัว ซึ่งทรัพยากรเหล่านี้ ต้องมีการจัดการที่ดี เพื่อที่จะทำให้ VE ที่รันอยู่ไปมีผลกระทบกับ VE ตัวอื่นๆ ที่รันอยู่ในโฮสเดียวกัน
OpenVZ มีการจัดการทรัพยการอยู่สามส่วน
- จัดการโควต้าดิสก์แบบสองชั้น -- ชั้นแรก ที่ OpenVZ server สามารถจำกัดโควต้าของขนาดดิสก์และจำนวนของ inode, ชั้นที่สอง ที่ VE สามารถใช้ การจำกัดโควต้าโดยใช้เครื่องมือ UNIX quota ปกติ โดยสามาถจำกัดได้ทั้งแบบรายผู้ใช้ หรือแบบกลุ่มผู้ใช้
- "Fair" CPU scheduler -- OpenVZ CPU scheduler ก็มีสองระดับเช่นกัน คือ ระดับแรก จะมองดูว่า VE ไหนที่จำเป็นต้องใช้พลังของ CPU รวมถึงมีการเซ็ตระดับความสำคัญไว้ ส่วนอีกระดับคือ ภายใน VE จะใช้ standard Linux scheduler ในการดูว่า โปรเซส ไหนที่จำเป็นต้องใช้พลังของ CPU โดยใช้ ระดับความคำคัญของโปรเซส
- User Beancounters -- คือเซ็ตของ การนับ, การจำกัด และ การันตี ซึ่งจะมีอยู่ 20 พารามิเตอร์ซึ่งจะนำมาควบคุมการทำงานของ VE ผลที่ได้คือ จะไม่มี VE ไหน ใช้ทรัพยากรเกินกว่าที่ได้กำหนดไว้ ซึ่งอาจไปกระทบกับ VE อื่นได้ ซึ่งค่าส่วนใหญ่จะเกี่ยวกับหน่วยความจำ, IPC, network buffer เป็นต้น
Checkpointing และ live migration
การทำ checkpoint นำไปสู่การอนุญาติให้ทำ live migration หรือการย้าย VE จาก physical server นึง ไปยังอีก server นึงได้ โดยที่ไม่ต้องดาวน์ VE กระบวนการคือ VE จะถูก "แช่แข็ง" และสถานะทั้งหลายจะถูกเซฟลงดิสก์ โดยไฟล์นี้ล่ะจะถูกส่งต่อไปยัง server อีกเครื่อง จากนั้น VE ก็จะถูก ละลายน้ำแข็ง (เรียกว่า restore กะได้) กระบวนการทั้งหมดเกิดขึ้นภายในไม่กี่วินาที ซึ่งมองจากมุมผู้ใช้แล้ว จะไม่เหมือนเป็นการดาวน์ VE แต่จะเหมือนเป็นการดีเลย์ระหว่ากระบวนการซะมากกว่า
หมดแล้วสำหรับครั้งนี้ ครั้งหน้าก็น่าจะยังคงเป็น OpenVZ อยู่ พอดีใช้บ่อย เลยมีอะไรมาเขียนนี่แหละ
