الارتباك المروّع لمصفوفة الأقراص

الارتباك المروّع لمصفوفة الأقراص، أو DAC، مصطلح يُطلق على مجموعة من أنواع إخفاقات مصفوفة RAID التي يستحيل تشخيصها فعلياً، وتتشابه في كون الجهاز لا يعاني فيها من أي فشل في الأقراص بالتزامن مع فشل كامل للمصفوفة ينتج عنه فقدان تام للبيانات. ويُفترض أن ثلاثة أسباب رئيسية تؤدي إلى غالبية حالات DAC:

أخطاء البرمجيات أو البرامج الثابتة: بينما تكون الأخطاء الجسيمة في سلوك RAID نادرة اليوم، فإنها ممكنة دائماً، لا سيما مع أنواع المصفوفات الأكثر تعقيداً كـ RAID التكافلي حيث يجب إجراء حسابات إعادة البناء على المصفوفة. يمكن أن يظهر خطأ في برنامج أو برنامج ثابت لـ RAID (بحسب ما إذا كنا نتحدث عن RAID برمجي أو صلب) بطرق عديدة بما في ذلك الإتلاف غير المقصود للمصفوفة. يمكن أن تحدث مشكلات البرنامج الثابت في الأقراص ذاتها أيضاً.

فشل الأجهزة: يمكن أن يكون لفشل الأجهزة كالمعالجات والذاكرة ووحدات التحكم آثار جسيمة على مصفوفة RAID. يمكن أن تؤدي أخطاء الذاكرة بسهولة إلى فقدان المصفوفة كلياً. يُعتقد أن هذا هو الأقل شيوعاً بين أسباب DAC.

اهتزاز الأقراص: في هذا السيناريو تهتز الأقراص الفردية وتنفصل عن اللوحة الخلفية ثم تعود إلى مكانها باهتزاز مجدد مما يطلق حدث إعادة البناء. لو حدث هذا مع أقراص متعددة خلال دورة إعادة بناء أو لو صُودِف خطأ قراءة غير قابل للاسترداد (URE) خلال إعادة البناء، فسنشهد فقداناً تاماً للمصفوفة التكافلية حتى دون وقوع أي فشل في الأجهزة.

نظراً لطبيعة DAC ولأنها ليست مشكلة في RAID نفسه بل في المكونات الداعمة له، نجد أنفسنا في موقف بالغ الصعوبة في محاولة تحديد المخاطر أو قياسها. لا يعرف أحد احتمال وقوع DAC، وبينما نعلم أن DAC يشكل تهديداً أكبر على أنظمة RAID التكافلي، لا نعرف بأي مقدار. تشير الأدلة الظرفية إلى أن الخطر على RAID المعكوس (المرايا) منخفض لدرجة لا يمكن قياسها، وقد يرتفع على RAID التكافلي لدرجة تتجاوز مستوى الضوضاء الخلفية في تحليل المخاطر. من بين أسباب الفشل، تُشكّل أخطاء البرمجيات واهتزاز الأقراص خطراً أعلى بكثير على الأنظمة العاملة بـ RAID التكافلي لأن خطر URE لا يؤثر إلا على المصفوفات التكافلية كما أن البرمجيات اللازمة للتكافل أكثر تعقيداً بكثير من تلك المطلوبة للمرايا. ببساطة RAID التكافلي أكثر هشاشة ويحمل أنواعاً أكثر من المخاطر مما يعرضه لـ DAC بطرق أكثر مما هو عليه الحال في RAID المعكوس.

بما أن DAC يشمل عدة احتمالات وبما أنه يستحيل فعلياً تحديد هويته بعد وقوعه، فلا توجد وسيلة ممكنة تقريباً لجمع أي بيانات عنه. منذ تحديد DAC كمخاطرة تقدم كثيرون، بصورة رئيسية في مجتمع Spiceworks، لتقديم شهادات ظرفية مباشرة عن إخفاقات مصفوفات بسبب DAC. طبيعة تقنية المعلومات لدى المستخدمين النهائيين تعني أن الإحصاءات، لا سيما على مفاهيم ضبابية كـ DAC التي لا تُعرف على نطاق واسع، لا تُجمع ولا يمكن جمعها. يحدث DAC في أماكن عمل حول العالم حيث يعود مسؤول النظام إلى مكتبه ليجد خادماً فقدت بياناته كلياً دون أن يكون أي جهاز قد تعطل. البيانات ضاعت بالفعل. لن تُجرى تشخيصات على الأرجح، ولن تكون هناك سجلات، وحتى لو أمكن تحديد المشكلة فإلى من سيُبلَّغ عنها؟ وحتى لو أُبلغ عنها، كيف نحدد كمياً كم مرة يحدث مقابل كم مرة لا يحدث أو كم مرة يمكن أن يحدث دون أن يُبلَّغ عنه؟ لا أعرف للأسف سوى أنه بعد تحديد المخاطرة وإشهار أعراضها إلى حد ما، تقدم فجأة كثير من الناس معترفين بأنهم شهدوا DAC مباشرةً دون أن يعرفوا ماذا حدث.

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

نضطر بحكم طبيعة الصناعة إلى قبول DAC كمخاطرة محتملة وإدراجه كمخاطرة “ثانوية” مجهولة القدر في تقييمات المخاطر والاستعداد له دون أن نستطيع احتساب قيمة حسابية له. لكن معرفة أنه قد يكون مخاطرة وفهم لماذا يمكن أن يحدث أمران مهمان في تقييم المخاطر وإجراءات التخفيف منها.

[تشير الأدلة الظرفية إلى أن DAC يقتصر تقريباً دائماً على تطبيقات RAID الصلبة لمصفوفات RAID ذات التكافل الأحادي على وحدات تحكم SCSI.]