ბევრი უფასო ოპერატიული მეხსიერება, NVMe Intel P4500 და ყველაფერი ძალიან ნელია - სვოპ დანაყოფის წარუმატებელი დამატების ამბავი

ამ სტატიაში მე ვისაუბრებ სიტუაციაზე, რომელიც ახლახან მოხდა ჩვენს VPS ღრუბელში ერთ-ერთ სერვერზე, რამაც რამდენიმე საათის განმავლობაში დამტოვა. ლინუქსის სერვერების კონფიგურაციას და პრობლემების მოგვარებას ვაკეთებ დაახლოებით 15 წელია, მაგრამ ეს შემთხვევა საერთოდ არ ჯდება ჩემს პრაქტიკაში - რამდენიმე მცდარი ვარაუდი გამოვთქვი და ცოტა სასოწარკვეთილი ვიყავი, სანამ შემეძლო პრობლემის მიზეზის სწორად დადგენა და მისი მოგვარება. .

პრეამბულა

ჩვენ ვმუშაობთ საშუალო ზომის ღრუბელზე, რომელსაც ვაშენებთ სტანდარტულ სერვერებზე შემდეგი კონფიგურაციით - 32 ბირთვი, 256 GB ოპერატიული მეხსიერება და 4500TB PCI-E Intel P4 NVMe დისკი. ჩვენ ძალიან მოგვწონს ეს კონფიგურაცია, რადგან ის გამორიცხავს IO ზედმეტად ფიქრის აუცილებლობას VM ინსტანციის ტიპის დონეზე სწორი შეზღუდვის უზრუნველყოფით. რადგან NVMe Intel P4500 აქვს შთამბეჭდავი შესრულება, ჩვენ შეგვიძლია ერთდროულად მივაწოდოთ როგორც სრული 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-ისთვის ჩვენ არ ვიყენებთ სნეფშოტის მონტაჟს RO ტომების ამოსაღებად, ჩვენ უბრალოდ ვაკოპირებთ მთელ LVM2 ტომს.

სარეზერვო სერვერზე სარეზერვო ასლის სიჩქარე ჩვენს შემთხვევაში განისაზღვრება სარეზერვო სერვერის მუშაობით, რომელიც არის დაახლოებით 600-800 მბ/წმ შეკუმშვადი მონაცემებისთვის; შემდგომი შემზღუდველია 10 გბიტი/წმ არხი, რომელთანაც დაკავშირებულია სარეზერვო სერვერი. მტევნისკენ.

ამ შემთხვევაში, 8 ჰიპერვიზორის სერვერის სარეზერვო ასლები ერთდროულად აიტვირთება ერთ სარეზერვო სერვერზე. ამრიგად, სარეზერვო სერვერის დისკი და ქსელის ქვესისტემები, რომლებიც უფრო ნელია, არ აძლევენ საშუალებას ჰიპერვიზორის ჰოსტების დისკის ქვესისტემების გადატვირთვას, რადგან მათ უბრალოდ არ შეუძლიათ დამუშავება, ვთქვათ, 8 გბ/წმ, რაც ჰიპერვიზორის ჰოსტებს ადვილად შეუძლიათ. აწარმოოს.

ზემოაღნიშნული კოპირების პროცესი ძალიან მნიშვნელოვანია შემდგომი სიუჟეტისთვის, დეტალების ჩათვლით - სწრაფი Intel P4500 დისკის გამოყენება, NFS და, ალბათ, ZFS გამოყენებით.

სარეზერვო ამბავი

თითოეულ ჰიპერვიზორის კვანძზე გვაქვს პატარა SWAP დანაყოფი 8 GB ზომის და ჩვენ „გავაფარებთ“ თავად ჰიპერვიზორის კვანძს. DD საცნობარო სურათიდან. სერვერებზე სისტემის მოცულობისთვის, ჩვენ ვიყენებთ 2xSATA SSD RAID1 ან 2xSAS HDD RAID1 LSI ან HP ტექნიკის კონტროლერზე. ზოგადად, ჩვენ საერთოდ არ გვაინტერესებს რა არის შიგნით, რადგან ჩვენი სისტემის მოცულობა მუშაობს "თითქმის მხოლოდ წაკითხვის" რეჟიმში, გარდა SWAP-ისა. და რადგან სერვერზე გვაქვს ბევრი ოპერატიული მეხსიერება და ის 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 GB ოპერატიული მეხსიერებით. როგორც ჩანს, საკმარისი მეხსიერება იყო, მაგრამ უსაფრთხო მხარეს რომ ვიყოთ, ჩვენ გამოვყავით კიდევ 32 GB სვოპ დანაყოფისთვის. VPS შეიქმნა, წარმატებით დაასრულა თავისი დავალება და ინციდენტი დავიწყებას მიეცა, მაგრამ SWAP დანაყოფი დარჩა.

კონფიგურაციის მახასიათებლები. ყველა ღრუბლოვანი სერვერისთვის პარამეტრი vm.swappiness დაყენებული იყო ნაგულისხმევად 60. და SWAP შეიქმნა SAS HDD RAID1-ზე.

რა მოხდა (რედაქტორების მიხედვით). სარეზერვო ასლის შექმნისას DD აწარმოებდა უამრავი ჩაწერის მონაცემს, რომელიც განთავსებული იყო RAM-ის ბუფერებში NFS-ში ჩაწერამდე. სისტემის ბირთვი, ხელმძღვანელობს პოლიტიკით swappiness, გადაიტანა VPS მეხსიერების მრავალი გვერდი swap ზონაში, რომელიც განთავსებული იყო ნელი HDD RAID1 მოცულობაზე. ამან გამოიწვია IOWAIT ძალიან ძლიერი ზრდა, მაგრამ არა IO NVMe, არამედ IO HDD RAID1-ის გამო.

როგორ მოგვარდა პრობლემა. 32 GB swap დანაყოფი გამორთული იყო. ამას დასჭირდა 16 საათი; შეგიძლიათ ცალკე წაიკითხოთ, თუ როგორ და რატომ ირთვება SWAP ასე ნელა. პარამეტრები შეიცვალა swappiness ღირებულების ტოლი 5 მთელ ღრუბელს.

როგორ შეიძლება ეს არ მომხდარიყო?. ჯერ ერთი, თუ SWAP იქნებოდა SSD RAID ან NVMe მოწყობილობაზე, და მეორეც, თუ არ იყო NVMe მოწყობილობა, მაგრამ უფრო ნელი მოწყობილობა, რომელიც არ გამოიმუშავებდა მონაცემთა ამხელა მოცულობას - ირონიულად, პრობლემა მოხდა იმიტომ, რომ ეს NVMe ძალიან სწრაფია.

ამის შემდეგ, ყველაფერი დაიწყო მუშაობა, როგორც ადრე - ნულოვანი IOWAIT.

წყარო: www.habr.com