Hyper-V SMB Netzwerkkommunikation Frage

[CoolAce 17]

Hallo zusammen,

 

ich möchte bei einem Kunden ein 2 Node Hyper-V Cluster auf SMB3.0 migrieren. Es kommen Windows Server 2012 R2 mit allen Patchen zu Einsatz und ein geeigneter Storage.

Eine Frage hierzu, ich hab ein eigenes VLAN gebaut was rein für die SMB Kommunikation zuständig ist und müsste jetzt den SMB Datenverkehr dahin vom restlichen Datenverkehr

trennen.

 

Hierzu hab ich ein Team aus 2 mal 1 GBit NIC gebaut und würde das über den Befehl 

New-SmbMultichannelConstraint -ServerName "HyperVStorage" -InterfaceAlias "NICSMB1", "NICSMB2""

machen.

 

Ist das richtig oder habe ich hier was falsch verstanden, denn nach meinem Verständnis müsste damit der komplette SMB Traffic und nur dieser hierein fallen und getrennt

von LiveMigration und sonstigem sein.

 

Gruß

 

Coolace

[NilsK 2.958]

Moin,

 

ich möchte bei einem Kunden ein 2 Node Hyper-V Cluster auf SMB3.0 migrieren.

 

hm. Warum? Was ist das Ziel, was sind die Anforderungen?

 

Allgemein werden die Vorteile von SMB 3.x oft über-, dafür die Voraussetzungen unterschätzt. In mittelständischen Umgebungen spricht m.E. nur selten etwas für SMB 3.x.

 

Es kommen Windows Server 2012 R2 mit allen Patchen zu Einsatz und ein geeigneter Storage.

 

Was ist denn das "geeignete Storage"? Kann das wirklich SMB 3.x? Bietet es in dem Betrieb irgendwelche Vorteile gegenüber iSCSI oder FC? Beherrscht es auch die Funktionen, die SMB 3.x interessant machen? Das tun die meisten Nicht-Windows-Storages m.W. nämlich nicht.

 

Eine Frage hierzu, ich hab ein eigenes VLAN gebaut was rein für die SMB Kommunikation zuständig ist und müsste jetzt den SMB Datenverkehr dahin vom restlichen Datenverkehr

trennen.

 

Hierzu hab ich ein Team aus 2 mal 1 GBit NIC gebaut und würde das über den Befehl 

New-SmbMultichannelConstraint -ServerName "HyperVStorage" -InterfaceAlias "NICSMB1", "NICSMB2""

machen.

 

Das ist jetzt arg rudimentär. Ohne Details über den physischen Netzwerkaufbau, die VLANs und das Teaming zu wissen, kann man dazu wenig Sinnvolles sagen. Spontan würde ich mal sagen, dass sich SMB Multichannel und Teaming eher widersprechen. Außerdem finde ich zweimal 1 Gbit für VM-Storage arg wenig.

 

Zunächst wären aber wohl die obigen Grundsatzfragen zu klären.

 

Gruß, Nils

[CoolAce 17]

Danke für deine Unterstützung.

Das Ziel ist das alte Storage System abzulösen und das neue in Betrieb zu nehmen aus dem EMC Familie und das kann SMB3.0 mit Hyper-V.

Mein Ziel ist es denn gesamten Netzwerkverkehr nach BestPractice zu trennen, daher mein Plan wie folgt

 

VLAN 10: 10.1.0.0 für den Hyper-V Server zur Verwaltung

VLAN 20: 10.2.0.0 für den vSwitch   (10G Adapter)

VLAN 50: 10.2.0.0 für die LiveMigration (10G Adapter)

VLAN 90: 10.3.0.0 für SMB Kommunikation zwischen Hyper-V und Storage

eigener Switch: Cluster Heartbeat.

 

Ich hänge gerade an dem Punkt wie man das mit VLAN 90 hinbekommt und und wieviel Datenverkehr unter SMB Kommunikation läuft

 

Gruß

 

Coolace

[NilsK 2.958]

Moin,

 

wie ist denn das Netzwerk aufgebaut? Gigabit? 10 GbE?

Wie sind die Hosts angebunden - tatsächlich nur mit 2x1 GbE?

 

Zu "Best Practices" würde gehören:

• 10 GbE mindestens einfach redundant
• Converged Networking auf Host-Ebene, d.h. ein Team über alle NICs, Trennung des Verkehrs über VLANs, vNICs und Bandbreitenregeln
• exakte Zuweisung des Traffics

VLAN 10: 10.1.0.0 für den Hyper-V Server zur Verwaltung

VLAN 20: 10.2.0.0 für den vSwitch   (10G Adapter)

VLAN 50: 10.2.0.0 für die LiveMigration (10G Adapter)

VLAN 90: 10.3.0.0 für SMB Kommunikation zwischen Hyper-V und Storage

eigener Switch: Cluster Heartbeat.

 

• "Verwaltung des Hosts" bedeutet: Kontakt zum AD und WSUS, normalerweise ist das das "normale" LAN.
• "für den vSwitch" gibt es kein VLAN und kein IP-Segment - das ist ein Layer-2-Switch. Vermutlich ist hier das Segment für die VMs gemeint - was typischerweise auch das "normale" LAN ist.
• Live MIgration - OK, kann man separat machen, aber hier braucht man in kleinen und mittleren Umgebungen keine Höchstleistung - die sollen ja die VMs haben. Wie oft verschiebt man denn VMs? ... eben
• Storage: Hier wird es interessant. Eigenes VLAN und eigenes IP-Segment ist schon korrekt. Wenn in genau dem VLAN und dem IP-Segment auch das Storage hängt, dann solte das eigentlich schon passen.
• "Cluster Heartbeat" - warum ein eigener Switch?

Dass aktuelle Storage-Systeme SMB 3.x nominell unterstützen, ist schon klar. Interessant wird SMB 3.x aber eigentlich erst mit den Funktionen, die der Windows-SoFS bereitstellt, und das kann m.W. kein Storage-Anbieter so wie Windows selbst.

 

Gruß, Nils

bearbeitet 4. Januar 2017 von NilsK

[NorbertFe 2.066]

•"Cluster Heartbeat" - warum ein eigener Switch?

 

Wäre nicht der erste Kunde, der mit einem Stackupdate mal eben den Cluster runterfallen läßt. ;)

[CoolAce 17]

Vielen Dank für die ausführliche Beschreibung und deine Unterstützung.

Das Netzwerk hat sowohl 10G als 1G Module am Core Switch.  Jeder der 2 Server hat 2 mal 10G Adapter drin und ist entsprechend an den Switch angeschlossen.  

Die exakte Zuweisung des Traffic ist mein Ziel.

 

• "Verwaltung des Hosts" bedeutet: Kontakt zum AD und WSUS, normalerweise ist das das "normale" LAN. --> habe ich so umgesetzt, in dem Fall gibt es ein eigenes Server -VLAN
• "für den vSwitch" gibt es kein VLAN und kein IP-Segment - das ist ein Layer-2-Switch. Vermutlich ist hier das Segment für die VMs gemeint - was typischerweise auch das "normale" LAN ist --> ist auch das Server-VLAN
• Storage: Hier wird es interessant. Eigenes VLAN und eigenes IP-Segment ist schon korrekt. Wenn in genau dem VLAN und dem IP-Segment auch das Storage hängt, dann solte das eigentlich schon passen. --> hier ist mein Problem wie viel Traffic läuft da zwischen Storage und Hyper-V Host für die SMB Kommunikation (reicht 1G oder 4 G LACP ) ? Wo stelle ich es ein das eben nur der SMB Traffic hier reinläuft ? In dem Segment hängt auch der Storage mit drin

Da denke ich hast du vollkommen Recht was Storage-Systeme und SMB 3.x angeht aber die EMC ist nun im Haus.

 

Gruß

 

Coolace

@•"Cluster Heartbeat" - warum ein eigener Switch? --> der war schon da und es läuft ja nur der Ping für den Cluster drüber

[NilsK 2.958]

Moin,

 

äh ... mir scheinen da doch ein paar Missverständnisse vorzuliegen.

• Wenn die ersten beiden Netzwerke, die du nennst, beide im Server-VLAN arbeiten sollen - warum siehst du dann getrennte VLANs und getrennte IP-Segmente vor?
• Storage wird den höchsten Traffic überhaupt erzeugen. Natürlich wirst du mit 1 GbE dort nicht glücklich werden. Da würde ich von einem 2x10-GbE-Team durchaus eine Reservierung von 50 Prozent sehen.
• Wenn dein Storage-Netz exklusiv ist, reicht es doch völlig aus, dass das Storage über ein eigenes IP-Segment angesprochen wird. Dann kann dort kein anderer Traffic laufen. Du willst in dem Netz kein Routing usw. haben, also richtest du auch keins ein.

 

•"Cluster Heartbeat" - warum ein eigener Switch?

Wäre nicht der erste Kunde, der mit einem Stackupdate mal eben den Cluster runterfallen läßt.

 

Wenn das der Grund ist, ist das okay und sinnvoll. Angesichts der anderen Missverständnisse wollte ich aber mal nachhaken. ;)

 

Gruß, Nils

[NorbertFe 2.066]

Wird leider zu oft vergessen, dass ein Stack afaik immer in Gesamtheit durchatmet, wenn man ihn aktualisieren muss.

[magheinz 110]

Gibt es einen zweiten Cluster-heartbeat oder ist der nicht redundant? Falls nicht braucht meiner Meinung nach der Rest auch nicht redundant sein da im Fall eines Switchausfalles sowieso ein Problem besteht!

[NilsK 2.958]

Moin,

 

das ist letztlich eine Frage von Design und Operating ... du hast schon Recht, dass bei Ausfall des "Hauptswitches" die Funktionen des Clusters (= die VMs) ohnehin nicht zur Verfügung stehen. Dann nützt der separate Heartbeat nichts und kann sich u.U. sogar negativ auswirken (einzige Netzwerkverbindung wäre der Heartbeat, alles andere ist tot - das kann einen Cluster durchaus zusätzlich verwirren).

 

Schon weil die VMs in dem Fall ihr Storage verlieren, wird man vor einem geplanten Ausfall des Switches (Firmware-Updates z.B.) alle VMs herunterfahren wollen. Das ist dann eine Operating-Frage.

 

Was den Cluster-Heartbeat selbst angeht: Den kann man ohne weiteren Hardware-Aufwand redundant machen, weil man dafür mehrere Netzwerke zuweisen kann. So könnte man den SPOF umgehen, den der separate Switch darstellen würde. (Wenn man den denn haben will.)

 

Gruß, Nils

bearbeitet 4. Januar 2017 von NilsK

[CoolAce 17]

Ja, ich muss zugeben in dem Punkt hab ich glaub ich im Moment noch ein Verständnisproblem im Kopf

 

• Wenn die ersten beiden Netzwerke, die du nennst, beide im Server-VLAN arbeiten sollen - warum siehst du dann getrennte VLANs und getrennte IP-Segmente vor? --> Mein Verstädnis nach ist ja 

          der eine 10G Adapter im VLAN20, nach meinem Verständnis binde ich an den Adapter den vSwitch, über den vSwitch fließt der komplette Traffic zwischen den Clients und den VMs sprich z.B. ein

          User will einen Druckauftrag abschicken dann geht er über diesen Weg.

       

       Jetzt brauch ich noch einen 10G Adapater mit z.B. der IP 10.3.0.1 der muss nach meinem Verständnis, kann auch falsch sein, ins VLAN 90, dort sollte die Kommunikation laufen zu den VMs die ja

      als Pfad in der vhd \\storage\vms\printserver\printserver.vhdx haben. Hier muss ich ja, falls ich nicht auf dem Holzweg bin, dem Node mitteilen das er für die Kommunikation den Adapter nimmt aber wie?

 

Gruß

 

Coolace  

[NilsK 2.958]

Moin,

 

ich versteh deine Darstellung nicht ganz, aber mir scheint da noch ein grundlegendes Missverständnis der Netzwerke in Hyper-V vorzuliegen.

 

Das Grundsetup würde ich so machen:

• Je Host beide NICs zu einem Team zusammenbinden.
• Die Netzwerkkabel kommen an "tagged" Ports. Die VLAN-Zuweisung geschieht über Hyper-V, nicht über den Switch.
• An dieses Team wird der vSwitch gebunden.
• Für jedes Host-Netzwerk wird eine vNIC erzeugt, das muss per PowerShell geschehen. Diese vNICs bekommen ihr VLAN-Tag und die Bandbreitenreservierung.
• Die IP-Adressen für die Host-Netzwerke werden in die zugehörigen vNICs eingetragen.
• Die VMs bekommen ganz normal ihre vNICs, je nach Bedarf mit VLAN-Tag oder ohne.

Wenn die VMs dann ihr Storage über einen UNC-Pfad finden, muss der Servername dort auf die IP-Adresse auflösen, die der Host eben nur über seine Storage-vNIC erreicht. Die IP-Segmente müssen also so eindeutig sein, dass der Host nicht auf die Idee kommt, den Traffic in eins seiner anderen Netzwerke zu routen.

 

Gruß, Nils

[Dunkelmann 96]

Moin,

 

ich häng mich mal mit rein.

Ich würde kein SMB3 für einen kleinen zwei Node Cluster nutzen. Erst recht nicht, wenn keine Windows Headserver genutzt werden.

 

Ein paar Punkte, die bedacht werden sollten:

• Der Aufwand, eine SMB3 Infrastruktur in Betrieb zu nehmen, ist im Vergleich zu FC oder iSCSI deutlich größer. In der Zeit, die der Thread schon läuft, würde der Cluster längt mit FC/iSCSI fliegen  ;) 
• Ist die Umgebung so dynamisch, dass SMB3 Speicher per converged Networking im Vergleich zu einer dedizierten FC/iSCSI Fabric wirklich einen Mehrwert liefert?
• Unterstützt die Backuplösung SMB3 (auch in Kombination mit SMB3 über die EMC)?
• Unterstützt das Storage alle benötigten SMB3 Features. Bspw. RDMAoE, shared vhdx?

[NilsK 2.958]

Moin,

 

ziehen wir die Frage doch mal andersrum auf: Das Storage kann ja mit Sicherheit auch iSCSI. Wie wäre es, darauf umzusteigen?

 

Gruß, Nils

[CoolAce 17]

Hallo zusammen,

 

vielen Dank für eure Mühe mir zu helfen und mich aufzuklären. Das Storage kann auch bezüglich Backup die SMB3.0 Logik unterstüzten, das habe ich bereits überprüft.

Das stimmt, via iSCSI, wäre ich vermutlich schon fertig aber auch nur weil ich das schon X-Mal gemacht habe, das selbe würde denk ich auch für SMB3.0 gelten sobald sich

meine Verständnisprobleme komplett gelöst haben.

 

Die FC Struktur wurde abgeschafft beim Kunden, erstens war Sie extrem alt und das notwendige KnowHow ist beim Kunden nicht vorhanden und die Anschaffung einer neuen FC

Struktur ist nicht unbedingt günstig was das Thema FC Switche und Co angeht.

 

Mein bisheriges Verständnis nach dachte ich das ich auf dem Adapter einfach die IP setze und auf dem SwitchPort VLAN 90, da ich zum einbinden der .vhd ja dann als ziel 10.3.0.2

angebe weiß der Hyper-V Server Routingtechnisch das er diesen Adapter nutzen soll oder lieg ich da komplett falsche ?

 

 

Die elegantere Lösung ist das converged Networking