Cloudflare ընկերության սեղմողները Linux-ի Kernal-ում դիսկային կոդավորման արտադրողականության օպտիմալացման աշխատանքների անցկացումը: Պատճառն այն էր, որ պատրաստվեցին գործողության ենթահամակարգի համար և Crypto API, որոնք հնարավորություն տվեցին սինթետիկ թեստում ավելի քան երկու անգամ բարձրացնել ընթերցման և գրանցման throughput-ը, ինչպես նաև երկու անգամ կրճատել ուշացումները: Իրական սարքերում կատարված թեստավորման արդյունքում կոդավորման ծախսերը հաջողվեց նվազեցնել գրեթե այն մակարդակին, որը դիտարկվում է ոչ կոդավորված դիսկի համար:
Cloudflare-ն օգտագործում է dm-crypt տվյալների կոդավորման համար իր CDN ցանցում պահվող տվյալներում: Dm-crypt-ը գործում է բլոկային սարքի մակարդակում և կատարում է գրիչի ելքի հարցման կոդավորումը և միայն ընթերցման հարցումների կատարումը, հանդիսանալով միջանկյալ շերտ բլոկային սարքի և ֆայլային համակարգի վարորդի միջև:
dm-crypt-ի կատարողականությունը գնահատելու համար օգտագործելով մայք է եղած արագության տվյալները գրանցվում էին կոդավորված և ոչ կոդավորված բաժինների վրա RAM-դիսկում, որը գտնվում էր RAM-ում, որպեսզի կանխեն դիսկային կատարողականության փոփոխությունները և կենտրոնանան կոդի կատարողականության վրա: Երբ Երևանի առանց կոդավորման բաժինների, ընթերցման և գրանցման կատարողականությունը պահվում էր 1126 MB/s, բայց կոդավորման ակտիվացմամբ արագությունը նվազեց 7 անգամ և կազմեց 147 MB/s:
Ի սկզբանե կասկած կար, որ քննական համակարգում օգտագործվում էին ոչ արդյունավետ ալգորիթմներ: Բայց թեստերում օգտագործվում էր առավել արագ ալգորիթմ aes-xts 256 կոդավորման բանալով, որի կատարողականությունը «cryptsetup benchmark» կատարելու ժամանակ ավելի քան երկու անգամ բարձր էր, քան RAM-դիսկի համար ստացված արդյունքը: dm-crypt-ի կատարողականությունը ճշգրտող դրոշներով փորձերը արդյունք չտվեցին. «—perf-same_cpu_crypt» դրոշով օգտագործելու դեպքում կատարողականությունը նվազեց 136 MB/s, իսկ «—perf-submit_from_crypt_cpus» դրոշը ընդամենը բարձրացրեց 166 MB/s:
Ազգային հաշվարկի սուզումը ցույց տվեց, որ dm-crypt-ը այնքան պարզ չէ, որքան թվում է՝ FS վարորդի կողմից գրանցման հարցման վրա ժամանումը, dm-crypt-ը անմիջապես այն չի մշակում, այլ նստեցնում է «kcryptd» հերթում, որը անմիջապես չի լուծվում, այլ միայն առկա պահի իջեցված: Հերթից հարցումը ուղարկվում է Linux Crypto API-ին կոդավորման աշխատանքը կատարելու համար: Բայց քանի որ Crypto API-ն օգտագործում է ասինխրոն մոդել, կոդավորումը նույնպես չի կատարվում անմիջապես, այլ անցնում է ևս մեկ հերթ: Քանի որ կոդավորումը ավարտված է, dm-crypt-ը կարող է փորձել բարելավել սպասող գրանցման հարցումների դասակարգումը, օգտագործելով որոնման ծառ Ավարտին առանձին միջուկի հոսք կրկին որոշակի ուշացումով բռնում է կուտակված մուտքային/արտահոսքի հարցումները և ուղարկում դրանք բլոկային սարքի կույտին:
Ունենալով ընթերցում, սկզբում dm-crypt-ը queues-նում է «kcryptd_io» հարցում, որպեսզի տվյալները ստացվեն պահեստից: Մերձավոր ժամանակում տվյալները հասանելի են դառնում և տեղադրվում «kcryptd» հերթում ապակոդավորելու համար:
Kcryptd-ն հարցում է ուղարկում Linux Crypto API-ին, որը ապակոդավորում է տվյալները ասինխրոնային ռեժիմում: Հարցումները միշտ չեն անցնում բոլոր հերթերով, բայց ամենավատ սցենարի դեպքում գրառման հարցումը առաջանում է 4 անգամ, իսկ ընթերցման հարցումը 3 անգամ: Յուրաքանչյուր հերթի մուտքը հանգեցնում է ուշացումների, որոնք հանդիսանում են dm-crypt-ի նկատելի արդյունավետության նվազեցման հիմնական պատճառ.
Հերթերի կիրառումը պայմանավորված է միջամտությունների առաջացման պայմաններով: 2005 թվականին, երբ իրականացվեց dm-crypt-ի ընթացիկ աշխատանքային մոդելը հերթերի հիման վրա, Crypto API-ն դեռևս ասինխրոն չէր: Crypto API-ի անցման արդյունքում ասինխրոն իրագործման մոդելին, փաստացի ընդունվում էր կրկնակի պաշտպանության կիրառումը: Յուրաքանչյուր հերթ նաև ցուցաբերվեց սառեցման սպառման տնտեսման համար, բայց 2014 թվականին դրա աճի արդյունքում տվյալ օպտիմիզացումները կորցրել են արդիականությունը: Լրացուցիչ «kcryptd_io» հերթը մտցվել է, որպեսզի հաղթահարելու բարդությունը, որը հանգեցնում էր հիշողության հատկացման սպասման, երբ մեծ թվով հարցումներ էին ժամանուճում: 2015 թվականին նաև մտցվեց դասակարգման փուլ, քանի որ մուլտիվազերում տվյալների հարցումները կարող էին ավարտվել առանց ուղարկված կարգի հետևելու (հաստատապես շրջանառու մուտք դեպի սկավառակը, կատարվում էր պատահական կարգով, իսկ CFQ ժամանակակից պլանավորիչն արդյունավետ չէր աշխատում): Այժմ SSD-մատակարարների օգտագործման դեպքում դասակարգումն անպետք է դարձել, իսկ CFQ պլանավորիչը այլևս չի օգտագործվում միջուկում:
Հաշվի առնելով, որ ժամանակակից պահեստները արագ և խելացի են դարձել, Linux միջուկի ռեսուրսների բաժանման համակարգը վերանայվել է, իսկ որոշ ենթասistemas-ն փոփոխվել են, Cloudflare-ի ինժեներները dm-crypt-ում նոր աշխատանքի režim, որը ազատված է ավելորդ հերթերի և ասինխրոն նահանգներից: Rėjim-ը ակտիվանում է առանձին «force_inline» խորք և dm-crypt-ը բերում է պարզ պրոքսի ձևի, որն encrypts և decrypts մուտքային հարցումները: Մշակումը Crypto API-ի հետ օպտիմիզացված է, ընտրելով վերջնական մոդելով այրումները, որոնք աշխատում են синхронային ռեժիմում և չեն օգտագործում հարցումների հերթեր: Crypto API-ի հետ синхронային աշխատանքի համար բարելավվեց մոդուլ, որը թույլ է տալիս օգտագործել FPU/AES-NI արագացման համար և ուղղակիորեն անցկացնում է ապակոդավորման և կոդավորման հարցումները.
Ստացվեց, որ RAM-ի սկավառակի թեստավորման արդյունքում dm-crypt-ի կատարողականությունը ավելացավ ավելի քան երկու անգամ — կատարողականությունը բարձրացավ 294 MB/ս (2 x 147 MB/ս) մինչև 640 MB/ս, ինչը շատ մոտ է մերկ կոդավորման կատարողականությանը (696 MB/ս)।
Իրական սերվերների վրա բեռի թեստավորման ընթացքում նոր իրականացումը ցուցադրեց կատարողականություն, որը շատ մոտ էր առանց կոդավորումների աշխատող կոնֆիգուրացիային, իսկ Cloudflare-ի ակումբում կոդավորումը առկա սերվերներին ոչ մի կերպ չի ազդել պատասխանների արագության վրա։ Այսպիսով, Cloudflare-ն ծրագրում է փոխանցել պատրաստված նորագոյացված պաչերը Linux-ի հիմնական միջուկի մեջ, սակայն նախ դրանք պետք է վերամշակվեն, քանի որ նրանք օպտիմիզացվել են որոշակի բեռների համար և չեն ընդգրկում բոլոր կիրառման ոլորտները, օրինակ, ցածր հզորության ինտեգրված սարքերի կոդավորում։
Ընտանիք: opennet.ru
