Ist die von VMware eingesetzte Gangplanung ein schwerwiegender Nachteil?

Ich habe einige Technet-Artikel sowie diesen gelesen, in denen es um die Unterschiede zwischen VMware und hyper v bei der CPU-Planung geht.

Ich habe mich gefragt, ob ich objektive Informationen dazu bekommen könnte. Es scheint, dass die von VMware verwendete Gangplanung ein RIESIGER Nachteil ist, aber ich möchte nicht nur den Coolaid trinken. Beeinträchtigt es die Leistung ernsthaft oder lösen die neuesten Iterationen der Hypervisoren von VMware dieses Problem?

Bearbeiten: Wenn ich Nachteil sage, meine ich relativ zu Hyper V "freie Prozessorplanung" oder wie auch immer KVM es tut. Das Material, das ich las, sagte nicht, dass es irgendwelche Probleme mit der "freien Prozessoreinteilung" gab, die mit der Gruppeneinteilung vermieden werden.

Wie Bloody Mary in einen dunkel erleuchteten Badezimmerspiegel zu singen , wollen wir mal sehen, ob Jake Oshins auftaucht ...

Gang-Scheduling wird auch als Co-Scheduling bezeichnet. Ich denke, VMware bevorzugt den Begriff Co-Scheduling gegenüber Gang-Scheduling.

In ESX-Versionen vor Version 3.x verwendete VMware die "strikte" gemeinsame Planung, die die Synchronisierungsnachteile aufwies. In ESX 3.x und höher hat VMware auf "entspanntes" Co-Scheduling umgestellt.

Entspanntes Co-Scheduling ersetzte das strikte Co-Scheduling in ESX 3.x und wurde in nachfolgenden Releases verbessert, um eine bessere CPU-Auslastung zu erzielen und breite virtuelle Multiprozessor-Maschinen zu unterstützen. Entspanntes Co-Scheduling hat im Vergleich zum strengen Co-Scheduling-Algorithmus einige Besonderheiten. Am wichtigsten ist jedoch, dass beim strengen Co-Scheduling-Algorithmus aufgrund einer verzögerten vCPU die gesamte virtuelle Maschine gleichzeitig gestoppt wird. Im entspannten Co-Scheduling-Algorithmus entscheidet eine führende vCPU anhand des Versatzes gegenüber der langsamsten geschwisterlichen vCPU, ob sie sich selbst stoppen soll. Wenn der Versatz größer als ein Schwellenwert ist, stoppt sich die führende vCPU selbst. Beachten Sie, dass eine nacheilende vCPU deutlich weniger Fortschritte macht als die schnellste geschwisterliche vCPU. Eine führende vCPU ist eine, die erheblich größere Fortschritte erzielt als die langsamste vCPU für Geschwister. Durch Verfolgen der langsamsten vCPU für Geschwister ist es nun für jede vCPU möglich, ihre eigene Entscheidung zur gemeinsamen Planung unabhängig zu treffen. Wie beim Co-Stop wird auch die Co-Start-Entscheidung individuell getroffen. Sobald die langsamste vCPU für Geschwister fortschreitet, können die gemeinsam gestoppten vCPUs gemeinsam gestartet werden und können abhängig von der Verfügbarkeit der pCPUs geplant werden. Dies löst das CPU-Fragmentierungsproblem im strengen Co-Scheduling-Algorithmus, indem keine Gruppe von vCPUs gemeinsam geplant werden muss. Im vorherigen Beispiel der virtuellen 4-vCPU-Maschine kann die virtuelle Maschine Fortschritte erzielen, selbst wenn nur eine inaktive pCPU verfügbar ist. Dies verbessert die CPU-Auslastung erheblich. Durch Verfolgen der langsamsten vCPU für Geschwister ist es nun für jede vCPU möglich, ihre eigene Entscheidung zur gemeinsamen Planung unabhängig zu treffen. Wie beim Co-Stop wird auch die Co-Start-Entscheidung individuell getroffen. Sobald die langsamste vCPU für Geschwister fortschreitet, können die gemeinsam gestoppten vCPUs gemeinsam gestartet werden und können abhängig von der Verfügbarkeit der pCPUs geplant werden. Dies löst das CPU-Fragmentierungsproblem im strengen Co-Scheduling-Algorithmus, indem keine Gruppe von vCPUs gemeinsam geplant werden muss. Im vorherigen Beispiel der virtuellen 4-vCPU-Maschine kann die virtuelle Maschine Fortschritte erzielen, selbst wenn nur eine inaktive pCPU verfügbar ist. Dies verbessert die CPU-Auslastung erheblich. Durch Verfolgen der langsamsten vCPU für Geschwister ist es nun für jede vCPU möglich, ihre eigene Entscheidung zur gemeinsamen Planung unabhängig zu treffen. Wie beim Co-Stop wird auch die Co-Start-Entscheidung individuell getroffen. Sobald die langsamste vCPU für Geschwister fortschreitet, können die gemeinsam gestoppten vCPUs gemeinsam gestartet werden und können abhängig von der Verfügbarkeit der pCPUs geplant werden. Dies löst das CPU-Fragmentierungsproblem im strengen Co-Scheduling-Algorithmus, indem keine Gruppe von vCPUs gemeinsam geplant werden muss. Im vorherigen Beispiel der virtuellen 4-vCPU-Maschine kann die virtuelle Maschine Fortschritte erzielen, selbst wenn nur eine inaktive pCPU verfügbar ist. Dies verbessert die CPU-Auslastung erheblich. Sobald die langsamste vCPU für Geschwister fortschreitet, können die gemeinsam gestoppten vCPUs gemeinsam gestartet werden und können abhängig von der Verfügbarkeit der pCPUs geplant werden. Dies löst das CPU-Fragmentierungsproblem im strengen Co-Scheduling-Algorithmus, indem keine Gruppe von vCPUs gemeinsam geplant werden muss. Im vorherigen Beispiel der virtuellen 4-vCPU-Maschine kann die virtuelle Maschine Fortschritte erzielen, selbst wenn nur eine inaktive pCPU verfügbar ist. Dies verbessert die CPU-Auslastung erheblich. Sobald die langsamste vCPU für Geschwister fortschreitet, können die gemeinsam gestoppten vCPUs gemeinsam gestartet werden und können abhängig von der Verfügbarkeit der pCPUs geplant werden. Dies löst das CPU-Fragmentierungsproblem im strengen Co-Scheduling-Algorithmus, indem keine Gruppe von vCPUs gemeinsam geplant werden muss. Im vorherigen Beispiel der virtuellen 4-vCPU-Maschine kann die virtuelle Maschine Fortschritte erzielen, selbst wenn nur eine inaktive pCPU verfügbar ist. Dies verbessert die CPU-Auslastung erheblich. Die virtuelle Maschine kann Fortschritte erzielen, selbst wenn nur eine inaktive pCPU verfügbar ist. Dies verbessert die CPU-Auslastung erheblich. Die virtuelle Maschine kann Fortschritte erzielen, selbst wenn nur eine inaktive pCPU verfügbar ist. Dies verbessert die CPU-Auslastung erheblich.

Das obige Snippet stammt aus der Dokumentation von VMware .

VMware verwendet also keine strikte Gangplanung mehr. Ich würde die Dokumentation direkt vom Anbieter als maßgeblicher ansehen.

Das Einzige, was Ihnen harte Zahlen gibt, ist ein Benchmark, der vollständig von der Art des Codes abhängt, den die CPUs ausführen. Aber ich kann Ihnen sagen, dass VMware bei einem solchen Nachteil nicht den Löwenanteil des Virtualisierungsmarktes ausmachen würde.

Okay, Ryan, du hast meinen Tag gemacht. Ich lese dieses Forum nicht mehr so ​​oft wie früher, habe aber zufällig eingecheckt.

Red888, Sie sollten wissen, dass ich ein Softwarearchitekt bin, der bei Microsoft an Hyper-V arbeitet. Ich gehe davon aus, dass die meisten Leute, die dies lesen, durchaus in der Lage sind, auf meinen Namenslink darunter zu klicken und das zu entdecken oder mich sogar zu googeln, aber für diese Antwort ist es nützlich, ganz sicher zu sein, dass die Leute, die dies lesen, keinen Zweifel an meiner Perspektive haben.

Im Allgemeinen ist die Gruppenplanung hilfreich, wenn der Hypervisor keinen Einfluss auf das Verhalten des Betriebssystems hat, das in der VM ausgeführt wird. Dies ist natürlich der Grund, warum VMware so begann. Sie besitzen keine Betriebssysteme und ihr Ziel war es, vorhandene Betriebssysteme funktionsfähig zu machen. Wenn ich sie wäre, hätte ich hier angefangen.

Die Gang-Planung, und VMware würde wahrscheinlich sagen, dass ich damit Recht habe, lässt viele Einschränkungen in Bezug auf die Verwendung der physischen Prozessoren in der Maschine zu. Der Hypervisor kann häufig nicht die richtige Ressource für den Moment finden. Deshalb haben sie ihren Algorithmus im Laufe der Jahre modifiziert und nach Wegen gesucht, um eine besser funktionierende Zeitplanung durchzuführen.

Microsoft (und wahrscheinlich auch mehrere andere Unternehmen) starteten mit einer anderen Sichtweise. Wir besitzen Windows. Wir sorgen dafür, dass Windows sich bei der Virtualisierung gut verhält. Und so wird Gangplanung nicht notwendig sein. Wir werden uns nicht einmal die Mühe machen, einen Gangplaner zu bauen.

Interessanterweise ist es uns bei Microsoft wichtiger, dass Windows im Vergleich zu anderen Betriebssystemen gut läuft, als dass Hyper-V besser aussieht als VMware, KVM, Xen, Oracle, Unisys usw. Daher haben wir die Windows-Benutzeroberflächen veröffentlicht wird verwendet, um mit einem Hypervisor zusammenzuarbeiten. Hier ist ein Link, wenn Sie neugierig sind, obwohl ich es nicht als Schlafenszeitlesung empfehle:

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

Auf diese Weise kann jeder Hypervisor-Anbieter Informationen bereitstellen, die ein kooperatives Verhalten von Windows auslösen. Einige von ihnen haben. Ich weiß ehrlich gesagt nicht, ob VMware dies hat oder tut oder offenlegen wird. Man müsste sie fragen oder jemanden, der ihnen viel Aufmerksamkeit schenkt. Und wenn sie dies tun, wäre ich sehr überrascht, wenn sie ihren Zeitplan nicht geändert hätten, um sich noch mehr zu entspannen. Diese letzte Aussage ist natürlich reine Spekulation.

Mein Fazit lautet also, dass ich bezweifle, dass Sie 2014 eine Kaufentscheidung treffen sollten, die auf der Funktionsweise des Hypervisor-Schedulers basiert. Ich vermute, dass sie mittlerweile alle ziemlich gut sind. Vor ein paar Jahren hätte das vielleicht nicht gestimmt.

Sie sollten Ihre Workloads auf den verschiedenen Systemen testen und prüfen, wie sie funktionieren. Ich wette, Ihre ultimative Leistung hängt davon ab, ob Ihr Speicher und Ihr Netzwerk Ihren Anforderungen entsprechen.