Buchbesprechung – Projekt PHOENIX

Worum geht es?

In dieser kurzen Buchbesprechung möchte ich auf den Roman „Projekt PHOENIX“ eingehen, in welcher ich auf „Storyteller-Weise“ DevOps Ideen vermittelt werden.

Ich muss gestehen, dass ich seit Tom DeMarcos Roman „Der Termin“, zum Thema Projektmanagement, solche Art der Wissensvermittlung liebe.

Dieses Buch wurde von drei Autoren [Gene Kim, Kevin Behr und George Spafford] geschrieben. Die deutsche Ausgabe ist bei O’Reilly erschienen.

Inhalt

Ein IT Teamleiter aus dem Midrange Bereich (Bill) wird plötzlich zum neuen IT-Manager ernannt und rennt faktisch den Problemen der IT Abteilung nur so hinterher. Reines Reaktionsgeschäft.

Zu allem Überfluß arbeitet die Firma Parts Unlimited schon seit geraumer Zeit mit viel Geldeinsatz an einem neuen Web basierten All-You-can-eat System, welches nicht in die Gänge kommt und von Version zu Version eher schlechter als besser wird.

Als alles zu kollabieren scheint, bekommt Bill den Anruf von einem geheimnisvollen Dr. Reid. Dieser versucht Bill anhand den Arbeitsweisen im Fertigungbereich der Firma, Methoden zur effektiven IT Arbeit und Entwicklung beizubringen. Bill muss sich diese aber stückweise selbst erarbeiten. Er erhält immer nur Anhaltspunkte. So z.B. die „vier Arten von Arbeit/Aufgaben“ zu erkennen.

Anhand dieser Beispiele, versuchen die Autoren die Philosophie und Methodik von DevOps zu vermitteln.

Bill schafft es so, Stück für Stück die IT (Operations) und die Entwicklung (Development) zusammen zu bringen und mit modernen Tools (Cloud) aus dem Chaos zu führen.

Dazu erkennt er, dass neben der Bereitschaft Dinge völlig neu zu denken, auch ein hoher Grand an Automatisierung, gepaart mit einem sicheren Management, die Grundpfeiler der „neuen“ IT mit dem Schlagwort DevOps bilden.

Meine Meinung

Dieses Buch lässt sich auf Grund des Romanformates sehr flüssig lesen. Sicher wird man durch dieses Buch nicht zum DevOps Guru (gibt es das überhaupt?). Man erfährt aber viel über die Philosophie und die Vorgehensweise von DevOps.

Für mich war interessant, dass DevOps scheinbar die Überleitung von Methoden aus der Güter-Produktion auf die „Produktion“ von IT Leistungen im weiten Sinne ist. Besonders im Bereich der Entwicklung von anwendungsspezifischen Software Projekten macht die Zusammenarbeit von Entwicklern und IT Operations sehr viel Sinn. Ebenso die Bereitstellung von neuen Funktionen in „kleinen Häppchen“, wobei hier das Augenmerk auf Kontinuität liegt.

Keine Mega Arbeitspakete mit unzähligen Funktionen, sondern Stück für Stück zum nie fertig werdenden Produkt ;-). Nur, dass dieses Prinzip und kein Mangel ist. Heute arbeiten schon viele Unternehmen nach diesen Prinzipien und verändern und verbessern (hoffentlich) Ihre Produkte ohne riesige „Major-Releases“ zu schaffen.

Als Einstieg in das Thema DevOps daher aus meiner Sicht durchaus empfehlenswert, wenn man anschließend auch sicher ein oder mehrere echte Fachbücher braucht um DevOps tatsächlich umsetzen zu können.

Etwas einseitig fand ich den Eindruck, dass DevOps nur mit Kanban Board wirklich effektiv umzusetzen ist. Hier gibt es sicher unterschiedliche Meinungen, wobei ich selbst Kanban durchaus für eine einfache und gute Methode halte, um Dinge von der Idee zur Fertigstellung zu bringen.

Anomaly Detection – was ist denn das?

Machine Learning nutzen um mögliche Problemfälle automatisch zu erkennen

In diesem Artikel möchte ich eine interessante Anwendung des Machine Learnings vorstellen. Dazu ein paar Grundlagen „was ist und macht Machine Learning“ und eine kurze Erklärung dieses interessanten Ansatzes der z.Z. viel durch die Medien geistert vorstellen.

Abschließend ein Beispiel eines Usecases und einer Anwendung dieser Technik.

Machine Learning – was ist das?

Machine Learning gehört zu dem gesamten Umfeld der Künstlichen Intelligenz [KI]. Hierbei werden Maschinen darauf getrimmt bestimmte Dinge selbstständig zu erkennen und dann auch zu reagieren. Reaktionen können dabei auch einfache Benachrichtigungen über erkannte „Zustände“ sein.

Wikipedia schreibt dazu: „Ein künstliches System lernt aus Beispielen und kann diese nach Beendigung der Lernphase verallgemeinern. Das heißt, es werden nicht einfach die Beispiele auswendig gelernt, sondern es „erkennt“ Muster und Gesetzmäßigkeiten in den Lerndaten. So kann das System auch unbekannte Daten beurteilen (Lerntransfer) oder aber am Lernen unbekannter Daten scheitern (Überanpassung)“ © by Wikipedia 2017

Bild 1: Prinzipbild Neuronales Netz

Das bedeutet also das eine Erkennung immer erst nach einer Lernphase möglich ist. Perfomance Management Systeme arbeiten seit einiger Zeit gern mit solchen Methoden. Hier spricht man immer von „Einschwing oder Lernphasen“ die typischerweise mehrere Wochen andauern bis das System verlässliche Aussagen treffen kann. Will heißen, Aussagen können am Anfang durchaus falsch liegen, denn die Grundlage jedes lernenden Systems sind die Auswertung vieler Daten (Big Data).

Das Thema KI ist eng mit der Disziplin „Neuronale Netze“ etc. verbunden und hatte in den 1990er Jahren schon einmal eine Hochkonjunktur. Leider waren die damaligen Rechnersysteme nicht Leistungsstark genug um den Lernprozess schnell genug durchzuführen, ausserdem fehlte es oft an Datenpools die genug „Lermaterial“ bereitstellen konnten. In Zeiten von Big Data, IoT etc. haben wir genug Daten :-). Ausserdem sind unsere heutigen System in der Lage diese Datenmengen auch zu verarbeiten (auch Hyperconverged ist erst auf Basis der heutigen Systemleistungen machbar geworden!).

Anwendung IT Monitoring

Ein fantastischer Anwendungsfall für Machine Learning ist das Monitoring komplexer und großer IT Umgebungen.

Ein einfaches Beispiel: Früher mussten wir mühsam für „alle“ oder viele Systeme zulässige Schwellwerte ermitteln und konfigurieren. Diese waren dann Ober- bzw. Untergrenzen eines bestimmten Messwertes die bei Über- oder Unterschreitung zu Alarmen oder Notification geführt haben. Da zum Startzeitpunkt eines neuen Services diese Grenzwerte oft nur unzureichend bekannt waren gab es hier jede Menge Potenzial Dienstleistung über Wochen und Monate beim Kunden zu erbringen in denen diese Schwellwerte (thresholds) konfiguriert und mit Regelwerken verknüpft wurden.

Moderne Systeme gehen nun mehr und mehr dazu über auf Grund von Machine Learning Algorithmen selbst zu erkennen wann ein Messwert Anomalien zeigt. Diese hört sich vielleicht leichter an als es ist.

Ein paar Gedankenansätze:

• Was ist normal?
• Ab wann soll alarmiert werden?
• Wie geht das System mit Peaks um?
• Welche Anomalien können zu kritischen Zuständen führen
• uvm.

Ziel ist es dabei das gesamte Operation und die Administratoren von der mühsamen Konfiguration und Anpassung bzw. Nachjustierung von Schwellwerten zu entlasten und statt dessen das System zu trainieren selbst zu erkennen wann etwas außerhalb des normalen (Anomalie) läuft.

Beispiel Usecase

Im Beispiel usecase haben wir eine VM deren CPU Usage über mehrere Woche gemonitort wird.

Bild 2: CPU Usage einer fiktiven VM

Im Bild 2 betrachten wir eine fiktive VM und deren CPU Usage. Wie man sehen kann hat diese VM alle 4 Wochen eine höhere CPU Usage. Dieses scheint in der Anwendung begründet zu sein und wird vom System (grüne Linie) als „Normal“ betrachtet. Erst als die CPU Usage über den normalen Wert ansteigt (+kurzer Versatz) wird ein Alarm ausgelöst, obwohl für diese VM nie ein CPU Usage Schwellwert definiert wurde.

Anomaly Detection in der Praxis

Nutanix bringt ins seinem nächsten Release seiner Management Lösung Prism Pro genau diese Methode zum Einsatz. Prism Pro wird in Zukunft in der Lage sein Alarme auf Basis von „gelernten“ Regeln auszulösen und diese sogar automatisch nachzujustieren!

Bild 3: Anomaly Detection in Prism from .NEXT 2017 © by Nutanix 2017

Wie man im Bild 3 sehen kann zeigt der Graph der Messwerte einmal als dunkelblaue Line den Verlauf der tatsächlichen Messwerte. Die hellblaue „Wellenkurve“ zeigt dagegen den vom System selbst ermittelten „Normal-Bereich“ der über die Zeit durchaus schwanken kann! Erste eine Überschreitung dieses Bereichs führt zu einer Erkennung einer Anomalie die dann mit kurzem „Verifizierungszeitraum“ (zur Vermeidung von Alarmen auf Grund von Peaks) zu einem tatsächlichen Alarm führt.

Fazit

Mit Hilfe von Machine Learning und verlässlichen Daten können Administratoren ohne zeitaufwändige Beobachtung Ihrer Systeme und der manuellen Definition von Schwellwerten zuverlässig über „Unnormale“ Verhalten Ihrer VMs oder Applikationen informiert werden.
Gerade bei großen Umgebungen kann hier ein deutlicher Administrativer Aufwand eingespart werden ohne auf Alarmierungen von möglichen Problemfällen verzichten zu müssen.

All in one oder was? Hyper-konvergente Systeme

Hyperconvergence – der neue Hype?

Nach längerer Pause möchte ich heute mal wieder ein aktuelles Thema aufgreifen und ein paar Grundlagen und Gedanke dazu vorstellen.

Es geht um das Thema Hyper-konvergente Systeme. Was ist das? Was machen diese Systeme? Wie sind sie aufgebaut?  und was bringt mir das?

Was sind Hyper-konvergente Systeme?

Hyper-konvergente Systeme sind im ersten Ansatz x86 basierte Hardware die verschiedene Komponenten aus einem Rechenzentrum vereinen. Hier werden, simpel ausgedrückt, Computing Leistung (CPU und RAM) mit Netzwerkfunktion und Storage verbunden. Dieses alles in einer Box.

Ziel ist es IT Infrastruktur zu vereinfachen und so auf Administrativer Seite einfachere Strukturen zu etablieren, Man könnte es mit „Alles aus einer Hand“ umschreiben. Dieses greift, für die doch komplexe Idee natürlich als einzelnes Schlagwort, zu kurz.

In einem älteren Artikel habe ich das Thema im Prinzip schon einmal angesprochen (Zukunft der Ressourcen im RZ). Hier ging es zwar primär um die Last am Hypervisor, aber wir werden sehen das ein Hyper-konvergentes System nicht so viel anders zu betrachten ist.

Abbildung 1: Hyper-konvergente Systeme – OHNE und MIT Management Funktionalität

Was machen diese Systeme ?

Hyper-konvergente Systeme sind DIE Verwirklichung des Software defined Data Centers [SDDC]. Hier wird vor allem Storage und Netzwerk in Software gegossen und realisiert. Grundlage dafür sind (z.B. im vmware Jargon) vSAN und NSX bzw. allgemein Software defined Network [SDN]. Erst diese Lösungen ermöglichen es die ehemaligen RZ Bereiche Storage und Netzwerk auch in die Hyper-konvergente Appliance zu packen. Das ganze wird vom Hypervisor „zusammengehalten“, dieser sorgt für die Ressourcenverteilung und die Orchestrierung.

Nun gibt es Hyper-konvergente Systeme die „nur“ die einzelnen Silos in einer Box zusammenfassen und alles weiter weitgehend der Virtualisierungsplattform überlassen. Andere bieten spezielle Management Lösungen auf, oder für das entsprechende System. Anbieter sind hier z.B. Simplivity, Nutanix oder vmware EVO:RAIL um nur einige zu nennen.

Wie sind sie aufgebaut?

Wie bereits angedeutet machen echte Hyper-konvergente Systeme nicht einfach eine Zusammenfassung der RZ Silos: Computing, Storage und Networking in eine Box oder Appliance aus. Diese Funktionen werden sehr oft auch durch spezielle physikalische Einschübe und Karten unterstützt und ergänzt. So sind eingebaute Switche, Karten zur Hardware unterstützten Deduplizierung, Replikation usw. anzufinden.

Gerade die Funktionen des eingebauten Managements sind die tatsächlichen Plus Punkte welche die Systeme einerseits unterscheiden, andererseits aber auch erst zu den Hyper-konvergenten Lösungen machen.

Problem hierbei ist, das meines Wissens nach nur Lösungen eines Anbieters miteinander kompatibel sind! Hier gilt es zu prüfen ob man die Abhängigkeit von einem Anbieter will und ob dieser auch das anbietet was man braucht. Bitte daran denken, das Sie vielleicht in einem  ½ oder 1 Jahr größere oder andere Systeme brauchen die der gewählte Anbieter so vielleicht nicht bereitstellen kann. Ein Anbieterwechsel wird dann aufwendig und unter Umständen auch sehr teuer.

vmware EVO:RAIL ist hier eine kleine Ausnahme, da hier verschiedene Anbieter vorhanden sind, die diese „Definition“ unterstützen.

Was bringt mir das?

Tja, was bringt mir nun der Einsatz einer Hyper-konvergenten Plattform? Vor allem eine Vereinfachung der Systemlandschaft im RZ. Wenn denn alle mitspielen ;-). Denn typischerweise reissen Sie vorhandene Team- und Aufgabenstrukturen auseinander bzw. ein. Mit einer Hyper-konvergenten Plattform haben plötzlich Netzwerkadministratoren oder Storageexperten keine, bzw. andere Aufgaben. Also bitte dieses vorher in Betracht ziehen und sehen wie die Kollegen eingebunden bzw. „verändert“ werden können.

Die Hersteller sprechen oft davon, das Hyper-konvergente Systeme eben keine „Spezialisten“ mehr benötigen. Dieses ist zweischneidig (siehe oben) und nicht ganz so einfach wie dargestellt. Sicher lässt sich ein vSAN mit wenigen Mausklicks und Konfigurationen auch von Storage „Laien“ erstellen. Brauche ich daher keine „Kenner der Materie“ mehr? Ich denke nicht. Gerade im virtuellen Netzwerkbereich hilft mir z.B. NSX dabei schnell und konsistent auf Anforderungen zu reagieren, aber ohne Netzwerkkenntnisse geht es nicht. Ausserdem – was mache ich im Falle eines Fehlers oder Problems? Fachwissen ist immer noch mehr als nützlich und notwendig. Nur werden mit diesen Systemen die „KnowHow Silos“ aufgebrochen. Gut ist es wenn ein Team nun sowohl Netzwerker, als auch Storage Spezialisten und Kenner der Hypervisor Plattformen beinhalten.

Wenn alles passt gewinnen Sie tatsächlich eine höhere Dynamik bei Erweiterungen und Änderungen im RZ. Wie so oft werden hier wieder die OPEX Kosten in der Fokus geraten.

Ausserdem eigenen sich Hyper-konvergente Lösungen nicht für jede Art von Workload und Anforderung. Daher muß sicher „noch“ nicht jeder Storageexperte um seinen Job bangen, Weiterbildung kann aber nie schaden ;-).

Vorteile

Hyper-konvergente Syteme sind Lösungen für virtuelle Umgebungen. In virtuellen Umgebungen steht die VM im Mittelpunkt, der Workload der einzelnen VM ist mit klassischen Lösungen aber nicht, oder nur sehr schwer zu messen und zu steuern.

Beispiel Storage: Früher hatte jeder physikalische Server seine entsprechenden Storage Anbindungen. Der Datenbank Server eher schnelle LUNs für die Logpartitionen. Der Fileserver dagegen eher mehr „Masse“ als Geschwindigkeit. Packt man virtuellen Load auf „klassische“ physikalische Umgebungen geht viel Potential verloren. Eine LUN die 5-10 VMs hostet kann entweder für die einen gut und die anderen schlecht konfiguriert werden, oder ein Mittelmass für alle bereitstellen.

Policie driven ist hier der Ansatz den Hyper-konvergente Lösungen fahren. Je nach VM und „Leistungs- oder Anforderungsparametern“ werden diese optimiert platziert und betrieben (Netzwerkbandbreite, Storage IOPS usw.) je nachdem was die Lösung bereitstellen kann.

Welche Szenarien sind gut für Hyper-konvergente Lösungen?

Aus meiner Sicht vor allem zwei Bereiche:

1. Unternehmen mit vielen kleineren Standorten: Hier bieten die meisten Hersteller eine deutliche Vereinfachung in den Rechnerräumen (vom RZ zu sprechen ist hier oft übertrieben) der Zweigstellen oder kleinen Standorte. Nun stehen ein oder zwei 2U Systeme statt mehrere Hosts, Switche und Storage Systeme im Rack. Auch bestehen oft Funktionen um die Aussenstellen mit einer Zentrale oder untereinander zu backupen oder zu synchronisieren. Die Management Funktionen der Systeme sind hier besonders zu betrachten. Wir alles einfacher zu administrieren und zu monitoren?
   Hier kommen auch die gern genannten „einfach zu installierenden“ Systeme zum Tragen. Gerade in abgesetzten Standorten gibt es eben nicht das Spezialisten-Team. Hier sind diese Systeme oft im Vorteil.
2. Mal wieder die oft strapazierten VDI (Virtual Desktop Infrastructure) Umgebungen, denn meist ist es simpel zusätzliche Ressourcen in Form von weiteren Appliances in einen bestehenden Verbund Hyper-konvergenter Systeme einzubinden (natürlich nur vom gleichen Hersteller!). Somit ist eine Skalierung recht einfach durchzuführen. Auch hier gehört wieder ein kritischer Blick auf die Management Lösungen der Appliances.

Knackpunkte

Wie jede Lösung haben auch die Hyper-konvergenten Systeme einige Knackpunkte die vor der Anschaffung genau untersucht und bedacht werden müssen. Einige habe ich schon angesprochen.

• Prüfen Sie die Zuständigkeiten und Strukturen ihrer IT! Nichts macht mehr Probleme als Mitarbeiter oder Kollegen die um Ihre Position oder gar Stelle bangen. Der Storage Kollege der sich überflüssig fühlt oder der Netzwerker der sich übergangen fühlt machen Ihnen spätestens im Nachgang große Probleme.
• Die Anforderungen an die unterschiedlichen Workloads Ihrer IT Systeme sollten im Vorfeld bekannt oder ermittelt werden. Leistet die angedachte Lösung alles was Sie benötigen? Oder ist die Hyper-konvergente Lösung nur für einen bestimmten Bereich sinnvoll (warum auch nicht, nicht immer muß man alles auf einmal ändern).
• Erweiterung der Infrastruktur! Haben Sie bereits 10GB Netzwerke in allen Standorten? SDN und virtual SAN funktionieren nur sinnvoll mit dieser Bandbreite. Also zur Investition auch gegebenenfalls neue 10GB Switche + Kabel + Zubehör hinzurechnen. (Manche Hyper-konvergenten Systeme beinhalten echte physikalische Switche, die ersetzten aber keine redundanten separaten Switche!)
• Redundanz: Auch Hyper-konvergente Systeme arbeiten erst ab min. zwei Systemen redundant! Also „mal ein System anschaffen und sehen was es bringt“ ist nicht möglich.
• Wie passen die Hyper-konvergenten Systeme grundsätzlich in die Systemlandschaft (Backuplösungen, Administration und Management, Monitoring etc.)

Fazit

Wie man vielleicht aus diesem kurzen Beitrag entnehmen kann, bieten die Hyper-konvergenten Systeme im gut geplanten und richtigen Umfeld viele entscheidende Vorteile. Um diese zu nutzen gibt es aber doch eine ganze Menge zu beachten und zu planen. Wie immer ist eine gute Vorarbeit das halbe Projekt. Vergleichen Sie nicht nur stumpf Funktionen, versuchen Sie vielmehr Anbieterlösungen an Hand von konkreten Anforderungsliste zu vergleichen und durchaus auch den einen oder anderen PoC (Proof of Concept) anzufragen.

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 vCenter Operations Manager – Update auf 5.7

Wie kann man den vCenter Operations Manager updaten?

Da vmware ja vor kurzem die neue Version des vCenter Operations Managers V5.7 veröffentlicht hat, gibt es sicher den einen oder anderen der eine ältere Version betreibt und nun updaten möchte. Daher hier kurz und knapp wie das geht. Dieses gilt übrigens exemplarisch auch für weitere Updates!

Voraussetzungen

Als erstes benötigt man das entsprechende Update Pack (im Moment: VMware-vcops-5.7.0-1073531.pak).

Da der vCenter Operations Manager in als vApp mit zwei VMs ausgeliefert wird könnte die Idee aufkommen das ein Update etwas schwierig ist. Das Gegenteil ist der Fall.

Die beiden VMs sind einmal die „Analytics VM“ und zweitens die „UI VM„.

Vorgehen

Alle Aktionen gehen über die Administrative Konsole der „UI VM„. Dazu muß die URL „https://<IP der UI VM>/admin“  am besten über einen Google Crome aufgrufen werden.

• Login als „admin“
• Auf den Reiter „Aktualisieren“ [1] gehen
• Mittels „Durchsuchen“ [2] das Update Pack auswählen
• Auf den Button „Aktualisieren“ drücken – und abwarten!

Irgendwann nach ein paar Minuten wird man automatisch ausgeloggt. Anschließend kommt die Login Maske wieder, mit dem Hinweis man solle sich einloggen um den Update Prozess zu monitoren.

Normalerweise war es das. – Viel Erfolg

vmware Resource Pools als Resource Silos einsetzen

Wie in meinem letzten Beitrag über den Einsatz von Resource Pools beschrieben kann man in vmware Resource Pools eine Einstellung treffen ob dieser Resource Pool Resourcen vom übergeordneten Pool beziehen darf oder nicht (Expandable Reservation).

Da der übergeordnete Pool in einem vmware vSphere Cluster die gesamten Cluster Resourcen umfasst, (CPU Leistung aller Hosts im Cluster summiert, ebenso physikalischer RAM in allen Hosts aufsummiert) besteht die Möglichkeit Hostübergreifende Resource Silos zu bilden.

Die Idee der Resource Silos sieht dann folgendermassen aus:

Wir nehmen mal eine Unternehmen mit verschiedenen Abteilungen an die alle auf einem vSphere Cluster gehostet werden. Jede Abteilung hat verschiedene VMs die sie betreibt. Möglicherweise haben die Abteilungen sogar das Recht selbst VMs zu erstellen oder umzukonfigurieren.

Der „arme“ vmware Administrator steht nun vor der Aufgabe mit Bordmitteln dafür zu sorgen, das die Abteilungen größtmögliche Freiheiten genießen, sich aber nicht gegenseitig behindern, indem Sie zu viele Resourcen aus dem Cluster beziehen. Was könnte man nun tun?

Eine interessante Lösung währe ein Konzept basierend auf Resource Pools.

Jede Abteilung wird in einen eigenen Resource Pool gepackt. Das sähe dann z.B. so aus:

Das alleine nutzt unserem Admin aber noch nicht sehr viel. Er kann nun zwar den Abteilungen Rechte auf Ihre Resource Pools geben, doch Resource Pools nur für Rechtestrukturen sollten niemals angelegt werden. Das währe auch mit Foldern unter dem View „VMs und Templates“ möglich.

Erinnern wir uns mal an den Schalter „Expandable Reservation“ für CPU und Memory. Des weiteren denken wir mal an die Möglichkeit Limits zu setzen.

Hier haben wir eine interessante Möglichkeit Resourcen Silos zu definieren.

Wir nehmen dazu unsere Cluster Resourcen, bauen für jede Abteilung im Cluster einen „Abteilungs-Root-Resource Pool“ und konfigurieren diesen wie folgt.

–          Expandable Reservation sowohl für CPU als auch für Memory := NO

–          Limit für Memory z.B. für eine Abteilung 32 GB, für eine andere 64 GB usw. je nach Anforderung bzw. bei zahlenden Kunden nach Bezahlung

–          CPU MHz ebenso wie Memory mit einem festen Limit

Was passiert nun?

Eine Abteilung kann innerhalb Ihres zugewiesenen Pools Resourcen bis zum definierten Limit verbrauchen (getreu dem Motto „Die merken schon wenn es eng wird“). Erreichen sie das Limit können sie keiner Nachbarabteilung „das Wasser oder die Resourcen abgraben“, denn durch den Schalter „Expandable NO“ werden bei Overcommitment im Resource Pool keine weiteren Resourcen vom Cluster bezogen.

Durch das Limit auf CPU und Memory haben wir praktisch ein Resourcen Silo im Cluster gebaut. So als wenn die physikalischen Abteilungsserver der Vergangenheit die Limitierung der IT Resourcen darstellen. Vorteil hier, wenn tatsächlich mehr Resourcen benötigt werden kann entweder der Resourc Pool neu definiert werden, oder es wird weitere Hardware beschafft und dann der Resource Pool erweitert (Limits erhöhen!).

Somit haben wir ohne Zusatztools einfach und sicher unsere vSphere Cluster Resourcen auf die Abteilungen heruntergebrochen.

Was halten Sie von dieser Idee? (Kommentare erwünscht)

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.