سلامت هارد سرور؛ ۷ روش تست و پایش دقیق
سلامت هارد سرور تنها به روشن بودن دیسک یا سبز بودن چراغ RAID محدود نمی شود. برای جلوگیری از توقف سرویس و از دست رفتن داده، باید شاخص های SMART، کارایی خواندن و نوشتن، خطاهای کنترلر و روند تغییر عملکرد را زیر نظر گرفت. در این راهنما، هفت روش کاربردی برای تست هارد سرور و پایش سلامت دیسک سرور مرور می شود تا بتوانید برنامه ای منظم و متناسب با بار کاری سازمان خود بسازید.
فهرست مطالب
سلامت هارد سرور دقیقاً چه معنایی دارد؟
در محیط سرور، سلامت هارد سرور یعنی توانایی دیسک برای ذخیره و ارائه پایدار داده در شرایط کاری واقعی. دیسکی که در حالت بی کاری خطایی نشان نمی دهد، ممکن است هنگام بار هم زمان چند ماشین مجازی یا اجرای یک پایگاه داده، با افزایش تأخیر و خطای ورودی وخروجی روبه رو شود.
ارزیابی فنی باید دست کم سه بُعد را در نظر بگیرد: وضعیت فیزیکی و خطاهای رسانه، عملکرد دیسک زیر بار، و سلامت مسیر ارتباطی شامل کابل، backplane و کنترلر. این تفکیک مهم است؛ زیرا هر خطایی که در گزارش دیسک ثبت می شود الزاماً به معنی خرابی خود هارد نیست.
برای مثال، افزایش شمارنده خطای انتقال می تواند از اتصال نامناسب یا مسیر ارتباطی معیوب ناشی شود. بنابراین بررسی سلامت هارد سرور بدون توجه به سایر اجزای زیرساخت ذخیره سازی، تصویر کاملی به دست نمی دهد.
چرا پایش سلامت دیسک سرور مهم است؟
خرابی ناگهانی همیشه قابل پیش بینی نیست، اما بسیاری از دیسک ها پیش از ازکارافتادن نشانه هایی مانند رشد خطاهای رسانه ای، کندی نامعمول یا هشدار کنترلر نشان می دهند. ثبت منظم این نشانه ها فرصت می دهد پیش از تبدیل مشکل به قطعی، نسخه پشتیبان را بررسی کنید و بار را جابه جا کنید.
در سرورهای دارای RAID نیز وجود افزونگی به معنی بی نیازی از پایش نیست. هنگام بازسازی آرایه، دیسک های باقی مانده تحت فشار بیشتری قرار می گیرند و خرابی دیسک دوم می تواند دسترس پذیری داده را به خطر بیندازد. برای پیاده سازی پایش پیوسته، می توانید از راهنمای راه اندازی سیستم پایش و مانیتورینگ زیرساخت مجازی کمک بگیرید.
مانیتورینگ هارد سرور باید هم وضعیت کلی آرایه و هم هر دیسک را جداگانه پوشش دهد. اتکا به پیام «Optimal» کنترلر کافی نیست، چون ممکن است یک دیسک خطاهای اصلاح شده یا تأخیر غیرعادی داشته باشد.
هفت روش تست و پایش سلامت هارد سرور

۱. تحلیل SMART و مقایسه روند شاخص ها
SMART داده هایی درباره عملکرد و وضعیت داخلی دیسک در اختیار می گذارد. شاخص هایی مانند سکتورهای بازتخصیص یافته، سکتورهای معلق و خطاهای غیرقابل اصلاح می توانند برای شناسایی روندهای نگران کننده مفید باشند. در لینوکس، ابزارهایی مانند smartctl برای خواندن این اطلاعات کاربرد دارند.
به جای آنکه فقط به پیام کلی «PASSED» توجه کنید، خروجی را در بازه های زمانی ثبت و با داده های قبلی مقایسه کنید. ثابت ماندن مقدارها معمولاً با افزایش پیوسته یک شمارنده تفاوت دارد. پیش از اجرای آزمون نیز مستندات سازنده سرور یا کنترلر را بررسی کنید.
۲. اجرای خودآزمایی کوتاه و بلند دیسک
بسیاری از دیسک ها قابلیت اجرای خودآزمایی داخلی دارند. آزمون کوتاه معمولاً برای غربالگری سریع مناسب است، درحالی که آزمون طولانی بخش بیشتری از سطح رسانه را بررسی می کند و ممکن است زمان بیشتری بگیرد.
زمان مناسب اجرا را با توجه به نوع بار کاری انتخاب کنید؛ اجرای تست طولانی در اوج مصرف، به ویژه روی سرور حساس، می تواند بر پاسخ گویی سرویس اثر بگذارد. این آزمون ها جایگزین نسخه پشتیبان یا بررسی عملکرد نیستند.
اگر دیسک در محیط تولیدی کار می کند، ابتدا وضعیت بکاپ را تأیید کنید و از اجرای آزمون های مخرب یا نوشتنی روی داده های مهم خودداری کنید. پس از پایان نیز گزارش تست و زمان اجرا را در سامانه پایش ثبت کنید تا نتیجه های آینده قابل مقایسه باشند.
۳. سنجش latency، IOPS و throughput
یکی از مهم ترین مراحل بررسی، اندازه گیری کارایی در شرایطی نزدیک به بار واقعی است. تأخیر خواندن و نوشتن، تعداد عملیات ورودی وخروجی در ثانیه و نرخ انتقال داده می توانند افت عملکردی را آشکار کنند که در آزمون سلامت ساده دیده نمی شود.
ابزارهایی مانند fio امکان تعریف الگوی کاری مشخص را می دهند؛ برای نمونه، خواندن تصادفی برای بعضی پایگاه های داده یا انتقال ترتیبی برای آرشیو فایل. تست باید با احتیاط انجام شود. اجرای آزمون نوشتن روی دیسکی که داده عملیاتی دارد ممکن است اطلاعات را بازنویسی کند.
بنابراین از فایل آزمایشی یا محیط جداگانه استفاده کنید و تنظیمات را دقیق بخوانید. نتیجه یک تست منفرد نیز به تنهایی حکم خرابی نیست؛ بار هم زمان، نوع RAID، کش کنترلر و محدودیت شبکه ذخیره سازی هم بر اعداد اثر می گذارند.
۴. بررسی دیسک های منفرد و گزارش کنترلر RAID
در آرایه RAID، وضعیت کلی می تواند «Optimal» باشد، در حالی که یک دیسک خطاهای اصلاح شده یا تأخیر غیرعادی دارد. گزارش کنترلر را برای هر دیسک جداگانه بخوانید و مواردی مانند media error، خطای پیش بینی خرابی، وضعیت rebuild و رخدادهای خارج شدن و بازگشت دیسک را بررسی کنید.
- وضعیت آرایه و دیسک های عضو را جداگانه ثبت کنید.
- خطاهای رسانه و ارتباط را از هم تفکیک کنید.
- زمان شروع و پایان rebuild و هرگونه توقف آن را بررسی کنید.
- پیش از تعویض، شماره اسلات دیسک معیوب را از ابزار مدیریتی تأیید کنید.
برداشتن دیسک اشتباه یا خارج کردن چند دیسک به صورت هم زمان می تواند وضعیت آرایه را بحرانی کند. در صورت ابهام، تغییر سخت افزاری را متوقف کنید و ابتدا مستندات کنترلر و نقشه اسلات ها را بررسی کنید. برای انتخاب دیسک مناسب، صفحه خرید هارد HDD سرور مشخصات فنی مفیدی ارائه می دهد.
۵. تحلیل لاگ سیستم عامل و کنترلر
لاگ ها به شناسایی خطاهای تکرارشونده و زمان شروع مشکل کمک می کنند. در لینوکس، پیام های مرتبط با لایه بلوکی، کنترلر و درایور را در گزارش های سیستم بررسی کنید. افزایش timeout، reset شدن دستگاه یا خطاهای ورودی وخروجی ممکن است به دیسک، کنترلر، کابل یا برق رسانی مربوط باشد.
هم زمانی این رخدادها با کندی برنامه ها سرنخ مهمی برای عیب یابی فراهم می کند. برای تحلیل بهتر، زمان رخدادها را با نمودار latency، مصرف منابع و گزارش های RAID تطبیق دهید. اگر خطا فقط هنگام بار سنگین دیده می شود، احتمال محدودیت عملکرد یا مشکل در مسیر ارتباطی را نیز بررسی کنید.
ثبت لاگ بدون نگهداری و مقایسه، ارزش محدودی دارد؛ برای همین بهتر است گزارش ها به سامانه ای مرکزی ارسال شوند. این کار بخشی از راهبرد مانیتورینگ هارد سرور است.
۶. استفاده از ابزارهای سازنده و بررسی سخت افزار جانبی
ابزارهای عمومی برای بررسی اولیه مفیدند، اما ابزار رسمی سازنده سرور، کنترلر یا دیسک می تواند اطلاعات اختصاصی تری نمایش دهد. این ابزارها ممکن است وضعیت firmware، خطاهای قابل اصلاح، پیش بینی خرابی یا رویدادهای سخت افزاری را گزارش کنند.
نسخه ابزار و firmware را نیز ثبت کنید، چون تفاوت نسخه ها می تواند بر نحوه نمایش یا تفسیر داده اثر بگذارد. اگر شمارنده خطای انتقال افزایش می یابد اما نشانه ای از خرابی رسانه وجود ندارد، کابل، اتصال، backplane و پورت کنترلر را هم بررسی کنید.
در برخی سناریوها، مشکل اصلی از هارد نیست و تعویض دیسک باعث رفع ریشه ای اختلال نمی شود. برای آشنایی با راهکارهای سخت افزاری سازمانی، پکیج راهکارهای سخت افزاری برای سازمان ها و صنایع مختلف را ببینید.

۷. مقایسه با خط مبنا و پایش پیوسته
یک عدد به تنهایی همیشه غیرعادی نیست؛ مقایسه آن با عملکرد معمول همان دیسک، در همان سرور و تحت بار مشابه، معنا پیدا می کند. یک خط مبنا از latency، نرخ خطا، دما و حجم ورودی وخروجی تهیه کنید و آستانه هشدار را بر اساس نوع سرویس تنظیم کنید.
آستانه یکسان برای سرور آرشیو و میزبان پایگاه داده معمولاً تصمیم مناسبی نیست. پایش را طوری تنظیم کنید که افزایش تدریجی خطا یا کندی را زودتر از رسیدن به وضعیت بحرانی گزارش دهد. هشدارها باید به فرد یا تیم مسئول برسند و برای هر هشدار، رویه پاسخ گویی مشخص باشد.
برای امنیت و دسترس پذیری زیرساخت ذخیره سازی نیز می توانید توصیه های منتشرشده در راهنمای NIST درباره امنیت سامانه های ذخیره سازی را مطالعه کنید.
نشانه هایی که نیاز به بررسی فوری دارند
برخی رخدادها باید سریع تر از برنامه پایش عادی پیگیری شوند. این موارد به تنهایی علت خرابی را قطعی نمی کنند، اما نادیده گرفتنشان می تواند ریسک سرویس را بالا ببرد:
- افزایش پیوسته سکتورهای معلق یا بازتخصیص یافته؛
- خطاهای مکرر خواندن و نوشتن یا خارج شدن دیسک از آرایه؛
- افزایش محسوس تأخیر نسبت به خط مبنای همان سرور؛
- هشدار پیش بینی خرابی از کنترلر یا ابزار رسمی سازنده؛
- توقف یا طولانی شدن غیرعادی عملیات rebuild.
هنگام مشاهده این نشانه ها، ابتدا از سالم بودن نسخه پشتیبان و امکان بازیابی آن مطمئن شوید. سپس گزارش ها را ذخیره کنید و وضعیت بار، آرایه و مسیر ارتباطی را بررسی کنید. تعویض دیسک در سرور عملیاتی باید طبق دستورالعمل سازنده و سیاست سازمان انجام شود؛ به خصوص اگر آرایه در حالت degraded است یا بازسازی آن جریان دارد.
برنامه ریزی برای تست ایمن و کاربردی
برنامه مناسب باید با حساسیت سرویس و توان عملیاتی تیم هماهنگ باشد. بررسی SMART و لاگ ها را می توان به صورت منظم و خودکار انجام داد؛ اما تست های سنگین عملکردی بهتر است در پنجره نگهداری یا روی محیطی جدا اجرا شوند.
برای هر سرور، مدل دیسک، شماره سریال، firmware، اسلات، نوع RAID و تاریخ آخرین آزمون را ثبت کنید. برای ماشین های مجازی و سرویس های پایگاه داده، معیارهایی مانند تأخیر صدک های بالا اهمیت دارند؛ میانگین خوب ممکن است جهش های کوتاه اما مخرب را پنهان کند.
اگر ذخیره سازی از چند لایه یا استوریج اشتراکی تشکیل شده، محل دقیق ایجاد تأخیر را مشخص کنید. همچنین برای حفظ داده ها، راه اندازی سرور بکاپ و آزمون دوره ای بازیابی را در برنامه بگنجانید.
جمع بندی
برای ارزیابی دقیق سلامت هارد سرور، به یک چراغ سبز یا یک آزمون منفرد تکیه نکنید. SMART، خودآزمایی دیسک، سنجش کارایی، گزارش RAID، لاگ ها و بررسی مسیر سخت افزاری را کنار هم بگذارید و نتایج را در طول زمان مقایسه کنید.
با پایش منظم، بکاپ قابل بازیابی و رویه تعویض مشخص، می توان بسیاری از اختلال ها را پیش از تبدیل شدن به قطعی جدی شناسایی و مدیریت کرد. بررسی سلامت هارد سرور یک فعالیت یک باره نیست؛ فرایندی مستمر است که به پایداری سرویس کمک می کند.
پرسش های متداول درباره سلامت هارد سرور
هر چند وقت یک بار باید هارد سرور را بررسی کنیم؟
بازه بررسی به حساسیت سرویس، نوع دیسک و سیاست سازمان بستگی دارد. پایش شاخص های SMART و لاگ ها بهتر است پیوسته یا زمان بندی شده باشد؛ تست های طولانی و عملکردی را نیز در بازه نگهداری و متناسب با بار سرور اجرا کنید.
آیا وضعیت SMART سالم، خرابی هارد را رد می کند؟
خیر. SMART ابزار غربالگری مفیدی است، اما همه خرابی ها را پیش بینی نمی کند و پیام کلی آن به معنی تضمین عملکرد مناسب نیست. نتایج را همراه با تأخیر، خطاهای سیستم عامل و گزارش کنترلر بررسی کنید.
آیا تست عملکرد می تواند به داده های سرور آسیب بزند؟
بله، بعضی آزمون های نوشتن ممکن است داده را بازنویسی کنند. پیش از اجرا، نوع تست و مقصد آن را بررسی کنید، نسخه پشتیبان معتبر داشته باشید و از فایل یا محیط آزمایشی استفاده کنید؛ به ویژه روی سرور عملیاتی.
چطور خرابی هارد را از مشکل کابل یا کنترلر تشخیص دهیم؟
نوع خطا و روند آن را بررسی کنید. افزایش خطاهای رسانه ای می تواند به خود دیسک مربوط باشد، درحالی که خطاهای انتقال ممکن است از کابل، backplane یا کنترلر ناشی شوند. گزارش SMART، لاگ سیستم و ابزار سازنده را با هم مقایسه کنید.
آیا RAID نیاز به نسخه پشتیبان را از بین می برد؟
خیر. RAID برای افزایش دسترس پذیری در برابر برخی خرابی های سخت افزاری طراحی شده است، اما جایگزین بکاپ نیست. حذف تصادفی، آسیب نرم افزاری، باج افزار یا خرابی هم زمان چند مؤلفه همچنان می تواند داده را از دسترس خارج کند.


