Hyper-V - wohin mit Host Betriebssystem

[Doso 77]

Wir planen den Aufbau eines HyperV Clusters mit mehreren Windows Server 2012 Servern. Mir stellt sich nun die Frage wohin das Betriebsystem des HyperV Host Servers installiert werden soll, die VHD Dateien liegen bei uns auf einem SAN das mittels iSCS angebunden ist.

 

Man kann nun 2 kleine Festplatten verbauen und diese zu einem RAID 1 zusammenfassen und hier installiert, oder man nutzt iSCS Boot und bootet den Server selber auch über das SAN. iSCS Boot ist aber recht komplex und leider sind die hierfür verwendeten Netzwerkkarten dann auch nicht mehr im HyperV nutzbar da sie schlicht nicht im HyperV Manager angezeigt werden. Eine weiter Möglichkeit wäre die Installation auf einem (eingebauten) USB Stick, was aber wohl von Microsoft nicht supported wird.

 

Hat hier schon jemand Erfahrung mit und kann sagen wie es bei euch gelöst wurde. In entsprechenden Guides und Anleitungen steht nur immer wie man den Cluster einrichtet, aber nix dazu was man mit dem Host OS macht.

[NorbertFe 2.034]

Naja, die zwei Varianten die in Frage kommen, hast du doch schon genannt. ;) Ist also eher die Frage von willst du lieber mehr Netzwerkkarten kaufen/stecken, oder willst du lokalen Storage haben. Bei ersterem geht dir die Performance und die Speicherkapazität im Storage System für die Hosts mit ab, bei letzterem hast du zusätzliche ausfallgefährdete Teile. ;)

 

Bye

Norbert

 

PS: Im Fall von iscsi würde ich mich wohl für lokale Bootplatten entscheiden. Bei FC, ist boot from SAN jetzt kein wirklicher Stress.

[Necron 71]

Hi,

 

nimm die lokalen Platten. Von Boot from SAN über iSCSI würde ich definitiv abraten. Bei einem Hyper-V Host würde ich ebenfalls nur bedingt zu Boot from SAN über FC raten. Ich habe bisher nur bei einem Kunden Boot from SAN mit iSCSI und Hyper-V gesehen. Wirklich rund läuft das aber nicht.

 

Ich tendiere, um es nochmals zu erwähnen, bei Hyper-V Hosts immer zu lokalen Platten.

[NorbertFe 2.034]

Warum das abraten bei fc? Konkrete Gründe, oder nur bauchgefühl? :)

[dvbuddy 14]

Boot über iSCSI vom San haben wir auch schon bei Kunden im Einsatz. Läuft stabil, hat auch Nachteile: z.B. bei der Datensicherung, geht die Performance in den Keller. Ich würd immer lokale Platten für den Host empfehlen.

Gruß dvbuddy

bearbeitet 30. September 2013 von dvbuddy

[Doso 77]

Danke für euer Feedback. Hatte mir schon gedacht das 2 kleine lokale Platten am sinnvollsten sind. Bei den von uns verwendeten Fujitsu Servern ist ein einfacher Raid Controller (Raid 0/1) immer im Grundpreis mit dabei, das passt also.

[Necron 71]

Warum das abraten bei fc? Konkrete Gründe, oder nur bauchgefühl? :)

 

Naja was Kosten heute noch Platten im Server. ;)

 

Boot from SAN über FC habe ich schon ohne Probleme bei File Servern installiert und in Betrieb gesehen. Spricht also auch nichts dagegen, dies bei Hyper-V Hosts zu machen. Ich würde aber aus Erfahrungswerten, auch wenn diese größtenteils auf Boot from SAN über iSCSI beruhen, bei einem Hyper-V Host eher zu einem lokalen RAID1 mit zwei Platten greifen. :)

[NorbertFe 2.034]

Naja was Kosten heute noch Platten im Server. ;)

Naja, wenn ich mit Blades arbeiten will, dann ist das eben 1. ne Menge mehr an beweglichen Teilen und 2. auch stromtechnisch mehr. Und ja, ich hab durchaus auch Hosts, die einfach lokal Bootplatten bekommen, weils eben viel einfacher im Fehlerfall zu Troubleshooten ist. ;)

 

Boot from SAN über FC habe ich schon ohne Probleme bei File Servern installiert und in Betrieb gesehen. Spricht also auch nichts dagegen, dies bei Hyper-V Hosts zu machen. Ich würde aber aus Erfahrungswerten, auch wenn diese größtenteils auf Boot from SAN über iSCSI beruhen, bei einem Hyper-V Host eher zu einem lokalen RAID1 mit zwei Platten greifen. :)

Also ich kann dir zumindest aus meinen Erfahrungswerten der letzten 6 Jahre sagen, dass ich genau keine Probleme seit Windows 2008 (auch schon mit Hyper-V) und neuer mit Boot from SAN im FC Umfeld kenne. Hier läuft aktuell ein Hyper-V Cluster mit 8GB FC Infrastruktur an einer EMC VNX und da gibt's keinen Stress. Im Gegenteil, ich muß im Zweifel nur die LUN umhängen wenn mal neue Hardware gebraucht wird. ;)

 

Bye

Norbert

[Necron 71]

Danke Norbert! :)

Das mit dem Umhängen ist ein Vorteil, weil es schneller ist als ein Bare-Metal Deployment über den SCVMM zu fahren. ;)

[DrDisk 2]

Ich denke Daniel hat recht. Aus der Management Perspektive sind lokale Platten immer besser. Für Core Server reicht eine kleine billige Platte aus. Hauptsache du hast genug Platz für die Auslagerungsdatei. Alles andere auf´s CSV und los geht´s. Falls der Server abraucht geht nichts verloren und bei Plattenschaden ist es eben nur eine kleine Billigplatte.

Ein weiterer Gedanke: man will bei CSVs den Netzwerktraffic gering halten, es wird sowieso zu viel hin und her geschickt bei CSVs. Wenn einfache Sachen lokal laufen können, ist das ein zusätzlicher Performance Gewinn. Beim Auswechseln der Nodes wird man wahrscheinlich neue Treiber brauchen also ist eine Windows Core Neuinstallation sowieso eine gute Idee. Bringt also nix wenn das Storage zentralisiert isch

Nur mal so ne Idee....

[NorbertFe 2.034]

Ich weiß ja nicht, wie du nodes tauschst, aber ich redete vom 1:1 Ersatz bei totalausfall und nicht von hardwarupgrade. ;)

[zahni 554]

Kleine Ergänzung:

 

Aktuelle Blades von HP können intern auch von SD-Karten booten. Die haben per Default intern schon eine gesteckt, von der die Installations- / Diag-Software gestartet werden kann.

Ob die Lösung für Hyper-V brauchbar ist, kann ich nicht sagen. Für den "Anderen" aber vermutlich schon.

bearbeitet 12. Oktober 2013 von zahni

[NorbertFe 2.034]

Hyper v auf ne sd karte? Ich bezweifle, dass das geht, und selbst wenn, dass das besonders sinnvoll ist. Ich meine mich zu erinnern, das auch VMware dies nicht mehr empfiehlt, da bin ich mir aber nicht sicher, da nicht ganz meine Baustelle. ;)

[zahni 554]

Schau mal hier:  http://h18004.www1.hp.com/products/quickspecs/13971_div/13971_div.pdf

Wird, zumindest von HP, supported. Wir aber auch ein RAID 1 mit zwei internen HD's benutzt. Wegen der Ausfallsicherheit...

[NorbertFe 2.034]

Nicht alles was machbar ist, ist ja auch immer sinnvoll. ;)