SSD-ների օգտագործման վրա հիմնված և պահեստավորման համակարգերում լայնորեն կիրառվող կատարողականության բարելավման տեխնոլոգիաները վաղուց են հորինվել: Առաջին հերթին դա SSD-ի օգտագործումն է որպես պահեստային տարածք, որը 100% արդյունավետ է, բայց թանկ: Հետևաբար, օգտագործվում են հոգնեցուցիչ և քեշավորման տեխնոլոգիաներ, որտեղ SSD-ները օգտագործվում են միայն ամենահայտնի («տաք») տվյալների համար։ Tiering-ը լավ է «թեժ» տվյալների երկարաժամկետ (օր-շաբաթ) օգտագործման սցենարների համար: Քեշավորումը, ընդհակառակը, նախատեսված է կարճաժամկետ (րոպե-ժամ) օգտագործման համար։ Այս երկու տարբերակներն էլ ներդրված են պահեստավորման համակարգում . Այս հոդվածում մենք կանդրադառնանք երկրորդ ալգորիթմի իրականացմանը. .
SSD քեշավորման տեխնոլոգիայի էությունը SSD-ների օգտագործումն է որպես միջանկյալ քեշ կոշտ սկավառակների և վերահսկիչի RAM-ի միջև: SSD-ի կատարումը, իհարկե, ավելի ցածր է, քան վերահսկիչի սեփական քեշի կատարումը, բայց ծավալը մեծության կարգով ավելի բարձր է: Հետևաբար, մենք ստանում ենք որոշակի փոխզիջում արագության և ծավալի միջև:
Ընթերցանության համար SSD քեշի օգտագործման ցուցումներ.
- Ընթերցանության գործողությունների գերակշռությունը գրելու գործողությունների նկատմամբ (առավել հաճախ բնորոշ է տվյալների բազաների և վեբ հավելվածների համար);
- Կոշտ սկավառակի զանգվածի կատարման տեսքով խցանման առկայություն.
- Պահանջվող տվյալների քանակը պակաս է SSD քեշի չափից:
«Կարդալ+գրել» SSD քեշի օգտագործման ցուցումները նույնն են, բացառությամբ գործողությունների բնույթի՝ խառը տիպի (օրինակ՝ ֆայլերի սերվեր):
Պահեստավորման վաճառողներից շատերն իրենց արտադրանքներում օգտագործում են միայն կարդալու SSD քեշ: Հիմնարար տարբերությունը Նրանք հնարավորություն են տալիս օգտագործել քեշը նաև գրելու համար: QSAN պահեստավորման համակարգերում SSD քեշավորման գործառույթն ակտիվացնելու համար դուք պետք է գնեք առանձին լիցենզիա (տրամադրվում է էլեկտրոնային եղանակով):
SSD քեշը XCubeSAN-ում ֆիզիկապես ներդրված է առանձին SSD քեշ լողավազանների տեսքով: Համակարգում դրանք կարող են լինել մինչև չորսը: Յուրաքանչյուր լողավազան, իհարկե, օգտագործում է SSD-ների իր հավաքածուն: Եվ արդեն վիրտուալ սկավառակի հատկություններում մենք որոշում ենք, թե արդյոք այն կօգտագործի քեշ լողավազան և որը: Հատորների համար քեշի օգտագործումը միացնելն ու անջատելը կարող է կատարվել առցանց՝ առանց I/O-ի դադարեցման: Կարող եք նաև տաք ավելացնել SSD-ներ լողավազանում և հեռացնել դրանք այնտեղից: SSD pool cache ստեղծելիս պետք է ընտրել, թե ինչ ռեժիմով է այն աշխատելու՝ միայն կարդալու կամ կարդալու+գրելու: Դրա ֆիզիկական կազմակերպումը կախված է սրանից։ Քանի որ կարող են լինել մի քանի քեշ լողավազաններ, դրանց ֆունկցիոնալությունը կարող է տարբեր լինել (այսինքն՝ համակարգը կարող է միաժամանակ ունենալ և՛ կարդալու, և՛ կարդալու+գրելու քեշ լողավազաններ)։
Եթե օգտագործվում է միայն կարդալու քեշի լողավազան, այն կարող է բաղկացած լինել 1-8 SSD-ից: Սկավառակները պարտադիր չէ, որ լինեն նույն հզորությամբ և նույն վաճառողով, քանի որ դրանք միավորված են NRAID+ կառուցվածքում: Լողավազանի բոլոր SSD-ները համօգտագործված են: Համակարգն ինքնուրույն փորձում է մուտքային հարցումները զուգահեռացնել բոլոր SSD-ների միջև՝ առավելագույն արդյունավետության հասնելու համար: Եթե SSD-ներից մեկը ձախողվի, ոչ մի վատ բան տեղի չի ունենա. ի վերջո, քեշը պարունակում է կոշտ սկավառակների զանգվածում պահվող տվյալների միայն պատճենը: Պարզապես հասանելի SSD քեշի քանակը կնվազի (կամ կդառնա զրո, եթե օգտագործեք բնօրինակ SSD քեշը մեկ սկավառակից):
Եթե քեշը օգտագործվում է կարդալ + գրել գործողությունների համար, ապա լողավազանում SSD-ների թիվը պետք է լինի երկուսի բազմապատիկ, քանի որ բովանդակությունը արտացոլված է զույգ կրիչներով (օգտագործվում է NRAID 1+ կառուցվածքը): Քեշի կրկնօրինակումը անհրաժեշտ է, քանի որ այն կարող է պարունակել տվյալներ, որոնք դեռ չեն գրվել կոշտ սկավառակների վրա: Եվ այս դեպքում, SSD-ի ձախողումը քեշի լողավազանից կհանգեցներ տեղեկատվության կորստի: NRAID 1+-ի դեպքում, SSD-ի ձախողումը պարզապես կհանգեցնի նրան, որ քեշը կփոխանցվի միայն կարդալու վիճակի, իսկ չգրված տվյալները կթափվեն կոշտ սկավառակի զանգվածի վրա: Սխալ SSD-ը փոխարինելուց հետո քեշը կվերադառնա իր սկզբնական աշխատանքային ռեժիմին: Ի դեպ, ավելի մեծ անվտանգության համար կարող եք հատուկ տաք պահեստամասեր հատկացնել կարդալու + գրելու քեշին:
XCubeSAN-ում SSD քեշավորման գործառույթն օգտագործելիս մի շարք պահանջներ կան պահեստավորման կարգավորիչների հիշողության քանակի համար. որքան շատ լինի համակարգի հիշողությունը, այնքան մեծ կլինի քեշի լողավազանը:
Ի տարբերություն պահեստավորման համակարգերի արտադրողների մեծամասնության, որոնք առաջարկում են միայն SSD քեշը միացնելու/անջատելու տարբերակ, QSAN-ն ավելի շատ տարբերակներ է տրամադրում: Մասնավորապես, դուք կարող եք ընտրել քեշի գործող ռեժիմը կախված բեռի բնույթից: Կան երեք նախադրված ձևանմուշներ, որոնք իրենց գործողությամբ ամենամոտ են համապատասխան ծառայություններին՝ տվյալների բազա, ֆայլային համակարգ, վեբ ծառայություն: Բացի այդ, ադմինիստրատորը կարող է ստեղծել իր սեփական պրոֆիլը՝ սահմանելով անհրաժեշտ պարամետրերի արժեքները.
- Բլոկի չափը (Cache Block Size) – 1/2/4 ՄԲ
- Բլոկը կարդալու հարցումների քանակն այնպես, որ այն պատճենվի քեշում (Ընթերցման շեմ)՝ 1..4
- Բլոկ գրելու հարցումների քանակն այնպես, որ այն պատճենվի քեշում (Populate-on-Write Threshold) – 0..4
Պրոֆիլները կարող են փոփոխվել անմիջապես, բայց, իհարկե, քեշի վերակայման բովանդակությամբ և դրա նոր «տաքացումով»:
Հաշվի առնելով SSD քեշի շահագործման սկզբունքը, մենք կարող ենք առանձնացնել հիմնական գործողությունները դրա հետ աշխատելիս.
Տվյալների ընթերցում, երբ դրանք քեշում չեն
- Հյուրընկալողի խնդրանքը հասնում է վերահսկիչին.
- Քանի որ պահանջվածները չկան SSD քեշում, դրանք կարդացվում են կոշտ սկավառակներից;
- Ընթերցված տվյալները ուղարկվում են հյուրընկալողին: Միևնույն ժամանակ ստուգվում է, թե արդյոք այդ բլոկները «տաք» են.
- Եթե այո, ապա դրանք պատճենվում են SSD քեշում՝ հետագա օգտագործման համար:
Կարդացեք տվյալները, երբ դրանք առկա են քեշում
- Հյուրընկալողի խնդրանքը հասնում է վերահսկիչին.
- Քանի որ պահանջվող տվյալները գտնվում են SSD քեշում, այն կարդացվում է այնտեղից.
- Ընթերցված տվյալները ուղարկվում են հյուրընկալողին:
Տվյալներ գրելը կարդալու քեշը օգտագործելիս
- Հյուրընկալողից գրելու հարցումը հասնում է վերահսկիչին.
- Տվյալները գրվում են կոշտ սկավառակների վրա;
- Պատասխանը, որը ցույց է տալիս հաջող ձայնագրությունը, վերադարձվում է հյուրընկալողին.
- Միևնույն ժամանակ, ստուգվում է, թե արդյոք բլոկը «տաք» է (համեմատվում է «Populate-on-Write Threshold» պարամետրը): Եթե այո, ապա այն պատճենվում է SSD քեշում՝ հետագայում օգտագործելու համար:
Տվյալներ գրելը կարդալու+գրելու քեշի օգտագործման ժամանակ
- Հյուրընկալողից գրելու հարցումը հասնում է վերահսկիչին.
- Տվյալները գրվում են SSD քեշում;
- Պատասխանը, որը ցույց է տալիս հաջող ձայնագրությունը, վերադարձվում է հյուրընկալողին.
- SSD քեշից տվյալները գրվում են ֆոնային կոշտ սկավառակների վրա.
Ստուգեք գործողության մեջ
Փորձարկման տակդիր
2 սերվեր (CPU՝ 2 x Xeon E5-2620v3 2.4Hz / RAM՝ 32 ԳԲ) միացված են երկու նավահանգիստներով Fiber Channel 16G-ի միջոցով անմիջապես XCubeSAN XS5224D պահեստավորման համակարգին (16GB RAM/կարգավորիչ):
Մենք օգտագործել ենք 16 x Seagate Constellation ES, ST500NM0001, 500 ԳԲ, SAS 6 Գբ/վրկ, համակցված RAID5-ում (15+1), տվյալների զանգվածի համար և 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, SSS100, SAS12, ca.
Ստեղծվել է 2 հատոր՝ մեկը յուրաքանչյուր սերվերի համար։
Փորձարկում 1. SSD միայն կարդալու քեշ 1-8 SSD-ից
SSD քեշ
- I/O տեսակը՝ անհատականացում
- Քեշի բլոկի չափը՝ 4 ՄԲ
- Լրացրեք ընթերցման շեմը՝ 1
- Լրացնել գրելու շեմը՝ 0
I/O նախշ
- Գործիք՝ IOmeter V1.1.0
- Աշխատողներ՝ 1
- Հատկանշական (հերթի խորություն): 128
- Մուտքի բնութագրերը՝ 4KB, 100% ընթերցված, 100% պատահական
Տեսականորեն, որքան շատ SSD-ներ քեշի լողավազանում, այնքան բարձր է կատարումը: Գործնականում դա հաստատվել է։ Փոքր քանակությամբ ծավալներով SSD-ների քանակի միակ զգալի աճը պայթյունավտանգ էֆեկտի չի հանգեցնում։
Փորձարկում 2. SSD քեշը կարդալու + գրելու ռեժիմում՝ 2-8 SSD-ով
SSD քեշ
- I/O տեսակը՝ անհատականացում
- Քեշի բլոկի չափը՝ 4 ՄԲ
- Լրացրեք ընթերցման շեմը՝ 1
- Լրացնել գրելու շեմը՝ 1
I/O նախշ
- Գործիք՝ IOmeter V1.1.0
- Աշխատողներ՝ 1
- Հատկանշական (հերթի խորություն): 128
- Մուտքի բնութագրերը՝ 4KB, 100% գրել, 100% պատահական
Նույն արդյունքը. պայթուցիկ կատարողականի աճ և մասշտաբացում SSD-ների քանակի աճով:
Երկու թեստերում էլ աշխատանքային տվյալների քանակը պակաս էր ընդհանուր քեշի չափից: Հետեւաբար, ժամանակի ընթացքում բոլոր բլոկները պատճենվեցին քեշում: Իսկ աշխատանքն, ըստ էության, արդեն իրականացվել է SSD-ներով՝ գործնականում առանց կոշտ սկավառակների վրա ազդելու։ Այս թեստերի նպատակն էր հստակ ցույց տալ քեշը տաքացնելու և դրա կատարողականությունը մեծացնելու արդյունավետությունը՝ կախված SSD-ների քանակից:
Հիմա եկեք վերադառնանք երկիր և ստուգենք ավելի իրատեսական իրավիճակը, երբ տվյալների քանակն ավելի մեծ է, քան քեշի չափը: Որպեսզի թեստն անցնի ողջամիտ ժամկետում (քեշի «տաքացման» ժամանակահատվածը մեծապես մեծանում է ձայնի ծավալի մեծացմանը զուգընթաց), մենք կսահմանափակենք ձայնի ծավալը մինչև 120 ԳԲ:
Թեստ 3. Տվյալների բազայի էմուլյացիա
SSD քեշ
- I/O տեսակը՝ տվյալների բազա
- Քեշի բլոկի չափը՝ 1 ՄԲ
- Լրացրեք ընթերցման շեմը՝ 2
- Լրացնել գրելու շեմը՝ 1
I/O նախշ
- Գործիք՝ IOmeter V1.1.0
- Աշխատողներ՝ 1
- Հատկանշական (հերթի խորություն): 128
- Մուտքի բնութագրերը՝ 8KB, 67% ընթերցված, 100% պատահական
Դատավճիռ
Ակնհայտ եզրակացությունը, իհարկե, SSD քեշի օգտագործման լավ արդյունավետությունն է ցանկացած պահեստավորման համակարգի աշխատանքը բարելավելու համար: Կիրառվել է Այս հայտարարությունը լիովին կիրառվում է. SSD քեշավորման գործառույթը կատարյալ է իրականացվում: Սա վերաբերում է կարդալու և կարդալու + գրելու ռեժիմների աջակցությանը, օգտագործման ցանկացած սցենարի համար ճկուն կարգավորումներին, ինչպես նաև ամբողջ համակարգի ընդհանուր աշխատանքին: Հետևաբար, շատ ողջամիտ գնի համար (լիցենզիայի գինը համեմատելի է 1-2 SSD-ի արժեքի հետ), կարող եք զգալիորեն բարձրացնել ընդհանուր կատարումը:
Source: www.habr.com