Linux บน VMware - ทำไมต้องใช้การแบ่งพาร์ติชัน

เมื่อติดตั้ง Linux VM ในสภาพแวดล้อมเสมือนจริง (ESXi ในกรณีของฉัน) มีเหตุผลที่น่าสนใจในการแบ่งพาร์ติชันดิสก์ (เมื่อใช้ ext4) แทนที่จะเพิ่มดิสก์แยกต่างหากสำหรับแต่ละจุดเชื่อมต่อหรือไม่

สิ่งเดียวที่ฉันเห็นคือมันทำให้ง่ายขึ้นที่จะดูว่ามีข้อมูลอยู่ในดิสก์ด้วยเช่น fdisk หรือไม่

ในทางกลับกันฉันสามารถเห็นเหตุผลที่ดีบางประการที่ไม่ใช้พาร์ติชัน (สำหรับนอกเหนือจาก / boot อย่างชัดเจน)

• ง่ายต่อการขยายดิสก์ เป็นเพียงการเพิ่มขนาดดิสก์สำหรับ VM (โดยทั่วไปคือ VCenter) จากนั้นทำการสแกนอุปกรณ์ใน VM อีกครั้งและปรับขนาดระบบไฟล์ออนไลน์
• ไม่มีปัญหาเพิ่มเติมเกี่ยวกับการจัดพาร์ติชันให้สอดคล้องกับ LUN พื้นฐาน

ฉันไม่พบอะไรมากในหัวข้อนี้ ฉันคิดถึงบางสิ่งที่สำคัญไหม?

นี่เป็นคำถามที่น่าสนใจ ...

ฉันไม่คิดว่าจะมีคำตอบที่ชัดเจน แต่ฉันสามารถให้บริบททางประวัติศาสตร์เกี่ยวกับวิธีปฏิบัติที่ดีที่สุดในหัวข้อนี้อาจมีการเปลี่ยนแปลงตลอดเวลา

ฉันเคยไปหลายพันสนับสนุนของ Linux VMs นำไปใช้ในรูปแบบต่าง ๆ ในสภาพแวดล้อม VMware ตั้งแต่ปี 2007 วิธีการของฉันที่จะใช้งานได้มีการพัฒนาและฉันเคยซ้ำกัน ( บางครั้งโชคร้าย ) ประสบการณ์ในการสืบทอดและ refactoring ระบบที่สร้างขึ้นโดยวิศวกรอื่น ๆ

วันเก่า ๆ ...

ย้อนกลับไปในวัน (2007) ระบบ VMware ยุคแรกของฉันได้รับการแบ่งพาร์ติชันเช่นเดียวกับระบบโลหะเปลือยของฉัน ในด้านของ VMware ฉันใช้ไฟล์หนาแบบแยกขนาด 2GB เพื่อประกอบข้อมูลของ VM และไม่ได้คิดเกี่ยวกับแนวคิดของ VMDK หลายตัวเพราะฉันดีใจที่เวอร์ชวลไลเซชันสามารถใช้งานได้!

โครงสร้างพื้นฐานเสมือนจริง ...

โดย ESX 3.5 และ ESX / ESXi 4.x รีลีสต้น (2009-2011) ฉันใช้ Linux ซึ่งแบ่งพาร์ติชันตามปกติบนไฟล์ VMDK ที่มีการเตรียมโมโนลิ ธ แบบหนาก้อนเดียว การเตรียมพื้นที่เก็บข้อมูลล่วงหน้าทำให้ฉันต้องคิดถึงการออกแบบลีนุกซ์ในลักษณะที่คล้ายกับฮาร์ดแวร์จริง ฉันสร้าง 36GB, 72GB, 146GB VMDK สำหรับระบบปฏิบัติการแบ่งพาร์ติชั่นปกติ /, / boot, / usr, / var, / tmp จากนั้นเพิ่ม VMDK อีกอันสำหรับพาร์ติชั่น "data" หรือ "growth" (ไม่ว่าจะเป็น / home / opt หรือบางอย่างเฉพาะแอปพลิเคชัน) อีกครั้งจุดหวานในขนาดฮาร์ดดิสก์ทางกายภาพในช่วงยุคนี้คือ 146GB และเนื่องจากการจัดสรรล่วงหน้าเป็นข้อกำหนด (เว้นแต่ใช้ NFS) ฉันจึงต้องอนุรักษ์พื้นที่

การถือกำเนิดของการจัดเตรียมบาง ๆ

VMware พัฒนาคุณสมบัติที่ดีกว่าเกี่ยวกับThin provisioningใน ESXi 4.x ที่ออกมาในภายหลังและนี่เป็นการเปลี่ยนแปลงวิธีที่ฉันเริ่มติดตั้งระบบใหม่ ด้วยการเพิ่มชุดคุณสมบัติแบบเต็มใน 5.0 / 5.1 ความยืดหยุ่นชนิดใหม่ที่อนุญาตให้มีการออกแบบที่สร้างสรรค์มากขึ้น โปรดทราบว่านี่คือการก้าวไปพร้อมกับความสามารถที่เพิ่มขึ้นบนเครื่องเสมือนในแง่ของจำนวน vCPUS และจำนวน RAM ที่สามารถใช้กับ VM แต่ละเครื่องได้ เซิร์ฟเวอร์และแอปพลิเคชั่นประเภทอื่น ๆ อาจถูกจำลองเสมือนมากกว่าในอดีต สิ่งนี้ถูกต้องเนื่องจากสภาพแวดล้อมการคำนวณเริ่มเสมือนจริงสมบูรณ์

LVM แย่มาก ...

เมื่อถึงเวลาที่ฟังก์ชั่น hot-add เต็มรูปแบบที่ระดับ VM อยู่ในตำแหน่งและเป็นปกติ (2011-2012) ฉันได้ทำงานกับ บริษัท ที่พยายามรักษา uptime สำหรับ VMs ของลูกค้าในราคาใด ๆ ( โง่ ) ดังนั้นสิ่งนี้รวมถึงการเพิ่ม VMware CPU / RAM ออนไลน์และการปรับขนาดดิสก์ LVM ที่มีความเสี่ยงบน VMDK ที่มีอยู่ ระบบลีนุกซ์ส่วนใหญ่ในสภาพแวดล้อมนี้คือการตั้งค่า VMDK เดี่ยวพร้อมกับพาร์ติชัน ext3 ที่ด้านบนของ LVM มันแย่มากเพราะเลเยอร์ LVM เพิ่มความซับซ้อนและความเสี่ยงที่ไม่จำเป็นต่อการดำเนินงาน ตัวอย่างเช่นการใช้พื้นที่ว่างใน / usr อาจส่งผลให้เกิดการตัดสินใจที่ไม่ดีซึ่งในที่สุดก็หมายถึงการกู้คืนระบบจากการสำรองข้อมูล ... นี่เป็นกระบวนการบางส่วนและเกี่ยวข้องกับวัฒนธรรม แต่ยัง ...

ฉากกั้นฉาก ...

ฉันใช้โอกาสนี้เพื่อลองเปลี่ยนสิ่งนี้ ฉันเป็นพาร์ทิชัน snobใน Linux และรู้สึกว่าระบบไฟล์ควรแยกออกจากกันเพื่อการตรวจสอบและการปฏิบัติงานตามความต้องการ ฉันไม่ชอบ LVM โดยเฉพาะกับ VMware และความสามารถในการทำสิ่งที่คุณต้องการ ดังนั้นฉันจึงขยายการเพิ่มไฟล์ VMDK ไปยังพาร์ติชันที่อาจเติบโตได้ / opt, / var, / home สามารถรับไฟล์เครื่องเสมือนของตนเองได้หากจำเป็น และนั่นก็คือดิสก์ดิบ บางครั้งนี่เป็นวิธีที่ง่ายกว่าในการขยายพาร์ติชันที่มีขนาดเล็กโดยเฉพาะ

Obamacare ...

ด้วย onboarding ของไคลเอนต์สูงโปรไฟล์ฉันถูกมอบหมายด้วยการออกแบบของแม่แบบการอ้างอิง Linux VM ที่จะใช้ในการสร้างสภาพแวดล้อมของแอปพลิเคชันที่มองเห็นได้อย่างมาก ข้อกำหนดด้านความปลอดภัยของแอปพลิเคชันจำเป็นต้องใช้ชุดเมาท์ที่ไม่ซ้ำกันดังนั้นทำงานร่วมกับนักพัฒนาเพื่อพยายามยัดพาร์ติชันที่ไม่ใช่การเติบโตไปยัง VMDK หนึ่งตัวจากนั้นเพิ่ม VMDK แยกต่างหากสำหรับแต่ละตัวยึดที่มีศักยภาพในการเติบโตหรือมีข้อกำหนดเฉพาะ การตรวจสอบ ฯลฯ ) ดังนั้นในที่สุด VMs เหล่านี้ประกอบด้วย VMDK 5 ตัวขึ้นไป แต่ให้ความยืดหยุ่นที่ดีที่สุดสำหรับการปรับขนาดและป้องกันข้อมูลในอนาคต

วันนี้ฉันทำอะไร ...

วันนี้การออกแบบทั่วไปของฉันสำหรับ Linux และระบบไฟล์ดั้งเดิมคือระบบปฏิบัติการบน VMDK แบบบาง (แบ่งพาร์ติชัน) และแยก VMDKs ออกจากกันเพื่อสิ่งอื่น ฉันจะเพิ่มร้อนตามความจำเป็น สำหรับระบบไฟล์ขั้นสูงเช่น ZFS เป็นหนึ่ง VMDK สำหรับระบบปฏิบัติการและอีก VMDK ที่ทำหน้าที่เป็น ZFS zpool และสามารถปรับขนาดแกะสลักเป็นระบบไฟล์ ZFS เพิ่มเติม ฯลฯ

คุณพูดถูกหลายวิธีฉันเห็นการโต้เถียง - มีประเด็นหนึ่งที่พิสูจน์ได้ว่าเป็นเรื่องยุ่งยาก หากคุณใช้ Resource Pools (และฉันรู้ว่าไม่ชอบสิ่งที่น่ารังเกียจ) จากนั้น VM สามารถรับเวลา IO ได้มากขึ้นหากมีดิสก์มากขึ้น - ในสถานการณ์ที่ทรัพยากร จำกัด มาก VM ที่มีดิสก์สองแผ่นจะได้รับทรัพยากร IO มากกว่าสองเท่า ดิสก์เดียว นี่อาจไม่เป็นปัญหาสำหรับคุณ แต่ฉันคิดว่าฉันจะชี้ให้เห็น

แก้ไข - โอ้แล้วมันจะทำให้การจัดเรียงช้าลงเล็กน้อยเช่นกัน แต่อีกครั้งที่อาจไม่มีปัญหา

เมื่อฉันทำงานในโครงสร้างพื้นฐานที่ "บริษัท ซอฟต์แวร์เวอร์ชวลไลเซชันขนาดใหญ่" โดยเฉพาะเรามักต้องเพิ่มขนาดของระบบไฟล์ของ vm เราใช้ ext3 / 4 ในเวลานั้น

การเพิ่มดิสก์เสมือนนั้นง่ายมากการเพิ่มขนาดอุปกรณ์ใหม่ในระบบปฏิบัติการสดนั้นค่อนข้างง่าย (โผล่ไปมาใน / sys) ปรับขนาดระบบไฟล์สด ext3 / 4 เป็นเรื่องง่าย แต่สิ่งที่ดูเหมือนจะเป็นไปไม่ได้เสมอ ปรับขนาดพาร์ติชัน

คุณต้องใช้ gparted หรือ rewrite / resize พาร์ติชั่นตารางโดยใช้ fdisk - แต่มันถูกล็อกโดยเคอร์เนลเสมอและจำเป็นต้องรีบูตเพื่อให้เคอร์เนลรับเค้าโครงใหม่ (partprobe ไม่ได้ทำเช่นนั้น)

ฉันย้ายระบบหลายระบบไปยัง LVM และการปรับขนาดระบบไฟล์กลายเป็นประสบการณ์ที่ง่ายและน่าพึงพอใจเกือบ!

• เพิ่มอิมเมจดิสก์เสมือนนอก VM
• ใน VM
  • Poke / sys เพื่อสแกนเมตริกของดิสก์อีกครั้ง (echo "1"> / sys / class / scsi_device // device / rescan)
  • pvresize / dev / sdX (ปรับขนาดฟิสิคัลวอลุ่มเป็น LVM)
  • lvresize - เนื้อหา + 100% ฟรี / dev / VG / lvolXX (ปรับขนาดโลจิคัลวอลุ่มเป็น LVM)
  • resize2fs (ปรับขนาดระบบไฟล์)

ทั้งหมดนี้สามารถทำได้อย่างปลอดภัยในระบบที่ใช้งานจริง - และไม่ต้องรีบูตเครื่อง!

ทำไมไม่ใช้ดิสก์เปล่า มันทำให้ฉันกังวล - ฉันไม่รู้สึกว่าดิสก์เปล่าได้รับการยอมรับอย่างกว้างขวางเพียงพอ แต่ฉันคิดว่าเรากำลังจะได้รับการยอมรับในวงกว้างมากขึ้น มีเธรดในรายการส่งเมล btrfs ที่เกี่ยวข้องกับสิ่งนี้:

http://www.spinics.net/lists/linux-btrfs/msg24730.html

แต่ดิสก์เปล่าจะต้องการ rescan และ resize2fs อีกครั้ง

ดังนั้นโดยสรุปใช่หลีกเลี่ยงตารางพาร์ติชันถ้าคุณสามารถ

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

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

จริงอยู่ที่มันเป็นเรื่องมุม แต่ก็คุ้มค่าที่จะพิจารณาหากคุณต้องการตั้งค่าแบบนี้

ไม่ว่าจะเป็นการดีกว่าหรือไม่ขึ้นอยู่กับระบบของคุณ

มีข้อดีข้อเสียของการตั้งค่าแต่ละอย่าง

อย่างไรก็ตามข้อดีหลักของไดรฟ์เดียวมีดังนี้:

1. ความเรียบง่าย: ไดรฟ์เดียวมีไฟล์เดียวซึ่งสามารถกระจายและทำซ้ำได้ง่าย
2. หมายถึง Host OS: ไฟล์เดียวจะถูกถือว่าเป็นบล็อกข้อมูลเดียวและด้วยเหตุนี้โฮสต์ระบบปฏิบัติการจะรู้ว่าลำดับของการเข้าถึงเครื่องแขกจะอยู่ในไฟล์เดียว สิ่งนี้สามารถทำได้ในการกำหนดค่าโฮสต์บางระบบโดยเพียงแค่วางอิมเมจไดรฟ์ทั้งหมดในไฟล์เดียวกัน แต่ไม่จำเป็นต้องเป็นกรณีนี้

อย่างไรก็ตามมีข้อดีหลายประการ

1. ความสัมพันธ์ของโลหะเปลือย / ตำแหน่งที่กำหนดด้วยตนเอง: ด้วยไดรฟ์เดียวคุณจะถูกล็อคเข้ากับความสัมพันธ์ของโลหะเปลือยของไดรฟ์
2. ข้อ จำกัด ด้านขนาด: หากระบบของคุณมีข้อ จำกัด เกี่ยวกับขนาดของไดรฟ์หรือไฟล์คุณสามารถใช้ระบบเหล่านี้กับระบบที่มีขนาดใหญ่มาก
3. โวลุ่มแบบอ่านอย่างเดียวเพื่อความปลอดภัย: นี่เป็นข้อได้เปรียบที่ยิ่งใหญ่ หากโวลุ่มหลักของคุณสำหรับ OS นั้นอ่านได้ทางด้าน VM เท่านั้นมันจะให้ข้อดีด้านความปลอดภัยที่สำคัญโดยทั่วไปแล้วจะปิดกั้นความสามารถของโปรแกรมภายใน VM จากการแก้ไขระบบปฏิบัติการพื้นฐานของแขก การใช้ไดรฟ์ข้อมูลแยกต่างหากช่วยให้คุณสร้างไดรฟ์แบบอ่านอย่างเดียวซึ่งสามารถบูตอ่าน - เขียนเพื่อการบำรุงรักษาและอัปเดตได้โดยไม่ต้องใช้ข้อมูลเทมเพลตคลีนรูมเท่านั้นป้องกันการแก้ไขไดเรคทอรี OS สำคัญจากเซิร์ฟเวอร์ทั้งหมด

มีตัวเลือกอื่น: เมาท์ข้อมูลแอปพลิเคชันบนวอลุ่ม NFS คุณต้องการตัวกรองที่ดี (การใช้งาน NFS ไม่เหมือนกันทั้งหมด)

เมื่อปริมาณ NFS เติมขึ้นให้ขยายระดับเสียงไคลเอ็นต์ linux จะเห็นพื้นที่พิเศษทันที

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

อีกหนึ่งจุดโบนัสสำหรับวิธีนี้คือหากผู้ขายพื้นที่จัดเก็บของคุณมีเทคโนโลยี snapshotting / cloning (เช่น zfs หรือ Netapp) สำรองข้อมูลและสร้างสภาพแวดล้อมการทดสอบ / dev นั้นง่ายมาก

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

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

ในอีกด้านหนึ่งจะสามารถแบ่งพาร์ติชันเพื่อใช้แบบดั้งเดิมน้อยกว่าเช่นChromeOSและCoreOSมีสองพาร์ติชันแบบอ่านอย่างเดียวสำหรับการอัพเกรดระบบ

เหตุผลหนึ่งที่ยังไม่ได้รับการกล่าวถึงเพื่อให้ห่างไกลที่อยู่ในโครงสร้างพื้นฐานบางอย่างเช่น Google Compute, ดิสก์ประสิทธิภาพ IO เป็นเส้นตรงเพิ่มขึ้นกับขนาดของดิสก์ กล่าวอีกนัยหนึ่งไดรฟ์ที่แบ่งพาร์ติชันใหญ่จะมีประสิทธิภาพ IO ดีกว่าไดรฟ์ขนาดเล็กหลายตัว

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

จากประสบการณ์ของฉันวิธีที่ดีกว่าคือใช้ 1 VMDK สำหรับ OS และฉันมักจะแบ่งพาร์ติชันด้วยวิธีต่อไปนี้:

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

ฉันพบว่า 8GB นั้นเพียงพอสำหรับ / เพราะฉันมักจะติดตั้งซอฟต์แวร์ Linux (~ 800MB) + ซอฟต์แวร์ที่ฉันต้องการน้อยที่สุด บันทึกยังไปที่พาร์ติชันนั้น แต่ถ้าตั้งค่าอย่างถูกต้อง (ล็อกเอาต์เป็นเวลาหนึ่งสัปดาห์) และจัดส่งที่อื่น (syslog / elasticsearch) พวกเขามักจะไม่ทำเช่นนั้นเพื่อเติมพาร์ติชัน

ข้อมูลถูกเพิ่มเป็น VMDK อื่นและฉันมักจะฟอร์แมตระบบไฟล์โดยตรงบนดิสก์เปล่า (เช่น. / dev / sdb) สิ่งนี้ทำให้ฉันสามารถปรับขนาดไดรฟ์ข้อมูลใน VmWare และปรับขนาดโดยตรงใน VM โดยไม่จำเป็นต้องแบ่งพาร์ติชัน / umount / รีบูต

ฉันแบ่งพาร์ติชันด้วยเหตุผลสองประการ:

1. เอกสารประกอบ - ฉันเคยมีผู้ดูแลระบบ EMC ที่ "ผ่านการฝึกอบรม" ขโมย LUNs จากตัวฉันเพราะพวกเขาไม่มีเอกสารและดูเหมือนว่าเขาจะไม่ได้รับการจัดสรรและในตอนกลางคืน เขาจัดสรร LUN ของฉันอีกครั้งสำหรับอีกเล่มหนึ่งสำหรับแอปที่ไม่เกี่ยวข้อง ตั้งแต่นั้นมาฉันก็หวาดระแวงเกี่ยวกับเอกสาร
2. เตรียมดิสก์ของฉันมากเกินไป ด้วย platters จะช่วยป้องกันข้อมูลจากกระบอกสูบที่ช้าลงและด้วย SSD มันจะช่วยยืดอายุการใช้งาน / MTBF