การแข่งขันใน VMware มีจำนวนเท่าใด

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

ฉันเพิ่งดาวน์โหลดและติดตั้งรุ่นทดลองสำหรับชุดการจัดการ Veeam VMware สำหรับ SCOM 2012 แต่ฉันรู้สึกลำบากใจที่จะต้องรับตัวเลขที่รายงานมาให้ฉัน ในการพยายามโน้มน้าวเจ้านายของฉันว่าตัวเลขที่บอกฉันนั้นเป็นความจริงฉันเริ่มมองหาลูกค้า VMware เพื่อตรวจสอบผลลัพธ์

ฉันได้ดูบทความ VMware KB นี้แล้ว โดยเฉพาะสำหรับคำจำกัดความของ Co-Stop ซึ่งถูกกำหนดเป็น:

จำนวนเวลาที่เครื่องเสมือน MP พร้อมที่จะทำงาน แต่เกิดความล่าช้าเนื่องจากการช่วงชิง co-vCPU

ซึ่งฉันกำลังจะแปล

guest OS ต้องการเวลาจากโฮสต์ แต่ต้องรอให้ทรัพยากรพร้อมใช้งานและถือได้ว่า "ไม่ตอบสนอง"

คำแปลนี้ดูเหมือนถูกต้องหรือไม่

ถ้าเป็นเช่นนั้นนี่คือที่ที่ฉันมีเวลายากที่จะเชื่อสิ่งที่ฉันเห็น: โฮสต์ที่มี VMs ส่วนใหญ่ที่ "ช้า" กำลังแสดง CPU Co-stop เฉลี่ยที่127,835.94มิลลิวินาที!

นี่หมายความว่าโดยเฉลี่ย VM บนโฮสต์นี้ต้องรอเวลา 2+ นาทีสำหรับเวลาของ CPU หรือไม่

โฮสต์นี้มีซีพียู 4 คอร์สองตัวและมี 1x8 CPU แขกและแขกซีพียู 14x4

ฉันสามารถอธิบายประสบการณ์บางอย่างที่ฉันมีในพื้นที่นี้ ...

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

สำหรับ OP เซิร์ฟเวอร์โฮสต์ ESXi มีซีพียูแบบควอดคอร์สองตัวซึ่งมี 8 ฟิสิคัลคอร์

เค้าโครงของเครื่องเสมือนที่อธิบายไว้คือ 15 ผู้เยี่ยมชมทั้งหมด 1 x 8 vCPU และ 14 x 4 vCPU ระบบ ว่าวิธีการของ overcommitted เกินไปโดยเฉพาะอย่างยิ่งกับการดำรงอยู่ของการเป็นผู้เข้าพักเดียวกับ 8 vCPUs มันไม่มีเหตุผล หากคุณต้องการ VM ที่ใหญ่คุณน่าจะต้องการเซิร์ฟเวอร์ที่ใหญ่กว่า

โปรดลองขนาดที่เหมาะสมของเครื่องเสมือนของคุณ ฉันค่อนข้างแน่ใจว่าพวกเขาส่วนใหญ่สามารถอยู่กับ 2 vCPU การเพิ่มซีพียูเสมือนจริงไม่ได้ทำให้สิ่งต่าง ๆ ทำงานได้เร็วขึ้นดังนั้นหากเป็นการแก้ไขปัญหาด้านประสิทธิภาพก็เป็นแนวทางที่ไม่ถูกต้อง

ในสภาพแวดล้อมส่วนใหญ่ RAM เป็นทรัพยากรที่ จำกัด มากที่สุด แต่ CPU อาจเป็นปัญหาหากมีการช่วงชิงกันมากเกินไป คุณมีหลักฐานของเรื่องนี้ RAM ยังสามารถเป็นปัญหาถ้ามากเกินไปจะจัดสรรให้แต่ละ VMs

เป็นไปได้ที่จะตรวจสอบเรื่องนี้ ตัวชี้วัดที่คุณกำลังค้นหาคือ "CPU Ready%" คุณสามารถเข้าถึงสิ่งนี้ได้จากไคลเอนต์ vSphere โดยเลือก VM และไปที่Performance >> Overviewกราฟ CPU

• CPU ต่ำกว่า 5% - ไม่เป็นไร
• CPU พร้อม 5-10% - ติดตามกิจกรรมอย่างใกล้ชิด
• พร้อม CPU มากกว่า 10% - ไม่ดี

สังเกตเส้นสีเหลืองในกราฟด้านล่าง

คุณจะตรวจสอบสิ่งนี้ในเครื่องเสมือนที่เป็นปัญหาและรายงานกลับมาหรือไม่

คุณระบุความคิดเห็นที่คุณมีโฮสต์ ESXi แบบ quad-core คู่และคุณกำลังใช้หนึ่ง 8vCPU VM และสิบสี่ 4vCPU VMs

หากนี่คือสภาพแวดล้อมของฉันฉันจะถือว่ามันเป็น ไม่มีการลดมากกว่าการจัดเตรียม มากที่สุดฉันจะใส่แขก 4vCPU สี่ถึงหกบนฮาร์ดแวร์ (นี่เป็นการสมมติว่า VMs ที่เป็นปัญหามีโหลดที่ต้องการให้มีจำนวน vCPU ที่สูง)

ฉันสมมติว่าคุณไม่ทราบกฎทอง ... ด้วย VMware คุณไม่ควรกำหนด VM คอร์มากกว่าที่จำเป็น เหตุผล? VMware ใช้การจัดกำหนดการร่วมที่ค่อนข้างเข้มงวดซึ่งทำให้ยากสำหรับ VM ที่จะรับเวลา CPU เว้นแต่ว่าจะมีหลายคอร์ที่พร้อมใช้งานตามที่ได้รับมอบหมาย VM หมายความว่า 4vCPU VM ไม่สามารถทำงานได้ 1 หน่วยยกเว้นว่ามีการเปิดฟิสิคัลคอร์ 4 คอร์ในเวลาเดียวกัน กล่าวอีกนัยหนึ่งก็คือสถาปัตยกรรมที่ดีกว่าคือการมี 1vCPU VM พร้อมกับโหลด CPU 90% จากนั้นจะมี VM 2vCPU ที่มีโหลด 45% ต่อหนึ่งคอร์

ดังนั้น ... เสมอสร้าง VM ด้วย vCPU ขั้นต่ำและเพิ่มเมื่อจำเป็นต้องมีเท่านั้น

สำหรับสถานการณ์ของคุณใช้ Veeam เพื่อตรวจสอบการใช้งาน CPU กับแขกของคุณ ลด vCPU ให้มากที่สุด ฉันยินดีที่จะเดิมพันว่าคุณสามารถไปที่ 2vCPU สำหรับแขก 4vCPU ที่มีอยู่เกือบทั้งหมดของคุณ

จริงอยู่ถ้า VMs ทั้งหมดเหล่านี้มีโหลด CPU จริง ๆ เพื่อต้องการจำนวน vCPU ที่มีอยู่คุณต้องซื้อฮาร์ดแวร์เพิ่มเติม

127,835.94 มิลลิวินาทีเป็นผลรวมและคุณต้องหารด้วยเวลาตัวอย่างเพื่อรับค่า% RDY ที่ถูกต้อง ดูเหมือนว่าคุณได้รับการอ่าน% RDY ที่ถูกต้องแล้วในขณะนี้ คุณสามารถไปได้สูงด้วย vCPU ต่ออัตราส่วน cpu ทางกายภาพ แต่ไม่ใช่วิธีที่คุณทำ

คุณมี Quad vCPU VMs มากเกินไปและแม้แต่ 8 vCPU VM มีการตอบกลับคุณภาพบางอย่างเกี่ยวกับการปรับขนาดที่ถูกต้องและการแบ่งส่วนของการไม่รวมวงจรกับ vCPU น้อยลง สิ่งหนึ่งที่ฉันต้องการชี้แจงก็คือแม้ว่ามันจะไม่ใช่กรณีที่ VM ต้องรอจำนวนของฟิสิคัล CPU ที่เท่ากับจำนวน vCPUs ที่จะใช้งานได้ก่อนที่จะประมวลผลคำสั่งใด ๆ มันเป็นอันตรายมาก ที่จะมีการจัดสรรพื้นที่ส่วนเกินนี้ด้วยอัตราส่วน multi-vCPU VMs ต่อคอร์ฟิสิคัล 64 vCPU ใน 8 แกนเป็นวิธีที่เกินอัตราส่วนสูงสุด 4 ต่อ 1 ฉันคิดว่าคุณมี HT ในตัวประมวลผลเหล่านี้ดังนั้นคุณจึงมีลอจิคัล 16 คอร์? นั่นอาจเป็นสิ่งที่ตกลงกับ 1 และ 2 vCPU VM ที่มีการโหลดเบา แต่ถ้าคุณมีการโหลดจำนวนมากบน VMs มันจะยากที่จะทำสำเร็จ

FYI ตัวประมวลผล HT ไม่ได้ใช้ในการคำนวณที่ใช้ CPU% - หมายถึงถ้าคุณมีลอจิคัล 32 คอร์ที่ทำงานที่ 2.4 Ghz บนเซิร์ฟเวอร์คุณกำลังใช้งาน 100% เมื่อคุณกด 38.4 GHz ดังนั้นเมื่อคุณเห็นค่าเฉลี่ยของโหลดแสดงมากกว่า 1.0 นั่นคือเหตุผล

นี่คือ ESXi Host ที่ใช้อัตราส่วน 3.5 ถึง 1 vCPU ต่อ CPU จริง (รวมถึง HT cores) ด้วยค่าเฉลี่ย% RDY เท่ากับ 3%

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

เราได้ทำการติดตั้ง Veeam ONE ซึ่งให้ความกระจ่างในเรื่องประสิทธิภาพการทำงานของเรา โดยดูที่หน้าจอ CPU Bottlenecks ใน Veeam ONE จากนั้นใช้การแก้ไขปัญหาเครื่องเสมือนที่หยุดการตอบสนอง: การเปรียบเทียบการใช้งาน CPU ของ VMM และ Guestเป็นการอ้างอิงเราได้ค้นพบว่าการโต้แย้งที่ "ยอมรับไม่ได้" นั้นคืออะไร

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