Hyper-V / dynamische Zuweisung vom RAM / Server / Client / Meinungen erwünscht

[Blase 15]

Moin in die Runde,

 

mangels eigener Erfahrungen wollte ich mal horchen, wie ihr das so handhabt und bewertet. Es geht schlicht um die dynamische Zuweisung des Arbeitsspeichers unter Hyper-V. Ich persönlich weise fest zu, aber ich bin hier an einen Verfechter dynamischer Zuweisung geraten - und mangels eigener Erfahrungen kann ich nur zuhören, aber nichts dazu sagen ;-)

 

Was ist hier "best practice"?

 

Klar, mit einer dynamischen Zuweisung "verschwende" ich keinen fest zugewiesenen RAM, der aber vielleicht (grade) nicht genutzt wird. Andererseits, funktioniert diese "Dynamik" uneingeschränkt? Hat das negative Auswirkungen? Gilt das für virtuelle Server UND Clients?

 

Würde mich über kurzes Feedback freuen

 

Gruß

Björn

[NorbertFe 1.808]

"Kommt darauf an!" ;)

Fakt ist, dass einige Applikationen wie bspw. Exchange Server nicht mit dynamischer Ressourcenzuweisung supported sind.

https://technet.microsoft.com/de-de/library/jj619301(v=exchg.160).aspx

Some hypervisors have the ability to oversubscribe/overcommit or dynamically adjust the amount of memory available to a specific guest machine based on the perceived usage of memory in the guest machine as compared to the needs of other guest machines managed by the same hypervisor. This technology makes sense for workloads in which memory is needed for brief periods of time and then can be surrendered for other uses. However, it doesn't make sense for workloads that are designed to use memory on an ongoing basis. Exchange, like many server applications with optimizations for performance that involve caching of data in memory, is susceptible to poor system performance and an unacceptable client experience if it doesn't have full control over the memory allocated to the physical or virtual machine on which it's running. As a result, using dynamic memory or memory overcommit features for Exchange isn't supported.

Ob das jetzt überzeugend wirkt, muß man abschätzen. Im Zweifel gib die Maschinen vor, die das nicht haben sollen/dürfen und der Rest kann dir ja wurscht sein. ;)

 

Bye

Norbert

[Dunkelmann 96]

Moin,

 

es gibt keine pauschalen "best practices". Wichtig ist die Unterstützung durch die eingesetzte Software.

Bei MS Anwendungen ist das recht gut dokumentiert, bei anderen muss man sich etwas mehr anstrengen um eindeutige Aussagen vom Anbieter zu erhalten.

[NilsK 2.786]

Moin,

 

meine Ansichten dazu habe ich recht ausführlich u.a. hier dargelegt:

 

[10 Dinge, die Hyper-V übel nimmt - Cloud & Datacenter Conference Germany 2016 - Channel 9]
https://channel9.msdn.com/Events/community-germany/Cloud--Datacenter-Conference-Germany-2016/10-Dinge-die-Hyper-V-uebel-nimmt
 

dort Minuten 5:10 bis 18:40.

 

In der Praxis setze ich Dynamic Memory höchst selten ein. Außerhalb von VDI und virtuellen Terminalservern ist es meist eher ein Kennzeichen von schlechter Planung.

 

Gruß, Nils

[Blase 15]

Mahlzeit in die Runde,

 

vielen Dank für die Meinungen - das Thema ist für mich jetzt klarer.

 

Werde noch abschließend bei unserem ERP Lieferanten mal Fragen, wie er das Thema so sieht..

 

@Nils - Dass VDI und Terminal Server die Paradedisziplin bezüglich Dynamic Memory ist, ist verständlich. Aber es hängt ja doch sicherlich trotzdem mit der verwendeten (NICHT Microsoft) Software auf dem (virtuellen) Client / Terminal Server zusammen, oder? Also laut Microsoft ja bei VDI und TS - aber den Software Hersteller der relevanten Systeme sollte man trotzdem fragen...!?

 

Gruß

Björn

[Doso 77]

Bei Linux Gästen immer komplett fest, da hat das einfach zu viele Einchränkungen. Bei Windows Anwendungen machen wir Dynamic Memory, außer es ist anders dokumentiert. Bei lokalen SQL Express Installationen ist es z.B. auch fest. Wobei ich ganz gerne vernünftigen Mindest-RAM setze.

bearbeitet 13. Juni 2016 von Doso

[NilsK 2.786]

Moin,

 

letztlich ist es eine Strategiefrage. Technisch spricht nichts gegen Dynamic Memory, wenn die Applikationen das unterstützen (was im Einzelfall zu klären ist). Strategisch sollte man sich aber überlegen, warum man Dynamic Memory einsetzen will. Oft ist es eher eine Notlösung für zu gering dimensionierte RAM-Ausstattung auf dem Host - dann ist das natürlich nicht eben sinnvoll.

 

In großen Umgebungen kann das Kalkül aufgehen, dass manche VMs mehr RAM brauchen, während andere weniger benötigen. Da kann sich das dann auf einem Host gut ausgleichen. Kritisch sind aber Lastsituationen, in denen "alle" VMs viel RAM brauchen. Da kann Dynamic Memory dann auch nach hinten losgehen. In solchen Fällen hat man mit einer festen Zuweisung und einer ausreichenden Dimensionierung der Hosts bessere Zuverlässigkeit.

 

Dazu kommt das "Noisy Neighbor"-Problem: Eine VM fordert unverhältnismäßig viel RAM an und bremst dadurch andere aus. Das ist mit Dynamic Memory zwar (anders als Mitbewerber wie VMware behaupten) besser gelöst als bei anderen Plattformen, die reines "Overcommit" betreiben, weil Dynamic Memory immer nur wirklich freien RAM umverteilt und einer VM nichts wegnimmt, was sie eigentlich braucht. Trotzdem kann das zu unerwünschten Effekten führen. Die Lösung lautet dann, für eine solche VM das Maximum zu begrenzen - was aber dann schon wieder sehr in die Nähe einer festen Zuweisung geht, die vielleicht leichter zu handhaben wäre.

 

Gruß, Nils

[Doso 77]

Wir haben einen Cluster und genug Reserve. Der VMM optimiert auch alle paar Stunden den Cluster, das sollte also passen.

 

Ich habe halt die Erfahrung gemacht das bei uns eigentlich keiner der Kollegen ein ordentliches Sizing hin bekommt. Da läuft es gerne mal auf "viel hilft viel" raus. Die VM die dann aber 16GB brauchen soll läuft dann in der Praxis mit Dynamic Memory mit knapp 1,2 GB aber prima. Andere Server sollen mit 1 GB auskommen, in der Praxis holen sie sich aber durch Dynamic Memory fast 3 GB. Klappt bei uns ganz gut, aber natürlich ist das kein Allheil-Mittel und man muss wissen was man tut.

[Dunkelmann 96]

Zur Strategie und warum ich so viele VMs wie möglich mit Dynamic Memory ausstatte:

Ich kann mehr Ausfall in meinem Hyper-V Cluster verkraften ohne dass Anwendungen komplett stehen. Raucht mir ein komplettes Chassis mit 4 Sleds ab oder muss ich es für Firmware Updates offline nehmen, reicht es immer noch um die RDS Umgebung und die Anwenungen, wenn auch mit eingeschränkter Leistung, weiter zu betreiben.

 

Off-Topic:
Zum Sizing von Kollegen:

Meine sind nur Self Service User und müssen mit den Vorlagen leben, die ich ihnen bereitstelle.

Sonderlocken müssen wie immer plausibel begründet werden :cool:

[NilsK 2.786]

Moin,

 

zwei valide Beispiele, wo es Sinn ergibt. Ziemlich genau solche Überlegungen meinte ich.

 

Für den interessierten Leser ergänze ich noch: Wie bei jeder "Thin-Provisioning"-Technik gehört auch hier ein adäquates Monitoring dazu.

 

Gruß, Nils

bearbeitet 13. Juni 2016 von NilsK

[Doso 77]

Self Service, schön wäre es. Mein Chef ist der Meinung Vorlagen braucht es eigtl. nicht und man kann auch überall IP-Adressen per Hand eintragen...  :(