Mit ‘vmware’ getaggte Beiträge

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.

Advertisements

vmware vSphere 6 – Neuigkeiten – Kurze Zusammenfassung

Veröffentlicht: 5. Februar 2015 in Virtualisierung
Schlagwörter:

Eine kurze Zusammenfassung der Neuigkeiten in vmware vSphere 6

Am 2. Februar 2015 (EMEA 3. Feb. 2015) hat Pat Gelsinger die Neue vSphere Version 6 angekündigt. Leider war der EMEA Event, trotz großer Ankündigung, nur ein Recording der Session vom Vortrag. vSphere 6 hat ja eine ganze Zeit auf sich warten lassen. Laut Pat und Ben Fathi wegen der vielen neue Features (über 640) und der langen QA Phase inkl. Public Beta.

Alles läuft unter dem Motto „ON Cloud“

Die Neuerungen würde ich in folgende Bereiche zusammenfassen:

  1. Plattform: die üblichen vSphere Enhancements (mehr von allem..)
  2. Storage: vSAN6 und Virtual Volumes
  3. VM Verfügbarkeit: vMotion und Foult Tolerance Enhancements
  4. VM Bereitstellung: Instant Cloning
  5. OpenStack Unterstützung

Alle Neuerungen können hier im Original nachgelesen werden.(Whats New vSphere 6)

Nun zu den Neuerungen im Einzelnen.

vSphere 6 Enhancements

Wie schon eingangs gesagt: „Von allem mehr“

Abbildung 1: vSphere 6 Enhancements ©by vmware

Abbildung 1: vSphere 6 Enhancements ©by vmware

Vor allem auf den vRAM per VM Wert wurde im Zusammenhang mit SAP HANA (einer „in RAM DB“) hingewiesen. Ich persönlich finde die Erhöhung der Anzahl der Hosts im Cluster interessant. Vor allem in Bezug auf die HA Konfiguration ist das noch genauer zu betrachten!

vSAN6 und Virtual Volumes

Die neue Version von vSAN ist nun auch laut vmware „Enterprise ready“. Die Anzahl der vSAN -Hosts wurde auf 64 erhöht! Dieses führt auch zu höheren Performance Werten (bis zu 90K IOPS bei „all Flash“). Wobei jetzt auch eine „all Flash“ Konfiguration erlaubt ist (vorher min. 1 SSD und 1 magentic Disc). Bis zu 32 Snapshots per VM (wer macht so etwas?). Sowie 200 VMs pro Host usw.

Interessant finde ich die Möglichkeit Rack Gruppen zu bilden! Damit hat man die Möglichkeit, ähnlich wie bei DRS die Affinity Rules, zu definieren das einen wichtige VM nie nur auf den vSAN Hosts in einem Rack verfügbar sein darf. Das ist in größeren Rechenzentren und mit Cluster aus bis zu 64 Hosts sicher eine sinnvolle Erweiterung.

vMotion und Foult Tolerance Enhancements

Im Bereich vMotion und Foult Tolerance [FT] geht es richtig rund. Hier ist sicher viel Entwicklerschweiss geflossen.

vMotion funktioniert nun auch über vCenter Grenzen hinweg. Das bedeutet, das man z.B. eine laufende VM vom heimischen Rechenzentrum in die Cloud – oder zurück transferieren könnte. Somit haben wir nicht nur ein „Cross vCenter“, sonder auch ein „Cross Switch“ vMotion. Damit das lange versprochene „Long Distance vMotion„.

FT wurde ebenfalls um eine lang erwartete und auf den verschiedenen VMWorld’s seit langem als Tech. Preview vorgestellte Unterstützung von SMP bzw. Mehr-vCPU VMs erweitert. Nun kann eine VM mit bis zu 4 vCPUs FT geschaltet werden. Die genauen Requirements sind sicher in jeder Produktivumgebung genau zu betrachten.

Instant Cloning

Unter dem Begriff „Instant Cloning“ ist eine schnelle Bereitstellung von neuen VMs gemeint, bei der die Clones mit dem Memory der Master VM arbeiten bis dieses auseinander läuft. Erst dann werden eigene Ressourcen belegt. Mittels Instant Cloning sollen 64 VM in 6 Sekunden bereitgestellt werden können. Ich denke das dieses z.T. vmware’s Antwort auf Docker Container ist.

OpenStack Unterstützung

Als Abschluß sei noch die Unterstützung von OpenStack nativ im WebClient genannt. Durch den Aufkauf von Nicira, einem der Gründer der Open Stack bzw. Open vSwitch Initiative kann sich vmware als langjähriger Unterstützer von OpenStack positionieren. vmware ist auch Mitglied von OpenStack. Somit können alle die, die OpenStack einsetzten wollen oder müssen getrost bei vmware als Plattform bleiben 😉

 Fazit

Es gibt natürlich noch viele neue Funktionen, die ich aber hier nicht alle aufzählen möchte. Dazu gibt es vielleicht zu einem späteren Zeitpunmkt noch Raum.

Wie man sieht hat vmware sehr viel getan um weiter die Nr. 1 im Bereich Virtualisierung zu bleiben. Die Frage die ich mir trotzdem stelle ist die „Wer braucht alle diese – meist Enterprise Plus – Features“? Für viele RZ Betreiber reichen auch weniger Funktionen, gerade im Mittelstand. Dort holt vor allem Microsoft auf. Das führt auch oft zu den sogenannten Hybriden Plattformen mit mehr als einem Hersteller. Auf der einen Seite Microsoft und vmware, auf der anderen Citrix und vmware. Um alles zusammen noch besser nutzen zu können ist ein Blick auf „unsere“ ASG Dynamic Hybrid Workspace Lösung durchaus gewünscht 🙂

vmware vSphere 5.1-Webclient-Suchfunktion

Veröffentlicht: 15. November 2012 in Virtualisierung, vmware, vSphere 5.1 News
Schlagwörter:,

Der neue Webclient (2)

vmware hat viele neue Details im neuen Webclient untergebracht, die es sicher noch zu finden gilt. Einige möchte ich in loser Folge hier vorstellen. Siehe auch den Artikel zu „Work in Progress + Tags„.

Hier möchte ich nun auf die mächtige Suchfunktion des Webclients eingehen.

Objektsuche im Webclient

Im neuen Webclient ist es möglich Objekte zu suchen. Das gab es auch schon im vSphere Client. Diese Suchabfragen kann man nun aber auch sehr komfotabel zu komplexen Suchabfragen verknüpfen.

Suchfunktion

Suche nach Objekt mit Eigenschaften.

Oder eben die komplexe Suche mit verknüften Suchdetails (siehe Screenshot).

Das beste dabei ist aber, das man diese Suchabfragen speichern kann! So kann man die wichtigsten Suchabfragen einmal erstellen und immer wieder aufrufen.

Dieses sich sicher nur Details, die das Leben des vmware Admins aber entscheident vereinfachen können.

Mal sehen was es noch so alles neues gibt. Hoffe das ich demnächst mal wieder etwas mehr Zeit habe 😉

vmware bietet dem Administrator in jeder Edition einige Einstellmöglichkeiten um Virtuelle Maschinen [VMs] Performence-technisch zu steuern und zu priorisieren.

Dieses sind vor allem die Möglichkeit Memory (RAM) und CPU (MHz) einer VM zu limitieren bzw. zu reservieren. Dieses sind die sogenannten „Limits“ und „Reservations“ – siehe Screenshot.

Resourcen Einstellung einer VM

Eine weitere Möglichkeit besteht darin VMs unterschiedlich zu priorisieren. Dieses geschied über die sogenannten „Shares“. Was sind nun Shares und was kann man damit machen?

Als erstes sei gesagt, das all diese Einstellmöglichkeiten nur dann Verwendung finden sollten wenn es wirklich benötigt wir und einiges nur im Falle eines Resourcen Engpasses zum Tragen kommt. Haben Sie in Ihrer Umgebung kein „Overcommitment“, also mehr Resourcen verteilt als Sie physikalisch haben, brauchen Sie sich z.B. über die Einstellung von Shares für RAM und CPU keine Gedanken machen.
Halten Sie Ihre Umgebung so einfach wie möglich!

Wenn Sie allerdings VMs priorisieren müssen (zu wenig physikalischer RAM oder CPU lastige VMs) dann bieten sich die Share Einstellungen der einzelnen VM bzw. eines Resource-Pools (in einem späteren Artikel) dazu an.

vmware bietet hier die Möglichkeit von drei vordefinierten Einstellunge oder alternativ einem frei einstellbaren Wert. Vorgegeben sind dabei:

  • Low      := 500 Shares
  • Normal := 1000 Shares
  • High     := 2000 Shares

Dieses bedeutet das eine VM welche auf High in Bezug auf den RAM Bedarf gesetzt wird vom VMKernel eben bevorzugt mit physikalischen RAM versorgt wird, oder umgedreht – als letzte z.B. zum baloonen oder swappen genötigt wird.

Aber was ist nun ein Share?  Erst einmal gar nichts! Denn Shares haben mehrere Fakten die zu beachten sind.

  1. Shares sind KEINE Prozentualen Anteile an einer Resource!
  2. Shares haben keine direkte Wertigkeit!
    Soll heissen: Ob Sie allen VMs Einstellung im Bereich 10 / 20 / 40 Shares oder 5000 / 10.000 / 20.000 Shares geben spielt keine Rolle.
  3. Shares sind immer nur im Zusammenhang mit den Einstellungen der anderen VMs eines Hostes bzw. Clusters zu betrachten!
    Einstellungen einer einzelnen VM ohne Kenntnis der anderen VMs sind ohne Aussage!

Eine kurze Grafik soll dieses Erläutern:

Scenaren mit unterschiedlichen Shares

Hier sehen wir in Status A erst mal alle VMs eines Hostes (oder Clusters) gleich priorisiert. Alle stehen auf Normal und haben somit prinzipiell Anspruch auf den gleichen Anteil (z.B. der CPUs)

Wir nun eine VM auf 3000 Shares gesetzt Status B verschiebt sich die Priorisierung zugunsten dieser VM. Nachfolgende Grafik soll die effektiven „Ansprüche“ verdeutlichen.

Status C zeigt die Veränderung durch das Ausschalten einer VM und Status D dann das hinzufügen einer „very High“ Shared VM. Was tatsächlich für die VMs bleibt zeigt die Grafik unten

Share Verteilung als KuchensegmentIn dieser Grafik wird die Verteilung anhand der Verschiedenen Stati und deren Verteilung in „Kuchenstücke“ gezeigt.

In meinen Kursen versuche ich immer den Spruch zu prägen „Einen Kuchen kann man nur einmal teilen! Je mehr Mitesser, desto kleiner die Stücke„. Wenn nun ein Mitesser höher priorisiert ist erhält Er eben einen doppelten oder n-fachen Anteil der anderen. Trotzdem ist der Kuchen nur einmal zu teilen!

Somit kann man Shares nicht immer leicht fassen, da man die Gesamtsituation betrachten muß und nur dann Rückschlüsse auf das VMKernel Verhalten im Fall des Resourcen Engpasses sehen.

Im Gegensatz zu Reservations sind Shares somit eher eine „weiche“ Einstellmöglichkeit ohne feste Werte. Bedeutet, ich muß, um z.B. eine tatsächliche Höherpriorisierung eine VM zu erreichen, diese mit einem „signifikant“ höheren Share – Wert versehen. Also alle VMs auf 1000 Shares und eine auf 1010 Shares macht sehr wenig Sinn. Vor allem ändert sich die Auswirkung mit der Anzahl der VMs auf dem Host bzw. Cluster, so das hier möglicherweise später „nachgebessert“ werden muß.

Um dieses in großen Umgebungen bzw. für ganze Gruppen von VMs nun nicht einzeln konfigurieren zu müssen existieren die sogenannten Resource-Pools. Diese möchte ich demnächst in einem weiteren Artikel behandeln.