Virtuelle Maschinen mit schnellerem LAN als Host ausstatten

PHuV

Banned
Registriert
März 2005
Beiträge
14.219
Ganz blöde Frage, warum kann mit Hypervisoren wie Hyper-V, VMWare und XenServer für die VMs keine virtuellen Netzwerkadapter erstellen, die schneller laufen als der Host-Adapter?

Rein praktisch ist es ja meines Wissens nach so, daß ein Host mit einer oder mehreren Netzwerkkarten mit 1GBbit/s für alle anderen zur Verfügung stellt, die dann mit einem virtuellen TCP-Adapter nur auf diesem LAN aufsetzen. Rein theoretisch könnte man doch auch virtuelle Adapter schaffen, die nicht über das Host-LAN gehen, sondern eben nur virtuell vom Hypervisor erstellt wird.

Hintergrund meiner Frage: Ich will auf einem XenServer Host einen Netzwerk-Cluster (Cloudera, Hadoop) erstellen, der mit seiner Netzwerklast nicht das Hostssystem belastet, wo noch einige anderen VMs laufen, die im laufenden Betrieb nötig sind. Leider stehen mir keine anderen Kapazitäten zur Verfügung, weil nur diese Maschine über genügend RAM, CPU und neuerdings eine NVMe als Massenspeicher zur Verfügung. Dazu würde ich einen Proxy oder Jumphost erstellen, der über Netzwerk normal erreichbar ist, und alle anderen Knoten sollten nur noch über das "interne" Netzwerk, am besten 10GBit, kommunizieren.

Falls das nicht gehen sollte, würde es ausreichen, einen 10GBit-Adapater einzubauen, der nicht mit den Netzwerk verbunden ist, aber über den dann alle Knoten miteinander reden könnten? Hier könnten ich ja dann eine billige Karte mit SFP nehmen, da sie eh nicht verwendet wird.
 
wenn du den host adapter deaktivierst, heisst das dann, dass du garkeinen virtuellen adapter erstellen kannst?
 
Also unter Hyper-V geht das definitiv, gerade getestet. Selbst wenn du einen vSwitch mit Anbindung an die NIC erstellst (= externes Netzwerk) sind die VMs mit 10 GBit/s angebunden. Bei meinem Test mit iperf habe ich gerade Übertragungsraten von 3.9 GBit/s bekommen, für mehr ist die CPU wahrscheinlich einfach zu schwach, aber es sind deutlich mehr als die 1 Gbit NIC an die der vSwitch hängt

Ich denke mit XenServer geht das auch bestimmt irgendwie. Hast du vielleicht SR-IOV aktiviert? Das leitet den Traffic ja direkt auf die NIC und das könnte in dem Fall dann ausbremsen. Alternativ kannst du bei Xen doch bestimmt auch ein internes Netzwerk erstellen, dann bekommen deine VMs das interne und nur dein Proxy intern + extern. Der muss dann eben als Gateway fungieren
 
@d4nY

Richtig, im Hyper-V geht das.
Ich betreue auch Cluster wo die Hosts "nur" physische Gbit Schnittstellen haben, die VMs am Virtuellen Switch haben aber immer 10Gbit.
 
Super, vielen Dank für die Antworten. Das wäre ja wirklich ein Grund, nach Hyper-V zu migrieren. Wir wollen eh unternehmensweit weg von Xen.
d4nY schrieb:
Ich denke mit XenServer geht das auch bestimmt irgendwie. Hast du vielleicht SR-IOV aktiviert? Das leitet den Traffic ja direkt auf die NIC und das könnte in dem Fall dann ausbremsen. Alternativ kannst du bei Xen doch bestimmt auch ein internes Netzwerk erstellen, dann bekommen deine VMs das interne und nur dein Proxy intern + extern. Der muss dann eben als Gateway fungieren
Das ist ein sehr guter Hinweis, das werde ich am Dienstag gleich mal prüfen, vielen Dank.

Update: Laut Info für XenCenter sieht es wohl so aus:
https://support.citrix.com/article/CTX126624
To make use of this capability, you must have a host server in which a SR-IOV capable network device is installed. The device tested for this article is the Intel 82599 10 Gigabit Ethernet Controller.

Note: The setup procedure requires that the 10 GigE NIC not be used as the management interface for the host. A second physical NIC must be installed on the system for that purpose.
Ich brauchte also wirklich ein entsprechendes Interface, um dieses Feature nutzen zu können, mal sehen, ob das im BIOS des Servers auftaucht.
 
Zuletzt bearbeitet:
Die VMs haben dann aber nur 10GBit bei der Kommunikation untereinander, für den Verkehr nach/von "außen" macht es durchaus Sinn 10Gig Karten zu besorgen. Ob RJ45 oder SFP+ Karten hängt von der entsprechenden Switch-Infrastruktur ab.
 
Achtung Theoretiker:

Sollten paravirtualisierte Interfaces nicht beliebige Geschwindigkeiten zwischen den Gästen erlauben? Zumindest sollte das einzige Limit an der Stelle die CPU sein, da jedwede physikalische Einschränkung des Netzwerkgerätes ja bei der Kommunikation der Gäste untereinander auf einem gemeinsamem Host überhaupt keine Rolle spielt.
Jedwede künstliche Einschränkung, die die Geschwindigkeit auf 1GB/s oder 10GB/s beschränken würde, wäre an der Stelle ja rein künstlich und würde deutlich mehr CPU Zyklen fressen als einfach durchzureichen was gerade an Daten da ist.
 
Zuletzt bearbeitet:
@Pikto:

Prinzipiell stimmt das schon, dass paravirtualisierte NICs einzig durch die CPU beschränkt sind (sofern eben so Sachen wie SR-IOV aktiv sind). Problem ist nur folgendes, bei Ethernet hat man ja nur vergleichsweise Große Schritt 100 MBit -> 1 GBit -> 10 Gbit -> 40 GBit (wenn überhaupt für Ethernet) -> 100 GBit
Und schon bei 10 GBit sieht man, dass die CPU alleine zu langsam dafür ist. Microsoft hat da mal nen schönen Artikel zu SR-IOV geschrieben, da wird z.B. dargestellt, dass eine vNIC nur gute 4 GBit/s übertragen kann, weil die CPU im Host dann zu langsam wird (da nur ein Core für die Datenverarbeitung genutzt wird/werden kann). Auf der physikalischen Seite hat man das Problem ja nicht, weil die NIC ja zig Warteschlange und Hardware-Offloading hat, deswegen sind da die 10 GBit/s kein Problem. Kernpunkt des Artikels war dann auch, dass man mit SR-IOV (dass der VM ermöglicht direkt auf die NIC-Hardware zugreifen zu können) auch volle 10 GBit/s in der VM bekommen kann. Das geht mit VMQ bspw. nicht (ich schau mal ob ich den Artikel noch finde, der war auch relativ aktuell, sprich Windows Server 2012 R2)

Anscheinend sind momentan einfach die einzelnen Cores noch zu langsam (zumindest die im Serverumfeld, wo man sich ja idR eher bei um die 2,5 bis 3 GHz bewegt)
 
Das die CPU eher früher als später winzelnd am Boden liegt ist mir klar, aber es ist doch ein mehrfaches von den 1GBit/s erreichbar, was der TE ja beklagt. Das Ganze dann zu optimieren scheint dann wirklich ein weites Feld zu sein bei dem es viele, recht komplexe Paper und Leitfäden gibt. Da kann man sicher noch Optimieren und ganz nebenbei noch Guru vom Netzwerkstack seines Lieblingsbetriebssystem werden.
 
Zurück
Oben