Ինչպես ենք փորձարկում HCI կլաստերները. հանգույցի կորուստ և p99

HCI-ի չափավորման աղյուսակը պատասխանում է մեկ հարցի՝ քանի VM կտեղավորվի 4 հանգույցի վրա, եթե մեկը պահվում է պահուստում։ Այն հաշվարկվում է առողջ կլաստերի համար։ Գնորդը կարդում է «N+1» և սպասում, որ հանգույցի կորուստը կարժենա հզորության մեկ քառորդը։ Իրականում մնացած հանգույցները վերականգնում են կորած պատճենները (rebuild) նույն 25G uplink-ներով, որոնցով անցնում են VM-ների տրաֆիկը և յուրաքանչյուր ռեպլիկացվող գրառում։ Մենք չափում ենք երկու թիվ՝ VM-ների I/O latency p99-ը յուրաքանչյուր իրադարձության ընթացքում և այն ժամանակը, որից հետո տվյալները կրկին լիովին պաշտպանված են։

Ստենդը

Կլաստերը Ձերն է՝ 3-ից 8 հանգույց ռեկում, կամ ծրագրային պլատֆորմը լաբորատորիայի հիպերվիզորի վրա։ Յուրաքանչյուր հանգույց ստանում է 2 uplink 25G-ով (breakout 100G պորտերից) դեպի ToR զույգը՝ Ձեր կոնֆիգուրացիայի արտահանմամբ՝ VLAN-ներ VM-ների, պահեստավորման, live migration-ի և կառավարման համար, MTU, LACP, QoS map։ Պահեստավորման շերտն աշխատում է այնպես, ինչպես Դուք եք պլանավորում՝ ռեպլիկացիայի գործակից կամ erasure coding, rebuild-ի առաջնահերթություն, խափանման տիրույթներ։

Յուրաքանչյուր հանգույցի բեռնող VM-ները գործարկում են Ձեր I/O պրոֆիլը՝ բլոկների չափերը, ընթերցման և գրառման հարաբերակցությունը և հերթի խորությունը Ձեր բեռնվածության վիճակագրությունից, տվյալների հավաքածուի վրա, որը լցված է մինչև այն մակարդակը, որը սպասում եք մեկ տարի անց։ Գեներատորի պորտերը հավելվածների տրաֆիկը դնում են նույն uplink-ների վրա։ Latency-ն գրանցում ենք յուրաքանչյուր VM-ի համար, կոմուտատորի հաշվիչները՝ ըստ պորտերի և հերթերի, և հանգույցների միջև տրաֆիկը երևում է VM-ների տրաֆիկից առանձին։

Ինչ ենք ստուգում

• Բազային գիծ. VM-ների I/O latency p50 և p99 ըստ բլոկի չափի առողջ կլաստերում, VM-ների քանակն աճում է, մինչև p99-ը դուրս գա Ձեր չափանիշից
• East-west. ռեպլիկացիայի և VM-ների տրաֆիկը յուրաքանչյուր uplink-ում, և VM-ների այն քանակը, որի դեպքում 25G կապուղին հագենում է սկավառակներից շուտ
• Հանգույցի կորուստ. հանգույցն անջատվում է I/O-ի ընթացքում, կանգը յուրաքանչյուր VM-ի համար՝ վերջին ավարտված գործողությունից մինչև առաջին վերադարձածը, և երբ են այդ հանգույցի VM-ները կրկին աշխատում այլ հանգույցներում
• Rebuild. ժամանակը մինչև բոլոր պատճենների վերականգնումը և VM-ների p99-ը դրա ամբողջ ընթացքում՝ rebuild-ի առաջնահերթությամբ ըստ Ձեր պլանի և մեկ քայլ ցածր
• Resync. հանգույցը վերադառնում է rebuild-ի կեսին, որքան է տևում համաժամեցումը և ինչ է այն անում ուշացման հետ
• Maintenance mode և rolling upgrade. հանգույց առ հանգույց, VM-ները տեղափոխվում են live migration-ով, resync հաջորդ հանգույցից առաջ, ընդհանուր պատուհանը
• Uplink failover. անջատվում է մեկ 25G կապուղի, NIC-ի մեկ պորտ կամ մեկ ToR, կանգը, և արդյոք կլաստերը դա չի ընդունում որպես հանգույցի կորուստ

Պահեստավորման էջում HCI-ը սարքերի 5 դասերից մեկն է, իսկ արտաքին զանգվածի ցանցը ներկայացված է ինչպես ենք փորձարկում պահեստավորման ցանցերը հոդվածում։

Ինչն է սովորաբար խափանվում

Rebuild VM-ների uplink-ների վրա։ Տիպային նախագծում 4 հանգույցով կլաստերը կորցնում է հանգույցը, և rebuild-ը սկսվում է լրիվ արագությամբ նույն 2×25G-ով։ VM-ների գրառման latency p99-ը 3 մվ-ից հասնում է 45 մվ-ի և այդպես մնում rebuild-ի ամբողջ 2 ժ 40 րոպեի ընթացքում, տվյալների բազաների VM-ները timeout են ստանում շատ ավելի շուտ, քան տվյալները ապահով են։ Երբ պահեստավորումը ToR-ում առանձին դասում է, իսկ rebuild-ի առաջնահերթությունը մեկ քայլ ցածր, p99-ը մնում է 9 մվ-ից ցածր, իսկ rebuild-ը տևում է 3 ժ 50 րոպե։ Սեփականատերն ընտրում է երկուսից մեկը՝ սեղանին ունենալով երկու թիվն էլ։

Uplink failover, որը նման է հանգույցի կորստի։ Պահեստավորման VLAN-ն աշխատում է MTU 9000-ով հոսթերում և նրանց կոմուտատորային պորտերում, իսկ երկու ToR-ի միջև կապուղին մնացել է 1500-ի վրա։ Ամեն ինչ աշխատում է, մինչև մեկ uplink ընկնում է, և պահեստավորման տրաֆիկն անցնում է այդ կապուղով։ Փոքր heartbeat-ներն անցնում են, ռեպլիկացիայի մեծ կադրերը՝ ոչ, և timeout-ից հետո կլաստերը առողջ հանգույցի պատճենները հայտարարում է կորած ու իզուր վերականգնում դրանք։ Կոմուտատորի կոնֆիգուրացիայի մեկ տող՝ գտնված failover-ի առաջին իսկ սցենարում։

Rolling upgrade, որն ավելի երկար է, քան պատուհանը։ Պլանում գրված է 30 րոպե մեկ հանգույցի համար։ Յուրաքանչյուր հանգույց նշանակում է VM-ների տեղափոխում, թարմացում, ապա այդ ընթացքում գրված ամեն ինչի resync, և հաջորդ հանգույցը սպասում է դրա ավարտին։ 6 հանգույցի վրա աշխատանքային բեռի տակ պատուհանը տիպային նախագծում պլանավորված 3 ժամից աճեց մինչև 7։ Յուրաքանչյուր resync-ի ընթացքում տվյալներն ունեն մեկ պատճեն պակաս, և պլատֆորմային թիմը պետք է այդ ռիսկը տեսնի ժամերով։

Ինչ կա հաշվետվության մեջ

VM-ների I/O latency p50 և p99 ըստ բլոկի չափի և VM-ների քանակի առողջ կլաստերում, և որպես կոր յուրաքանչյուր իրադարձության ընթացքում։ Կանգը յուրաքանչյուր VM-ի համար յուրաքանչյուր խափանման ժամանակ։ Rebuild-ի, resync-ի և թարմացման տևողությունը ըստ իրադարձությունների և կարգավորումների։ Տրաֆիկը և կորուստները ըստ uplink-ների և հերթերի, պահեստավորումը՝ VM-ների տրաֆիկից առանձին։ Հանգույցների և ToR զույգի կոնֆիգուրացիայի արտահանումները յուրաքանչյուր չափման համար՝ յուրաքանչյուր չանցած չափանիշի հետևում կանգնած կոնֆիգուրացիայի տողով։

Որտեղից սկսել

Ուղարկեք մեզ հանգույցների քանակը, HCI պլատֆորմը և կոմուտատորների սխեման։ Մենք պատասխանում ենք թեստի պլանի նախագծով՝ կետերը, ստենդի սխեման և ժամկետները։ Հաշվետվությունը մնում է Ձեզ, և Դուք կարող եք այն ցույց տալ վենդորին։ Գրեք մեզ կամ տեսեք, թե էլ ինչ է անում ստենդը։