Sziasztok!
Két otthoni/hobby rendszeren nézem a kliens hálózat sebességeket és nem túl jó eredményeket mérek.
Az egyik egy Ryzen 1700X-es processzoros asztali gép, rajta Ubuntu 1804 server, rajta VirtualBox headless. A másik egy Athlon X4-es processzor, rajta egy frissen telepített Proxmox. A kettő egy switchen keresztül össze van kötve 10G hálózattal. A méréshez iperf3-at használok, de a cél, hogy a SMB fájlmegosztás legyen gyors. Guest operációs rendszernek Windowst szeretnék használni.
Ha a host gépeken mérem a sebességet, akkor 9 Gbits/sec feletti eredményket mérek mindkét irányban.
Ha a Proxmoxon csinálok egy ubuntu konténert, akkor az is ilyen gyors.
Ha a Proxmoxon csinálok egy Windows 10 virtuális gépet, az csak 3,3 GBits/sec kifelé és 2,2 GBits/sec befelé. Ezt már úgy tudtam elérni, hogy telepítettem a virtio drivereket, előtte 1 Gigabit és alatti sebességeket mértem.
Proxmoxon egy ubuntu virtuális gép 7,6 kifelé és 8,0 befelé (ez már teljesen jó lenne).
A Ryzenes gépen VirtualBox allatt is hasonló dolgokat mérek Windowson:
Windows 10 guest: 3,5/2,4 (Itt nem igazán van különbség, hogy a virtio vagy másik drivert használok.
Ubuntu guest: 3,9/2,5
Van valami ötlet arra, hogy hogyan lehetne felgyorsítani a Windows guest gép hálózatát?
Hozzászólások
Szia
Virtualizált körtnyezetben a CPU (szoftveres) végzi a hálózati forgalom feldolgozását - ezért lassabb mint a fizikai.
Ha 10G duplex teljesítmény kell, akkor a virtuális gépnek közvetlen oda kell adni egy hardveres 10G kártyát.
Megoldás: "PCI-Passthrough" -nak hívják, ehhez viszont hardveres támogatás szükséges a HOST gép/szerver alaplap+CPU -tól:
- intel_iommu
- amd_iommu
Tehát szükséged lesz még egy fizikai 10G kártyára a Proxmox gép/szerver -hez.
https://pve.proxmox.com/wiki/Pci_passthrough
majdnem teljesen így van, de SR-IOV esetén (természetesen olyan NIC-el ami ezt támogatja) lehetőséged van virtual function-nek nevezett "klónokat" létrehozni, amik úgy PCI azonosítót is kapnak, ezt is átadhatod PCI Passthruval.
Annyi előnye van, hogy ebből ugye több is lehet (azaz több VM-nek is kiadhatod uazt a kártyát, vagy akár VLAN-okkal is variálhatsz, ha jól értelmeztem)
Kitaláltam egy megoldást, amihez nem kell iommu/sr-iov sem :)
Szükség van 1db - 2 portos 10G kártyára, ezt önmagával összekötjük.
Szükség van 1db - X portos 10G kártyára ez az uplink.
nic1 port-1: eth1 (észak)
nic1 port-2: eth2 (dél)
nic2 port-1: eth3 (uplink)
Létrehozzuk a trunk-t:
$> ovs-vsctl add-br brtrunk
$> ovs-vsctl add-port brtrunk eth1
$> ovs-vsctl add-port brtrunk eth2
Létrehozzuk a kimenő hálózatot (uplink)
$> ovs-vsctl add-br bruplink
$> ovs-vsctl add-port bruplink eth3
VM és az uplink közé létrehozzuk a kapcsolatot a következőképp:
->VM bridge: vmbr1000
->VM interface: tap1000i0
$> ip link add link eth1 name eth1.1000 type vlan id 1000
$> ip link add link eth2 name eth2.1000 type vlan id 1000
$> ovs-vsctl add-port vmbr1000 eth2.1000
$> ovs-vsctl add-port bruplink eth1.1000
Következőképpen fog kinézni:
vmbr1000
-tap1000i0
-eth2.1000
brtrunk
-eth1
-eth2
bruplink
-eth3
-eth1.1000
Lényegében a fizikai (loopback) kártyán megjáratjuk a forgalmat - így nem a CPU fog dolgozni, hanem a hálókártya ASIC/SOC-ja, így közel 10G duplex sebesség elérhető.
Legjobban 4portos NIC-kártya esetén működhetne, mert akkor uplink is ugyan azon menne át.
Mennyire működik, azt tesztelni kellene.
ezt inkább rajzold le, mert így nem bírom megérteni :-)
Tessék:
https://drive.google.com/file/d/1WQSqgqeWLPra0OkoDoBGP0ivGjeC7NAL/view?…
Nagyon jók az ábrák, de szerintem a szűk keresztmetszet a VM-ből kilépéskor van (a VM-1000 eth1-es és a TAP10000 között), így szerintem ez nem segítene.
Az a virtio-interfész ami összeköti a HOST tap-intefészét a Guest eth1-csatolóval.
Pl.: Amit 1G duplex hálókártyának ír a Guest OS, valóságban lehet sokkal több mint 1G duplex.
Onnantól már az OS/Hardver dolga, hogy ki tudja-e nyomni rendesen a sávszélességet.
az az eth1-eth2 kivul ossze van kotve, akkor miert kell berakni a brtrunk-ba?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Logikailag is össze kell kötni, egy Layer-2 linket hozunk létre vele ha így érthetőbb.
Ezt úgy kell elképzelni, mint amikor 2db switchet összekötsz 1 kábellel, a port trunk módba van, ilyenkor minden vlan átmegy rajta.
hm. hogy' sikerült a virtuális gépnél 7,6-8gbps sebességet elérni? pont ezzel sz.pok, bár debiannal
Az IOMMU-t megnéztem, sajnos az Athlon II X4-es chipsetem nem támogatja, a Ryzenesben egy B350-es chipset van, az elvileg tudja, de nem túl jó teszteket olvastam róla, meg az az "éles" gépem, azt nem szeretném széttúrni. Mindenesetre átgondolom, mert az Athlonos gép csak egy teszt, ha működik, akkor vásárolok valami modernebb cuccot és ott már lehet erre figyelni.
Megpróbáltam egy Windows Servert húzni az Athlonos vasra, ott elsőre nagyon rossz hálózati sebesség jött ki, de egy kis állítgatással sikerült feltornásznom 8,4-6,9 Gigabit/sec-re, ami már egészen jó, de azért meg sem közelíti a varsa telepített ubuntu 9,4-9,4-ét. Most még telepítek egy ubuntu servert és egy Windows 10-et HyperV alá, hogy ott is megmérjem a sebességeket, de rossz érzésem van, mert már több mint két órája megy a Win10 telepítés ...
@wpeople Az ubuntu virtuális gépen minden trükk nélkül ment a 7,6-8, simán amit találtam letöltött ISO-t (ubuntu server 1804.1 live) telepítettem, virtio hálókártyával a Proxmox-on és működött. Virtual box alatt sokkal rosszabbat mérek a sokkal jobb gépen.
Na közben elkészültek a Hyper-V gépek, a Windows 10-es 2,4 Gigbit/sec-el küld és 1,1 -el fogad, az Ubuntu 1804 pedig 5-el küld és 1,3-al fogad. Nem a Hyper-V lesz a megoldás, hanem valamelyik HW virtualizációs dolog.
milyen érdekes, hogy pl Mikrotik CHR esetén -állítólag- magasan a Hyper-V hozza a legjobb számokat...
(hallottam rá olyan magyarázatot, hogy a ProxMox és VmWare az működött, a Hyper-V -hez meg hozzá kellett fejleszteni a Mikrotik-nek, és hát így sikerült :-)
Lehet, hogy igazi szerver HW-en másképpen alakulnak a dolgok, ott talán jobban odafigyelnek rá, hogy ezek működjenek.
Még egy kérdés:
Az SR-IOV-hez szükség van a IOMMU-ra is?
Elvileg a Mellanox ConnectX-2 kártyám az tudja az SR-IOV-t, de az alaplap nem az IOMMU-t.
Az SR-IOV-hez 3 csillag együttállása szükséges:
NIC
Alaplap
OS
Még egy adag mérési eredmény, hogy mennyire gyors a virtio. Megmértem két, egy host gépen lévő virtuális gép egymás közötti sebességét és a host és a virtuális gép közötti sebességet. Ilyenkor a külső kártya nem számít, a belső bridge meg a virtuális gép és a host közötti adatátadás játszik.
A proxmox gépen, ami jóval gyengébb mint a Virtual boxos:
Két ubuntu guest között: 4,8 Giga mindkét irányba
Ubuntu guest és host között: 7,7/ 6,7
Két windows 10 gép között: 0,9/0,9 (Mondjuk ezek nagyon leterhelték ezt a kis gépet)
Win 10 és host között: 3,5/2,5
Hoston loop0-n: 12,6 G
A Virtbox gépen:
Két ubuntu guest között: 2,5/2,5
Ubuntu guest és host között: 2,8/7,4 (7,4 a kimenő a virtuális gépből)
Win10 guestek között: 0,8/1,9 (hogy miért nem szimmetrikus azt nem tudom)
Win10 és host között: 2,1/7,6
Hoston loop0: 53,2 Giga
Ebből nekem eddigi az a konklúzió, hogy linuxoknál a Proxmox sokkal jobb mint a VirtualBox, de a korábbi mérések alapján, ha LXC-t tudok használni, az még jobb.
Windows gépeknél tovább kell tesztelni, mert nem tudom, hogy a különbség abból adódik-e hogy a VirtBoxos gép sokkal erősebb vagy abból, hogy a Virtbox maga jobb-e.
Mindenesetre ilyen vitrualizációs környezetben, ha a hálózati teljesítmény kritikus, akkor a Windows nem tűnik egy jó választásnak.