Многу бесплатна RAM меморија, NVMe Intel P4500 и сè е исклучително бавно - приказната за неуспешното додавање на swap партиција

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

Преамбула

Работиме со облак со средна големина, кој го градиме на стандардни сервери со следнава конфигурација - 32 јадра, 256 GB RAM и 4500 TB 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 за некомпресибилни податоци; дополнителен ограничувач е каналот од 10 Gbit/s со кој е поврзан резервниот сервер. до кластерот.

Во овој случај, резервните копии од 8 хипервизорски сервери истовремено се поставуваат на еден резервен сервер. Така, дискот и мрежните потсистеми на резервниот сервер, бидејќи се побавни, не дозволуваат подсистемите на дискот на хостовите на хипервизорот да се преоптоварат, бидејќи тие едноставно не се способни да обработат, на пример, 8 GB/s, што може лесно да ги хостира хипервизорот. произведуваат.

Горенаведениот процес на копирање е многу важен за понатамошната приказна, вклучувајќи ги и деталите - користење брз погон 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 за 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 swap партицијата беше оневозможена. Ова траеше 16 часа; можете да прочитате одделно за тоа како и зошто SWAP се исклучува толку бавно. Поставките се променети swappiness до вредност еднаква на 5 низ целиот облак.

Како може да не се случи ова?. Прво, кога SWAP би бил на SSD RAID или NVMe уред, и второ, ако нема уред NVMe, туку побавен уред кој не би произведувал толкав обем на податоци - иронично, проблемот се случи бидејќи тој NVMe е пребрз.

После тоа, сè почна да работи како порано - со нула IOWAIT.

Извор: www.habr.com