OpenStack + SRIOV tapasztalatok és tanuló konfiguráció

 ( SPYFF | 2018. június 21., csütörtök - 11:39 )

Idén január közepétől május végéig volt szerencsém szétnézni az IBM Zürichi kutatólaboratóriumában. Egy itteni, HUP-os blogposztomat látta meg NagyZ és ajánlotta fel ezt a lehetőséget, én pedig éltem vele. Lentebb pár személyes élmény és az IBM-nél szerzett tapasztalataim leírása következik.

Néhány levélváltás és telefonos egyeztetés után megkaptam a szerződést, aláírtam, scannelve visszaküldtem, ezek után jött meg csomagban az érvényes szerződés egy másolata. Ez azért volt nagyon fontos, mert később már Svájcban minden hivatalos ügyintézésnél tudtam rá hivatkozni: vízum igénylésnél, bankszámla létrehozásnál, lakhely bejelentésnél, egészségbiztosítás megkötésekor, stb.
Az IBM kutatólaborja Zürich kanton Rüschlikon városában van, sikerült itt albérletet találnom, így 10 perc sétára voltam csak tőle. Egyébként ez egy kis város, nagyjából 5000 fős, így túl sok dolog nincs itt, viszont Zürich nagyjából fél órányira van busszal vagy vonattal így ez nem jelent semmilyen problémát. Első látásra a hely olyasmi, mint egy nagy autószalon, új autók mindenfelé, sétáló embereket nem is nagyon látni, aki csak tud Volvo XC90-ben, M5 BMW-ben vagy Porschéban ül. Aki sétálni vagy futni akar annak egyébként is ott az erdő a város szélén, nekem nagyjából 5 perc sétára volt így elég sokat futottam benne.
A svájciakkal kapcsolatos sztereotípiákat én is meg tudom erősíteni. Legtömörebben (lehet egyben leghülyébben is) úgy tudnám leírni az egészet, hogy kevésbé jellemző az emberekre az entrópia felesleges növelése. A hivatalos ügyekben nem tapasztaltam túlszabályozást, ahogy fentebb írtam, a szerződéssel nyíltak a kapuk, pár telefonnal és minimális személyes megjelenéssel mindent el tudtam intézni, sokszor ímélben elküldött scannelt dokumentum is elég volt. Nagyjából ennyi amit egyelőre meg tudok említeni, ha bármi eszembe jut majd bővítem a posztot.

Szakmai oldalról nagyon sok izgalmas dolog volt amit kipróbálhattam. NagyZ csapata a labort kiszolgáló infrastruktúráért felelős. Itt is bőven van lehetőség kutatni és kísérletezni új dolgokkal, meg a legújabb technológiák adaptációja is folyamatos. Elég nehéz volt felvennem a tempót, mert a hálózati ismereteim sajnos eléggé behatároltak, az SDN/NFV vonal teljesen új volt. Azt beszéltük meg, hogy olyasmivel foglalkozzak, amiből a legtöbbet tanulok és ha ez a cégnek is hasznos az még jobb. Így az SRIOV implementálásra esett a választás. Fontos megemlíteni, hogy ez egy folyamatosan használt infrastruktúra és bár mindig implementálva vannak a legújabb technológiák, legfrissebb hardveres megoldások, viszont nincs idő mindent kipróbálni – ilyen például az SRIOV is – és itt jöttem én a képbe.

Maga az SRIOV a Single-Root IO Virtualization rövidítése. Bármilyen PCIe síntechnológiát használó eszköz implementálhatja és fizikai erőforrások (PF) mellé virtuális erőforrásokat (VF – virtual function) hozhat létre. Például egy hálózati kártyánál ha két fizikai portja van, mellé beállíthatunk még virtuális portokat, ezek már korlátozott konfigurációs lehetőségekkel rendelkeznek. Az előnyük, hogy nagyon gyorsak: méréseim alapján natív sebességen használhatóak. Léteznek a technológiát támogató videókártyák is viszont ezekkel nem kísérleteztem.
Szinte minden virtualizációs megoldás (QEMU/KVM, Xen, VMWare vagy VirtualBox) támogatja jó ideje a PCI passthrough technológiát, aminek a lényege, hogy a host operációs rendszer PCI eszközéhez közvetlen hozzáférést adunk a guest oprendszer számára. Itt lesz értelme az SRIOV virtuális eszközeinek: egy hoston futó guest rendszerek megkaphatják a VF-eket így a host továbbra is használhatja a fizikai eszközt, egyik guest sem kap kizárólagos hozzáférést hozzá. Ez különösen kapóra jön a hálózati kártyánál, ahol egy 100Gbps sebességre képes NIC-en egyszerre 10 guest is forgalmazhat 10Gbps sebességgel! Alternatíva erre a virtio, amikor nincs a guestnek közvetlen hozzáférése a hálózati kártyához, hanem folyik egy kommunikáció a guest és a host között, majd a host külön írja a saját buffereit küldéshez és olvassa fogadáshoz. Persze ez sokkal CPU igényesebb: még egy erős Xeon processzornál is 25-30Gbps maximális throughputot mértem két különböző szerveren futó virtuális gép között – hiába volt közöttük 100Gbps az összeköttetés. A CPU idő egyszerűen elmegy az I/O-ra. Előnye, hogy ezt a forgalmat viszont tudjuk tunnelezni (VXLAN vagy GRE) a hoston valamint tűzfalas szűréseket is alkalmazhatunk a VM-ek közötti forgalomra. Sajnos nem a sebesség az egyetlen hátránya a virtio-nak: a kommunikáció a gépek között nagyrészt RDMA-n keresztül folyik. Ez virtio-n keresztül lehetetlen, így a VM-ek nem képesek egymást közt RDMA kommunikációra, pedig ez egy nagyon jó dolog – CPU-t kímélő kommunikáció VM-ek között. Méréseim alapján egy 1 magos CPU-t használó VM képes a másik fizikai hoston lévő társával 98Gbps sebességgel kommunikálni RDMA-n keresztül top szerint minimális (2-5%) CPU használattal.
Azzal kezdtem a dolgot, hogy a laptopomon összeállítottam egy egyszerű OpenStack környezetet, kísérletezni. Azért ezzel, mert az infrastruktúra alapját ez adja a laborban. Itt NagyZ tanácsait követve lépésről lépésre haladva raktam fel a különböző moduljait az OpenStack-nek. Elsőként PackStack-el és DevStack-el próbálkoztam, sajnos ezekkel voltak gondjaim, annak ellenére, hogy ezek direkt leegyszerűsített telepítőkészletek OpenStack-hez. Így maradt a függőségről-függőségre és modulról-modulra való telepítés, külön a control és a compute nodeokat. Először gondjaim voltak ezzel az elnevezéssel, később letisztult a dolog, a control nodeon fut a legtöbb szolgáltatás és adatbázis, amiben tárolva vannak az egyes compute nodeokon elérhető erőforrások: szabad CPU magok száma, elérhető tárterület, stb. Így amikor új VM-et indítunk OpenStack-ben, akkor a control node megpróbálja megtalálni neki a legjobb compute nodeot. Laptopon ez a része trükkös volt, mert nested vertualization-t kellett használni, hiszen a compute nodejaim eleve QEMU virtuális gépek voltak ezeken ismét futott a QEMU, de már az OpenStacké, ami itt képes volt VM-eket indítani.
Miután nagyjából felállt a laptopomon a cucc (1 controller és 2 compute node), következett egy jó kis torna, amit nem nem nagyon tudnék részletesen leírni, a lényeg, hogy az OpenStack alap L2Pop drivere helyett BGP és EVPN teremti meg a kapcsolatot a virtuális gépek között. A konfig itt FRR-el történt (Quagga fork, lényegében Cisco szerű router CLI GNU/Linuxra). Egyes VXLAN-ok unnumbered BGP-vel lesznek behirdetve. Sajnos később SRIOV-nél már másképp van a VXLAN, ott nincs a kényelmes szoftveres tunnel kapcsolat, de egyes kártyák támogatják, hogy már maga a NIC végzi el a csomagolást (a frameket amiket küldene UDP-s VXLAN-be enkapszulálja).

Mikor nagyjából működött a laptopomon a tesztkörnyezet, kaptam nyolc fizikai gépet, közöttük 100Gbps switch kapcsolattal. Itt egy picit gyorsabban ment már az OpenStack feltelepítése, a virtuális gépeken nagyjából 4 hétbe tellett, itt talán egy pár nap volt mire felállt a konfig. Ez nem jelenti, hogy nem voltak hibák menet közben, lényegében az utolsó napig találtam hibákat. Sok esetben módosítás nélkül, másnap belogolva a gépekre már nem működött amit előző nap még működőképes állapotban hagytam ott.
Itt már Mellanox hálózati kártyák voltak, sikerült rajtuk VF-eket létrehoznom, ez után pedig lehetett szórakozni azzal, hogy az OpenStack tudjon valamit kezdeni velük. Szerencsére elég régóta van SRIOV támogatás OpenStack-ben, viszont ennek a doksija körülbelül akkor frissült utoljára, mikor a feature bekerült, sajnos azóta több konfigurációs paraméter is változott, valamint van pár lépés ami mára már felesleges, vagy épp hiányzik belőle. Sajnos ezek troubleshootingja nekem nagyon sokáig tartott, néha nem triviális hibák miatt, meg sokszor figyelmetlenségből adódóan. Végül szerencsére összeállt a dolog és lassan működni kezdett. A végső állapotban az OpenStack felismerte a kártyákat és a VF-eket, így új virtuális gép indításakor alapértelmezett virtio emulált kártya helyett már VF-et adott a VM-nek mint NIC. Annyi kiegészítést csináltam még NagyZ javaslatára, hogy Horizon dashboard-on policy (user role) alapján eltüntethetővé tettem a hálózatválasztást, ilyenkor ha a felhasználó indítja a VM-et, ha úgy van a role-ja, nem választhat hálózatot, hanem az előre allokált VF poolból kap majd egy hálókártyát a gépe automatikusan.

Kiugró látványos eredmény én úgy gondolom nem született, ilyen lett volna egy sikeres SRIOV-s live-migration például, viszont ilyen 4-5 másodperc kieséssel migrálhatók a futó VM-ek a compute nodeok között, működő hálózattal (SRIOV és így az RDMA is megy). Live-migration egyébként is open issue nem csak QEMU/KVM-nél de amennyire láttam mindenütt. Készült viszont egy elég nagy doksi, ami alapján az éles környezetbe is deployolható a munka. Ez alapján tervezek pár patchet beküldeni javítva az SRIOV-s részét az OpenStack dokumentációnak. A munka nagy része azzal telt, hogy valamiféle halott levlistás thread, nyitott ticket vagy deprecated doksi/fórum leírás alapján kerestem ki egy adott problémára sok n nem működő közül az egy működő megoldást, vagy találtam ki magam, majd léptem a következő hibára, pörgetve a logokat és a tcpdumpolgatva hálózatot.
Bent az IBM-nél az én mércémmel mérve groteszk mennyiségű anyagi erőforrás áll rendelkezésre, bármire lehet húzni lapot, bármit ki lehet próbálni, elébb fogy el a hely a rack szekrényben a legújabb Power-es Titan GPU-s gépektől mint a pénz, nyugodtan tudtam én is kísérletezni. Ami biztos, hogy én rengeteget tanultam ez alatt a szűk öt hónap alatt. A tanultakat jelenleg közvetlenül tudom hasznosítani egy másik projekthez, amiről részletesebben fogok majd itt is írni, ha sikerül, továbbá ebből még pár kisebb blog/wiki bejegyzés is leágazhat majd (virtuális hálózatos kernel módosítgatás, eBPF és TCP teljesítmény tuning témában).

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szép :)

orulok, hogy sikerult sokat tanulni! :)

A részletes leírást, köszi, nagyon érdekes volt olvasni!

Viszont elszörnyedve kell megállapítsam, hogy az Openstack még mindig az a tákolt fostalicska, ami X éve emlékeimben él. A dokumentáció nem létezik, vagy egy rossz vicc. Erről az ugrik be, hogy vagy a BBC, vagy a British Telecom szopta be irtózatosan az Openstacket, elkezdték használni, de a folyamatos pátyolgatás miatt sokkal nagyobb az emberierőforrás-igénye, mint hitték.

POWER vasakkal is dolgoztál esetleg, nem Linux alatt?

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

mondj jobbat mint OpenStack.. :) ugy, hogy csomo mindenre van sajat megoldasunk alatta/belehekkelve, szerintem teljesen hasznalhato.

Kezdőként tényleg nagy figyelmet igényel, viszont ami a hátránya, az egyben az előnye is: szinte minden probléma előjött már valakinél és van rá valami megoldás. A leggyengébb része, amire elment kb. másfél hetem az az, hogy volt Horizonnak egy része, amit még 2016.-ban töröltek egy commitban mint deprecated kód (Pythonos Django-s rész) ehhez képest az a commit nem lett rendesen bemergelve és több ezer sor használaton kívüli kód ott van - ami engem nagyon félrevezetett.

POWER vasakkal nem jutott idő foglalkozni, viszont nemrég itt HUP-on láttam elég részletes cikket (lehet csak link volt egy Phoronix-es cikkre) amiben méregettek Epyc-Xeon-POWER konfigokat.

A Mellanox kártyákat milyen driverrel hajtottátok meg?
Saját fordított, vagy amit a disztro szállított? Utóbbi esetben milyen Linux disztribúciót használtatok?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

legujabb mellanoxos driverrel, forditva.

Működni amúgy működtek az Ubuntu Server 16.04 (4.4 kernel) default Mellanox driverei is, ha csak a VM-el használod őket (felpasszolva a VF-et a VM-nek) oda pont jók. A hoston viszont legújabb fordított driver futott. Cloud-init-el egyébként a guest VM-ekre is fel lehet könnyen rakni friss fordított drivert.

Köszi a választ.
Egy mostani rendszeremen 18.04 alatti default drivert használunk most, és nem vagyok megelégedve a performanciájával, ezért is érdekelt, hogy a fenti eredményt a disztro által adott "gyári" driverrel sikerült e elérni.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Kis update: Aki ezekből a kártyákból komolyabb teljesítményt is ki akar csikarni, az felejtse el a gyári Ubuntus (meg RH-s ha már ott tartunk) drivert.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

ez mondjuk alapvetes, en nem ismerek senkit aki a gyarival hasznalna :))

Sajna a helyzet nem ilyen egyszerű - a régebbi teszt rendszeren a gyári mellanox driver állandóan hard LOCKUP-ba rántotta a cpu core-(oka)t, és ez miatt az egész szerverünk beállt mint a gerely. Az új teszt rendszeren ez miatt eredetileg az Ubuntuban lévőt kezdtük el használni, mondván, hogy az hátha jobban ki van tesztelve.. Ott ez a probléma nem jelentkezett, viszont a performancia meg elégtelen volt.
Ez miatt most visszaváltottunk a gyári Mellanox driverre és reménykedtünk, hogy a latest verzióban ezt a problémát megoldották.. Ma sajnos ismét előjött a probléma, szóval ismét lehet szellemet vadászni..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

nyitni kell ticketet nekik.