Czy planowanie gangów przez VMware jest poważną wadą?

Czytałem kilka artykułów o technecie, a także ten dotyczący różnic między sposobem, w jaki VMware i hyper v wykonują planowanie procesora.

Zastanawiałem się, czy mogę uzyskać obiektywne informacje na ten temat. Wydawałoby się, że harmonogram gangów wykorzystywany przez VMware jest OGROMNYM mankamentem, ale nie chcę po prostu wypić coolaida. Czy ma to poważny wpływ na wydajność, czy też rozwiązują to najnowsze iteracje hiperwizorów VMware?

Edycja: Kiedy mówię „wada”, mam na myśli „wolne planowanie procesora” Hyper V lub to, co robi KVM. W materiale, który czytałem, nie stwierdzono żadnych problemów z „wolnym planowaniem procesorów”, których unika się przy planowaniu grup.

Jak intonowanie Krwawej Mary w ciemno oświetlonym lustrze w łazience, zobaczmy, czy możemy sprawić, by pojawił się Jake Oshins ...

Planowanie grupowe jest również określane jako wspólne planowanie. Wydaje mi się, że VMware woli termin „wspólne planowanie” niż planowanie grupowe.

W wersjach ESX wcześniejszych niż 3.x VMware stosowało „ścisłe” wspólne planowanie, co miało wady synchronizacji. W ESX 3.xi nowszych VMware przełączyło się na „zrelaksowane” współsprawianie.

Zrelaksowane współdziałanie zastąpiło ścisłe współdziałanie w ESX 3.x i zostało udoskonalone w kolejnych wydaniach w celu lepszego wykorzystania procesora i obsługi szerokopasmowych maszyn wirtualnych. Zrelaksowane wspólne planowanie ma kilka charakterystycznych właściwości w porównaniu do ścisłego algorytmu wspólnego planowania. Co najważniejsze, podczas gdy w algorytmie ścisłego wspólnego planowania istnienie opóźnionego vCPU powoduje zatrzymanie całej maszyny wirtualnej. W uproszczonym algorytmie współsprawiania wiodący procesor vCPU decyduje, czy powinien się zatrzymać na podstawie pochylenia względem najwolniejszego procesora vCPU z rodzeństwa. Jeśli pochylenie jest większe niż próg, wiodąca jednostka vCPU zatrzymuje się sama. Pamiętaj, że opóźnione vCPU to takie, które robi znacznie mniejszy postęp niż najszybszy vCPU z rodzeństwa, podczas gdy wiodący vCPU to taki, który robi znacznie większy postęp niż najwolniejszy vCPU z rodzeństwa. Dzięki śledzeniu najwolniejszego procesora vCPU z rodzeństwa możliwe jest, aby każdy procesor vCPU samodzielnie podejmował własną decyzję dotyczącą wspólnego planowania. Podobnie jak co-stop, decyzja o ponownym uruchomieniu podejmowana jest również indywidualnie. Po rozpoczęciu postępów najwolniejszego procesora vCPU z rodzeństwa współdziałające procesory vCPU kwalifikują się do ponownego uruchomienia i można je zaplanować w zależności od dostępności pCPU. Rozwiązuje to problem fragmentacji procesora w ścisłym algorytmie współsprawiania, nie wymagając, aby grupa procesorów vCPU była planowana razem. W poprzednim przykładzie maszyny wirtualnej 4-vCPU maszyna wirtualna może robić postępy do przodu, nawet jeśli dostępna jest tylko jedna bezczynna pCPU. To znacznie poprawia wykorzystanie procesora. Dzięki śledzeniu najwolniejszego procesora vCPU z rodzeństwa możliwe jest, aby każdy procesor vCPU samodzielnie podejmował własną decyzję dotyczącą wspólnego planowania. Podobnie jak co-stop, decyzja o ponownym uruchomieniu podejmowana jest również indywidualnie. Po rozpoczęciu postępów najwolniejszego procesora vCPU z rodzeństwa współdziałające procesory vCPU kwalifikują się do ponownego uruchomienia i można je zaplanować w zależności od dostępności pCPU. Rozwiązuje to problem fragmentacji procesora w ścisłym algorytmie współsprawiania, nie wymagając, aby grupa procesorów vCPU była planowana razem. W poprzednim przykładzie maszyny wirtualnej 4-vCPU maszyna wirtualna może robić postępy do przodu, nawet jeśli dostępna jest tylko jedna bezczynna pCPU. To znacznie poprawia wykorzystanie procesora. Dzięki śledzeniu najwolniejszego procesora vCPU z rodzeństwa możliwe jest, aby każdy procesor vCPU samodzielnie podejmował własną decyzję dotyczącą wspólnego planowania. Podobnie jak co-stop, decyzja o ponownym uruchomieniu podejmowana jest również indywidualnie. Po rozpoczęciu postępów najwolniejszego procesora vCPU z rodzeństwa współdziałające procesory vCPU kwalifikują się do ponownego uruchomienia i można je zaplanować w zależności od dostępności pCPU. Rozwiązuje to problem fragmentacji procesora w ścisłym algorytmie współsprawiania, nie wymagając, aby grupa procesorów vCPU była planowana razem. W poprzednim przykładzie maszyny wirtualnej 4-vCPU maszyna wirtualna może robić postępy do przodu, nawet jeśli dostępna jest tylko jedna bezczynna pCPU. To znacznie poprawia wykorzystanie procesora. Po rozpoczęciu postępów najwolniejszego procesora vCPU z rodzeństwa współdziałające procesory vCPU kwalifikują się do ponownego uruchomienia i można je zaplanować w zależności od dostępności pCPU. Rozwiązuje to problem fragmentacji procesora w ścisłym algorytmie współsprawiania, nie wymagając, aby grupa procesorów vCPU była planowana razem. W poprzednim przykładzie maszyny wirtualnej 4-vCPU maszyna wirtualna może robić postępy do przodu, nawet jeśli dostępna jest tylko jedna bezczynna pCPU. To znacznie poprawia wykorzystanie procesora. Po rozpoczęciu postępów najwolniejszego procesora vCPU z rodzeństwa współdziałające procesory vCPU kwalifikują się do ponownego uruchomienia i można je zaplanować w zależności od dostępności pCPU. Rozwiązuje to problem fragmentacji procesora w ścisłym algorytmie współsprawiania, nie wymagając, aby grupa procesorów vCPU była planowana razem. W poprzednim przykładzie maszyny wirtualnej 4-vCPU maszyna wirtualna może robić postępy do przodu, nawet jeśli dostępna jest tylko jedna bezczynna pCPU. To znacznie poprawia wykorzystanie procesora. maszyna wirtualna może robić postępy, nawet jeśli dostępna jest tylko jedna bezczynna pCPU. To znacznie poprawia wykorzystanie procesora. maszyna wirtualna może robić postępy, nawet jeśli dostępna jest tylko jedna bezczynna pCPU. To znacznie poprawia wykorzystanie procesora.

Powyższy fragment pochodzi z własnej dokumentacji VMware .

Tak więc VMware nie używa już ścisłego planowania gangów. Traktowałbym dokumentację bezpośrednio od dostawcy jako bardziej autorytatywną.

Jedyną rzeczą, która da ci twarde liczby, jest test porównawczy i będzie on całkowicie zależny od rodzaju kodu uruchomionego przez procesory. Mogę jednak powiedzieć, że gdyby VMware znajdowało się w takiej niekorzystnej sytuacji, nadal nie mieliby lwią część rynku wirtualizacji.

Okej, Ryan, zrobiłeś mi dzień. Nie czytam tego forum tak często jak kiedyś, ale zdarzyło mi się to zameldować.

Red888, powinieneś wiedzieć z góry, że jestem architektem oprogramowania, który pracuje na Hyper-V w Microsoft. Zakładam, że większość osób, które to czytają, jest w pełni zdolna do kliknięcia linku do mojego imienia poniżej i odkrycia tego, a nawet Googlowania mnie, ale w przypadku tej odpowiedzi warto mieć całkowitą pewność, że osoby czytające to nie mają wątpliwości co do mojej perspektywy.

Zasadniczo planowanie grup jest przydatne, jeśli hiperwizor nie ma żadnego wpływu na zachowanie systemu operacyjnego działającego na maszynie wirtualnej. Właśnie dlatego VMware zaczęło w ten sposób. Nie posiadają żadnych systemów operacyjnych, więc ich celem było sprawienie, aby istniejące systemy operacyjne działały dobrze. Gdybym był nimi, to od tego bym zaczął.

Planowanie gangów, a VMware prawdopodobnie powiedziałoby, że mam rację co do tego, pozostawia wiele ograniczeń w zakresie korzystania z fizycznych procesorów w maszynie. W tej chwili hiperwizor często nie może znaleźć odpowiedniego zasobu. Dlatego przez lata zmodyfikowali swój algorytm, szukając sposobów na lepsze planowanie.

Microsoft (i prawdopodobnie kilka innych firm) zaczął od innego spojrzenia. Posiadamy system Windows. Sprawimy, że Windows będzie się dobrze zachowywał podczas wirtualizacji. Dlatego planowanie gangów nie będzie konieczne. Nie będziemy nawet zawracać głowy budowaniem harmonogramu gangów.

Co ciekawe, w Microsoft dbamy bardziej o to, aby Windows działał dobrze w porównaniu z innymi systemami operacyjnymi, niż o Hyper-V wyglądający lepiej niż VMware, KVM, Xen, Oracle lub Unisys itp. Więc opublikowaliśmy interfejsy, które Windows używa do współpracy z hiperwizorem. Oto link, jeśli jesteś ciekawy, chociaż nie polecam go do czytania przed snem:

http://www.bing.com/search?q=Hypervisor+Top-Level+Functional+Specification+3.0a%3A+Windows+Server+2012&src=IE-SearchBox&FORM=IESR02

Tak więc każdy dostawca hiperwizora może ujawnić rzeczy, które wywołają zachowanie współpracy z Windows. Kilka z nich ma. Szczerze mówiąc, nie wiem, czy VMware to zrobiło, ujawnia lub ujawnia. Będziesz musiał ich zapytać lub kogoś, kto zwraca na nie dużą uwagę. A jeśli tak, byłbym bardzo zaskoczony, gdyby nie zmodyfikowali swojego harmonogramu, aby jeszcze bardziej się zrelaksować. To ostatnie stwierdzenie jest oczywiście czystą spekulacją.

Tak więc moją podstawową odpowiedzią jest to, że wątpię, że powinieneś podjąć decyzję o zakupie w 2014 r. W oparciu o działanie harmonogramu hiperwizora. Podejrzewam, że do tej pory są całkiem niezłe. Kilka lat temu mogło to nie być prawdą.

Powinieneś spróbować swoich obciążeń w różnych systemach i zobaczyć, jak one działają. Założę się, że twoja najwyższa wydajność sprowadza się do tego, czy pamięć i sieć spełniają twoje potrzeby.