vmware Resource Management – Resource Pools – wie nutzen?

In meinem letzten Artikel „vmware-resource-management-shares-was-ist-das“ habe ich versucht das Thema Resource Management und die Einstellmöglichkeiten für VMs in vmware vSphere zu behandeln. Schwerpunkt lag auf den oft falsch interpretierten „Shares“.

Nun möchte ich gern das Thema Resource Pools und deren Nutzen und Risiken beschreiben.

Global betrachtet sind Resource Pools in vmware von zwei Seiten anzugehen.

1. Gruppen von VMs mit gleichen Resource Einstellungen bezüglich Limits, Reservations und Shares.
2. Objekte die Hierarchiene abbilden können, sowie Resourcen von Hardware separieren.

Gleich vorweg, die Zweite Seite ist bedeutend schwieriger und komplexer zu betrachten als die erste.

Wenn man den Bedarf hat für viele VMs Resource Einstellungen zu tätigen, z.B. um sie unterschiedlich zu priorisieren, sind Resource Pools eine einfache Möglichkeit solche „Prioritäten-gruppen“ zu erstellen. Nun muß man VMs nur noch in diese Pools verschieben und die festgelegten Konfigurationen gelten für sie. Dabei sollte man allerdings einige Design Best Practices beachten. Diese habe ich aus einer VMWorld Session von Frank Denneman und Duncan Epping übernommmen.

A. NIE mehr als drei Ebenen von Resource Pools definieren!
B. Wenn Resource Pools, dann KEINE VMs auf gleicher Ebene wie Resource Pools, sondern die VMs immer in die unterste Resource Pool Ebene plazieren.

Dabei bitte beachten „vApps sind IMMER auch Resource Pools“

Was man mit Resource Pools nicht tun sollte, ist die Abbildung von Unternehmens Organigrammen oder Hierarchien! Es ist zwar möglich auch auf Resource Pools Rechte zu vergeben, aber nur dafür ist der Aufwand den man dem vmkernel bzw. dem vCenter Server verschafft zu groß. Jetzt fangen diese nämlich an Resource Management zu betreiben, obwohl das garnicht geplant war.

Was man machen kann, ist die Bildung von Resource Silos mit Hilfe von Resource Pools!
Dieses kann durch einen, oft nicht beachteten oder gekannten Schalter in der Resource Pool Konfiguration erfolgen.

Es handelt sich um den Schalter „Expandable Reservation„.
Dazu muß etwas ausgeholt werden.

Was ist denn der Root-Resource Pool einer vSphere Umgebung?
I. Bei einem Single-Host der ESX/ESXi Host selbst!
II. Bei einem vSphere Cluster die gesamten Cluster-Resourcen!!!

(Einschränkung: Im Cluster gibt es nur dann Resource Pools (und auch vApps!!) wenn DRS aktiv ist. Somit haben alle Kunden der Standard Lizenz zwar HA und somit Cluster, aber keine Resource Pools (bitte beachten).)

Expandable Reservation bedeutet, das wenn ein Kind-Resource Pool keine Resourcen mehr bereitstellen kann, er diese beim übergeordneten Resource Pool anfragt, sofern der Schalter „Expandable Reservation“ gesetzt ist – Bedenke im Zweifelsfall ist das der Host oder Cluster!

Ist der Schalter nicht gesetzt, kann unter Umständen einen Reservation nicht erfüllt werden und eine oder mehrere VMs bleiben aus. Setzt man z.B. in der ersten Resource Pool Eben statt Reservations – Limits, könnte man dadurch Silos bauen die von Host Resourcen unabhängig sind.

So könnte ein Provider z.B. jedem Kunden, je nach dem was er zahlt, eine Limit bestimmter MHz CPU Leistung und GB RAM zuteilen. Gesteuert über einen „Kunden“ Resource Pool der nicht „Expandable“ ist. Nun kann dieser Kunde nichts „anstellen“ was alle anderen Kunden der gleichen Umgebung beeinflusst.

Was halten Sie von dieser Idee?

Kommentare erwünscht.

Demnächst mehr !

Wie zuviele vCPUs eine negative Performance verursachen – from Gabes Virtual World

How too many vCPUs can negatively affect your performance – Gabes Virtual World.

Dieser Artikel beschreibt sehr plastisch und praxisnah was „viel nicht immer Viel hilft!“ Problem sind einfach parallele CPU- Slots und vielens mehr, was dem vmkernel das Leben bei SMP VMs nun mal schwerer macht. Oft hilft die Reduzierung auf weniger vCPUs und siehe da – wie beschrieben rennt es.

vmware Resource Management – Shares was ist das?

vmware bietet dem Administrator in jeder Edition einige Einstellmöglichkeiten um Virtuelle Maschinen [VMs] Performence-technisch zu steuern und zu priorisieren.

Dieses sind vor allem die Möglichkeit Memory (RAM) und CPU (MHz) einer VM zu limitieren bzw. zu reservieren. Dieses sind die sogenannten „Limits“ und „Reservations“ – siehe Screenshot.

Eine weitere Möglichkeit besteht darin VMs unterschiedlich zu priorisieren. Dieses geschied über die sogenannten „Shares“. Was sind nun Shares und was kann man damit machen?

Als erstes sei gesagt, das all diese Einstellmöglichkeiten nur dann Verwendung finden sollten wenn es wirklich benötigt wir und einiges nur im Falle eines Resourcen Engpasses zum Tragen kommt. Haben Sie in Ihrer Umgebung kein „Overcommitment“, also mehr Resourcen verteilt als Sie physikalisch haben, brauchen Sie sich z.B. über die Einstellung von Shares für RAM und CPU keine Gedanken machen.
Halten Sie Ihre Umgebung so einfach wie möglich!

Wenn Sie allerdings VMs priorisieren müssen (zu wenig physikalischer RAM oder CPU lastige VMs) dann bieten sich die Share Einstellungen der einzelnen VM bzw. eines Resource-Pools (in einem späteren Artikel) dazu an.

vmware bietet hier die Möglichkeit von drei vordefinierten Einstellunge oder alternativ einem frei einstellbaren Wert. Vorgegeben sind dabei:

• Low      := 500 Shares
• Normal := 1000 Shares
• High     := 2000 Shares

Dieses bedeutet das eine VM welche auf High in Bezug auf den RAM Bedarf gesetzt wird vom VMKernel eben bevorzugt mit physikalischen RAM versorgt wird, oder umgedreht – als letzte z.B. zum baloonen oder swappen genötigt wird.

Aber was ist nun ein Share?  Erst einmal gar nichts! Denn Shares haben mehrere Fakten die zu beachten sind.

1. Shares sind KEINE Prozentualen Anteile an einer Resource!
2. Shares haben keine direkte Wertigkeit!
   Soll heissen: Ob Sie allen VMs Einstellung im Bereich 10 / 20 / 40 Shares oder 5000 / 10.000 / 20.000 Shares geben spielt keine Rolle.
3. Shares sind immer nur im Zusammenhang mit den Einstellungen der anderen VMs eines Hostes bzw. Clusters zu betrachten!
   Einstellungen einer einzelnen VM ohne Kenntnis der anderen VMs sind ohne Aussage!

Eine kurze Grafik soll dieses Erläutern:

Hier sehen wir in Status A erst mal alle VMs eines Hostes (oder Clusters) gleich priorisiert. Alle stehen auf Normal und haben somit prinzipiell Anspruch auf den gleichen Anteil (z.B. der CPUs)

Wir nun eine VM auf 3000 Shares gesetzt Status B verschiebt sich die Priorisierung zugunsten dieser VM. Nachfolgende Grafik soll die effektiven „Ansprüche“ verdeutlichen.

Status C zeigt die Veränderung durch das Ausschalten einer VM und Status D dann das hinzufügen einer „very High“ Shared VM. Was tatsächlich für die VMs bleibt zeigt die Grafik unten

In dieser Grafik wird die Verteilung anhand der Verschiedenen Stati und deren Verteilung in „Kuchenstücke“ gezeigt.

In meinen Kursen versuche ich immer den Spruch zu prägen „Einen Kuchen kann man nur einmal teilen! Je mehr Mitesser, desto kleiner die Stücke„. Wenn nun ein Mitesser höher priorisiert ist erhält Er eben einen doppelten oder n-fachen Anteil der anderen. Trotzdem ist der Kuchen nur einmal zu teilen!

Somit kann man Shares nicht immer leicht fassen, da man die Gesamtsituation betrachten muß und nur dann Rückschlüsse auf das VMKernel Verhalten im Fall des Resourcen Engpasses sehen.

Im Gegensatz zu Reservations sind Shares somit eher eine „weiche“ Einstellmöglichkeit ohne feste Werte. Bedeutet, ich muß, um z.B. eine tatsächliche Höherpriorisierung eine VM zu erreichen, diese mit einem „signifikant“ höheren Share – Wert versehen. Also alle VMs auf 1000 Shares und eine auf 1010 Shares macht sehr wenig Sinn. Vor allem ändert sich die Auswirkung mit der Anzahl der VMs auf dem Host bzw. Cluster, so das hier möglicherweise später „nachgebessert“ werden muß.

Um dieses in großen Umgebungen bzw. für ganze Gruppen von VMs nun nicht einzeln konfigurieren zu müssen existieren die sogenannten Resource-Pools. Diese möchte ich demnächst in einem weiteren Artikel behandeln.

virtualization.info | VKernel releases Integration Support with Microsoft System Center 2012

VKernel unterstützt nun ebenso wie Quest vFoglight Pro und einige ander neben vmware vSphere aus Microsoft Hyper-V.  Leben diese beiden Welten wirklich in einem RZ friedlich miteinander?

Interessante Frage. Der Hypervisor rückt doch etwas in den Hintergrund. Management und Operating inkl. Automatisierung in den Vordergrund.

virtualization.info | VKernel releases Integration Support with Microsoft System Center 2012.

vmware Performance Management – Top 5 Performanc Problems – Solutions

Anschließend an den ersten Artikel zum Thema vmware Performance Management ein weiter Hinweis zu einem, ebenfalls interessanten WhitePaper von den vkernel Kollegen.
(werde nich von vkernel gesponsort – Dokus sind in meinen Augen einfach sehr brauchbar!)
http://www.vkernel.com/resources/whitepapers/top-5-vm-performance-problems

Hier beschreibt David Davis fünf der häufigsten Performance Probleme unter vmware und wie man sie mit „Bordmitteln“ also nur mit Hilfe des vCenter Servers messen bzw. analysieren kann. Also keine Extra Tools!

Das allein ehrt schon den Autor. Oft wird solch ein Dokument benutzt um ein Tool anzupreisen und zu zeigen was man damit alles tolles machen kann.

Hier bleibt, gerade für Consultants alles handhabbar!

vmware HA – Host isolation response Einstellungen

vmware HA – Alte und wichtige Funktionalität, in vSphere 5 völlig neu erstellt, aber immer wieder falsch verstanden

vmware HA ist mittlerweile fast bis in die kleinste Edition gewandert. In vSphere 5 wurde HA komplett neu von vmware geschrieben. Trotzdem gibt es immer wieder Unklarheiten, Falschkonfiguratione und div. „Unwissen“ über Einstellmöglichkeiten.

Ein kurzes Vorwort zur geplanten Serie von Artikeln

In meinen Augen ist der vmware Mitarbeiter und Blogger Duncan Epping (http://www.yellow-bricks.com) der Guru in Sachen HA und auch DRS.

Ich möchte nun hier einige dieser sehr nützlichen Artikel in deutsch wiedergeben und geg. ergänzen. Mein besonderer Dank geht hier an Duncen der mir auf Anfrage sofort erlaubt hat Seine Artikel als Grundlage zu nutzen! Am Ende meines Artikels verweise ich daher immer auf das Original.
__________________________________________________

Host isolation response – Was ist das?

HA oder High Availability als vmware Funktion ist gedacht den Ausfall eine ESX/ESXi Hostes abzufangen in dem die, auf dem ausgefallenen Host laufenden VMs auf den verbleibenden Hosts neu gestartet werden.

Soweit so klar. Betrachtet man die Funktionsweise von vmware HA dann kommt man leicht zu dem Schluß: „Was passiert wenn der Host gar nicht ausgefallen ist, sondern nur HA einen Ausfall meldet?“ Dieses würde passieren wenn die ESX/ESXi Hosts des HA Clusters keinen Heartbeat von einem Host mehr erhalten (repektive der Master).

Der so isolierte Host wird sich selbst ebenfalls als isoliert betrachten (genauer Ablauf wir jetzt hier nicht behandelt). Was soll dieser Host nun mit seinen VMs tun?

vmware sieht für diese Fall drei Möglichkeiten vor:

Diese bedeuten:

• Leave powered on     := „Du erkennst Dich isoliert! Lass Deine VMs eingeschaltet“ (Default)
• Power off                     := „Du erkennst Dich isoliert! Schalten Deinen VMs den Strom ab“
• Shut down                   := „Du erkennst Dich isoliert! Fahre Deine VMs herunter“

Duncan Epping hat nun eine sehr nette Tabelle veröffentlicht die Hinweise gibt was in welcher Situation einzustellen sinnvoll sein kann:

Wie wahrscheinlich ist es das der Host noch Zugriff auf den Datastore hat?	Wie wahrscheinlich ist es das der Host noch Zugriff auf das VM Netzwerk hat?	Empfohlene Isolation Response Policy	Erklärung
Wahrscheinlich	Wahrscheinlich	Leave Powered On	Die VMs laufen einwandfrei, warum sollen sie ausgeschaltet werden?
Wahrscheinlich	Nicht Wahrscheinlich	Entweder Leave Powered On oder Shutdown	Wähle Shutdown um HA zu erlauben die VMs auf den verbleibenden Hosts zu restarten, da diese wahrscheinlich auch Datastore Zugriff haben.
Nicht Wahrscheinlich	Wahrscheinlich	Power Off	Nutze Power Off um zu verhindern das zwei Instanzen der gleichen VM Zugriff auf das VM Netz haben
Nicht Wahrscheinlich	Nicht Wahrscheinlich	Leave Powered On oder Power Off	Wähle Leave Powered On wenn es möglich ist den Netzwerk- oder Datastore-Ausfall zu beheben. Anderfalls Wähle Power Off

Besten Dank an Duncan und hier der Link zum Original Artikel:

Which isolation response should I use?

vmware Performance Management – die wichtigsten Metriken

Da ich mich selbst seit vielen Jahren mit verschiedenen Aspekten des Performance Management beschäftigt habe, kenne ich das Problem, die wichtigen Metriken eines Systems zu erkennen und dann auch richtig zu interpretieren.

Die Kollegen von vkernel haben hier, meiner Meinung nach, sehr gute Arbeit geleistet.
http://www.vkernel.com/resources/whitepapers/20-vm-performance-metrics

Dieses Papier stellt die 20 wichtigsten vmware Metriken kurz und knapp vor. Wichtig dabei, die Metriken finden sich alle im vmware vCenter Server unter:

Über „Chart Options“ kann man nun die, im Dokument besprochenen, Metriken auswählen und sich so eigene Charts zusammenstellen.

Hier als Beispiel: CPU.Ready

Diese lassen sich auch abspeichern, allerdings nur Objektbezogen, also nicht zur Weiterverwendung bei anderen Objekten des gleichen Typs (z.B. VM)!

(Thema wird fortgesetzt)

Warum dieser Blog?

Seit einigen Jahren beschäftige ich mich mit allen Themen rund um die Virtualisierung. Vor allem mit den Lösungen von vmware.

Mittlerweile bin ich selbst zertifizierter vmware Instructor (Trainier, VCI).

Dabei ist mir aufgefallen das es fast nur englischsprachige Blogs zum Thema gibt. Diese sind zum Teil sehr gut, aber eben nur in englisch. Meine Idee ist es nun einen deutschsprachigen Blog zu erstellen, in dem ich (und alle die Spass daran haben) das eine oder andere Thema mal auch deutsch betrachte und beschreibe. Ich hoffe das ich damit meinen Schulungsteilnehmern, Geschäftspartnern und auch Kunden helfen kann dieses spannende Thema in deutsch zu lesen.

Ich distanziere mach ausdrücklich von jeder Art Rassismus oder falsch verstandener Nationaler Einstellung!

Die deutschsprachigen Regionen in Europa und auch die vielen deutschsprechenden Menschen auf dieser Welt sollen einfach die Möglichkeit habe auch mal IT Themen in ihrer Sprache zu lesen.

Viel Spass dabei

Daniel Baby

Dell kauft Quest

Gester gingen die ersten Mails rum: Dell kauft Quest

Brian Madden schrieb schon Anfang Juni in seinem Blog das Dell vor hat Quest zu kaufen http://www.brianmadden.com/blogs/brianmadden/archive/2012/07/02/dell-is-thinking-about-buying-quest-software-what-do-you-think.aspx

Nun kann man es auch auf virtualization. info nachlesen http://virtualization.info/en/news/2012/07/dell-acquires-quest-software.html

Das ist in meinen Augen ein ähnlicher Deal wie damals Oracle und Sun, nur das hier der Hardware Partner den Software Partner kauft. Nach Sonicwall und Wyse nun Quest! Mal sehen was Dell draus macht. Quest war gerade auf dem Weg vom Direct Sales zum Channel Sales. Wie wird Dell dieses weiterführen? Dell verkauft ja auch nicht mehr nur direkt.

Bin gespannt was nun aus vWorkplace und vor allem Foglight wird!

Es bleibt spannend