В тази статия ще говоря за ситуацията, която наскоро се случи с един от нашите VPS облачни сървъри, поставяйки ме в задънена улица за няколко часа. Аз се занимавам с конфигуриране и отстраняване на проблеми със сървъри Linux от около 15 години, но този случай напълно не попада в моята практика — направих няколко погрешни предположения и малко се отчаях, преди да успея правилно да идентифицирам причината за проблема и да я реша.
Преамбула
Ние експлоатираме облак със среден размер, който изграждаме на базата на стандартни сървъри с следната конфигурация — 32 ядра, 256 GB RAM и NVMe диск PCI-E Intel P4500 с капацитет 4TB. Много харесваме тази конфигурация, тъй като тя ни позволява да не се притесняваме за недостиг на 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 не използваме монтиране на снимки в режимROза извличане на томове, а просто копираме целия LVM2 том.
Скоростта на резервно копиране на резервния сървър се определя в нашия случай от производителността на защитния сървър, която е около 600-800 MB/s за несжимаеми данни, а допълнителният ограничител е канал 10Gbit/s, с който резервният сървър е свързан към клъстера.
В същото време на един резервен сървър едновременно се качват резервни копия от 8 сървъри хипервизори. По този начин дисковата и мрежовата подсистеми на резервния сървър, като по-бавни, не дават да се натоварят дисковите подсистеми на хостовете-хипервизори, тъй като просто не са способни да обработят, да речем, 8 GB/сек, които спокойно могат да бъдат предоставени от хостовете-хипервизори.
Процесът на копиране, описан по-горе, е много важен за по-нататъшното развитие на историята, включително детайлите — използване на бързото устройство Intel P4500, използване на NFS и вероятно и на ZFS.
История за резервното копиране
На всеки хипервизорен възел имаме малък SWAP дял с размер 8 GB, а самият хипервизор "разгръщаме" с помощта на DD стандартния образ. За системния том на сървърите използваме 2xSATA SSD RAID1 или 2xSAS HDD RAID1 на хардуерен контролер LSI или HP. Всичко това е без значение за нас, тъй като системният том работи в режим "почти readonly", освен SWAP-a. А тъй като имаме много 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-и, за тях това е актуално, ето и се използва AS IS. В общи линии, това просто е интересен фрагмент код, който обяснява безсмислието ionice в случай на такава конфигурация.
Обърнете внимание на флага iflag=direct за DD. Използваме direct IO мимо буферната кеш памет, за да избегнем ненужни замествания на буферите IO при четене. Въпреки това, oflag=direct не го правим, тъй като сме срещали проблеми с производителността на ZFS при използването му.
Тази схема се използва успешно от нас в продължение на няколко години без проблеми.
И тук започна… Открихме, че резервното копиране е спряло да работи за един от възлите, а предишното е било изпълнено с ужасен IOWAIT от 50%. При опитите ни да разберем защо не се извършва копиране, се сблъскахме с явлението:
Група от обеми "images" не е намеренаЗапочнахме да мислим за "края на Intel P4500", но преди да изключим сървъра, за да заменим диска, беше необходимо все пак да направим резервно копиране. Поправихме LVM2 с възстановяване на метаданните от бекъп на LVM2:
vgcfgrestore imagesСтартирахме резервното копиране и видяхме следната картина:
Отново се притеснихме — очевидно беше, че така не може да продължава, тъй като всички VPS-ки ще страдат, а следователно и ние. Какво се случваше, беше напълно неясно — iostat показваше жалки IOPS и много висок IOWAIT. Нямаше идеи, освен "да заменим NVMe", но в точното време дойде прозрение.
Разбор на ситуацията стъпка по стъпка
Исторически журнал. Няколко дни по-рано на този сървър беше необходимо да създадем голяма VPS с 128 GB RAM. Паметта изглеждаше достатъчна, но за всеки случай добавихме още 32 GB за swap дяла. VPS беше създадена, успешно изпълни задачата си и инцидентът беше забравен, а SWAP дялът остана.
Специфики на конфигурацията. За всичките сървъри в облака параметърът vm.swappiness беше зададен на стойност по подразбиране 60. А SWAP беше създаден на SAS HDD RAID1.
Какво се случваше (според редакцията). При резервното копиране DD даваше много данни за запис, които се поставяха в буферите RAM преди запис в NFS. Ядро системата, ръководена от политиката swappiness, преместваше много страници памет от VPS в областта за подкачване, която се намираше на бавен том HDD RAID1. Това водеше до значително увеличаване на IOWAIT, но не заради IO на NVMe, а заради IO на HDD RAID1.
Как беше решен проблемът. Разделът за подкачване от 32 GB беше изключен. Това отне 16 часа, за това как и защо SWAP се изключва толкова бавно може да се прочете отделно. Бяха променени параметрите swappiness на стойност равна на 5 в целия облак.
Как би могло да не се случи. Първо, ако SWAP беше на SSD RAID или NVMe устройство, второ, ако нямаше NVMe устройство, а имаше по-бавно устройство, което не можеше да издава толкова голям обем данни — по ирония, проблемът се случи, защото NVMe е твърде бърз.
След това всичко започна да работи както преди — с нулево IOWAIT.
Източник: habr.com
