2K12R2 Cluster NIC/VLAN Konfig

[henryy 11]

Hallo,

 

ich arbeite an einem Projekt mit zwei HP Hosts( 4x 10GB NICs, 4x 1GB NICs) welche über zwei gestapelte Switche HP2920 angebunden sind. Ich würde jertzt gerne LBFO bei der NIC konfiguration nutzen.

 

Grundlegende Idee ist :

• 2x10GB als Team für die VMs
• 2x1GB als Team für die Cluster Komunikation
• 2x1GB als Team fürs Management

Serverseitig würde ich das Teaming(ohne HP Tools) im OS konfigurieren

• 3 Teams erstellen. Dort dann die IPs vergeben(3 unterschiedliche Netze,172...für csv,192..für VMs,10..für Live Migration)
• LACP(switchabhängig), dynamsich, alle Adapter aktiv

Switchseitig:

• Die betreffenden Ports auf lacp activ konfigurieren

Bis hierhin funktioniert es auch. Die Komunikatuion (ping) läuft auch weiter, wenn ein Switch ausfällt.

 

Mein Problem fängt bei den VLANs an. Normalerweise bräuchte ich ja mindestens zwei VLANs. 1x für CSV, 1x für Livemigration. Die VMs könnten im Default "VLAN" verweilen

 

Frage1: Ist es überhaupt notwendig das ich VLANs einsetze und wenn ja wo mache ich die am besten? Im switch als portbasiertes VLANs oder über Server 2012 im NIC teaming?

Frage2: Ist die Teamkonfig mit LACP, dynamisch in Ordnung oder gibt es andere Empfehlungen?

 

P.S Sobald ich VLANs auf 2012 OS Ebene in den Teams erstelle funktioniert kein Ping mehr.

 

Danke und Gruß

 

 

 

[DocData 85]

Als CCNA sollte man wissen, dass wenn der Host Frames mit VLAN Informationen sendet (und das tut er, wenn du VLANs im OS konfigurierst), die Switchports im Trunk-Mode laufen müssen.

 

Hinsichtlich deiner verwendeten Subnetze würde ich mich auf eine Netzklasse festlegen und unterschiedliche Subnetze verwenden, wobei ich jedes Subnetz einem VLAN zuordnen würde.

[Doso 77]

VLANs in den VMs konfiguriert man an den VMs: http://blogs.technet.com/b/keithmayer/archive/2012/11/20/vlan-tricks-with-nic-teaming-in-windows-server-2012.aspx

[Dunkelmann 96]

Moin,

 

1. Seit Server 2012 sind Teams und VLAN empfohlen (vorher lief es auch schon, nur nicht von MS 'supported').
   Du kannst natürlich auch ausreichend physische NICs in den Server stopfen und auf VLAN verzichten.
2. LACP dynamisch ist ok. Hängt aber auch vom Switch ab

ich würde mir gut überlegen, ob ich an meinen Switchports für VMs das native VLAN erlaube. (Suchbegriff 'tagging the native VLAN') ;)

 

Auf Hostseite könntest Du Team-Interfaces mit native und taged VLAN nutzen.

http://blogs.technet.com/b/keithmayer/archive/2013/04/04/build-a-private-cloud-foundation-networking.aspx

[henryy 11]

Moin,

 

danke für die Antworten und Links.

 

Mir geht es in erster Linie erstmal um das separieren des CSV, Live Migartions und VM traffic(alle virtuellen server). Es geht mir noch nicht um das aufteilen oder abgrenzen des Traffics einzelner VMs.

 

Wie und wo trenne ich am einfachsten CSV,Live Migration Traffic vom VM Traffic (beides hängt ja an den gleichen Switchen) oder ist das gar nicht nötig weil die unterschiedlichen Subnetze dafür schon ausreichen? Für jedes dieser Netze sind seperate NICs in den Servern vorhanden. Dort sind sie  "getrennt" durch die NICs und unterschiedliche Subnetze.

 

Sind da VLANs noch nötig?

[Dunkelmann 96]

Mir geht es in erster Linie erstmal um das separieren des CSV, Live Migartions und VM traffic(alle virtuellen server). Es geht mir noch nicht um das aufteilen oder abgrenzen des Traffics einzelner VMs.

 

Wie und wo trenne ich am einfachsten CSV,Live Migration Traffic vom VM Traffic (beides hängt ja an den gleichen Switchen) oder ist das gar nicht nötig weil die unterschiedlichen Subnetze dafür schon ausreichen? Für jedes dieser Netze sind seperate NICs in den Servern vorhanden. Dort sind sie  "getrennt" durch die NICs und unterschiedliche Subnetze.

 

Sind da VLANs noch nötig?

Ja

 

Broadcast-Domain? http://de.wikipedia.org/wiki/Broadcast-Dom%C3%A4ne

OSI Modell? http://de.wikipedia.org/wiki/OSI-Modell

[henryy 11]

Moin,

 

ja Layer 2 Broadcast ist ein Grund. Um es erstmal simpel zu halten  werde ich für CSV und LM ein Port basiertes VLAN machen. Scheint mir etwas einfacher für eventuelle Fehlersuche als ein tagged VLAN