Այս հոդվածում ես կխոսեմ մի իրավիճակի մասին, որը վերջերս տեղի ունեցավ մեր VPS ամպի սերվերներից մեկի հետ, որն ինձ մի քանի ժամ ապշեցրեց: Ես մոտ 15 տարի կարգավորում և վերացնում եմ Linux սերվերները, բայց այս դեպքն ընդհանրապես չի տեղավորվում իմ պրակտիկայում. .
Նախաբան
Մենք գործարկում ենք միջին չափի ամպ, որը մենք կառուցում ենք ստանդարտ սերվերների վրա՝ հետևյալ կոնֆիգուրացիայով՝ 32 միջուկ, 256 ԳԲ օպերատիվ հիշողություն և 4500 ՏԲ PCI-E Intel P4 NVMe սկավառակ: Մեզ իսկապես դուր է գալիս այս կոնֆիգուրացիան, քանի որ այն վերացնում է IO-ի վերին ծախսերի մասին անհանգստանալու անհրաժեշտությունը՝ ապահովելով ճիշտ սահմանափակում VM օրինակի տեսակի մակարդակում: Քանի որ NVMe Intel ունի տպավորիչ կատարողականություն, մենք կարող ենք միաժամանակ ապահովել ինչպես մեքենաների IOPS-ի ամբողջական ապահովում, այնպես էլ զրոյական IOWAIT-ով պահեստային սերվերի պահեստային պահեստավորում:
Մենք այն հին հավատացյալներից ենք, ովքեր չեն օգտագործում հիպերկոնվերգացված SDN և այլ նորաձև, մոդայիկ, երիտասարդական իրեր VM-ի ծավալները պահելու համար՝ հավատալով, որ որքան պարզ է համակարգը, այնքան ավելի հեշտ է այն լուծել «հիմնական գուրուն գնացել է»: դեպի սարեր»։ Արդյունքում մենք VM ծավալները պահում ենք QCOW2 ձևաչափով XFS կամ EXT4, որը տեղակայվում է LVM2-ի վերևում:
Մենք նույնպես ստիպված ենք օգտագործել QCOW2 արտադրանքը, որը մենք օգտագործում ենք նվագախմբի համար՝ Apache CloudStack:
Պահուստավորում կատարելու համար մենք ձայնի ամբողջական պատկերը վերցնում ենք որպես LVM2 ակնթարթ (այո, մենք գիտենք, որ LVM2 նկարահանումները դանդաղ են, բայց Intel P4500-ն այստեղ նույնպես օգնում է մեզ): Մենք անում ենք lvmcreate -s .. և օգնությամբ dd մենք պահուստային պատճենն ուղարկում ենք ZFS պահեստով հեռավոր սերվեր: Այստեղ մենք դեռ մի փոքր առաջադեմ ենք. ի վերջո, ZFS-ը կարող է տվյալները պահել սեղմված ձևով, և մենք կարող ենք արագ վերականգնել դրանք՝ օգտագործելով DD կամ ստանալ անհատական VM ծավալներ՝ օգտագործելով mount -o loop ....
Դուք, իհարկե, կարող եք հեռացնել ոչ թե LVM2 ծավալի ամբողջական պատկերը, այլ տեղադրել ֆայլային համակարգը
ROև պատճենեք QCOW2 պատկերներն իրենք, այնուամենայնիվ, մենք բախվեցինք այն փաստի հետ, որ XFS-ը վատացավ դրանից, և ոչ անմիջապես, այլ անկանխատեսելի կերպով: Մեզ իսկապես դուր չի գալիս, երբ հիպերվիզորի հաղորդավարները հանկարծակի «կպչում են» հանգստյան օրերին, գիշերը կամ տոն օրերին սխալների պատճառով, որոնք պարզ չեն, թե երբ են դրանք տեղի ունենալու: Հետևաբար, XFS-ի համար մենք չենք օգտագործում snapshot-ի տեղադրումROծավալներ հանելու համար մենք պարզապես պատճենում ենք ամբողջ LVM2 հատորը:
Պահուստային սերվերի վրա պահուստավորման արագությունը որոշվում է մեր դեպքում պահուստային սերվերի գործունակությամբ, որը կազմում է մոտ 600-800 ՄԲ/վ՝ չսեղմվող տվյալների համար։ Հետագա սահմանափակիչը 10 Գբիտ/վրկ ալիքն է, որի հետ միացված է պահուստային սերվերը։ դեպի կլաստերի.
Այս դեպքում 8 հիպերվիզոր սերվերների կրկնօրինակները միաժամանակ վերբեռնվում են մեկ պահեստային սերվերի վրա: Այսպիսով, պահեստային սերվերի սկավառակը և ցանցային ենթահամակարգերը, լինելով ավելի դանդաղ, թույլ չեն տալիս գերբեռնել հիպերվիզոր հոսթերի սկավառակի ենթահամակարգերը, քանի որ նրանք պարզապես չեն կարողանում մշակել, ասենք, 8 ԳԲ/վրկ, ինչը հիպերվիզորի հոսթները կարող են հեշտությամբ: արտադրել.
Վերոնշյալ պատճենման գործընթացը շատ կարևոր է հետագա պատմության համար, ներառյալ մանրամասները՝ արագ Intel P4500 սկավառակի օգտագործումը, NFS-ի օգտագործումը և, հավանաբար, ZFS-ի օգտագործումը:
Պահուստային պատմություն
Յուրաքանչյուր հիպերվիզոր հանգույցի վրա մենք ունենք 8 ԳԲ չափի փոքր SWAP միջնորմ, և մենք «գլորում ենք» հիպերվիզորի հանգույցն ինքը՝ օգտագործելով DD տեղեկանքի պատկերից: Սերվերների վրա համակարգի ծավալի համար մենք օգտագործում ենք 2xSATA SSD RAID1 կամ 2xSAS HDD RAID1 LSI կամ HP ապարատային կարգավորիչի վրա: Ընդհանուր առմամբ, մեզ ընդհանրապես չի հետաքրքրում, թե ինչ կա ներսում, քանի որ մեր համակարգի ծավալը գործում է «գրեթե միայն կարդալու» ռեժիմով, բացառությամբ SWAP-ի: Եվ քանի որ մենք սերվերի վրա ունենք շատ RAM և այն 30-40% անվճար է, մենք չենք մտածում SWAP-ի մասին:
Կրկնօրինակման գործընթաց. Այս առաջադրանքը մոտավորապես այսպիսի տեսք ունի.
#!/bin/bash
mkdir -p /mnt/backups/volumes
DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)
lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snapՈւշադրություն դարձրեք ionice -c3Փաստորեն, այս բանը լիովին անօգուտ է NVMe սարքերի համար, քանի որ նրանց համար IO ժամանակացույցը սահմանված է հետևյալ կերպ.
cat /sys/block/nvme0n1/queue/scheduler
[none] Այնուամենայնիվ, մենք ունենք մի շարք ժառանգական հանգույցներ սովորական SSD RAID-ներով, նրանց համար դա տեղին է, ուստի նրանք շարժվում են: ԻՆՉՊԵՍ ՈՐ ԿԱ. Ընդհանուր առմամբ, սա պարզապես հետաքրքիր կոդ է, որը բացատրում է անիմաստությունը ionice նման կոնֆիգուրացիայի դեպքում.
Ուշադրություն դարձրեք դրոշին iflag=direct համար DD. Մենք օգտագործում ենք ուղղակի IO՝ շրջանցելով բուֆերային քեշը, որպեսզի խուսափենք IO բուֆերների անհարկի փոխարինումից կարդալիս: Այնուամենայնիվ, oflag=direct մենք դա չենք անում, քանի որ այն օգտագործելիս բախվել ենք ZFS-ի աշխատանքի հետ կապված խնդիրների հետ:
Մենք այս սխեման հաջողությամբ օգտագործում ենք մի քանի տարի առանց խնդիրների։
Եվ հետո սկսվեց... Մենք հայտնաբերեցինք, որ հանգույցներից մեկն այլևս չի կրկնօրինակվել, իսկ նախորդն աշխատում էր 50% հրեշավոր IOWAIT-ով: Փորձելով հասկանալ, թե ինչու պատճենումը տեղի չի ունենում, մենք հանդիպեցինք հետևյալ երեւույթին.
Volume group "images" not foundՄենք սկսեցինք մտածել «Intel P4500-ի վերջը եկել է» մասին, սակայն, մինչ սերվերն անջատելը սկավառակը փոխարինելու համար, դեռևս անհրաժեշտ էր կրկնօրինակում կատարել: Մենք շտկել ենք LVM2-ը՝ վերականգնելով մետատվյալները LVM2 կրկնօրինակից.
vgcfgrestore imagesՄենք գործարկեցինք կրկնօրինակը և տեսանք այս յուղաներկը.
Կրկին մենք շատ տխուր էինք. պարզ էր, որ մենք չենք կարող այսպես ապրել, քանի որ բոլոր VPS-ները տուժելու են, ինչը նշանակում է, որ մենք նույնպես կտուժենք: Այն, ինչ տեղի ունեցավ, լիովին անհասկանալի է. iostat ցույց տվեց ողորմելի IOPS-ը և ամենաբարձր IOWAIT-ը: «Եկեք փոխարինենք NVMe»-ից բացի այլ գաղափարներ չկային, բայց հասկացությունը տեղի ունեցավ ճիշտ ժամանակին:
Իրավիճակի քայլ առ քայլ վերլուծություն
Պատմական ամսագիր. Մի քանի օր առաջ այս սերվերի վրա անհրաժեշտ էր ստեղծել մեծ VPS՝ 128 ԳԲ օպերատիվ հիշողությամբ։ Թվում էր, թե բավականաչափ հիշողություն կար, բայց ապահով կողմում լինելու համար մենք ևս 32 ԳԲ հատկացրինք swap բաժանման համար: VPS-ը ստեղծվեց, հաջողությամբ կատարեց իր խնդիրը և միջադեպը մոռացվեց, բայց SWAP միջնորմը մնաց:
Կազմաձևման առանձնահատկությունները. Բոլոր ամպային սերվերների համար պարամետրը vm.swappiness սահմանվել է լռելյայն 60. Իսկ SWAP-ը ստեղծվել է SAS HDD RAID1-ի վրա։
Ինչ է տեղի ունեցել (ըստ խմբագիրների). Կրկնօրինակելիս DD արտադրեց շատ գրելու տվյալներ, որոնք տեղադրվեցին RAM-ի բուֆերներում՝ նախքան NFS-ին գրելը: Համակարգի առանցքը՝ առաջնորդվելով քաղաքականությամբ swappiness, VPS հիշողության շատ էջեր էր տեղափոխում փոխանակման տարածք, որը գտնվում էր դանդաղ HDD RAID1 ձայնի վրա: Սա հանգեցրեց նրան, որ IOWAIT-ը շատ ուժեղ աճեց, բայց ոչ IO NVMe-ի, այլ IO HDD RAID1-ի շնորհիվ:
Ինչպես լուծվեց խնդիրը. 32 ԳԲ փոխանակման բաժանումն անջատված է: Սա տևեց 16 ժամ: Դուք կարող եք առանձին կարդալ այն մասին, թե ինչպես և ինչու է SWAP-ն այդքան դանդաղ անջատվում: Կարգավորումները փոխվել են swappiness հավասար արժեքի 5 ամբողջ ամպի վրա:
Ինչպե՞ս կարող էր դա տեղի չունենալ:. Նախ, եթե SWAP-ը լիներ SSD RAID կամ NVMe սարքի վրա, և երկրորդը, եթե չլիներ NVMe սարք, այլ ավելի դանդաղ սարք, որը չէր արտադրի նման ծավալի տվյալներ, հեգնանքով, խնդիրը տեղի ունեցավ, քանի որ այդ NVMe-ն չափազանց արագ է:
Դրանից հետո ամեն ինչ սկսեց աշխատել նախկինի պես՝ զրոյական IOWAIT-ով։
Source: www.habr.com