blog :: skarware: Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė [2 dalis

Kartą jau apkalbėta pfSense kompiuterių tinklo užkardos sistema (žr. straipsnį "pfSense kompiuterių tinklo mazge"), turi labai stiprius maršrutizatoriaus bruožus, todėl neretai tinklo administratoriai ją pritaiko kaip pavienį perimetro (WAN) ar vidinio (LAN) tinklo maršrutizatorių. Vidutinio ir didesnio dydžio kompiuterių tinkluose, kurių jungtys sodriai prisotintos paketų srautu, tai atskiras tinklo mazgo vaidmuo pfSense sistemai.

Šioje straipsnio dalyje pateikta susistemintų testavimo duomenų vizualizacija diagramose, kai KVM hipervizoriaus sukurtų virtualiųjų mašinų tinklo sąsajos realizuojamos skirtingais būdais. Analizuojamas jų našumas tinklo mazgo pralaidumo, paketų delsos ir drebėjimo atžvilgiu, kai pfSense sistema veikia tik maršrutizatoriaus režimu {routing platform only} (paketų filtravimas išjungtas).

Tinklo mazgo pralaidumas

Dauguma Ethernet tinklinės įrangos gamintojų pristato savo produktų pralaidą {throughput} bitais per sekundę (pvz., 100 Mbps ar 1 Gbps), tačiau marketingo verčiami pamiršta nurodyti svarbią informaciją: prie kurio paketo dydžio ta pralaida pamatuota. Beveik visada ta pralaida pamatuota su didžiausias paketais, tačiau tai neatspindi realios įrenginio spartos.

Kompiuterių tinklo inžinieriai tinklo įrenginių pralaidą matuoja pirmiausiai kadrais/paketais per sekundę, ir bent keliems skirtingiems jų dydžiams, kurie padeda objektyviau įvertinti įtaiso spartą tinkle. Tokia įrenginio specifikacija ypač naudinga jei tinklo administratorius išanalizavęs prižiūrimą tinklo duomenų srautą ir žino tinkle vyraujančių paketų ilgių pasiskirstymą.

Neatsitiktinai ir šiame tiriamajame darbe pralaida pirmiausiai matuojama ir vertinama kadrų skaičiumi per sekunde (kps). Toks žvilgsnis į pfSense tinklo mazgo sistemą padės geriau įvertinti našumo pokyčius sukeltus visiškos virtualizacijos sluoksnio, ir skirtingų KVM VM tinklo sąsajų.

pfSense tik maršrutizatoriaus režimu: dvikryptis paketų apdorojimo skaičius per sekundę

Pralaidos stulpelinėje diagramoje vertikalioje ašyje žymimas suminis vienalaikis abiejų krypčių kadrų skaičius per sekundę tūkstančiais. Horizontalioje ašyje sužymėti skirtingų dydžių tinklo paketai. Keturių spalvų stulpeliai žymi skirtingas pfSense maršrutizatoriaus realizacijas.

Kaip ir buvo galima tikėtis, pfSense maršrutizuoja paketus sparčiausiai kai jai priskiriamos dedikuotos tinklo plokštės per IOMMU virtualizaciją ir paravirtualizuotas VirtIO tinklo sąsajos tvarkykles, kurios abi leidžia tiesioginę prieigą prie fizinių tinklo plokščių.

Gali nustebinti, bet testuose užfiksuotas ženklus pralaidos našumo skirtumas (apie 27 proc. mažesnis) tarp IOMMU dedikuotų tinklo plokščių ir tų pačių tinklo plokščių aparatinės įrangos (HW) atveju, kai pfSense maršrutizatorius apdoroja mažiausius tinklo kadro dydžius (64-256 baitų ilgio).

Iš diagramos matyti IOMMU dedikuotų tinklo plokščių maksimali 64-256 ilgio paketų apdorojimo riba – apie 470 tūkst. paketų per sekundę. pfSense sistemai veikiant betarpiškai virš aparatinės įrangos, su tomis panašiomis tinklo plokštėmis ir tvarkyklėmis, maksimali riba gerokai aukščiau – daugiau nei 600 tūkst. paketų per sekunde (to priežastis nagrinėjama prie pfSense sistemos procesoriaus vidutinės apkrovos diagramos).

VirtIO ir E1000 tinklo plokštės paketų pralaida išlieka gana stabili nepriklausomai nuo testuojamo paketo ilgio – maždaug 85 ir 32 tūkst. paketų per sekundę atitinkamai. To priežastis aparatinės įrangos spartos ribos, realizuojant programine įranga imituojamas tinklo sąsajas.

IOMMU kadrų pralaidumu prisiveja aparatinę įrangą ties 512 ilgio paketais; VirtIO paveja kai pfSense tinklo mazgas dirba su 1280 baitų paketais, o E1000 sąsaja nepriartėja ne perpus.

Taigi, įvertinus pfSense maršrutizatoriaus tinklo pralaidą kadrais per sekunde, galima į tą pačią pralaidą pažvelgti kitu kampu – bitais per sekundę. Kaip matyti kadrų ir bitų pralaidos paveiksluose vaizduojamų diagramų duomenys tarsi apsivertė. Tai gerai iliustruoja kaip įrenginio pralaidumas bitais priklauso nuo kadrų dydžio ir kaip maždaug vienodas kardų srautas per sekundę tarp visų paketo dydžių duoda skirtingą įrenginio greitaveiką bitais per sekunde (E1000 ir VirtIO atveju). Apačioje pralaidos diagramoje vaizduojama suminė vienalaikė dvikryptė greitaveika bitais per sekundę.

pfSense tik maršrutizatoriaus režimu: dvikryptė tinklo mazgo greitaveika

Gali nustebinti, tačiau net be virtualizacijos sluoksnio pfSense sistema su mažiausiais 64 baitų ilgio paketais, pralaida tik 90 Mbps (45 Mbps abiem kryptimis), kita vertus, šį duomenų srautą sudaro 629 tūkst. kadrų per sekundę; tuo tarpu IOMMU greitaveika beveik trečdaliu mažesnė – 66 Mbps (33 Mbps abiem kryptimis).

Dar prasčiau atrodo E1000 programinės ir VirtIO paravirtualizuotos tinklo sąsajos tvarkyklės, tik 10 ir 24 Mbps atitinkamai. Šiais laikais, kai belaidžio ryšio technologijos gali pasiūlyti didesnę nei 30 Mbps stabilią greitaveiką, vargu ar gali sužavėti tokia virtualaus tinklo mazgo pralaida.

Iš dalies dėl to kalta pridėtinė informacija, kaip minėta metodikos straipsnio dalyje, 64 baitų ilgio paketu perduodamos naudingos informacijos kiekis tik apie 28%, visą kitą sudaro meta duomenys.

Kai pfSense maršrutizatorius dirba su dvigubai ilgesniais 128 baitų paketais, pralaida bitais padidėja daugiau nei 4 kartus, nes ir jų perduodama naudinga informacija didėja daugiau nei du kartus, iki 64%; kartu su kadro ilgio didėjimu matomas ženklus bendros pralaidos augimas bitais.

Visos tinklo sąsajos realizacijos virtualioje mašinoje pasiekia savo praktiškai naudingą pralaidos bitais piką su didžiausiais kadrų dydžiais – 1518, nes ir jų naudingoji krova išauga iki 97%.

Paketų delsa

Kitas svarbus maršrutizatoriaus rodiklis – jį kertančių paketų delsa. Kaip minėta metodikoje, šiame darbe pfSense mazgo delsa matuojama į abi puses {round-trip time}, o ne į vieną {end-to-end}. Toliau nagrinėjama delsa pamatuota dviem atvejais: kai pfSense sistema neveikios būsenos {idle} ir kai yra apkrauta sveikąja pralaida, nustatyta pralaidos testų metu.

Pažymėtina, jog vertikalioji linijinės diagramos vertikalioji ašis logaritminės skalės – maži pokyčiai plokštumoje, turi didelį skaitinių reikšmių skirtumą.

pfSense tik maršrutizatoriaus režimu: laisvoji paketų delsa

Vėlgi, galbūt daugelio nustebimui, bet matyti aiškus skirtumas tarp tos pačios tinklo plokštės, kai ši priskirta pfSense maršrutizatoriaus platformai be virtualizacijos sluoksnio ir kai ji priskirta VM per IOMMU virtualizaciją su tos pačios konfigūracijos pfSense sistema. Vidutiniškai laisvoji delsa IOMMU atveju net 38% didesnė, tarp 64 ir 1518 baitų ilgio kadrų.

Laisvosios delsos anomalija užfiksuota su 8K-64K dydžio paketais, čia VM tinklo plokštė pasižymėjo mažesne delsa nei ta pati tinklo plokštė aparatinės įrangos atveju. Papildomi testais nepavyko šios anomalijos panaikinti, todėl tai turėtų būti teisingi duomenys. Atsižvelgus į mažą pfSense apkrovą apdorojant fragmentuotus paketus, didesnę delsą aparatinės įrangos atveju gali lemti tinklo plokštę aptarnaujančio proceso konteksto perjungimo suvėlinimas.

Laisvosios delsos skirtumas tarp VirtIO ir aparatinės įrangos kiek daugiau nei 91%, imant 64 ir 1518 baitų ilgio kadrus. Nežymus skirtumas užfiksuotas tarp programiškai imituojamų VirtIO ir E1000 tinklo sąsajų. Pastarojo vidutiniškai apie 12% didesnis, tarp 64 ir 1518 baitų ilgio kadrų.

Ryškus laisvosios delsos skirtumas tarp aparatinės įrangos ir E1000 imituojamos tinklo sąsajos: nuo 64 iki 1518 baitų ilgio kadrų užfiksuota vidutiniškai 114% didesnė laisvoji delsa.

Didesnių nei 1518 dydžio, fragmentuojamų tinklo paketų delsa tiesiogiai priklauso nuo Ethernet kanalinio lygmens kadrų delsos, todėl dideliems paketams skiriamas mažesnis dėmesys.

Apkrautosios delsos diagrama ryškiai skiriasi nuo laisvosios delsos. Įdomu tai, jog apkrautoji delsa mažesnė už laisvąją toms VM tinklo sąsajoms, kurios turi tiesioginę prieigą prie fizinės tinklo plokštės. Itin ženkliai sumažėjo VirtIO paravirtualizuotos tinklo sąsajos delsa, nors jos skirtumas lyginant su nevirtualizuota pfSense sistema vidutiniškai kiek daugiau nei 62%, imant 64 ir 1518 baitų ilgio kadrus. Iš pirmo žvilgsnio šie rezultatai prieštarauja logikai, tačiau tiek daug klaidingų duomenų surinkta testų metu negalėjo būti.

pfSense tik maršrutizatoriaus režimu: apkrautoji paketų delsa

To priežastis tikriausiai VM tinklo plokštės eiles aptarnaujančio proceso konteksto keitimas procesoriuje. Jei procesas reikšmingai apkrautas, jam skirta daugiau laiko užduotims atlikti iki procesoriaus planuoklės algoritmai nusprendžia vykdyti brangiai laiko ir našumo atžvilgiu kainuojantį procesoriaus/branduolio konteksto perjungimą. Siekiant efektyviau išnaudoti procesoriaus laiką planuoklės algoritmai siekia sumažinti kontekstų perjungimą, todėl priklausomai nuo apkrovos situacijos tai gali arba padidinti paketų aptarnavimo delsą, arba ją sumažinti.

Skirtingai nei kitos tinklo sąsajos pfSense maršrutizatoriaus apkrautos delsos testuose, E1000 gerokai sublogo. Jos rezultatai itin nenuoseklūs ir nestabilūs, kelis kart kirto 10 ms ribą. Bei apkrautoji delsa vidutiniškai didesnė net 2235% nei aparatinės įrangos, tarp 64 ir 1518 baitų dydžio kadrų.

Nepaisant rezultatų pagerėjimo tinklo plokštė atvaizduojama per IOMMU virtualizaciją vis tiek nepaveja savo našumu tos pačios tinklo plokštės naudojamos pfSense sistemoje be virtualizacijos sluoksnio; jos delsa vidutiniškai 21% didesnė, 64-1518 baitų ilgio kadrams.

Nors VirtIO tinklo sąsajos apdorojamų paketų delsa pfSense maršrutizatoriaus platformoje sumažėjo ir priartėjo prie IOMMU bei aparatinės įrangos atvejų, ji išliko pastebimai didesnė.

Paketų drebėjimas

Kitas svarbus kokybinis tinklo ryšio parametras, dažnai matuojamas kartu su tinklo delsa – tinklo paketų drebėjimas {jitter}. Atsižvelgus į sąlyginai nedidelį paketų drebėjimą sukeltą pfSense maršrutizatoriaus platformos, darbe matuojamas tik apkrautojo tinklo paketų drebėjimas, maksimalios dvikryptės pralaidos metu.

pfSense tik maršrutizatoriaus režimu: paketų drebėjimas

Kaip matyti iš paketų drebėjimo linijinės diagramos visais paketų ilgių matavimo atvejais pfSense maršrutizatoriaus įtakotas paketų drebėjimas, taikant skirtingas tinklo sąsajos realizacijas, pasižymi nuoseklumu ir stabilumu. Tarp kurių geriausiai pasirodė tiesioginę kreiptį prie fizinės tinklo plokštės turinčios virtualios mašinos tinklo sąsajos.

pfSense maršrutizatoriaus platformai apdorojant mažiausius tinklo kadrų dydžius matyti akivaizdus našumo skirtumas tarp IOMMU virtualizacijos priskirtos tinklo plokštės ir tos pačios tinklo plokštės naudojamos betarpiškai virš aparatinės įrangos. Skirtumas pradeda blėsti ties 512 baitų ilgio paketų, o testuojant 1024 baitų ir ilgesnius paketus, užfiksuotas vienodas paketų drebėjimas.

VirtIO ryškiai atsilieka nuo kitų tinklo sąsajos tvarkyklių, turinčių tiesioginę prieigą prie fizinės tinklo plokštės. Našumo skirtumas pakankamai ryškus pfSense apdorojant 128-512 baitų ilgio paketus, tačiau susilygina nuo 1280 baitų ilgio paketų.

Iš dalies blogiausius rezultatus vėl rodo programine įranga imituojama tinklo plokštė su E1000 tvarkyklėmis. E1000 rezultatų anomalija prasideda kartu su paketų fragmentacija. Pakartotini testai linijos trajektorijos nepakeitė, todėl laikomasi nuomonės, jog tai teisingi rezultatai. E1000 tinklo sąsajos pranašumą gali lemti tam tikri jos architektūriniai sprendimai, leidžiantys efektyviau apdoroti fragmentuojamus tinklo paketus.

pfSense sistemos procesoriaus vidutinė apkrova

Visų testų metu buvo fiksuojama pfSense maršrutizatoriaus vidutinė procesoriaus apkrova, tai duoda papildomos įžvalgos į pfSense sistemos ir virtualizacijos sąveiką.

Stebint pfSense vidutinę apkrova gali kilti klausimas, kodėl apkrova neviršija 50 procentų ribos. Dažniausiai, nors nebūtinai, pfSense sistemoje vienai tinklo sąsajai aptarnauti skiriamas vienas procesoriaus branduolys. Kadangi testuojama pfSense maršrutizatorius turi 4 branduolius ir 2 dedikuotas tinklo sąsajas testavimo duomenų srautui apdoroti, jų sveika apkrova neviršija 50 proc.

pfSense sistemos vidutinė procesoriaus apkrova maršrutizatoriaus režimu

Kaip matyt iš skritulinės diagramos IOMMU virtualizacija ir aparatine įranga paremta pfSense sistemos vidutinės apkrovos skritulinė figūra savo forma maždaug sutampa, bet ryškiai skiriasi jų masteliai. IOMMU būdu priskirtos tinklo plokštės VM siūlo ne tik didžiausią pralaidą virš virtualizacijos sluoksnio, bet ir vieną didžiausių pfSense VM centrinio procesoriaus apkrovą.

Iš apkrovos diagramos matyti, jog IOMMU su 64-512 baitų ilgio paketais remiasi į aparatinės įrangos galimybes, o tai paaiškina pralaidos diagramoje pastebėta aiškią IOMMU riba ties 470 tūkstančių kadrų per sekundę.

Iš teisų, IOMMU našumo dilema išlieka: kodėl toks didelis skirtumas tarp tinklo plokštės išskirtinai dedikuotos VM per IOMMU virtualizacijos palaikymą ir tos pačios tinklo plokštės be virtualizacijos sluoksnio, kai pfSense sistemos konfigūracija identiška.

Abiem atvejais, pfSense be virtualizacijos sluoksnio ir su IOMMU virtualizacija, mato tas pačias tinklo plokštes, bei naudoja tas pačias tvarkykles jų darbui tinkle. Tą patvirtina abejose pfSense sistemose, per komandinę eilutė įvykdytos komandos: pciconf –lvc igb1/igb2 ir ifconfig –a bei dmesg | grep igb1/igb2; kurių išvesta informacija praktiškai sutampa. Tačiau IOMMU atveju ta pati tinklo plokštė tampa procesoriaus išteklių siurbliu, dėl ko pasiekia ir mažesnį našumą.

Įtarus, jog virtualizacija smarkiai įtakoja procesoriaus skaičiavimo pajėgumus, su sysbench testavimo įrankiu atliktas VM su IOMMU priskirtomis tinklo sąsajomis ir nevirtualizuotos pfSense sistemos procesoriaus testavimas su komanda: sysbench --test=cpu run --num-threads=1/2/4/32; VM rezultatai buvo 3,22%, 3,23%, 3,25% ir 2,12% atitinkamai mažesni už nevirtualizuotos pfSense sistemos, o tai nepaaiškina kodėl kadrų pralaida kirto net apie 27 procentus.

Iš diagramos gana nuosekliai atrodo VirtIO tinklo sąsajos apkrova, bei apgaulingai nedidelė už mainais siūloma spartą. Iš tiesu, KVM hipervizorius kiekvienai VirtIO sąsajai sukuria po papildomą aptarnaujantį vhost procesą, matoma tik už VM ribų. Nors apkrovos diagramoje jų įtakos nematyti, top įrankio duomenimis vhost procesų apkrova testų metu buvo apie 60% per branduolį/tinklo sąsają, o tai bendrai sudaro daugiau apkrovos fizinei sistemai, nei kitos tiriamos VM tinklo sąsajos.

Kaip matyt iš skritulinės diagramos programine įranga imituojama tinklo sąsaja su E1000 tvarkyklėmis visais testuojamų paketų dydžiais maksimaliai išnaudoja dviejų branduolių išteklius – dviem tinklo plokštėms. Tikėtina, jog lėta bet stabili E1000 kadrų pralaida su visais paketų ilgiais (apie 32 kkps) padeda išlaikyti ir stabilesnį didesnių paketų apdorojimą pfSense tinklo mazge.