การศึกษา vSphere - อะไรคือข้อเสียของการกำหนดค่า VM ด้วย * RAM มากเกินไป?

การจัดการหน่วยความจำ VMware ดูเหมือนจะเป็นการปรับสมดุลให้ยุ่งยาก ด้วยคลัสเตอร์แรม, Resource Pools, เทคนิคการจัดการของ VMware (TPS, การทำบอลลูน, การสลับโฮสต์), การใช้ RAM ในห้องพัก, การแลกเปลี่ยน, การจองการแชร์และข้อ จำกัด มีตัวแปรมากมาย

ฉันอยู่ในสถานการณ์ที่ลูกค้ากำลังใช้ทรัพยากรคลัสเตอร์ vSphere เฉพาะ อย่างไรก็ตามพวกเขากำลังกำหนดค่าเครื่องเสมือนราวกับว่าพวกเขาอยู่บนฮาร์ดแวร์ทางกายภาพ ในทางกลับกันสิ่งนี้หมายความว่าบิวด์ VM มาตรฐานอาจมี 4 vCPUs และ RAM 16GB หรือมากกว่า ฉันมาจากโรงเรียนที่เริ่มต้นเล็ก (1 vCPU, RAM น้อยที่สุด), ตรวจสอบการใช้งานจริงและปรับตามความจำเป็น น่าเสียดายที่ความต้องการของผู้จำหน่ายจำนวนมากและผู้คนที่ไม่คุ้นเคยกับการจำลองเสมือนร้องขอทรัพยากรมากกว่าที่จำเป็น ... ฉันสนใจที่จะประเมินผลกระทบของการตัดสินใจนี้

ตัวอย่างบางส่วนจากกลุ่ม "ปัญหา"

สรุปกลุ่มทรัพยากร - มีลักษณะเกือบ 4: 1 มีคำสั่งมากเกินไป สังเกตปริมาณ RAM ที่บอลลูนอยู่ในระดับสูง

การจัดสรรทรัพยากร - คอลัมน์การจัดสรรกรณีที่เลวร้ายที่สุดแสดงให้เห็นว่า VM เหล่านี้จะสามารถเข้าถึง RAM ที่กำหนดค่าน้อยกว่า 50% ภายใต้เงื่อนไขที่ จำกัด

กราฟการใช้งานหน่วยความจำตามเวลาจริงของ VM อันดับต้น ๆ ในรายการด้านบน จัดสรร 4 vCPU และ 64GB RAM มันมีค่าเฉลี่ยต่ำกว่าการใช้งาน 9GB

สรุปของ VM เดียวกัน

• ข้อเสียของการทับซ้อนและการกำหนดค่าทรัพยากร (RAM เฉพาะ) ในสภาพแวดล้อม vSphere คืออะไร

• สมมติว่า VM สามารถทำงานใน RAM น้อยกว่ามันเป็นธรรมที่จะบอกว่ามีค่าใช้จ่ายในการกำหนดค่าเครื่องเสมือนที่มี RAM มากกว่าที่พวกเขาต้องการจริงหรือไม่

• ข้อโต้แย้งคืออะไร: "ถ้า VM มี RAM 16GB จัดสรร แต่ใช้ 4GB เท่านั้นปัญหาคืออะไร" ลูกค้าจำเป็นต้องได้รับการศึกษาหรือไม่ว่าVMs ไม่เหมือนฮาร์ดแวร์จริง?

• ควรใช้การวัดแบบใดเพื่อวัดการใช้ RAM ติดตามยอดของ "ใช้งาน" กับเวลา? กำลังดู "บริโภค" หรือไม่

อัปเดต:ฉันใช้vCenter Operations Managerเพื่อทำโปรไฟล์สภาพแวดล้อมนี้และรับรายละเอียดบางอย่างเกี่ยวกับสถานะของคลัสเตอร์ที่ระบุไว้ด้านบน ในขณะที่สิ่งที่ overcommitted แน่นอนที่ VMs เป็นจริงดังนั้น overconfigured กับ RAM ที่ไม่จำเป็นที่จริง (เล็ก ๆ ) รอยความทรงจำไม่แสดงการต่อสู้ของหน่วยความจำที่ระดับคลัสเตอร์ / เจ้าภาพ ...

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

อัปเดต 2: VMs เหล่านี้บางตัวเริ่มที่จะขัดข้องด้วย:

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 

VMware อธิบายว่านี่เป็นอาการของ overcommitment ดังนั้นฉันเดาว่าจะตอบคำถาม

vCops รายงาน "เครื่องเสมือนขนาดใหญ่" ...

vCops กราฟ "ของเสียที่เรียกคืนได้" ...

การจัดการหน่วยความจำของ vSphere ค่อนข้างดีแม้ว่าคำที่ใช้มักจะทำให้เกิดความสับสนมาก

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

ข้อเสียของการทับซ้อนและการกำหนดค่าทรัพยากร (RAM เฉพาะ) ในสภาพแวดล้อม vSphere คืออะไร

ข้อเสียที่สำคัญของทรัพยากรที่ต้องทำมากเกินไปคือหากคุณมีความขัดแย้งโฮสต์ของคุณจะถูกบังคับให้บอลลูนแลกเปลี่ยนหรือกำหนดตารางเวลา / ยกเลิกการทำซ้ำอย่างชาญฉลาดเบื้องหลังเพื่อให้ VM แต่ละ RAM ต้องการ

สำหรับการบอลลูน vSphere จะขยาย "บอลลูน" ของ RAM ภายใน VM ที่เลือกจากนั้นมอบ RAM บอลลูนที่ส่งให้กับแขกที่ต้องการ นี่ไม่ใช่ "เลวร้าย" - VMs กำลังขโมย RAM ของกันและกันดังนั้นจึงไม่มีการสลับดิสก์ที่เกิดขึ้น - แต่อาจนำไปสู่การแจ้งเตือนที่ไม่ถูกต้องและการวัดที่เบ้ถ้าสิ่งเหล่านี้ขึ้นอยู่กับการวิเคราะห์การใช้ RAM ของ VM ไม่ถูกทำเครื่องหมายเป็น "บอลลูน" เพียงแค่ว่าเป็น "ใช้งาน" โดยระบบปฏิบัติการ

คุณสมบัติอื่น ๆ ที่ vSphere สามารถใช้ได้คือการแบ่งหน้าโปร่งใส (TPS) - ซึ่งเป็นการลบข้อมูลซ้ำซ้อนแรม vSphere จะสแกน RAM ที่จัดสรรทั้งหมดเป็นระยะเพื่อค้นหาหน้าที่ซ้ำซ้อน เมื่อพบมันจะยกเลิกการทำซ้ำและเพิ่มหน้าที่ซ้ำซ้อน

ดูเอกสารทางเทคนิคการจัดการหน่วยความจำของ vSphere (PDF) - โดยเฉพาะ "การเรียกคืนหน่วยความจำใน ESXi" (หน้า 8) - หากคุณต้องการคำอธิบายเชิงลึกเพิ่มเติม

สมมติว่า VM สามารถทำงานใน RAM น้อยกว่ามันเป็นธรรมที่จะบอกว่ามีค่าใช้จ่ายในการกำหนดค่าเครื่องเสมือนกับ RAM มากกว่าที่พวกเขาต้องการ?

ไม่มีค่าใช้จ่ายที่มองเห็นได้ - คุณสามารถจัดสรร RAM ขนาด 100GB บนโฮสต์ที่มี 16 GB (แต่นั่นไม่ได้หมายความว่าคุณควรจะทำด้วยเหตุผลข้างต้น)

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

ความแตกต่างระหว่าง RAM "ใช้งานอยู่" และ "ใช้แล้ว" ในหัวข้อชุมชน VMWareนี้

ข้อโต้แย้งคืออะไร: "ถ้า VM มีการจัดสรร RAM ขนาด 16GB แต่ใช้ 4GB เท่านั้นปัญหาคืออะไร?" ? ลูกค้าจำเป็นต้องได้รับการศึกษาหรือไม่?

คำตอบสั้น ๆ นี้คือใช่ - ลูกค้าควรเสมอได้รับการศึกษาที่ดีที่สุดในการปฏิบัติโดยไม่คำนึงถึงเครื่องมือในการกำจัดของพวกเขา

ลูกค้าควรได้รับการศึกษาขนาด VMs ของพวกเขาเป็นไปตามสิ่งที่พวกเขาใช้มากกว่าสิ่งที่พวกเขาต้องการ หลายครั้งที่ผู้คนจะระบุ VMs ของตัวเองมากเกินไปเพราะพวกเขาอาจต้องการ RAM ขนาด 16 GB ถึงแม้ว่าพวกเขาจะล้มเหลวในประวัติศาสตร์ใน 2 GB ทุกวัน ในฐานะผู้ดูแลระบบ vSphere คุณมีความรู้เมตริกและพลังที่จะท้าทายพวกเขาและถามพวกเขาว่าพวกเขาต้องการ RAM จริงหรือไม่

ที่กล่าวว่าหากคุณรวมการจัดการหน่วยความจำของ vSphere กับข้อ จำกัด overcommit ที่ควบคุมอย่างระมัดระวังคุณไม่ค่อยมีปัญหาในทางปฏิบัติความน่าจะเป็นของ RAM ในระยะเวลานานนั้นค่อนข้างไกล

นอกจากนี้ vMotion แบบอัตโนมัติ (เรียกว่าDistributed Resource Schedulingโดย VMware) เป็นตัวสร้างสมดุลสำหรับ VMs ของคุณ - หาก VM ตัวเดียวกลายเป็นหมูทรัพยากร DRS ควรโยกย้าย VM ไปรอบ ๆ เพื่อใช้ประโยชน์ทรัพยากรของคลัสเตอร์ให้ดีที่สุด

ตัวชี้วัดที่เฉพาะเจาะจงใดที่ควรใช้ในการวัดการใช้ RAM ติดตามยอดของ "ใช้งาน" กับเวลา?

โดยส่วนใหญ่จะกล่าวถึงข้างต้น - ข้อกังวลหลักของคุณคือการใช้ RAM "ใช้งานได้" แม้ว่าคุณควรกำหนดเกณฑ์ overcommit ของคุณอย่างรอบคอบเพื่อให้ได้อัตราส่วนที่แน่นอน ( นี่เป็นตัวอย่างที่ดีแม้ว่าอาจจะล้าสมัยเล็กน้อย) โดยทั่วไปฉันจะอยู่ภายใน 120% ของ RAM คลัสเตอร์ทั้งหมด แต่ก็ขึ้นอยู่กับคุณที่จะตัดสินใจว่าอัตราส่วนใดที่คุณพอใจ

บทความ / การสนทนาที่ดีสองสามข้อเกี่ยวกับความจำที่มากเกินไป:

• หน่วยความจำ overcommit ในการผลิต? ใช่ใช่ใช่
• vSphere - โอเวอร์คล็อกหน่วยความจำ?
• หน่วยความจำทับซ้อนใน vSphere

นอกจากคำตอบที่ยอดเยี่ยมจาก Craig Watson ฉันต้องการเพิ่มต่อไปนี้:

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

หากการมอบหมายมากเกินไปเป็นเพียงตัวเลือกเดียวฉันขอแนะนำให้คุณบังคับใช้กฎที่มีความสำคัญ หากใครบางคนก้มลงมอบ VM 16GB ที่ไม่สำคัญเมื่อต้องการเพียง 4GB - อย่างน้อยก็วาง VM นั้นไว้ในกลุ่มทรัพยากรต่ำหรือให้ความสำคัญต่ำ คุณไม่ต้องการให้ฐานข้อมูลการผลิตที่สำคัญถูกสับเปลี่ยนโดยไฮเปอร์ไวเซอร์ ไม่เพียง แต่ประสิทธิภาพจะลดลงไปตามท่อระบายน้ำเท่านั้น แต่ยังจะกินคิว I / O กับที่เก็บข้อมูลส่วนหลัง

หากคุณกำลังใช้งานพื้นที่จัดเก็บข้อมูลที่รวดเร็ว (ฟิวชั่น, ไวโอลิน, ฯลฯ ของโลคัล SSD) ดังนั้นการแลกเปลี่ยนอาจไม่ใช่เรื่องใหญ่ แต่ด้วยหน่วยเก็บข้อมูล SAN แบบดั้งเดิมคุณจะมีผลต่อ VM และโฮสต์ที่เชื่อมต่อกับอาเรย์ / คอนโทรลเลอร์เดียวกัน