Много свободна RAM, NVMe Intel P4500 и всичко е изключително бавно - историята на неуспешното добавяне на суап дял

В тази статия ще говоря за ситуация, която наскоро се случи с един от сървърите в нашия VPS облак, която ме остави в безизходица за няколко часа. Конфигурирах и отстранявах неизправности на Linux сървъри от около 15 години, но този случай изобщо не се вписва в моята практика - направих няколко погрешни предположения и се отчаях малко, преди да успея правилно да определя причината за проблема и да го разреша .

предисловие

Оперираме среден по размер облак, който изграждаме на стандартни сървъри със следната конфигурация - 32 ядра, 256 GB RAM и 4500TB PCI-E Intel P4 NVMe диск. Наистина харесваме тази конфигурация, защото елиминира необходимостта да се тревожим за IO overhead, като предоставя правилното ограничение на ниво тип екземпляр на 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 MB/s за некомпресируеми данни; допълнителен ограничител е 10Gbit/s каналът, с който е свързан резервният сървър към клъстера.

В този случай резервни копия на 8 сървъра на хипервайзор се качват едновременно на един резервен сървър. По този начин дисковата и мрежовата подсистеми на резервния сървър, тъй като са по-бавни, не позволяват на дисковите подсистеми на хостовете на хипервайзора да се претоварят, тъй като те просто не могат да обработват, да речем, 8 GB/sec, които хостовете на хипервайзора могат лесно произвеждат.

Горният процес на копиране е много важен за по-нататъшната история, включително подробностите - използване на бързо устройство Intel P4500, използване на NFS и, вероятно, използване на ZFS.

Резервна история

На всеки хипервизорски възел имаме малък SWAP дял с размер 8 GB и „разгръщаме“ самия хипервизорски възел, използвайки 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, когато го използваме.

Ние използваме тази схема успешно от няколко години без проблеми.

И тогава се започна... Открихме, че един от възлите вече не е архивиран, а предишният работи с чудовищно IOWAIT от 50%. Когато се опитвахме да разберем защо не се случва копиране, срещнахме следното явление:

Volume group "images" not found

Започнахме да мислим за „настъпи краят на Intel P4500“, но преди да изключим сървъра, за да сменим устройството, все още беше необходимо да се извърши архивиране. Поправихме LVM2, като възстановихме метаданни от резервно копие на LVM2:

vgcfgrestore images

Пуснахме резервно копие и видяхме тази маслена картина:

Отново бяхме много тъжни - беше ясно, че не можем да живеем така, тъй като всички VPS ще пострадат, което означава, че и ние ще страдаме. Какво се е случило е напълно неясно - iostat показа жалки IOPS и най-високия IOWAIT. Нямаше други идеи освен „да заменим NVMe“, но прозрението се появи точно навреме.

Анализ на ситуацията стъпка по стъпка

Историческо списание. Няколко дни по-рано на този сървър беше необходимо да се създаде голям VPS със 128 GB RAM. Изглеждаше, че има достатъчно памет, но за по-сигурно отделихме още 32 GB за суап дяла. 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.

Източник: www.habr.com