پایش سلامت دیسک سرور اختصاصی ایران؛ SMART، خطاهای I/O و هشدار خرابی

پایش سلامت دیسک سرور اختصاصی ایران را از کجا شروع کنیم؟ برای پایش سلامت دیسک سرور اختصاصی ایران سه منبع را کنار هم قرار دهید: گزارش سلامت هر دیسک، رخدادهای…

دسته‌بندیآموزش سرورنویسندهوطن هاستتاریخ انتشار۲۱ آبان ۱۴۰۵زمان مطالعه۲۶ دقیقه

پایش سلامت دیسک سرور اختصاصی ایران را از کجا شروع کنیم؟

برای پایش سلامت دیسک سرور اختصاصی ایران سه منبع را کنار هم قرار دهید: گزارش سلامت هر دیسک، رخدادهای خواندن و نوشتن در سیستم‌عامل، و وضعیت آرایه یا کنترلر ذخیره‌سازی. یک گزارش SMART سالم به‌تنهایی برای تصمیم کافی نیست. از وضعیت فعلی هر دیسک یک خط پایه بسازید و تغییرات آن را در طول زمان ثبت کنید. اگر خطای رسانه بیشتر می‌شود یا کرنل در همان زمان خطای ورودی و خروجی می‌نویسد، سلامت بکاپ و امکان بازیابی را بررسی کنید و شواهد را برای پشتیبانی بفرستید. اگر فقط دما تغییر کرده، بازهٔ دمایی سازنده، شدت بار و شرایط خنک‌کاری را با هم ببینید.

در این راهنما، هدف تصمیم عملی است. به‌جای جمع‌آوری ده‌ها عدد بی‌ارتباط، برای هر سرور مشخص می‌کنیم کدام دیسک متعلق به کدام سرویس است، چه شاخصی باید بررسی شود، چه زمانی پاسخ فوری لازم است و چه اطلاعاتی باید در تیکت بیاید. انتخاب هاستینگ هم بخشی از همین تصمیم است. اگر نمی‌دانید در سرویس موردنظر چه کسی می‌تواند اطلاعات دیسک را بخواند یا دیسک فیزیکی را تعویض کند، این پرسش را پیش از خرید مطرح کنید. پاسخ عملی برای پروژه‌ای با نیاز به دسترسی کنسول، رویهٔ مشخص تعویض و بازیابی، از نام فناوری ذخیره‌سازی به‌تنهایی ارزش بیشتری دارد.

نقشهٔ ذخیره‌سازی و خط پایه

پیش از بررسی، دیسک واقعی را شناسایی کنید

از نمایی شروع کنید که به شما نشان می‌دهد سیستم‌عامل چه دستگاه‌های بلوکی می‌بیند. در لینوکس، فهرست دستگاه‌ها می‌تواند نام، نوع، اندازه، مدل و محل اتصال فایل‌سیستم را نشان دهد. یک پارتیشن، دیسک فیزیکی، حجم منطقی و آرایه ممکن است در همان فهرست کنار هم ظاهر شوند. نامی مانند sda می‌تواند یک دیسک، یا نمای منطقی یک کنترلر سخت‌افزاری باشد. اگر در گزارش کنترلر چند عضو وجود دارد ولی لینوکس فقط یک حجم می‌بیند، همان حجم را با تک‌تک دیسک‌ها یکی فرض نکنید. قبل از خواندن سلامت اعضا، مسیر مناسب کنترلر و مدل دستگاه را از مستندات یا تیم میزبان بگیرید.

برای هر دیسک فیزیکی، مدل، نقش، جایگاه در آرایه، شناسهٔ پایدار و تاریخ آخرین تغییر را ثبت کنید. شناسهٔ داخلی برای استفادهٔ تیم مفید است. شماره‌سریال کامل را تنها در کانال خصوصی لازم به اشتراک بگذارید. در لحظهٔ حادثه، نامی که کرنل ثبت کرده ممکن است پس از راه‌اندازی دوباره عوض شود. با نقشهٔ به‌روز، می‌توان پیام مربوط به دستگاه فعلی را به عضو درست در کنترلر ربط داد و از اقدام روی عضو سالم جلوگیری کرد. هر تعویض باید در همان فهرست ثبت شود تا اعداد دیسک تازه به‌اشتباه با خط پایهٔ دیسک قدیمی مقایسه نشوند.

خط پایه چه اطلاعاتی باید داشته باشد؟

یک نمونه در زمان کار عادی بگیرید و زمان، مدل و نسخهٔ ابزار را ثبت کنید. برای هر دستگاه، وضعیت کلی گزارش سلامت، دما و شمارنده‌های مهم همان مدل را نگه دارید. وضعیت آرایه و وجود یا نبود رخدادهای جدید کرنل را هم اضافه کنید. در صورت امکان یک نمونه از زمان بار سبک و نمونه‌ای از زمان کار معمول تهیه کنید تا تفاوت شرایط قابل تفسیر باشد. دمای زمان بکاپ شبانه ممکن است با دمای زمان بیکاری فرق داشته باشد. مقایسهٔ درست زمانی صورت می‌گیرد که زمان و شرایط نمونه‌ها کنار عدد مشخص باشند.

گزارش خام را با یک خلاصهٔ عملیاتی کوچک همراه کنید. مثلاً بنویسید شمارندهٔ خطای رسانه در این نمونه نسبت به دیروز ثابت است و کرنل رخداد تازه‌ای برای همان عضو گزارش نکرده است. در نمونهٔ بعد اگر فقط زمان کارکرد بالا رفته باشد، ثبت آن به معنی حادثه نیست. اگر شمارندهٔ خطای رسانه در فاصلهٔ کوتاهی تغییر کند، با نمونهٔ قبلی و زمان رخداد آن را تطبیق دهید. به این ترتیب داشبورد از نمایش اعداد پراکنده به شواهدی تبدیل می‌شود که می‌توان با آن زمان اقدام را تعیین کرد.

برای دسترسی محدود چه کنیم؟

اگر دسترسی کنسول یا مجوز خواندن دستگاه را ندارید، ابتدا بپرسید ارائه‌دهنده چه اطلاعاتی را می‌تواند در قالب گزارش معتبر تحویل دهد. نام نقش یا سرویس آسیب‌دیده، بازهٔ زمانی، و پیام قابل مشاهده را آماده کنید. گزارش خوب از ارائه‌دهنده معمولاً به پرسش مشخص پاسخ می‌دهد. برای مثال روشن می‌کند آیا دو خطای امروز به یک عضو خاص مربوط بوده، وضعیت آرایه در آن لحظه چه بوده و شمارندهٔ سلامت از دفعهٔ قبل تغییر کرده است. دسترسی نداشتن به دادهٔ خام را در گزارش پایش مشخص کنید تا نبود داده با سلامت دستگاه اشتباه نشود.

در پروژه‌ای که فقط مصرف‌کنندهٔ یک سرور مجازی است، آنچه از داخل مهمان می‌بینید معمولاً نمای تخصیص‌یافته به همان محیط است. برای تفسیر وضعیت دیسک فیزیکی لازم است بدانید پلتفرم چه داده‌ای را به مهمان ارائه می‌دهد. این تفاوت در خرید اهمیت دارد. اگر امکان پایش جزئی دیسک فیزیکی شرط تیم شماست، نوع دسترسی و ابزار رسمی را قبل از خرید تأیید کنید. اگر مسئولیت پایش با ارائه‌دهنده است، دربارهٔ مسیر دریافت هشدار و بازهٔ پاسخ‌گویی سؤال کنید تا مسئول اقدام در لحظهٔ رخداد مشخص باشد.

خواندن SMART و گزارش NVMe

فرمان‌های مشاهده‌ای را متناسب با نوع دستگاه انتخاب کنید

ابزار smartctl می‌تواند برای دستگاه‌های پشتیبانی‌شده گزارش SMART یا گزارش سلامت NVMe را بخواند. پیش از اجرا نام دستگاه را با نقشهٔ سرور تطبیق دهید. در نمونه‌های این مطلب، نام‌ها صرفاً نمونه‌اند و باید با دستگاه واقعی جایگزین شوند. در حضور RAID سخت‌افزاری، بعضی کنترلرها برای دسترسی به عضو فیزیکی روش ویژه دارند. اگر ابزار دیسک‌های پشت کنترلر را نمی‌بیند، ابتدا مدل کنترلر، پشتیبانی نسخهٔ ابزار و روش تأییدشدهٔ سازنده را پیدا کنید. نام دستگاه را با حدس‌های مکرر امتحان نکنید، چون خروجی اشتباه به تصمیم عملیاتی اشتباه منجر می‌شود.

lsblk -o NAME,TYPE,SIZE,MODEL,MOUNTPOINTS
sudo smartctl --scan
sudo smartctl -a /dev/sdX
sudo smartctl -a /dev/nvme0

برای کار روزمره ابتدا گزارش موجود را بخوانید. شروع خودآزمایی، تغییر زمان‌بندی دستگاه یا هر عملیات سنگین را به‌عنوان تصمیمی جداگانه در نظر بگیرید. هدف عیب‌یابی اولیه این است که بدون تغییر وضعیت سرویس، شواهد فعلی را جمع کنید. اگر سیستم درگیر کندی یا بازسازی آرایه است، قبل از اجرای بررسی سنگین ظرفیت باقی‌مانده، امکان بازیابی و دستورالعمل مسئول سرویس را بررسی کنید. در بعضی محیط‌ها مناسب است ابتدا فقط گزارش‌های فعلی و لاگ‌های موجود جمع شوند و آزمایش عمیق در پنجرهٔ نگهداری انجام شود.

SMART در دیسک‌های ATA و SATA را چگونه بخوانیم؟

به‌جای تمرکز روی یک مقدار خام، وضعیت کلی را با ویژگی‌هایی که سازنده برای همان مدل تعریف کرده و تغییرات آن‌ها کنار هم قرار دهید. برخی دستگاه‌ها شمارنده‌هایی برای بخش‌های بازتخصیص‌یافته، بخش‌های در انتظار بررسی یا خطاهای اصلاح‌ناپذیر ارائه می‌کنند. یک مقدار خام ثابت ممکن است سابقهٔ رخداد را نشان دهد و افزایش پیوسته در همان شمارندهٔ همان دیسک می‌تواند نیاز به پیگیری فوری‌تر داشته باشد. معنی و حتی شیوهٔ نمایش مقدار خام در مدل‌های مختلف یکسان نیست. اعداد دو دستگاه متفاوت را بدون مراجعه به راهنمای مدل مقایسه نکنید.

یک نمونهٔ عملی این است که دیسک با وضعیت کلی سالم، در سه نمونهٔ پی‌درپی افزایش شمارندهٔ مربوط به بخش‌های نامطمئن نشان دهد و هم‌زمان برنامه برای خواندن فایل‌های بزرگ چند خطا داشته باشد. این شواهد برای باز کردن تیکت کافی‌اند، حتی اگر وضعیت کلی هنوز از آستانهٔ گزارش خودکار عبور نکرده باشد. در تیکت زمان تغییر، نقش دیسک و وضعیت آرایه را بنویسید و دربارهٔ روش بررسی یا تعویض از پشتیبانی سؤال کنید. اگر همان روند روی یک عضو در آرایه دیده می‌شود، قبل از اقدام روی عضو، وضعیت بقیهٔ اعضا و آخرین بازیابی آزمایشی را ببینید.

گزارش NVMe را با شاخص‌های خودش بخوانید

NVMe گزارش SMART/Health دارد، اما فهرست شاخص‌ها عین گزارش ATA نیست. فیلد Critical Warning وضعیت‌هایی را که کنترلر اعلام کرده در قالب بیت‌های هشدار نمایش می‌دهد. Available Spare به ذخیرهٔ قابل‌استفادهٔ باقیمانده در گزارش کنترلر اشاره دارد و در کنار آستانهٔ گزارش‌شده خوانده می‌شود. Percentage Used برآورد مصرف عمر اعلام‌شده توسط سازنده است. رسیدن آن به عدد مشخص، تاریخ قطعی خرابی یا دستور خودکار تعویض برای همهٔ پروژه‌ها تعیین نمی‌کند. آن را با مدل، میزان نوشتن، سیاست نگهداری و نشانه‌های فعلی سلامت کنار هم بخوانید.

شمارندهٔ Media and Data Integrity Errors را با نمونهٔ قبلی همان دستگاه مقایسه کنید. اگر تعداد افزایش یافته و زمان آن با خطاهای کاربر یا لاگ سیستم هم‌خوان است، بررسی را جدی‌تر کنید. شمارندهٔ Error Information Log Entries را جداگانه بخوانید. افزایش آن نیازمند دیدن جزئیات ثبت خطا و زمینهٔ رخداد است. بعضی رخدادها ممکن است از مسیر فرمان یا ارتباط دیده شوند. همین تفاوت دلیل خوبی است که هر افزایش را با یک خلاصهٔ کوتاه از زمان، بار، نوع خطا و وضعیت آرایه مستند کنید و معنای یک شمارنده را به همهٔ مدل‌ها تعمیم ندهید.

مشاهده	برداشت اولیه	اقدام قابل بررسی
Critical Warning در گزارش NVMe فعال است	کنترلر وضعیت مهمی اعلام کرده است	جزئیات هشدار، آرایه و امکان بازیابی را سریع بررسی کنید
شمارندهٔ خطای رسانه نسبت به نمونهٔ قبلی بالا رفته است	وضعیت دستگاه تغییر کرده است	تطبیق با لاگ کرنل و ثبت تیکت با زمان رخداد
دما فقط هنگام بکاپ بالا می‌رود	افزایش دما با یک بار مشخص هم‌زمان است	حدود مدل و خنک‌کاری را بررسی کنید
خطای ارتباط بالا رفته ولی شمارندهٔ رسانه ثابت است	مسیر ارتباط هم به بررسی نیاز دارد	وضعیت کنترلر، مسیر و رخدادهای کرنل را مقایسه کنید
گزارش SMART در دسترس نیست	دید پایش ناقص است	روش دسترسی مناسب دستگاه یا گزارش ارائه‌دهنده را بگیرید

از دما و شمارنده‌های تجمعی چه نتیجه‌ای بگیریم؟

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

در شمارنده‌های تجمعی، مهم است بدانید چه چیزی از شروع عمر، از روشن شدن اخیر یا از یک بازهٔ ثبت دیگر شمرده شده است. مدل، نسخهٔ ابزار و تعریف فیلد را بخوانید. هنگام تعویض دیسک یا تغییر کنترلر، از خط پایهٔ تازه استفاده کنید. اگر مقدار کاهش پیدا کرده، ابتدا بررسی کنید نمونه‌ها از همان دستگاه آمده‌اند یا ابزار عوض شده است. بررسی همین جزئیات از یک گزارش نادرست به تیم شیفت بعدی جلوگیری می‌کند.

«SMART Monitoring Tools» — راهنمای smartctl

خطاهای I/O و تطبیق با کرنل

رخداد را از دید سرویس و سیستم‌عامل کنار هم ببینید

اگر پایگاه داده یا برنامه کند شده، از زمان نخستین علامت شروع کنید. بررسی کنید آیا همان ساعت در لاگ کرنل برای دستگاه مرتبط پیام خطای ورودی و خروجی، پایان مهلت انتظار یا راه‌اندازی دوبارهٔ کنترلر ثبت شده است. پیام‌ها را با زمان و نام دستگاه ذخیره کنید. اگر سیستم چند سرور دارد، ساعت و منطقهٔ زمانی هر منبع را روشن کنید تا رویدادهای نامرتبط به یکدیگر وصل نشوند. بازهٔ کوتاه اطراف رخداد، کنار نمونه‌ای از روز عادی، برای تشخیص الگو مفیدتر از یک خروجی طولانی و بدون توضیح است.

پیام I/O به‌تنهایی حکم تعویض دیسک نیست. منبع می‌تواند دستگاه، مسیر ارتباط، کنترلر یا لایهٔ دیگری در زنجیره باشد. در بررسی اولیه، ترتیب رخدادها را مشخص کنید. اگر ابتدا زمان انتظار افزایش یافته و سپس چند درخواست به پایان مهلت رسیده‌اند، بررسی بار و مسیر هم اهمیت دارد. اگر خطای رسانهٔ همان عضو نیز افزایش یافته، شواهد سمت دستگاه قوی‌تر می‌شود. اگر چند عضو هم‌زمان رخداد مشابه دارند، لایهٔ مشترک را در صورت دسترسی بررسی کنید یا از ارائه‌دهنده گزارش بخواهید.

sudo journalctl -k --since "2 hours ago" --no-pager
iostat -xz 2 3

از فرمان‌های مشاهده‌ای چه انتظار داشته باشیم؟

خروجی لاگ کرنل باید زمان و جزئیات رخداد را نشان دهد. اگر ابزار journalctl در محیط شما نصب نیست یا گزارش کرنل را نگه نمی‌دارد، از روش ثبت لاگ مورد تأیید همان توزیع استفاده کنید. پیام‌های قدیمی ممکن است به‌دلیل سیاست نگهداری در دسترس نباشند. اگر حادثه مهم است، بازه‌ای از گزارش موجود را در مقصد مطمئن نگه دارید و بعد به سراغ تفسیر بروید. برای گزارش به پشتیبانی، داده‌های مشتری، مسیر فایل محرمانه و شماره‌سریال غیرضروری را حذف کنید. زمان دقیق و متن خطای مربوط به دستگاه را حفظ کنید.

اگر ابزار iostat روی سیستم در دسترس است، نمونه‌ای از رفتار دستگاه در زمان عادی و زمان مشکل بگیرید. شاخص‌های زمان انتظار و صف به شما کمک می‌کنند الگو را ببینید. اعداد را در کنار عملیات واقعی برنامه و نوع ذخیره‌سازی بخوانید. روی دستگاهی که چند درخواست را هم‌زمان انجام می‌دهد، یک عدد استفاده از دیسک به‌تنهایی ظرفیت قابل‌استفادهٔ آن را مشخص نمی‌کند. اگر خروجی از حجم منطقی می‌آید، برای تصمیم دربارهٔ عضو فیزیکی آن را با گزارش کنترلر یا آرایه تکمیل کنید.

خطای منفرد را چگونه بررسی کنیم؟

فرض کنید هنگام انتشار گزارش شبانه، یک پیام پایان مهلت ثبت شده و سرویس بعد از آن عادی است. نخست رخداد را مستند کنید. سپس خط پایه و گزارش فعلی را مقایسه کنید و ببینید آیا دستگاه، کنترلر یا آرایه وضعیت تازه‌ای نشان داده است. اگر رخداد تکرار شد، بازه‌ها و فاصلهٔ میان نمونه‌ها را ثبت کنید. یک پیام منفرد می‌تواند نقطهٔ شروع بررسی باشد و رفتار پی‌درپی یا تشدیدشونده اولویت اقدام را تغییر می‌دهد. در محیطی با دادهٔ مهم، وجود بکاپ تازه و آزموده‌شده را با یک مشاهدهٔ واقعی تأیید کنید.

پیوند دادن نام کرنل به عضو آرایه

برای تشخیص عضو درست، نام دستگاه در لاگ را با مدل، شناسهٔ پایدار و جایگاه ثبت‌شده در نقشه تطبیق دهید. اگر پس از راه‌اندازی مجدد نام کوتاه عوض شده است، بر شناسهٔ معتبرتر تکیه کنید. در آرایه‌ای که میزبان مدیریت می‌کند، تأیید کتبی جایگاه از تیم میزبان بگیرید. هنگام ارسال تیکت می‌توانید از نام منطقی سرویس و بخش غیرحساس شناسه شروع کنید. اگر برای عملیات تعویض شناسهٔ کامل لازم شد، آن را از مسیر خصوصی تعیین‌شده ارائه کنید.

اطلاعات لازم برای تیکت تعویض

تاریخ و ساعت رخداد، نام سرور، مدل کنترلر، نقش عضو، وضعیت فعلی آرایه، نتیجهٔ مقایسهٔ SMART و زمان آخرین بازیابی آزمایشی را در یک تیکت کوتاه بنویسید. مشخص کنید عملیات روی سرویس اصلی است یا آزمایشی و هماهنگی پنجرهٔ تغییر با چه کسی است. برای یک عضو معیوب، پرسش دقیق این است که میزبان چگونه عضو درست را تأیید می‌کند و بعد از تعویض چه شاخصی برای پایان بازسازی گزارش می‌دهد. این اطلاعات به تصمیم تیم عملیاتی کمک می‌کند.

نمونهٔ کاربردی: کندی فقط در زمان تهیهٔ بکاپ

فرض کنید سرور فروشگاه در بازهٔ بکاپ کند می‌شود، اما خطای کرنل و شمارندهٔ رسانه تغییری نکرده‌اند. زمان اجرای کار و مدت افت پاسخ را مشخص کنید. سپس نمونه‌ای از صف و زمان انتظار دستگاه، زمان پاسخ پایگاه داده و منابع مصرف‌شده توسط خود کار بکاپ بگیرید. در این سناریو می‌توان دربارهٔ برنامهٔ زمان‌بندی، هم‌زمانی کارها و مقصد بکاپ سؤال کرد. اگر کندی با تغییر برنامه کم شد و شواهد سلامت ثابت ماند، فرضیهٔ بار هم‌زمان تقویت می‌شود. اگر با وجود کاهش بار همچنان خطا ظاهر شد، مرحلهٔ بعد بررسی کنترلر و خود دستگاه است.

نمونهٔ کاربردی: چند خطا روی یک عضو و درخواست‌های ناموفق کاربران

فرض کنید در فاصلهٔ یک روز، شمارندهٔ خطای رسانهٔ یک دستگاه NVMe بالا رفته است و اپلیکیشن هم چند خطای خواندن گزارش کرده است. ابتدا تأیید کنید هر دو مشاهده به همان عضو و همان بازه مربوط‌اند. وضعیت آرایه را بخوانید و مطمئن شوید نسخهٔ پشتیبان مرتبط در دسترس است. در پروندهٔ رخداد بنویسید چند نمونه در اختیار دارید، کدام عدد افزایش یافته، آیا کنترلر هشدار مهمی داده و کاربران در چه مسیرهایی خطا دیده‌اند. اگر خدمت در معرض اختلال است، هماهنگی بازیابی و اقدام پشتیبانی را از همان تیکت پیگیری کنید.

آرایه و بکاپ

سلامت آرایه و سلامت اعضا را جداگانه پایش کنید

یک آرایه ممکن است از نگاه سرویس در حال کار باشد، در حالی که یکی از اعضا رفتار غیرعادی دارد. همچنین ممکن است وضعیت آرایه به‌دلیل عضو حذف‌شده یا بازسازی تغییر کند و گزارش تک‌دیسک در همان لحظه هنوز نشانهٔ روشنی ندهد. در پایش روزانه دو سؤال ثبت کنید: آیا آرایه همهٔ اعضای مورد انتظار را دارد؟ و آیا گزارش اعضای قابل مشاهده نسبت به خط پایه تغییر کرده است؟ زمان بازسازی، میزان پیشرفت و رخدادهای تازه را کنار مصرف سرویس ببینید. نتیجهٔ یک گزارش را به کل مجموعه تعمیم ندهید.

در لینوکس، آرایهٔ نرم‌افزاری MD می‌تواند از طریق اطلاعات کرنل و ابزارهای مرتبط دیده شود. اگر محیط از کنترلر سخت‌افزاری یا فناوری دیگری استفاده می‌کند، شیوهٔ مشاهده ممکن است متفاوت باشد. قبل از استفاده از فرمان نمونه، سازوکار فعال را شناسایی کنید. نام آرایه، سطح، تعداد اعضای مورد انتظار و وضعیت گزارش‌شده را ثبت کنید. اگر عضو تازه اضافه یا تعویض شده است، گزارش قبل و بعد از تغییر را جدا نگه دارید. پس از عملیات، بازگشت وضعیت آرایه و نبود رخدادهای تازه را بررسی کنید.

cat /proc/mdstat
sudo mdadm --detail /dev/md0

بازیابی باید قابل آزمایش باشد

آرایه برای تحمل بعضی خرابی‌های سخت‌افزاری طبق چیدمان خود طراحی می‌شود. بازیابی داده بعد از حذف اشتباه، تغییر خراب برنامه یا حادثه‌ای که چند مؤلفه را هم‌زمان درگیر می‌کند، نیاز جداگانه‌ای است. نسخهٔ پشتیبان زمانی قابل اتکا است که بدانید کجا نگهداری می‌شود، چه کسی اجازهٔ استفاده دارد و آخرین بازگردانی در چه شرایطی موفق بوده است. در یک تست، یک نمونهٔ غیرحساس از داده و تنظیمات وابسته را برگردانید و بررسی کنید برنامه می‌تواند آن را بخواند. تاریخ و مدت بازگشت را ثبت کنید.

اگر یک سرور میزبان چند سرویس است، برای هر سرویس مشخص کنید چند ساعت یا چند روز داده ممکن است از دست برود و چند ساعت توقف قابل تحمل است. این دو هدف می‌توانند روش پشتیبان‌گیری و ترتیب بازیابی را عوض کنند. برای یک فروشگاه فعال، نسخهٔ پایگاه داده و فایل‌های سفارش ممکن است باید از یک بازهٔ هماهنگ باشند. در مقابل، بعضی فایل‌های کش قابل بازتولیدند. چک‌لیست شما باید این تفاوت را از قبل بداند تا هنگام خراب شدن دیسک برای بازیابی دادهٔ کم‌اهمیت وقت صرف نشود.

اتفاق	سؤال اول	مدرک عملیاتی
آرایه با یک عضو کمتر کار می‌کند	کدام عضو و جایگاه تحت تأثیر است؟	وضعیت آرایه و شناسهٔ تأییدشدهٔ عضو
آرایه بازسازی می‌شود	روند پیشرفت و اثر آن بر سرویس چیست؟	گزارش کنترلر و زمان پاسخ سرویس
فایلی به‌اشتباه حذف شده است	نسخهٔ معتبر قبل از حذف کجاست؟	بازیابی یک نمونه در مقصد مجزا
چند عضو رخداد مشترک دارند	عامل مشترک و وضعیت بکاپ چیست؟	زمان‌بندی رخدادها و گزارش کنترلر

یک تمرین کوچک بازیابی قبل از بحران

یک پوشه یا مجموعهٔ دادهٔ نمونه تعیین کنید که ساختار آن شبیه دادهٔ سرویس باشد و اطلاعات حساس نداشته باشد. زمان تهیهٔ بکاپ و نام مجموعه را ثبت کنید. سپس در مقصدی مجزا بازیابی را انجام دهید و نتیجه را از نگاه برنامه بررسی کنید. اگر این آزمون به مجوز اضافه یا یک کلید خاص نیاز دارد، فرایند دریافت آن را در یادداشت داخلی ثبت کنید. بعد از پایان آزمایش، مشخص کنید کدام مسیر یا وابستگی در دستورالعمل کم بود. هدف تمرین این است که تیم بتواند در رخداد واقعی با شرایط مشابه نتیجه را تکرار کند.

هشدار و فرایند رسیدگی

از شاخص به اقدام برسید

برای هر هشدار یک مالک مشخص کنید. مالک ممکن است مسئول شیفت، مدیر سرور یا پشتیبانی میزبان باشد. حداقل دادهٔ لازم برای رسیدگی را داخل خود هشدار بگذارید. نام سرور، نقش دستگاه، ساعت تغییر، مقدار جدید و پیوند به گزارش داخلی معمولاً کافی است. اگر هشدار فقط «دیسک خراب» می‌گوید، گیرنده مجبور می‌شود دوباره همهٔ دستگاه‌ها را بگردد. اگر هشدار مشخص کند وضعیت آرایه تغییر کرده و کدام عضو تحت تأثیر است، کار سریع‌تر شروع می‌شود. دربارهٔ نوع و حدود دسترسی گیرنده هم تصمیم بگیرید تا اطلاعات حساس به کانال عمومی نرود.

خطاهای مهم مانند تغییر وضعیت آرایه، هشدار بحرانی NVMe یا افزایش خطای رسانه که با اختلال کاربر همراه است، به رسیدگی زودتر نیاز دارند. تغییر آهستهٔ شاخص مصرف عمر ممکن است موضوع نگهداری برنامه‌ریزی‌شده باشد. بین این دو، رخدادهایی وجود دارند که نیازمند دیدن چند نمونه‌اند. برای نمونه، یک افزایش دما در زمان بار سنگین با یک افزایش ماندگار در زمان بار عادی اولویت یکسانی ندارد. معیارها را با تجربهٔ سرور خودتان و محدودهٔ اعلام‌شده برای مدل تنظیم کنید. سپس پس از چند هفته بررسی کنید چند هشدار واقعاً به اقدام منجر شده است.

از smartd یا سامانهٔ پایش موجود استفاده کنید

اگر smartd برای دستگاه‌ها و سیستم‌عامل شما مناسب است، تنظیم آن را از مستندات همان نسخه شروع کنید. مشخص کنید کدام دستگاه‌ها در محدودهٔ پایش قرار دارند و هشدار به کدام مقصد می‌رسد. برای دستگاه پشت کنترلر، ابتدا قابلیت خواندن گزارش را جداگانه امتحان کنید. اگر یکپارچگی فعلی شما اطلاعات را از ابزار دیگری می‌خواند، می‌توانید از همان مسیر استفاده کنید و در داشبورد پوشش هر دیسک را ثبت کنید. هدف اصلی این است که بدانید هشدار از کدام دستگاه و کدام شاخص آمده و تحویل آن در شرایط واقعی امکان‌پذیر است.

خود مسیر هشدار را هم آزمایش کنید. دریافت یک اعلان آزمایشی به شما نشان می‌دهد مقصد، تنظیمات و مسئول درست انتخاب شده‌اند. سپس برای موقعیت‌های عادی و خارج از ساعت کاری تعیین کنید چه زمانی باید رخداد تأیید شود. اگر پیام‌رسان یا ایمیل در آن ساعت در دسترس نیست، مسیر جایگزین را در رویهٔ داخلی مشخص کنید. بعد از تغییر تیم یا آدرس گیرنده، آزمون را تکرار کنید. اضافه شدن دیسک جدید هم باید با بازبینی فهرست پایش همراه باشد، وگرنه داشبورد ممکن است فقط اعضای قبلی را نشان دهد.

اگر هشدار به شما رسید چه ترتیبی را دنبال کنید؟

ابتدا مطمئن شوید رخداد تازه است و به سرور درست مربوط می‌شود. سپس ببینید سرویس از دید کاربر در چه وضعیت است و آیا آرایه همهٔ اعضای مورد انتظار را دارد. گزارش فعلی دستگاه را با خط پایه مقایسه کنید. یک نسخه از لاگ مرتبط را نگه دارید و در صورت خطر برای داده یا خدمت، دسترسی به نسخهٔ پشتیبان و نتیجهٔ آخرین بازیابی را بررسی کنید. اگر رفع مشکل به عملیات فیزیکی نیاز دارد، از پشتیبانی بخواهید عضو و پنجرهٔ تغییر را تأیید کند. در چنین شرایطی تصمیم بازگردانی و تصمیم تعویض را در تیکت به‌صورت جداگانه توضیح دهید.

بعد از پایان رسیدگی، فقط بسته شدن تیکت را معیار قرار ندهید. وضعیت آرایه، دسترسی سرویس، خواندن فایل‌های نمونه و گزارش جدید دستگاه را بررسی کنید. اگر تعویض انجام شده، خط پایهٔ عضو تازه را ثبت کنید. اگر معلوم شد رخداد از کنترلر یا مسیر مشترک آمده، یادداشت پایش را به‌روزرسانی کنید تا بار بعد نخستین فرضیه به‌طور خودکار تعویض دیسک نباشد. در یادداشت کوتاه بنویسید چه چیزی دیده شد، چه اقدامی انجام شد و کدام معیار نشان داد سرویس به شرایط معمول برگشته است.

نمونهٔ یک هشدار و شرح پیگیری

فرض کنید ساعت ۰۲:۱۵ آرایهٔ یک سرور فایل با عضو کمتر از تعداد مورد انتظار کار می‌کند. پیام اولیه می‌تواند نام سرور، نام آرایه، عضو احتمالی و زمان آخرین گزارش سالم را داشته باشد. مسئول شیفت ابتدا باز بودن سرویس را بررسی می‌کند و از تکرار عملیات روی دیسک خودداری می‌کند تا عضو در گزارش کنترلر تأیید شود. سپس اطلاعات بکاپ سرویس و امکان بازیابی یک نمونه را جمع می‌کند. اگر پشتیبانی میزبان تعویض را پیشنهاد دهد، زمان مناسب، اثر مورد انتظار و معیار پایان را از پیش ثبت می‌کنند.

در نمونهٔ دیگری، هیچ وضعیت بحرانی وجود ندارد ولی درصد مصرف عمر در چند ماه رو به افزایش است. تیم می‌تواند نرخ تغییر و نوع بار را ثبت کند و با سازنده یا میزبان دربارهٔ نگهداری برنامه‌ریزی‌شده گفت‌وگو کند. اگر الگوی نوشتن با تغییر یک کار دوره‌ای عوض شده باشد، این تغییر ممکن است در تحلیل لازم باشد. تصمیم را به یک عدد بدون زمینه گره نزنید. نرخ افزایش، نقش دستگاه و امکان تهیهٔ نسخهٔ قابل‌بازیابی ارزش بیشتری برای زمان‌بندی تصمیم فراهم می‌کنند.

چک‌لیست خرید سرور اختصاصی ایران

قبل از سفارش چه چیزی را از پشتیبانی بپرسیم؟

از نیاز واقعی سرویس شروع کنید. اگر پایگاه داده و فایل مشتری روی یک سرور نگهداری می‌شوند، زمان قابل تحمل توقف و روش بازیابی را بنویسید. سپس دربارهٔ نوع دیسک، مدل کنترلر یا آرایه، امکان خواندن گزارش سلامت و مسئول تعویض فیزیکی سؤال کنید. شیوهٔ دسترسی یا ابزار تأییدشده را در همان پاسخ مشخص کنید. در صورت نیاز به کنسول، روشن کنید هنگام دسترسی‌نداشتن از طریق شبکه، چه مسیر مدیریتی در اختیار دارید و این دسترسی طبق شرایط سرویس چگونه ارائه می‌شود.

اگر دیسک نیاز به تعویض داشته باشد، پاسخ مربوط به هماهنگی مهم است. بپرسید تأیید عضو از چه روشی انجام می‌شود و آیا عملیات به توقف خدمت نیاز دارد. اگر میزبان پایش را انجام می‌دهد، بپرسید نتیجه با چه سطح جزئیاتی در اختیار شما قرار می‌گیرد. اگر پایش بر عهدهٔ تیم خودتان است، در دورهٔ راه‌اندازی یک نمونه گزارش سلامت و یک هشدار آزمایشی بگیرید. برای بکاپ، محل نگهداری، دامنهٔ پوشش و امکان بازیابی را مشخص کنید. ادعاهای مربوط به پلن را از صفحهٔ محصول یا پشتیبانی تأیید کنید.

شرط خرید	سؤال پیشنهادی	معیار پذیرش
دید به سلامت دیسک	گزارش عضو فیزیکی از چه طریقی قابل دریافت است؟	نمونهٔ معتبر از عضو یا کنترلر
تعویض سخت‌افزاری	چه کسی عضو معیوب و زمان تعویض را تأیید می‌کند؟	رویه و کانال پیگیری مشخص
پایش و اعلان	هشدار چه رخدادهایی به کجا می‌رسد؟	یک اعلان آزمایشی موفق
بازیابی اطلاعات	داده از کدام محل و با چه مجوزی بازگردانده می‌شود؟	بازیابی موفق یک دادهٔ نمونه
مدیریت هنگام اختلال	در زمان دسترسی‌نداشتن از شبکه چه گزینه‌ای داریم؟	مسیر مدیریت تأییدشده برای سرویس

مقایسهٔ سرویس را به مشاهده‌پذیری گره بزنید

اگر تیم شما به گزارش هر دیسک و هماهنگی مستقیم عملیات نیاز دارد، این نیاز را هنگام بررسی سرور اختصاصی ایران وطن هاست مطرح کنید. اگر بار کاری کوچک‌تر است و مسئولیت سخت‌افزار را به ارائه‌دهنده می‌سپارید، پلن‌های سرور مجازی ایران را هم بر اساس سطح دسترسی، پشتیبانی و روش بازیابی ارزیابی کنید. پاسخ در هر سرویس باید از مستندات همان سرویس یا پشتیبانی تأیید شود. صرف اشتراک نام فناوری ذخیره‌سازی به معنی دسترسی یکسان به پایش دیسک نیست.

برای انتخاب مسیر مهاجرت، راهنمای مهاجرت از سرور مجازی به اختصاصی به تصمیم دربارهٔ زمان انتقال کمک می‌کند. اگر سؤال تیم دربارهٔ فناوری ذخیره‌سازی است، مقایسهٔ NVMe و SSD را در کنار این راهنما بخوانید. پرسش‌های عملی این مقاله برای بعد از انتخاب یا در زمان بررسی پلن مفیدند. می‌توانید آن‌ها را به تیکت پیش از خرید تبدیل کنید و پاسخ را در برگهٔ راه‌اندازی سرور نگه دارید.

چک‌لیست تحویل سرور به تیم عملیات

در روز تحویل، یک نفر فهرست اجزای ذخیره‌سازی را با گزارش ارائه‌دهنده تطبیق دهد و نفر دیگری بتواند بر اساس همان فهرست، بدون کمک فرد اول، دیسک مربوط به یک سرویس نمونه را پیدا کند. این آزمون ساده نشان می‌دهد اطلاعات موجود برای یک شیفت واقعی کافی است. اگر هر دو نفر برای یافتن دستگاه به حدس وابسته‌اند، نام‌های منطقی و جایگاه اعضا را روشن‌تر کنید. پس از آن یک گزارش سلامت با زمان مشخص ذخیره کنید تا در هفته‌های بعد معیار مقایسه داشته باشید. در همان روز حدود مسئولیت تیم داخلی و پشتیبانی میزبان را در تیکت تحویل ثبت کنید.

در هفتهٔ اول، فقط سلامت لحظهٔ تحویل را معیار نگیرید. پس از نخستین بکاپ، کار زمان‌بندی‌شده یا انتقال حجم اصلی داده، گزارش دیگری بگیرید و ببینید بار جدید چه تغییری در دما و صف ایجاد کرده است. از مقایسهٔ نمونه‌ای که هنگام بیکاری گرفته شده با نمونهٔ وسط یک کار سنگین، نتیجهٔ قطعی دربارهٔ خرابی نگیرید. در عوض ساعت، فعالیت هم‌زمان و نوع پاسخ را ثبت کنید. اگر کار شبانه زمان پاسخ را زیاد می‌کند، به‌صورت جداگانه بررسی کنید آیا کاربران در همان بازه اختلال دیده‌اند و آیا می‌توان زمان آن را با الگوی استفاده هماهنگ کرد.

بعد از یک ماه، مرور کوتاهی برای پوشش پایش انجام دهید. بررسی کنید همهٔ دیسک‌هایی که در فهرست هستند واقعاً نمونهٔ قابل خواندن دارند و هشدار برای همه به مسیر درست می‌رود. سپس یک نتیجهٔ روشن برای ادامه ثبت کنید. مثلاً یک عضو پشت کنترلر هنوز گزارش مستقیم ندارد و پشتیبانی ماهانه گزارش آن را می‌دهد. با چنین توافقی مشخص می‌شود کدام بخش خودکار است و کدام بخش نیاز به پیگیری دارد. اگر گزارش مورد انتظار نرسید، آن را به‌عنوان وقفهٔ پایش ثبت کنید تا نبود هشدار با سلامت قطعی اشتباه نشود.

پرسش‌های متداول

اگر وضعیت SMART سالم باشد، پایش دیگری لازم است؟

بله. وضعیت کلی را با روند شاخص‌های همان دستگاه، رخدادهای کرنل و گزارش آرایه مقایسه کنید. سلامت کلی ممکن است در یک نمونه مثبت باشد و در عین حال یکی از شمارنده‌ها در چند نمونه تغییر کند. برای تشخیص، زمان و نام عضو را کنار هر مشاهده ثبت کنید و نتیجه را به مدل‌های دیگر تعمیم ندهید.

آیا افزایش دما حتماً نشانهٔ خرابی دیسک است؟

تفسیر دما به مدل، زمان اندازه‌گیری و بار هم‌زمان وابسته است. افزایش کوتاه هنگام یک کار سنگین با افزایش ماندگار در زمان بیکاری شرایط یکسانی ندارد. بازهٔ مجاز مدل و شرایط خنک‌کاری را بررسی کنید. اگر دما خارج از محدودهٔ تأییدشده است یا هشدار همراه با افت سرویس رخ داده، زمان و شرایط را برای پشتیبانی مستند کنید.

چرا سیستم‌عامل دیسک‌های پشت RAID را نشان نمی‌دهد؟

بعضی کنترلرها حجم منطقی را به سیستم‌عامل معرفی می‌کنند و دسترسی به اطلاعات اعضای فیزیکی به سازوکار دیگری وابسته است. مدل کنترلر، نسخهٔ ابزار و روش مورد تأیید میزبان را بررسی کنید. اگر اطلاعات اعضا در دسترس شما نیست، گزارش کنترلر یا گزارش پشتیبانی را به پایش اضافه کنید تا نمای دقیق‌تری از وضعیت آرایه داشته باشید.

آیا تمام خطاهای I/O به دیسک معیوب مربوط می‌شوند؟

خطای ورودی و خروجی علامت مشکل در مسیر درخواست است و برای تشخیص منشأ به زمینه نیاز دارد. رخداد کرنل را با زمان اختلال، شناسهٔ عضو، گزارش سلامت و وضعیت کنترلر مقایسه کنید. رخداد هم‌زمان روی چند عضو می‌تواند بررسی مسیر مشترک را ضروری کند. افزایش خطای رسانه روی یک عضو مشخص نیز فرضیهٔ مشکل همان دستگاه را تقویت می‌کند.

چه زمانی باید دربارهٔ تعویض با میزبان صحبت کرد؟

اگر هشدار بحرانی فعال است، وضعیت آرایه تغییر کرده یا خطای رسانه همراه با اثر قابل مشاهده روی سرویس افزایش می‌یابد، مستندات رخداد را به پشتیبانی بدهید. برای شاخص‌های تغییر آهسته، زمان‌بندی نگهداری را بر اساس نقش دستگاه، سیاست سازنده و امکان بازیابی بررسی کنید. در هر دو حالت عضو و نقش آن را پیش از عملیات تأیید کنید.

آرایهٔ سالم به معنی داشتن بکاپ است؟

تحمل خرابی در آرایه و بازگردانی اطلاعات دو کار متفاوت‌اند. برای بازگردانی داده به نسخهٔ مناسب و یک روش آزموده نیاز دارید. زمان آخرین بازیابی آزمایشی، محل نسخه و دسترسی لازم را در پروندهٔ سرویس ثبت کنید. در تمرین از داده‌ای نمونه استفاده کنید و باز شدن آن را از مسیر برنامه بررسی کنید.

جمع‌بندی

پایش سلامت دیسک با یک خط پایه و نقشهٔ روشن ذخیره‌سازی شروع می‌شود. گزارش هر عضو را در بازه‌های قابل مقایسه بخوانید، خطاهای کرنل و وضعیت آرایه را با همان زمان تطبیق دهید و برای هشدار مهم مالک اقدام تعیین کنید. برای تصمیم تعویض، نشانه‌های تکرارشونده و شواهد مربوط به همان عضو را در کنار امکان بازیابی بررسی کنید. اگر قصد خرید دارید، از صفحهٔ سرور اختصاصی ایران وطن هاست مشخصات سرویس را بررسی کنید و دربارهٔ دسترسی پایش، فرایند تعویض و روش بازیابی متناسب با بار کاری خود سؤال بپرسید.

منابع فنی راهنمای smartctl، پیکربندی smartd، راهنمای nvme-smart-log و مستندات آرایه‌های MD در لینوکس.