Virtualizált routerek

Fórumok

Sziasztok,

Routert virtualizálnék. Ha lehet, Mikrotik-et :-)

ProxMox-al próbálkozok, de sajnos komoly limitbe ütközök: ~5gbps-nél nem nagyon akar gyorsabban menni a hálózat két VM, vagy VM és fizikai port között.

A tesztasztalon van 2 mikrotik amik egymás között ~8.5gbps átvitelt produkálnak btest-el, UDP-n.

Ha linuxon (hypervizor szinten) route-olok v bridge-elek, akkor uez a sebesség.
Ha a gépben lévő dual 10G portjait bridge-elem a VM interface-eihez, akkor ~5gbps a sebesség, attól függetlenül, h a VM az linux, ROS chr, v ROS x86
kivéve, ha SR-IOV virtual function-en átadom a kártyát a VM-nek. Akkor mint hypervizor layeren: ~8.5gbps

Sajnálatos módon a Mikrotik ROS nem ismeri az SR-IOV virt.interface-t. Én meg a linux alatti FRR routingot...

Valakinek tipp esetleg? Mit kéne/lehet tuningolni?

Hozzászólások

nincs nagy meglepetes hogy az SRIOV mukodik megfeleloen: a tobbit elveszted a sok szoftver retegben. sokan megenekeltek mar ezt. egy UDP stream (mint ahogy egy TCP stream) ennyit tud ebben a felallasban. ha tobb streamet tolsz gondolom kijon a 8.5GBps a VMben is.

 

az frr nem az ordogtol valo, mi hasznaljuk elesben. ha most epitenek valamit, en biztos SRIOV + kedvenc disztrib friss kernellel + frr kore epitenem.

Nyilván nem azon lepődök meg, hogy SR-IOV-van működik, hanem azon, hogy a többin nem :-)

Nem, 20-50 stream esetén sem vidámabb az eredmény...
Persze, nem ördögtől való. OSPF-re használom a Quagga-t (és az FRR elvileg quagga fork - inkább a BGP filterek online klikkelős kezelhetősége miatt örvendenék a Mikrotik-nek)

Szerkesztve: 2020. 05. 19., k - 00:43

Igyvan, sajna ennyit tudnak a paravirtualizalt network interfaceek... Aztan meg maga a routeolas is viszi az eroforrast, hardveres tamogatas nelkul...

Első körben azt feltételeztem, hogy a linux bridge-ben van valami limitáció, de kipróbáltam: abban nincs.

Hypervisor szinten route-olva a NIC 2 lába között 10G forgalmat - szinte meg sem látszik a terhelés.
Egy full view esetén a route-ok beillesztése számolása kb egy teljes magot elvinne - de ezzel sincs gond, mert van belőle bőven.

Általánosságban ez ennyit tud, mert a guest szintről több mem copy-val kerül le a csomag a kártyáig/másik vm-ig.

Erre pár éve a "zerocopy" (pl. vhost-user) volt a megoldás, míg hw irányba a dpdk. Ez egyben egy ovs-dpdk + pmd -vel megugorható (van hátránya is), de a proxmox mintha nem támogatná. Mostanában a AF_XDP + eBPF megoldásokról lehet sokat hallani, de az még ovs szinten is experimental. Sajnos konkrét tapasztalatom nincs ezekkel, csak távolról láttam ezen megoldásokat.

És akkor még a VM-en belüli routing performanciájáról nem is beszéltünk...

Kipróbálhatod még ezt: https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

Sosem próbáltam, viszont ez VPP (FD.io, DPDK alapú) dataplane + FRR routing és elvileg elég gyors. AF_XDP itt szerintem egyelőre felejtős, iszonyat sok meló lenne benne bármit értelmesen implementálni benne, jelenleg pedig nem ismerek semmit ami működne. Sima XDP eBPF kódból elérni a routing táblát fib helperekkel, így működhet interfészek közti redirect FRR által bekonfigolt route szabályok alapján, viszont erről sem láttam semmi kész szofvert a kernel forrásban lévő sample alkalmazáson kívül.

A DPDK saját KNI-je elég lassú, amit az AF_XDP PMD segít, viszont az meg hardver felé lassabb mint a "default" DPDK. Ellenben 10Gbps tartományt mindkettő képes kiszolgálni. Elméletileg egy OVS-nek csak egy kapcsoló, hogy AF_XDP vagy XDP módban fusson így külön támogatás Proxmox felől (bár sosem használtam) nem hiszem hogy kellene.

Viszont: 8.5Gbps SRIOV-n az bármilyen más virtualizáció mellett sem lenne sokkal több 5Gbps-től, legalábbis nekem ebből az jön le hogy maga a hypervisor a bottleneck.

SR-IOV + PCI Passthrough megoldással a gond, hogy a VM nem live migrálható, bár igaz routert nem is biztos, hogy kell.

Megnéztem az ovs-dpdk csomag szintjén megjelent a proxmox 6.2-ben, de a vhost-user támogatás még nincs benne, így nem fog menni gányolás nélkül.

Esetleg nézd meg az újonnan bevezetett SDN (ffr-re épül)  támogatást - bár még beta - amivel a routolást a host szintjére le tudod vinni. Igaz ez nem oldja meg a VM network performancia problémát.

Ez utóbbit fogom 1-2 hónapon belül tesztelni (bgp-evpn+vxlan), igaz a routing switchen fog megtörténni.

De ha találsz bármi jó megoldást, kérlek oszd meg, mert engem is érdekel. :)

A proxmox nodeokon a VTEP, VNI, stbket a beépített SDN megoldására bízom (a VM-ek miatt ez a célszerű). Ebbe meg lehet adni external nodokat/gw-ket ami pedig a két fizikai switch lenne. Ez utóbbit talán neutonnal hajtanám meg és később esetleg lehet neutron db->proxmox szinkront, vagy minimalista ml2 drivert hegeszteni hozzá.

De ez egy kis rendszer (5 node), így akár az is lehet, hogy egy egyszerű előredefiniált ip rangek kerülnek vrfbe a switcheken, míg a nodeok felé csak szimpla VLAN. Vagy a másik irány, hogy csak a proxmox SDN-je lesz használva és az L3 routing is ott történik. Szóval megnézem mit lehet kihozni ebből, úgy hogy ne bonyolítsam túl...

Nem teljesen ez a tema, de nekem is van gondom a virtualis routerrel/tuzfallal (OPNSense) 1 Gigabit-es netet routolok, de a CPU-t teljesen felzabalja (Persze ez home server, egy i3-as procival) Ha tudtok valami eroforraskimelo route trukkot OPNsense alatt, azt megkoszonom :)

Fogadni merek, hogy PPPOE-t használsz a WAN oldalon :)

Erre nem találtam megoldást én se, csak kerülőmegoldás van.

A probléma hogy a FreeBSD PPPOE program (mpd) csak 1x CPU (1-szál)-t képes használni, tehát hiába adsz hozzá CPU magot a VM-hez, nem növekszik a teljesítmény.
Linux-hoz van (rp-pppoe) program, ami több CPU/több szálat képes használni, tehát ott elméletileg több cpu mag kis terhelése mellett képes a teljes WAN sávszélességet kihasználni.

Kerülőmegoldás, hogy a FreeBSD (pfsense) előtt termináljuk a PPPOE-t, utána sima ethernet kapcsolattal adjuk át a FreeBSD (pfsense)-nek.

Megoldások:
-Virtualizáció (pl.: VyOS): Ebbe rp-pppoe van alapból, és van HA, szép CLI de nincs GUI. (félig fizetős, nightly-build ingyenes)
-Hardveres Router: 1G PPPOE nehéz probléma, ehhez kb. Cisco ASR1000 típusú eszközre van szükség, ami ki is tudja hajtani a sávszélességet.
-Egyéb: Létezik ilyen?

Igen, nem PPPOE WAN, de a szolgáltatónál csak az van :)

Szerkesztve: 2020. 05. 19., k - 14:06

Egy másik topikban IOMMU/SR-IOV megoldás helyett írtam egy alternatív megoldásról:

https://hup.hu/comment/2481876#comment-2481876

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.

 

Akinek van ideje/hardvere azt tesztelhetné :)