Buchvorstellung – VMware vSphere Resource Management Essentials

Kurze Vorstellung des Buches „VMware vSphere Resource Management Essentials“

In diesem Beitrag möchte ich ein recht neues Buch aus dem Packt Publishing Verlag (erschienen im Feb. 2014) vorstellen. Dieses Buch wurde mir freundlicherweise als eBook von Packt Publishing zur Verfügung gestellt. Dieser Verlag hat in der letzten Zeit einige sehr interessante Bücher gerade zu VMware Themen herausgebracht. Einige davon habe ich selbst gelesen und muß sagen das die Bücher zwar sehr unterschiedlich von der „Tiefe“ der Wissensvermittlung sind, aber meistens recht praxisnah mit hohem „Daily use“.

© by Packt Publishing

Inhalte des Buches

Der Titel des Buches war für mich etwas irreführend. Das heißt nicht das er komplett falsch währe, nur habe ich mir etwas anderes darunter vorgestellt. Eher ein Buch welches einen Einführung in die VMware Metriken gibt, ähnlich dem im Artikel („vmware Performance Management – die wichtigsten Metriken“ ) beschriebenen nur ausführlicher mit mehr Hintergrund.

Es werden durchaus wichtige Metriken besprochen und erklärt, aber der Schwerpunkt ist eher ein allgemeiner.

Zu den Inhalten:

von dem neuen App HA über Ballooning, DRS, Cluster Maximums bis zu VAAI dem vCenter Operations Manager im Überblick wird alles angesprochen was einen angehenden VMware Consultant oder Administrator interessieren könnte.

Kenner der Plattform finden sicher auch den einen oder anderen interessanten Aspekt, sind aber aus meiner Sicht nicht die ersten Adressaten dieses Buches.

Kritikpunkt

Einzige echte Kritik von meiner Seite ist: VMware Metriken werden meist NUR mit ihrem ESXTOP Bezeichner angesprochen! Ein Beginner kann aber z.B.  unter Umständen mit %RDY wenig anfangen. Eine kuze Erklärung das damit CPU.Ready gemeint ist würde enorm helfen. Hier sollte in einer späteren Auflage nachgearbeitet werden. Oder es gibt einen Anhang in welchem die wichtigsten Metriken zusammengestellt werden.

Fazit

Ich denke der Autor möchte einen guten Überblick über die Plattform VMware vSphere 5.5 geben. Dieses ist gelungen! So ziemlich alle Themen die auch im VMware Kurs „vSphere Install Configure Manage 5.5“ behandelt werden, werden hier angesprochen und z.T. vertieft. Somit ist dieses Buch aus meiner Sicht eine sehr gute Quelle um sich auf den VCP-DCV 5 vorzubereiten.

Sehr gut finde ich, das zu vielen Bereichen auch hilfreiche oder weiterführende KB Artikel angeführt werden (KB = KnowLedge Base). Das fehlt mir in einigen Büchern zu VMware.

Daher kann man der Zielgruppe „angehende“ VMware Consultants und Administratoren, besonders als Ergänzung zum vSphere ICM 5.5 Kurs, dieses Buch wärmstens empfehlen. Kenner der Plattform sollten dagegen erst einen Blick in das Buch werfen um nicht enttäuscht zu sein. Aber auch die finden sicher einige Fakten die sie so vielleicht nicht wußten.

Angesichts des anvisierten €-Preises macht man auf keinen Fall etwas falsches wenn man sich, als Mensch im vSphere Umfeld, dieses Buch zulegt (siehe Buchlink am Anfang).

Weitere Bücher aus gleichem Verlag die ich habe und empfehlen kann:

Learning PowerCLI

Sehr schöne Einführung in die Power Shell Schnittstelle von VMware.

 

 

 

 

 

 

Troubelshooting vSphere Storage

Wer sich nicht vor der Command Line scheut und im VMware Storage Bereich Troubleshooting betreiben muß ist hier  genau richtig.

VMware vCenter Operations Manager – Do You use Policies – Nutzen Sie schon Policies und Gruppen?

Nutzen Sie schon die Policies (und Gruppen) im vCenter Operations Managers?

Nach längerer Zeit (und auch neuen Versionen des vC Ops) möchte ich mal wieder ein paar nützliche Tipps zum vCenter Operations Manager weitergeben. VMware hat in Socialcast eine Community zum Thema Cloud Management „Cloud Management Partner Technical Community“ gegründet. Diese Community hat sich nun im Februar das erste mal Live getroffen und Wolfgang Stichel sowie Matthias Diekert von VMware habe einige sehr gute Infos und Tripps (Best Practices) zum vCenter Operations Manager und auch zu vCenter Log Insight gegeben. Etwas davon möchte ich nun hier beschreiben. Der Artikel ist etwas länger geworden!

Policies und Gruppen im vCenter Operations Manager

Wenn ich es richtig in Erinnerung habe, dann gibt es im vCenter Operations Manager seit Version 5.6 sowohl Gruppen als auch Policies. Was kann man nun damit machen und was bringt das für den praktischen Einsatz des Operation Managers?

Gruppen

Wie sich sicher jeder denken kann, kann man mit Hilfe von Gruppen im vC Ops Virtuelle Maschinen (VMs) zu Gruppen zusammenfassen. Das kann viele Vorteile bringen, denn VMs können auch mehreren Gruppen angehören!

Gruppen können automatisch oder manuell erstellt werden. Gruppen können VMs eines Clusters oder auch eines Services umfassen bzw. beliebig zusammengestellt werden

Bild 1: Gruppen im vC Ops 5.8

Somit hat man mit der Gruppen Funktion ein mächtiges Mittel um die überwachte Umgebung sinnvoll und effizient zu organisieren.

Da jede Gruppe die vollständige vC Ops Hirarchie mit Dashbord, Environment usw. darstellt, kann man hier z.B. auf einen Blick sehen wie es denn dem Service XYZ geht. Das ist in meinen Augen schon allein eine sehr nette und nützliche Funktionalität.

Policies

Policies sind eine sehr mächtige Möglichkeit vC Ops mit Informationen und Einstellungen „vorzuladen“, so daß es möglich ist auf die Kunden bzw. Service Besonderheiten einzugehen (Beispiel: Development Umgebung wird anders behandelt als eine Produktivumgebung). So können hier z.B. die Aggregation der Major and Minor Badges beeinflusst werden (wann wird was gelb, orange oder rot?).

Bild 2: Policies im vCenter Operations Manager

Interessant werden Policies durch die Möglichkeit diese Gruppen zuzuweisen!!! Das ermöglicht die Nutzung der dynamischen Schwellwerte (thresholds) mit Anpassung an gewünsche Prioritäten in bezug auf die praktische Auslastung (dazu später mehr).

So werden unterschiedliche Workloads und Anforderungen in einer VMware vSphere Umgebung auch „artgerecht“ behandelt.

Die default Policies sind eben nicht immer optimal für alle Anforderungen und Umgebungen. Das kann man nun ändern.

Gruppen erstellen

Gruppen können über zwei Menüpunkte erstellt werden:

Bild 3: Gruppen in vC Ops erstellen

Es ist zusätzlich möglich eigene Gruppen Typen zu erstellen (Gruppen Typen siehe Bild 1)

Bild 4: Neuer Gruppen Typ

Dieses geht über den Menüpunkt „Configuration“ und dort „Manage Group Type“ (siehe Bild 2)

Legen wir los und erstellen eine neue Policy.

Policies erstellen und „Best Practices“ für die Einstellung

In diesem Abschnitt möchte ich nun die „Best Practice“ Einstellungen vorstellen, welche auf dem Community Meeting vorgestellt wurden. Aus meiner eigenen Erfahrung machen dieses viel Sinn. Ob man nun direkt die „Default Policy“ ändert oder eine neue Policy erstellt sei jedem selbst überlassen. Keine Angst es gibt eine Punkt „Original Defaults“ mit welchem man die „Werkseinstellung“ wiederherstellen könnte!

Policies werden über das globale Configuration Menü editiert oder neu erstellt:

Bild 5: Globales Configuration Menü

Hier können die Gruppen, Policies und Monitor Einstellungen eingestellt werden. Wir beschäftigen uns jetzt mit den Policies:

Bild 6: Manage – Policies  Neu oder Editieren

Ich möchte in diesem Beitrag eine neue Policy Erstellen und dabei die Default Policy als Ausgangsbasis verwenden. (Hier gibt es auch die Möglichkeit eines „Clone from Original Defaults“ zu wählen falls man die Default Policy verändert hat!)

Bild 7: Policy Clonen

Mittlerweile gibt es ein paar vordefinierte Anwendungs-Policies, wir clonen aber einfach die „Default Policy“, vergeben noch einen Namen und können dann dem „Workflow“ im linken Fensterteil (sobald ein Name für die neue Policy vergeben ist kann man über <Next> einfach weitergehen – die Screenshots zeigen dieses nicht, da ich die erst anschließend erstellt habe) folgen.

Gruppenbezug der Policy

Im nächsten Fenster kann man definieren für welche Objekte diese Policy gelten soll. Das ist eine der mächtigen Kombinationen, um ein gesamtes Rechenzentrum oder mehrere vCenter Server Umgebungen auch unterschiedlich zu behandeln und somit dem tatsächlichen Business Need zu genügen.

Bild 8:  Gruppe zuweisen

Konfiguration der „Badges“ – Anpassen der „Ampelfunktion“

Als erstes werden die sogenannten Badges konfiguriert. Einfach ausgedrückt: „Wann geht ein Badge von Grün auf Gelb auf Orange und Rot“?  Faktisch beeinflusst man die dynamische Theshold-Bildung (Schwellwerte).

Bild 9:  Infrastructur Badge Thresholds

Wir verändern hier die beiden Bereiche „Health Level“ und „Stress Level“ denn diese sind wichtige für das „Einstiegsbild“ um schnell zu erkennen ob etwas „aus dem Ruder“ läuft. Erfahrungsgemäss laufen oft mehrere Dinge gleichzeitig schief oder beeinflussen sich. Default für Health ware „25 / 50 / 75“ welches auf „10 / 25 / 50“ geändert wird. Es wird also früher kritisch!

Im Bereich Stress dagegen steht der Default auf „1 / 5 / 30“. Hier sollte etwas konservativer auf „10 / 30 / 50“ gegangen werden, denn somit werden kurze Stess Situationen entschärft. Ziel soll es ja sein Probleme frühzeitig zu melden, aber im Gegenzug nicht in Eventstürme oder permanentes Warnen zu verfallen. Es wurde hier noch angesprochen geg. unter „Anomalie Level“ den 50% Schwellwert zu aktivieren (Wert ist ein unausgefülltes Feld und daher inaktiv). Dazu einfach anklicken wenn gewünscht. Es wird dann eben früher „alarmiert“.

Gehen wir nun zu den Badges auf VM Ebene und sehe was dort „Best Practices“ sein kann:

Bild 10: Policy erstellen: Badge Konfiguration auf VM Ebene

Auch hier passen wir die Bereiche „Health Level“ und „Stress Level“ an. Im Prinzip gilt das gleiche wir auf Infrastruktur Ebene. Bei Health mächte man etwas früher den Severity Level ändern, bei Stress degegen etwas mehr Spielraum für tatsächliche Stresssituationen schaffen. Daher ändern wir „Health“ wieder von „25 / 50 / 75“ auf „10 / 25 / 50“ und „Stress“ von „1 / 5 / 30″ auf “ 5 / 10 / 20″.

In den Badge Einstellungen für die Gruppen besteht kein Bedarf etwas zu ändern, hier können wir mit den „ausgewogenen“ Defaults von „25 / 50 /75“ starten. Es kann ja auch später noch nachjustiert werden!

Bild 11: Policy erstellen: Badge Einstellungen für Gruppen

Konfiguration der „Capacity“ und „Time“  – Kapazitätsmodell festlegen, Bereichnungs-Zeitbasis

Die nun folgenden Einstellungen sind äusserst wichtig, denn hier legen Sie fest welches Kapazitätsmodell für die gewählte Gruppe zugrundegelegt wird.

Wir haben grundsätzlich zwei Kapazitätsmodelle zur Auswahl:

• Physical Capacity: reine Kalkulation auf Basis der physikalischen Metriken und Werte ohne Puffer für HA usw.
• Usable Capacity: Kalkulation auf Basis der physikalischen Metriken unter Einbezug von HA und selbst definierten Puffergrößen

Leider kann ich an dieser Stelle nicht noch weiter auf die Modelle eingehen, wie man vielleicht aus dem wenigen erkennen kann, wird man für Produktionsumgebungen sicher die „Best Practice“ Empfehlung „Usable Capacity“ Modell nachvollziehen können. Hier besteht die Möglichkeit detaillierter (im nächsten Fenster) Puffereinstellungen vorzunehmen. Wer will schon bis an die physikalischen Grenzen geben?

Bild 12: Policy erstellen: Kapazitätsmodell etc.

Im folgenden Fenster legt man nun die gewünschten Puffer in Prozentualen Anteilen fest. Ebenso ob man die eingestellte HA Admission Control Policy einbeziehen will oder nicht. Vorsicht! Nur verwenden wenn diese auch korrekt eingestellt ist! (siehe auch hier und bei Duncan Epping)

Bild 13: Policy erstellen: Puffer festlegen

Im letzten Fenster dieses Bereiches kann nun festgelegt werden über welche Zeiträume kalkuliert wird und mit welchen Ratios man arbeiten möchte.

Bild 14: Policy erstellen: Berechnungszeiten und Consolidierungs Ratios

Als „Best Practice“ gilt sicher für viele Produktive Umgebungen das man die Wochenenden ausklammert, da hier wenig bis keine Aktivität vorliegt und daher die Wochenenden die Gesamtbewertung verfälschen würde. Als Ratio bei aktuellen CPU Leistungen kann durchaus mit 4:1 gearbeitet werden. Memory ist eher kritisch und sollte genau wie Disk Space aussen vor gelassen werden. Gerade im Disk-Space Bereich sollte man sehen was für ein Storage System man nutzt und was dieses zum Kapazitätsmanagement beiträgt (Stichworte: Deduplizierung und Kompession)

Konfiguration bzw. Einbeziehen des Status der VMs in die Berechungen

Der nun folgende Bereich schließt relativ Nahtlos an die Einstellung der Berechungszeiten an. Jetzt definieren wir wann eine VM als Powerd Off bzw. Idle angesehen wird. Dieses ist ein durchaus interessanter Aspekt der es ermöglicht „Schwachlastzeiten“ korrekt in die Berechungen einzubeziehen.

Bild 15: Policy erstellen: VMs Power Off und Idle

Als „Best Practice“ wir ein 100% Schwellwert für Power Off VM eingestellt (statt 90% default) denn hier sollen alle mit einfließen (Warum auch nicht?). Bei den Idle detection Rules kann man unter Umständen den Bereich Disk I/O ausklammern, da man z.B. auf NFS Storage (ohne VAAI) normalerweise KEINE I/O Informationen vom vCenter Server auf VM Ebene erhält. Also bitte an die eigenen Umgebung anpassen!

Ein weiterer Konfigurationspunkt betrifft Oversized- oder Untersized VMs und wie diese erfasst und in das Gesamtbild einbezogen werden.

Bild 16: Policy erstellen: Over- Undersized VMs

Eine gute Einstellungsveränderung soll für mehr als 10% der VMs in einer Stunde betreffen und nicht wie default vorgegeben nur 1% über 4 Wochen!

Für Container (vApps; Resource Pools usw.) und Datastores sind ähnliche Einstellung zu empfehlen.

Bild 17: Policy erstellen: Stress und Ungenutzte Datastores und Container

Konfiguration der Alarme die generiert werden sollen (Alerts)

In den Einstellungen für Alarme empfiehlt es sich keine Alarme für Forecasts (Time- und Capacity Remaining) generieren zu lassen.

Bild 18: Policy erstellen: Alerts konfigurieren

Forecasts lassen sind viel praktikabler als Reports generieren bzw. direkt unter „Efficiency“ ablesen. Gerade das kann der vCenter Operations Manager sehr gut, vorausgesetzt man lässt ihm gerade zu Beginn genug Zeit ;-).

Konfiguration von Forecasts und Trends

Die eben angesprochenen Forecast und Trend Informationen sind sicher neben den Operativen Badges und Alerts einer der größten Nutzfunktionen des Operation Managers. Hier kann auch noch ein wenig „getuned“ werden.

Bild 19: Policy erstellen: Forecasts und Trends

Beide Einstellungen dienen zur „Kurvenglättung“. Im ersten Fall sollen alle Kurvenanomalien die weniger als 40 Messpunkte beninhalten ausgeklammert werden (non-linear functions for data sets less than 40 points) welches auch aus meiner langjährigen Erfahrung ein praxisnäherer Wert als nur „4“ Punkte der default Einstellung darstellt. Ganze 4 Messpunkte sind einfach „zu schnell“ erreicht (VM erstellt, temporäre Last durch Tests usw.) als 40 Punkte. Ausserdem möchte man Ausreißer erkennen und ebenfalls eliminieren. Diese verfälschen Typischerweise solche (und nicht nur diese ;-)) Forecasts.

Fazit

Mit Hilfe von Gruppen und Policies sowie der geschickten Kombination der beiden, angepasst an die eigene oder Kundenspezifische Umgebung und Anforderung entfaltet der vCenter Operations Manager sein Potential um so mehr. Gerade in dieses Einstellbereichen ist gutes und hochwertiges Consulting lohnenswert. Allerdings schadet hier ein gewisser Betriebswirtschaftlicher und Prozessbezogener Blickwinkel sicher nicht.

Nochmals vielen Dank an die VMware Kollegen für Ihren guten Input!

vmware vCenter Operations Manager – Custom-UI – the secret Side of vCOPs

Kennen Sie die Custom-UI des vCenter Operations Managers?

Der vCenter Operatons Manager wartet üblicherweise mit der bekannten Startpage unter „https://<IP-Adresse>/vcops-vsphere/loginPage.action“  auf. Hier findet man das von vmware vorbereitete Dashbord mit allen Möglichkeiten um vmware vSphere Umgebungen effizient zu überwachen, zu analysieren und zu managen.

Trotzdem gibt es ambitionierte Anwender die weitergehende Wünsche an solch eine Lösung haben. So sollen z.B. Service oder Aufgabenorientierte Dashbords für spezifische Anwender erstellt werden.

Auch hier ist der vCenter Operations Manager bestens gerüstet (wenigstens ab Advanced Edition).

Wenn Sie statt der oben genannten URL folgende aufrufen „https://<IP-Adresse>/vcops-custom/?locale=en_us “ erscheint folgende Login Seite:

Custom-UI Login

Beachten Sie den markierten Bereich!

Der User mit dem Sie sich hier einloggen hat mit dem vCenter Server NICHTS zu tun! Dieses Custom-UI hat eine eigene Userverwaltung und muss separat an LDAP bzw. AD angekoppelt werden! Default User ist „admin“ mit dem Passwort „Password„.

Folgendes Dashboard wird nun gezeigt (Version 5.7.1)

Custom-UI Home Dashboard

Das sieht doch ein wenig anders aus als gewohnt oder ?

Man könnte sagen das man jetzt auf die rudimentär oder roh aufbereiteten Daten schaut, während die vSphere-UI wunderschön angepasst ist.

Allerdings hat man hier die Möglichkeit „alles“ weitgehend nach eigenen Vorstellungen zu konfigurieren. So z.B. durch Aufgaben oder Service bezogene Dashboards.

Dashbords bauen – ein Einstieg

Sie können Dashbords über den Menüpunkt Dashboards – Add erstellen:

Dashbord – Add

Hier erscheint nun auf der rechten Seite ein leeres Dashbord welches man mit verschieden Widgets füllen kann. Ebenso kann man hier festlegen wieviel Spalten das Dashboard haben soll.

Dashbord erstellen: Widgets / Style usw.

Die einzelnen Widgets müssen anschließend natürlich mit „Leben“ gefüllt werden. Dazu den oben gezeigten Dialog wieder verlassen (nachdem die benötigten Widgets angelegt wurden ;-))

Nun könne die einzelnen Widgets konfiguriert werden. Der Knopf dazu ist etwas versteckt:

Konfigurieren eines Widgets

Folgender Dialog dient nun zur Konfiguration des Widgets (hier eine Heatmap)

Konfiguration Widget: EDIT

Diese Konfiguration wird unter separatem Namen gespeichert! Des weiteren kann hier das Widget mit einem Namen versehen werden und alle relevanten Metriken sind konfigurierbar.

Templates – Eigene Dashboard Templates erstellen

Durch die Möglichkeit Dashbords als Templates zu speichern diese zu exportieren oder auch wieder zu importieren bietet sich ein weites Spektrum für Kundenspezifische Anpassungen und auch für Consultants Dienstleistung mit geprüften Lösungen / Modulen (Templates) anzubeiten.

Dashbord als Template sichern

Extrem interessant wird die Dashbordgestaltung durch die Möglichkeit ganze Dashbords als Widgets zu definieren und so neue Dashbords auf Basis bestehender „Module“ aufzubauen. Dazu vielleicht irgendwann späten einmal ein separater Beitrag.

Fazit

Es ist relativ einfach eigene Dashbords in der Custom UI des vCenter Operations Manager zu erstellen. Die Herausforderung ist eher diese eigen Dashbords durchdacht mit den richtigen Informatione zu füllen um dem angedachten Zweck zu entsprechen 🙂

Hier ist sicher etwas Einarbeitung und Planung notwendig. Ausserdem sollte man wissen was man sehen will und vielleicht auch eine Idee haben welche Metriken dazu notwendig sind. Der Operations Manager hilft dann allerdings hervorragend bei der Umsetztung!

vmware Performance Metriken – Memory.Consumed (Belegt)

Kleine Einführung in einige vmware Performance Metriken und was sie bedeuten

Um das Thema Memory Metriken fortzuführen hier nun die Betrachtung der Metrik Memory.Consumed. Dieser ergänzt direkt den Artikel über die Metrik Memory.Active.

Heute – Memory.Consumed

Die Metrik Memory.Consumed findet man sowohl unter VMs als auch auf Host bzw. Clusterebene. Sie wird auf VM Ebene ermittelt. Was sagt diese nun aus?

„Original vmware: Amount of machine memory used on the host. Consumed memory includes virtual machine memory, service console memory, and VMkernel memory. consumed memory = total host memory – free host memory“

Auf deutsch: „Betrag des Memory der von einem VM auf dem Host tatsächlich konsumiert wird. Dazu gehört der Verbrauch der VM als auch der sog. Virtualisierungsoverhead (vmkernel + VMM). „

Ganz einfach erklärt

Im Gegensatz zur Memory.Active Metrik summiert die Metrik Memory.Consumed allen Host Speicher auf den eine VM „benötigt“. Dazu zählen auch Memory Pages die „gelegentlich“ genutzt werden. Eine VM mit hohem Memory.Consumed Wert im Vergleich zum konfigurierten vRAM ist damit als „Speicherfresser“ erkannt und muß geg. vRAM seitig erweitert werden bzw. mit einer Memory Reservation versehen werden.

Beispiel: Eine VM die mit 13GB vRAM konfiguriert wurde und 12GB RAM „konsumiert“ ist „gut ausgelastet“

Performance Chart VM Advanced

 

Fazit

Die Metrik Memory.Consumed zeigt den gesamten RAM der von einer VM „konsumiert“ wird. Dazu gehört der vRAM + der gesamte Virtualisierungs Overhead. Hier ist auch der Virtual Machine Monitor [VMM] enthalten. Dieser Metrik sollte für Berechungen der Gesamtbelastung einer Umgebung genutzt werden.

vmware Performance Metriken – Memory.Active

Kleine Einführung in einige vmware Performance Metriken und was sie bedeuten

Nach dem Artikel zur Metrik CPU.Ready und CPU.Usage folgen nun einige Essentielle Metriken die den Memory (RAM) Verbrauch bzw. den belegten RAM darstellen. Anfangen möchte ich mit der Metrik Memory.Active.

Heute – Memory.Active

Die Metrik Memory.Active findet man sowohl unter VMs als auch auf Host bzw. Clusterebene. Was sagt diese nun aus?

„Original vmware: Sum of the active guest physical memory of all powered on virtual machines on the host, plus memory used by basic VMkernel applications. Active memory is estimated by the VMkernel.“

Auf deutsch: „Summe der aktive von den Virtuellen Maschinen [VMs] genutzte physikalische Memory Pages auf einem Host (Hostebene) bzw. auf Clustereben, Summe über alle Hosts im Cluster. Für VMs nur die der aktuell betrachteten VM. Zusätzlich kommen noch Werte für vmkernel Basisdienste dazu. Diesen Wert schätzt der vmkernel!“

Ganz einfach erklärt

Aktiv belegter physikalischer Speicher des Hostes bezogen auf alle VMs (Hostebene) oder einer dedizierten VM (VM Ebene). Da jede VM zusätzlich Basisdienste des vmkernel nutzt, wird der Betrag noch aufgeschlagen. Somit ergibt sich der Gesamt-Aktiv genutzte physikalische Hostspeicher (z.B. per VM). Es handelt sich um einen Schätzwert des vmkernel. Daher ist es oft besser den Memory.Consumed Wert hinzuzuziehen um zu sehen was eine VM z.Z. tatsächlich Konsumiert. (Diese Metrik kommt im nächsten Artikel!)

Für Memory.Active werden Min/Max und Mittelwerte (Average) angegeben. Die Einheit ist KiloByte [KB].

Beispiel: Eine VM ist mit mit 3GB vRAM konfiguriert und zeigt auf dem Summary Tab eine Memory Usage von 124 MB an.

Summary Tab VM

Dieses bedeutet, das die VM von konfigurierten 3GB z.Z. im Mittel (Average) nur 124 MB nutzt.

Also praktisch im Leerlauf arbeitet.

Im Performance Grafen der VM unter Advanced – Memory würden zeitgleich folgende Werte dargestellt:

Werte im Performance Chart der VM

Fazit

Wenn eine VM einen besonders hohen Memory.Active Wert anzeigt, sollte geg. die vRAM Konfiguration angepasst werden. Ein sehr kleiner Wert, wie im Beispiel, zeigt eine VM die nichts zu tun hat ( idle). Ein Vergleich mit dem Memory.Consumed Wert ist sehr sinnvoll.

NEU – vmware vCenter Log Insight BETA

Vorstellung: neues Analysewerkzeug „vmware vCenter Log Insight [BETA]“

vmware hat ein neues Analyse Tool für vSphere in einer offenen Beta vorgestellt: „vCenter Log Insight„.

Bei diesem Tool handelt es sich um eine Lösung zur zentralen Logfile Analyse von ESXi Hosts (auch alle Hosts eines ganzen vCenter Servers). Die Lösung besteht aus einer, im OVA Format ausgelieferten Appliance, welche zur zentralen Sammelstelle konfiguriert werden kann. (Fungiert quasi als Syslog Server, daher erst am ESX/ESXi 4.0 nutzbar)

Anschließend stellt die Appliance eine Web basierte Oberfläche zur semigrafischen Analyse der Logfiles bereit.

Bild 1: Grafische Anzeige „Interactive Analytics“

Webfrontend

Das Webfrontend der Appliance ist in zwei Ansichten unterteilt, „Dashbords“ und „Interactive Analytics“ (siehe Bild 1).

In der Ansicht „Dashboards“ (Bild 2) bekommt man eine Übersicht der gesammt gesammelten Events, Error Events usw.

Bild 2: Ansicht „Dashbords“

Hier kann man weitere Dashbords zu den Bereichen:

• ESX/ESXi Hosts
• SCSI/SCSIi and NFS
• vCenter Servers
• Events, Tasks and Alarms

auswählen. Dabei sind alle Grafiken (Balken usw.) interaktiv. Klickt man z.B. auf einen Balken in der Grafik, so landet man automatisch in der Ansicht „Interactive Analytics“ und zwar im angewählten Kontext! Dahinter steckt eine automatische Suchfunktion die je nach Grafik die entsprechenden Logfiles nach Schlüsselwörtern durchsucht (Bild 3).

Bild 3: Suchabfrage

Dies kann nun geg. auch erweitert und verändert werden. In den gefundenen Logfileeinträgen werden die Suchworte automatisch markiert (Bild 4).

Bild 4: Logfileeintrage mit markierten Suchwörtern

Allein durch diese schnellen Analysemöglichkeiten hat ein erfahrener Administrator oder Consultant enorme Möglichkeiten zur effizienten Fehleranalyse oder auch zum einfachen „Health Check„.

Weitere Hinweise

Es ist möglich, schon während der Grundkonfiguration der Appliance diese mit einem vCenter Operations Manager zu verbinden. Dazu benötigt man min. die Version 5.7.1!

Weitere Artikel gefällig?

Leider hatte ich nur ein paar Stunden um das Tool zu konfigurieren und kurz anzusehen. Ich denke da folgt noch mehr. Falls Interesse besteht kann ich auch eine ausführliche Installations und Konfigurationsanleitung erstellen. Bitte die Umfrage benutzen. DANKE

vmware Performance Metriken – CPU.Usage

Kleine Einführung in einige vmware Performance Metriken und was sie bedeuten

Nach dem Artikel zur Metrik CPU.Ready nun eine weitere Metrik welche die CPU Analyse eine Virtuellen Maschine betrifft.

Heute – CPU.Usage

Unter den CPU Metriken einer VM kommt immer wieder die Metrik CPU.Usage auf. Was sagt diese nun aus?

„Original vmware: Amount of actively used virtual CPU as a percentage of total available CPU.
CPU usage is the average CPU utilization over all available virtual CPUs in the virtual machine.“

Auf deutsch: „Menge der aktiv genutzten virtuellen CPUs [vCPU] einer VM als Prozentsatz der insgesamt verfügbaren physikalischen CPUs [pCPU]“

Ganz einfach erklärt

Prozentualer Anteil der Nutzung einer pCPU durch ein VM mit ihren vCPUs.

Beispiel: wenn eine VM eine CPU.Usage von 100% anzeigt, bedeutet das, das hier ein oder mehrere pCPUs zu 100% von dieser VM genutzt werden.

Metrik Berechung nach vmware Angaben:

Virtuelle CPU-Nutzung = MHz-Nutzung / (Anzahl an virtuellen CPUs × Core-Frequenz)

Fazit

Die Metrik CPU.Usage bezieht sich auf die pCPU Nutzung des Hostes und ist daher ein Indikator dafür, wie die vorhandenen physikalischen Cores des Hostes zur Zeit ausgelastet sind. Daher sollten immer mehrere VMs eines Hostes betrachtet werden, um z.B. zu analysieren welche VMs den Host entsprechend belasten und Rückschlüsse auf das „Warum“ zu finden. Dieses könnten Ressource Einstellungen (Reservation) in der VM oder einem Ressource Pool, bis hin zu gesetzten CPU Affinitäten sein.

Es ist durchaus möglich, das Engpässe im Bereich Memory oder Storage indirekt zu erhöhter vCPU Last führt, was wiederum in einer hohen CPU.Usage endet.

vmware Performance Metriken – CPU.Ready

Kleine Einführung in einige vmware Performance Metriken und was sie bedeuten

Mit diesem Artikel möchte ich eine kleine lose Reihe von Artikeln zu diversen vmware Performance Metriken starten. Sicher ist zu den meisten schon einiges geschrieben worden, doch stelle ich immer wieder fest das vielfach nicht wirklich bekannt ist was eine Metrik aussagt. Ohne diese Kenntniss sind die Messwerte die z.B. der vCenter Server oder esxtop oder vCenter Operations Manager ausgeben wenig Wert. Daher diese kleine Reihe. Gern nehme ich auch Anregungen auf was gefagt ist!

Heute – CPU.Ready

Unter den CPU Metriken einer VM kommt immer wieder die Metrik CPU.Ready auf. Was sagt diese nun aus?

„Percentage of time that the virtual machine was ready, but could not get scheduled to run on the physical CPU. CPU.Ready time is dependent on the number of virtual machines on the host and their CPU loads.“

Auf deutsch: „Prozentualer Zeitanteil einer virtuelle Maschine welche die VM auf physikalische CPU Zuteilung wartet“

Ganz einfach erklärt

Jeder Hypervisor ist gleichzeitig ein geschedultes System! Solange keinerlei Overcommitment vorliegt, kann jede Ressource genutzt werden. Dieses gilt auch für den Zusammenhang zwischen physikalischer CPU [pCPU] und virtueller CPU [vCPU].

Im Falle den (fast normalen) Overcommitment von vCPUs auf einem HOST (mehr vCPUs als in Summe pCPUs – Cores) wird es nun spannend. Was passiert nun? Der vmkernel muß nun die einzelnen Anforderungen der vCPUs bzw. VMs schedulen.

Für 1 vCPU VMs ist das meist recht einfach. Bei SMP bzw. mehr vCPU VMs wird das schon schwerer, denn für eine z.B. 4 vCPU VM muß der vmkernel 4 parallele pCPU Slots finden. Das kann schon mal dauern (siehe „vmware Resource Techniken – CPUs und Multi vCPUs (SMP)„).

CPU.Ready wird an den meisten Stellen entweder in Millisekunden [ms] Wartezeit, oder in % des gesamt zur Verfügung stehen Zeitraums angegeben.

Fazit

Je höher die CPU.Ready Time ist desto schlechter für die VM und somit für die Performance der VM! Wie im genannten Artikel schon beschrieben ist eben hier oft weniger – mehr. (siehe auch hier „Gabes virtual World„)

Hoffentlich demnächst mehr. Welche Metriken sind am interessantesten?

DELL – Quest: vOPS jetzt Foglight for Virtualization Standard Edition – Eindrücke

Alles heisst nun Foglight! vkernel vOPS jetzt Foglight Standard – 02Eindrücke

Nach längerer Zeit habe ich mir mal wieder etwas Zeit gehabt die aktuelle Version von Foglight Standard (ehemals vkernel vOPS) anzutesten.

Wie beeits beim ersten Begutachten vor einiger Zeit, macht diese Monitoring Lösung einen sehr guten Eindruck. Das wesentliche wird kurz und übersichtlich dargestellt. Performance Bottelnecks sind relativ leicht aufzuspüren und werden einfach, aber effektiv dargestellt.

Hier das Main Dashbord als erste Übersicht:

Man bekommt einen guten Überblick zur gesamten vmware Umgebung. Anzahl der Objekte, physikalische Ressourcen, virtuelle Ressourcen usw.

Interessant sind aber vor allem die Auswertungen die Foglight Standard liefert (siehe roter Pfeil).

Installation

Die Installation von Foglight Standard erfolgt als fertige OVF Appliance. Sollte also von jedem vmware Admin durchführbar sein.

Intern arbeitet die Appliance mit einer Postgres DB (vmware nutzt die ja nun auch ;-)). Es kann aber auch MS SQL oder Oracle verwendet werden. Eine Datenmigration ist scheibar problemlos möglich. Hab ich aber nicht ausprobiert.

Auswertungen am Beispiel Datastore Latency

Klickt man im Main Deshbord z.B. auf den, vom roten Pfeil, gezeigten Link, bekommt man ein gute Übersicht der aktuellen Latenzen auf den Datastores (uns mehr)

Durch die Pfeile wird schnell sichtbar wo geg. Engpässe vorhanden sind oder drohen, dabei werden trotzdem aktuelle Messerte angezeigt.

Auch hier muß daran erinnert werden: „Nur Messwerte die mir etwas sagen, bzw. die ich interpretieren kann“ nützen mir“

Da hilft dann oft das Dokument aus gleicher Quelle wir diese Lösung „The Top 20 VMware Performance Metrics You Should Care About“

Geht man nun mit der Maus über solch ein Feld (z.B. Total Latency) erhält man alle Werte noch einmal in einem Popup Fenster angezeigt (siehe Beispiel Summary Dashbord). Ein Doppelklich gibt nun detailierte Infos zum Problem, dem Impact und gegebenenfalls auch zur Lösung (Resolution).

Also rundum eine einfache aber effektive Lösung für alle die nichts selbst konfigurieren wollen und denen die vorhandenen Ansichten ausreichen.

Konfigurationsmöglichkeiten – Reporting

Nichts desto Trotz kann man auch in Foglight Standard das eine oder andere Anpassen. Diese bezieht sich hauptsächlich auf Analysefunktionen, aber auch auf Kapazitätsberechnungen.

Beispiel: Slotsizes für die vmware HA Admission Control Policies

Hier kann man schön die optimale Einstellung für die eigene Umgebung finden.

Fazit

Eine gute und praxistaugliche Lösung. Installation ist denkbar einfach. Bedienung nach kurzer Lehrnphase logisch aufgebaut. Felxibilität aber eingeschränkt. Wer mehr will oder braucht muß auf Foglight for Virtualization (vFoglight Pro) oder andere Lösunge (wie vmware vCenter Operations Manager) ausweichen.

DELL – Quest: Foglight for Virtualization 6.8 upgrade

Upgrade einer vFoglight 6.7.x auf ein Foglight for Virtualization 6.8

DELL/Quest hat sein Enterprise Management System Foglight mal wieder Namentlich geändert! Diesmal zum Glück nur marginal. Aus vFoglight Pro wurde Foglight for Virtualization.

Leider hat dieses beim Upgrade einer vFoglight Pro Instanz aber einen unschönen Nebeneffekt. Das heisst, wenn man nicht aufpasst hat man auf einmal zwei Instanzen auf dem Server laufen!

Hauptgrund ist eben diese Namensänderung, denn nun wir Foglight per default auch in einen Ordner Foglight und nicht mehr in einen Ordner vFogliht installiert. Mir ist es erst aufgefallen, als das Setup nicht nach einem Upgrade fragte, aber dann anmeckerte, das der Datenbank Port schon belegt sei.

Daher hier ein paar kleine Hinweise zum Upgrade.

Upgrade in Schritten

Am besten sollte man alle vFoglight Prozesse herunterfahren. Dieses geht recht gut mit den Script

„C:\Program Files\Quest Software\vFoglight\bin\fms.exe -q“ (gibt es auf dem vFoglight Server direkt als ausführbaren Link im StartMenü).

Anschließend das Setup der neuen Version mit Administratorrechten starten.

Hier auf JEDEN FALL „Custom Install“ auswählen.

Den Default Installationspfad mit dem ehemaligen „vFoglight“ Pfad ersetzten. Denn nur so erkennt das Setup eine bestehende vFoglight Installation.

Hier natürlich „Upgrade“ auswählen.

Nach einigen Informations Fenstern sollte schließlich folgendes zu lesen sein.

Am besten nach der fertigen Installation (Fortschritt der Cartridge Installation wird in einem Browserfenster angezeigt) und der Initialisierung der Agents (cmd Fenster). Den Server einmal durchbooten und kontrollieren ob alle Services/Dienste gestartet werden.

So zeigt sich dann das neue Login Fenster:

Neuerungen in der Version 6.8

Wichtigste Neuerung aus vmware Sicht ist sicher die Unterstützung von vmware View. Hier werde ich sicher noch etwas schreiben, sobald ich vernünftige Daten habe und etwas mehr dazu sagen kann.