Programuesit nga kompania Cloudflare kanë punuar për optimizimin e performancës së enkriptimit të disqeve në kernelin Linux. Si rezultat, janë përgatitur për nëndظامin e dhe Crypto API, duke lejuar që në testin sintetik kapaciteti i kalimit të të dhënave të rritet më shumë se dyfish gjatë leximit dhe shkruajtur, si dhe të reduktohen vonesat me dyfish. Gjatë testimit në pajisje reale, kostot nga enkriptimi arritën të reduktoheshin pothuajse në nivelin e vërejtur gjatë punës me disk pa e përdorur enkriptimin e të dhënave.
Cloudflare përdor dm-crypt për enkriptimin e të dhënave në pajisjet që përdoren për caching të përmbajtjes në rrjetin CDN. Dm-crypt funksionon në nivelin e pajisjeve të bllokimeve dhe kryen enkriptimin e kërkesave për hyrje/ dalje të shkrimit dhe dekriptimin e kërkesave për lexim, duke vepruar si një shtresë midis pajisjes së bllokues dhe drejtorit të sistemit të skedarëve.
Për të vlerësuar performancën e dm-crypt me paketën u mat shpejtësia e punës me parti të enkriptuara dhe të paenkriptuara në një disk RAM, i vendosur në RAM për të përjashtuar fluktuacionet në performancën e disqeve dhe për të fokusuar në performancën e kodit. Për partit e paenkriptuara, performanca e leximit dhe shkrimit mbeti në nivelin 1126 MB/s, por kur u aktivizua enkriptimi, shpejtësia ra me 7 herë dhe arriti në 147 MB/s.
Në fillim, kishte dyshime për përdorimin e algoritmeve joefikase në sistemin e enkriptimit të kernelit. Por në testime u përdor algoritmi më i shpejtë aes-xts me një çelës enkriptimi prej 256, performanca e të cilit gjatë kryerjes së «cryptsetup benchmark» është më shumë se dyfish më e lartë se rezultati i marrë në testimin e disk RAM. Eksperimentet me flamujt dm-crypt për optimizimin e performancës nuk dhanë rezultat: kur u përdor flamuri «—perf-same_cpu_crypt», performanca madje ra në 136 MB/s, ndërsa me flamurin «—perf-submit_from_crypt_cpus» u rrit vetëm në 166 MB/s.
Një shqyrtim më i thellë i logjikës së funksionimit tregoi se dm-crypt nuk është aq i thjeshtë sa dukej — kur merr një kërkesë për shkrim nga drejtori i FS, dm-crypt nuk e përpunon atë menjëherë, por e vendos në radhë «kcryptd», e cila nuk përpunon menjëherë, por në një moment të përshtatshëm. Nga radhët, kërkesa dërgohet në Linux Crypto API për të kryer enkriptimin. Por, pasi që Crypto API përdor një model asinkron të ekzekutimit, enkriptimi gjithashtu nuk kryhet menjëherë, duke kaluar përmes edhe një radhe tjetër. Pasi përfundon enkriptimi, dm-crypt mund të përpiqet të kryejë renditjen e kërkesave të pritura për shkrim, duke përdorur një pemë kërkuese . Në fund, një proces tjetër i kernelit përsëri me një vonesë të caktuar merr kërkesat e akumuluara për hyrje/ dalje dhe i dërgon ato në grumbullin e pajisjes së bllokimit.
Kur lexon, fillimisht dm-crypt shton në radhen «kcryptd_io» një kërkesë për marrjen e të dhënave nga pajisja. Pas një kohe, të dhënat bëhen të disponueshme dhe vendosen në radhë «kcryptd» për dekriptim.
Kcryptd dërgon kërkesën në Linux Crypto API, që dekriptizon informacionin në mënyrë asinkrone. Kërkesat nuk kalojnë gjithmonë përmes të gjitha radheve, por në skenarin më të keq, kërkesa për shkrim ngec në radhë deri në 4 herë, ndërsa kërkesa për lexim deri në 3 herë. Çdo hyrje në radhë shkakton vonesa, të cilat janë shkaku kryesor i uljes së madhe të performancës së dm-crypt.
Përdorimi i radheve justifikohet nga nevoja për të punuar nën kushte të ndërprerjeve. Në vitin 2005, kur u implementua modeli i tanishëm i punës së dm-crypt mbi bazën e radheve, Crypto API nuk ishte ende asinkron. Pas kalimit të Crypto API në modelin asinkron të ekzekutimit, u aplikua në thelb një mbrojtje e dyfishtë. Radhët gjithashtu u futur për të kursyer konsumimin e grumbullit të kernelit, por pas rritjes së tij në vitin 2014, këto optimizime humbën relevancën. Një radhë shtesë «kcryptd_io» u prezantua për të kapërcyer ngushticat që shkaktojnë pritjen e ndarjes së memories kur vijnë shumë kërkesa. Në vitin 2015, një fazë renditjeje u fut gjithashtu, pasi kërkesat për enkriptim në sisteme me shumë procesor mund të përfundonin pa ruajtur rendin e dërgimit (në vend që të kishte qasje sekondare në disk, ishte e mundur një qasje në rend të rastësishëm, si dhe planifikuesi CFQ punonte joefikas). Aktualisht, me përdorimin e disqeve SSD, renditja ka humbur kuptimin, dhe planifikuesi CFQ nuk përdoret më në kernel.
Duke marrë parasysh se pajisjet moderne janë bërë më të shpejta dhe më të mençura, sistemi i shpërndarjes së resurseve në kernelin Linux është rishikuar dhe disa nëndhërrat janë ripunuar, inxhinierët e Cloudflare në dm-crypt ka një mënyrë të re pune, e cila është çliruar nga përdorimi i radhëve të tepruara dhe thirrjeve asinkrone. Mënyra aktivizohet me një flag të veçantë 'force_inline' dhe e shndërron dm-crypt në një proxy të thjeshtë, që enkripton dhe dekripton kërkesat e ardhshme. Bashkëveprimi me Crypto API është optimizuar përmes një zgjedhjeje të qartë të algoritmeve të enkriptimit që punojnë në modin sinkron dhe që nuk përdorin radhë kërkesash. Për punën sinkrone me Crypto API ishte një modul, që lejon përdorimin e FPU/AES-NI për përshpejtim dhe që direkt kalon kërkesat për enkriptim dhe dekriptim.
Në përfundim, gjatë testimit të RAM-diskut arritëm të rrisim më shumë se dyfish performancën e dm-crypt — performanca u rrit nga 294 MB/s (2 x 147 MB/s) në 640 MB/s, që është shumë afër performancës së enkriptimit të pastër (696 MB/s).
Gjatë testimit të ngarkesës në serverë realë, implementimi i ri tregoi një performancë shumë të afërt me konfigurimin që punon pa enkriptim, dhe aktivizimi i enkriptimit në serverat me cache Cloudflare nuk kishte asnjë ndikim në shpejtësinë e përgjigjes. Në të ardhmen, Cloudflare planifikon të kalojë patch-et e përgatitura në bërthamën kryesore të Linux-it, por para kësaj ata do të duhet të rishikohen, pasi janë optimizuar për një ngarkesë të caktuar dhe nuk mbulojnë të gjitha fushat e përdorimit, për shembull, enkriptimin në pajisje të vogla të integruara.
Burimi: opennet.ru
