عندما منع عطل قرص الحالة الصلبة من نوع Lexar NS100 إقلاع OPNsense: CAM وTRIM ومهلة الـ31 ثانية

توقف جدار الحماية لدى أحد عملائنا، وكان القرص هو السبب. لم يتمكن نظام OPNsense من الإقلاع من قرص الحالة الصلبة الداخلي، ولم يتمكن من الإقلاع من أي وسيط آخر ما دام ذلك القرص متصلاً. كان القرص يعرض الرسالة التالية:

Attempt to query device size failed not ready
device not ready after 31000ms

القرص المعطّل في نظام العميل كان Lexar NS100 سعة 512 جيجابايت، وهو قرص حالة صلبة SATA (الطراز LNS100-512RB). بعد إزالته، أقلع النظام من وسيط التثبيت. أعدنا تثبيت OPNsense على قرص USB 3 Gen2، واستعدنا الإعدادات السابقة، وأعدنا تثبيت الإضافات الناقصة، ثم أعدنا جدار الحماية إلى الخدمة. قرص USB كان حلاً مؤقتاً للاستعادة؛ أما قرص الحالة الصلبة المعطّل فقد خرج من الخدمة نهائياً.

الأثر على العمل

جدار الحماية الطرفي نقطة فشل واحدة للاتصال وDNS وVPN والوصول عن بُعد. وعندما يتعطل قرص الإقلاع فيه، لا تكون المشكلة مجرد قرص تالف، بل يتوقف محيط الشبكة بأكمله عن العمل. في هذه الحادثة أدّت نسخة الإعدادات الاحتياطية دورها، لكن عطل العتاد ظل مشروع استعادة غير مخطط له.

هذا هو الدرس العملي: النسخة الاحتياطية لا تكون مفيدة إلا إذا كانت عملية الاستعادة نفسها مختبرة، وكان لديك وسيط إقلاع جاهز عندما يرفض النظام العمل.

لماذا رفض النظام الإقلاع بالكامل

يعمل OPNsense على FreeBSD. تمر عمليات القرص عبر نظام Common Access Method (CAM) في FreeBSD، وهو المسؤول عن التعامل مع أجهزة ATA وSATA وإرسال الأوامر وفرض المهل الزمنية. أثناء الإقلاع يطلب النواة من القرص معلومات أساسية، منها سعته. وإذا لم يستجب القرص، ينتظر CAM ويعيد المحاولة، ثم يعلن أن الجهاز غير جاهز. في هذا النظام ظهرت المهلة بصيغة 31000ms.

المهم أن العطل كان تحت طبقة OPNsense. لم تكن برمجيات جدار الحماية تالفة؛ لكن FreeBSD لم تعد قادرة على التواصل مع وحدة التخزين بشكل موثوق. ولأن عملية الإقلاع تعتمد على ذلك الجهاز، لم يستطع النظام المتابعة، ولم ينتقل البرنامج الثابت بنجاح إلى وسيط إقلاع آخر ما دام قرص الحالة الصلبة غير المستجيب متصلاً.

أين يأتي دور TRIM

تحتاج أقراص الحالة الصلبة إلى معرفة الكتل التي لم تعد مستخدمة. وTRIM هو أمر ATA يخبر القرص بأنه يمكنه مسح تلك الكتل في الخلفية. يستطيع نظام الملفات في OPNsense، سواء كان ZFS أو UFS، إرسال TRIM عندما يكون هذا الخيار مفعلاً.

تختلف وحدات التحكم في أقراص الحالة الصلبة منخفضة التكلفة في مدى قدرتها على التعامل مع TRIM وأوامر ATA ذات الصلة، خصوصاً حول حالات الطاقة. في هذه الحالة تشير الأدلة إلى مهلة على مستوى CAM: توقف القرص عن الاستجابة، ولم يتمكن FreeBSD من استعادته. من المرجح أن TRIM كان عاملاً مساهماً أو محفزاً، وليس سبباً جذرياً مثبتاً من هذه الحادثة وحدها. القرص نفسه كان المكوّن المعطّل؛ أما تفاعل CAM مع TRIM فيشرح طريقة ظهور العطل.

ولهذا أيضاً لم يكن الحل المعتاد بإعادة تثبيت نظام التشغيل مجدياً. فبرنامج التثبيت لم يستطع استخدام القرص بشكل موثوق. كانت الإزالة الفيزيائية أول خطوة في الاستعادة.

الاستعادة خطوة بخطوة

1. أزلنا قرص Lexar NS100. فالنظام لم يكن يقلع من وسائط أخرى ما دام القرص متصلاً.
2. أقلعنا مثبّت OPNsense بواجهة VGA من بطاقة microSD.
3. استخدمنا قرص USB 3 Gen2 كهدف للتثبيت، وقرص USB 2 منفصلاً للنسخة الاحتياطية من الإعدادات (conf/config.xml).
4. سجّلنا الدخول إلى المثبّت باسم installer وكلمة المرور الافتراضية opnsense.
5. اخترنا الإعدادات السابقة أثناء التثبيت واستوردناها.
6. أكملنا التثبيت على قرص USB ثم أعدنا التشغيل.
7. تأكدنا من إمكانية الوصول إلى النظام بالإعدادات المستعادة. ظهرت جميع الإضافات المثبتة سابقاً على أنها مفقودة.
8. رفضت الواجهة الرسومية تثبيت الإضافات المفقودة حتى يتم تحديث البرنامج الثابت. أجلنا التحديث لأن اختباراً سابقاً على صورة nano انتهى بخطأ importer بعد التحديث.
9. ثبّتنا الإضافات المفقودة من سطر الأوامر باستخدام pkg install، لتغطية أدوار البريد وDNS والوكيل العكسي والنسخ الاحتياطي والمراقبة وACME التي كان يؤديها جدار الحماية سابقاً.
10. أعدنا التشغيل. لم تبدأ جميع الخدمات تلقائياً بعد تثبيت الحزم، لكنها عملت بشكل طبيعي بعد إعادة تشغيل كاملة.
11. حدّثنا البرنامج الثابت عبر الواجهة الرسومية، وأعدنا التشغيل مرة أخرى، وتأكدنا من استقرار النظام.

لماذا منعت الواجهة تثبيت الإضافات

استعادة ملف config.xml قديم تعيد إعدادات الإضافات، لكنها لا تعيد حزم الإضافات نفسها. أرادت الواجهة الرسومية أن يكون النظام الأساسي على مستوى برنامج ثابت مطابق قبل تثبيتها. أما المسار عبر سطر الأوامر فقد تجاوز مشكلة الترتيب هذه. وبعد توفر الحزم وتحديث البرنامج الثابت، عاد النظام إلى حالة مدعومة.

خطأ importer السابق يستحق الذكر هنا. فهو سبب عدم قيامنا بتحديث البرنامج الثابت أولاً ومجرد الأمل في نجاح العملية. في جدار حماية إنتاجي، ترتيب الاستعادة مهم: أعد الخدمة، وتحقق منها، ثم نفّذ التغيير التالي.

ما نوصي به لأي نشر لـ OPNsense

• اختبر الاستعادة، لا النسخة الاحتياطية فقط. وجود config.xml على قرص USB جيد، لكن استعادة قمت بها فعلاً أفضل.
• افصل وسائط الإقلاع عن النظام. كان مثبّت microSD الفرق بين استعادة سريعة وانقطاع أطول بكثير.
• اختر التخزين بعناية لتوافقه مع FreeBSD. ليست كل أقراص الحالة الصلبة SATA منخفضة التكلفة متساوية في التعامل مع CAM. تحقق من الطراز المحدد قبل وضعه في جدار حماية.
• راقب SMART واستبدل الأقراص المشبوهة مبكراً. القرص الذي يختفي تحت الحمل ليس قرصاً يصلح للإنتاج.
• تعامل مع تغييرات TRIM كحل مؤقت. على ZFS يمكن أن يساعد vfs.zfs.trim.enabled=0 في تشخيص المهلة أو تجنبها مع قرص مشكوك فيه، لكنه ليس إصلاحاً. أنت تقايض التنظيف في الخلفية بالأداء وطول العمر، ولا يزال لديك قرص مشبوه.
• لا تترك تخزين USB كجهاز إقلاع دائم. أعاد جدار الحماية إلى العمل، لكن التخزين الداخلي هو المكان الصحيح على المدى الطويل.
• جرّب تحديثات البرنامج الثابت على مراحل. اختبرها على صورة غير إنتاجية عندما تستطيع، واحتفظ بنسخة إعدادات حديثة قبل كل تحديث.

الخلاصة

قد يبدأ انقطاع جدار الحماية بأمر بسيط مثل قرص يتوقف عن الاستجابة لأمر ATA واحد. في هذه الحالة كان التشخيص مهلة CAM في FreeBSD بعد 31 ثانية، وكان المحفز متسقاً مع معاناة قرص الحالة الصلبة منخفض التكلفة مع TRIM أو أمر ذي صلة، واعتمدت الاستعادة على أمرين: إزالة القرص المعطّل، وتوفر نسخة إعدادات قابلة للاستخدام.

إذا لم يكن جدار الحماية لديك قد اختبر مسار الاستعادة من قبل، فهذه هي مهمة الصيانة التالية التي تستحق التنفيذ.

هل تحتاج إلى مراجعة خطة استعادة جدار الحماية لديك؟ تواصل معنا أو اطّلع على خدمات تقنية المعلومات.