Կարճ պատմություն Ֆիոյի և այլնի մասին
Կլաստերի կատարումը մեծապես կախված է դրա պահեստավորման կատարումից: etcd-ն արտահանում է որոշ չափումներ ցանկալի պահեստավորման կատարողականի տեղեկատվություն տրամադրելու համար: Օրինակ՝ wal_fsync_duration_seconds չափանիշը: Որպեսզի պահեստը բավականաչափ արագ համարվի, այս չափման 99-րդ տոկոսը պետք է լինի 10 մվ-ից պակաս: Եթե դուք պլանավորում եք գործարկել etcd կլաստերը Linux սարքերում և ցանկանում եք գնահատել, թե արդյոք ձեր պահեստը բավականաչափ արագ է (օրինակ՝ SSD), կարող եք օգտագործել I/O գործառնությունների փորձարկման հայտնի գործիք է: Գործարկեք հետևյալ հրամանը, որտեղ test-data-ն պահեստավորման ամրացման կետի տակ գտնվող գրացուցակն է.
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestԴուք պարզապես պետք է նայեք արդյունքներին և ստուգեք, որ տևողության 99-րդ տոկոսը 10 ms-ից պակաս: Եթե այո, ապա դուք ունեք բավականին արագ պահեստավորում: Ահա արդյունքների օրինակ.
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
sync percentiles (usec):
| 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
| 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
| 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
| 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
| 99.99th=[15795]Նշումներ
- Մենք հարմարեցրել ենք --size և --bs տարբերակները մեր կոնկրետ սցենարի համար: Fio-ից օգտակար արդյունք ստանալու համար տրամադրեք ձեր սեփական արժեքները: Որտեղ ստանալ դրանք: Կարդացեք .
- Փորձարկման ընթացքում ամբողջ I/O բեռը գալիս է fio-ից: Իրական կյանքի սցենարում, ամենայն հավանականությամբ, կլինեն պահեստում գրելու այլ հարցումներ, բացի wal_fsync_duration_seconds-ի հետ կապվածներից: Լրացուցիչ բեռը կբարձրացնի wal_fsync_duration_seconds-ի արժեքը: Այսպիսով, եթե 99-րդ տոկոսը մոտ է 10 մս-ին, ձեր պահեստի արագությունը սպառվում է:
- Վերցրեք տարբերակը 3.5-ից ոչ ցածր (նախորդները ցույց չեն տալիս fdatasync-ի տևողության տոկոսները):
- Վերևում ներկայացված է fio-ի արդյունքների միայն մի հատված:
Երկար պատմություն Ֆիոյի և այլնի մասին
Ինչ է WAL-ը և այլն
Սովորաբար օգտագործվում են տվյալների բազաները ; etcd-ը նույնպես օգտագործում է այն: Մենք այստեղ մանրամասն չենք քննարկելու նախօրոք գրելու մատյանը (WAL): Բավական է, որ մենք իմանանք, որ etcd կլաստերի յուրաքանչյուր անդամ այն պահպանում է մշտական պահեստում: etcd-ը գրում է բանալի-արժեքի յուրաքանչյուր գործողություն (օրինակ՝ թարմացումը) WAL-ում՝ նախքան այն խանութում կիրառելը: Եթե պահեստի անդամներից մեկը խափանում է և վերագործարկվում է պատկերների միջև, այն կարող է լոկալ կերպով վերականգնել գործարքները WAL բովանդակության վերջին լուսանկարից հետո:
Երբ հաճախորդը բանալի է ավելացնում բանալի-արժեքի պահեստին կամ թարմացնում է գոյություն ունեցող բանալու արժեքը, etcd-ը գրանցում է գործողությունը WAL-ում, որը սովորական ֆայլ է մշտական պահեստում: etcd ՊԵՏՔ Է լիովին վստահ լինել, որ WAL մուտքն իրականում տեղի է ունեցել նախքան մշակումը շարունակելը: Linux-ում մեկ համակարգային զանգը բավարար չէ դրա համար: , քանի որ ֆիզիկական պահեստում իրական գրառումը կարող է հետաձգվել: Օրինակ, Linux-ը կարող է որոշ ժամանակ պահել WAL գրառումը միջուկի հիշողության քեշում (օրինակ՝ էջի քեշը): Եվ որպեսզի տվյալները ճշգրիտ գրվեն մշտական պահեստում, գրելուց հետո անհրաժեշտ է fdatasync համակարգի զանգը, և etcd-ը պարզապես օգտագործում է այն (ինչպես կարող եք տեսնել աշխատանքի արդյունքում , որտեղ 8-ը WAL ֆայլի նկարագրիչն է):
21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8) = 0 <0.008314>Ցավոք, մշտական պահեստում գրելը անմիջապես տեղի չի ունենում: Եթե fdatasync զանգը դանդաղ է, etcd համակարգի կատարումը կտուժի: որ պահեստը համարվում է բավականաչափ արագ, եթե 99-րդ տոկոսային կետում fdatasync-ի զանգերը WAL ֆայլում գրելու համար տևում է 10 մվ-ից պակաս: Կան պահեստավորման այլ օգտակար չափումներ, բայց այս գրառման մեջ մենք խոսում ենք միայն այս չափման մասին:
Պահպանման գնահատում fio-ով
Եթե Ձեզ անհրաժեշտ է գնահատել, թե արդյոք ձեր պահեստը հարմար է etcd-ի համար, օգտագործեք fio, որը շատ հայտնի I/O բեռնման փորձարկման գործիք է: Պետք է հիշել, որ սկավառակի գործողությունները կարող են շատ տարբեր լինել՝ համաժամանակյա և ասինխրոն, համակարգային զանգերի բազմաթիվ դասեր և այլն: Արդյունքում, fio-ն բավականին դժվար է օգտագործել: Այն ունի բազմաթիվ պարամետրեր, և դրանց արժեքների տարբեր համակցությունները առաջացնում են շատ տարբեր I/O աշխատանքային բեռներ: etcd-ի համար համապատասխան թվեր ստանալու համար WAL ֆայլեր գրելիս պետք է համոզվեք, որ fio-ից փորձնական գրելու բեռնվածությունը հնարավորինս մոտ է etcd-ի իրական բեռնվածությանը:
Հետևաբար, fio-ն առնվազն պետք է ստեղծի բեռնվածություն ֆայլում մի շարք հաջորդական գրառումների տեսքով, յուրաքանչյուր գրություն բաղկացած կլինի համակարգային զանգից: որին հաջորդում է fdatasync համակարգի զանգը: Fio-ում հաջորդական գրությունները պահանջում են --rw=write տարբերակը: Որպեսզի fio-ն օգտագործի գրելու համակարգը գրելիս զանգահարեք, այլ ոչ , դուք պետք է նշեք --ioengine=sync պարամետրը: Վերջապես, ամեն գրելուց հետո fdatasync-ը կանչելու համար պետք է ավելացնել --fdatasync=1 պարամետրը։ Այս օրինակի մյուս երկու տարբերակները (--size և -bs) հատուկ են սցենարին: Հաջորդ բաժնում մենք ձեզ ցույց կտանք, թե ինչպես դրանք կարգավորել:
Ինչու fio-ն և ինչպես սովորեցինք այն ստեղծել
Այս գրառման մեջ մենք նկարագրում ենք իրական դեպք. Մենք ունենք կլաստեր v1.13, որը մենք վերահսկել ենք Պրոմեթևսի հետ: etcd v3.2.24-ը տեղադրվել է SSD-ի վրա: Etcd չափումները ցույց տվեցին, որ fdatasync-ի հետաձգումը չափազանց բարձր է, նույնիսկ երբ կլաստերը ոչինչ չէր անում: Չափիչները տարօրինակ էին, և մենք իրականում չգիտեինք, թե դրանք ինչ են նշանակում: Կլաստերը բաղկացած էր վիրտուալ մեքենաներից, պետք էր հասկանալ, թե որն է խնդիրը՝ ֆիզիկական SSD-ներում, թե վիրտուալացման շերտում։ Բացի այդ, մենք հաճախ փոփոխություններ էինք կատարում ապարատային և ծրագրային ապահովման կոնֆիգուրացիայի մեջ, և մեզ անհրաժեշտ էր դրանց արդյունքները գնահատելու միջոց: Մենք կարող էինք գործարկել etcd-ը յուրաքանչյուր կոնֆիգուրացիայի մեջ և դիտարկել Պրոմեթևսի չափումները, բայց դա չափազանց մեծ դժվարություն է: Մենք փնտրում էինք որոշակի կոնֆիգուրացիան գնահատելու բավականին պարզ միջոց: Մենք ուզում էինք ստուգել, թե արդյոք ճիշտ ենք հասկանում Պրոմեթևսի չափումները etcd-ից:
Բայց դրա համար երկու խնդիր էր պետք լուծել. Նախ, ի՞նչ տեսք ունի I/O բեռնումը, որը etcd-ն ստեղծում է WAL-ին գրելիս: Ինչ համակարգային զանգեր են օգտագործվում: Ո՞րն է գրառումների չափը: Երկրորդ, եթե պատասխանենք այս հարցերին, ինչպե՞ս կարող ենք նմանատիպ ծանրաբեռնվածություն վերարտադրել fio-ի հետ: Մի մոռացեք, որ fio-ն շատ ճկուն գործիք է՝ բազմաթիվ տարբերակներով: Մենք երկու խնդիրն էլ լուծեցինք մեկ մոտեցմամբ՝ օգտագործելով հրամանները и . lsof-ը թվարկում է գործընթացի կողմից օգտագործվող բոլոր ֆայլերի նկարագրիչները և դրանց հարակից ֆայլերը: Իսկ strace-ով կարող եք ուսումնասիրել արդեն իսկ գործող գործընթաց, կամ սկսել գործընթաց և ուսումնասիրել այն: strace-ը տպում է բոլոր համակարգային կանչերը հետազոտվող գործընթացից (և նրա զավակ գործընթացները): Վերջինս շատ կարևոր է, քանի որ etcd-ը պարզապես նման մոտեցում է ցուցաբերում:
Մենք առաջին անգամ օգտագործեցինք strace՝ ուսումնասիրելու etcd սերվերը Kubernetes-ի համար, երբ կլաստերի վրա բեռ չկար: Մենք տեսանք, որ գրեթե բոլոր WAL գրառումները մոտավորապես նույն չափն էին. 2200–2400 բայթ: Հետևաբար, գրառման սկզբի հրամանում մենք նշել ենք -bs=2300 պարամետրը (bs նշանակում է բայթերով չափը յուրաքանչյուր fio մուտքի համար): Նկատի ունեցեք, որ etcd մուտքի չափը կախված է etcd տարբերակից, բաշխումից, պարամետրերի արժեքներից և այլն, և կազդի fdatasync-ի տևողության վրա: Եթե ունեք նմանատիպ սցենար, ստուգեք ձեր etcd գործընթացները strace-ով` ճշգրիտ թվերը պարզելու համար:
Այնուհետև լավ պատկերացում կազմելու համար, թե ինչ է անում etcd ֆայլային համակարգը, մենք այն սկսեցինք strace-ով և -ffttT տարբերակներով: Այսպիսով, մենք փորձեցինք ուսումնասիրել երեխայի գործընթացները և գրանցել դրանցից յուրաքանչյուրի արդյունքը առանձին ֆայլում, ինչպես նաև ստանալ մանրամասն հաշվետվություններ յուրաքանչյուր համակարգային զանգի մեկնարկի և տևողության մասին: Մենք օգտագործեցինք lsof-ը, որպեսզի հաստատենք strace-ի ելքի մեր վերլուծությունը և տեսնենք, թե որ ֆայլի նկարագրիչը ինչ նպատակով է օգտագործվում: Այսպիսով, ստրեյսի օգնությամբ ստացվեցին վերը նշված արդյունքները։ Համաժամացման ժամանակի վիճակագրությունը հաստատեց, որ wal_fsync_duration_seconds-ը etcd-ից համահունչ է fdatasync զանգերին WAL ֆայլի նկարագրիչներով:
Մենք ուսումնասիրեցինք fio-ի փաստաթղթերը և ընտրեցինք մեր սցենարի տարբերակները, որպեսզի fio-ն ստեղծի etcd-ի նման բեռ: Մենք նաև ստուգեցինք համակարգային զանգերը և դրանց տևողությունը՝ գործարկելով fio-ն strace-ից, որը նման է etcd-ին:
Մենք ուշադիր ընտրել ենք --size պարամետրի արժեքը՝ ներկայացնելու համար fio-ից ամբողջ I/O բեռը: Մեր դեպքում սա պահեստում գրված բայթերի ընդհանուր թիվն է: Պարզվեց, որ այն ուղիղ համեմատական է գրելու (և fdatasync) համակարգային զանգերի քանակին։ bs-ի որոշակի արժեքի համար fdatasync զանգերի քանակը = չափ/bs: Քանի որ մեզ հետաքրքրում էր տոկոսը, մենք պետք է ունենայինք բավականաչափ նմուշներ, որպեսզի համոզվեինք, և մենք հաշվարկեցինք, որ մեզ համար բավարար կլինի 10^4-ը (դա 22 մբիբայթ է): Եթե --size-ն ավելի փոքր է, ապա կարող են առաջանալ արտանետումներ (օրինակ, fdatasync-ի մի քանի զանգեր սովորականից ավելի երկար են տևում և ազդում 99-րդ տոկոսի վրա):
Փորձեք դա ինքներդ
Մենք ձեզ ցույց տվեցինք, թե ինչպես օգտագործել fio-ն և տեսնել, թե արդյոք պահեստը բավականաչափ արագ է, որպեսզի etcd-ը լավ գործի: Այժմ դուք կարող եք դա փորձել ինքներդ՝ օգտագործելով, օրինակ, վիրտուալ մեքենաներ, որոնցում առկա է SSD պահեստավորում .
Source: www.habr.com