Vor- / Nachteile für Virtualisierung?

[Weingeist 159]

@GTRDRIVER: Das verhalten konnte ich auch schon feststellen. Fehlerverursacher war bei mir immer das Storage. Im Speziellen SSD's im RAID-Betrieb wo es normalerweise rennt ohne Ende aber zwischendurch unerklärliche Hänger gibt. Da hatten dann ne handvoll IO's plötzlich eine enorme Latenz und haben die VM's in Globo komplett ausgebremst. Bis hin zu kurzen 1-2sekunden Hängern innerhalb den VM's.

Daher auch wichtig - vor allem im RAID-Betrieb -, auf eine sehr stabile, gleichbleibende Latenz der SSD's zu achten. Sonst ist immer irgend eine Disc innerhalb des RAIDs mit langer Latenz dabei und bremst alles spürbar aus. --> So als Fehlersuch-Ansatz

 

Ansonsten zum Vergleich, ein wenig pauschalisiert

 

Vorteile:

- Stromkosten

- Hardwarekosten (sehr beschränkt! Sieht unten, Stichwort Strom)

- Verwaltbarkeit

- Trennbarkeit von Rollen auch in kleinen Umgebungen

- Einfachere Testungen/Rollbacks etc.

- Hardwaretausch, allgemein Upgrades

 

Nachteile:

Nachteile sehe ich - bereits genannte Spezialfälle mal aussen vor - nur in der Stromversorgung und was alles damit zusammenhängt.

 

Vor allem die saubere, automatische Abschaltung der einzelnen VM's ist nicht immer so trivial wie mit physischen PC's. Auch die Endabschaltung des Hosts kann mitunter problematisch sein (unter VmWare imho anspruchsvoller wie unter HyperV).

Einen typischen SBS hat es normalerweise nicht gross gejuckt wenn man der Strom weg war. Aufm Exchange nen Rollback oder nen Wiederherstellungspunkt vom Vorabend und gut war. Falls überhaupt notwendig.

Bei VM's sieht das schon etwas anders aus. Da kann es einem so ziemlich alles zerschiessen. Hier sehe ich zum Beispiel HyperV mit seinem extrem robusten Dateisystem klar im Vorteil gegenüber VmWare. Einer der Gründe warum ich bei Installationen mit Vmware gerne Windows als NFS-Storage-Lieferant verwende anstelle iSCSI mit VMFS.

 

Daher empfehle ich auch immer 2 leistungsstarke Online USV's ab ca. 3000 VA (da sind die Geräte in der Regel technisch vernünftig aufgebaut). Ich hatte schon mehr grobe Probleme wegen sterbenden kleineren Einzel-USV's als mit Stromausfällen. Für mich ein Grund um eine Umgebungen nicht zu bauen/zu betreuen. Dazu so viel Akkuleistung wie möglich. Notfalls wenn das Budget knapp ist, tuts auch ein Eigenbau mit grossen Akkus und Verkabelung durch den Elektriker. Kostet einen Bruchteil, dafür ist Garantie weg. Akkus halten aber länger, da bei kleineren Ausfällen nie tiefentladen wird und vernünftige grosse Akkus technisch besser gebaut sind. Des weiteren immer genügend Reaktionszeit um hinzufahren, sofern überhaupt nötig. Ein paar h werden immer überbrückt. Auch die Telefonanlage kann grad darüber gezogen werden, vor allem bei neueren IP-Dingern geht da nämlich gar nix mehr.

bearbeitet 20. August 2015 von Weingeist

[lefg 276]

Ich habe solche Art der Fragestellung, nach Vor- und Nachteilen schon öfters erlebt, manchmal hatte ich den den Eindruck, die Nachteile mussten krampghaft an den Haaren herbeigezogen werden. Sind die "Nachteile" wesentlicher oder marginaler Art? Meist fallen sie doch gegenüber den Vorteilen nicht ins Gewicht. Die vorteiligen Eigenschaften, das sit doch meist das Wesentliche.

bearbeitet 21. August 2015 von lefg

[monstermania 53]

Nachteile:

Nachteile sehe ich - bereits genannte Spezialfälle mal aussen vor - nur in der Stromversorgung und was alles damit zusammenhängt.

 

Vor allem die saubere, automatische Abschaltung der einzelnen VM's ist nicht immer so trivial wie mit physischen PC's. Auch die Endabschaltung des Hosts kann mitunter problematisch sein (unter VmWare imho anspruchsvoller wie unter HyperV).

Einen typischen SBS hat es normalerweise nicht gross gejuckt wenn man der Strom weg war. Aufm Exchange nen Rollback oder nen Wiederherstellungspunkt vom Vorabend und gut war. Falls überhaupt notwendig.

Bei VM's sieht das schon etwas anders aus. Da kann es einem so ziemlich alles zerschiessen. Hier sehe ich zum Beispiel HyperV mit seinem extrem robusten Dateisystem klar im Vorteil gegenüber VmWare. Einer der Gründe warum ich bei Installationen mit Vmware gerne Windows als NFS-Storage-Lieferant verwende anstelle iSCSI mit VMFS.

 

Daher empfehle ich auch immer 2 leistungsstarke Online USV's ab ca. 3000 VA (da sind die Geräte in der Regel technisch vernünftig aufgebaut). Ich hatte schon mehr grobe Probleme wegen sterbenden kleineren Einzel-USV's als mit Stromausfällen. Für mich ein Grund um eine Umgebungen nicht zu bauen/zu betreuen. Dazu so viel Akkuleistung wie möglich. Notfalls wenn das Budget knapp ist, tuts auch ein Eigenbau mit grossen Akkus und Verkabelung durch den Elektriker. Kostet einen Bruchteil, dafür ist Garantie weg. Akkus halten aber länger, da bei kleineren Ausfällen nie tiefentladen wird und vernünftige grosse Akkus technisch besser gebaut sind. Des weiteren immer genügend Reaktionszeit um hinzufahren, sofern überhaupt nötig. Ein paar h werden immer überbrückt. Auch die Telefonanlage kann grad darüber gezogen werden, vor allem bei neueren IP-Dingern geht da nämlich gar nix mehr.

Moin,

das ist jetzt nicht ernst gemeint oder!? :suspect:

Was Du hier anmerkst trifft wohl auf jede komplexere IT Infrastruktur zu.

Ob nun das Filesystem von Windows oder VMWare stabiler ist, lasse ich mal dahingestellt. Das kommt m.E. auch ganz stark auf das hinter der Infrastruktur stehende Storage an. Weil wenn es das zerschießt spielt auch der Hypervisor keine Rolle mehr.

 

Zum Thema USV:

Ich bin froh, dass man in der virtuellen Welt die Möglichkeit hat das Shutdownverhalten der VM's bei einem totalen Stromausfall individuell zu steuern. Früher gab es zig Server und jeder hatte eine lokale USV. Da war es dann oft Zufall in welcher Reihenfolge die Server bei einem Stromausfall herunterfuhren. So war der Exchange oder auch der SQL Server oft vor dem entsprechenden Applikationsserver weg. Auch nicht schön.

 

Heute haben wir 2 USV, die über Kreuz unsere 3 Hosts sowie die übrige Infrastruktur versorgen. Die Kapazität der USV ist so bemessen, dass selbst eine USV die Infrastruktur für ca. 30 Minuten mit Energie versorgen kann.

So Bald die Akkukapazität einer der USV unter 75% absinkt (nach ca. 5 Minuten auf Batterie) wird der automatische Shutdown der Infrastruktur eingeleitet.

Ich habe das hier über Gruppen realisiert

1. Gruppe Applikationserver z.B. RDP, Versandserver, AV, usw.

2. Gruppe Backendserver (z.B. SQL und sonstige Datenbankserver, Exchange, usw.)

3. Gruppe sonstige (z.B. DC, usw.).

Dabei spielt es natürlich keine Rolle auf welchem Host die der jeweiligen Gruppe zugehörige VM gerade läuft.

4. Nachdem die VM heruntergefahren wurden werden die Hosts in den Wartungsmodus geschaltet und heruntergefahren.

 

Bei letzten simulierten Stromausfall hat der Shutdown aller unsere VM (ca. 40) und der 3 Hosts 14 Minuten gedauert.

Ja, so etwas ist in der virtuellen Welt komplexer aber muss ja auch nur 1 mal eingerichtet werden. Und irgendwie muss man als Admin doch auch sein Geld verdienen.

[GTRDRIVER 17]

Hallo

 

@lefg:

 

Ich stimme prinzipiell zu - jedoch hat jede TEchnik - jedes Produkt - jede Methode Vor und Nachteile - das liegt in der Natur der Sache - Nun müsste man beides gewichten und das ist schwierig da die Gewichtung ja bei jedem anders ausfällt. (je nach Einsatz-Zweck etc...) Daher spricht aus meiner Sicht nichts gegen die bloße Aufzählung von Vor und Nachteilen - die Gewichtung muss man dann dem überlassen der das interpretieren muss.

 

 

@Weingeist:

 

ich bin ganz offen- so ganz verstanden habe ich es nicht.  Du meinst dass die SSD´s unterschiedliche Latenzen haben und der Raid Controller deshalb aus dem Tritt kommt und "wartet" ?

Aber dann müsste das doch auch passieren wenn das OS "auf Bleck" - also ohne Hypervisor aufgesetzt ist ?

Oder sprechen wir von einer Latenz im Hypervisor ?

Der Raid ist ja Hardware und sollte sich dem OS einfach als Device präsentieren oder sehe ich das falsch ?

 

Im speziellen Fall hier habe ich einen Raid60 Verbund aus 6 SSD´s  - die Werte die ich mit diversen Benchmark Tools ermittelt habe sind schon beeindruckend - komischerweise weichen diese (bei messung inenrhalb und ausserhalb der VM) nicht besonders stark ab - aber diese "Hänger" machen mir sorgen.

 

Ich habe hier noch 2 ESXI Maschinen  - teilweise mit SSD Raid - teilweise mit SAS 15k Raid - da hab ich sowas noch nicht erlebt.

 

Cu

GTR

 

 

Nachtrag zum Thema Datensicherheit und VMWARE:

 

aus meiner Erfahrung und auch wenn man  im Netz so sucht ist das VMWARE Dateisystem auch sehr robust - was bei VMWARE wiederum kritisch ist sind Snapshots  - such mal mach  "Stromausfall" oder "Absturz" und "Snapshot" - das ist echt mist bei VMWARE - ist mir selbst mal passiert - da vesteht das HD image ja auch verschiedenen Dateien die dann vom HV wieder logisch zusammengesetzt werden - je nach "Zeitpunkt des Snapshot" und wenn dann die Datei in der das gespeichert wird wie das zusammen passt "hin" ist oder einen alten stand hat (wie bei  mir weil im Cache des RAid noch eine vorherige Version war - dann erlebst du ein DESASTER aus nicht reparierbarem Datenmüll... 

bearbeitet 21. August 2015 von GTRDRIVER

[zahni 554]

Wie  bei VMWare: schaue in die HCL, ob Deine Konfig  supported ist. Prüfe bei Deinem Server-Hersteller, ob er  Deine SSDs an Deinem RAID-Controller validiert und zertifiziert  hat.

Wenn das nicht gegeben ist, musst Du mit unvorhersehbaren Fehlern rechnen. Mal davon abgesehen geht  ein Hypervisor ganz anders mit seinem Storage um. Hier werden u.U. andere Blocksizes usw. verwendet.

[GTRDRIVER 17]

Hallo 

 

Der Server und der Raid controller ist supported.

Die SSD´s tauchen wiederum in der Liste des Raid Controllers auf. Sollte also passen.

[zahni 554]

Namen doch mal Namen und  Bezeichnungen. Ist denn der RAID-Controller in dem Server supported?

[GTRDRIVER 17]

Servus

 

das ist ein Ibm System das laut Liste supportet wird. (ich hab jetzt die Modellnummer nicht da)  - der Raid wiederum ist ein von IBM gelabelter LSI und laut LSI wiederum passen die SSD´s zum Raid

[Weingeist 159]

@Lefg: Finde ich nicht dass die Krampfhaft herbeigezogen werden. Die zusätzlichen Risiken sind neben den sehr grossen Vorteilen nicht zu vernachlässigen. Vor allem in Kleinumgebungen wo die Infrastruktur bisher bei vielen eine eher unbedeutende Rolle gespielt hat. Da sah man in der Vergangenheit oft, dass da einfach ein günstiger Server steht, der alles macht. Dazu im höchsten Falle eine poplige USV. Mit Virtualisierung wird sie plötzlich essentiel. Ebenso Dinge wie ECC-Ram (auch wenn das eh schon vorher sinnvoll wäre). So zumindest die Erfahrung die ich gemacht habe ;)

 

EDIT: Hui, da gabs ja schon massi neue Antworten (wurde ned angezeigt, sorry)

 

@Monstermania: Das mag bei vielen mittleren Umgebungen zutreffen, aber bei kleinen hab ich echt schon alles gesehen. Das funktioniert mit nem SBS Single-Server in der Regel auch. Wenn er hochkommt und alles tut, alles OK. Wens ned haut, tja nen Rollback eines Servers und gut ist. Sache von ein paar Minuten. Kann mich damit nicht wirklich identifizieren, aber es funktioniert. 2x Online USV mit ordentlich Kapazität kost gutes Geld.

Wird nun virtualisiert und hat voneinander abhängig VM's ist das ganz nicht mehr so einfach. Da ists eben sträflich wenn man seine Infrastruktur nicht den neuen Bedingungen anpasst. ;)

 

Bezüglich runterfahren: Nun, auch bei physischen PC's konnte man das über LAN-Karten bereits machen. War jetzt nicht so der Akt. Ich fands einfacher als es z.B. mit VmWare jetzt ist.

 

Bezüglich Filesystem: VMFS ist im Verlgeich mit NTFS alles andere als robust. Das sehen auch topcracks die das VMFS-System wirklich kennen und teilweise auch reparieren können so. Es gibt ja noch ned mal richtige Diagnose oder Reperatur-Tools, was es im NTFS Bereich gibt.

 

@GTRDRIVER: Nun, die Hersteller geben meist Latenzen an welche eine SSD im Schnitt macht. Dann haben die eher günstigen SSD's teilweise massive Ausreisser wo dann plötzlich der Faktor 50 oder manchmal sogar mehr ansteht. Je mehr man also in nem RAID-Verbund hat, desto höher die Wahrscheinlichkeit, dass es kurz hintereinander passiert. Dann fehlen plötzlich ein paar IOPS und es geht 1-3 Sekunden gar nix mehr. Da hier selten mit dem Cache des Controllers gearbeitet wird, kann der das ned mal auffangen. Konnte das schon viele male beobachten. Mit Magnetplatten noch nie. Auch mit SLC's hatte ich das nie, nur mit dem modernen MLC Kram.

 

Ist auch in den Logs/Diagrammen der VM/Host ersichtlich. Da mal die Latenzen der Datastores anschauen. Daher verwende ich nur SSD's im RAID-Verbund, die auch die grossen Hersteller verwenden. Mit Intel DC S3700 habe ich zum Beispiel sehr gute Erfahrungen gemacht, auch wenn es da - wenn auch sehr sehr selten - doch mal zu einem solchen Verhalten kommt.

bearbeitet 21. August 2015 von Weingeist

[NorbertFe 2.034]

Wieso ist die USV bei einem Server der alles virtualisiert essentieller als bei einem Server der alles nicht virtualisiert erledigt?

 

Bye

Norbert

[magheinz 110]

Servus

 

das ist ein Ibm System das laut Liste supportet wird. (ich hab jetzt die Modellnummer nicht da)  - der Raid wiederum ist ein von IBM gelabelter LSI und laut LSI wiederum passen die SSD´s zum Raid

"Laut LSI" ist nicht ganz so interessant wie das was IBM sagt. Schliesslich ist der Controller ja von IBM gelabelt. Da kann durchaus ein Unterschied in der Firmware gegenüber dem original-LSI sein.

 

Im übrigen: Ich würde derzeit um IBM einen großen Bogen machen...

[Doso 77]

Wir haben IBM SANs. Eigentlich ganz gut, nur zwischendrinn rennt man dann mal wieder in einen heftigen Firmware Bug und hat 2x halben Tag Downtime mit Technikerbesuch. Niemals rausgefunden was es war, einfach mal auf Verdacht Firmware gepatcht seitdem ist Ruhe. Ist also irgendwie gemischte Gefühle weil sonst ist das Ding top.

bearbeitet 21. August 2015 von Doso

[magheinz 110]

Wir haben Bladecenter+Pizzaboxen von IBM und werden definitiv kein IBM mehr kaufen. Bei jedem zweiten Call muss ich erst mal wieder klären das die betroffenen Geräte Support haben.

Seit 3Wochen tüfteln die an einem Blade rum. 2mal RAM-Tausch, einmal CPU und jetzt vermutlich das ganze Board. Die angestrebten vier Stunden schaffen die auch fast nie. Die brauchen ja schon zwei Tage um die DSA-Logs jedes mal zu lesen. Ich könnte noch viel mehr erzählen, alleine wenn ich an die Emulexgeschichten denke...

[DocData 85]

Die 4 Stunden die viele Hersteller im Rahmen ihrer reaktiven Supportverträge nennen (langläufig 13x5x4h oder 24x7x4h) bezieht sich immer auf die Reaktionszeit. Wenn sich der Hersteller innerhalb von 4 Stunden meldet, gilt die SLA als erfüllt. Die 4 Stunden beziehen sich nie auf das Eintreffen von Ersatzteilen oder gar die Wiederherstellung. Einfach mal sehr genau die Vertragsbedingungen lesen.

[magheinz 110]

Das ist mir bekannt. Auf mein Ticket von heute 16:00 gab es von seiten IBM genau null Reaktion. Obwohl 24*7 4Stunden und Stufe2. Bei mir ist das schon wieder länger als vier Stunden her...