vSphere 5.5 - Whats new.

[MarcelMertens]

http://www.vmware.com/files/pdf/vsphere ... ts-New.pdf

64TB VMDKs

[irix]

So richtig haut mich das alles nicht vom Hocker und das mit dem Rewrite des SSO verschlaegt mir glatt die Sprache. Haetten sie vorher mal 5Min drueber nachgedacht aber nein. *seufz*

Gruss
Joerg

[pirx]

Es sind wenige "must haves" dabei. Und was von den neuen Dingen am Ende wirklich funktioniert ist eine andere Frage. Ich warte ja nur darauf das der Flash Webclient in die Tonne getreten und mit HTML5 neu entwickelt wird.

[Dayworker]

@Marcel
Ich will ja nicht klugscheissen, aber im verlinkten PDF (Seite 13) wird lediglich "Support for 62TB VMDK" beworben.


Auf den ersten Blick viel interessanter finde ich die vGPU-Geschichte, da inzwischen kaum noch ein OS ohne grafischen Firlefanz auskommen mag und auch zertifizierte, grafische Anwendungen davon profitieren dürften.

[vl13]

Das hoert sich doch mal gut an:

vCenter Server Appliance
...
With the release of vSphere 5.5, vCenter Server
Appliance now uses a reengineered, embedded vPostgres database that can now support as many as 500 vSphere hosts or 5,000 virtual machines.

Habe nie verstanden wo das limit herkommt, einerseits vertreibt VMware eine (eigene?) PgSQL version, auf der anderen reizen Sie nicht mal den standart PgSQL aus.

Fehlt nur noch der Update Server als Appliance ;)

[pirx]

Das hoert sich doch mal gut an:

vCenter Server Appliance
...
With the release of vSphere 5.5, vCenter Server
Appliance now uses a reengineered, embedded vPostgres database that can now support as many as 500 vSphere hosts or 5,000 virtual machines.

Habe nie verstanden wo das limit herkommt, einerseits vertreibt VMware eine (eigene?) PgSQL version, auf der anderen reizen Sie nicht mal den standart PgSQL aus.

Fehlt nur noch der Update Server als Appliance

An zwei Standorten im Ausland würde ich ja glatt die Appliance einsetzten. Damit ist aber kein linked mode zwischen unseren3 vCentern möglich und der Webclient in seiner jetzigen Form ist bei uns auf Eis gelegt.

[MarcelMertens]

@Marcel
Ich will ja nicht klugscheissen, aber im verlinkten PDF (Seite 13) wird lediglich "Support for 62TB VMDK" beworben.


Auf den ersten Blick viel interessanter finde ich die vGPU-Geschichte, da inzwischen kaum noch ein OS ohne grafischen Firlefanz auskommen mag und auch zertifizierte, grafische Anwendungen davon profitieren dürften.

Dann hab ichs falsch getippt..

[UrsDerBär]

Limit für vCenter App war wohl um keine grossen Umgebungen mit einem neuen Produkt supporten zu müssen. Erstmal Erfahrungen oder so sammeln.

vGPU: Kling interessant, vor allem mit View. Selbst neue Browser langern ja immer mehr auf die GPU aus.

ReadCache: So ganz gepeilt habe ich das ehrlich gesagt nicht. Ist das nun nur ein Cache für die Swap-Files der Festplatte, mit dem Unterschied, dass das Swapfile optisch als 'bei' der Festplatte wahrgenommen wird und evtl. sogar zusätzlich so ist oder werden auch viel geforderte IO's zwischengepuffert?

[irix]

...
ReadCache: So ganz gepeilt habe ich das ehrlich gesagt nicht. Ist das nun nur ein Cache für die Swap-Files der Festplatte, mit dem Unterschied, dass das Swapfile optisch als 'bei' der Festplatte wahrgenommen wird und evtl. sogar zusätzlich so ist oder werden auch viel geforderte IO's zwischengepuffert?

Beides:
1. Ja die *.swap Files der VMs koennen dort abgelegt werden. Das gabs ja vorher auch schon
2. Ja man kann jeder VM ein paar GB, max. die Gesamtgroesse der vDISKs, aus dem Bereich der SSD Cache zuweisen. Das ganze ist dann transparent und fuer Writes ist immer Write-Trough eingestellt und nur die Reads werden gecached.

Ein vMotion geht dann nur noch wenn der Zielhost auch entsprechenden Platz in seinem SSD Cache hat um die neue VM aufzunehmen.

Gruss
Joerg

[sirrossi]

Und wann bekommen wir bei FT mal 4 vCPUs

[UrsDerBär]

@irix: Readcache: Ok, also richtig interpretiert. Hört sich für mich nicht verkehrt an sofern die Logik dahinter passt (zbsp. nach ein paar Reboots nicht einfach nur Windows Files drinn sind) oder man später sogar beeinflussen kann, was da rein soll --> Sowas wie ne Ordner-Auswahl des Gastsystems wäre cool oder den VmWare-Tools sagen welche oder ...

FT: Das frage ich mich auch... Schade kann das nach wie vor nur Xen/Marathon richtig gut und einfach (allgemein deren Ausfallszenarien für Storage, Network, Host).

[vl13]

Hier ein paar weitere Informationen zu VMware vSphere 5.5 vFlash Read Cache
Evtl. auch interessant fuer die User der freien Version, nach Vladan SEGET ist das RAM Limit von 32GB nicht mehr vorhanden.

[blue_focus]

Also mich haut das Featureset jetzt auch nicht grade um. Ich hätte ja ganz schwer auf nen brauchbaren Web-Client gehofft. Dieser Flashmist der noch dazu bei komplexeren Operationen ständig abstürzt und ohnehin sehr träge ist kann doch wohl nicht deren Ernst sein

@sirrossi: Da bin ich ganz bei dir. Könnten wir FT endlich mal auch für "Highperformance" Maschinen nutzen könnten wir endlich unsere mistigen Windows-Cluster ablösen.
Naja, wir schauen uns im Frühjahr eh CERTO an. Mal schauen, ob das hält was es verspricht.

[UrsDerBär]

Naja, ist ja 'nur' eine halbe Version und dafür gibts doch schon einiges an Detailverbesserung oder auch ausbügeln von früheren Fehlern/falschem Design.

Was mich etwas stört, jetzt sind schon die Festplatten zu zertifizieren. :-/
Hardware Requirements? Yes, the SSDs has to be on the HCL.

Bin ja mal gespannt wie viel mehr Arbeit unser Ulli bekommen wird wenn sie die Snapshot-Geschichten zusammen mit Replication dermassen hochpushen.

Auch interessant wird sein welche Features in welchen Versionen zu Verfügung stehen.

[bla!zilla]

Ich denke, der Aufwand FT mit mehr als einer vCPU hinzubekommen steht in keinem Verhältnis zum Nutzen. FT und Cluster richten sich an zwei unterschiedliche Einsatzbereiche.

Ansonsten bin ich ganz zufrieden mit vSphere 5.5. Vor allem das SSO Redesign finde ich gut. VSAN klingt auch spannend und wird die VSA beerben. Mal sehen was PernixData angesichts von vFlash macht. VSAN ist ein wenig in Richtung Nutanix gemünzt. Klar, PernixData und Nutanix können das (noch) besser, aber der Weg zeichnet sich schon ab.

Aber einiges kommt eh erst mit U1. VSAN geht ja auch erst mal in die Public Beta.

Bezüglich Flash, Replication und Ulli: Ulli hat vor allem so viel zu tun, weil Kunden immer wieder mit Unwissen Dinge betreibe, keine passende Datensicherungsstrategie haben und/ oder keine qualifizierte HW einsetzen. Ich denke die Fälle, wo der Kunde mit Knowhow, passender Datensicherungsstrategie uns vollends supporteter Hard- und Software einem Datenverlust erleiden und auf professionelle Datenrettung angewiesen sind, bewegen sich im einstelligen Prozentbereich - wenn überhaupt. Ich war in all den Jahren, seit ESX 2.x, bei keinem Kunden auf Datenrettung angewiesen.

[MarcelMertens]

Was mich stört ist das 90% der Features für Ent+ Kunden sind.
Gerade DRS hätte für mich in Std. rutschen können

[UrsDerBär]

FT macht halt vor allem für Systeme Sinn wo die Performance nicht sooo der Knackpunkt ist. Diese Domäne beherrschen Cluster deutlich besser, da eben auch Leistung verteilt werden kann. Auch ist nicht jede Anwendung ja dafür geeignet und die Komplexität ziemlich hoch.

FT würde prinzipiell für viele kleinere Umgebungen die nötige Umgebungskomplexität für den Betrieb einer hochverfügbaren Umgebung deutlichst herunterschrauben. Aber denen will man ja eigentlich eh die Umgebung wegnehmen und sie in die öffentliche Wolke verbannen.

Wenn das Marathon als verhältnissmässig kleine Firma gut und anwenderfreundlich auf die Reihe kriegt, vermute ich mal, dass VmWare irgendwo einen tieferliegenden Designfehler in diesem Bereich hat, sonst hätten Sie das schon längst gemacht. Oder aber die CPU-Hersteller sind da selber drann und bieten in naher Zukunft sowas wie nen Direktlink.


Auf alle Fälle schön, wenn VmWare weiterhin Innovativ bleibt/bleiben muss dank der Konkurenz durch MS.

[bla!zilla]

Was mich stört ist das 90% der Features für Ent+ Kunden sind.
Gerade DRS hätte für mich in Std. rutschen können

Das wird so schnell nicht passieren... Storage vMotion ist auch nur in die Standard gerutscht, weil es Bestandteil von "Unified vMotion" ist. Ob ich nun eine VM zwischen zwei Maschinen ohne shared Storage oder zwischen zwei Datastores umziehe ist egal - das Verfahren ist das gleiche.

FT würde prinzipiell für viele kleinere Umgebungen die nötige Umgebungskomplexität für den Betrieb einer hochverfügbaren Umgebung deutlichst herunterschrauben. Aber denen will man ja eigentlich eh die Umgebung wegnehmen und sie in die öffentliche Wolke verbannen.

Damit vermittelst du deinen Kunden aber den Eindruck, dass komplexe Dinge, wie der unterbrechungsfreie Betrieb, ganz einfach zu lösen sind. Dabei ist das Merkmal, wie ich die Maschine und Anwendung unterbrechungsfrei betreibe, nur die halbe Miete. FT suggertiert Kunden günstige Verfügbarkeit. Einem Cluster haftet immer noch der Ruf an komplex zu sein. FT ist ein Klick. Der Vergleich hinkt und es vermittelt Kunden ein falsches Gefühl. Der unterbrechungsfreie Betrieb ist immer komplex, egal mit welchem technischen Unterbau.

Wenn das Marathon als verhältnissmässig kleine Firma gut und anwenderfreundlich auf die Reihe kriegt, vermute ich mal, dass VmWare irgendwo einen tieferliegenden Designfehler in diesem Bereich hat, sonst hätten Sie das schon längst gemacht.

VMware einen Designfehler zu unterstellen ist schon gewagt. Sicherlich lösen beide das auf unterschiedlichen Wegen. Marathon macht es aus der VM heraus, VMware setzt darunter an. Aufgrund der unterschiedlichen Technologie ergeben sich auch unterschiedliche Limitationen/ Features.

[UrsDerBär]

Damit vermittelst du deinen Kunden aber den Eindruck, dass komplexe Dinge, wie der unterbrechungsfreie Betrieb, ganz einfach zu lösen sind. Dabei ist das Merkmal, wie ich die Maschine und Anwendung unterbrechungsfrei betreibe, nur die halbe Miete. FT suggertiert Kunden günstige Verfügbarkeit. Einem Cluster haftet immer noch der Ruf an komplex zu sein. FT ist ein Klick. Der Vergleich hinkt und es vermittelt Kunden ein falsches Gefühl. Der unterbrechungsfreie Betrieb ist immer komplex, egal mit welchem technischen Unterbau.

IT ist so oder so komplex. Virtualisierung legt noch ordentlich was drauf.
Im Grunde verschiebt es ja nur eine Anwendungskomplexität auf die Untere Schicht. Die Routinen müssen also einmal durch VmWare erstellt werden und nicht durch jeden Anwendungsprogrammierer - was eh nicht gemacht wird. Funktionieren diese, funktioniert auch das obere. Somit ist es nicht nur suggeriert sondern Tatsache. Es ist also ein gutes Mittel um eine wiederkehrende Anwendungskomplexität auf die Schicht darunter zu verlagern.

Dass man eben nur auf zertifizierte Hardware zurückgreifen darf, liegt auf der Hand oder? Das tut man ja auch ohne FT. Dass man USV, Storage etc. ebenfalls darauf ausrichten muss, muss ebenso klar sein.

Cluster sind zwar schon deutlich einfacher zu handhaben aber deutlich oversized und immer noch komplex. Gilt für Unterhalt, Updates und auch für ein Recovery. Mit einer VM im Lockstep kann man sich die ganze zusätzliche Anwendungs- und Unterhaltungskomplexität sparen sofern man kein Loadbalancing braucht.

VMware einen Designfehler zu unterstellen ist schon gewagt. Sicherlich lösen beide das auf unterschiedlichen Wegen. Marathon macht es aus der VM heraus, VMware setzt darunter an. Aufgrund der unterschiedlichen Technologie ergeben sich auch unterschiedliche Limitationen/ Features.

Unterstellung ist auch etwas hart ausgedrückt. Das will ich ja damit sagen, sie haben irgendwo Limitierungen. Limitierung klingt einfach schöner als Designfehler für ein bestimmtes Szenario (muss ja auch gar nicht für alles sein).

[MarcelMertens]

Unterstellung ist auch etwas hart ausgedrückt. Das will ich ja damit sagen, sie haben irgendwo Limitierungen. Limitierung klingt einfach schöner als Designfehler für ein bestimmtes Szenario (muss ja auch gar nicht für alles sein).

VMware nutzt für FT vMotion. Es ist quasi ein vMotion Vorgang der mit dem sterben der Primär VM Endet.

[blue_focus]

Ich glaube ja diese Limitierung hängt mit der Netzwerkgeschwindigkeit zusammen.
Meine mich zu erinnern, dass das Synchronhalten zwischen primär und schatten-VM derart netzwerklastig ist und sich mit steigender vCore Zahl multipliziert - selbst 10Gbit Netze auf Grund von Latenzen hier an ihre Grenzen stoßen. Zumindest der bekannte FT-Mechanismus kann hier aus Designgründen derzeit einfach nicht mehr.

[Mr.Schrotti]

Increased platform support – With vSphere 5.5, full client support for Mac OS X is now available in the vSphere Web Client.

Na endlich .... als nächsten schritt weg mit dem Flash mist !!!

Aber VMware war IMHO noch nie in der Lage ordentliche WebGUIs zu bauen ... hab jedenfalls noch keine brauchbare gesehen von denen. Das fing mit VMware Server 2 ja schon an gruselig zu werden....

[irix]

..
Aber VMware war IMHO noch nie in der Lage ordentliche WebGUIs zu bauen ... hab jedenfalls noch keine brauchbare gesehen von denen. Das fing mit VMware Server 2 ja schon an gruselig zu werden....

Kann ich so nicht bestaetigen. Ich finde vCOPs bemerkenswert. Aber ich weis was du meinst und ich schliesse mich an das die Entscheidung dort auf Flash zusetzen ein Griff ins Klo war.

Gruss
Joerg

[PatrickW]

Und hier das Ganze noch mal kompakt zusammengefasst.

http://blogs.vmware.com/wp-content/uploads/2013/09/vSphere-5.5-Quick-Reference-0.4.pdf

[BastiHN]

ab wann ist version 5.5 eigentlich verfügbar?