none
Hyper-V Hostserver Anbindung an ein SAN via FC oder Kupfer? RRS feed

  • Frage

  • Hallo zusammen,

    ich habe eine konkrete Frage zum Thema Hyper-V Hostserver und der physischen Anbindung an ein SAN. Dazu folgende, kurze Infos:

    Wir planen eine neue Virtualisierungsumgebung. Diese soll unter Hyper-V laufen.
    Dazu sollen 2 Host Server auf 1 gemeinsames SAN zugreifen.

    Wir haben einige Gespräche mit Systemhäusern in Sachen benötigter Hardware durchgeführt. Dabei kommt es zu unterschiedlichen Aussagen und "Meinungen" in Sachen Anbindung zum SAN. So wurde uns u.a. mitgeteilt dass:

    eine Anbindung zwischen Hostserver und SAN via FC NICHT optimal wäre, da Hyper-V bevorzugt das SMB Protokoll sprechen würde und dieses am besten über eine 10 GB Kupfer Anbindung zu lösen wäre.

    Meine konkrete Frage:

    Was ist die optimale Anbindung (Performance und Stabilität) für eine Virtualisierungsumgebung unter Hyper-V, welche aus 2 Hostservern und 1 SAN besteht?

    Bei meinen Recherchen habe ich weder eine ähnliche Frage, noch eine befriediegende Antwort gefunden.

    Vielen Dank! :-)

    Viele Grüße von der...
    Würstchenbude


    • Bearbeitet Würstchenbude Montag, 13. Juni 2016 14:07 Textkorrekturen
    Montag, 13. Juni 2016 14:00

Antworten

  • Was ist die optimale Anbindung (Performance und Stabilität) für eine Virtualisierungsumgebung unter Hyper-V, welche aus 2 Hostservern und 1 SAN besteht?

    Bei meinen Recherchen habe ich weder eine ähnliche Frage, noch eine befriediegende Antwort gefunden.

    Das ist deshalb, weil es keine eindeutige Antwort darauf gibt. Es kommt auf einen Haufen Faktoren an, und die meisten spielen nicht im Bereich der Infrastruktur, sondern bei den Workloads, die ihr virtualisieren wollt. Aber wenn ihr 10GbE- und 16GFC-Komponenten überhaupt preislich für zwei Hosts in Betracht zieht, dann muss dahinter ja auch ein Storage sein, das diese Bandbreite bedienen kann - und darauf ein Workload, der eine solche Bandbreite braucht!

    Übrigens, "Kupfer" ist natürlich rein symbolisch, denn auch 10GbE wird in der Regel über Glas gefahren werden.

    Und "SAN" ist bei einer SMB-Anbindung ja auch nicht ganz richtig, denn es ist ja dann ein Fileserver und kein Block-Storage.

    Was ist nun besser? It depends. Für eine ganz ganz grobe Einschätzung müsste man zumindest wissen:

    • wieviele VMs werden insgesamt in diesem Cluster laufen?
    • Was werden sie tun (VDI, SQL, Exchange, Webserver, andere Applikationsserver, usw. usw.)?
    • Ist in der Lebenspanne der jetzt zu schaffenden Umgebung absehbar, dass der Cluster - sowohl die VMs als auch und vor allem die Hosts - stark erweitert wird?
    • Welches SAN- und Windows Clustering-Know-How ist bereits vorhanden? Ist schon ein SAN im Einsatz?

    Die pauschale Antwort "SMB3 ist besser" ist genauso falsch wie die pauschale Antwort "FC ist besser".

    Gruß


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 13. Juni 2016 14:24
  • Hallo Würstchen, 

    wie Evgenij schon sagt gibt es auch bei der Storageanbindung für Hyper-V keinen Königsweg. 

    Hyper-V kann mit drei Arten von Storageanbindung umgehen, FC, iSCSI und SMB 3.x (begrenzt sogar direkt Attached SAS aber das ist nicht wirklich supported).  

    Leistungsmässig sind alle equivalent. Es kommt auf eure "Umstände" an. FC ist vergleichweise komplex und teuer für kleine Umgebungen. Da würde ich es bei zwei Hosts nicht in Erwägung ziehen. 

    Bleiben noch SMB 3.x und iSCSI. Den vollen SMB 3.x Umfang bietet aktuell nur Windows Server. Da ihr hier mit Updates und Downtimes rechnen müsst, braucht ihr entweder eine redundante Scale out Fileserver Lösung (was wiederrum etwas teurer wird) oder ihr müsst mir regelmässigen Downtimes für Updates leben. 

    Wo aus logischer sich dann nur noch iSCSI übrig bleibt. Hier gibts es schon gute Hardware zu vernünftigen Preisen z.B. Dell Equalogic oder NetApp. Zudem könnt ihr die 10G Basis von iSCSI nutzen um z.B. nach Release von Windows Server 2016 auf Storage Spaces Direct zu gehen und damit später vielleicht komplett von der SAN Infrastruktur wegzugehen. 

    Ich hoffe das hilft dir etwas weiter. 

    P.s. Bei 10G oder schnelleren Netzwerken ist RJ45 und Kupfer zu vermeiden. Der Energieaufwand und die Fehleranfälligkeit wächst mit zunehmender Netzwerkgeschwindigkeit enorm. Greif hier bei 10G auf SFP+ und Kabel mit Glaskern oder bei höheren Geschwindigkeiten auf den entsprechenden genormten Standard zurück. 


    Kind regards, Flo




    Montag, 13. Juni 2016 14:56
  • Naja, was macht ihr denn jetzt mit vSphere? Das ist doch eigentlich der beste Ausgangspunkt für die Planung - Du kennst das Lastprofil, die I/Os, den Speicherbedarf usw. Auch hier müsste ja die Entscheidung für VMFS auf SAN oder NFS gefallen sein - ähnliche Argumente greifen auch bei Hyper-V. Wegen Updates hat Flo schon recht, andererseits würdet ihr auch bei nicht-redundantem SAN Downtime bekommen, wenn dieses Mal gepatcht werden muss. Was die Frage nach dem Übertragungsprotokoll angeht: Es ist in Deinem Szenario aus Performance-Sicht vermutlich egal, ob Du FC, SMB3 oder - ich lehne mich mal aus dem Fenster - iSCSI über 10 GB nimmst. Und auch hier würde ich Flo zustimmen - nimm 10GbE-basierte Technik (NICHT Kupfer!!!!), bist am Ende flexibler.

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 13. Juni 2016 17:17
  • 1. Zur Zeit verwalte ich eine VMware basierende Umgebung und verfüge über einiges Knowhow in dem Bereich vSphere. Meine Kenntnisse in Hyper-V sind grundlegender Natur. Aktuell habe ich einen Hyper-V 2012 R2 Testserver im Kernel Modus laufen und experimentiere darauf fleißig.

    2. In der Hyper-V Umgebung wird so einiges laufen:
    Terminal-Server 2012 R2 für 50 Anwender, Exchange-Server 2010, SQL-Server 2012, SQL-Server 2005, AD Domänen-Controller, Fileserver mit aktuell 3,8 Mio Dateien, CTI-Server, einige W7 Workstation für spezielle Anwendungen, sowie einige Server und W2008 R2 und W2012 für spezielle Applikationen (z.B. ERP-System). In Summe werden es etwa 20 bis 22 Maschinen sein. Das ganze "Zeuch" ;-) läuft derzeit unter der VMware völlig Stressfrei. Leider sind wir aus strategischen Gründen gezwungen auf Hyper-V umzusteigen. Das bedeudet ebenfalls, einen Großteil der VMware VM zu Hyper-V zu konvertieren.

    Hi Peter,

    wie schon geschrieben, gibt es keine exakte Vorgabe für Deine Umgebung, aber Du hast einen riesen Vorteil gegenüber anderen Planern, Du kannst den aktuellen Workload messen! Miss beispielsweise die IoPS, Du hast die derzeitige Hardwareauslastung plus zukünftige Anforderungen.

    Ich persönlich sehe kein "Leider" bei Hyper-V. Es ist ein stabiler Hypervisor mit genauso vielen interessanten Features. Aber auch hier gibt es kein: Was ist besser? Hyper-V oder VMware. Hyper-V bietet interessante Disaster Recovery Möglichkeiten auch beispielsweise hin zu Azure.

    Wenn Du noch etwas Zeit mit der Planung und Umsetzung hast, kann es sich lohnen auf Windows Server 2016 zu warten, da auch hier Verbesserungen bei Hyper-V passieren.

    Im SMB Bereich kann auch die Nutzung von SMB Direct und RDMA NICs in Betracht gezogen werden. SMB bietet den Vorteil einer nativen Betriebssystemunterstützung und Features wie SMB Multichannel etc.

    Gruß,
    Marcel

    https://www.windowspro.de/marcel-kueppers

    I write here only in private interest

    Disclaimer: This posting is provided AS IS with no warranties or guarantees, and confers no rights.

    Dienstag, 14. Juni 2016 07:02
  • Moin,

    ich werfe mal etwas ganz anderes in die Runde:

    Wenn es nur zwei Hyper-V Nodes werden sollen und kein Wachstum angedacht ist, würde ich auch über ein einfaches shared SAS Enclosure nachdenken.

    Kostet im Vergleich zum SAN deutlich weniger in der Anschaffung und im Betrieb.


    This posting is provided AS IS with no warranties.

    Dienstag, 14. Juni 2016 10:56
  • Naja, aber gibt es denn inzwischen eine Lösung, die offiziell für Windows Failover Clustering zertifiziert ist? Das letzte Mal, dass ich geguckt habe (zugegeben, Jahre her ;-) ) war das noch nicht der Fall... Und funktioniert hat es nur solange kein Failover erfolgen sollte.

    Außerdem war das Geld für den TO nicht der primäre Bewertungsfaktor, sondern die Performance, auch die nur in der Signalkette. Und da er gewillt war, 10GbE SMB3/iSCSI mit 16Gb FC zu vergleichen, sehe ich hier bei 6Gb SAS ein Vergleichbarkeitsproblem...

    Eins wäre für SAS allerdings zu sagen: Es wäre in diesem Fall WIRKLICH KUPFER! ;-)


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 14. Juni 2016 13:17
  • Von DataOnStorage gibt es 12G SAS Enclosures, die für 2012 R2 zertifiziert sind.

    Über 10Gb iSCSI vs. 16Gb FC (vs. 12G SAS vs. 10Gb SMB3) zu diskutieren lohnt sich ohnehin erst, wenn man dahinter ein Disk/SSD Array betreibt, welches den möglichen Durchsatz auch bedienen kann.

    Geht es nur um den Transport zwischen Storage und Server und werden alle anderen Faktoren ausgeblendet, gewinnt natürlich das Prtotokoll mit der höchsten Bandbreite und dem geringsten Overhead, also 16Gb FC in diesem Fall. Für praxisrelevant halte ich so einen Ansatz jedoch nicht.


    This posting is provided AS IS with no warranties.

    Mittwoch, 15. Juni 2016 04:39
  • Letztendlich spielt die Skalierung in Zukunft eine Rolle.

    Eine Idee wäre beispielsweise auch, Windows Server 2016 mit Storage Spaces Direct und 3 Knoten mirrored zu betreiben. Interner Festspeicher wäre dann auch über SATA unterstützt oder unterschiedliche Tiers mit SSDs zusammen. So wäre man für die Zukunft über 3 Knoten breiter aufgestellt und könnte Compute und Storage hyperconverged auf einer Node fahren inkl. SMB3 :)

    https://www.windowspro.de/marcel-kueppers

    I write here only in private interest

    Disclaimer: This posting is provided AS IS with no warranties or guarantees, and confers no rights.

    Mittwoch, 15. Juni 2016 06:38

Alle Antworten

  • Was ist die optimale Anbindung (Performance und Stabilität) für eine Virtualisierungsumgebung unter Hyper-V, welche aus 2 Hostservern und 1 SAN besteht?

    Bei meinen Recherchen habe ich weder eine ähnliche Frage, noch eine befriediegende Antwort gefunden.

    Das ist deshalb, weil es keine eindeutige Antwort darauf gibt. Es kommt auf einen Haufen Faktoren an, und die meisten spielen nicht im Bereich der Infrastruktur, sondern bei den Workloads, die ihr virtualisieren wollt. Aber wenn ihr 10GbE- und 16GFC-Komponenten überhaupt preislich für zwei Hosts in Betracht zieht, dann muss dahinter ja auch ein Storage sein, das diese Bandbreite bedienen kann - und darauf ein Workload, der eine solche Bandbreite braucht!

    Übrigens, "Kupfer" ist natürlich rein symbolisch, denn auch 10GbE wird in der Regel über Glas gefahren werden.

    Und "SAN" ist bei einer SMB-Anbindung ja auch nicht ganz richtig, denn es ist ja dann ein Fileserver und kein Block-Storage.

    Was ist nun besser? It depends. Für eine ganz ganz grobe Einschätzung müsste man zumindest wissen:

    • wieviele VMs werden insgesamt in diesem Cluster laufen?
    • Was werden sie tun (VDI, SQL, Exchange, Webserver, andere Applikationsserver, usw. usw.)?
    • Ist in der Lebenspanne der jetzt zu schaffenden Umgebung absehbar, dass der Cluster - sowohl die VMs als auch und vor allem die Hosts - stark erweitert wird?
    • Welches SAN- und Windows Clustering-Know-How ist bereits vorhanden? Ist schon ein SAN im Einsatz?

    Die pauschale Antwort "SMB3 ist besser" ist genauso falsch wie die pauschale Antwort "FC ist besser".

    Gruß


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 13. Juni 2016 14:24
  • Hier noch einige zusätzliche Infos zum Thema:

    1. Zur Zeit verwalte ich eine VMware basierende Umgebung und verfüge über einiges Knowhow in dem Bereich vSphere. Meine Kenntnisse in Hyper-V sind grundlegender Natur. Aktuell habe ich einen Hyper-V 2012 R2 Testserver im Kernel Modus laufen und experimentiere darauf fleißig.

    2. In der Hyper-V Umgebung wird so einiges laufen:
    Terminal-Server 2012 R2 für 50 Anwender, Exchange-Server 2010, SQL-Server 2012, SQL-Server 2005, AD Domänen-Controller, Fileserver mit aktuell 3,8 Mio Dateien, CTI-Server, einige W7 Workstation für spezielle Anwendungen, sowie einige Server und W2008 R2 und W2012 für spezielle Applikationen (z.B. ERP-System). In Summe werden es etwa 20 bis 22 Maschinen sein. Das ganze "Zeuch" ;-) läuft derzeit unter der VMware völlig Stressfrei. Leider sind wir aus strategischen Gründen gezwungen auf Hyper-V umzusteigen. Das bedeudet ebenfalls, einen Großteil der VMware VM zu Hyper-V zu konvertieren.

    3. Die "Lebensdauer" des System ist auf 5 Jahre berechnet. Dementsprechend ist die Hardware sorgfältig ausgwählt. Es ist zum aktuellen Zeitpunkt NICHT davon auszugehen, dass noch mehr VM erzeugt werden. Eher wird es einen Trend nach unten geben. Aktuell plane ich aber mit den o.a. Zahlen.

    Viele Grüße
    Peter Duwenhögger

    Montag, 13. Juni 2016 14:49
  • Hallo Würstchen, 

    wie Evgenij schon sagt gibt es auch bei der Storageanbindung für Hyper-V keinen Königsweg. 

    Hyper-V kann mit drei Arten von Storageanbindung umgehen, FC, iSCSI und SMB 3.x (begrenzt sogar direkt Attached SAS aber das ist nicht wirklich supported).  

    Leistungsmässig sind alle equivalent. Es kommt auf eure "Umstände" an. FC ist vergleichweise komplex und teuer für kleine Umgebungen. Da würde ich es bei zwei Hosts nicht in Erwägung ziehen. 

    Bleiben noch SMB 3.x und iSCSI. Den vollen SMB 3.x Umfang bietet aktuell nur Windows Server. Da ihr hier mit Updates und Downtimes rechnen müsst, braucht ihr entweder eine redundante Scale out Fileserver Lösung (was wiederrum etwas teurer wird) oder ihr müsst mir regelmässigen Downtimes für Updates leben. 

    Wo aus logischer sich dann nur noch iSCSI übrig bleibt. Hier gibts es schon gute Hardware zu vernünftigen Preisen z.B. Dell Equalogic oder NetApp. Zudem könnt ihr die 10G Basis von iSCSI nutzen um z.B. nach Release von Windows Server 2016 auf Storage Spaces Direct zu gehen und damit später vielleicht komplett von der SAN Infrastruktur wegzugehen. 

    Ich hoffe das hilft dir etwas weiter. 

    P.s. Bei 10G oder schnelleren Netzwerken ist RJ45 und Kupfer zu vermeiden. Der Energieaufwand und die Fehleranfälligkeit wächst mit zunehmender Netzwerkgeschwindigkeit enorm. Greif hier bei 10G auf SFP+ und Kabel mit Glaskern oder bei höheren Geschwindigkeiten auf den entsprechenden genormten Standard zurück. 


    Kind regards, Flo




    Montag, 13. Juni 2016 14:56
  • ...

    Leistungsmässig sind alle equivalent. Es kommt auf eure "Umstände" an. FC ist vergleichweise komplex und teuer für kleine Umgebungen. Da würde ich es bei zwei Hosts nicht in Erwägung ziehen. 

    Bleiben noch SMB 3.x und iSCSI. Den vollen SMB 3.x Umfang bietet aktuell nur Windows Server. Da ihr hier mit Updates und Downtimes rechnen müsst, braucht ihr entweder eine redundante Scale out Fileserver Lösung (was wiederrum etwas teurer wird) oder ihr müsst mir regelmässigen Downtimes für Updates leben. 

    Wo aus logischer sich dann nur noch iSCSI übrig bleibt. Hier gibts es schon gute Hardware zu vernünftigen Preisen z.B. Dell Equalogic oder NetApp. Zudem könnt ihr die 10G Basis von iSCSI nutzen um z.B. nach Release von Windows Server 2016 auf Storage Spaces Direct zu gehen und damit später vielleicht komplett von der SAN Infrastruktur wegzugehen. 

    ...

    Kind regards, Flo




    Da die Hardware auf 5 Jahre Lebenszeit berechnet ist, soll es nicht an 1.000 EUR mehr oder weniger scheitern (...bitte nicht falsch verstehen!). Mir geht es um eine performante und zuverlässige Verbindung innerhalb von Hostserver und SAN. Wenn sich dieses mit einer "Preiswerten" Lösung erzielen ließe, super!

    Was ich vermeiden möchte ist ein heimlicher Ressorcenfresser der mit "Protokoll -A- konvertiert auf Protokoll -B-" soviel Overhead erzeugt, dass der - vermeintliche - Geschwindigkeitsvorteil dahin ist. Das Aufstellen der Hardware, sowie die Erstinbetriebnahme lasse ich eh über ein Systemhaus abwickeln. Da man in der Regel dieses "Fundament" nicht ständig verändert, ist der dafür einmalig zu betreibende Aufwand nebensächlich.

    Alledings muss das System nach der Erstinbetriebnahme "easy to handle" sein. Speziell was die Verwaltung, Nutzung und Zuordnung des Festplattenspeichers im SAN angeht. Was mich wieder zur Kernfrage FC oder Kupfer bringt. ;-)

    Montag, 13. Juni 2016 15:46
  • Naja, was macht ihr denn jetzt mit vSphere? Das ist doch eigentlich der beste Ausgangspunkt für die Planung - Du kennst das Lastprofil, die I/Os, den Speicherbedarf usw. Auch hier müsste ja die Entscheidung für VMFS auf SAN oder NFS gefallen sein - ähnliche Argumente greifen auch bei Hyper-V. Wegen Updates hat Flo schon recht, andererseits würdet ihr auch bei nicht-redundantem SAN Downtime bekommen, wenn dieses Mal gepatcht werden muss. Was die Frage nach dem Übertragungsprotokoll angeht: Es ist in Deinem Szenario aus Performance-Sicht vermutlich egal, ob Du FC, SMB3 oder - ich lehne mich mal aus dem Fenster - iSCSI über 10 GB nimmst. Und auch hier würde ich Flo zustimmen - nimm 10GbE-basierte Technik (NICHT Kupfer!!!!), bist am Ende flexibler.

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 13. Juni 2016 17:17
  • 1. Zur Zeit verwalte ich eine VMware basierende Umgebung und verfüge über einiges Knowhow in dem Bereich vSphere. Meine Kenntnisse in Hyper-V sind grundlegender Natur. Aktuell habe ich einen Hyper-V 2012 R2 Testserver im Kernel Modus laufen und experimentiere darauf fleißig.

    2. In der Hyper-V Umgebung wird so einiges laufen:
    Terminal-Server 2012 R2 für 50 Anwender, Exchange-Server 2010, SQL-Server 2012, SQL-Server 2005, AD Domänen-Controller, Fileserver mit aktuell 3,8 Mio Dateien, CTI-Server, einige W7 Workstation für spezielle Anwendungen, sowie einige Server und W2008 R2 und W2012 für spezielle Applikationen (z.B. ERP-System). In Summe werden es etwa 20 bis 22 Maschinen sein. Das ganze "Zeuch" ;-) läuft derzeit unter der VMware völlig Stressfrei. Leider sind wir aus strategischen Gründen gezwungen auf Hyper-V umzusteigen. Das bedeudet ebenfalls, einen Großteil der VMware VM zu Hyper-V zu konvertieren.

    Hi Peter,

    wie schon geschrieben, gibt es keine exakte Vorgabe für Deine Umgebung, aber Du hast einen riesen Vorteil gegenüber anderen Planern, Du kannst den aktuellen Workload messen! Miss beispielsweise die IoPS, Du hast die derzeitige Hardwareauslastung plus zukünftige Anforderungen.

    Ich persönlich sehe kein "Leider" bei Hyper-V. Es ist ein stabiler Hypervisor mit genauso vielen interessanten Features. Aber auch hier gibt es kein: Was ist besser? Hyper-V oder VMware. Hyper-V bietet interessante Disaster Recovery Möglichkeiten auch beispielsweise hin zu Azure.

    Wenn Du noch etwas Zeit mit der Planung und Umsetzung hast, kann es sich lohnen auf Windows Server 2016 zu warten, da auch hier Verbesserungen bei Hyper-V passieren.

    Im SMB Bereich kann auch die Nutzung von SMB Direct und RDMA NICs in Betracht gezogen werden. SMB bietet den Vorteil einer nativen Betriebssystemunterstützung und Features wie SMB Multichannel etc.

    Gruß,
    Marcel

    https://www.windowspro.de/marcel-kueppers

    I write here only in private interest

    Disclaimer: This posting is provided AS IS with no warranties or guarantees, and confers no rights.

    Dienstag, 14. Juni 2016 07:02
  • Zum Thema Hyper-V, SMB3 und SoFS vllt ein interessantes White paper:

    Achieving Over 1-Million IOPS from Hyper-V VMs in a Scale-Out File Server Cluster Using Windows Server 2012 R2

    https://www.windowspro.de/marcel-kueppers

    I write here only in private interest

    Disclaimer: This posting is provided AS IS with no warranties or guarantees, and confers no rights.

    Dienstag, 14. Juni 2016 08:39
  • Moin,

    ich werfe mal etwas ganz anderes in die Runde:

    Wenn es nur zwei Hyper-V Nodes werden sollen und kein Wachstum angedacht ist, würde ich auch über ein einfaches shared SAS Enclosure nachdenken.

    Kostet im Vergleich zum SAN deutlich weniger in der Anschaffung und im Betrieb.


    This posting is provided AS IS with no warranties.

    Dienstag, 14. Juni 2016 10:56
  • Moin Grant, 

    hatte ich auch schon kurz anklingen lassen. Problem ist hier eventuell der Support und die Qualität des SAS Arrays. Hab da noch keine guten Erfahrungen gemacht. :/ Ist aber auch Geschmackssache. 


    Kind regards, Flo

    Dienstag, 14. Juni 2016 12:50
  • Naja, aber gibt es denn inzwischen eine Lösung, die offiziell für Windows Failover Clustering zertifiziert ist? Das letzte Mal, dass ich geguckt habe (zugegeben, Jahre her ;-) ) war das noch nicht der Fall... Und funktioniert hat es nur solange kein Failover erfolgen sollte.

    Außerdem war das Geld für den TO nicht der primäre Bewertungsfaktor, sondern die Performance, auch die nur in der Signalkette. Und da er gewillt war, 10GbE SMB3/iSCSI mit 16Gb FC zu vergleichen, sehe ich hier bei 6Gb SAS ein Vergleichbarkeitsproblem...

    Eins wäre für SAS allerdings zu sagen: Es wäre in diesem Fall WIRKLICH KUPFER! ;-)


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 14. Juni 2016 13:17
  • Von DataOnStorage gibt es 12G SAS Enclosures, die für 2012 R2 zertifiziert sind.

    Über 10Gb iSCSI vs. 16Gb FC (vs. 12G SAS vs. 10Gb SMB3) zu diskutieren lohnt sich ohnehin erst, wenn man dahinter ein Disk/SSD Array betreibt, welches den möglichen Durchsatz auch bedienen kann.

    Geht es nur um den Transport zwischen Storage und Server und werden alle anderen Faktoren ausgeblendet, gewinnt natürlich das Prtotokoll mit der höchsten Bandbreite und dem geringsten Overhead, also 16Gb FC in diesem Fall. Für praxisrelevant halte ich so einen Ansatz jedoch nicht.


    This posting is provided AS IS with no warranties.

    Mittwoch, 15. Juni 2016 04:39
  • Letztendlich spielt die Skalierung in Zukunft eine Rolle.

    Eine Idee wäre beispielsweise auch, Windows Server 2016 mit Storage Spaces Direct und 3 Knoten mirrored zu betreiben. Interner Festspeicher wäre dann auch über SATA unterstützt oder unterschiedliche Tiers mit SSDs zusammen. So wäre man für die Zukunft über 3 Knoten breiter aufgestellt und könnte Compute und Storage hyperconverged auf einer Node fahren inkl. SMB3 :)

    https://www.windowspro.de/marcel-kueppers

    I write here only in private interest

    Disclaimer: This posting is provided AS IS with no warranties or guarantees, and confers no rights.

    Mittwoch, 15. Juni 2016 06:38
  • An dieser Stelle ersteinmal meinen Dank an alle Poster! :-)

    Aus all Euren Anmerkungen und Ratschlägen habe ich folgende Basics in die Hostserver <> SAN Struktur übernommen.

    1. Hostserver und SAN werden via FC - direct attached und redundant - angeschlossen.
    2. Die Hostserver untereinander werden an 2 FC- / "Kupfer"Switch  - redundant - angeschlossen.
    3. Im SAN werden entweder 15k SAS Platten eingesetzt, alternativ SAS- und / SSD-Technologie. Best case - ein SSD-SAN. ;-) Die Angebote werden es zeigen und bei zu großer Preisdifferenz wird das Pendel zur SAS Technologie ausschlagen

    Windows HyperV Server 2016 werden ich voerst nicht einsetzen, da das Produkt erst im Juli 16 final Release erscheint. Auf dieses "frische" Produkt möchte ich ungern unsere absolut zuverlässige VMware Umgebung abbilden.

    Bei weiteren Anmerkungen und Anregungen - einfach posten...

    Viele Grüße
    Peter Duwenhögger

    Montag, 20. Juni 2016 17:29