Hyper-V und verschiedene Subnetze

[kosta88 2]

Hallo,

 

Gleich voraus: bin zum Thema Netzwerk noch sehr "grün". Also:

 

Gibt es Gründe warum man ein oder mehrere Hyper-V Server in ein anderes Subnet legen würde?

 

zB. unser Firmenserver hat 4 NICs. Da habe ich bereits eine HauptNIC deklariert, die ist quasi die Hauptverbindung für den Server. Sagen wir halt das ist Netz-11.

D.h. mir bleiben 3 NIC für Hyper-V, was super ist, aber irgendwie sehe ich (noch) keine wirklichen Vorteile.

 

Das einzige was mir so einfällt ist wegen der Firewall Konfiguration. Man kann dann die Server gruppieren, zwecks einfacheren Verwaltung. Weil sonst kann ich die Zugriffe von und auf die Server via Objekte und IPs im Firewall managen. Es werden eventuell 10 HV Server insgesamt wenn alles fertig ist.

 

Die Clients sind wohl in einem anderen Netzwerk, und da werden die Zugriffe grundsätzlich nur auf der Client-Ebene erlaubt.

 

Ich kann natürlich detailliert erklären was in die Umgebung Serverbezogen kommen wird, aber fangen wir mal mit der Frage oben.

 

Besten Dank.

Kosta

[NilsK 2.785]

Moin,

 

vor allem musst du die Netzwerkkonfiguration des Hosts von der der VMs getrennt betrachten. Die haben nichts miteinander zu tun.

 

Als Einstieg empfehle ich:

 

[Hyper-V und Netzwerke | faq-o-matic.net]
http://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/

 

Oder noch ausführlicher in meinem Buch. ;)

 

Bei 4 NICs könnte man die Netzwerkkarten auf einem alleinstehenden Host logisch so aufteilen:

• 1. Karte Management für den Host - hieran wird dann kein vSwitch gebunden
• 2. - 4. Karte: Ein Team bilden, einen vSwitch daran binden, über diesen vSwitch kommen die VMs ins Netz

Nutzen: Für die VMs stehen nominell 3 GBit zur Verfügung (bei Gigabit-Ethernet). Das Host-Management ist davon getrennt.

 

Wenn die VMs auf physisch getrennte Subnetze zugreifen sollen, müssen im Host auch Karten für jedes der Segmente vorgesehen werden. Diese müssen dann physisch bzw. per VLAN in diesen Netzen sein. Dann könnte man es so machen:

• 1. Karte Management für den Host - hieran wird dann kein vSwitch gebunden
• 2. Karte LAN1, vSwitch für LAN1, hieran kommen die VM-NICs, die auf LAN1 zugreifen sollen
• 3. Karte LAN2, vSwitch für LAN2, hieran kommen die VM-NICs, die auf LAN2 zugreifen sollen
• 4. Karte LAN3, vSwitch für LAN3, hieran kommen die VM-NICs, die auf LAN3 zugreifen sollen

Dies könnte man aber auch mit dem ersten Modell machen, indem man an den vSwitch die VM-NICs bindet und dort dann die VLAN-IDs setzt. Dann müssen die drei Ports natürlich auf alle benötigten VLANs zugreifen können.

 

Ist nicht ganz einfach, vor allem weil das GUI so unübersichtlich ist.

 

In einem Host-Cluster sieht es grundsätzlich anders aus, weil du dort auch physische Netze für den Cluster und für das Storage brauchst. Da wären 4 NICs dann eigentlich zuwenig; man könnte es aber so machen:

• 1. Karte Management
• 2. Karte Cluster
• 3. Karte Storage
• 4. Karte VM-LAN; nur hier wird ein vSwitch erzeugt

Hierbei gäbe es aber keine Redundanz auf Netzwerkebene. Das wiederum könnte man in dem Fall mit einem Team über alle Karten sowie mit VLANs und Bandbreitenreservierungen erreichen. Das ginge aber über das hinaus, was man in einem Forum sinnvoll beschreiben kann.

 

Gruß, Nils

[kosta88 2]

Hallo Nils,

 

Danke dir für eine super Antwort! Dass man Host und VM trennen muss/soll, habe ich nicht gewusst.

Das Netzwerk in der Firma in die ich vor relativ kurzen Zeit reingekommen bin wurde von mehreren "Admins" gestückelt und administriert, wenn man das so überhaupt nennen darf.

Jetzt soll ich das neu machen. Ich weiss, wie gesagt, bin noch relativ grün hinter die Ohren, aber ganz grün auch wieder nicht. Schaffen tue ich es auf jeden Fall, brauche nur ordentliche Planung und muss wissen warum ich was mache. Deswegen die Frage oben.

 

Derzeit sind am HW-Server 4 NICs, und sogar die Haupt-NIC, also Host-NIC mit einem vSwitch versehen und dort wurde die IP konfiguriert. Warum, darfst du mich nicht fragen :)

 

Das ganze hat derzeit soweit ich sehen kann, 2 Subnetze, und diese sind wie folgt:

- das Schulungsnetz, vSwitch IP bezogen via DHCP (nicht fixiert, aus welche Grund auch immer), bekomme zugewiesen Netz 192.168.12.x - dort sitzt unser RDSH (der ist aber auch im Subnet 12, aber fixe IP), an dem sich 10 Notebooks per RDP verbinden (die IPs von die Notebooks habe ich noch nicht, aber soweit ich weiss, die gehen per DHCP). Ist wie schon das Wort sagt, für unseren Schulungen (Firmenintern und extern) gedacht. Hier sind noch zwei Rechner drinnen, interner Server für was anderes und ein VM Client zum testen, beide 192.168.12.x

- das Hauptnetz - vSwitch an einer anderen NIC, hat fixe IP 192.168.13.x - das ist auch gleichzeitig auch die Hauptverbindung des Servers, aber am vSwitch. Hier hängt auch eine VM für Admin Zwecke, dort ist ein Teamviewer eingerichtet, mit dem man von aussen ins Netz kommt. Schaut quasi wie ein Poor-Mans-VPN... dieser Admin Rechner ist dagegen in 192.168.14.x.

 

Die richtige Einrichtung aus meiner Sicht wäre VPN in den Router anstatt von Teamviewer, Host in zB. 192.168.11.x und alle anderen VMs in 192.168.12.x. Mehr ist gar nicht notwendig. Im Firewall kann man dann die VMs (bzw. Netz 192.168.12.x) als "Server-Farm" deklarieren für einfachere Handhabung, somit egal welche VM man erstellt, ist sie automatisch für gewisse Freigaben freigegeben. Und dann spezifische Zugriffe für die einzelnen Rechner.

Wie schon vorher gefragt, ich sehe kaum Bedarf nach getrennten Netzen für verschiedene VMs, ledigliche verschiedene IPs bzw. Firewall-Objekte, ist wohl klar.

 

Ich bedanke mich für das Artikel, bin halbwegs durch mit Lesen, nun bin ich noch immer mit einer halboffener Frage von vorher, warum und ob man die VMs in diverse Subnetze platzieren sollte? Ob welche Vorteile gibt? Habe ich die Antwort vielleicht übersehen?

 

Ah, und übrigens, NIC Teaming scheint auf dem Server nicht unterstüzt zu sein. Wenn ich auf Konfigurieren gehe, habe ich kein Tab mit Teaming. Vielleicht liegt's am Treiber, es sind Broadcom NICs am HP Proliant Server.

 

Besten Dank.

Kosta

bearbeitet 17. Mai 2014 von kosta88

[Doso 77]

Teaming und HyperV sollte man erst ab Server2012 machen. Vorher ist das unsupported und klappt entsprechend nicht so wirklich gut da man auf die Software des Herstellers zurückgreifen muss.

[NilsK 2.785]

Moin,

 

von welchem Betriebssystem reden wir überhaupt? Wenn 2012 oder 2012 R2, dann lege ich dir wirklich (m)ein Buch ans Herz.

 

Du hast das typische Missverständnis, dass der vSwitch eine IP-Adresse hätte. Hat er nicht. Kein Switch hat eine IP-Adresse, auch ein physischer nicht. (Höchstens dessen Management-Interface hat eine, aber eben nicht der Switch als solcher.) Was du dort siehst bzw. was du meinst, ist eine virtuelle Netzwerkkarte, die im Host (genauer: im Management OS bzw. in der Parent Partition) erzeugt wurde und die an den vSwitch angeschlossen ist. Dadurch hat der Host eine Verbindung zu dem betreffenden Netzwerk. Ob er die braucht, kann ich von außen nicht beurteilen, das ist eine Frage eures Netzwerkdesigns.

 

Da ich die Anforderungen eures Netzwerks und das Netzwerk-Design nicht kenne, kann ich auch zu deiner VLAN-Frage nichts sagen. Man kann das so machen, man muss es aber nicht.

 

@Doso: Es ist richtig, dass NIC-Teaming vor 2012 von Microsoft nicht unterstützt ist. Deshalb muss man aber noch lange nicht davon abraten. Wenn man es richtig macht, klappt es hervorragend (und ist auch unter 2008/R2 durchaus von Microsoft empfohlen, nur supporten die es eben nicht selbst).

In jedem Fall richtet man das Teaming ein, bevor man Hyper-V einrichtet und die vSwitches erzeugt. Vor 2012 kommt es sonst zu gravierenden Fehlern. Ob es die auch in 2012/R2 gibt, ist mir gerade nicht geläufig, aber ich würde es auch dort nicht ohne Weiteres nachträglich einrichten.

 

Gruß, Nils

bearbeitet 17. Mai 2014 von NilsK

[kosta88 2]

Maine Güte, du hast recht. Klar hat der switch selber keine ip bzw. nur eine für die Verwaltung. Wie dumm von mir...

 

Es handelt sich um 2008R2. Und ein Buch fürs Kindle von Sams habe ich mir auch gekauft, allerdings 2012, da wir sicher früher oder später auf 2012 oder Nachfolger setzen werden, somit fange ich gleich mit der aktuellen Version.

 

Ich werde nachsehen ob Teaming durch HP möglich ist, aber zur Zeit würde ich eher sehen wie ich das Netzwerk ohne dem organisiere. Ein DC kommt in Frage und noch so paar andere VMs, damit wir eine ordentliche Struktur haben.

 

Das einzig sinnvolle was ich sehe ist die Netzwerke wegen Last zu trennen, obwohl so viel Last kommt nicht hin, ich glaube es wird nichtmal eine GB Leitung ausgereizt. Ohne ein Netzwerk Diagramm zu posten kann ich schwer alles erklären. Und dieses ist noch nicht ganz bereit...