Много слободне РАМ-а, НВМе Интел П4500 и све је изузетно споро - прича о неуспешном додавању свап партиције

У овом чланку ћу говорити о ситуацији која се недавно догодила са једним од сервера у нашем ВПС облаку, што ме је неколико сати оставило збуњеним. Конфигуришем и решавам проблеме са Линук серверима око 15 година, али овај случај се уопште не уклапа у моју праксу - направио сам неколико лажних претпоставки и постао мало очајан пре него што сам успео да исправно утврдим узрок проблема и решим га .

Преамбула

Ми управљамо облаком средње величине, који градимо на стандардним серверима са следећом конфигурацијом - 32 језгра, 256 ГБ РАМ-а и 4500ТБ ПЦИ-Е Интел П4 НВМе драјв. Заиста нам се допада ова конфигурација јер елиминише потребу да бринете о ИО прекомерним оптерећењима пружањем исправног ограничења на нивоу типа ВМ инстанце. Јер НВМе Интел ПКСНУМКС има импресивне перформансе, можемо истовремено да обезбедимо и потпуну ИОПС обезбеђивање машинама и складиште резервних копија на бацкуп серверу са нултим ИОВАИТ-ом.

Ми смо једни од оних старих верника који не користе хиперконвергентни СДН и друге модерне, модерне, омладинске ствари за складиштење ВМ волумена, верујући да што је систем једноставнији, то је лакше решити га у условима „главног гуруа је отишао на планине." Као резултат тога, ми складиштимо волумене ВМ-а у КЦОВ2 формату у КСФС или ЕКСТ4, који је распоређен на врху ЛВМ2.

Такође смо приморани да користимо КЦОВ2 због производа који користимо за оркестрацију - Апацхе ЦлоудСтацк.

Да бисмо направили резервну копију, правимо пуну слику волумена као ЛВМ2 снимак (да, знамо да су ЛВМ2 снимци спори, али нам Интел П4500 такође помаже). Радимо lvmcreate -s .. i uz pomoć dd шаљемо резервну копију на удаљени сервер са ЗФС складиштем. Овде смо и даље мало прогресивни - на крају крајева, ЗФС може да складишти податке у компримованом облику, а ми можемо брзо да их вратимо користећи DD или користите појединачне волумене ВМ-а mount -o loop ....

Можете, наравно, уклонити не пуну слику ЛВМ2 волумена, већ монтирати систем датотека у RO и копирајте саме КЦОВ2 слике, међутим, суочили смо се са чињеницом да је КСФС постао лош од овога, и то не одмах, већ на непредвидив начин. Заиста не волимо када се домаћини хипервизора изненада „заглаве“ викендом, ноћу или празницима због грешака за које није јасно када ће се десити. Стога, за КСФС не користимо монтажу снимка RO да бисмо издвојили волумене, једноставно копирамо цео ЛВМ2 волумен.

Брзина прављења резервне копије на бацкуп сервер је у нашем случају одређена перформансама бацкуп сервера, које су око 600-800 МБ/с за некомпримоване податке; додатни лимитер је канал од 10Гбит/с са којим је бацкуп сервер повезан. до грозда.

У овом случају, резервне копије 8 хипервизорских сервера се истовремено учитавају на један резервни сервер. Дакле, диск и мрежни подсистеми резервног сервера, будући да су спорији, не дозвољавају преоптерећење дисковних подсистема хостова хипервизора, јер једноставно нису у стању да обрађују, рецимо, 8 ГБ/сец, које хостови хипервизора могу лако производити.

Горенаведени процес копирања је веома важан за даљу причу, укључујући и детаље - коришћење брзог Интел П4500 драјва, коришћење НФС-а и, вероватно, коришћење ЗФС-а.

Резервна прича

На сваком хипервизорском чвору имамо малу СВАП партицију величине 8 ГБ и „разваљујемо“ сам хипервизорски чвор користећи DD са референтне слике. За системски волумен на серверима користимо 2кСАТА ССД РАИД1 или 2кСАС ХДД РАИД1 на ЛСИ или ХП хардверском контролеру. Генерално, уопште нас није брига шта је унутра, пошто наш системски волумен ради у режиму „скоро само за читање“, осим за СВАП. А пошто имамо пуно РАМ-а на серверу и 30-40% је бесплатно, не размишљамо о СВАП-у.

Бацкуп процес. Овај задатак изгледа отприлике овако:

#!/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, у ствари, ова ствар је потпуно бескорисна за НВМе уређаје, пошто је ИО планер за њих подешен као:

cat /sys/block/nvme0n1/queue/scheduler
[none] 

Међутим, имамо велики број старих чворова са редовним ССД РАИД-овима, за њих је ово релевантно, па се померају КАО ИС. Све у свему, ово је само занимљив део кода који објашњава узалудност ionice у случају такве конфигурације.

Обратите пажњу на заставу iflag=direct за DD. Користимо директни ИО заобилазећи кеш бафера да бисмо избегли непотребну замену ИО бафера приликом читања. Међутим, oflag=direct немамо јер смо наишли на проблеме са перформансама ЗФС-а када смо га користили.

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

А онда је почело... Открили смо да један од чворова више нема резервну копију, а претходни је радио са монструозним ИОВАИТ-ом од 50%. Када смо покушавали да разумемо зашто се копирање не дешава, наишли смо на следећи феномен:

Volume group "images" not found

Почели смо да размишљамо о томе „дошао је крај за Интел П4500“, међутим, пре искључивања сервера да би се заменио драјв, ипак је било потребно направити резервну копију. Поправили смо ЛВМ2 враћањем метаподатака из резервне копије ЛВМ2:

vgcfgrestore images

Покренули смо резервну копију и видели ову слику уља:

Опет смо били веома тужни - било је јасно да не можемо овако да живимо, јер би сви ВПС-ови патили, што значи да бисмо и ми патили. Шта се десило потпуно је нејасно - iostat показао јадан ИОПС и највиши ИОВАИТ. Није било других идеја осим „хајде да заменимо НВМе“, али увид се десио баш на време.

Анализа ситуације корак по корак

Историјски часопис. Неколико дана раније, на овом серверу је било потребно направити велики ВПС са 128 ГБ РАМ-а. Чинило се да има довољно меморије, али да бисмо били сигурни, доделили смо још 32 ГБ за свап партицију. ВПС је креиран, успешно је извршио свој задатак и инцидент је заборављен, али је СВАП партиција остала.

Карактеристике конфигурације. За све сервере у облаку параметар vm.swappiness је подешено на подразумевано 60. И СВАП је креиран на САС ХДД РАИД1.

Шта се десило (према уредницима). Приликом прављења резервне копије DD произвео много података за упис, који су смештени у РАМ бафере пре писања у НФС. Језгро система, вођено политиком swappiness, је премештао многе странице ВПС меморије у област за замену, која се налазила на спором ХДД РАИД1 волумену. Ово је довело до веома снажног раста ИОВАИТ-а, али не због ИО НВМе, већ због ИО ХДД РАИД1.

Како је проблем решен. Свап партиција од 32 ГБ је онемогућена. Ово је трајало 16 сати; можете засебно прочитати како и зашто се СВАП тако споро искључује. Подешавања су промењена swappiness на вредност једнаку 5 по целом облаку.

Како се ово не би догодило?. Прво, да је СВАП био на ССД РАИД или НВМе уређају, и друго, да нема НВМе уређаја, већ споријег уређаја који не би производио толики обим података – иронично, проблем се десио јер је тај НВМе пребрз.

Након тога, све је почело да ради као и раније - са нултим ИОВАИТ-ом.

Извор: ввв.хабр.цом