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

Vienas iš pagrindinių darbų kuriuos atlikau ruošdamas savąjį bakalauro baigiamąjį darbą buvo kruopštus Linux KVM virtualizacijos ir pfSense kompiuterių tinklo užkardos sąveikos testavimas. pfSense sistemos atžvilgiu buvo ištestuotas Linux KVM visiškos virtualizacijos našumas Ethernet kompiuterių tinkle, taikant skirtingas tinklo sąsajas realizuojančias tvarkykles. Norėdamas gautus testų rezultatus padaryti kaip galima labiau prieinamus visiems internautams, nusprendžiau baigiamojo darbo praktinės dalies turinį paversti į keturių dalių straipsnį savo tinklaraščiui:

Iš tiesų, pirmosios trys straipsnio dalys naujos informacijos nesuteikia tiems kas drįso skaityti mano bakalauro baigiamąjį darbą. Tačiau ketvirtoji dalis, kurioje nagrinėjama gretimų KVM virtualių mašinų sąveiką virš vienos fizinės kompiuterio sistemos, papildyta nauja informacija iš papildomai atliktų testų jau po baigiamojo darbo, kurio gautos išvados ir paskatino papildomus testavimus.

Metodika

Prieš pereinant prie atliktų testavimo ir gautų duomenų analizės, šio straipsnio dalyje bus apžvelgta testavimo metodika – Linux KVM virtualizacijos ir pfSense sistemos testavimo procedūros – kuri išsamiai apibrėžia naudojamą aparatinę ir programinę įrangą, taikomus metodus testams, naudojamus įrankius, tyrimo eigą bei kitą informaciją tyrimui atlikti.

Testavimo aplinkos aparatinė įranga

pfSense sistemos ir įvairių Linux KVM virtualizacijos metodų sąveikos testavimui buvo sukurta pakankamai nuo išorės izoliuota ir nepriklausoma kompiuterijos laboratorija. Nors ir su savais trūkumais, tačiau numatytam eksperimentui tinkama testavimo aplinka.

Testavimo aplinkos loginė schema

Testavimo aplinką sudaranti laboratorija suformuota iš kolegijai priklausančios studentų reikmėms skirtos kompiuterijos infrastruktūros, bei asmeninėmis priemonėmis (žr. 1 lentelė). Pažymėtina, jog testavimo aplinką sudarantys serveriai rinkoje pasirodė apie 2011 metus ir priklauso ekonomiškų modelių klasei. Jų skaičiavimų ir duomenų apdorojimo sparta nėra itin didelė. Tai reikia turėti mintyje, jog nesusidaryti klaidingos nuomonės apie nūdienos x86 architektūros platformos galimybes kompiuterių tinklo mazge.

Vis dėlto, testams skirti serveriai yra pakankamai nauji, jog turėtų AMD centrinį procesorių ir lustų rinkinį {chipset} su antros kartos aparatinio lygmens palaikymu x86 platformos virtualizacijai (AMD V 2.0), o tai tenkina minimalius praktinės darbo dalies reikalavimus, jos įgyvendinimą.

Iš tiesų, palankiomis aplinkybėmis renkantis naują serverio sistemą virtualizacijos platformai realizuoti, ypatingas dėmesys skiriamas pasirinkto virtualizacijos sprendimo palaikomos aparatinės įrangos sąrašą, bei pati kompiuterio sistema parenkama daug spartesnė už tą su kuria dirbama šiame tiriamajame darbe.

Kaip matyti iš 1 lentelės, abu serveriai identiški savo specifikacijomis (išskyrus standžiuosius diskus, bet tai neturi kritinės reikšmės tyrimui). Fizinėje testavimo aplinkos schemoje prie serverių pažymėtos tinklo plokštės prievadai (TP) iš kurių pirmieji (TP1) sujungti per komutatorių su kolegijos vidiniu kompiuterių tinklu. Tai leidžia serverius administruoti per nuotolį ir supaprastina praktinės dalies testavimo procesą. Šie prievadai (TP1) naudojami tik serverių administravimui.

1 lentelė. Testavimo aplinkos aparatinės įrangos sąrašas

Serveris 1	HP ProLiant DL165 G7 (Firmware Version: 4.22) AMD Opteron™ Processor Model 6128 (2.0 GHz, 12MB Level 3 Cache, 8 cores, 80W) AMD Chipset SR5670 2 x HP NC362i Integrated Dual Port Gigabit Server Adapter 4GB 1Rx4 PC3-10600R-09-10-C1-P1 2 x GB0160EAPRR HP 160GB 3G SATA 7.2K LFF HDD
Serveris 2	HP ProLiant DL165 G7 (Firmware Version: 4.22) AMD Opteron™ Processor Model 6128 (2.0 GHz, 12MB Level 3 Cache, 8 cores, 80W) AMD Chipset SR5670 2 x HP NC362i Integrated Dual Port Gigabit Server Adapter 4GB 1Rx4 PC3-10600R-09-10-C1-P1 SAMSUNG Spinpoint F3 HD103SJ 1TB 7200 RPM 32MB Cache SATA 3.0Gb/s 3.5"
Komutatorius	NETGEAR GS305 5-port Gigabit Ethernet Switch
Kabeliai	5 vnt. vytos poros 5e kategorijos kabelių po 2 metrus

Tuo tarpu antrosios (TP2) ir trečiosios tinklo (TP3) sąsajos tarp serverių tiesiogiai sujungtos vytos poros 5e kategorijos kabeliais. Toks pastarųjų serverių tinklo prievadų sujungimas leidžia pasiekti maksimalią tinklo paketų pralaidą ir sumažina pašalinių veiksnių įtaką testų rezultatams. Testų metu pfSense sistemai veikiant tiesiogiai virš aparatinės įrangos ar virš KVM virtualizacijos, TP2 ir TP3 tinklo plokštės prievadai dedikuoti tik tiesioginėms testavimo reikmėms.

Testavimo aplinkos programinė įranga

Praktinėje baigiamojo darbo dalyje naudojama programinė įranga priklauso atvirajam kodui, kuris šiame darbe akcentuojamas kaip teisingas pasirinkimas smulkioms ir vidutinėms organizacijoms, neretai suvaržytoms finansiškai. Antra vertus, didžioji dauguma našumo testavimo įrankių priklauso atvirajai programinei įrangai ir buvo tik natūralus atsitiktinis pasirinkimas (apie juos netrukus). Visa testavimo aplinkoje naudojama programinė įranga pateikta 2 lentelėje.

2 lentelė. Testavimo aplinkoje naudojama programinė įranga

Visiškos virtualizacijos hipervizorius	Linux KVM
Virtualizacijos administravimo įrankiai	Proxmox Virtual Environment 4.4
Tinklo mazgo testavimo įrankių OS	Ubuntu 17.04 Server (64-bit)
Tinklo mazgo testavimo įrankis	iperf 2.0.9 (1 June 2016) pthreads
Kompiuterio apkrovos simuliavimo įrankis	stress 1.0.4
Tinklo užkardos sistema	pfSense CE 2.3.4 (64-bit)

Testavimo sistemos struktūra

Testavimo aplinkos fiziniai serveriai sudaro dvi atskiras sistemas: testuojamą (serveris 1) ir testuojančią (serveris 2). Testuojantis serveris savo ruožtu gali būti išskirtas į duomenų srauto siuntėją ir gavėją (techniškai, abu serveriai siunčia ir gauna duomenis dvikryptės pralaidos testų metu), jų fizinė ir programinė konfigūracija viso testavimo metu nekinta. Tuo tarpu testuojamas serveris testavimo metu kinta tarp dviejų veikimo režimų: tarp aparatinės įrangos kompiuterio platformos su pfSense sistema ir KVM virtualizacijos platformos su pfSense sistema.

Testavimo sistemos struktūrinė schema

Pirmuoju atveju, testuojamas pfSense tinklo mazgas vykdomas be virtualizacijos sluoksnio, tiesiogiai virš aparatinės serverio įrangos. Tai leidžia nubrėžti atskaitos taškus ir nustatyti virtualizacijos sluoksnio įtaką pfSense užkardos sistemos našumui.

Antruoju atveju fizinis testuojamas serveris perjungiamas į Proxmox VE virtualizacijos aplinką, kurioje sukurtos ir pakaitomis vykdomos kelios savo specifikacijomis praktiškai identiškos KVM virtualios mašinos pfSense užkardos sistemos testavimui. Skiriasi tik VM tinklo sąsajos realizavimas skirtingiems testams atlikti.

Taigi, testavimo aplinka suprojektuota taip, jog bet kuriuo laiko momentu būtų galima persijungti tiek į virtualizuotą tiek į aparatinės įrangos pfSense tinklo mazgo testavimo režimą, jei toks poreikis atsiranda (pvz., aptikus klaidą ar netikslumų galima pakartoti tam tikrą testavimo etapą).

Testuojantis serveris

Vienas iš šios testavimo aplinkos trūkumų tas, jog testuojantis serveris taip pat remiasi į virtualizaciją – virš fizinio serverio veikia Proxmox virtualizacijos aplinka, kuri realizuoja siuntėjo ir gavėjo virtualias mašinas. Papildomas programinės įrangos sluoksnis gali įtakoti ir iškreipti testų rezultatus. Todėl, siekiant kompensuoti šiuos testavimo aplinkos trūkumus ir sumažinti gautų duomenų paklaidą, testavimui reikia skirti daugiau laiko, o neretai ir pakartoti didelę deviaciją turinčius rezultatus, jog įsitikinti gautų duomenų teisingumu.

Siuntėjo ir gavėjo virtualioms mašinoms paskirta po lygiai centrinio procesoriaus, operatyviosios atminties, standžiojo disko ir tinklo sąsajos išteklių, bei vienodos jų operacinės sistemos su įtaisų tvarkyklėmis ir visų operacijų prioritetais Proxmox VE atžvilgiu. Testavimo aplinkos siuntėjo ir gavėjo virtualiųjų mašinų charakteristikos pateiktos 3 lentelėje.

3 lentelė. Testavimo aplinkos siuntėjo ir gavėjo VM techninės specifikacijos

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

Pastebėtina, jog aštuoni virtualaus centrinio procesoriaus branduoliai abiems virtualioms mašinoms nėra klaida (fizinis procesorius turi tik 8 branduolius), o normali ir saugi KVM virtualizacijos praktika. Jei kuri nors viena mašina nenaudoja visų jai priskirtų branduolių, juos gali panaudoti kitos. Tačiau reiktų vengti vienoje VM nustatyti daugiau virtualiųjų branduolių nei turi fizinis procesorius, tai tik sulėtins sistemą dėl dažno procesoriaus konteksto perjunginėjimo.

Kadangi abi virtualios mašinos, siuntėjas ir gavėjas, dirbs su dideliais duomenų srautais tinkle nuo kurių našaus ir nepertraukiamo darbo priklauso testų rezultatai, abiems VM priskirtos dedikuotos tinklo plokštės per IOMMU virtualizacijos palaikymą (dar žinoma kaip PCI passthrough); bei viena bendrinama su paravirtualizuotomis tvarkyklėmis, skirtą testų valdymo reikmėms.

Nors techniškai buvo galima išvengti papildomo virtualizacijos sluoksnio siuntėjui ir gavėjui realizuoti, visgi praktikoje neretai dėl patogumo paaukojamas našumas. Šiuo atveju Proxmox VE administravimo panelė leidžia per nuotolį pasiekti abi virtualias mašinas ir jas valdyti per grafinę saityno tinklalapio vartotojo sąsaja (GUI), o tai supaprastina tiriamojo darbo įgyvendinimą.

Darbo autoriaus nuomone tai pateisintina dėl itin mažos siuntėjo ir gavėjo apkrovos bendrai sistemai. Priklausomai nuo testo, bendra fizinės kompiuterio sistemos apkrova svyruoja nuo 30 iki 50 proc.: po vieną centrinio procesoriaus branduolį tinklo sąsajoms aptarnauti ir maždaug po vieną branduolį testavimo iperf įrankio reikmėms – duomenų srautui generuoti ir registruoti. Antra vertus, prailgintas testavimo laikas gali kompensuoti rezultatų nuokrypio svyravimus ir sumažinti paklaidą.

Testuojamas serveris

Testavimo aplinkos testuojamas serveris priklauso ekonominei klasei, nepasižymi nei funkcijų gausumu nei ištekliu gausa. Todėl nors ir siekta sukonfigūruoti techniškai vienodų aparatinių parametrų VM ir fizinę serverio platformą pfSense užkardos sistemos testavimui, tarp jų yra skirtumų, tačiau atliekamiems testams jie nėra esminiai ir kritiškai reikšmingi (žr. 4 lentelę).

4 lentelė. Testavimo aplinkos testuojamų mašinų techninės specifikacijos

	*Nevirtualizuota pfSense* sistema**	*Virtualios mašinos su pfSense* sistema**
Hipervizorius	-	Linux KVM (Proxmox VE 4.4)
vCPU branduoliai	4 (apriboti programiškai)	4 [host]
RAM	4096 MB	2048 MB (dedikuota, fiksuoto dydžio)
OS	pfSense CE 2.3.4 (64-bit)	pfSense CE 2.3.4 (64-bit)
Tinklo plokštė	3 fizinės dedikuotos	1 atvejis: 2 dedikuotos [E1000 bridge] 2 atvejis: 2 dedikuotos [VirtIO bridge] 3 atvejis: 2 dedikuotos [PCI passthrough] Visais atvejais: 1 bendrinama [VirtIO bridge]
Standusis diskas	4 GB skaidinys [SATA standusis diskas]	4 GB [VirtIO SCSI, LVM Thin]

Vieną skirtumą įtakojo tai, jog testavimo serverio BIOS sistemoje nėra galimybės aparatiniame lygmenyje išjungti dalį centrinio procesoriaus branduolių. Tačiau, šią problemą pavyko išspręsti programiniu būdu – į pfSense paleidimo failą (/boot/loader.conf) įrašius kelias direktyvas: „hint.lapic.CPUid.disabled=1“, kurios nurodė pfSense (FreeBSD) operacinės sistemos branduoliui nenaudoti įvardintus procesoriaus branduolius.

Vis dėlto, sumažinti operatyviosios atminties kiekį nei fiziniu nei apriboti programiniu būdu nepavyko. Tačiau, remiantis sistemos apkrovos stebėjimais, testų metu pfSense užkardos sistemos darbinės atminties sunaudojimas neperžengė 512MB ribos, iš kurių 300MB autorius savo iniciatyva rezervavo /tmp ir /var atminties failų sistemos diskui {memory file system disks}. Iš tiesų, pfSense kūrėjų teigimu, jų sistemą įmanoma sėkmingai vykdyti ir su 128 MB operatyviosios atminties, nors rekomenduojama 256 MB ar daugiau.

Testuojamam serveriui veikiant virtualizacijos platformos režimu, sukurtos virtualios mašinos su pfSense užkardos sistema veikia virš tos pačios platformos pakaitomis. Todėl tarp jų aparatinės ir programinės įrangos parametrų skirtumų nėra (žr. 4 lentelę). Sąmoningai skiriasi tik KVM hipervizoriaus realizuojamos skirtingų savybių tinklo plokštės skirtingiems testams atlikti.

Jei nėra nurodyta kitaip, skirtumų nėra ir tarp pfSense užkardos sistemos konfigūracijos, taikytos virtualizuotoje ir nevirtualizuotoje aplinkoje.

pfSense testavimo modelis

Praktinėje baigiamojo darbo dalyje tinklo mazgo testavimas vykdomas kliento-serverio modelių, kai matuojamas tinklo našumas tarp dviejų tinklo taškų. Šiuo tiriamojo darbo atveju tarp testuojamų dviejų tinklo taškų tik vienas tinklo mazgas – pfSense sistema, todėl matuojamas tik jos tinklo našumas, jei testo metu galinių taškų (serverio ir kliento) ištekliai nėra perkrauti.

Kaip jau buvo minėta praktinėje dalyje atliekamų testų metu testuojančio serverio bendra apkrova svyravo tarp 30 ir 50 proc., priklausomai nuo atliekamo testo. Todėl galima teigti, jog visų testų metu buvo matuojamas tik pfSense tinklo mazgo našumas.

pfSense testavimo modelio schema

Atliktų testų procedūrą, nepriklausomai nuo platformos virš kurios veikia pfSense sistema, suprantamai perteikia testavimo modelio schema. Viena dedikuota pfSense tinklo plokštė sujungta su testavimo įrankio serveriu ir imituoja interneto sąsają (WAN); kita sujungta su klientu ir imituoja vietinio tinklo sąsają (LAN). Klientas su serveriu užmezga ryšį ir pagal nurodytus parametrus generuoja, siunčia bei priima duomenų srautą. Visi testai atliekami vienalaikiu dvikrypčiu duomenų perdavimu, nes ir praktikoje tinklo mazgas patiria vienalaikį dvikryptį duomenų srautą.

Testų metodika ir RFC 2544

Tiriamojo darbo testavimo metodika remiasi RFC 2544 (Benchmarking Methodology for Network Interconnect Devices) rekomendacijomis. Vis dėlto, dėl tinklo mazgų testavimo įrankių palaikančių šį neoficialų standartą trūkumo autoriaus aplinkoje, tik iš dalies laikomasi RFC 2544 nurodymų. Be to, darbe taikomas papildomas paketų drebėjimo {jitter} testas, kuris neapibrėžtas RFC 2544 tinklo įrenginių testavimo metodikoje, nors šiai dienai įvardinamas kaip vienas iš svarbesnių tinklo kokybinių rodiklių. Iš tiesų, nūdienos Ethernet tinklo testavimo įrenginiai palaiko ir naujesnę tinklo mazgų testavimo metodiką, apibrėžtą ITU (International Telecommunication Union) organizacijos Y.1563 (Ethernet frame transfer and availability performance) standartu. Deja pastaroji yra mokama ir dėl finansinių suvaržymų darbe ja nesiremta.

RFC 2544, tai tinklo kartotuvų, komutatorių bei maršrutizatorių testavimo metodikos de facto standartas laisvai prieinamas internete. Jis 1999 metais pristatytas Internet Engineering Task Force organizacijos, siekiant suvienodinti ir aiškiai apibrėžtą tinklo mazgų testavimo metodiką, kuri leistų palyginti skirtingų gamintojų tinklo įrenginius tarpusavyje.

Nors RFC 2544 standartas numato daugiau tinklo mazgo įrenginių testų, šiame tiriamajame darbe pasinaudota tik svarbiausių testų metodikos rekomendacijomis, derinant jas prie darbe naudojamos testavimo įrangos išteklių ir poreikių darbo tikslui pasiekti.

Testavimo įrankiai

Šiame darbe testavimui naudojamas populiarus ir lengvai prieinamas atvirosios programinės įrangos tinklo tiriamasis įrankis – iperf. Jis leidžia pamatuoti tinklo pralaidą UDP ir TCP protokolais, vienakrypčiu {unidirectionally} ir vienalaikiu dvikrypčiu {bi-directionally} duomenų perdavimu, bei keliomis lygiagrečiomis ryšio sesijomis, tarp dviejų tinklo mazgų. Testuojant UDP duomenų srautu, iperf ne tik parodo pralaidos rezultatus, bet suteikia daug naudingos informacijos apie tinklo kokybinius rodiklius: tokius kaip UDP paketų drebėjimą {packet jitter} ir jų nuostolius {packet loss}.

Testavimo įrankį padėjo pasirinkti Barton J. tiriamasis darbas „Performance Testing Tools“, nagrinėjantis tinklo našumui tirti skirtus programinius įrankius RFC2544 rekomendacijos atžvilgiu.

Tačiau tinklo našumo testavimas iperf turi trūkumą, tai programinės įrangos testavimo priemonė veikianti virš bendro pobūdžio Linux operacinės sistemos. Bendros paskirties operacinėje sistemoje veikia sisteminiai procesai, kurie tam tikrais laiko momentais suaktyvėja, o tai gali iškreipti testų duomenis, ne dėl testuojamo tinklo mazgo (pfSense) įtakos.

Kita vertus, testavimo iperf įrankis operuoja virš bendro pobūdžio Linux OS, kuri veikia virš virtualizacijos sluoksnio, sukurtą dar kitos programinės įrangos – Proxmox VE, ši taip pat paremta Linux OS. Deja profesionalūs tinklo mazgo testavimo įrankiai, kuriu integriniai grandynai sukurti tik vienai užduočiai atlikti – tinklo kokybiniams ir kiekybiniams rodikliams matuoti, kainuoja nemenkus finansinius išteklius ir autoriui yra neprieinami.

Nepaisant atsakingo ir kruopštaus testavimo, tiriamojo darbo testų metu surinktus duomenis vertėtų priimti mintyje su nedidele paklaida, atsirandančias dėl minėtų testuojamos aplinkos trūkumų. Tačiau, pateikti galutiniai ir susisteminti rezultatai pakankamai tikslūs, jog būtų galima palyginti skirtingas Linux KVM hipervizoriaus tinklo sąsajos tvarkykles, jų našumą pfSense sistemos atžvilgiu.

Ethernet kompiuterių tinklo kadrų ilgiai

Išsamiai tinklo mazgo charakteristikai gauti RFC 2544 rekomenduoja, jog visi testai būtų atliekami bent su penkiais skirtingo dydžio tinklo kadrais. Tarp kurių būtinai mažiausias ir didžiausias galimas testuojamam kanalinio lygmens standartui.

Ethernet kompiuterių tinklo atveju, RFC 2544 rekomendacijos apibrėžia šiuos tinklo kadro dydžius: 64, 128, 256, 512, 1024, 1280 ir 1518 baitų; tarp kurių mažiausias ir didžiausias galimi, bei keletas tarpinių lengvai įsimenamų kadro dydžių.

Iš tiesų, nėra vieno geriausio kadro dydžio tinkamo visiems Ethernet tinklams, kadangi visuose kompiuterių tinkluose vyrauja skirtingas kadrų dydžių pasiskirstymas. Tačiau, jei tinklo įrenginio gamintojas pristato savo įrenginio spartą/pralaidą vienu skaičiumi, RFC 2544 rekomenduoja, jog pralaida būtų išreikšta mažiausiu tinklo kadro dydžiu. Deja marketingo vedami didelė dalis tinklinės įrangos gamintojų pristato savo prietaisų pralaidą išmatuota su didžiausiais tinklo kadrais, dažnai pamiršdami tai nurodyti ne tik ant pakuotės, bet ir įrenginio instrukcijose, specifikacijose.

Mažesni tinklo kadrai padeda testuoti tinklo mazgo aparatinės įrangos spartą, kadangi maksimaliai mazgo pralaidai pasiekti reikia apdoroti daugiau tinklo kadrų per vienetinį laiko tarpą. Tuo tarpu didesni tinklo kadrai neša daugiau naudingos informacijos ir gali tą pačią pralaidą pasiekti su mažesniu tinklo kadrų skaičiumi per vienetinį laiko tarpą.

Iš dalies laikantis RFC 2544 nurodymų, šiame darbe testai atliekami ne tik su didžiausiu Ethernet standarto kadro dydžiu, bet ir didžiausiu leidžiamu IP protokolo paketų dydžiu, bei keliais tarpiniais tinklo lygmens paketų dydžiais. Taigi, šiame darbe papildomai testuojami šie IP paketų dydžiai: 4096, 8192, 16384, 32768 ir 65507 baitų.

Kompiuterių tinkle maksimalus perdavimo vienetas – vadinamasis MTU {maximum transmission unit} – kanaliniame lygmenyje tik 1518 baitų ilgio. Todėl dideliems IP protokolo paketams reikalinga fragmentacija – didesnių tinklo lygmens paketų skaidymas į mažesnius kanalinio lygmens kadrus, kurį atlieka TCP/IP protokolų rinkinį palaikantis maršrutizatorius.

Kadrų dydžių išplėtimą IP paketų dydžiais siekiama išsiaiškinti kaip pfSense susitvarko su paketų fragmentacija vykstančia tinklo lygmenyje. Šiame darbe atliekami testai orientuoti ne kiek tinklų tilto (kuris apdoroja tik kanalinio lygmens kadrus), bet į interneto tinklą (paremta IP protokolu) sudarančių tinklo mazgų operacijoms testuoti.

Kita vertus operuoti 65507 baitų paketais virš pakankamai mažo standartinio Ethernet MTU yra pavojinga. Fragmentų surinkimas vykdomas tik tada, kai gaunami visi jo fragmentai. Tai sulėtina pilno paketo apdorojimą. Antra vertus, pametus bent vieną fragmentą, tenka siųsti visus fragmentus iš naujo. Vadinasi, vienas kadro netekimas prilygsta maždaug 44 įprastų MTU praradimui.

Nors paketo ir kadro sąvokos skiriasi, šiame darbe šie terminai neretai vartojami kaip lygus. Vis dėlto darbe dažniau vartojama paketo sąvoka. Viena vertus, testuojamas tinklo mazgas (pfSense) operuoja tinklo lygmenyje; antra vertus, ne IT srities atstovui paketo sąvoka suprantamesnė už kadro.

Tačiau reiktų turėti mintyje, jog IP protokolo leidžiamas paketo ilgis yra 20-65535 baitai, o žemesniojo Ethernet kanalinio lygmens kadrų: 64-1518 baitai. Todėl analizuojant gautus testų duomenis, visuose diagramose abscisės ašyje nuo 64 iki 1518 žymimas kanalinio lygmens kadrų ilgis baitais, o nuo 4K iki 64K paketų ilgis baitais. Pralaidos diagramos ordinatės ašyje mazgo sparta matuojama tik kadrais ir bitais per sekundę. Autoriaus nuomonė kadrai reikšmingesnė informacija už paketus vertinant tinklo mazgo spartą, kadangi paketai žemesniame lygmenyje vis vien perduodami kaip tinklo kadrai kurių maksimali naudingųjų duomenų krova {payload} tik 1500 baitų.

Šiame darbe testavimo įrankiu iperf tinklo mazgo našumo rodiklius pasirinktinai matuojama su UDP paketų srautu, kuris pagal OSI modelį priklauso ketvirtajam lygmeniui. Tuo tarpu Ethernet kadarai priklauso antrajam, kanaliniam lygmeniui. Todėl norint siųsti pageidaujamo dydžio kadrus kanaliniame lygmenyje, reikia nepamiršti apskaičiuoti ir atmesti iš siunčiamo paketo tarpinių lygmenų antraščių ilgius.

Pavyzdžiui, jei iperf nurodoma siusti 1518 baitų UDP paketus, kanaliniame lygmenyje pridėjus antraštes jo dydis bus matomas kaip 1546 baitai, o tai reiškia fragmentaciją, bet ne vieną standartinį Ethernet MTU, kas iškreiptų testo rezultatus. Jog neįsiveltų klaida, darbe siunčiamų paketų ir kadrų dydžių tikslumu buvo įsitikinta juos patikrinus tcpdump paketų analizatoriumi.

Taigi, norint išsiųsti tam tikro dydžio kadrą kanaliniu lygmeniu reikia nepamiršti transportinio (TCP/UDP), tinklinio (IP) bei kanalinio lygmens (Ethernet) antraščių ilgių sumos atimti iš siunčiamo paketo su iperf testavimo įrankiu.

Jei MTU 1518 baitų, norint išvengti UDP paketo fragmentacijos maksimalus jo ilgis neturėtų viršyti 1472 baitų: 1518 – 18 (Ethernet antraštė) – 20 (IP antraštė) – 8 (UDP antraštė);

Atitinkamai TCP protokolo atveju maksimalus TCP paketo ilgis neturėtų viršyti 1460 baitų: 1518 – 18 (Ethernet antraštė) – 20 (IP antraštė) – 20 (TCP antraštė).

Visi kadrų ir paketų ilgiai naudoti testavimo metu su iperf –l parametro reikšmėmis pateikti 5 lentelėje, naudingos UDP paketo krovos {payload} stulpelyje.

5 lentelė. Testuojamų kadrų ir paketų ilgiai baitais

Ethernet kadro dydis	UDP paketo krova	Ethernet kadro dydis	UDP paketo krova
64	18	1518	1472
128	82	fragmentuojama į 1518	4096
256	210	fragmentuojama į 1518	8192
512	466	fragmentuojama į 1518	16384
1024	978	fragmentuojama į 1518	32768
1280	1234	fragmentuojama į 1518	65507

Iš 5 lentelės gerai matyti, jog labai skiriasi naudingos perduodamos informacijos ir pridėtinės informacijos (antraščių) santykis: kuo jis didesnis, tuo efektyviau išnaudojama tinklo mazgo pralaida. Iš tiesų, galima nesunkiai paskaičiuoti UDP protokolo efektyvumą Ethernet atžvilgiu:

Siunčiant mažiausius kadro dydžio paketus:

Ethernet

Siunčiant didžiausius kadro dydžio paketus:

Ethernet

Atitinkamai pridėtinės UDP protokolo informacijos {protocol overhead} santykis išreikštas procentais: maždaug 72% su mažiausiais kadrais ir 3% su didžiausiais (Ethernet atžvilgiu).

Sekančiame skyrelyje apibrėžta tinklo mazgo (pfSense) pralaidos matavimo metodika, kuri šiame darbe matuojama tik naudingos informacijos srauto atžvilgiu, t.y. tokią, kurią galima išnaudoti praktiškai, neskaičiuojant paketų antraščių sukuriamo pridėtinės informacijos duomenų srauto.

Sveikoji tinklo mazgo pralaida

Tinklo pralaida {throughput} esminis tinklo našumo kiekybinis rodiklis, marketingo tikslais dažnai perteikiamas bitais per sekunde (bps), tartum leidžiantis iš pirmo žvilgsnio įvertinti tinklo įrenginio spartą. Tačiau, tinklo pralaida matuojama ne tik bitais per sekundę, bet ir kadrais/paketais per sekundę (kps/pps). Būtent pastarasis pralaidos matavimo vienetas padeda objektyviau įvertinti įrenginio spartą. Be to, svarbu nurodyti su kuriuo tinklo kadro ilgiu įrenginio pralaida išmatuota, kadangi dažnas Ethernet tinklo įrenginys pasieks afišuojamą 1 Gbps duomenų perdavimo spartą siunčiant didelius paketus, bet retas pasieks bent pusę nurodytos pralaidos su mažais tinklo paketais.

RFC 2544 tinklo mazgo pralaidą apibrėžia kaip maksimalų kadrų skaičių per sekundę, perduotą be nuostolių per 60 sekundžių laikotarpį – išsiųstų kadrų skaičius lygus gautųjų skaičiui. Pralaidą rekomenduojama įvardinti kadrų skaičiumi per sekundę, visiems testuojamiems kadro dydžiams.

Šiame darbe pralaida taip pat įvardinama kadrais per sekundę (kps), bei bitais per sekundę (bps) dėl visuotinio aiškumo. Tačiau taikoma didesnė leidžiamoji nuostolių riba – 0,1 proc. Absoliučia dauguma atveju tinklo paslaugos turėtų be problemų susitvarkyti su 0,1% paketų nuostoliais tinkle.

Visgi reikia pažymėti, jog iš pirmo žvilgsnio ir nedidelė dalis pamestų tinklo paketų (pvz., 1-2 proc.), priklausomai nuo naudojamo transportinio protokolo, skirtingai įtakoja tinklą ir jo paslaugas. Pavyzdžiui, pamestas UDP paketas nepersiunčiamas ir papildomo krūvio tinklui dėl to nesukuria. Tačiau pamestas TCP paketas pagal protokolo apibrėžimą yra pakartotinai persiunčiamas, o tai gali paskatinti tinklo grūstį ir dar didesnius paketų nuostolius.

Nors tinklo mazgo pralaidą galima matuoti TCP paketais, šiame tiriamajame darbe pralaida matuojama su UDP paketų srautu, kadangi šis testavimo režimas su iperf tinklo testavimo įrankiu suteikia ne tik kiekybinės, bet ir kokybinės informacijos apie tinklo ryšį, reikalingos testų duomenims surinkti, bei testų patikimumui įvertinti. Visi pralaidos testai atliekami vienalaikiu dvikrypčiu duomenų perdavimu, nes ir praktikoje tinklo mazgas apdoroja vienalaikį dvikryptį duomenų srautą.

Tinklo mazgo pralaidos testai atliekami parenkant iperf –b parametro reikšmes ir laikomas sėkmingu jei testo metu prarastų paketų dalis mažesnė arba lygi 0,1 proc. Surasta –b parametro reikšmė nurodo testuojamam paketo dydžiui maksimalią pralaidą (paketais ir bitais) su kuria pfSense sistema gali susidoroti be žymių UDP paketų nuostolių. Maksimali pralaida kurios nuostoliai pasirinktam paketo dydžiui nedidesni už 0,1% šiame darbe vadinama sveikąja pralaida.

Vienas pralaidos testas trunka 100 sekundžių ir periodiškai pakartojamas 3 kartus. Jei bent 1 iš 3 bandymų rezultatų, imant vidurkį iš dvikrypčio duomenų srauto rezultatų, tenkina keliamus nedidesnių nei 0,1% nuostolių reikalavimus, o deviacija proporcinga kitiems rezultatams, jis užskaitomas kaip teisingas testas. Jei visi bandymai atitinka iškeltus reikalavimus, imami to bandymo rezultatai, kurio gauti duomenys turi mažesnius nuostolius, o paketų pralaida ir drebėjimas atrodo stabilesni už kitus. Antraip vėl kartojamas 3 bandymų ciklas kol randama iperf –b parametro reikšmė. Ieškant –b parametro reikšmės naudotas derinimo detalumas ir tikslumas: didesniems tinklo paketams po 5 Mbps, mažiems po 1 Mbps (nors galima derinti ir kps).

Sėkmingo iperf –c 10.0.2.20 –u –b 130 M –d –t 100 –i 10 –l 82 testo fragmentas:

[ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[3] 0.0-10.0 sec   155 MBytes   130 Mbits/sec   0.006 ms 2182/1981800 (0.11%)
[3] 10.0-20.0 sec   155 MBytes   130 Mbits/sec   0.008 ms 2101/1981718 (0.11%)
[3] 20.0-30.0 sec   155 MBytes   130 Mbits/sec   0.008 ms 1071/1981710 (0.054%)
[3] 30.0-40.0 sec   155 MBytes   130 Mbits/sec   0.008 ms 1669/1981713 (0.084%)
[3] 40.0-50.0 sec   155 MBytes   130 Mbits/sec   0.006 ms 494/1981713 (0.025%)
[3] 50.0-60.0 sec   155 MBytes   130 Mbits/sec   0.008 ms 2276/1981709 (0.11%)
[3] 60.0-70.0 sec   155 MBytes   130 Mbits/sec   0.009 ms 1554/1981703 (0.078%)
[3] 70.0-80.0 sec   155 MBytes   130 Mbits/sec   0.006 ms 1742/1981718 (0.088%)
[3] 80.0-90.0 sec   155 MBytes   130 Mbits/sec   0.008 ms 1693/1981697 (0.085%)
[3] 0.0-100.0 sec 1.51 GBytes   130 Mbits/sec   0.008 ms 19657/19817064 (0.099%)

Laisvoji ir apkrautoji paketų delsa tinkle

Paketų delsa {latency} yra vienas esminių kompiuterių tinklo kokybinių rodiklių, leidžiantis įvertinti ryšio kokybę. Vėlinimas itin neigiamai įtakoja realaus laiko tinklo paslaugas, tokias kaip VoIP, vaizdo konferencijas, kompiuterinius žaidimus tinkle bei kt. Nesunku įsivaizduoti, kaip laike vėlinamas pokalbis telefonu, ar vaizdo konferencija sumažina produktyvumą ir jų panaudojimo efektyvumą. Tuo tarpu žaidimai tinkle visai netoleruoja ir sąlyginai nedidelės paketų delsos.

Tinklu keliaujantis paketas yra pristabdomas kiekvieno tinklo mazgo kurį jis kerta, tol kol bus apdorotas pagal apibrėžtas mazgo taisykles. Kiek ilgai paketas užtruks tinkle, priklauso nuo tinklo mazgų spartos, todėl renkantis tinklo mazgą itin svarbu atkreipti dėmesį į jo sukeltą paketų vėlinimą.

Šiame darbe delsa matuojama dviem atvejais: kai pfSense sistema neveikios būsenos {idle} ir kai apkrovos būsenos {load}. Tuo tarpu RFC 2544 apibrėžia tik apkrovos būsenos matavimą. Neveikios būsenos delsos laiką šiame darbe vadinsime laisvąja delsa, o apkrovos – apkrautąja delsa.

RFC 2544 taip pat taiko skirtingą delsos laiko matavimo metodiką, kuri matuoja tinklo mazgo vidinės delsos laiką {end-to-end time}. Šiame darbe testavimo metodika supaprastinta iki ping įrankio, matuojančio delsos laiką tinkle į abi puses {round-trip time}, tačiau visiškai tinkamo skirtumui ir įtakai tarp įvairių tinklo mazgo sprendimų pamatuoti.

Nors RFC 2544 rekomenduoja tikrinti testuojamos sistemos delsą maksimalia pralaida nustatyta mazgo pralaidumo testuose, tačiau, atsižvelgus į testavimo sistemos jautrumą, pfSense tinklo paketų apkrautos delsos testai atliekami kartu su 95% maksimalia greitaveika, t.y. sveikoji pralaida sumažinta 5% kiekvienam testuojamo paketo dydžiui.

RFC 2544 numato vieną delsos testą kiekvienam paketo dydžiui vykdyti 120 sekundžių ir siųsti tik vieną delsos tikrinimo paketą po 60 sekundžių. Šį testą siūloma kartoti bent 20 kartų ir teisingam atsakymui imti vidurkį iš visų 20-ties gautų delsos tikrinimo paketų.

Šiame darbe delsos testas tai pat vykdomas 120 sekundžių, kurio metu po 60 sek. siunčiama 10 ping komandos sugeneruotų delsos tikrinimo paketų (kanaliniame lygmenyje 64 baitų ilgio). Vieno testo metu fiksuojamas vidurkis iš 10 delsos paketų. Toks išplėstas testavimas leidžia patikrinti delsos deviaciją tarp 10 paketų, ir padeda pastebėti galimai iškreiptus rezultatus dėl anksčiau aptartų testavimo sistemos trūkumų.

Delsos testai po 120 sek. kartojami 9 kartus kiekvienam paketo ilgiui. Iš geriausių 6 delsos laiko rezultatų imamas vidurkis kaip teisingas rezultatas testuojamam paketo dydžiui. Jei 9 testų metu gauti duomenys tarpusavyje prastai koreliuoja, turi didelę deviaciją ir nuostolius, visi duomenys atmetami ir testų serija atitinkamam paketo dydžiui kartojama.

Tinklo paketų drebėjimas

Kitas svarbus kokybinis kompiuterių tinklo rodiklis yra paketų drebėjimas {jitter}, kuris taip pat atsiranda dėl tinklo mazgo kaltės, jų paketų apdorojimo metodų ir spartos. Kaip ir paketų delsos atveju ryšio drebėjimas neigiamai įtakoja realaus laiko tinklo paslaugas. Sakoma, jog didelė paketų delsa ir drebėjimas sumažina naudingo kompiuterių tinklo diametrą.

Pavyzdžiui, VoIP perduodamo balso duomenų srauto paketų perteklinis drebėjimas gali sukelti girdimos kalbos trūkinėjimus telefono garsiakalbyje kitame ryšio gale; analogiškai trūkinėja ir tinklu transliuojamas vaizdo signalas. Taip nutinka jei priimančio prietaiso buferis lengvai perpildomas ar laiku negauna duomenų, kuris procesorinio įtaiso apdorojamas reguliariais laiko intervalais.

Paketų drebėjimas tai paketų delsos svyravimas, dėl kurio tinkle susidaro nelygus tarpai tarp nuosekliai siunčiamų paketų. Jei nuosekliai siunčiamų kadrų perdavimo pradžioje jų tarpkadrinis laiko tarpas buvo vienodas, tinklo paketams keliaujant tinklu ir kertant ne vieną tinklo mazgą tarpkadrinis laiko tarpas pradeda kisti. Jis kinta dėl ilgo kadrų apdorojimo laiko tinklo mazge, mazgo buferinės atminties sukeltų kadrų pliūpsnio {burst}, ar susidariusių skirtingų tinklo kelių tarp paketų.

Atrodytų keista, bet paketų drebėjimo testas nėra apibrėžtas RFC 2544 rekomendacijoje. Galbūt todėl, jog 1999 metais šio kokybinio kompiuterių tinklo rodiklio reikšmę ateičiai buvo sunku numatyti? Kaip ten bebūtų, dauguma nūdienos tinklo testavimo įrenginių siūlo ne tik delsos, bet ir paketų drebėjimo testą. Ne išimtis ir šio tiriamojo darbo testavimas, kadangi paketų drebėjimas ir delsa gali sukelti daug problemų realaus laiko tinklo paslaugoms.

Paketų drebėjimo testai buvo atlikti kartu su maksimalios sveikosios pralaidos matavimais. Testuose naudojamas iperf tinklo testavimo įrankis kartu su UDP paketų pralaida leidžia matuoti ne tik pralaidą, pamestų paketų skaičių, bet ir suteikia informacija apie paketų drebėjimą.

Pralaidos testavimo metu pastebėtas iperf įrankio trūkumas – jis neskaičiuoja vidutinės paketų drebėjimo reikšmės, o pateikia tą, kurią fiksavo standartinės išvesties momentu. Atsižvelgus, jog paketų drebėjimo vidurkį tenka skaičiuoti lėtuoju-rankiniu būdu, bei į testų metu surinktų duomenų gausą, nuspręsta ryšio drebėjimą skaičiuoti tik iš vieno stabiliausio pralaidos testo duomenų.

Vienas pralaidos testas, 100 sekundžių trukmės, paketų drebėjimą užfiksavo 10 kartų, lygiais laiko tarpais kas 10 sekundžių nuo testo pradžios. Šių duomenų vidurkis buvo priimtas kaip paketų drebėjimo rezultatas tam pačiam paketų dydžiui kuriam matuota sveikoji pralaida.

Užkardos funkcijų testavimas

Dauguma tinklo mazgų turi bent minimalias galimybes filtruoti duomenų srautą, kurios neretai panaudojamos tinklo saugumo didinimui. Todėl RFC 2544 rekomendacijos apibrėžia paketų filtravimo testą, kuriuo siekiama patikrinti tinklo mazgo galimybes efektyviai filtruoti paketus pagal tinklo protokolo siuntėjo ir gavėjo adresus. Šis tinklų tilto ir maršrutizatoriaus našumą įtakojantis testas buvo pritaikytas ir pfSense užkardos testavimo reikmėms. Testu tiriamajame darbe siekiama imituoti vartotojo sukonfigūruotą pfSense užkardos sistemą su vartotojo apibrėžtomis taisyklėmis.

Atliekant skirtingus pfSense užkardos sistemos režimų testus, pirmiausia buvo užfiksuota pfSense sistemos paketų apdorojimo sparta kai jos duomenų srauto filtravimo galimybės išjungtos, ir sistema dirba tik maršrutizatoriaus režimu (pfctl -d). Vėliau, į pfSense užkardos sistema su įjungtu duomenų srauto filtravimu (pfctl -e) buvo įtrauktos 25-ios vartotojo apibrėžtos paketų filtravimo taisyklės ir atliktas išsamus testavimas.

RFC 2544 nurodymais pirmosios 24 vartotojo apibrėžtos taisyklės turi blokuoti apibrėžtus, testų duomenų srautui nenaudojamus IP adresus, o paskutinė 25-oji taisyklė suteikti leidimą testo duomenų srautui kirsti pfSense mazgą iki paskirties taško. Taigi, pfSense sistema priverčiama nuosekliai tikrinti visas 25 vartotojo apibrėžtas paketų filtravimo taisykles. Toks taisyklių tikrinimas gali gerokai įtakoti tinklo mazgo našumą, jei šis nėra pritaikytas tinklo apsaugos užduotims vykdyti.

Reikia pastebėti, jog RFC 2544 nurodo 24 pirmas taisykles kaip blokavimo. Tačiau tinklo užkardose dažniausiai taikoma saugos praktika paremta strategija viską blokuoti {default deny} ir praleisti tik tai kas būtina. Todėl pfSense sistema sukonfigūruota su 25 leidimo taisyklėmis, iš kurių taip pat tik viena ir paskutinė duoda leidimą testo duomenų srautui kirsti pfSense tinklo mazgą.

Atsižvelgiant į tai, jog vidinio tinklo adresai dažniau kerta pfSense užkardą, pirmosios 12 filtravimo taisyklių skirtos iš LAN sąsajos ateinantiems paketams ir sekančios 12 iš WAN pusės ateinantiems paketams; tuo būdu tikimasi optimizuoti užkardos paketų tikrinimą. Paskutinioji taisyklė, duodanti teigiamą leidimą testų duomenų srautams, tikrina abiejų sąsajų (WAN ir LAN) įeinantį {inbound} srautą. Taisyklių sąrašas naudotas pfSense užkardos testuose įkeltas į priedus.

Virtualizacijos ir pfSense sistemos sąveikos testavimas

Siekiant geriau suprasti kuri iš Linux KVM hipervizoriaus palaikomų tinklo plokštės tvarkyklių efektyviausiai – sparčiausiai ir su mažiausiomis sąnaudomis – atlieka Ethernet kompiuterių tinklo paketų apdorojimą, šiame skyriuje analizuojami testų metu surinkti duomenys su skirtingomis tinklo plokštės tvarkyklėmis virtualioje mašinoje:

E1000 – programine įranga imituojamos tinklo plokštės tvarkyklės, leidžia prieigą prie bendrinamos fizinės tinklo plokštės;
VirtIO – paravirtualizuotos tinklo plokštės tvarkyklės leidžia tiesioginę prieigą prie fizinės, bendrinamos arba dedikuotos, tinklo plokštės;
IOMMU virtualizacija – įgalina tiesioginę kreiptį prie sistemos išteklių {PCI passthrough}, VM priskiriama tik jai dedikuota fizinė tinklo plokštė su įprastomis įtaiso tvarkyklėmis.

Skirtingi tinklo plokštės realizavimo būdai KVM virtualioje mašinoje analizuojami tinklo mazgo pralaidumo {throughput}, paketų delsos {latency} ir drebėjimo {jitter} atžvilgiu, kai:

pfSense sistema tik persiunčia paketus {forwarding}, paketų filtravimas išjungtas – veikia tik kaip maršrutizatoriaus platforma {routing platform only};
pfSense sistema dirba normaliu įsimenamuoju tinklo užkardos režimu {stateful firewall};
pfSense sistema veikia specifiniu neįsimenamuoju užkardos režimu {stateless firewall}.

Norint įvertinti virtualizacijos įtaką pfSense tinklo sistemos našumui, reikia ne tik mokėti jį testuoti, bet ir nusibrėžti atskaitos liniją, kuri leis įvertinti virtualizacijos įtaka pfSense sistemai. Todėl kartu su skirtingais KVM virtualizacijos būdais buvo ištestuota pfSense ir fizinės aparatinės įrangos našumas, kuris visose diagramose žymimas HW (nuo angl. hardware) trumpiniu.