Archiv für die Kategorie ‘vmware’

vmware Lizenzänderungen – Enterprise Edition verschwindet

In diesem kurzen Artikel möchte ich heute einmal eine weniger technische, aber für viele vmware Kunden und Partner wichtige Änderung besprechen. Ich möchte mich hier nicht auf alle Aspekte beziehen, das können die vmware Distributoren besser :-). Mir geht es eher um die technischen Auswirkungen die viele vmware Kunden nun bedenken müssen.

Das wichtigste für mich: vSphere Enterprise Edition verschwindet!

Soweit mir bekannt hat vmware zum 1. April 2016 die neuen Preise und somit auch den „Tot“ der vSphere Enterprise Edition umgesetzt.

Vor viel Jahren viel die Advanced Edition auch schon einmal dem Rotstift zum Opfer.

Was bedeutet das nun konkret? Schauen wir mal auf die Funktionen die nun in den verbleibenden Editionen Standard und Enterprise Plus enthalten sind und vergleichen das mit dem was die Enterprise Edition beinhaltet, gibt es doch wichtige, positive wie negative Auswirkungen.

Lizenzen_vSphere6_T1

© by vmware 2016: Funktionsvergleich- vSphere Editionen Teil 1

Lizenzen_vSphere6_T2

© by vmware 2016: Funktionsvergleich- vSphere Editionen Teil 2

Positiv

Alle Standard Kunden erhalten nun endlich auch die Storage APIs for Array Integration [VAAI] und das vmware Multipathing System (vmware Whitepaper). Das ist in Anbetracht der immer besseren Unterstützung durch die Storage Hersteller und der immer wichtigeren Funktionen auch für „kleinere Rechenzentren“ eine schöne Sache. Viele Funktionen können nun an das Storage ausgelagert werden und sollten damit auch schneller und effizienter ablaufen (z.B. Storage vMotion). Multipathing ist eigentlich in jedem produktiven Rechenzentrum ein Muss und daher ebenfalls zu begrüßen.

Negativ

Als persönlich negative empfinde ich den Verlust des „kostengünstigen“ Einsatzes von DRS (Distributed Resource Scheduler). Wenn ich als Kunde diese, wirklich stabile und tolle Funktion, haben will, muß ich auf Enterprise Plus umsteigen, obwohl ich vielleicht gar keinen Bedarf für den Distributed Switch oder Host Profiles habe. DRS dagegen ist in meinen Augen, gerade im Zusammenspiel mit HA, eine äusserst wichtige Funktion! (Siehe dazu HA Beispiel mit stretched Cluster)

Fazit

Meine persönliche Meinung zu diesem Schritt von vmware ist etwas gespalten. Wie schon erwähnt sehe ich die Erweiterung der Standard Edition um die Storage API for Array Integration und Multipathing mit den Anforderungen heutiger RZs und auch kleinerer Kunden als notwendig und sinnvoll. Aus meiner Zeit bei der Distribution hatte ich aber den Eindruck das, vielleicht gerade in Deutschland, viele Kunden auf die Entersprise Edition gesetzt haben und zwar genau aus dem Grunde „Distributed Resource Scheduler“ [DRS]. In allen meinen vSphere ICM Kursen habe ich diese Funktion als „wünschenswert“ im HA Fall vorgestellt, denn HA versucht willkürlich die VMs auf den verbleibenden Hosts zu restarten. Erst DRS sorgt wieder für geordnete Verhältnisse und geg. sogar dafür das Platz für größerer VMs durch Verschieben von anderen VM geschaffen wird. Also eine mehr als sinnvolle Funktion!

Jetzt müssen alle diese vmware Kunden auf Enterprise Plus oder eine der vSOM Editionen wechseln! Das ist mit nicht unerheblichen Kosten verbunden. Mir zeigt es, das vmware immer weniger mit der reinen Virtualisierung a la vSphere und ESXi verdient und daher die bestehenden Kunden „upgraten“ muß. Auf der anderen Seite werden jetzt natürlich auch die Operations Management Editionen [vSOM] immer interessanter.

Hier noch mal der „alte“ Funktionsvergleich:

OldVersions_onlyEditions

© by vmware (aus dem Lizensierungs Whitepaper)

 

Entscheiden Sie selbst was diese Änderung für Sie bedeutet. Meinungen und Feedback würden mich interessieren.

 

 

Advertisements

vMotion 6 – die neuen Möglichkeiten etwas näher betrachtet

vmware hat mit vSphere 6 das alt bekannte vMotion deutlich erweitert. Viele neue Möglichkeiten stehen ab der Standad-Edition zur Verfügung, einige erst mit Enterprise Plus.

In diesem Beitrag möchte ich die neuen Möglichkeiten kurz vorstellen und beschreiben. Ich denke das viele Interesse an diesen Infos haben. Ein „DeepDive“ soll dieser Beitrag aber nicht werden 😉

Alle Infos stammen aus verschiedenen vmware Dokumenten sowie den bekannten Blogs.

Eine der wichtigsten technischen Änderungen vMotion 6 betreffend ist die Einführung eines eigenen TCP-Stacks nur für vMotion! In früheren Versionen wurde min. eine VMKernet-Portgruppe mit dem Flag „Für vMotion Traffic“ versehen. Es wurde aber der gleiche TCP-Stack wir für allen anderen Traffic verwendet. Ab vSphere 6 wird nun min. ein weiterer TCP-Stack nur für vMotion angelegt.

Cross vSwitch – vMotion

Cross vSwitch – vMotion bedeutet, das es nun möglich ist eine VM von einem vSwitch auf einen anderen vSwitch zu verschieben. Das darunter liegende „Netzwerk“ (Layer 2) muss natürlich weiterhin eine ungehinderte Verbindung zum gwünschten physikalichen oder logischen Netzwerk ermöglichen. Im Prinzip könnte man sage das in der ersten Näherung die Prüfung auf das Label (den Namen) des vSwitches toleranter ist. Wir erinnern uns, das vorher die Label der vSwitche auf allen ESXi Hosts übereinstimmen mussten (Casesensitiv!).

Bild 1: Cross vSwitch vMotion

Bild 1: Cross vSwitch vMotion

Nun kann auch auf andere vSwitche migiriert werden. Dieses ist gerade für Cross vCenter und Long Distance Migrationen wichtig.

Erlaubt ist die Migration von einem virtual Standard Switch (vSS) zu einem anderen vSwitch oder auch zu einen virtual Distributed Switch (vDS). Ebenso natürlich vom vDS zum vDS, nicht aber vom vDS zum vSS (Danke an Duncan Epping für die Info).

IP Adressen der VM werden dabei NICHT geändert!

Diese Funktionserweiterung steht ab vSphere 6 Standard zur Verfügung.

Cross vCenter – vMotion

Eine weiter Funktionserweiterung ermöglicht es nun VMs zwischen verschiedenen vCenter Server Umgebungen zu verschieben. Grundlage dafür ist, das die beteiligten vCenter Server zu einer vmware Security Domäne gehören! Hier kommt das neue vCenter Konzept des „Platform Service Controllers“ zum Einsatz. Dieser beinhaltet SSO, Lizenzierung und Zertifikatsmanagement. Der PSC stellt eine Security Domäne bereit an die mehrere vCenter Server angeschlossen sein können (mehr dazu vielleicht ein andermal).

Mit dieser Funktion ist es nun möglich, z.B. eine VM an einen anderen Standort bei gleichzeitiger Änderung des vCenters, Hostes, Storages und Netzwerkes (vSS oder vDS) zu verschieben. Für Unternehmen mit entsprechender Infrastruktur eine tolle Sache. Ebenso für all die, die eine weitere vSphere Umgebung in der „Cloud“ betreiben. Hier kommt dann unter Umständen noch Long Distance – vMotion zu Einsatz.

Bild 2: Cross vCenter Server vMotion

Bild 2: Cross vCenter Server vMotion

Eine prima Sache bei Cross vCenter – vMotion ist die Tatsache, das sowohl Alarme, Events, Ressource Einstellungen, die Task History, HA und DRS Einstellung sowie (bei vDS to vDS) Performance Werte mit migriert werden (in die vCenter DB des Target vCenter Servers).

Die IPs der VM bleiden gleich – hier ist darauf zu achten das, genau wie beim Cross vSwitch – vMotion die Layer 2 Netze passen. Um Konflikte mit später erstellten VMs auf dem Ursprungs vCenter zu vermeiden wird die MAC Adresse in eine Art „Blacklist“ eingetragen, so das diese MAC nicht neu generiert werden darf.

Long Distance – vMotion

Kernerweiterung der Long Distance – vMotion Möglichkeit ist die Erhöhung der RTT (Round Trip Time := Paketumlaufzeit/Latenz) von 10ms auf 150ms. Dadurch können nun auch weitere Strecken überwunden werden (Wikipedia zeigt eine schöne Tabelle mit typischen RTTs für verschieden Verbindungen. So z.B. innerhalb Deutschlands meist < 50ms).

Bild 3: Long Distance vMotion

Bild 3: Long Distance vMotion

Sowohl VMFS als auch NFS werden supported.

Weitere Erweiterungen in vMotion 6

vMotion 6 kann wird nun auch für Layer 3 Verbindungen supported. Wie schon am Anfang beschrieben kann vSphere 6 mit mehreren TCP Stacks aufwarten. Einer davon ist für vMotion Traffic reserviert.

Die Unterstützung von Windows Server Failover Clustering (WSFC) ermöglicht es nun auch den vollen Support für Windows 2012 R2 und MS SQL 2012 Cluster mit RDMs.
Long Distance vMotion unterstütz auch Virtual Volumes, diese sind aber KEINE Voraussetzung.

Fazit

Mit vSphere 6 vMotion hat vmware die Messlatte mal wieder ein ganzes Stück nach oben gelegt. Die Konkurrenz schläft ja nicht 😉 . Sicher sind einige der Funktionen und Möglichkeiten nicht für alle vmware Kunden praxisrelevant, Dinge wie höhere Latenz-Verträglichkeit oder Cross vSwitch vMotion ist aber unter Umständen schon einen Blick wert.

Wer mehr als eine vCenter Server Umgebung betreibt sollte sich über das Konzept seiner vmware Security Domäne Gedanken machen. Diese spielt keine Unbedeutende Rolle – siehe Cross vCenter vMotion.

Für mich würde das bedeuten, das man mit der Migration auf vSphere 6 durchaus auch einmal seine gesamte vmware Landschaft neu bewertet und betrachtet. Gerade in Großen Umgebungen wird sicher das Thema „Software Defined Network“ [SDN] und vielleicht auch die Virtual Volumes interessant.

Damit bin ich mit meinen „Osterurlaub Überlegungen“ am Ende. Viel Spass mit vSphere 6.

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!

Beispiel eines vmware High Availabe Stretched Clusters

Auch wenn dieses Thema schon weit ausgedehnt wurde, z.B. von Duncan Epping und Frank Denneman in Ihrem Deep Dive Buch , möchte ich ein Design Beispiel aus meiner Vergangenheit  hier gerne wiedergeben.

Beim Aufräumen alter Dokumente bin ich auf ein Konzeptpapier gestossen welches Grundlage dieses Artikels ist. Es diente damals dazu eine ältere vmware Produktionsumgebung die neu aufgebaut werden sollte so zu designen, das alle üblichen High Availability (HA) Fälle von der Umgebung möglichst automatisch bzw. mit geringem administrativen Eingriffen verfügbar bleibt. Also die üblichen Ziele: Hohe Verfügbarkeit mit möglichst minimalen Downtimes für alle Unternehmenswichtigen Services.

Ich denke das dieses Beispiel gut aufzeigt wie mit „normalen“, heute verfügbaren Mitteln, ohne Exorbitantem finanziellem Aufwand dieses Anforderung erfüllbar ist.

Ausgangssituation

Im genannten Umfeld war eine alte vmware 3.5 Umgebung sowohl Server- als auch Storage-seitig durch neues Equipment zu ersetzen. Um dem erwarteten Datenzuwachs Rechung zu tragen sollte goßzügig genug geplant werden. Ausserdem stand der Aspekt des möglichst einfachen, zeitlich kurzem und für die Anwender nicht spürbaren Umzugs auf die neue Umgebung im Anforderungs Katalog.

Die vmware 3.5 Umgebung war auf zwei Gebäude verteilt, die über Glasfaserleitungen miteinander verbunden sind (Distanz ca. 50 – 100 m). Somit kam das Konzept für einen sogenannten „Stretched Cluster“ zum Einsatz.

Bei einem Stretched Cluster sprechen wir von einer vmware vSphere Umgebung die sich auf zwei Räume / Gebäude / Brandabschnitte verteilt, aber von einem einzigen vCenter Server verwaltet wird.

 

Komplette Übersicht - vmware vSphere Stretched Cluster

Bild 1: Komplette Übersicht – vmware vSphere Stretched Cluster

Diese Bild zeigt den Architekturplan des gesamten Projektes und nimmt natürlich einige Elemente der Lösung vorweg.

Die Komponenten der Lösung

Wie man am Bild 1 sicher erkennen kann, besteht die Lösung aus folgenden Komponenten (ich nenne Hersteller nur dann wenn es für die Erklärung zwingend notwendig ist, anderfalls sind hier verschiedene Hersteller als Lieferanten einsetzbar):

  1. Auf Seite A und aus Seite B werden jeweils eine gleiche Anzahl gleicher Server als ESXi Hosts aufgesetzt.
  2. Auf beiden Seiten werden gleiche Storage Systeme installiert.
  3. Auf jeder Seite wird eine DataCore SDS mit SanSymphony V installiert

Zu den Details: In beiden Server Räumen der Seite A und Seite B werden praktisch indentische Hardware Umgebungen aufgebaut, beide Seiten sind autark betreibbar! Die Server und Storage Systeme sind so auszulegen das im Worst-Case eine Seite allein die gesamte Last tragen kann.

Verbunden sind hierbei die Storage Systeme via Fibre Channel (in diesem Fall 8GB, es könnte aber auch mit iSCSI gearbeitet werden. Da DataCore in der planten Version kein NFS unterstützte sähe eine NFS basierte Lösung etwas anders aus). Die DataStores werden jeweils via synchronem Spiegel auf die andere Seite gespiegelt und stehen auch dort zur Verfügung.

Bitte denken Sie daran auch das vSphere Management Netz so redundant auszulegen, das später alle Ausfall Scenarien abgedeckt werden (warum heiß der „Single Point of Failure“ nur so ;-))

Das die Storage Verbindungen und natürlich auch das Produktivnetz (im Bild Hausnetz) redundant ausgelegt werden ist sicher selbstverständlich.

Die ganze Lösung wurde als sog. Non-Uniform stretched vSphere Cluster realisiert.

Uniform stretched Cluster

Ein Uniform stretched Cluster bedeutet das alle Hosts und alle Storage Systeme so verbunden sind das alle alles zu jederzeit „sehen“. Das heisst die ESXi Hosts haben permanent Zugriff auf alle Datastores jeder Seite.

Non-Uniform stretched Cluster

Ein Non-Uniform stretched Cluste bedeutet das die Hosts einer Seite auch nur „aktiv“ mit den Datastores der Storage Systeme dieser Seite verbunden sind. Im Fehlerfall muß nun eine, wie auch immer geartete Lösung dafür sorgen das auf die jeweils andere Seite geschwenkt wird. Die Daten werden also „nur“ auf Storage Ebene repliziert (synchron oder asynchron). Hier bieten viele große Storage Hersteller eigene Plugins für „gutes“ Geld an.

Ausfall Scenarien

Betrachten wir nun nacheinander die verschiedenen Ausfall Scenarien und wie sich die Umgebung dann jeweils verhalten soll.

Ausfall eines Hostes auf einer Seite

Fällt ein Host einer Seite des Clusters aus, so greift vmware vSphere HA und startet die gecrashten VMs auf den verbleibenden Hosts dieser Seite neu. Damit das funktioniert sollte via DRS Rules und den dort konfigurierbaren Affiniti Rules über Gruppen eine „Sollte immer auf dieser Hostgruppe laufen“ Regel definiert werden. Diese erkläre ich jetzt hier nicht, vielleicht in einem anderen Artikel irgendwann. Kurzgesagt bedeutet diese Regel, das VMs im Normalfall möglichst auf bestimmten ESXi Hosts einer Gruppe laufen sollen. DRS sorgt dann dafür das dieses so ist. In unserem Fall haben wir zwei Hostgruppe: Hosts der Seite A und Hosts der Seite B. Hintergrund: Wir arbeiten mit einem Non-Uniform Cluster und die VMs auf den Hosts der Seite A sollen auch das Storage der Seite A nutzen um z.B. mögliche Laufzeiten (und Latenzen) zur anderen Seite zu minimieren.

Bild 2: HA-Host einer Seite fällt aus

Bild 2: HA-Host einer Seite fällt aus

Ausfall eines Datastores einer Seite

Falls ein Datastore einer Seite ausfällt (siehe Bild 3) so kommt es darauf an was genau unter „Ausfall“ zu verstehen ist. Fällt „nur“ eine Platte des Storage Systems aus, so haben wir hoffentlich kein direktes Problem für unsere VMs da dort durch RAID usw. der Fehler für den Host und die VMs transparent abgefangen wird. Sollte es dagegen zu einem Totalausfall eines Storage Bereiches dieser Seite kommen, fallen die VMs herunter und vmware HA kann zum Einsatz kommen, allerdings nur dann, wenn jetzt auf die gespiegelten Daten der anderen Seite zugegriffen werden kann!

Dazu muss jetzt, wie vorher (unter Non-Uniform Cluster) beschrieben, jemand die Storage Pfade „umschalten“, sprich die gespigelten Datastores der Seite B nun als aktiv an die Seite A anbinden. Unsere Lösung die hier projektiert wurde basiert auf  DataCore SANsymphony, welches einen transparenten Failover bereitstellt. Dieser schaltet im Normalfall so schnell um, das vmware HA garnicht erst zum Einsatz kommen muss. DataCore sorgt in unserem Fall auch für den Synchronen Spiegel.

Bild 3: HA Datastore einer Seite fällt aus

Bild 3: HA Datastore einer Seite fällt aus

Ausfall einer gesamten Host Cluster Seite

Kommen wir nun zu dem Fall das uns eine gesamte vmware Cluster Seite ausfällt. Hier greift wieder vmware HA, denn wir haben ja in unserer DRS Rule gesagt „sollte“, nicht „darf nur“. HA versucht nun die VMs der Seite A die ja mit den Hosts gestorben sind auf der Seite B neu zu starten. Geht das? Tja in unserem Fall müssen die Synchronen Datastores die von Seite A auf Seite B gespiegelt wurden dort „aktiv“ sein, oder kurz gesagt müsste jemand die Datastores der Seite A auf den Hosts der Seite B „aktiv“ schalten! Somit haben wir zwei Möglichkeiten. Diese können gern im Anschluß diskutiert werden.

Bild 4: Komplette ESXi Cluster Seite fällt aus

Bild 4: Komplette ESXi Cluster Seite fällt aus

Bitte daran denken, daß in diesem Fall auch die vCenter Server VM betroffen sein kann. Das bedeutet allerdings nur, das für die Zeit des wideranstartens durch vmware vSphere HA kein DRS läuft! DRS ist eines der wenigen Funktionen die nur funktionieren wenn der vCenter Server läuft.

Ausfall einer Seite ohne virtuelle Storage Pools

Betrachten wir im Anschluß an den vorhergehenden Failure Fall nun den Ausfall einer ganzen Seite, sowohl Hosts als auch Storage. Was hier passiert ist etwas aufwändiger. In diesem Fall haben wir keine virtuellen Storage Pools, sondern „klassische“ Anbindung. Es läuft so ähnlich wie unter „Ausfall eines Datastores einer Seite“ ab. Irgendjemand (z.B. via Skript) muß die Synchon gespiegelten Datastores der Seite A auf Seite B den Hosts der Seite B „aktiv“ schalten. Nun sehen diese Hosts die VMs und vSphere HA kann mit dem Restart der VM beginnen. Knackpunkt ist hier die Umschaltung der Storage Pfade. Wie gesagt „Irgendjemand“ muss das tun! Nur ist der Irgendjemand dann auch da und sieht das Chaos kommen ;-( ?

 

Bild 5: Ausfall einer kompletten Seite - Hosts und Storage

Bild 5: Ausfall einer kompletten Seite – Hosts und Storage

Ich selbst bin KEIN Freund von solchen „Desaster-Skripten“ denn die wollen gepflegt sein (bei jedem Storage Umbau usw. muss nachgepflegt werden). Storage Pfade sind auch nicht gerade „lesefreundlich“ und entsprechendes KnowHow sollte vorrätig sein.

Ausfall einer Seite mit virtuellen Storage Pools

Aus den genannten Gründen im letzten Abschnitt habe ich damals die Lösung mit sogenannten virtuellen Pools favorisiert. Hierbei sollte in diesem Konzept, DataCore einer der Pioniere der Storage Virtualisierung zum Einsatz kommen. DataCore stellt den angebunden ESXi Hosts virtuelle Datastores zur Verfügung die auf virtuellen Storage Pools beruhen. Diese virtuellen Pools bestehen aus Storage Bereichen beider Seiten und beinhalten unter anderem den Synchronen Spiegel von Seite A auf Seite B. Somit ist für die ESXi Host der komplette Storage Aufbau intransparent. Sie sehen nur den Pool. Fällt uns nun das Storage System einer Seite, oder die gesamte Seite aus, so sorgt DataCore dafür das die ESXi Hosts weiter den Pools so sehen als sei alles in Ordnung! Im Fall des Ausfalls der gesammten Seite muss allerdings vSphere HA auch noch arbeiten. Da dieses aber, bei korrekter Implementierung (siehe z.B. hier) absolut zuverlässig arbeitet, sollte die tatsächliche Downtime selbst in diesem Extrem-Fall relativ kurz sein. Das Schöne dabei ist, das eigentlich niemand „geweckt“ werden muss. Das System arbeitet alleine an der Wiederherstellung.

 

Bild 6: Totalausfall einer Seite mit virtuellen Pools

Bild 6: Totalausfall einer Seite mit virtuellen Pools

Abschussbemerkungen

Auch wenn ich selbst hier DataCore präferiere, kann das gezeigte Scenario auch mit anderen Storage Lösungen ähnlich aufgebaut werden. Ausserdem sollte trotz solch einer Lösung NIE auf ein funktionierendes Backup Konzept mit entsprechender Lösung verzichtet werden (soll es tatsächlich geben 😉 )

Übrigens kann DataCore durch seine „Proxied Volume“ Funktion auch beim Umzug einer alten- auf eine neue Storage Lösung sehr gute Dienste leisten.

Über eine Diskussion dieser Lösung würde ich mich freuen, denn soweit mir bekannt ist wurde diese Konzept aus verschiedenen Gründen nie umgesetzt. Schade oder?

Somit ist es mir gelungen durch ein paar „Nachteinsätze“ doch wieder einen Artikel zu erstellen.

 

Online Project 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.

VMware WebClient PlugIn von Tinitri: Eines der ersten PlugIns für den neuen WebClient! Erste Eindrücke

In diesem Beitrag möchte ich einen ersten Eindruck vom neuen Trinitri PlugIn für den VMware WebClient weitergeben. Die ScreenShots sind mir dankenderweise von Tintri selbst zur Verfügung gestellt worden. Wann dieses PlugIn verfügbar ist kann ich leider nicht sagen. Mit diesem Beitrag möchte ich an den Artikel (Trintri Global Center) anschließen.

Ausblick

Tinitri zeigt sich z.Z. hoch innovativ, besonders was die Weiterentwicklung und Neuentwicklung von Management Tools und deren Integration betrifft. Ich persönlich sehe schon lange einen wachsenden Bedarf an guten und trotzdem einfach zu handhabenden Management Lösungen. Das Tinitri Global Center ist hier sicher ein guter Ansatz.

Die Integration der Tintri Storage Systeme dirket in den vCenter Server bzw. den WebClient als zentrales Management ist da nur naheliegend und mehr als sinnvoll.

Tinitri hat mir hierzu einen ersten Einblick in das zu erwartende PlugIn gewährt und auch einige illustrierende Screenshots zur Verfügung gestellt. Besonderen Dank hier zu an die hilfsbereiten Tinitri Kollegen.

PlugIn -Screenshots

Das PlugIn integriert sich nahtlos in den WebClient von VMware und bietet eine Reihe von Möglichkeiten die nun keinen extra Zugriff auf die Tintri Management Konsole notwendig macht. Das fängt z.B. bei der Anbindung der Tintri Lösung an vSphere und der Bereitstellung von DataStores an:

Bild 1: Add VMware Storage

Bild 1: Add VMware Storage

 

Virtual Machine Infos

Auch der Summary Tab einzelner VMs die auf der Tinitri Box liegen wird mit wichtigen und nützlichen Infos angereichert (ähnlich dem was der vCenter Operations Manager macht):

Bild 2: VM Summary mit Tintri Infos

Bild 2: VM Summary mit Tintri Infos

Auch eine Anzeiger welche VMs denn die Top Konsumenten sind ist sicher oft sehr hilfreich (auch für Optimierungen!)

Bild 4: Top Latency VMs

Bild 3: Top Latency VMs

 

Tinitri Storage Infos

Da die Tinitri Systeme sich ja mit dem vCenter Server verbinden und es dem Administrator möglich ist hier steuernd einzugreifen (z.B. das eine VM mit mehr % auf den SSDs verbleicht usw.) bietet das PlugIn Optimierungsmöglichkeiten direkt an:

Bild 4: Best Practice Übersicht

Bild 4: Best Practice Übersicht

Und im Detail:

Bild 5: Best Practice Detail

Bild 5: Best Practice Detail

DataStore Summy Tab mit Tintri Infos:

Bild 6: Tintri DataStore Summary

Bild 6: Tintri DataStore Summary

SAN Snapshots

Das PlugIn bietet die Möglichkeit VMs mit der Tintri SAN SnapShot abzusichern:

Bild 7: VM SAN SnapShots

Bild 7: VM SAN SnapShots

Und im Detail:

Bild 8: Schedule Snapshots

Bild 8: Schedule Snapshots

 Fazit

Ich hoffe das ein guter erster Eindruck dieses sehr nützlichen PlugIns vermittelt wird. Jeder der eine oder mehrere Tinitri Boxen betreibt sollte sich das PlugIn und gegebenenfalls auch das Global Center näher ansehen!

(Alle Grafiken, sofern nicht anders angegeben © by Tintri)

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!

Das neue Tinitri Global Center – zentrales Management einer oder mehrerer Tintri Appliances

Nachdem ich sehr lange nichts mehr über Tintri geschrieben haben (Letzter Beitrag) sollen endlich mal wieder einige sehr interessante Neuigkeiten dieses Herstellers vorgestellt werden.

Tintri, als einer der innovativen, relativ neuen, Storage Anbieter speziell für den Virtualisierungs-Markt hat schon zur VMWorld 2013 seine neue Management Lösung Tintri Global Center vorgestellt.

Diese stellt mit der Version 1.0 einen ersten Schritt in Richting zentrales Management, erweitertes Management und auch später mehr Mandanten Management (Multi Tenancy) dar.

Global Center - Übersicht

Global Center – Übersicht

Es handelt sich dabei um eine virtuelle Appliance die einfach in bestehende VMware vSphere Umgebungen integiert werden kann (OVF). Diese koppelt sich an den vCenter Server und an die vorhandenen Tintri Boxen. Anschließend werde in der aktuellen Version 1.0 rein informativ eine Menge nützlicher Informationen bereitgestellt.

Der verwendete „Kachellook“ sieht, ohne Wertung ;-), ein wenig wie Windows 8 aus, ist aber durchaus sehr informativ und praktikabel zu nutzen.

Erweiterte Möglichkeiten mit dem Global Center

In dieser Version 1.0 ist das Global Center, wie bereits gesagt, als reiner erweiterter View zu sehen. Dabei werden aber z.B. die Daten der Tintri Boxen nun nicht nur 7 Tage zurück, sondern per default 30 Tage zurück auswertbar. Ein kleiner, aber manchmal entscheidenter Zeitgewinn.

Übersicht VMs - Messwerte aus vCenter Server und Tintri

Übersicht VMs – Messwerte aus vCenter Server und Tintri

Informationen aus dem vCenter Server werden dabei mit Informationen aus den Tintri Boxen zusammen bereitgestellt. Diese kann beim Troubleshooting sehr nützlich sein.

Global Center - verfügbare Metricen für VMs

Global Center – verfügbare Metricen für VMs

Zukunft

In den nächsten Versionen sollen auch Aktionen direkt über das Global Center ausführbar sein. Dieses betreffen z.B. die Mandantenfähigkeit, Snapshot Erstellung usw.

Im Bereich Mandantenfähigkeit soll es dann möglich werden z.B.:

  • Quotas für VMs zu vergeben
  • Bestimmten Usern nur bestimmte VMs bzw. Datastores zugänglich zu machen (Usermanagement)
  • virtuelle DataStores anzulegen die verschiedene Einstellungen beinhalten
  • z.B. min/max IOPS und anderes für VMs bereitzustellen

Aussichten

Auf dem Partner Channel Update letzte Woche wurde zusätzlich ein echter Knaller als Beta präsentiert.

Ein VMware WebClient Plugin, welches all die schönen neuen Funktionen des Global Centers direkt in den WebClient integriert! Leider habe ich noch keine Möglichkeit gehabt das live auszuprobieren, werde die Infos aber gern nachreichen sobald möglich. Das währe eine echte Innovation, da die verfügbaren Plugins der großen Hersteller für den WebClient doch leider noch sehr spärlich sind. Hier besteht die Möglichkeit für Tintri Vorreiter zu sein.

NAKIVO Backup and Restore : Update der virtuellen Appliance auf Version 3.9.1

In diesem Blog zeige ich wie einfach man eine NAKIVO virtuel Appliance (Linux Basis) auf eine neue Version updaten kann.
Für alle „Nicht Linuxer“ habe ich einige Screenshots erstellt, die Schritt für Schritt die Anleitung von NAKIVO „plastisch“ darstellen.

Step 1: Kopieren des „Linux Installers“ auf die Appliance per WinSCP

Als erstes muß man sich von der NAKIVO Webseite (Download-Trial) den „Linux Installer“  downloaden. Leider muß man sich jedes mal neu registrieren. Die Datei die ich verwendet habe heißt „NAKIVO_Backup_&_Replication_v3.9.1.5085_Installer-Linux.sh

Diese nun per WinSCP z.B. in das /tmp Verzeichnis der Appliance kopieren.

WinSCP Upload

WinSCP Upload

Step 2:Installation der neuen Version als Update auf Kommandozeile

Nun an der Appliance als root anmelden (Putty lässt grüßen)

Putty: Login als root

Putty: Login als root

Jetzt in das /tmp Verzeichnis wechseln und mal nachsehen wie unsere Datei heißt.

ls -a NAKIVO*

ls -a NAKIVO*

Anschließend müssen wir den Installer ausführbar machen. Da der Dateiname ein „&“ enthält muß der Dateiname bei allen Kommandos in Hochkomma gesetzt werden!

Ausführbar machen: chmod -x

Ausführbar machen: chmod -x

Im Putty kann man schön per Maus kopieren 🙂 und anschießend durch die „grüne“ Farbe sehen das dieser Installer jetzt ausführbar ist.

Bleibt nur noch das Ausführen des Installers:

Ausführen des Installers

Ausführen des Installers

Bestätigen einiger Fragen mit „Y“:

Bestätigen der Fragen beim Update

Bestätigen der Fragen beim Update

Das wars schon!

Fazit

Nach meinem Dafürhalten auch hier eine denkbar einfache Aktion, die auch von allen Kommandozeilen „Neulingen“ bewerkstelligt werden kann. – Viel Spaß damit

Erfahrungen und Vorgehen beim Update einer vmware vSphere 5.1 Umgebung auf vSphere 5.5

Nach den eher „philosopischen“ Betrachtungen des letzten Artikels, nun wieder Praxis!

Heute möchte ich kurz meine Erfahrunge beim Update unserer vmware vSphere 5.1 Umgebung auf die aktuelle Version vSphere 5.5 weitergeben.

Dieses wurde höchste Zeit, aber wie das Leben so spielt braucht man doch ein wenig Zeit für diese Aktion.

Hierbei möchte ich auch kurz das prinzipielle Vorgehen bei einem vmware Plattformupdate vorstellen (vielen sicher geläufig).

Prinzipielles Vorgehen beim Update vSphere 5.1 auf vSphere 5.5

Das Update einer vmware vSphere Umgebung verläuft immer nach dem gleichen Schema. Dieses hier kurz zur Einführung:

  1. Update des vCenter Servers (auch bei der Appliance!)
    1. Bei allen Komponenten auf einer VM einfach „Simpel Install“ auswählen
    2. Ansonsten:
      1. Update SSO (Achtung Änderungen von 5.1 auf 5.5)
      2. Installation bzw. Update WebClient
      3. Update Inventory Services
      4. Update vCenter Server
  2. Update des vSphere Clients (vielleicht zum letzte Mal)
  3. Update oder Installation 😉 des Update Managers
    1. Erstellen einer neuen HOST Baseline für das Update der ESXi Hosts
    2. Scan der Hosts mit dieser Baseline
    3. Test der Baseline auf einem der vorhandenen Hosts
    4. Remediate der übrigen Hosts wenn DRS vorhanden vollautomatisch

Soviel zum Prinzipiellen Ablauf. Handbuch der Wahl ist folgendes „vSphere Upgrade Guide„.

Die Umgebung

Kurz zur Umgebung die Upgedated wurde:

  • vCenter Server 5.1 U2  als VM mit externer MS SQL DB
    • Alle Komponenten auf dieser VM (SSO, Inventory, WebClient Webserver, vCente Server + vSphere Client)
  • 3 IBM Hosts auf ESXi 5.1 U1 mit IBM OEM ISO installiert

Hinweis: Bitte OEM Versionen NIE mit vmware Native ISO updaten! Das geht auf grund unterschiedlicher bzw. fehlender Treiber oft schief!

Mein Vorgehen und meine Erfahrungen

Mein Herangehen an die Migration bzw. das Update war einfach nach Lehrbuch (siehe oben). Dabei habe ich als erstes einen Snapshot des vCenter Servers Windows (2008 R2) erstellt.

Anschließend habe ich erst mal den neuen vSphere 5.5 Client auf meinem Arbeitsplatzrechner installiert bzw. Upgedated.

Nun mittels vSphere Client direkt mit dem Host verbunden auf welchem die vCenter Server VM läuft 😉 (zur Sicherheit)
ISO des neuen vCenter Servers mit der VM verbunden.

Anschließend per RDP eine „normale“ Remote Session auf den vCenter Server.

So nun ging es los.

Setup Wrapper vom ISO gestartet und Simple Install ausgewählt.

ISO Setup Wrapper

ISO Setup Wrapper

Jetzt werden nacheinander die Komponenten SSO, Web Client, Inventory Service und zum Abschluß vCenter Server upgedated!
Dieses verlief mehr als „gepflegt“ und ohne Probleme.

ACHTUNG: Der neue SSO Administrator heißt nun „administrator@vsphere.local“ und nicht mehr „admin@local-Domain„. Hier wird eine neues und vor allem komplexes Passwort erwartet!

Das SSO Update dauerte ca. 30 min da hier die alte SSO 5.1 DB ausgelesen werden muß und anschließend die neue Struktur erstellt wird. Unser AD als Authentifizierungsquelle wurde problemlos übernommen, doch gab es hier ein paar Problemchen im Nachgang (dazu später mehr). Diese waren aber unserer SSO „early Adapter Installation“ zuzuschreiben und sollten normalerweise nicht auftreten.

Anschließend dated der Wrapper den Web Server für den Web Client up. Dieses erfolgte relativ schnell und fehlerlos.

Nun kommt der Invertory Service an die Reihe und zum Schluß der vCenter Server.

Nach einem Windows obligatorischen Reboot sollte die Anmeldung via WebClient bzw. vSphere Client problemlos möglich sein. Zum Test erst mal den „administrator@vsphere.local“ verwenden und dann einen AD User testen. Dieser klappte erst gar nicht, lag aber, wie gesagt an einem etwas unglücklichen Alias aus der „Frühzeit des SSO 5.0“. Nachdem das behoben war (als administrator@vsphere.local) gab es keine weiteren Schwierigkeiten weiterzuarbeiten.

Jetzt wurde es Zeit den Update Manager ebenfalls auf die Version 5.5 zu bringen. Ging auch Problemlos von der Hand.

Nachdem der Update Manager 5.5 lief kann man im vSphere 5.5 Client das entsprechende PlugIn installieren und eine Baseline für die Migration auf ESXi 5.5 anlegen.

Baseline für ESXi Update erstellen

Ich möchte hier nicht den Update Manager erklären, sondern nur kurz angeben wie die Baseline schnell erstellt werden kann. Dazu einfach im Update Manager in der Administrator Ansicht auf „ESXi-Images“ gehen und ein neues ISO-Image importieren. Anschließend fragt der Wizzard automatisch nach einer neu zu erstellenden Baseline (Type Fixed)

Update Baseline

Update Baseline

In unserem Fall ein IBM ISO Image.

Update der ESXi Hosts

Grundsätzlich sollte man für alle upzudatenden ESXi 5.1 Host noch einmal die „Critical Host Update“ Baseline laufen lassen und die Hosts auf den letzten Patchlevel der Version 5.1 bringen. Nach meiner Erfahrung erspart das eine Menge Ungemach bei Update auf die neue Version!

Nachdem die ESXi Hosts also alle auf dem „letzten Stand“ ESXi 5.1 waren wurde die neue Update Baseline an den vSphere Cluster attached und ein Scan durchgeführt.

Erwartungsgemäss sind alle Hosts „Rot“ und „Non Complient“ (so muß es sein, ein Ausrufezeichen und Nicht kompatibel ist schlecht – dann noch mal auf kritische Host-Patche überprüfen). Jetzt versuche ich immer erst mal nur einen einzelnen Host via Update Manager zu migrieren. Klappt das und der Host läuft zufriedenstellend können alle anderen in einem DRS Cluster vollautomatisch mit der Baseline migriert werden.

So habe ich das auch hier gemacht. Erst einen getestet. Dann die beiden anderen „Automatisiert“ migriert. Ging alles in allem in ca. 4,5 Stunden problemlos über die Bühne. Davon ca. 2,5 Stunden den ersten Host migrieren und test, dann in 2 weiteren Stunden automatisch mit Hilfe von DRS die beiden weiteren Hosts des Clusters migriert.

Fazit

Update erfolgreich! vmware vSphere 5.1  ohne besondere Vorkommnisse auf vSphere 5.5 migriert. Alles in allem hat mich die Aktion ca. 1 1/2 Tage gekostet, wobei ich natürlich auch meine anderen Arbeiten machen durfte 🙂