Archiv für die Kategorie ‘Performance Management’

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

© 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

Learning PowerCLI

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

 

 

 

 

 

 

Troubelshooting vSphere Storage

Troubelshooting vSphere Storage

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

Advertisements

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

Gruppen im vC Ops 5.8

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?).

Policies im vCenter Operations Manager

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:

Gruppen in vC Ops erstellen

Bild 3: Gruppen in vC Ops erstellen

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

Neuer Gruppen Typ

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:

Globales Configuration Menü

Bild 5: Globales Configuration Menü

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

Manage - Policies: Neu oder Editieren

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!)

Policy Clonen

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.

Profile erstellen: Gruppe zuweisen

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).

Policy erstellen: Infrastructur Badge Thresholds

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:

Policy erstellen: Badge Konfiguration auf VM Ebene

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!

Policy erstellen: Badge Einstellungen für Gruppen

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?

Policy erstellen: Kapazitätsmodell etc.

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)

Policy erstellen: Puffer festlegen

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.

Policy erstellen: Berechnungszeiten und Consolidierungs Ratios

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.

Policy erstellen: VMs Power Off und Idle

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.

Policy erstellen: Over- Undersized VMs

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.

Policy erstellen: Stress und Ungenutzte Datastores und Container

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.

Policy erstellen: Alerts konfigurieren

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.

Policy erstellen: Forecasts und Trends

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 Log Insight 1.5TP2 auf Version 1.5 TP3 updaten

Und wieder eins meiner Lieblings-Tools aus 2013

Da ich ja schon einen Artikel zum Update der vCenter Log Insight BETA auf die  1.5 TP2 geschrieben habe, hier nur ein kurzer Artikel der zeigen soll, das vmware hier, aus meiner Sicht, sehr gute Arbeit leistet. Das Upgrad ist, wie schon vermutet noch einfacher geworden.

Hier nun die Update Anleitung in einzelnen Schritten.

Vorbereitungen

Als erstes sollte man sich, wenn noch nicht geschehen, der vCenter Log Insight Community anmelden: http://loginsight.vmware.com/

Sobald der Account approved ist kann man die Version 1.5 TP3 downloaden.

Hier sollte man für das Update das „RPM“ Packet von vmware herunterladen (z.Z. loginsight-cloudvm-1.1.3-1355360.x86_64.rpm).

Upgrade Prozess

Jetzt gibt es nichts mehr per WinSCP upzuloaden oder per Linux Shell auszuführen, sondern:

I) An der Weboberfläche von vCenter Loginsight 1.5TP2 anmelden und in die Administration der Appliance wechseln

Administration

Administration

II) Hier im Menü links unter Management – Appliance auswählen:

Management Appliance

Management Appliance

III) Nun einfach auf Upload RPM klicken und das zuvor heruntergeladene RPM Packet auswählen:

Upload RPM Packet

Upload RPM Packet

IV) Nun läuft der Upgrade Prozess automatisch los:

Upgrade läuft

Upgrade läuft

V) Wenn alles durch ist erscheint folgender Screen:

Neue Version 1.5 TP3

Neue Version 1.5 TP3

Nachbearbeitung

Leider hatte ich nach dem Upgrade ein paar kleine Probleme mit der vCenter Log Insight App. Ein Restart und eine Test der Verbindungen zum vCenter Server sowie die Neuregistrierung bei meiner vCenter Operations Manager Installation wirkten Wunder 😉

Fazit

Man sieht das VMware weiter an vCenter Log Insight arbeitet und schon jetzt eine interessante Lösung für alle bietet die zentrales Logfile Management machen müssen oder wollen. Auch im TP3 wurden wieder einige Neuerungen eingebaut.

Beispiel:

Neue Dashboards

Neue Dashboards

Viel Spass weiterhin mit vCenter Log Insight (Bitte lasst dem Tool nach JEDEM Update ein wenig Zeit! Daten müssen erfasst und verarbeitet werden!)

vmware vCenter Log Insight – Neue Quellen einfach einbinden

Heute möchte ich gerne zeigen wie man neue Syslog Quellen in vCenter Log Insight einbinden kann. Dazu habe ich einfach mal versucht unsere QNAP 459 an Log Insight zu koppeln. Diese möchte ich hier kurz exemplarisch vorstellen.

Es wird dazu KEIN Content Pack benötigt! Contentpacks sind einfach eine Sammlung von Dashboard und Abfragen (und etwas mehr ;-)).

Vorbereitung des Quellsystems – QNAP 459

Über die Web-Administration der QNAP in den Bereich Administration wechseln (in der neuen Firmware 4.0.2 Systemsteuerung):

QNAP Web Front End: Systemsteuerung

QNAP Web Administration: Systemsteuerung

Nun auf Systemprotokolle gehen:

QNAP Web Front End: Systemprotokolle

QNAP Web Administration: Systemprotokolle

Jetzt auf den Reiter „Syslog-Client-Management“ und hier nun den vCenter Log Insight Server als Syslog-Server mit seiner IP eintragen.

QNAP Web Administration: Syslog Server eintragen

QNAP Web Administration: Syslog Server eintragen

Nun sollte das QNAP System Syslog Meldungen an unseren Log Insight Server weiterleiten! Damit ist dieser Teil der Quellen Konfiguration schon erledigt.

vCenter Log Insight – Querys und Dashbords auf QNAP Daten

Jetzt kann man mittels Query testen ob vom QNAP System Daten kommen. Ich hatte das Glück das die QNAP gerade ein Systemupdate (3.8.3 auf 4.0.2) gefahren hat und daher gab es auch gleich Syslogmeldungen.

Diese einfach mit einem Search nach „qnap“ (bzw. den Vorschlag von Log Insight nach „qnapvit459“ übernehmen!) testen [Schritt 1].

vCenter Log Insight: QNAP Search Abfrage

vCenter Log Insight: QNAP Search Abfrage

In den gefunden Log Einträgen kann man sehen das ein Systemupdate gefahren wurde und auch von welcher Version auf welche neue Version.

Nun habe ich diese Abfrage in mein eigenes Dashbord mittels „Add to Dashbord“ [Schritt2] übernommen – Fertig!

QNAP Dashbord

QNAP Dashbord

 

Fazit

So einfach lassen sich im Prinzip alle Quellen in vCenter Log Insight einbinden, die direkt Syslog unterstützen! Der eigentliche Aufwand liegt nun in der Erstellung von sinnvollen Abfragen und geg. daraus resultierenden Dashboard Graphen.

Viel Spass damit !!!

vmware vCenter Log Insight BETA auf Version 1.5 TP2 updaten

Und es geht weiter mit vCenter Log Insight!

Nachdem vmware die ersten sogenannten Content Packs angekündigt bzw. verfügbar gemacht hat (Content Packs in der Solution Exchange), jetzt eine neue Version 1.5 Tech Preview 2! Das Schöne daran: Die BETA ist updatebar! Zwar mit ein paar „händischen“ Schritten aber einfach durchzuführen.

Die neue Version kommt mit einem Lizenzkey (bis 31. Oktober 2013) der in den Release Notes  auch abgedruck ist.

(https://my.vmware.com/group/vmware/get-download?downloadGroup=STRATA15TP2)

Hier nun die Update Anleitung in einzelnen Schritten.

Vorbereitungen

Wie bei jedem Update sollte man VOR dem Update ein Backup der Appliance machen. Diese geht am einfachsten über einen vmware Snapshot der aber bitte nach erfolgreichem Update schnellstmöglich wieder gelöscht wird ;-). Wer die BETA „aufheben“ will kann ja einen Clone machen.

Jetzt sollte man für das Update das „RPM“ Packet von vmware herunterladen (z.Z. loginsight-cloudvm-1.1.2-1311222.x86_64.rpm).

Dieses RPM habe ich mit WinSCP in das Tmp Verzeichnis auf der Appliance selbst geladen.

Copy RPM via WinSCP

Copy RPM via WinSCP

Soweit die Vorbereitungen.

Update Prozess über Command Line

Nach den Vorbereitungen geht es nun an den eigentlichen Update Prozess. Dieser muß von der BETA aus noch per Command Line durchgeführt werden. Diese klingt vielleicht etwas aufwendig, läuft aber ganz easy ab.

Das als root z.B. per Putty an der Appliance anmelden und die Log Insight Prozesse stoppen.

Stop der Services

Stop der Services

Anschließend wird der eigentliche Update Prozess gestartet:

            rpm -Uvh loginsight-cloudvm-<version>-<log-insigt-build-number>.x86_64.rpm

Update Prozess ausführen

Update Prozess ausführen

Wie man vielleicht im ScreenShot sehen kann werden die Prozesse bei erfolgreichem Update automatisch neu gestartet (anders als in den Release Notes beschrieben).

Damit ist das eigentliche Update schon passiert! So einfach – schön wenn es bei allen IT Lösungen so währe 😉

Check der neuen Version und Neuerungen

Nun wird es Zeit zu testen ob das Update funktioniert hat.

Schon beim Login Screen sieht man das der Vermerk BETA verschwunden ist. Am besten einloggen und unter „About“ nachsehen was der Versions Splash Screen anzeigt:

Versions Splash Screen

Versions Splash Screen

Erfolgreich! Schön das auch alle Dashboards und Contentpacks usw. beibehalten wurden.

Neuerungen

Die Neuerungen zur BETA sind aus meiner Sicht mit Schwerpunkt Kopplung an AD zur Userautentifizierung zu sehen. Leider wurde SSO bisher, soweit ersichtlich nicht integriert. Also wie gehabt Appliance an AD binden:

Appliance an ein AD binden

Appliance an ein AD binden

Dieses findet man unter „Administration – Configuration – Authentication„.

AD User können allerdings auch separat in Log Insight eingebunden werden, dann benötigt man allerdings das AD User Passwort!!

AD User anlegen

AD User anlegen

Somit kann man sich nun auch hier mit seinem AD User anmelden. Schöner, bzw. wünschenswert währe natürlich in Zukunft eine Anbindung via SSO Lösung. Dann könnte der „WebClient wirklich zur zentralen Admin Instanz werden.

Weitere Neuerungen gibt es in der Eigenüberwachung:

Eigenüberwachung

Eigenüberwachung

Und wahrscheinlich in vereinfachten zukünftigen Updates der vCenter Log Insight Appliance selbst:

Upload RPM!

Upload RPM!

Fazit

Ich denke man kann hier schön sehen das es mit dieser Lösung voran geht. Das lässt auf weitere spannende Erweiterungen und einer sicheren Basis für ein Unternehmensweites Log-File Management hoffen. Viel Spass damit.

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

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

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

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.

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

Konfigurieren eines Widgets

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

Konfiguration Widget: EDIT

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

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!

Arbeiten mit dem neuen vmware vCenter Log Insight: Abfragen und Alerts erstellen

Wie bereits im ersten Artikel zum vCenter Log Insight angekündigt, möchte ich nun ein wenig zeigen was man mit diesem Tool machen kann, bzw. wie einfach Abfragen und auch neue Alerts zu erstellen sind.

Die Alerts können dann als E-Mail Notification oder als Weiterleitung an den vCenter Operations Manager konfiguriert werden.

Abfragen erstellen und erweitern

Um eine Suche oder Abfrage in Log Insight zu erstellen und zu erweitern kann z.B. ein Standard Dashboard dienen.

Hier der Ausgangspunkt:

Dashbord SCSI/iSCSI and NFS

Dashbord SCSI/iSCSI and NFS

Als nächstes gehen wir in einen der Grafen und schauen uns die Details an:

Details im Grafen des SCSI/iSCSI NFS Dashboards

Details im Grafen des SCSI/iSCSI NFS Dashboards

Wenn wir jetzt z.B. den hellblauen Balken ganz links anklicken, gelangen wir automatisch ins Analysedashboard und sehen über welche Abfrage dieser Graf erstellt wurde:

Ansicht der Abfrage im Analytics Dashboard

Ansicht der Abfrage im Analytics Dashboard

Diese Abfrage möchten wir nun um eine Einschränkung auf bestimmte Hosts ergänzen. Dazu einfach „Add Constraint“ (unter der Abfrage) anklicken und die gewünschen Hostnamen als „text“ – „contains“ –„esx5..“ auswählen:

Log Insight zeigt dabei Vorschläge auf die der eingegebene Text matcht!

Add HOSTS zur Abfrage

Add HOSTS zur Abfrage

Schon haben wir eine, auf die ausgewählten Hosts eingeschränkte Abfrage erstellt (mehrere Hostnamen durch Komme getrennt angeben):

HOSTS esx51, esx52, esx53 als zusätzliche Abfrage

HOSTS esx51, esx52, esx53 als zusätzliche Abfrage

Nun schränken wir weiter auf bestimmte DeviceIDs (hier Storage Pfade ein)

Dazu kann man in einem Datensatz aus den Abfrageergebnissen einfach das entsprechende Feld/Objekt anklicken (KEINE Abschreiben nötig!):

Add DeviceID durch anklicken!

Add DeviceID durch anklicken!

Das war doch recht einfach oder? Ich denke an diesem Beispiel sieht man wie einfach es ist spezifische Such-Abfragen zur Logfile Analyse in Log Insight zu erstellen.

Sichern der Abfrage

Zum sichern der so erstellten Abfrage einfach auf „Save Current Querry“ gehen:

Save Current Querry

Save Current Querry

Alerts aus Abfragen erstellen und weiterleiten

Zum Schluß wollen wir aus dieser Abfrage Alerts für den vCenter Operations Manager erstellen. Dieses geht folgendermassen:

An der gleiche Stelle an der man Abfragen (Querys) sichert kann man auch Alerts erstellen. Hier einen Alert namens „TestAlert4SCSIDataID“ mit Weiterleitung an den vCenter Operations Manager (dieser muss im Log Insight konfiguriert sein!!)

Test Alert erstellen und weiterleiten

Test Alert erstellen und weiterleiten

Wie man sieht habe ich den Alert nun auf ein Host Objekt gemappt. Diese währe vielleicht besser der vSphere  Cluster gewesen 😉

Als Severity wurde „Warning“ gewählt.

Fazit

Ich hoffe mit diesem kurzen Beitrag gezeigt zu haben wie einfach man mit vCenter Log Insight eigene Abfragen und Alerts erstellen kann. Die Alerts kann man alternativ auch als E-Mail Notification versenden! Vielleicht demnächst mehr dazu. Ich muss erst mal ein paar konkrete Fälle in unserem DemoCenter erzeugen 😉

HINWEIS in eigener Sache:

Ich werde für meinen Arbeitgeber voraussichtlich in KW37/2013 einen Live Online Workshop (ca. 2-3h) zum Thema vCenter Log Insight geben. Dieser Workshop kostet 99€ (netto) und kann über Arrow EDU gebucht werden, dazu bitte eine Mail an die Schulungsabteilung senden!

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

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.

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

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

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.

Installationsanleitung vmware vCenter Log Insight BETA

Mit diesem Artikel möchte ich, wie angekündigt, eine kurze deutschsprachige Anleitung zur Installation der BETA Version von „vmware vCenter Log Insight“ geben.

Die Installation an sich ist nicht schwer, trotzdem gibt es ein paar kleine Hürden die genommen werden müssen. Besonders die Anbindung an LDAP (folgt später) und auch an vCenter Operations Manager will korrekt durchgeführt werden um schnell zum Ziel zu kommen. Daher hier diese kurze Anleitung. Das Original Install Dokument findet Ihr hier: „vCenter Log Insight BETA„.

Import der OVA

Als erstes wird die Appliance mittels vSphere Client oder WebClient in die vSphere Umgebung importiert.

Bild 1: Import OVA Log Insight BETA

Bild 1: Import OVA Log Insight BETA

Das OVA Setup liefert folgende Informationen:

Bild 2: Infos der OVA

Bild 2: Infos der OVA

Es wird empfohlen aus Performance Gründen die Variante „thick provisioned“ zu wählen, da die Lösung schließlich ein Logfile Analyser ist und somit durchaus einiges an Daten anfallen kann.

Während des Imports werden auch schon die Netzwerk Grundkonfigurationen der Appliance durchgeführt (sehr lobenswert, denn OVF/OFA kann so einiges).

Bild 3: Appliance Netzkonfiguration

Bild 3: Appliance Netzkonfiguration

Damit währe der Import beendet und nun kann die Appliance weiter konfiguriert werden.

Grundkonfiguration Appliance

Nun wird die Appliance gestartet. Nach gefühlt einigen Minuten 😉 sollte dieser Bildschirm erscheinen:

Bild 4: © by vmware: Startbildschirm Appliance

Bild 4: © by vmware: Startbildschirm Appliance

Hier bitte mit root anmelden. Nun startet automatisch der Prozess ein neues root Passwort anzulegen.

Bild 5: © by vmware: root Passwort Änderung

Bild 5: © by vmware: root Passwort Änderung

Die weitere Konfiguration erfolgt nun per Web Interface.

Grundkonfiguration via Web Interface

Nun könnt Ihr Euch mittels der angezeigten URL (auf der Appliance Console) bzw. einfach per https://<IP-Adresse-der-Appliance > mittels Browser mit dieser verbinden.

Bild 6: WebInterface Startbildschirm

Bild 6: WebInterface Startbildschirm

Als erstes muss auch hier ein Passwort für den „admin“ User erstellt werden.

Bild 7: Setzten des "admin" User Passwortes

Bild 7: Setzten des „admin“ User Passwortes

Jetzt sind noch ein paar Einstellungen zum Lizenzkey (ist in der BETA schon integriert!).

Bild 8: Lizenzinformationen

Bild 8: Lizenzinformationen

Zur E-Mail Notification Adresse. Hier ist der Empfänger gemeint.

Bild 9: E-Mail Notification Empfänger

Bild 9: E-Mail Notification Empfänger

Zur NTP Zeit Konfiguration. Diese ist, wie bei allen Systemmanagement Lösungen ÄUSSERST WICHTIG!!!

Bild 10: NTP - Sehr WICHTIG!

Bild 10: NTP – Sehr WICHTIG!

Und zur SMTP Konfiguration, damit Log Insight weiss welcher Mailserver genutzt werden soll.

Bild 11: SMTP Einstellungen (Mailserver)

Bild 11: SMTP Einstellungen (Mailserver)

Anschließende wird die Appliance mindestens mit einem vCenter Server verbunden.

Bild 12: vCenter Server und vCenter Operations Manager Anbindung

Bild 12: vCenter Server und vCenter Operations Manager Anbindung

Hier könnten auch mehrere vCenter Server angegeben werden. Ebenfalls ist es möglich eine Verbindung zum vCenter Operations Manager herzustellen. Ich habe dieses später nachgeholt, da min. eine Version 5.7.1 verlangt wird und ich erst mal mein Installation upgraden musste.

Nun kann noch ein NFS Share zur „Langzeit“ Sicherung der Logfiles angegeben werden. Dieses habe ich z.Z. in meiner Testinstallation noch nicht konfiguriert.

Bild 13: NFS Share als "Archiv" bzw. Langzeitstore

Bild 13: NFS Share als „Archiv“ bzw. Langzeitstore

Nun ist im Web Interface erst einmal alles wichtige konfiguriert. Es erfolgt nun ein Restart der Appliance!

Anschließend geht es in die Console der Appliance! Also etwas für Command Line Freunde 🙂 Denn die ESXi Host wollen auch konfiguriert werden – Syslog Target!!

Konfiguration (Anbindung) der ESXi Hosts via Command Line in der Appliance Console

Jetzt kommen wir zu einem Job der tatsächlich auf die Console der Appliance führt. Also entweder via vSphere Client oder Webclient oder direkt per SSH auf der Console der Appliance einloggen (als root mit dem neu gesetzten Password).

Anschließend müssen einzelne ESXi Hosts so konfiguriert werden das sie ihre Logfiles via Syslog bei der Log Insight Appliance abliefern. Dieses erfolgt, wie gesagt von der Console der Appliance aus. Zum Glück hat vmware ein Einsehen und bietet die Möglichkeit mit einem Aufruf alle ESXi Hosts eines vCenter Servers in einem Rutsch anzubinden.

>> configure-esxi -u <vCenter Server Administrator> -p <Password> -s  <vCenter Server Adresse> -t <Log Insight Appliance Adresse>

Bild 14: Anbindung der ESXi Hosts via Command Line

Bild 14: Anbindung der ESXi Hosts via Command Line

Wenn alles passt kommen pro ESXi Host eine Rückmeldung dieser Art:

Bild 15: Rückmeldung ESXi Syslog Konfiguration

Bild 15: Rückmeldung ESXi Syslog Konfiguration

Damit sollten die ESXi Hosts ihre Logfiles via Syslog bei vCenter Log Insight abliefern.

Fazit

Ich denke die Grundkonfiguration ist nicht so schwer. Vielleicht hilft diese Anleitung mit den Sceenshots zusätzlich etwas. Wenn ich etwas Zeit finde werde ich die LDAP Anbindung von vCOps aufzeigen und auch eine kurze Einführung in die Möglichkeiten dieser Lösung folgen lassen.

Lest trotzdem die am Anfang angegebene Getting Started Anleitung  von vmware. Alle Angaben ohne Gewähr 🙂