محتوای آموزشی وبلاگ نت‌آرام
در سرور مجازی ایران هنوز
df فضای خالی نشان می‌دهد، اما نوشتن فایل کند می‌شود یا خطای ورودی و خروجی می‌گیرید. اگر فایل‌سیستم روی LVM thin provisioning باشد، ممکن است فضای مشترک پشت چند دیسک منطقی یا snapshot پر شده باشد. فضای خالی داخل فایل‌سیستم با فضای واقعی باقی‌مانده در thin pool یکی نیست.thin pool مانند انباری مشترک برای چند پوشه است. هر پوشه ممکن است اندازه اسمی بزرگی داشته باشد، اما همه آن‌ها از ظرفیت واقعی یک انبار استفاده می‌کنند. snapshot نیز می‌تواند با تغییر داده‌ها فضای اضافی مصرف کند. در این راهنما قبل از هر تغییر، data و metadata را جدا اندازه می‌گیریم و از آسیب بیشتر جلوگیری می‌کنیم. دستورهای توسعه فقط برای زمانی‌اند که نام pool و فضای آزاد volume group را دقیق می‌دانید.
۱. اگر خطای نوشتن دارید، بار را کم و وضعیت را ثبت کنید
در صورت امکان کارهای نوشتنی غیرضروری، ساخت snapshot جدید و بکاپ سنگین روی همان pool را طبق برنامه سرویس متوقف یا به زمان دیگری منتقل کنید. وضعیت برنامه‌های حیاتی و آخرین نسخه پشتیبان قابل بازیابی را بررسی کنید. snapshot خود همان storage، بکاپ مستقل نیست. اگر خطای فایل‌سیستم یا pool مشاهده می‌کنید، بدون شناخت آن از
fsck روی فایل‌سیستم mountشده یا دستور تعمیر و حذف snapshot استفاده نکنید.در ترمینال مدیر اجرا کنید:
کد / دستورdf -hT
lsblk -f
sudo vgs -o vg_name,vg_size,vg_free
sudo lvs -a -o vg_name,lv_name,lv_size,segtype,pool_lv,origin,data_percent,metadata_percent,lv_attr
دو دستور اول فضای دیده‌شده از فایل‌سیستم و ساختار دیسک‌ها را نشان می‌دهند.
vgs فضای آزاد داخل هر volume group و lvs نوع و ارتباط volumeها را فهرست می‌کند. نام ستون یا در دسترس بودن بعضی fieldها با نسخه LVM فرق می‌کند؛ در صورت خطای نام فیلد، نسخه و راهنمای همان توزیع را بررسی کنید. نام و خروجی را با سرور و فایل‌سیستم مورد نظر تطبیق دهید، نه صرفاً نامی که شبیه مثال است.۲. عددهای Data و Meta را جدا بخوانید
در ردیف thin pool،
Data% نشان می‌دهد چه بخشی از فضای داده pool استفاده شده و Meta% میزان مصرف فضای metadata است. هر دو باید پیش از رسیدن به صد درصد بررسی و در صورت نیاز افزایش یابند. مثلاً اگر pool ده گیگابایت ظرفیت و Data برابر ۹۰ درصد دارد، تقریباً یک گیگابایت فضای داده برای همه thin volumeهای آن باقی است، حتی اگر فایل‌سیستم یک volume فضای آزاد بیشتری نشان دهد.عدد Data در ردیف یک thin volume با عدد pool یکسان نیست. حجم اسمی volumeها می‌تواند از ظرفیت واقعی pool بزرگ‌تر باشد؛ جمع‌زدن اندازه‌های اسمی دلیل وجود فضای فیزیکی کافی نیست. اگر Data یا Meta نزدیک ۱۰۰ درصد و با سرعت در حال افزایش است، تا قبل از رسیدن به سقف اقدام کنید. مستند LVM thin provisioning رفتار این دو محدودیت را توضیح می‌دهد.
۳. رابطه snapshotها را بفهمید
در خروجی
lvs ستون origin نشان می‌دهد یک snapshot به کدام volume مربوط است و pool_lv محل آن را مشخص می‌کند. با تغییر بلوک‌ها، نسخه‌های لازم ممکن است در pool باقی بمانند؛ بنابراین snapshot قدیمی می‌تواند مصرف را افزایش دهد. با این حال حذف یک snapshot همیشه همان مقدار ظاهری را بلافاصله آزاد نمی‌کند، چون بلوک‌ها ممکن است با volumeهای دیگر مشترک باشند.قبل از حذف هر snapshot، نام دقیق، مالک، کاربرد در بکاپ یا بازیابی و مجوز حذف را مشخص کنید. اگر snapshot بخشی از job بکاپ است، ابتدا از کامل‌شدن و مستقل‌بودن بکاپ مطمئن شوید. دستور حذف انبوه یا انتخاب از روی شباهت نام می‌تواند نقطه بازیابی مورد نیاز را از بین ببرد. اگر در تشخیص رابطه‌ها مطمئن نیستید، ابتدا ظرفیت امن اضافه و فهرست را با مدیر storage بررسی کنید.
۴. اگر فقط Data نزدیک سقف است و VG فضای آزاد کافی دارد
فرض کنیم خروجی بررسی‌شده شما pool به نام
کد / دستورpool0 در گروه vgdata را نشان می‌دهد و VFree آن گروه با احتساب metadata و رزرو سایر سرویس‌ها بیشتر از مقدار لازم است. پیش از اقدام نسخه پشتیبان معتبر و پنجره تغییر داشته باشید. برای افزودن ۱۰ گیگابایت نمونه به داده pool، تنها پس از جایگزینی نام واقعی اجرا کنید:sudo lvextend -L +10G vgdata/pool0
sudo lvs -a -o vg_name,lv_name,lv_size,segtype,data_percent,metadata_percent
sudo vgs -o vg_name,vg_free
دستور نخست ظرفیت thin pool را از فضای آزاد همان VG بزرگ می‌کند؛ مقدار و نام مثال‌اند و باید بر اساس رشد واقعی انتخاب شوند. دستورهای بعدی اندازه جدید، درصدها و فضای آزاد باقی‌مانده را نشان می‌دهند. LVM ممکن است متناسب با نسخه و شرایط، metadata را نیز هنگام توسعه داده افزایش دهد؛ نتیجه واقعی را بخوانید. این دستور اندازه فایل‌سیستم داخل یک thin volume را تغییر نمی‌دهد و با
lvextend --resizefs برای توسعه خود فایل‌سیستم فرق دارد.اگر
VFree کافی نیست، دستور را تکرار نکنید. باید ظرفیت فیزیکی مناسب به VG اضافه شود یا فضای امنی طبق طراحی storage فراهم شود؛ اضافه‌کردن دیسک و ساخت PV بدون تشخیص دستگاه می‌تواند داده‌های دیسک اشتباه را از بین ببرد. اگر storage توسط مجازی‌ساز یا ارائه‌دهنده مدیریت می‌شود، ظرفیت را از مسئول آن بخواهید و تا رسیدن ظرفیت، بار نوشتنی را کنترل کنید.۵. اگر Meta نزدیک سقف یا خود pool آسیب‌دیده است
مصرف بالای metadata موضوع جداگانه‌ای است و بزرگ‌کردن فایل‌سیستم داخل volume الزاماً آن را حل نمی‌کند. پیش از پرشدن، با فضای آزاد کافی و راهنمای نسخه LVM می‌توان اندازه metadata pool را با
lvextend --poolmetadatasize افزایش داد؛ عدد هدف و وضعیت فعلی را از خروجی همان سیستم و مستند توزیع تعیین کنید. از واردکردن عدد یا نام حدسی خودداری کنید.اگر Meta به ۱۰۰ درصد رسیده یا خطای metadata و I/O وجود دارد، طبق مستند LVM ممکن است بررسی و تعمیر آفلاین و بررسی فایل‌سیستم لازم باشد. این کار می‌تواند نیازمند توقف همه volumeهای وابسته باشد؛ روی سرور تولیدی بدون بکاپ، کنسول و طرح بازیابی آن را اجرا نکنید. ظرفیت اضافه‌کردن به‌تنهایی تضمین ترمیم metadata یا فایل‌سیستم آسیب‌دیده نیست. شواهد
lvs و journal را به مسئول storage بدهید و مراحل آفلاین مختص نسخه را با او اجرا کنید.۶. از تکرار مشکل جلوگیری کنید
برای pool، Data و Meta و برای VG فضای آزاد را به‌طور جداگانه پایش کنید. آستانه هشدار باید با سرعت رشد فاصله کافی داشته باشد؛ اگر مصرف در چند دقیقه به سقف می‌رسد، هشدار دیرهنگام فایده ندارد. توسعه خودکار thin pool به فعال‌بودن پایش LVM و وجود فضای آزاد در VG وابسته است؛ روشن‌بودن تنظیم بدون فضای رزرو کافی نیست.
بعد از اصلاح، دوباره Data و Meta و فضای VG را بخوانید و یک عملیات نوشتن بی‌خطر در مسیر آزمایشی مورد تأیید سرویس انجام دهید. سلامت فایل‌سیستم و برنامه را هم بررسی کنید. اگر پس از افزایش دیسک مجازی خود سیستم‌عامل ظرفیت جدید را نمی‌بیند، راهنمای افزایش دیسک و فایل‌سیستم VPS مسیر آن مسئله متفاوت را نشان می‌دهد.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام