Archiv für die Kategorie ‘Allgemeine Themen’

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

NeuronaleNetze

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.

CPUUsage

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!

anomaly-detection.png

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.

Advertisements

Konzepte, die entstehen – Konzepte, die vergehen

Nach längerer Abstinenz möchte ich heute ein Thema aufgreifen, welches mich schon einige Monate beschäftigt.

Nach dem Virtualisierungs- Hype reden nun alle von Microsegmentierung und Container a la Docker. Dabei bin ich alles andere als ein Docker Spezialist. Ich habe mir einfach einiges zum Thema Container angelesen und angesehen. Worum es mir in diesem Beitrag geht ist aber ein Nachdenken darüber, welche Konzepte wir im Rechenzentrum / DataCenter [RZ] schon so hinter uns haben und was dabei, vom Grundkonzept her, wieder auftaucht.

Container sind für mich so ein Phänomen. Doch am besten fange ich einfach mal ganz weit vorne an. Also nach IT Massstäben Steinzeit.

(Dieser Artikel erhebt dabei weder Anspruch auf Vollständigkeit, absolut korrekte Darstellung, sondern meine private Ansicht)

Wie das mit dem Großrechner so begann

Der gute alte Mainframe, bis heute in einigen Branchen immer noch die tragende Säule der IT im RZ. Sicher ist ein Mainframe von heute nicht mit dem von vor 20 oder mehr Jahren zu vergleichen aber vom Konzept funktioniert er immer noch so. Sehr effizient aufeinander abgestimmte Komponenten. Dauerbetrieb mit Wartung im Betrieb möglich. Hohe Ein- und Ausgabe Kapazität bei der Bearbeitung von Massendaten.

Sehr alter Mainframe

©pcmag.com – Sehr alter Mainframe

Heute hat der Mainframe sicher gelernt, ähnlich wie die x86 Server, virtuelle Maschinen auszuführen (z.B. Z-Linux auf IBM). Im Prinzip ist die Grundarchitektur aber gleich geblieben.

Nichts desto trotz wurden die Programme als einzelne „Jobs“ auf dem System ausgeführt, jedes in seiner Umgebung, geschedult und von den anderen, wenn gewünscht, abgeschottet.

Die Dezentralisierung des RZ beginnt

Mit dem Aufkommen immer leistungsfähiger Endgeräte (PC’s) kam nun die Idee auf, Aufgaben und Verarbeitung von Daten zu dezentralisieren und auf die PCs auszulagern. Windows™  sei Dank wurde die Bedienung nun auch für „angelernte“ Laien 😉 immer einfacher. Problem dabei – viele Dokumente und Daten wurden jetzt im Unternehmen verteilt und waren unter Umständen nur per „Turnschuh“ Transport erreichbar.

Zentrale Datenhalden und Druckdienste

Nun begann die Zeit der zentralen Datenhalden und Druckdienste. Bereitsteller wie NOVELL™ Banyan Vines™ (Wer kennt das noch?) sowie der Anfangs verschmähte Spät-Kommer Windows Advanced Server (später NT und noch später einfach Windows Server 2000 und folgende).

Banyan_Novell_NT

Banyan Vines – Novell Netware – Windows NT Advanced Server

Hier konnte man, wenigstens im Anfang, nur File und Druckdienste, sowie eine zentrale Userverwaltung beziehen. Später kamen dann Versuche dazu, z.B. eine Datenbank auch auf dem Server zu platzieren (Btrieve by Novell usw.). Diese „Dienste“ liefen auf den Servern mit und zwar meist „nicht dediziert“, also mit den File und Druckdiensten zusammen.

Bitte bedenken! Die zentrale Datenverarbeitung machte zu dieser Zeit immer noch der „Host“ im Hintergrund. Nur griff man jetzt nicht mehr per Grün- oder Amber-Terminal auf diesen zu, sondern per Terminalemulation. Davon lebten zu dieser Zeit ein paar Firmen recht gut (Hummingbird etc.).

Für spezielle Aufgaben gab es auch schon die verschiedenen UNIX Anbieter. Graphik war z.B. die Domäne von Silicon Graphics™ und SUN Microsystems™.

Spezialisierte Server Systeme

Nach dieser Phase der „einfachen zentralen Dienste“ starben die ersten Protagonisten dahin und Microsoft startete durch.

Gerade Microsoft schaffte auch eine Art Microsegmentierung ;-), denn bis heute ist es ratsam jede Serverfunktion auf eine oder mehrere separate Windows Server Maschinen(physikalisch oder heute VM) zu verteilen. Durch dieses Konzept entstanden plötzlich eine große Anzahl von Server Systemen im RZ. Statt einem großen Host und vielleicht einer Handvoll Peripherie Systemen explodierte die Anzahl der Server im RZ geradezu. Viele klassische IT Abteilungen hatten damit schwer zu kämpfen, zumal zentrale Management Tools noch eher rar waren.

Ausserdem entstand nun eine Art „Religionskrieg“ zwischen den Verfechtern der verschiedenen Systeme.

  • Auf der einen Seite die altvertrauten Host- Menschen mit ihren „Big Iron“ Systemen. Dicke, zuverlässige aber nicht im neuen Sinn flexible Systeme die zudem sehr teuer waren.
  • Auf der anderen Seite diverse UNIX Derivate (SUN Solaris, HP UX, IBM AIX usw.) die jeder den Alleinherrscher- Status beanspruchten (und schlußendlich daran scheiterten!). Alles irgendwie Unix, aber inkompatibel und jeder mit Eigenarten.
  • Und zuletzt Microsoft mit Windows Server, die im Hintergrund so langsam einen Service nach dem anderen übernahmen (sicher auch auf Grund der immer leistungsfähiger werdenden Intel Systeme an sich).
    Aber jeder Service und Dienst wollte hier gern ein eigenes System haben. Angefangen von AD, DHCP, DNS die man noch irgenwie zusammen betreiben kann über Exchange, MS SQL, SharePoint etc. Eben alles was so auf Windows Server lief und läuft.
  • … alle anderen Systeme mit weniger Verbreitung lasse ich hier mal weg. Dieses ist dabei meine private Einschätzung – ohne Wertung im Detail.

Die Virtualisierung beginnt

Durch die immer günstiger werdende Rechenleistung auf x86 Seite schafft es die Lösungsgemeinschaft Intel – Microsoft tatsächlich, daß viele Server Systeme eine nicht unerhebliche Zeit des Tages vor sich hin „ideln“, also mehr mit sich als mit der eigentlichen Aufgabe beschäftigt sind.

Das macht sich vor allem die Firma vmware™ zu eigen und baut einen Hypervisor der es schafft, vielen virtuellen Maschinen vorzugaukeln, sie würden auf dedizierter Handware laufen, obwohl sie zusammen mit anderen auf einem oder wenigen physikalischen Servern leben. Funktionen wie das Verschieben solcher VMs im laufenden Betrieb (vMotion) und vieles mehr räumen jetzt im RZ wieder etwas auf. Die Komplexität wird meiner Meinung nach aber nicht weniger, denn immer neue Services verlangen immer mehr neue VMs die z.T. mit 90% gleichem Basis Stack unterwegs sind.

Man muß bedenken, hier laufen immer noch separate Systeme mit hoher Redundanz, nur eben nicht auf einzelnen physikalischen Servern, sondern gepackt als VM auf mehrere Hypervisoren. Diese bringen selbstverständlich viele viele Vorteile mit sich. Die optimale Ausnutzung der Serverhardware tritt dabei immer mehr in den Hintergrund.

Gerade die immer weiter vordringenden Linux Systeme mit dem klassischen Software Stack (z.B. LAMP := Linux, Apache Webserver, MySQL DB und PHP) bringen uns auf neue „ALTE“ Ideen!

Der Container erscheint

So wie vmware im Virtualisierungs- Umfeld sicher als ein Pionier und Vorreiter gelten darf, kann man die Firma Docker™ für den Bereich Container sehen.

Dabei sind Container, wenigstens unter Unix/Linux eher ein alter Hut.Cgroups und Namespaces sind bekannte Linux Funktionen die hier aufgegriffen wurden und „abgerundet“ als Container Technologie der neue Hype sind.

Docker_und_Co

VMs versus Container

Was haben wir denn nun hier vor uns? Einfach abstrahiert haben wir den einzelnen Applikationen nur die für sie spezifischen System DDLs bzw. Libraries und Umgebungsanteile mitgegeben und führen diese auf EINEM Operating System aus. Also nicht 5 oder 10 vollständige Linux Systeme, sondern nur ein Linux System auf dessen Kernel und Ressource mehrere Applikationen mit Ihrem Applikationsstack laufen.

Gesteuert wird dieses durch die Container Engine. Riesen Vorteil. Die einzelnen Container sind kleine Pakete (im Gegensatz zu einer vollständigen VM) und durch verschiedene Techniken auch noch portabel zwischen mehreren Linux Hosts (bei entsprechender Vorbereitung sogar zwischen verschiedenen Distributionen!).

Haupt Punkt dabei: Das ganze ist aktuell hauptsächlich für Linux Applikationen vorhanden, aber auch Microsoft schraubt an diesem Konzept. Hyper-V 2016 soll es z.B. ermöglichen Docker Container auszuführen.

(Linked Clones verbinden nur Storageseitig mehrere gleichartige Systeme mit einer „Systemplatte“, das ist eine Verbesserung, aber keine vollständige wie Container)

Zusammenfassung

Was macht nun das „Hatten wir schon“ aus? Nach meinem Empfinden haben unsere IT Urgroßväter ihre Programme für den Mainframe (Host) schon damals, ähnlich wie wir heute Container, geplant und betrieben. Alles was Ein- und Ausgabe, Zugriffe auf Netz etc. betraf, lieferte der Host. Die Programme liefen in Ihrer Umgebung als einzelne Jobs die man schedulen und priorisieren konnte und die von Host zu Host, bzw. Hostbereich zu Hostbereich, portabel waren. Genau das Konzept findet man bei Containern wieder.

Für Container spricht die höhere Packungsdichte als bei VMs und das schnelle Starten der Container, da das OS ja schon läuft. Das Thema Sicherheit bedarf dagegen sicher einer separaten Betrachtung. Falls ich mal Zeit finde dazu vielleicht irgendwann mehr.

Somit sind wir vom RZ und dem Host über die Dezentralisierung wieder zurück ins RZ und wenn wir einen „Container-Cluster“ als Host betrachten, auch wieder bei unseren „Jobs“ die nun Applikationen in Containern darstellen. Hochflexibel, schnell zu deployen und in Massen zu betreiben. Alte Host-Hasen werden sich da doch gleich zuhause fühlen (wenigstens vom Konzept her).

Fazit

Diese, zugegeben, mit wenig technischer Tiefe aber dafür mehr Humor dargestellte Evolution vom Host zum Container, hilft vielleicht doch das eine oder andere Neue leichter zu verstehen und durchaus über neue Konzepte im Licht von Bekanntem nachzudenken.

Neben Docker gibt es übrigens auch noch weitere Anbieter solcher Lösungen, wie Kubernetes (Google), LXD (Canonical) oder Rocket/rkt (CoreOS). Auch vmware hat einen“Docker-Basis VM“ im Angebot (Project Photon).

 

 

 

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

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.

Einige Eindrücke und Trends vom vmware Winter Camp 2014 – München

Nach langer Zeit der Blog Abstinenz, 😉 möchte ich heute ein paar Eindrücke und Trends vom vmware Winter Camp 2014 Ende November in München mitteilen. Es sind rein persönliche Punkte die mir interessant erscheinen.  vmware hat, nach meinem Empfinden, zwei Schwerpunkte gesetzt.

  1. Enduser Computing
  2. Software Defined DataCenter [SDDC] in Form von Automation Solution und NSX bzw. Addons

Es gab dazu noch einen „Nicht-vmware“ Gast auf den ich am Ende kurz eingehen möchte, da dieses für mich ein Highlight der Veranstaltung war.

Enduser Computing

Im Bereich Enduser Computing gab es eine sehr interessante Vorstellung einer neuen vmware Lösung die auf einem Zukauf basiert.

AppVolume (früher CloudVolume):

AppVolume ist eine, für mich, neue Art Applikationen für Virtuelle Desktops (im Prinzip auch für physikalische) „very fast“ bereitzustellen. Das Geheimnis sind, wie der Name schon sagt die AppVolumes. Fertige Virtuelle Platten (VMDKs) in welche Applikationen hineininstalliert wurden die anschließend an mehrere VD-VMs gleichzeitig gemountet werden können. Dieses bringt praktisch „on the fly“ neue Applikationen zum Enduser.

AppVolumes

© by vmware: Prinzipbild AppVolumes

Wie man in dem Bild sehen kann, werden die vorbereiteten AppVolumes an die Ziel-VM gemountet. Alle Pfade zu den „neuen“ Applikationen werden vom AppVolume Treiber nun transparent, für den Enduser unsichtbar von dieser VMDK in das Windows System „verbogen“. (AppVolumes sind im Explorer nicht sichtbar, nur in der Datenträgerverwaltung). Damit erscheinen die Applikationen sofort im Startmenü oder auf dem Desktop und sind nutzbar!

Es gibt auch beschreibbare AppVolumes die Userdaten, z.B. Einstellungen an Applikationen usw. aufnehmen können. Da AppVolumes an Active Directory User, Gruppen, OUs und Computer gehängt werden, kann solch eine Zuweisung mit dem Anwender mitwandern! Das ist eine sehr interessante Lösung.

Die Erstellung einer neuen AppVolume VMDK wurde vorgeführt und stellt sich recht einfach dar. Hier wird praktisch eine leere AppVolum VMDK an die Paketier VM gemountet. Der AppVolume Treiber im Paketiermodus registriert nun alle Änderungen und bringt die Daten ausschließlich auf das AppVolume. Nach einem Reboot der Paketier VM ist das neue AppVolume fertig. Kling Genial und sieht sehr vielversprechend aus.

 Software Defined DataCenter [SDDC]

Vom SDDC spricht vmware schon länger. Alle Hardware wird abstrahiert und die Komplexität wandert in die Software Schichten. Damit sind dann schnelle Änderungen und eine hohe Dynamik z.B. bei Laständerungen und neuen Services möglich.

Um dieses zu erreichen sprechen einige nur von Technologien wie:

  • Virtualisierung der physischen Server := vSphere usw. die Hypervisoren
  • Virtualisieren der Storage Systeme :=  vSAN oder allgemein alle Shared Storages die schnell und dynamisch angepasst werden können (z.B. DataCore etc.)
  • Virtualisieren der Netze :=  Software Defined Networking (SDNs) mit der vmware Ausprägung NSX
  • …. usw.

Was oft vergessen wird ist aber der Part Ausführung und Konfigurationen sowie Deployments! Hier treten Tools wie vRealize Automation (ehemaliges Automation Center) aber auch „rudimentärer“ Tools wie der vmware Orchestrator, ein immer noch „Hidden Champion“ in Erscheinung. Also ohne Workflow Engine und entsprechenden Frontend Lösungen keine SDDCs!

(In diesem Bereich ist auch mein neuer Arbeitgeber tätig. Ich hoffe das ich „unsere“ Lösung demnächst einmal hier vorstellen kann)

Aber, wer stellt denn nun z.B. Laständerungen fest und kann Automationen triggern? In meinen Augen geht ohne die klassische Disziplin Monitoring und Systemmanagement gerade im SDDC gar nichts. Tausende von Metriken kann kein Admin oder Operator manuell oder per Selfdeveloped Script überwachen.

vmware tritt hier schon länger mit dem Operations Manager und LogInsight als sehr modernen und interessanten Lösungen auf. Aber auch die wollen verstanden, konfiguriert und genutzt sein.

Auch hier gab es ein paar sehr interessante Sessions von kompetenten vmware Kollegen.

Fazit

Alles in allem eine nette und informative Veranstaltung mit z.T. sehr praxisnahen Sessions. vmware hat hier wirklich ein paar gute Leute im Feld. Einige kenne ich persönlich und kann nur sagen – Hut ab vor deren KnowHow.

Zum Schluß noch mein persönliches High Light: Der Vortrag „Verhandeln im Grenzbereich“ von Matthias Schranner einem ehemaligen Polizisten und Verhandlungsführer bei Geiselnahmen usw. Er hat z.B. die Frage gestellt: „Sie stehen als Polizist einem Geiselnehmer gegenüber der droht die Geisel zu erschießen wenn Sie nicht verschwinden. Was tun Sie?“ Keine leichte Frage aber eine interessante Methodik der Reaktion die im Vortrag frisch und anschaulich präsentiert wurde.

Ein Fazit aus Schranners Sicht „Jede Verhandlung ist ein Konflikt“ – „Konflikte kann man nicht mit Kompromissen lösen“ bilden Sie sich Ihre eigene Meinung dazu!

Wenn Sie die Chance haben Matthias Schranner live zu erleben  – Nicht entgehen lassen!

Wer stellt in Zukunft welche Ressource im Rechenzentrum breit? – Was ändert sich – Was verschiebt sich?

Zum Jahresanfang 2014 möchte ich einmal einen Artikel vorstellen der eher etwas „philosophisch“ daherkommt. Es geht um Überlegungen wie sich der Ressourcenverbrauch eines Rechenzentrums in den nächsten Monaten und Jahren verändert. Gerade im VMware Umfeld stehen ja einige neu Themen an, die im laufe des Jahres sicher an Fahrt aufnehmen. Virtuelles Storage [vSAN], virtuelle Netzwerk [NSX] und sicher noch viel mehr Lösungen verschieben die Gesamtlastverteilung in einem Rechenzentrum der Zukunft.

Dieses Thema möchte ich einfach kurz betrachten und zu Diskussion freigeben.

Es geht hier nicht um Positive oder Negative Bewertung! Eine Betrachtung der technischen Entwicklung und deren Auswirkung sehe ich als viel interessanter an. Ist dieses dann das „Software defined DataCenter“ [SDDC]?

Entschuldigt das ich meist die VMware Begriffe verwende, aber aus meiner Sicht ist VMware hier durchaus Vorreiter und ausserdem kenne ich diese Plattform nun mal am besten 😉 Andere Anbieter sollen keinesfalls ausgeschlossen werden.

Der X86 Host als Arbeitstier für ALLES?

Schaut man sich die Hauptakteure im DataCenter Bereich, vor allem im Virtualisierungsbereich an (nicht nur VMware), dann denke ich, kann man erkennen das immer mehr „Last“ und damit auch Ressourcenverbrauch direkt auf die X86 basierten HOSTS (für VMware ESXi) verlagert wird.

Begonnen hat das in Form von Virtuellen Maschinen die auf einmal nicht nur Applikationen der klassischen Art beheimateten, sondern auch als virtualisierte Router, Firewalls oder auch Anti Virus Lösungen auftraten. Zum Teil schnell erfolgreich, zum Teil noch auf dem Weg zum Erfolg.

Der Beginn der Verlagerung

Meiner Meinung nach hat das alles aber viel viel früher mit der Einführung des vSwitch (virtueller Switche) gestartet! Auf einmal gab es virtuelles Netzwerk und entsprechende Konfigurationen ausserhalb der etablierten „Netzwerk-Truppe“. Mit Einführung des „distributed virtuell Switches“ (VMware Bezeichnung) ist dann endgültig eine eigene Netzhierarchie in der Black-Box, Virtualisierungs-Plattform entstanden.

Der Beginn

Der Beginn

Der nächste Schritt

Als nächster Schritt kamen dann VMs mit Infrastuktur Aufgaben, wie virtuelle Router (Vyatta was so ein Vorreiter) vShield Zones und vShield Edge als genannte Beispiele. Eine Schnittstelle im Hypervisor gekoppelt mit einer VM als zentrale Anti Virus Lösung wurde im VMware Umfeld als vShield Endpoint + Anti Virus Herstellerlösung als, quasi hybrid Lösung, etabliert.

Der nächste Schritt

Der nächste Schritt

Die weitere Entwicklung

Mit neuen Lösunge die nun auch das, für Virtualisierung zwingend notwendige SAN, in Software abbilden (DataCore usw. lässt grüßen ;-)) VSA und nun vSAN stehen die nächsten Bereiche zur reinen „Softwareisierung“ an. Wobei die VSA Lösung eher im vorigen Schritt angesiedelt ist, da diese Lösung auf einer VM basiert, während vSAN direkt in den Hypervisor implementiert wurde.Wenn dann auch noch das Netzwerk komplett als virtuelle Lösung dargestellt werden soll (mit NSX) dann haben wir plötzlich komplett andere Workloads in einem Rechenzentrum zu betrachten, zu beachten und zu kalkulieren!

Die Zukunft - Jetzt

Die Zukunft – Jetzt

Fazit – Offene Diskussion?

Wie man erkennen kann wird Workload verschiedener physikalischer Lösungen wie Router, Firewalls, Switche und Storage Systeme auf den X86 Host verlagert. Dieses bedeutet noch kein Ende der Physik! Schlussendlich müssen IP Pakete immer noch durch physikalisches Netzequipment reisen 😉

Der HOST der Zukunft!

Der HOST der Zukunft!

Große Datenmengen werden auch weiterhin in entsprechenden Storage Systemen gelagert, aber welcher Anteil in den genannten Lösungen landet werden wir sehen – Ausserdem wollen die Storage und Netzwerkausrüster ja auch leben.

Eine spannende Diskussion währe schön!