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

Tiriamasis modelis ir metodika

Apačioje pateikta tipinė virtualaus tinklo mazgo su integruota pfSense tinklo perimetro užkarda loginė schema (žr. 1 pav.). Joje pfSense sistema vykdoma lygiagrečiai su kita virtualia mašina virš vienos fizinės kompiuterio platformos. Šis kompiuterių tinklo perimetro užkardos schema bus praktiškai suderinta ir ištestuota.

1 pav. Virtualizuota tinklo perimetro užkardos sistema

Kaip matyti iš loginės schemos tiriama virtualizuota pfSense užkardos sistema dalinasi vienos fizinės kompiuterio sistemos ištekliais su kita lygiagrečiai veikiančia Linux VM. Taigi, šiuo darbu siekiama ištirti ne tik virtualizacijos sluoksnio įtaką tinklo našumui pfSense sistemos atžvilgiu, bet ir tuo atveju kai pfSense užkarda integruojama į virtualų tinklo mazgą kuriame turi dalintis aparatinės įrangos ištekliais su kitomis virtualiomis mašinomis.

Šioje dalyje bandoma patikrinti kokią įtaką pfSense užkardos našumui turi lygiagrečiai virš vienos fizinės sistemos vykdoma virtuali mašina kuri dirba perkrovos režimu – visapusiškai išnaudoja jai numatytos fizinės platformos dalies resursus. Pažymėtina, jog dėl ribotos testavimo aplinkos darbinės atminties išteklių lygiagrečiai su pfSense vykdoma tik viena papildoma VM. Fizinės platformos išteklių paskirstymas tarp virtualių mašinų pateiktas 1 lentelėje.

1 lentelė. Testuojamų virtualių mašinų techninės specifikacijos

	Linux VM	pfSense VM
Hipervizorius	Linux KVM (Proxmox VE 4.4)	Linux KVM (Proxmox VE 4.4)
vCPU branduoliai	2 [host]	4 [host]
RAM	1280 MB (dedikuota, fiksuoto dydžio)	2048 MB (dedikuota, fiksuoto dydžio)
OS	Ubuntu 17.04 Server (64-bit)	pfSense CE 2.3.4 (64-bit)
Tinklo plokštė	1 bendrinama [VirtIO bridge] 1 dedikuota [PCI passthrough]	2 dedikuotos [PCI passthrough] 1 bendrinama [VirtIO bridge]
Standusis diskas	4 GB [VirtIO SCSI, LVM Thin]	4 GB [VirtIO SCSI, LVM Thin]

Kaip matyti iš 1 lentelės pfSense VM priskirta tiek pat išteklių, kaip ir ankstesniais IOMMU virtualizacijos testavimo atvejais. Iš tiesų, tai ta pati VM, tik atkurta į pradinę konfigūracijos būseną. Vadinasi nebereikia per naujo testuoti tos pačios VM, nes jos našumo rezultatai jau yra žinomi.

Gretimai Linux VM priskirta tik dvejų branduolių procesorius su 1280 MB operatyviosios atminties. Daugiau fizinės sistemos išteklių neskirta, nes norima rezervuoti 2 fizinio procesoriaus branduolius ir likusią 768 MB operatyviąją atmintį KVM hipervizoriaus reikmėms, antraip testuose bus matuojama ne gretimos mašinos įtaka pfSense sistemai, o perkrauto hipervizoriaus.

Virtualioms mašinoms numatytos lygios dalys standžiojo disko išteklių dalys, bei jų KVM procesų apdorojimo prioritetai Proxmox VE atžvilgiu vienodi (tipinės Proxmox VE mašinos).

Kadangi pfSense sistema pagal taikomą modelį yra kritinis taškas nuo kurio priklauso prieiga prie interneto tinklo ir vidinės debesų kompiuterijos infrastruktūros bei jų paslaugų administravimas, pfSense VM priskirtos dvi dedikuotos tinklo plokštės – interneto ir vidinio kompiuterių tinklo sąsajoms, per IOMMU virtualizacijos palaikymą; bei viena bendrinama skirtą testų valdymo reikmėms. Dedikuotos sąsajos padeda užtikrinti spartų ir patikimą ryšį.

Vienu atveju gretimai Linux OS vykdančiai VM įdiegta viena VirtIO tinklo plokštė su paravirtualizuotomis tvarkyklėmis, kurios taip pat leidžia tiesioginę prieiga prie fizinės tinklo plokštės, bet ji yra bendrinama tarp kelių mašinų, įskaitant Proxmox virtualios aplinkos sistemą. Ši tinklo plokštė skirta ne tik testų valdymui, bet ir tinklo sąsajos apkrovos imitavimui 100 Mbps dvikrypčiu duomenų srautu.

Antru atveju, į gretimą Linux VM įdiegta viena dedikuota tinklo plokštė per IOMMU virtualizacijos palaikymą, kuri taip pat naudojama testavimui, tinklo sąsajos apkrovos imitavimui 100 Mbps dvikrypčiu duomenų srautu.

Abiem atvejiais kompiuterio aparatinės įrangos (centrinio procesoriaus ir operatyviosios atminties) apkrovos imitavimui pasirinkta paprasta, bet veiksminga stress programinė įranga. stress sisteminio įrankio parametrai suderinti taip, jog sistema būtų reikšmingai ir tolygiai apkrauta – vieno tipo stress sukurti darbiniai procesai neblokuotų kito tipo darbines operacijas. Testų metu naudota stress komanda su parametrais: stress --cpu 1 --io 1 --vm 1 --vm-bytes 1G (sukuria 1 procesoriaus, 1 įvesties/išvesties ir 1 su 1 GB operatyviosios atminties, darbinius procesus perkrovai imituoti)

Dėl testų intensyvumo ir trukmės, standžiojo disko imituojamos apkrovos buvo atsisakyta baiminantis juos pažeisti (kartu testavimo aplinkos vientisumą). Antra vertus, testams suderinta pfSense sistema diską naudoja tik pradinio sistemos paleidimo metu kol įkrauna save į operatyviąją atmintį. Kita vertus, nūdien serverių platformose standusis diskas, ilgą laiką buvęs didžiausias spartos kamštis {bottleneck}, naudojamas tik atsarginėms kopijoms. Sisteminiams diskams kurti juos pakeitė daugelį kartų spartesni lustiniai duomenų kaupikliai (SSD). Be to, diskai Linux OS, kurioje vykdomos KVM virtualios mašinos, gali būti efektyviai ribojami cgroups įrankiais. Dėl šių priežasčių, atsisakyta standaus disko apkrovos testuose, kaip nekritinio kintamojo darbo tikslui pasiekti.

Viename iš testų, kartu su stress sistemos apkrova gretimoje Linux VM imituojamas ir dvikryptis 100 Mbps UDP duomenų srautas su iperf testavimo įrankiu. Pasirinktas imituojamo duomenų srauto kadrų ilgis – 512 baitų, arba 466 baitai UDP paketo krovoje {payload}, nes tai arti vidutinio paketo dydžio interneto tinklo sraute, bei jo apkrova proporcinga stress apkrovai.

Remiantis jau apžvelgtais VirtIO testų rezultatais (žr. 3 straipsnio dalį), šio tipo VM tinklo sąsajos sveikoji dvikryptė pralaida, su 512 baitų ilgio kadrais, apie 300 Mbps. Tačiau, šiuose testuose gretimos Linux VM tinklo sąsajos imituojamas duomenų srautas sumažintas iki 100 Mbps dėl ribotų aparatinės įrangos galimybių. 300 Mbps pralaidos dvikryptis duomenų srautas reikalauja daugiau nei pusė Linux VM procesoriaus laiko. Vadinasi ji negalėtų pakankamai laisvai vykdyti kitų, stress apkrovą imituojančių procesų, ir tolygiai paskirstyti skirtingo tipo apkrovas tarp visų VM resursų. Kita vertus 100 Mbps dvikryptė pralaida dažnai pakankama interneto prieigos greitaveika daugeliui tinklo paslaugų naudojamų smulkiojo ir vidutinio verslo įmonėse.

Vykdant stress ir iperf imituojamas apkrovas vienu metu Linux VM tinklo sąsajos pralaidumas tampa nestabilus. Siekiant visapusiškos sistemos komponentų apkrovos, bet atsižvelgiant į tai, jog tai tinklo mazgo testas, tinklo sąsajos pralaidumui užtikrinti iperf įrankis paleistas su nice sistemine komanda (nice --20 iperf...), perkeliant iperf procesą į bendrosios planuoklės (SCHED_OTHER) sąrašo viršų. Tai užtikrina daugiau procesoriaus laiko iperf proceso apdorojimui.

Su nice prioretizavimu, Linux VM mašinos imituojamo iperf apkrovos srauto nuostoliai nuo stress darbinių procesų įtakos tapo minimalūs: mažiau nei 0,8% pamestų UDP paketų per 7 val. testą.

Iš tiesų, verta atkreipti dėmesį, jog naudojant VirtIO tvarkykles tinklo sąsajai realizuoti, KVM hipervizorius sukuria dar vieną procesą – vhost-[VMpid], skirtą virtualios mašinos VirtIO tinklo plokštės imitavimui ir aptarnavimui. Šis procesas vykdomas šalia kitų KVM VM procesų.

Planuojant vykdyti VM su reikšminga tinklo pralaida per VirtIO tvarkykles, į tai būtina atkreipti dėmesį, nes visos imituojamos tinklo sąsajos atima papildomus aparatinės įrangos išteklius ne iš VM kuriai priskirta VirtIO tinklo plokštė, o iš bendros fizinės sistemos. Todėl reiktų tai įskaičiuot į virtualizacijos hipervizoriaus pridėtines sąnaudas {overhead} ir rezervuoti tam dali išteklių.

Šioje dalyje testuojama gretimos Linux VM įtaka pfSense sistemai, jai veikiant normaliu įsimenamosios tinklo užkardos {stateful firewall} režimu. Šių testų rezultatai bus palyginti su jau turimais analogiškos įsimenamosios užkardos rezultatais apžvelgtais 3 straipsnio dalyje, kai virtualioje mašinoje naudojamos per IOMMU atvaizduotos fizinės tinklo sąsajos.

Skirtingai nei 1 straipsnio dalies apibrėžtoje metodikoje, šiame nebus ieškoma maksimali pralaida, prie kurios duomenų srauto nuostolis nedidesnis už 0,1%, bet pasinaudota jau turima sveikąja pralaida kaip atskaitos tašku, nuo kurio bus pamatuoti UDP duomenų srauto nuostoliai {packet loss}. Tai leis įvertinti kiek gretimos mašinos apkrova turi įtakos pfSense tinklo mazgo našumui.

Kiekvienam paketo ilgiui UDP duomenų srauto testas atliekamas 10 minučių, su jau turimu iperf –b pralaidos parametru iš analogiškų ankstesnių testų (pfSense + IOMMU). Testas atliekamas 3 kartus, iš kurių rezultatų skaičiuojamas vidurkis kaip teisingas rezultatas testuojamam paketo dydžiui.

Tinklo mazgo sukeltam paketų drebėjimui išmatuoti bus pasinaudota tais pačiais 10 min. trukmės testų duomenimis, imant 10 sekundžių drebėjimo išmatavimus 90-100, 190-200, 290-300, 390-400 ir 490-500 sek. intervaluose iš 3 atliktų testų, viso 15 reikšmių kiekvienam paketo dydžiui. Iš šių reikšmių vedamas vidurkis ir užskaitomas kaip teisingas rezultatas atitinkamam paketo dydžiui.

Likusi testavimo metodika iš esmės nesikeitė ir yra paveldima iš pirmos dalies, jei nenurodyta kitaip.

Praktiškai derinamas ir testuojamas pfSense modelis yra tinklo perimetro užkarda, kuri toliau analizuojama, kai:

šalia pfSense sistemos virš bendros fizinės kompiuterio sistemos veikia Linux VM, kuri patiria centrinio procesoriaus ir operatyviosios atminties perkrovas (imituojamas stress įrankio);
šalia pfSense sistemos virš bendros fizinės kompiuterio sistemos veikia Linux VM, kuri patiria centrinio procesoriaus ir operatyviosios atminties perkrovas (imituojamas stress įrankio) bei apdoroja dvikryptį 100 Mbps duomenų srautą kompiuterių tinkle (imituojamą iperf įrankio) naudojant VirtIO ir IOMMU tinklo sąsajas.

pfSense perimetro užkardos ir gretimos Linux VM sąveikos testavimas

Sisteminio top įrankio parodymais, su pasirinktais stress parametrais, imituojama apkrova per 15 min. laikotarpį gretimoje Linux VM sistemoje būna apie 150 proc. (average load 3.08, 3.03, 3.00), o tai 1,5 kartus daugiau nei procesorius geba susidoroti su užduotimis vienu metu.

Prie stress imituojamos apkrovos pridėjus iperf imituojamą VirtIO tinklo sąsajos apkrovą vienalaikiu dvikrypčiu 100 Mbps duomenų srautu, per 15 min. laikotarpį gretimos Linux VM sistemos apkrova pakyla iki 191 proc. (top įrankio parodymais: average load 3.86, 3.82, 3.81), iš kurių maždaug 0.60 priklauso iperf procesui. Bendrai Linux VM patiria beveik 2 kartus daugiau apkrovos nei procesorius geba susidoroti su vykdomomis užduotimis.

Už Linux VM ribų, bet jos tiksliais sukurtas vhost-[VMpid] procesas, kuris pasiima dalį išteklių bendros fizinės sistemos sąskaita. Testų metu iperf imituojamas dvikryptis 100 Mbps duomenų srautas, nukreiptas per VirtIO tinklo sąsają, privertė vhost procesą apkrauti vieną realaus procesoriaus branduolį 30 procentų, kuris kaip minėta metodikos skyrelyje, neįskaičiuotas į VM išteklių dalį.

Pastebėta, jog gretimą Linux VM apkrovus stress ir iperf įrankiais ženkliai padaugėjo, ypač fragmentuojamiems paketams, pranešimų apie out-of-order priimtus UDP paketus iperf testų metu.

Prie stress imituojamos apkrovos pridėjus iperf imituojamą IOMMU tinklo sąsajos apkrovą vienalaikiu dvikrypčiu 100 Mbps duomenų srautu, per 15 min. laikotarpį gretimos Linux VM sistemos apkrova mažesnė nei VirtIO atveju (top įrankio parodymais: average load 3.57, 3.66, 3.61), iš kurių maždaug 50% priklauso iperf procesui. Skirtingai nei VirtIO atveju, IOMMU virtualizuotos tinklo plokštės nesukuria papildomų sąnaudu už VM ribų.

Virtualaus tinklo mazgo nuostoliai dėl gretimos VM veiklos

Jungtinėje diagramoje (žr. 2 pav.) raudona ir mėlyna spalva pažymėtos linijos vaizdžiai iliustruoja našumo nuostolius {packet loss}, įtakotus stress ir iperf darbinių procesų. Kadangi abiejų vertikalių ašių masteliai vienodi, nubrėžtos kreivės tartum rodo nupjautą našumo dalį nuo pfSense tinklo mazgo su IOMMU atvaizduotomis {remapped} tinklo plokštėmis dėl gretimos Linux VM veiklos, vienu atveju testuotos su VirtIO tinklo sąsajos tvarkyklėmis (tamsiai raudona ir mėlyna kreivės), antru atveju su dedikuota tinklo plokšte per IOMMU virtualizacijos palaikymą (šviesiai mėlyna ir raudona linijos).

2 pav. pfSense stateful užkardos režimu + Linux VM: pralaidos ir nuostolių santykis

Kiek kitoks patirtų tinklo nuostolių vaizdas susidaro padidinus mastelį, kuris leidžia pažvelgti iš arčiau į apkrovą imituojančios Linux VM ir pfSense užkardos sistemos sąveiką.

Remiantis surinktais testų duomenimis galima teigti, jog įtaka pfSense užkardos tinklo našumui minimali ir praktiškai nereikšmingą, kai gretima Linux VM veikla apima tik jai priskirtų resursų naudojimą – užduotys su procesoriumi ir operatyviąja atmintimi (žr. 3 pav., mėlynos linijos).

Tačiau, gretimai Linux VM papildomai naudojant bendrinamą kompiuterių tinklo sąsają su paravirtualizuotomis VirtIO tvarkyklėmis, sukėlė reikšmingus našumo pokyčius pfSense sistemoje su IOMMU atvaizduotomis {remapped} tinklo sąsajomis (žr. 3 pav., tamsiai raudona kreivė).

3 pav. pfSense stateful užkardos režimu + Linux VM: pralaidos nuostoliai iš arti

Iš teisų, gretimoje Linux VM taip pat naudojant dedikuotą tinklo sąsają per IOMMU virtualizacijos palaikymą Linux VM aktyvi tinklo apkrova minimaliai įtakoja gretimą pfSense užkardos sistemą (žr. 3 pav., šviesiai raudona kreivė).

Antra vertus, ne visada įmanoma fiziškai priskirti VM tik išskirtinai dedikuotas tinklo plokštes per IOMMU virtualizacijos palaikymą. Todėl šiame darbe tiriamas ir bendresnis bei aktualesnis kompiuterio platformos virtualizacijos atvejis – kai tarp VM naudojama bendrinama aparatinė įranga. Visgi tuo virtualizacija ir patraukli, nes leidžia sumažinti aparatinės įrangos prastovas ją deleguojant kelioms virtualioms kompiuterio sistemoms.

Autoriaus nepastebėjo aiškaus skirtumo tarp pavienės pfSense VM su IOMMU ir kartu su gretimai tuščiąja eiga veikiančia Linux VM {idle}. Todėl nuspręsta naudoti vieną kreivę šio poskyrio diagramose dviem, bet praktikoje lygioms reikšmėms vaizduoti.

Paketų delsa

Linux gretimos VM paveikė ir paketų apdorojimo laiką pfSense tinklo mazge, delsa tapo mažiau stabili. Tačiau lyginant su pavienės pfSense užkardos sistema, išsaugojo tendenciją turėti didesnę laisvąją delsą už apkrautąją. (žr. 4 ir 5 pav.)

4 pav. pfSense stateful užkardos režimu + Linux VM: laisvoji paketų delsa

Kaip matyti iš 4 paveikslo, ženkliai padidėjo pfSense sistemos laisvosios delsos laikas su 64-1518 kadrų dydžiais, vidutiniškai apie 45%, ir tik ties 8K baitų ilgio paketais susilygina su pavienės pfSense užkardos laisvąja delsa. Įtakos skirtumas tarp stress ir iperf imituojamos apkrovos nežymus.

Įdomu tai, jog gretimos Linux virtualios mašinos įtaka priartino pfSense IOMMU virtualizacijos laisvąją delsa prie pavienės pfSense sistemos naudojančios VirtIO paravirtualizuotas tvarkykles.

5 pav. pfSense stateful užkardos režimu + Linux VM: apkrautoji paketų delsa

Apkrautosios delsos skirtumas, gretimai Linux VM imituojant apkrovas tik su stress įrankiu (per VirtIO sąsają) vidutiniškai 20% didesnis nei pavienės pfSense užkardos sistemos, su 64-1518 baitų ilgio kadrais. Tuo tarpu Linux VM naudojant tinklo plokštę per IOMMU, rezultatai labai nestabilūs.

Prisidėjus ir tinklo apkrovos imitavimui su iperf įrankiu, pfSense sistemos su IOMMU apkrautosios delsos laikas vidutiniškai padidėja iki 45%, su 64-1518 baitų ilgio kadrais, bei tampa labai nestabilus, vėl primindamas sunkiai nuspėjamą VirtIO paravirtualizuotos tinklo sąsajos kreivę.

Paketų drebėjimas

6 pav. pfSense stateful užkardos režimu + Linux VM: paketų drebėjimas

Kaip ir pralaidos testuose, dviejų VM mašinų sąveika beveik neįtakojo paketų drebėjimo pfSense tinklo mazge, kai Linux VM apkrova orientuota tik į jai priskirtus aparatinius išteklius (procesorių ir operatyviąją atmintį), kreivės praktiškai identiškos visų paketų ilgiais.

Nedidelį paketų drebėjimą pfSense užkardoje sukėlė gretimoje Linux VM prisidėjusi tinklo imituojama apkrova (abiem VirtIO ir IOMMU atvejais), kuri apima svarbiausius ir dažniausiai naudojamus realaus tinklo paslaugų kadrų ilgius. Tačiau jos kreivė ties 1024 baitų ilgio kadrais pasiveja nubrėžtą pavienės pfSense užkardos sistemos su IOMMU virtualizacija.

Išanalizavus gautus testavimo duomenis, galima daryti išvadą, jog vienos VM mažesnis tinklo aktyvumas per bendrinamą VirtIO tinklo sąsają daro mažesnę įtaką kitos VM našumui tinkle ir minimalią įtaką kai gretimos virtualios mašina naudoja dedikuotas tinklo plokštes per IOMMU. Virtualios mašinos kurios aktyviai nesinaudoja tinklo paslaugomis ir jų netiekia – neturi reikšmingos įtakos tarpusavio darbui veikiant virš vienos fizinės kompiuterio sistemos ir naudojant Linux KVM hipervizoriaus realizuojamą kompiuterio platformos virtualizaciją.