Çoxlu pulsuz RAM, NVMe Intel P4500 və hər şey olduqca yavaşdır - dəyişdirmə bölməsinin uğursuz əlavə edilməsi hekayəsi

Bu yazıda VPS buludumuzdakı serverlərdən biri ilə bu yaxınlarda baş verən və məni bir neçə saat çaşdıran bir vəziyyətdən danışacağam. Təxminən 15 ildir ki, Linux serverlərini konfiqurasiya edir və problemlərini həll edirəm, lakin bu hal ümumiyyətlə mənim praktikamıma uyğun gəlmir - problemin səbəbini düzgün müəyyənləşdirə və həll edə bilməmişdən əvvəl bir neçə yanlış fərziyyələr etdim və bir az çarəsiz qaldım. .

Başlanğıc

Biz orta ölçülü buluddan istifadə edirik və onu aşağıdakı konfiqurasiyaya malik standart serverlər üzərində qururuq - 32 nüvə, 256 GB RAM və 4500 TB PCI-E Intel P4 NVMe sürücüsü. Biz bu konfiqurasiyanı çox bəyənirik, çünki o, VM instansiya növü səviyyəsində düzgün məhdudiyyəti təmin etməklə IO əlavə yükü ilə bağlı narahatlığı aradan qaldırır. Çünki NVMe Intel P4500 təsir edici performansa malikdir, biz eyni zamanda həm maşınlara tam IOPS təminatı, həm də sıfır IOWAIT ilə ehtiyat serverə ehtiyat saxlama təmin edə bilərik.

Biz VM həcmlərini saxlamaq üçün hiperkonverged SDN və digər dəbli, dəbli, gənclik əşyalarından istifadə etməyən köhnə möminlərdən biriyik, hesab edirik ki, sistem nə qədər sadə olsa, “əsas guru getdi” şərtlərində onu həll etmək bir o qədər asan olacaq. dağlara”. Nəticədə, biz VM həcmlərini QCOW2 formatında LVM4-nin üstündə yerləşdirilmiş XFS və ya EXT2-də saxlayırıq.

Biz həmçinin orkestrasiya üçün istifadə etdiyimiz məhsul - Apache CloudStack tərəfindən QCOW2-dən istifadə etməyə məcbur oluruq.

Yedəkləməni həyata keçirmək üçün LVM2 snapshot kimi həcmin tam şəklini çəkirik (bəli, LVM2 anlıq görüntülərinin yavaş olduğunu bilirik, lakin Intel P4500 bizə burada da kömək edir). Biz edirik lvmcreate -s .. və köməyi ilə dd ehtiyat nüsxəsini ZFS yaddaşı olan uzaq serverə göndəririk. Burada biz hələ də bir qədər mütərəqqiyik - axı ZFS məlumatları sıxılmış formada saxlaya bilər və biz onu istifadə edərək tez bərpa edə bilərik. DD və ya istifadə edərək fərdi VM həcmləri əldə edin mount -o loop ....

Siz, əlbəttə ki, LVM2 həcminin tam şəklini deyil, fayl sistemini qovluğa quraşdıra bilərsiniz RO və QCOW2 şəkillərini özləri kopyalayın, lakin XFS-nin bundan dərhal deyil, gözlənilməz bir şəkildə pisləşməsi ilə qarşılaşdıq. Hipervizorun həftə sonları, gecələr və ya bayram günlərində nə vaxt baş verəcəyi bəlli olmayan səhvlərə görə qəfildən “yapışması” bizim xoşumuza gəlmir. Buna görə də, XFS üçün biz snapshot montajından istifadə etmirik RO həcmləri çıxarmaq üçün biz sadəcə olaraq bütün LVM2 həcmini kopyalayırıq.

Ehtiyat serverə ehtiyat nüsxəsinin sürəti bizim vəziyyətimizdə ehtiyat serverin performansı ilə müəyyən edilir, bu, sıxılmayan məlumatlar üçün təxminən 600-800 MB/s təşkil edir; daha bir məhdudlaşdırıcı ehtiyat serverin qoşulduğu 10Gbit/s kanaldır. klasterə.

Bu halda, 8 hipervizor serverinin ehtiyat nüsxələri eyni vaxtda bir ehtiyat serverə yüklənir. Beləliklə, ehtiyat serverin disk və şəbəkə alt sistemləri daha yavaş olmaqla, hipervizor hostlarının disk alt sistemlərinin həddən artıq yüklənməsinə imkan vermir, çünki onlar sadəcə olaraq hipervizor hostlarının asanlıqla işlədə biləcəyi 8 GB/san sürəti emal edə bilmirlər. istehsal edir.

Yuxarıdakı surət çıxarma prosesi təfərrüatlar da daxil olmaqla sonrakı hekayə üçün çox vacibdir - sürətli Intel P4500 sürücüsündən, NFS-dən istifadə etməklə və ehtimal ki, ZFS-dən istifadə etməklə.

Yedek hekayə

Hər bir hipervizor qovşağında 8 GB ölçüsündə kiçik SWAP bölməmiz var və biz hipervizor qovşağının özünü "yayırıq". DD istinad şəklindən. Serverlərdə sistem həcmi üçün biz LSI və ya HP aparat nəzarətçisində 2xSATA SSD RAID1 və ya 2xSAS HDD RAID1 istifadə edirik. Ümumiyyətlə, sistem həcmimiz SWAP istisna olmaqla, “demək olar ki, yalnız oxunur” rejimində işlədiyi üçün içəridə olanların heç vecinə də deyilik. Serverdə çoxlu operativ yaddaşımız olduğundan və 30-40% pulsuz olduğundan SWAP haqqında düşünmürük.

Yedəkləmə prosesi. Bu tapşırıq belə görünür:

#!/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

Qeyd ionice -c3, əslində, bu şey NVMe cihazları üçün tamamilə yararsızdır, çünki onlar üçün IO planlayıcısı belə qurulmuşdur:

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

Bununla belə, adi SSD RAID-ləri olan bir sıra köhnə qovşaqlarımız var, onlar üçün bu aktualdır, buna görə də hərəkət edirlər. OLDUĞU KİMİ. Ümumiyyətlə, bu, mənasızlığı izah edən maraqlı bir kod parçasıdır ionice belə bir konfiqurasiya olduqda.

Bayrağa diqqət yetirin iflag=direct uğrunda DD. Oxuyarkən IO buferlərinin lazımsız dəyişdirilməsinin qarşısını almaq üçün bufer keşindən yan keçərək birbaşa IO-dan istifadə edirik. Bununla belə, oflag=direct istifadə etmirik, çünki ZFS-dən istifadə edərkən performans problemləri ilə qarşılaşmışıq.

Biz bu sxemdən bir neçə ildir ki, problemsiz uğurla istifadə edirik.

Və sonra başladı... Biz aşkar etdik ki, qovşaqlardan biri artıq ehtiyat nüsxəsini çıxarmayıb və əvvəlki 50% dəhşətli IOWAIT ilə işləyir. Kopyalamanın niyə baş vermədiyini anlamağa çalışarkən aşağıdakı fenomenlə qarşılaşdıq:

Volume group "images" not found

Biz "Intel P4500-ün sonu gəldi" haqqında düşünməyə başladıq, lakin sürücünü əvəz etmək üçün serveri söndürməzdən əvvəl hələ də ehtiyat nüsxəsini çıxarmaq lazım idi. LVM2 ehtiyat nüsxəsindən metadatanı bərpa etməklə LVM2-ni düzəltdik:

vgcfgrestore images

Biz ehtiyat nüsxəsini işə saldıq və bu yağlı boya tablosunu gördük:

Yenə çox kədərləndik - belə yaşaya bilməyəcəyimiz aydın idi, çünki bütün VPS-lər əziyyət çəkəcək, yəni biz də əziyyət çəkəcəyik. Nə baş verdiyi tamamilə aydın deyil - iostat acınacaqlı IOPS və ən yüksək IOWAIT göstərdi. “NVMe-ni əvəz edək”dən başqa heç bir fikir yox idi, ancaq vaxtında bir fikir baş verdi.

Vəziyyətin addım-addım təhlili

Tarixi jurnal. Bir neçə gün əvvəl bu serverdə 128 GB RAM ilə böyük VPS yaratmaq lazım idi. Kifayət qədər yaddaş var idi, amma təhlükəsiz tərəfdə olmaq üçün dəyişdirmə bölməsi üçün başqa 32 GB ayırdıq. VPS yaradıldı, tapşırığını uğurla yerinə yetirdi və hadisə unudulub, lakin SWAP bölməsi qaldı.

Konfiqurasiya Xüsusiyyətləri. Bütün bulud serverləri üçün parametr vm.swappiness defolt olaraq təyin edildi 60. SWAP isə SAS HDD RAID1-də yaradılmışdır.

Nə baş verdi (redaktorlara görə). Yedəkləmə zamanı DD NFS-ə yazmadan əvvəl RAM buferlərinə yerləşdirilən çoxlu yazı məlumatları istehsal etdi. Siyasətlə idarə olunan sistem nüvəsi swappiness, VPS yaddaşının çoxlu səhifələrini yavaş HDD RAID1 həcmində yerləşən dəyişdirmə sahəsinə köçürürdü. Bu, IOWAIT-in çox güclü böyüməsinə səbəb oldu, lakin IO NVMe hesabına deyil, IO HDD RAID1 sayəsində.

Problem necə həll olundu. 32 GB dəyişdirmə bölməsi deaktiv edildi. Bu, 16 saat çəkdi; SWAP-ın necə və niyə belə yavaş söndüyü haqqında ayrıca oxuya bilərsiniz. Parametrlər dəyişdirilib swappiness bərabər dəyərə 5 bütün bulud üzərində.

Bu necə olmaya bilərdi?. Birincisi, SWAP SSD RAID və ya NVMe cihazında olsaydı və ikincisi, NVMe cihazı olmasaydı, lakin belə həcmdə məlumat istehsal etməyəcək daha yavaş bir cihaz olsaydı - ironik olaraq, problem NVMe çox sürətli olduğu üçün baş verdi.

Bundan sonra hər şey əvvəlki kimi işləməyə başladı - sıfır IOWAIT ilə.

Mənbə: www.habr.com