Այս հոդվածում ես կցանկանայի խոսել բոլոր Flash AccelStor զանգվածների առանձնահատկությունների մասին, որոնք աշխատում են վիրտուալացման ամենահայտնի հարթակներից մեկի՝ VMware vSphere-ի հետ: Մասնավորապես, կենտրոնացեք այն պարամետրերի վրա, որոնք կօգնեն ձեզ առավելագույն ազդեցություն ստանալ այնպիսի հզոր գործիքից, ինչպիսին All Flash-ն է:
AccelStor NeoSapphire™ Բոլոր Flash զանգվածներն են կամ հանգույցային սարքեր, որոնք հիմնված են SSD կրիչների վրա՝ հիմնովին այլ մոտեցմամբ տվյալների պահպանման հայեցակարգի իրականացման և դրան հասանելիության կազմակերպման համար՝ օգտագործելով սեփական տեխնոլոգիան շատ հայտնի RAID ալգորիթմների փոխարեն: Զանգվածները ապահովում են բլոկային մուտք դեպի հոսթինգ Fiber Channel կամ iSCSI միջերեսների միջոցով: Արդարության համար մենք նշում ենք, որ ISCSI ինտերֆեյս ունեցող մոդելները նաև ֆայլերի հասանելիություն ունեն որպես հաճելի բոնուս: Բայց այս հոդվածում մենք կկենտրոնանանք բլոկային արձանագրությունների օգտագործման վրա՝ որպես բոլոր Flash-ի համար ամենաարդյունավետը:
AccelStor զանգվածի և VMware vSphere վիրտուալացման համակարգի տեղակայման և հետագա կազմաձևման ամբողջ գործընթացը կարելի է բաժանել մի քանի փուլերի.
- Միացման տոպոլոգիայի իրականացում և SAN ցանցի կոնֆիգուրացիա;
- Բոլոր Flash զանգվածի կարգավորում;
- ESXi հոսթերի կազմաձևում;
- Վիրտուալ մեքենաների տեղադրում:
AccelStor NeoSapphire™ օպտիկամանրաթելային ալիքների զանգվածները և iSCSI զանգվածները օգտագործվել են որպես նմուշային սարքավորում: Հիմնական ծրագրաշարը VMware vSphere 6.7U1 է:
Նախքան այս հոդվածում նկարագրված համակարգերը տեղակայելը, խորհուրդ է տրվում կարդալ VMware-ի փաստաթղթերը կատարողական խնդիրների վերաբերյալ ( ) և iSCSI կարգավորումներ ()
Միացման տոպոլոգիա և SAN ցանցի կոնֆիգուրացիա
SAN ցանցի հիմնական բաղադրիչներն են HBA-ները ESXi հոստերում, SAN անջատիչները և զանգվածային հանգույցները: Նման ցանցի բնորոշ տոպոլոգիան այսպիսի տեսք կունենա.
Switch տերմինն այստեղ վերաբերում է և՛ առանձին ֆիզիկական անջատիչին կամ անջատիչների հավաքածուին (Fabric), և՛ սարքին, որը համօգտագործվում է տարբեր ծառայությունների միջև (VSAN Fiber Channel-ի դեպքում և VLAN՝ iSCSI-ի դեպքում): Երկու անկախ անջատիչների/գործվածքների օգտագործումը կվերացնի ձախողման հնարավոր կետը:
Հոսթերների ուղիղ միացումը զանգվածին, թեև աջակցվում է, խորհուրդ չի տրվում: Բոլոր Flash զանգվածների կատարումը բավականին բարձր է։ Իսկ առավելագույն արագության համար զանգվածի բոլոր պորտերը պետք է օգտագործվեն։ Հետևաբար, առնվազն մեկ անջատիչի առկայությունը հյուրընկալողների և NeoSapphire™-ի միջև պարտադիր է:
Հյուրընկալող HBA-ի վրա երկու նավահանգիստների առկայությունը նույնպես պարտադիր պահանջ է առավելագույն արդյունավետության հասնելու և սխալների հանդուրժողականություն ապահովելու համար:
Օպտիկամանրաթելային ալիքի միջերես օգտագործելիս գոտիավորումը պետք է կազմաձևվի նախաձեռնողների և թիրախների միջև հնարավոր բախումները վերացնելու համար: Գոտիները կառուցված են «մեկ նախաձեռնող նավահանգիստ – մեկ կամ մի քանի զանգվածի պորտ» սկզբունքով:
Եթե դուք օգտագործում եք կապ iSCSI-ի միջոցով այլ ծառայությունների հետ համօգտագործվող անջատիչ օգտագործելու դեպքում, ապա պարտադիր է մեկուսացնել iSCSI տրաֆիկը առանձին VLAN-ում: Նաև շատ խորհուրդ է տրվում միացնել Jumbo Frames-ի աջակցությունը (MTU = 9000)՝ ցանցում փաթեթների չափը մեծացնելու և այդպիսով նվազեցնելու հաղորդման ընթացքում վերադիր տեղեկատվության քանակը: Այնուամենայնիվ, հարկ է հիշել, որ ճիշտ աշխատանքի համար անհրաժեշտ է փոխել MTU պարամետրը ցանցի բոլոր բաղադրիչների վրա «նախաձեռնող-անջատիչ-թիրախ» շղթայի երկայնքով:
Ամբողջ Flash զանգվածի կարգավորում
Զանգվածը առաքվում է արդեն ձևավորված խմբերով հաճախորդներին . Հետևաբար, ոչ մի գործողություններ պետք չէ ձեռնարկել սկավառակները մեկ կառույցի մեջ միավորելու համար: Պարզապես անհրաժեշտ է պահանջվող չափի և քանակի ծավալներ ստեղծել։
Հարմարության համար առկա է տվյալ չափի միանգամից մի քանի հատորների խմբաքանակի ստեղծման գործառույթ: Լռելյայնորեն ստեղծվում են բարակ ծավալներ, քանի որ դա թույլ է տալիս ավելի արդյունավետ օգտագործել առկա պահեստային տարածքը (ներառյալ Space Reclamation-ի աջակցությունը): Կատարման առումով «բարակ» և «հաստ» ծավալների տարբերությունը չի գերազանցում 1%-ը։ Այնուամենայնիվ, եթե ցանկանում եք «քամել ամբողջ հյութը» զանգվածից, միշտ կարող եք ցանկացած «բարակ» ծավալը վերածել «հաստի»: Բայց պետք է հիշել, որ նման վիրահատությունն անշրջելի է։
Այնուհետև մնում է «հրապարակել» ստեղծված ծավալները և մուտքի իրավունքներ սահմանել հոսթներից՝ օգտագործելով ACL-ները (IP հասցեներ iSCSI-ի և WWPN-ի համար FC-ի համար) և ֆիզիկական տարանջատում զանգվածային նավահանգիստներով: iSCSI մոդելների համար դա արվում է Target ստեղծելու միջոցով:
FC մոդելների համար հրապարակումը տեղի է ունենում զանգվածի յուրաքանչյուր պորտի համար LUN ստեղծելու միջոցով:
Կարգավորման գործընթացը արագացնելու համար հյուրընկալողները կարող են միավորվել խմբերի: Ավելին, եթե հոսթն օգտագործում է բազմապորտ FC HBA (ինչը գործնականում ամենից հաճախ տեղի է ունենում), ապա համակարգը ավտոմատ կերպով որոշում է, որ այդպիսի HBA-ի նավահանգիստները պատկանում են մեկ հոսթին՝ շնորհիվ մեկով տարբերվող WWPN-ների: Target/LUN-ի խմբաքանակի ստեղծումը նույնպես աջակցվում է երկու ինտերֆեյսների համար:
iSCSI ինտերֆեյսը օգտագործելիս կարևոր նշում է ծավալների համար միանգամից մի քանի թիրախներ ստեղծելը՝ կատարողականը բարձրացնելու համար, քանի որ թիրախի հերթը չի կարող փոխվել և արդյունավետորեն խցանման խնդիր կլինի:
ESXi հոստերի կազմաձևում
ESXi հյուրընկալող կողմում հիմնական կոնֆիգուրացիան կատարվում է լիովին սպասված սցենարի համաձայն: iSCSI միացման կարգը.
- Ավելացնել ծրագրակազմ iSCSI ադապտեր (չի պահանջվում, եթե այն արդեն ավելացվել է, կամ եթե դուք օգտագործում եք ապարատային iSCSI ադապտեր);
- vSwitch-ի ստեղծում, որի միջով կանցնի iSCSI տրաֆիկը, և դրան ավելացրեք ֆիզիկական վերելք և VMkernal;
- Զանգվածի հասցեների ավելացում Dynamic Discovery-ին;
- Տվյալների պահեստի ստեղծում
Որոշ կարևոր նշումներ.
- Ընդհանուր դեպքում, իհարկե, կարող եք օգտագործել գոյություն ունեցող vSwitch-ը, բայց առանձին vSwitch-ի դեպքում հոսթի կարգավորումները կառավարելը շատ ավելի հեշտ կլինի։
- Անհրաժեշտ է առանձնացնել Կառավարման և iSCSI տրաֆիկը առանձին ֆիզիկական հղումների և/կամ VLAN-ների վրա՝ կատարողականի հետ կապված խնդիրներից խուսափելու համար:
- VMkernal-ի IP հասցեները և All Flash զանգվածի համապատասխան նավահանգիստները պետք է լինեն նույն ենթացանցում, կրկին աշխատանքի հետ կապված խնդիրների պատճառով:
- VMware կանոնների համաձայն սխալների հանդուրժողականություն ապահովելու համար vSwitch-ը պետք է ունենա առնվազն երկու ֆիզիկական վերելք
- Եթե օգտագործվում են Jumbo Frames, դուք պետք է փոխեք ինչպես vSwitch-ի, այնպես էլ VMkernal-ի MTU-ն
- Օգտակար կլինի հիշեցնել ձեզ, որ համաձայն VMware-ի առաջարկությունների ֆիզիկական ադապտերների համար, որոնք կօգտագործվեն iSCSI տրաֆիկի հետ աշխատելու համար, անհրաժեշտ է կարգավորել Teaming-ը և Failover-ը: Մասնավորապես, յուրաքանչյուր VMkernal պետք է աշխատի միայն մեկ վերելքի միջոցով, երկրորդ վերելքը պետք է անցնի չօգտագործված ռեժիմի: Սխալների հանդուրժողականության համար դուք պետք է ավելացնեք երկու VMkernals, որոնցից յուրաքանչյուրը կաշխատի իր վերելքի միջոցով:
VMkernel ադապտեր (vmk#)
Ֆիզիկական ցանցի ադապտեր (vmnic#)
vmk1 (Storage01)
Ակտիվ ադապտերներ
vmnic2
Չօգտագործված ադապտերներ
vmnic3
vmk2 (Storage02)
Ակտիվ ադապտերներ
vmnic3
Չօգտագործված ադապտերներ
vmnic2
Fiber Channel-ով միանալու համար նախնական քայլեր չեն պահանջվում: Դուք կարող եք անմիջապես ստեղծել Datastore:
Datastore-ը ստեղծելուց հետո դուք պետք է համոզվեք, որ Round Robin քաղաքականությունը դեպի Target/LUN ուղիներն օգտագործվում է որպես առավել արդյունավետ:
Լռելյայնորեն, VMware-ի կարգավորումները նախատեսում են այս քաղաքականության օգտագործումը ըստ սխեմայի՝ 1000 հարցում առաջին ճանապարհով, հաջորդ 1000 հարցում՝ երկրորդ ճանապարհով և այլն: Հոսթի և երկու վերահսկիչի զանգվածի միջև նման փոխազդեցությունը անհավասարակշիռ կլինի: Հետևաբար, խորհուրդ ենք տալիս սահմանել Round Robin քաղաքականությունը = 1 պարամետր Esxcli/PowerCLI-ի միջոցով:
Պարամետրեր
Esxcli-ի համար.
- Ցուցակեք հասանելի LUN-ները
esxcli պահեստավորման nmp սարքերի ցանկը
- Պատճենել սարքի անունը
- Փոփոխել «Round Robin» քաղաքականությունը
esxcli պահեստավորման nmp psp roundrobin սարքի կազմաձևման հավաքածու —type=iops —iops=1 —device=«Device_ID»
Ժամանակակից հավելվածների մեծ մասը նախագծված է տվյալների մեծ փաթեթներ փոխանակելու համար՝ առավելագույնի հասցնելու թողունակության օգտագործումը և նվազեցնելու պրոցեսորի ծանրաբեռնվածությունը: Հետևաբար, ESXi-ն լռելյայնորեն մուտքի/ելք պահանջները թողարկում է պահեստային սարքին մինչև 32767 ԿԲ ծավալով: Այնուամենայնիվ, որոշ սցենարների համար ավելի արդյունավետ կլինի ավելի փոքր կտորների փոխանակումը: AccelStor զանգվածների համար սրանք հետևյալ սցենարներն են.
- Վիրտուալ մեքենան օգտագործում է UEFI՝ Legacy BIOS-ի փոխարեն
- Օգտագործում է vSphere Replication
Նման սցենարների համար խորհուրդ է տրվում փոխել Disk.DiskMaxIOSize պարամետրի արժեքը 4096-ի:
iSCSI միացումների համար խորհուրդ է տրվում փոխել Login Timeout պարամետրը 30-ի (կանխադրված 5) միացման կայունությունը բարձրացնելու և DelayedAck-ի հետաձգումն անջատելու համար՝ փոխանցված փաթեթների հաստատման համար: Երկու տարբերակներն էլ գտնվում են vSphere Client-ում. Host → Կազմաձևել → Storage → Storage Adapters → Advanced Options for iSCSI adapter
Բավական նուրբ կետը տվյալների պահեստի համար օգտագործվող ծավալների քանակն է: Հասկանալի է, որ կառավարման հեշտության համար ցանկություն կա ստեղծել մեկ մեծ ծավալ զանգվածի ամբողջ ծավալի համար։ Այնուամենայնիվ, մի քանի հատորների և, համապատասխանաբար, տվյալների պահեստի առկայությունը բարենպաստ ազդեցություն ունի ընդհանուր կատարողականի վրա (հերթերի մասին ավելին ստորև): Ուստի խորհուրդ ենք տալիս ստեղծել առնվազն երկու հատոր:
Մինչև համեմատաբար վերջերս VMware-ը խորհուրդ էր տալիս սահմանափակել վիրտուալ մեքենաների քանակը մեկ տվյալների շտեմարանում՝ կրկին հնարավորինս բարձր արդյունավետություն ստանալու համար: Սակայն այժմ, հատկապես VDI-ի տարածման հետ մեկտեղ, այս խնդիրն այլեւս այնքան էլ սուր չէ։ Բայց դա չի չեղարկում երկարաժամկետ կանոնը՝ տարածել վիրտուալ մեքենաներ, որոնք պահանջում են ինտենսիվ IO տարբեր տվյալների պահեստներում: Մեկ ծավալի համար վիրտուալ մեքենաների օպտիմալ քանակը որոշելու համար ավելի լավ բան չկա, քան իր ենթակառուցվածքի շրջանակներում:
Վիրտուալ մեքենաների տեղադրում
Վիրտուալ մեքենաներ կարգավորելիս հատուկ պահանջներ չկան, ավելի ճիշտ դրանք բավականին սովորական են.
- Օգտագործելով հնարավոր ամենաբարձր VM տարբերակը (համատեղելիություն)
- Ավելի զգույշ է RAM-ի չափը սահմանել վիրտուալ մեքենաները խիտ տեղադրելու ժամանակ, օրինակ, VDI-ում (քանի որ լռելյայն, գործարկման ժամանակ ստեղծվում է RAM-ին համարժեք չափի էջի ֆայլ, որը սպառում է օգտակար հզորությունը և ազդում է. վերջնական կատարում)
- Օգտագործեք IO-ի առումով ադապտերների ամենաարդյունավետ տարբերակները՝ ցանցի տեսակ VMXNET 3 և SCSI տիպ PVSCSI
- Օգտագործեք Thick Provision Eager Zeroed սկավառակի տեսակը առավելագույն կատարողականության համար և Thin Provisioning՝ պահեստային տարածքի առավելագույն օգտագործման համար
- Հնարավորության դեպքում սահմանափակեք ոչ I/O կրիտիկական մեքենաների աշխատանքը՝ օգտագործելով Վիրտուալ սկավառակի սահմանաչափը
- Համոզվեք, որ տեղադրեք VMware Tools-ը
Նշումներ հերթերի վերաբերյալ
Հերթը (կամ ակնառու I/O-ները) մուտքային/ելքային հարցումների (SCSI հրամաններ) քանակն է, որոնք ցանկացած պահի սպասում են մշակման կոնկրետ սարքի/հավելվածի համար: Հերթի արտահոսքի դեպքում թողարկվում են QFULL սխալներ, որոնք, ի վերջո, հանգեցնում են latency պարամետրի ավելացմանը։ Սկավառակի (spindle) պահեստավորման համակարգեր օգտագործելիս, տեսականորեն, որքան մեծ է հերթը, այնքան բարձր է դրանց կատարումը: Այնուամենայնիվ, դուք չպետք է չարաշահեք այն, քանի որ հեշտ է բախվել QFULL-ի հետ: Բոլոր Flash համակարգերի դեպքում, մի կողմից, ամեն ինչ մի փոքր ավելի պարզ է. ի վերջո, զանգվածն ունի ուշացումներ, որոնք մեծության կարգերով ավելի ցածր են, և, հետևաբար, ամենից հաճախ հերթերի չափը առանձին կարգավորելու կարիք չկա: Բայց մյուս կողմից, որոշ օգտագործման սցենարներում (կոնկրետ վիրտուալ մեքենաների համար IO պահանջների ուժեղ շեղում, առավելագույն կատարողականության թեստեր և այլն) անհրաժեշտ է, եթե ոչ փոխել հերթերի պարամետրերը, ապա գոնե հասկանալ, թե ինչ ցուցանիշներ են: կարելի է հասնել, և գլխավորն այն է, թե ինչ ճանապարհներով։
Ինքնին AccelStor All Flash զանգվածում ծավալների կամ I/O պորտերի հետ կապված սահմանափակումներ չկան: Անհրաժեշտության դեպքում, նույնիսկ մեկ հատորը կարող է ստանալ զանգվածի բոլոր ռեսուրսները: Հերթի միակ սահմանափակումը iSCSI թիրախների համար է: Այս պատճառով է, որ վերևում նշվեց յուրաքանչյուր հատորի համար մի քանի (իդեալականորեն մինչև 8 կտոր) թիրախներ ստեղծելու անհրաժեշտությունը՝ այս սահմանը հաղթահարելու համար։ Կրկնենք նաև, որ AccelStor զանգվածները շատ արդյունավետ լուծումներ են։ Հետևաբար, դուք պետք է օգտագործեք համակարգի բոլոր ինտերֆեյսի նավահանգիստները առավելագույն արագության հասնելու համար:
ESXi հյուրընկալող կողմում իրավիճակը բոլորովին այլ է: Հյուրընկալողն ինքը կիրառում է բոլոր մասնակիցների համար ռեսուրսների հավասար հասանելիության պրակտիկան: Հետևաբար, հյուրերի OS-ի և HBA-ի համար կան առանձին IO հերթեր: Հյուր OS-ի հերթերը համակցված են հերթերից մինչև վիրտուալ SCSI ադապտեր և վիրտուալ սկավառակ.
HBA-ի հերթը կախված է կոնկրետ տեսակից/վաճառողից.
Վիրտուալ մեքենայի վերջնական կատարումը որոշվելու է հյուրընկալող բաղադրիչների միջև հերթի խորության նվազագույն սահմանաչափով:
Այս արժեքների շնորհիվ մենք կարող ենք գնահատել կատարողականի ցուցանիշները, որոնք մենք կարող ենք ստանալ որոշակի կոնֆիգուրացիայի մեջ: Օրինակ, մենք ուզում ենք իմանալ վիրտուալ մեքենայի տեսական կատարումը (առանց բլոկների կապի) 0.5 մվ ուշացումով: Այնուհետև դրա IOPS = (1,000/ուշացում) * Չմարված I/Os (հերթի խորության սահման)
օրինակները
Օրինակ 1
- FC Emulex HBA ադապտեր
- Մեկ VM յուրաքանչյուր տվյալների պահեստում
- VMware Paravirtual SCSI ադապտեր
Այստեղ Հերթի խորության սահմանաչափը որոշվում է Emulex HBA-ի կողմից: Հետեւաբար IOPS = (1000/0.5) * 32 = 64K
Օրինակ 2
- VMware iSCSI ծրագրային ապահովման ադապտեր
- Մեկ VM յուրաքանչյուր տվյալների պահեստում
- VMware Paravirtual SCSI ադապտեր
Այստեղ հերթի խորության սահմանն արդեն որոշված է Paravirtual SCSI Adapter-ի կողմից: Հետեւաբար IOPS = (1000/0.5) * 64 = 128K
Բոլոր Flash AccelStor զանգվածների լավագույն մոդելները (օրինակ, ) կարող են ապահովել 700K IOPS գրելու կատարում 4K բլոկում: Նման բլոկի չափի դեպքում միանգամայն ակնհայտ է, որ մեկ վիրտուալ մեքենան ի վիճակի չէ բեռնել նման զանգված: Դա անելու համար ձեզ հարկավոր է 11 (օրինակ 1) կամ 6 (օրինակ 2) վիրտուալ մեքենաներ:
Արդյունքում, վիրտուալ տվյալների կենտրոնի բոլոր նկարագրված բաղադրիչների ճիշտ կազմաձևման դեպքում դուք կարող եք շատ տպավորիչ արդյունքներ ստանալ կատարողականի առումով:
4K պատահական, 70% կարդալ/30% գրել
Իրականում իրական աշխարհը շատ ավելի բարդ է, քան կարելի է նկարագրել պարզ բանաձեւով։ Մեկ հոսթ միշտ հյուրընկալում է բազմաթիվ վիրտուալ մեքենաներ՝ տարբեր կոնֆիգուրացիաներով և IO պահանջներով: Իսկ I/O պրոցեսինգը վարում է հյուրընկալող պրոցեսորը, որի հզորությունը անսահման չէ: Այսպիսով, բացելու նույնի ամբողջ ներուժը իրականում ձեզ անհրաժեշտ կլինի երեք հյուրընկալող: Բացի այդ, վիրտուալ մեքենաների ներսում աշխատող հավելվածները կատարում են իրենց սեփական ճշգրտումները: Հետևաբար, ճշգրիտ չափագրման համար մենք առաջարկում ենք Բոլոր Flash զանգվածները հաճախորդի ենթակառուցվածքի ներսում իրական ընթացիկ առաջադրանքների վերաբերյալ:
Source: www.habr.com