هشدار باتری کنترلر RAID یعنی چه؟ از افت سرعت تا محافظت از داده

در پنل سخت‌افزاری سرور پیام باتری کنترلر RAID را می‌بینید و هم‌زمان سرعت نوشتن روی دیسک پایین آمده است. آیا دیسک‌ها خراب شده‌اند؟ آیا کافی است تنظیم کش را دوباره روشن کنید؟ پاسخ هر دو سؤال به وضعیت کنترلر بستگی دارد. باتری یا واحد انرژی کش، با باتری اصلی سرور یکی نیست و هشدار آن به‌تنهایی ثابت نمی‌کند دیسک فیزیکی خراب است.

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

فرض کنید برنامه اطلاعاتی را برای ذخیره می‌فرستد. کنترلر RAID در برخی حالت‌ها از حافظه سریع خود، یعنی کش، برای مدیریت عملیات نوشتن استفاده می‌کند. در حالت Write-Back ممکن است کنترلر پیش از کامل‌شدن نوشتن روی دیسک، دریافت عملیات را پس از قرارگرفتن داده در کش تأیید کند. در نتیجه بعضی بارهای کاری سریع‌تر پیش می‌روند، اما داده‌ای که هنوز فقط در کش است هنگام قطع برق باید محافظت شود.

در حالت Write-Through کنترلر معمولاً پس از نوشته‌شدن داده روی دیسک پاسخ تکمیل می‌دهد. بسته به کنترلر و نوع کار، این حالت می‌تواند کندتر باشد. هیچ‌کدام از این دو عبارت به‌تنهایی تضمین سلامت داده در تمام مسیر ذخیره‌سازی نیست؛ سیستم‌عامل، برنامه، دیسک و تنظیمات دیگر هم نقش دارند.

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

در بعضی کنترلرها، وقتی واحد محافظ کش شارژ کافی ندارد یا خراب تشخیص داده می‌شود، کنترلر برای محافظت از داده سیاست نوشتن را از Write-Back به Write-Through تغییر می‌دهد. در این حالت ممکن است کارهایی مانند ثبت سفارش، نوشتن پایگاه داده یا ساخت فایل کندتر شوند. اما هر کندی دیسکی به این هشدار مربوط نیست؛ باید زمان هشدار و تغییر سیاست را با زمان افت عملکرد مقایسه کرد.

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

از پنل مدیریتی سخت‌افزار یا گزارش مرکز داده این اطلاعات را بردارید:

۱. مدل سرور و مدل دقیق کنترلر RAID؛ ۲. متن کامل هشدار، زمان شروع و وضعیت واحد انرژی یا باتری؛ ۳. نام یا شناسه آرایه یا Virtual Disk مربوط؛ ۴. سیاست فعلی نوشتن و اگر پنل نشان می‌دهد، سیاست مورد انتظار یا تنظیم‌شده؛ ۵. وضعیت هر دیسک فیزیکی و وضعیت کلی آرایه؛ ۶. زمان شروع کندی و نمونه‌ای از عملیاتی که کند شده است.

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

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

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

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

پنل ذخیره‌سازی معمولاً اطلاعات کنترلر، آرایه و دیسک فیزیکی را در بخش‌های جدا نشان می‌دهد. در همان پنل یا با کمک ارائه‌دهنده، این موارد را با هم ببینید:

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

ممکن است در پنل گزینه‌ای شبیه Force Write-Back یا فعال‌کردن کش بدون باتری وجود داشته باشد. فعال‌کردن اجباری آن در زمانی که حفاظت انرژی کار نمی‌کند می‌تواند داده نوشته‌نشده را هنگام قطع برق در معرض از دست رفتن قرار دهد. این کار را صرفاً برای برگرداندن سرعت انجام ندهید.

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

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

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

برای درخواست پشتیبانی می‌توانید بنویسید:

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

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

۱. وضعیت باتری یا ماژول انرژی و پیام‌های تازه را در پنل همان کنترلر ببینید. بسته به مدل، شارژشدن یا بازگشت حالت محافظت‌شده ممکن است زمان ببرد. ۲. وضعیت آرایه و دیسک‌ها را جداگانه بررسی کنید. سبزشدن باتری به معنی سالم‌بودن تک‌تک دیسک‌ها نیست. ۳. سیاست واقعی نوشتن را با سیاست مورد تأیید برای همان سرویس مقایسه کنید. اگر هنوز Write-Through است، علت را از مرکز داده بپرسید؛ آن را اجباری تغییر ندهید. ۴. همان عملیات واقعی را که پیش از مشکل کند شده بود در شرایط قابل مقایسه امتحان کنید. برای مثال زمان ثبت یک سفارش آزمایشی یا گزارش داخلی را ثبت کنید؛ فشار مصنوعی سنگین روی سرور مشتریان وارد نکنید. ۵. هشدارها، قطعه تعویض‌شده و نتیجه آزمون را ثبت و بکاپ مستقل را طبق برنامه بررسی کنید. RAID و کش محافظت‌شده جای نسخه پشتیبان نیستند.

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

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