Có bao nhiêu sự tranh chấp là quá nhiều trong VMware?

Trong một thời gian, bây giờ tôi đã cố gắng tìm hiểu tại sao khá nhiều hệ thống quan trọng trong kinh doanh của chúng tôi lại nhận được báo cáo về "sự chậm chạp" từ nhẹ đến cực đoan. Gần đây tôi đã hướng mắt về môi trường VMware nơi lưu trữ tất cả các máy chủ nghi vấn.

Gần đây tôi đã tải xuống và cài đặt bản dùng thử cho gói quản lý Veeam VMware cho SCOM 2012, nhưng tôi đang gặp khó khăn trong việc tin tưởng (và ông chủ của tôi cũng vậy) những con số mà nó đang báo cáo cho tôi. Để cố gắng thuyết phục sếp của tôi rằng những con số mà nó nói với tôi là đúng, tôi bắt đầu tìm hiểu chính máy khách VMware để xác minh kết quả.

Tôi đã xem bài viết về VMware KB này ; đặc biệt cho định nghĩa của Co-Stop được định nghĩa là:

Lượng thời gian mà máy ảo MP đã sẵn sàng để chạy, nhưng phát sinh sự chậm trễ do tranh chấp lịch trình đồng vCPU

Mà tôi đang dịch

HĐH khách cần thời gian từ máy chủ lưu trữ nhưng phải chờ tài nguyên sẵn sàng và do đó có thể được coi là "không phản hồi"

Bản dịch này có vẻ đúng không?

Nếu vậy, đây là lúc tôi gặp khó khăn khi tin vào những gì tôi đang thấy: Máy chủ chứa phần lớn các máy ảo "chậm" hiện đang hiển thị mức trung bình Co-stop của CPU là 127.835,94 mili giây!

Điều này có nghĩa là trung bình các máy ảo trên máy chủ này phải chờ hơn 2 phút cho thời gian CPU ???

Máy chủ này có hai CPU 4 nhân và nó có CPU khách 1x8 và khách CPU 14x4.

Tôi có thể mô tả một số kinh nghiệm tôi đã có trong lĩnh vực này ...

Tôi không tin rằng VMware thực hiện một công việc đầy đủ là giáo dục khách hàng ( hoặc quản trị viên ) về các thực tiễn tốt nhất, cũng như họ không cập nhật các thực tiễn tốt nhất trước đây khi các sản phẩm của họ phát triển. Câu hỏi này là một ví dụ về cách một khái niệm cốt lõi như phân bổ vCPU không được hiểu đầy đủ. Cách tiếp cận tốt nhất là bắt đầu nhỏ, với một vCPU duy nhất, cho đến khi bạn xác định rằng VM yêu cầu nhiều hơn.

Đối với OP, máy chủ lưu trữ ESXi có hai CPU lõi tứ, mang lại 8 lõi vật lý.

Bố trí máy ảo đang được mô tả là 15 tổng số khách; 1 x 8 vCPU và 14 x 4 hệ thống vCPU. Đó là cách quá quan trọng, đặc biệt là với sự tồn tại của một khách với 8 vCPU . Không có nghĩa lý gì. Nếu bạn cần một VM lớn, bạn có thể cần một máy chủ lớn hơn.

Hãy cố gắng để kích thước đúng máy ảo của bạn. Tôi khá chắc chắn hầu hết trong số họ có thể sống với 2 vCPU. Thêm CPU ảo không giúp mọi thứ chạy nhanh hơn, vì vậy nếu đó là cách khắc phục vấn đề về hiệu năng, thì đó là cách tiếp cận sai.

Trong hầu hết các môi trường, RAM là tài nguyên bị hạn chế nhất. Nhưng CPU có thể là một vấn đề nếu có quá nhiều sự tranh chấp. Bạn có bằng chứng về điều này. RAM cũng có thể là một vấn đề nếu phân bổ quá nhiều cho từng VM .

Có thể theo dõi điều này. Số liệu bạn đang tìm kiếm là "CPU Ready%". Bạn có thể truy cập ứng dụng này từ máy khách vSphere bằng cách chọn VM và đi tới Performance>> OverviewBiểu đồ CPU.

• Sẵn sàng dưới 5% CPU - Bạn ổn.
• Sẵn sàng cho CPU 5-10% - Hãy theo dõi chặt chẽ hoạt động.
• Hơn 10% CPU sẵn sàng - Không tốt.

Lưu ý đường màu vàng trong biểu đồ bên dưới.

Bạn có phiền kiểm tra điều này trên các máy ảo có vấn đề của bạn và báo cáo lại không?

Bạn nêu trong các nhận xét rằng bạn có máy chủ ESXi lõi tứ kép và bạn đang chạy một máy ảo 8vCPU và mười bốn máy ảo 4vCPU.

Nếu đây là môi trường của tôi, tôi sẽ xem xét điều đó là hiển nhiên quá mức trích lập dự phòng. Tôi nhiều nhất sẽ đặt bốn đến sáu khách 4vCPU trên phần cứng đó. (Điều này giả định rằng các máy ảo được đề cập có tải yêu cầu chúng phải có số lượng vCPU cao như vậy.)

Tôi cho rằng bạn không biết quy tắc vàng ... với VMware, bạn không bao giờ nên gán cho VM nhiều lõi hơn mức cần thiết. Lý do? VMware sử dụng việc lập lịch trình hơi nghiêm ngặt khiến cho VM khó có được thời gian CPU trừ khi có sẵn nhiều lõi như VM được chỉ định. Có nghĩa là, máy ảo 4vCPU không thể thực hiện 1 đơn vị công việc trừ khi có 4 lõi vật lý mở cùng một lúc. Nói cách khác, về mặt kiến ​​trúc sẽ tốt hơn khi có máy ảo 1vCPU với tải CPU 90%, sau đó có máy ảo 2vCPU với tải 45% cho mỗi lõi.

Vì vậy, ... LUÔN LUÔN tạo VM với tối thiểu vCPU và chỉ thêm chúng khi cần xác định.

Đối với tình huống của bạn, hãy sử dụng Veeam để theo dõi việc sử dụng CPU đối với khách của bạn. Giảm số lượng vCPU càng nhiều càng tốt. Tôi sẵn sàng đặt cược rằng bạn có thể giảm xuống 2vCPU cho hầu hết tất cả các khách 4vCPU hiện tại của bạn.

Cấp, nếu tất cả các máy ảo này thực sự có tải CPU để yêu cầu số lượng vCPU mà chúng có, thì bạn chỉ cần mua phần cứng bổ sung.

127.835,94 mili giây là tổng của bạn và bạn cần chia cho thời gian mẫu để có được các giá trị% RDY chính xác. Dường như bây giờ bạn đã nhận được các bài đọc% RDY chính xác. Bạn có thể tăng khá cao với tỷ lệ vCPU so với cpu vật lý nhưng không phải theo cách bạn đang làm.

Bạn có quá nhiều máy ảo vCPU quad và thậm chí là máy ảo 8 vCPU. Có một số câu trả lời chất lượng đã thảo luận về kích thước phải và một số phân nhánh không hợp nhất chu kỳ với ít vCPU hơn. Một điều tôi muốn làm rõ là mặc dù VM không phải đợi số lượng CPU vật lý tương đương với số lượng vCPU của nó có sẵn trước khi bất kỳ lệnh nào có thể được xử lý, điều đó rất bất lợi được cung cấp quá mức độ lớn này với tỷ lệ của VM đa vCPU so với lõi vật lý. 64 vCPU trên 8 lõi vượt quá tỷ lệ tối đa 4 đến 1. Tôi giả sử bạn có HT trên các bộ xử lý này để bạn có 16 lõi logic? Điều đó có thể ổn với các máy ảo vCPU 1 và 2 có tải nhẹ nhưng nếu bạn tải nặng máy ảo thì khó có thể thực hiện được.

FYI Bộ xử lý HT không được sử dụng trong các tính toán% CPU được sử dụng - có nghĩa là nếu bạn có 32 lõi logic chạy ở tốc độ 2,4 Ghz trên máy chủ, bạn đang sử dụng 100% khi bạn đạt 38,4 GHz. Vì vậy, khi bạn thấy trung bình tải hiển thị nhiều hơn 1.0, đó là lý do.

Dưới đây là Máy chủ ESXi đang chạy tỷ lệ 3,5 đến 1 vCPU cho CPU vật lý (bao gồm cả lõi HT) với% RDY trung bình là 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

......

Kể từ khi chúng tôi cài đặt Veeam ONE đã làm sáng tỏ khá nhiều vấn đề về hiệu suất của chúng tôi. Bằng cách nhìn vào màn hình Tắc nghẽn CPU trong Veeam ONE sau đó sử dụng Khắc phục sự cố một máy ảo đã ngừng phản hồi: So sánh sử dụng CPU VMM và Guest như một tài liệu tham khảo, chúng tôi đã tìm ra sự phân bổ của sự tranh chấp "không thể chấp nhận" của chúng tôi.

Một mẹo nhỏ mà tôi muốn chia sẻ cụ thể là trong một trường hợp, tôi không thể loại bỏ sự tranh chấp CPU cho đến khi tôi xóa ảnh chụp nhanh trên VM. Hy vọng điều này sẽ giúp được ai đó.