Көптеген бос жедел жады, NVMe Intel P4500 және бәрі өте баяу - своп бөлімін сәтсіз қосу тарихы

Бұл мақалада мен жақында VPS бұлтындағы серверлердің бірінде орын алған жағдай туралы сөйлесемін, ол мені бірнеше сағат бойы таң қалдырды. Мен Linux серверлерін конфигурациялаумен және ақаулықтарды жоюмен 15 жылдай айналыстым, бірақ бұл жағдай менің тәжірибеме мүлдем сәйкес келмейді - мен бірнеше жалған болжамдар жасадым және мәселенің себебін дұрыс анықтап, оны шеше алмас бұрын біраз үмітсіз болдым. .

Кіріспе

Біз орташа өлшемді бұлтты пайдаланамыз, оны келесі конфигурациясы бар стандартты серверлерде құрастырамыз - 32 ядро, 256 ГБ жедел жады және 4500 ТБ PCI-E Intel P4 NVMe дискісі. Бұл конфигурация бізге өте ұнайды, себебі ол VM дана түрі деңгейінде дұрыс шектеуді қамтамасыз ету арқылы IO қосымша шығындары туралы алаңдатуды болдырмайды. Себебі NVMe Intel P4500 әсерлі өнімділікке ие, біз бір уақытта машиналарға толық IOPS қамтамасыз етуді және IOWAIT нөлдік резервтік серверге сақтық көшірме сақтауды қамтамасыз ете аламыз.

Біз VM көлемдерін сақтау үшін гиперконвергентті SDN және басқа стильді, сәнді, жастық заттарды пайдаланбайтын ескі сенушілердің біріміз, жүйе неғұрлым қарапайым болса, «негізгі гуру кетті» жағдайында оны жою оңайырақ болады деп есептейміз. тауларға». Нәтижесінде біз 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 пайдалану.

Сақтық көшірме оқиғасы

Әрбір гипервизор түйінінде бізде өлшемі 8 ГБ шағын SWAP бөлімі бар және біз гипервизор түйінінің өзін «шығарамыз». DD анықтамалық суреттен. Серверлердегі жүйе көлемі үшін LSI немесе HP аппараттық контроллерінде 2xSATA SSD RAID1 немесе 2xSAS HDD RAID1 пайдаланамыз. Жалпы алғанда, біз ішіндегі нәрсеге бәрібір емеспіз, өйткені біздің жүйе көлемі 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 өнімділігі мәселелеріне тап болғандықтан емес.

Біз бұл схеманы бірнеше жыл бойы еш қиындықсыз сәтті қолданып келеміз.

Сосын басталды... Біз түйіндердің біреуінің сақтық көшірмесі жасалмағанын, ал алдыңғысының 50% құбыжық IOWAIT-пен жұмыс істеп тұрғанын анықтадық. Көшіру неге болмайтынын түсінуге тырысқанда, біз келесі құбылысқа тап болдық:

Volume group "images" not found

Біз «Intel P4500-дің соңы келді» деп ойлай бастадық, дегенмен дискіні ауыстыру үшін серверді өшірмес бұрын, сақтық көшірме жасау қажет болды. LVM2 сақтық көшірмесінен метадеректерді қалпына келтіру арқылы LVM2 түзетілді:

vgcfgrestore images

Біз резервтік көшірме жасадық және бұл майлы кескіндемені көрдік:

Біз тағы да қатты қайғырдық - бұлай өмір сүре алмайтынымыз анық болды, өйткені барлық VPS зардап шегеді, яғни біз де зардап шегеді. Не болғаны мүлдем түсініксіз - iostat аянышты IOPS және ең жоғары IOWAIT көрсетті. «NVMe ауыстырайық» дегеннен басқа идеялар болған жоқ, бірақ түсінік дер кезінде орын алды.

Жағдайды кезең-кезеңімен талдау

Тарихи журнал. Бірнеше күн бұрын бұл серверде 128 ГБ жедел жады бар үлкен VPS жасау қажет болды. Жад жеткілікті болып көрінді, бірақ қауіпсіз болу үшін біз своп бөлімі үшін тағы 32 ГБ бөлдік. VPS құрылды, өз тапсырмасын сәтті орындады және оқиға ұмытылды, бірақ SWAP бөлімі қалды.

Конфигурация мүмкіндіктері. Барлық бұлттық серверлер үшін параметр vm.swappiness әдепкіге орнатылды 60. Ал SWAP SAS HDD RAID1 жүйесінде жасалған.

Не болды (редакцияның айтуы бойынша). Сақтық көшірме жасау кезінде DD NFS жүйесіне жазбас бұрын RAM буферлеріне орналастырылған көптеген жазу деректерін шығарды. Саясат басшылыққа алынатын жүйе өзегі swappiness, баяу HDD RAID1 көлемінде орналасқан своп аймағына VPS жадының көптеген беттерін жылжытты. Бұл IOWAIT-тің өте күшті өсуіне әкелді, бірақ IO NVMe есебінен емес, IO HDD RAID1 арқасында.

Мәселе қалай шешілді. 32 ГБ своп бөлімі өшірілді. Бұл 16 сағатқа созылды; SWAP қалай және неге сонша баяу өшетіні туралы бөлек оқуға болады. Параметрлер өзгертілді swappiness тең мәнге 5 бүкіл бұлттың үстінде.

Бұл қалай болмас еді?. Біріншіден, егер SWAP SSD RAID немесе NVMe құрылғысында болса, екіншіден, NVMe құрылғысы болмаса, бірақ деректердің мұндай көлемін шығармайтын баяу құрылғы болса - бір қызығы, мәселе бұл NVMe тым жылдам болғандықтан орын алды.

Осыдан кейін бәрі бұрынғыдай жұмыс істей бастады - IOWAIT нөлімен.

Ақпарат көзі: www.habr.com