مقدار زیادی رم رایگان، NVMe Intel P4500 و همه چیز بسیار کند است - داستان اضافه شدن ناموفق پارتیشن swap

در این مقاله، من در مورد وضعیتی صحبت خواهم کرد که اخیراً با یکی از سرورهای ابر VPS ما رخ داده است که من را برای چندین ساعت گیج کرده است. من حدود 15 سال است که سرورهای لینوکس را پیکربندی و عیب یابی می کنم، اما این مورد به هیچ وجه در تمرین من نمی گنجد - چندین فرض نادرست کردم و قبل از اینکه بتوانم به درستی علت مشکل را تعیین کنم و آن را حل کنم کمی ناامید شدم. .

مقدمه

ما یک ابر با اندازه متوسط ​​کار می کنیم که روی سرورهای استاندارد با پیکربندی زیر ایجاد می کنیم - 32 هسته، 256 گیگابایت رم و یک درایو 4500 ترابایتی PCI-E Intel P4 NVMe. ما واقعاً این پیکربندی را دوست داریم زیرا نیاز به نگرانی در مورد سربار IO را با ارائه محدودیت صحیح در سطح نوع نمونه VM از بین می برد. زیرا NVMe اینتل 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 مگابایت بر ثانیه است؛ یک محدود کننده دیگر کانال 10 گیگابیت بر ثانیه است که سرور پشتیبان به آن متصل است. به خوشه

در این حالت، نسخه های پشتیبان 8 سرور هایپروایزر به طور همزمان در یک سرور پشتیبان آپلود می شوند. بنابراین، دیسک و زیرسیستم های شبکه سرور پشتیبان، کندتر هستند، اجازه نمی دهند زیرسیستم های دیسک میزبان هایپروایزر بیش از حد بارگذاری شوند، زیرا آنها به سادگی قادر به پردازش مثلاً 8 گیگابایت در ثانیه نیستند، که میزبان هایپروایزر به راحتی می توانند آن را پردازش کنند. تولید کردن.

فرآیند کپی بالا برای داستان بعدی بسیار مهم است، از جمله جزئیات - استفاده از درایو سریع Intel P4500، استفاده از NFS و احتمالاً استفاده از ZFS.

داستان پشتیبان

در هر گره هایپروایزر یک پارتیشن SWAP کوچک به اندازه 8 گیگابایت داریم و خود گره هایپروایزر را با استفاده از آن "تولید" می کنیم. DD از تصویر مرجع برای حجم سیستم در سرورها، ما از 2xSATA SSD RAID1 یا 2xSAS HDD RAID1 در کنترلر سخت افزار LSI یا HP استفاده می کنیم. به طور کلی، ما اصلاً برای ما مهم نیست که چه چیزی در داخل است، زیرا حجم سیستم ما در حالت "تقریبا فقط خواندنی" کار می کند، به جز SWAP. و از آنجایی که ما رم زیادی روی سرور داریم و 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] 

با این حال، ما تعدادی گره قدیمی با RAID های SSD معمولی داریم، برای آنها این موضوع مرتبط است، بنابراین آنها در حال حرکت هستند. همانطور که هست. به طور کلی، این فقط یک کد جالب است که بیهودگی را توضیح می دهد 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 گیگابایت رم بود. به نظر می‌رسید که حافظه کافی وجود دارد، اما برای حفظ امنیت، 32 گیگابایت دیگر را برای پارتیشن swap اختصاص دادیم. VPS ایجاد شد، وظیفه خود را با موفقیت انجام داد و حادثه فراموش شد، اما پارتیشن SWAP باقی ماند.

ویژگی های پیکربندی. برای همه سرورهای ابری پارامتر vm.swappiness به طور پیش فرض تنظیم شد 60. و SWAP روی SAS HDD RAID1 ایجاد شد.

چه اتفاقی افتاد (به گفته سردبیران). هنگام پشتیبان گیری DD داده های نوشتن زیادی تولید کرد که قبل از نوشتن در NFS در بافرهای RAM قرار می گرفت. هسته سیستم، هدایت شده توسط سیاست swappiness، بسیاری از صفحات حافظه VPS را به ناحیه swap منتقل می کرد که روی یک حجم کم HDD RAID1 قرار داشت. این منجر به رشد بسیار قوی IOWAIT شد، اما نه به دلیل IO NVMe، بلکه به دلیل IO HDD RAID1.

چگونه مشکل حل شد. پارتیشن swap 32 گیگابایتی غیرفعال شد. این کار 16 ساعت طول کشید؛ می‌توانید به طور جداگانه در مورد چگونگی و چرایی خاموش شدن SWAP به آرامی مطالعه کنید. تنظیمات تغییر کرده است swappiness به مقداری برابر با 5 سراسر ابر

چطور ممکن است این اتفاق نیفتد؟. اولاً، اگر SWAP روی یک دستگاه SSD RAID یا NVMe بود، و ثانیاً، اگر دستگاه NVMe وجود نداشت، اما یک دستگاه کندتر بود که چنین حجمی از داده را تولید نمی کرد - از قضا، مشکل به این دلیل رخ داد که NVMe خیلی سریع است.

پس از آن، همه چیز مانند قبل شروع به کار کرد - با IOWAIT صفر.

منبع: www.habr.com