عندما يكون غياب التكرار أكثر موثوقية – أسطورة التكرار
المخاطرة مفهوم عسير يستلزم قدراً كبيراً من التدريب والتفكير والتحليل لتقييم السيناريوهات المعطاة بشكل صحيح. كثيراً ما نستبدل تحليل المخاطر بإضافة التكرار الأساسي والافتراض بأننا قللنا المخاطر بشكل مناسب. لكن في أحيان كثيرة لا يكون الأمر كذلك. إن إدخال التعقيد أو أوضاع فشل إضافية يرافق في الغالب إضافة التكرار، وقد تضيف هذه الأشكال الجديدة من الفشل مخاطر أكبر مما يزيله التكرار المضاف. أنظمة التخزين معرّضة بشكل خاص لعمليات اتخاذ القرار هذه وهو أمر مؤسف لأن أنظمة التخزين من بين القليلة أو ربما الوحيدة المعرّضة للفشل بشكل بالغ والأشد أهمية للحماية.
RAID مثال رائع على المكان الذي يمكن أن يُفضي فيه غياب التفكير الشامل في المخاطر إلى بعض قرارات غير موفقة. إذا نظرنا إلى سيناريو غير نادر سنرى أين يمكن أن يؤدي هدف الحماية من فشل المحرك فعلياً إلى زيادة في المخاطر حتى عند تطبيق تكرار إضافي. في هذا السيناريو سنقارن مصفوفة من اثني عشر محركاً تضم اثني عشر محرك SATA بسعة ثلاثة تيرابايت في مصفوفة واحدة. ليس من النادر سماع الناس يختارون RAID 5 لهذا السيناريو للحصول على “أقصى سعة وأداء” مع “حماية كافية من الفشل”.
الفكرة هنا هي أن RAID 5 يحمي من فقدان محرك واحد يمكن استبداله وستُعيد المصفوفة بناء نفسها قبل فشل محرك ثانٍ. هذا رائع نظرياً، لكن المخاطر الحقيقية لمصفوفة بهذا الحجم – ستة وثلاثون تيرابايت من سعة المحركات – لا تأتي كما يظن الناس عموماً من فشل محركات متعددة، بل من استحالة إعادة بناء المصفوفة بشكل موثوق بعد فشل محرك واحد أو من فشل المصفوفة ذاتها دون فشل أي محرك منفرد. مخاطرة فشل محرك ثانٍ منخفضة لا معدومة ولكن منخفضة جداً. المحركات اليوم موثوقة للغاية. حين يفشل محرك واحد يرتفع احتمال فشل محرك ثانٍ وهذا موثق جيداً، لكنني لا أريد لهذه المخاطرة أن تُضلّلنا عن النظر في المخاطر الحقيقية – مخاطرة فشل عملية إعادة البناء.
ما يُرعبنا أثناء عملية إعادة بناء RAID 5 هو إمكانية حدوث خطأ قراءة غير قابل للاسترداد (URE). حين يحدث تتوقف عملية إعادة البناء وتُترك المصفوفة في حالة عديمة الفائدة – تُفقد جميع البيانات على المصفوفة. على محركات SATA الشائعة معدل URE هو 10^14 أي مرة كل اثني عشر تيرابايت من عمليات القراءة. هذا يعني أن مصفوفة بسعة ستة تيرابايت تُعاد بناؤها لديها احتمال يبلغ خمسين بالمئة تقريباً لضربها بـURE والفشل. احتمال خمسين بالمئة للفشل مرتفع بشكل مجنون. تخيل لو أن سيارتك كان فيها احتمال خمسين بالمئة لسقوط عجلاتها في كل مرة تقودها. إذن مع مصفوفة RAID 5 صغيرة (بمعايير اليوم) بسعة ستة تيرابايت باستخدام محركات SATA ذات معدل URE 10^14، لو فقدنا محركاً واحداً لدينا فقط احتمال خمسين بالمئة لاسترداد المصفوفة بافتراض استبدال المحرك فوراً. هذا لا يشمل مخاطرة فشل محرك ثانٍ، فقط مخاطرة فشل URE. كما يفترض أن المحرك خامل تماماً بخلاف عملية إعادة البناء. إذا كانت المحركات مشغولة بمهام أخرى في الوقت ذاته فإن احتمالات حدوث شيء سيء سواء URE أو فشل محرك ثانٍ تبدأ في الارتفاع بشكل كبير.
مع مصفوفة بسعة اثني عشر تيرابايت تبدأ احتمالات الفقدان الكامل للبيانات خلال عملية إعادة البناء في الاقتراب من مئة بالمئة – مما يعني أن RAID 5 لا يؤدي وظيفة على الإطلاق في ذلك الحال. دائماً ثمة فرصة للنجاة لكنها ضئيلة جداً. عند ست تيرابايت يمكنك مقارنة عملية إعادة البناء بلعبة روليت روسية برصاصة واحدة وست غرف وعليك سحب الزناد ثلاث مرات. عند اثني عشر تيرابايت عليك سحبه ست مرات! تلك ليست احتمالات جيدة.
لكننا لسنا نتحدث عن مصفوفة بسعة اثني عشر تيرابايت. نتحدث عن مصفوفة بسعة ستة وثلاثين تيرابايت – التي تبدو كبيرة لكن هذا حجم يمكن لشخص ما امتلاكه بسهولة في المنزل اليوم ناهيك عن في عمل تجاري. كل شركة خوادم كبرى فضلاً عن تقريباً جميع موردي التخزين منخفض التكلفة يصنعون أنظمة تخزين بأقل من 10,000 دولار في هذا النطاق من السعة اليوم. إعادة بناء مصفوفة RAID 5 مع فشل محرك واحد في مصفوفة بستة وثلاثين تيرابايت يشبه لعب الروليت الروسية برصاصة واحدة وست غرف وسحب الزناد ثماني عشرة مرة! بياناتك لا تملك حظاً يُذكر. أضف إلى ذلك الكم الهائل من الوقت المطلوب لإعادة بناء مصفوفة بهذا الحجم ويبدأ خطر فشل قرص ثانٍ أثناء نافذة إعادة البناء في أن يصبح تهديداً ملموساً. رأيت تقديرات لأوقات إعادة البناء تصل إلى أسابيع أو أشهر في بعض الأنظمة. هذا وقت طويل للعمل دون القدرة على خسارة محرك آخر. حين نتحدث عن ساعات أو أيام فالمخاطر منخفضة نسبياً لكن موجودة. حين نتحدث عن أسابيع أو أشهر من الاستنزاف المستمر – إذ إن عمليات إعادة البناء مكثفة للغاية على المحركات – ترتفع معدلات الفشل بشكل حاد.
مع مصفوفة بهذا الحجم يمكننا بشكل فعّال افتراض أن فقدان محرك واحد يعني فقدان المصفوفة الكاملة مما يتركنا دون أي حماية من فشل المحركات. الآن لو نظرنا إلى مصفوفة بأداء مساوٍ أو أفضل وسعة مساوية أو أفضل في ظل RAID 0 الذي لا يملك أي حماية من فقدان المحركات، فنحن نحتاج فقط إلى أحد عشر من المحركات ذاتها التي نحتاج إليها اثني عشر منها لمصفوفة RAID 5. ما يعنيه هذا هو أنه بدلاً من اثني عشر محرك أقراص صلبة كل منها معرّض لاحتمال فشل سنوي يبلغ نحو ثلاثة بالمئة لدينا أحد عشر محركاً فقط. هذا وحده يجعل مصفوفة RAID 0 أكثر موثوقية إذ يوجد عدد أقل من المحركات القابلة للفشل. ليس فقط لدينا محركات أقل بل لا حاجة لكتابة كتلة التكافؤ ولا لتجاوز كتل التكافؤ عند القراءة مما يخفف قليلاً من التآكل الميكانيكي لمصفوفة RAID 0 للاستخدام ذاته مما يمنحها ميزة موثوقية إضافية طفيفة. ستكون مصفوفة RAID 0 من أحد عشر محركاً مطابقة في السعة لمصفوفة RAID 5 من اثني عشر محركاً لكن بإنتاجية وزمن استجابة أفضل قليلاً. فوز على كل الصعد. بالإضافة إلى توفير تكلفة المحرك الإضافي.
ما نراه إذن هو أنه في المصفوفات الكبيرة (كبيرة في السعة لا في عدد الأقراص) يتجاوز RAID 0 فعلياً RAID 5 في سيناريوهات معينة. عند استخدام محركات SATA الشائعة يحدث هذا عند سعات يختبرها حتى مستخدمو الطاقة في المنزل والشركات الصغيرة كثيرة. إذا انتقلنا إلى محركات SATA المؤسسية أو محركات SAS فإن رقم السعة الذي يحدث عنده هذا يصبح مرتفعاً جداً وليس مصدر قلق اليوم لكنه سيكون كذلك في غضون سنوات قليلة عندما تزداد سعات المحركات. لكن هذا يسلط الضوء على مدى خطورة RAID 5 في الأحجام التي نراها اليوم. يفهم الجميع المخاطر الهائلة لـ RAID 0 لكن قد يكون من الصعب استيعاب أن مشاكل RAID 5 بالغة لدرجة أنه قد يكون فعلاً أقل موثوقية من RAID 0.
أن RAID 5 قد يكون أقل موثوقية من RAID 0 في مصفوفة بهذا الحجم استناداً إلى عمليات إعادة البناء وحدها ليس إلا البداية. في مصفوفة ضخمة كهذه يمكن أن يستغرق وقت إعادة البناء وقتاً طويلاً جداً ويُحدث ضرراً شديداً على المحركات لدرجة يبدأ فيها فشل المحرك الثاني في أن يصبح مخاطرةً قابلة للقياس. ثم هناك مخاطر إضافية ناجمة عن أخطاء وحدة تحكم المصفوفة التي قد تستخدم خوارزميات إعادة البناء لتدمير مصفوفة بأكملها حتى دون فشل أي محرك. نظراً لأن RAID 0 (أو RAID 1 أو RAID 10) لا تمتلك خوارزميات إعادة بناء فهي لا تعاني من هذه المخاطرة الإضافية. هذه مخاطر يصعب تحديدها كمياً لكن المهم هو أنها مخاطر إضافية تتراكم عند استخدام نظام أكثر تعقيداً بينما كان نظام أبسط دون التكرار أكثر موثوقية منذ البداية.
الآن بعد أن أثبتنا أن RAID 5 قد يكون أقل موثوقية من RAID 0 سأشير إلى المخاطر الواضحة لـ RAID 0. يُستخدم RAID بشكل عام للتخفيف من مخاطرة فشل محرك صلب واحد منفرد. كلنا نخشى فشل محرك واحد وفقدان كل البيانات. RAID 0 بوصفه شريطاً كبيراً من المحركات دون أي شكل من التكرار يأخذ مخاطرة فقدان البيانات من فشل محرك واحد ويضاعفها عبر عدد من المحركات حيث يتسبب فشل أي محرك في الفقدان الكلي للبيانات على جميع المحركات. في مثالنا بأحد عشر قرصاً إذا فشل أي من الأحد عشر قرصاً يُفقد كل شيء. من الواضح أن هذا أشد خطورة بكثير من مجرد استخدام محرك واحد منفرد.
ما أحاول إثباته هنا هو أن التكرار لا يعني الموثوقية. مجرد كون شيء مكرراً كـ RAID 5 لا يضمن أنه سيكون دائماً أكثر موثوقية من شيء غير مكرر.
قياسي المفضّل هنا هو النظر إلى المنازل في مواجهة إعصار. في سيناريو واحد نبني منزلاً من الطوب والملاط. في السيناريو الثاني نبني منزلين مكررَين كل منهما من القش (بناتنا خنازير على ما يبدو). حين يأتي الإعصار (أو الذئب الشرير) أيهما أرجح أن يترك لنا منزلاً صامداً؟ بوضوح منزل الطوب الواحد له مزايا موثوقية كبيرة على منزلَي القش المكررَين. التكرار لم يهم، الموثوقية كانت ما يهم في النهاية.
التكرار مضلل في أحيان كثيرة لأنه سهل التحديد الكمي لكنه عسير التحديد النوعي. التكرار سؤال أبيض أو أسود: هل هو مكرر؟ نعم أو لا. بسيط. الموثوقية ليست بهذه البساطة. الموثوقية تتعلق بمعدلات الفشل والاحتمالات. تتعلق بالإحصاء والتحليل. وبما أنه من الصعب تحديد الموثوقية كمياً بطريقة ذات معنى لا سيما عند تقديم مشروع لرجال الأعمال كثيراً ما يصبح التكرار بديلاً بسيطاً لهذا المفهوم المعقد.
ينتهي مفهوم استخدام التكرار لصرف الأسئلة عن الموثوقية بالانطباق على الأنظمة الفرعية بطرق متشعبة للغاية. بدلاً من جعل “النظام” مكرراً أصبح من الشائع جعل نظام فرعي موثوق للغاية ومنخفض التكلفة مكرراً ثم التعامل مع تكرار النظام الفرعي باعتباره ينطبق على النظام كله. المثال الأكثر شيوعاً على ذلك هو وحدات تحكم RAID في منتجات SAN. بدلاً من امتلاك SAN مكرر (بمعنى SAN-ين) كثيراً ما يجعل الصانعون ذلك المكون الواحد غير المكرر عادةً في الخوادم الاعتيادية مكرراً ثم يسمون SAN ذا تكرار – أي SAN يحتوي على تكرار وهذا ليس الشيء ذاته أبداً.
قياس جيد هنا هو مقارنة امتلاك سيارتين مكررتين بمعنى سيارتين كاملتين تعملان وامتلاك سيارة واحدة مع مضخة ماء احتياطية في الصندوق في حال فشلت المضخة الرئيسية. من الواضح أن مضخة ماء احتياطية ليست شيئاً سيئاً. لكنها أيضاً قدر ضئيل جداً من الحماية ضد فشل السيارة مقارنةً بامتلاك سيارة ثانية جاهزة. في حالة واحدة النظام كله مكرر بما في ذلك الهيكل. في الحالة الأخرى نجعل مكوناً واحداً فقط عالي الموثوقية مكرراً داخل الهيكل. وهذا لا يرقى حتى إلى مستوى امتلاك إطار احتياطي الذي هو على الأقل مكوّن سيارة ذو احتمال فشل أعلى.
تماماً كأسطورة موثوقية RAID 5 وموثوقية النظام والنظام الفرعي كثيراً ما تُعامَل تقنيات التخزين المشترك كـ SAN وNAS بالطريقة ذاتها لا سيما فيما يخص المحاكاة الافتراضية. يوجد سيناريو شائع حيث يُجرى مشروع للمحاكاة الافتراضية ويشعر الناس بالذعر غريزياً لأن مضيف محاكاة افتراضية واحداً يُمثِّل نقطة فشل واحدة حيث إذا فشل تفشل أنظمة كثيرة معاً دفعةً واحدة.
استخدام مصطلح “نقطة فشل واحدة” يثير شعوراً بالذعر وهو وسيلة رائعة لتوجيه المحادثة. لكن SPOF كما نحب تسميته، وإن كنا نحب إزالته متى أمكن، قد لا يكون نهاية العالم. فكّر في منزلنا من الطوب. إنه SPOF. منزلانا من القش ليسا كذلك. ومع ذلك تُسقط نسمة هواء واحدة حلولنا المكررة أسرع من حلنا الموثوق ذي النقطة الواحدة. البحث عن SPOFs طريقة رائعة للعثور على نقاط الهشاشة في نظام ما، لكن لا تشعر بأن كل SPOF يجب جعله مكرراً في كل سيناريو. معظم الشركات ستجد قيمتها الأكبر مع SPOFs كثيرة في مكانها. هدفنا الحقيقي هو الموثوقية بتكلفة مناسبة، والتكرار كما رأينا ليس بديلاً عن الموثوقية بل هو مجرد أداة يمكننا استخدامها لتحقيق الموثوقية.
النظرية التي يتبعها كثيرون عند المحاكاة الافتراضية هي أنهم يأخذون مضيف المحاكاة الافتراضية ويقولون “هذا المضيف SPOF لذا أحتاج إلى اثنين منهما واستخدام ميزات التوافر العالي للسماح بالتحول الفوري الشفاف!” هذا مدفوع بجعل بائع المحاكاة الافتراضية الرائد أمواله أولاً ببيع منتجات إضافية مكلفة للتوافر العالي وثانياً بامتلاكه من قِبل شركة تخزين كبرى – لذا فإن بيع تخزين مشترك غير ضروري أو حتى خطير يُعدّ ربحاً مالياً كبيراً لهم وقد يكون بسهولة السبب وراء أنهم تصدّروا مجال المحاكاة الافتراضية منذ البداية. مضيفو المحاكاة الافتراضية المكررون مع التخزين المشترك يبدو رائعاً لكن يمكن أن يكون توجيهاً خاطئاً بشكل صارخ لعدة أسباب.
السبب الأول هو أن إزالة SPOF الأولي أي مضيف المحاكاة الافتراضية يُستبدَل بـ SPOF جديد هو التخزين المشترك. هذا لا يُنجز شيئاً. بافتراض أننا نستخدم خوادم وتخزين مشترك بجودة مقارنة كل ما فعلناه هو تحريك مكان المخاطرة لا تغيير حجمها. احتمالية فشل نظام التخزين مماثلة تقريباً لاحتمالية فشل الخادم الأصلي. لكن بالإضافة إلى قلب SPOF مثل لعبة قشرة البيضة فعلنا أيضاً شيئاً أسوأ بكثير بكثير – أدخلنا تبعيات فشل متسلسلة أو متتالية.
في سيناريونا الأصلي كان لدينا خادم واحد. إذا ظل الخادم يعمل فنحن بخير، إذا فشل لم نكن كذلك. بسيط. الآن لدينا مضيفا محاكاة افتراضية وخادم تخزين واحد (SAN أو NAS أو غيره) وشبكة تصلهما معاً. لقد حددنا بالفعل أن مخاطرة فشل التخزين المشترك مساوية تقريباً لإجمالي مخاطرة النظام في السيناريو الأصلي. لكن الآن لدينا التبعيات الإضافية للشبكة وعقدتي المحاكاة الافتراضية الأمامية. كل من هذه المكونات أكثر موثوقية من التخزين المشترك الهش (أي شيء يحتوي محركات ميكانيكية سيكون هشاً) لكن كونها أقل مخاطرة ليس هو القضية، القضية هي أن المخاطر تراكمية.
إذا فشل أي من هذه المكونات الثلاثة (التخزين أو الشبكة أو عقد الواجهة الأمامية) يفشل كل شيء. الحل لهذا هو جعل التخزين المشترك مكرراً من تلقاء نفسه وجعل الشبكة مكررة من تلقاء نفسها. بعمل كافٍ يمكننا التغلب على الهشاشة والمخاطرة التي أدخلناها بإضافة التخزين المشترك لكن التخزين المشترك في حد ذاته ليس شكلاً من أشكال التخفيف من المخاطر بل هو مخاطرة في حد ذاته يجب التخفيف منها. تبدأ دوامة التعقيد والتكلفة المرتبطة برفع هذا النظام الجديد إلى مستوى موثوقية نظام الخادم الواحد الأصلي يمكن أن تكون فلكية.
الآن بعد أن أصبح لدينا كل هذا التكرار لدينا مخاطرة واحدة أخرى نقلق بشأنها. إدارة كل هذا التكرار بكل هذه الأجزاء المتحركة تتطلب معرفة ومهارة وإعداداً أكثر بكثير مما تتطلبه إدارة خادم واحد بسيط. انتقلنا من حل بسيط إلى حل بالغ التعقيد. في تجربتي الأنيكدوتية المخاطر الحقيقية لحلول كهذه لا تأتي من فشل الأجهزة بل من الخطأ البشري. لم يُفعَل الكثير لتجنب تسبب الخطأ البشري في فشل هذا النظام الجديد بل أضفنا نقاطاً لا حصر لها حيث قد يُوقع الإنسان النظام كله بتكراره وكل شيء معه خطأً. رأيت ذلك بنفسي وسمعت قصص الرعب. كلما كان النظام أكثر تعقيداً كان أكثر احتمالاً أن يكسر الإنسان كل شيء عن طريق الخطأ.
من الأهمية بمكان أننا بوصفنا محترفين في تقنية المعلومات أن نتراجع خطوة وننظر إلى الأنظمة الكاملة ونأخذ في الاعتبار الموثوقية والمخاطرة ونفكر في التكرار ببساطة باعتباره أداةً نستخدمها في سعينا لتحقيق الموثوقية. التكرار في حد ذاته ليس علاجاً شاملاً. البساطة أيضاً ليست كذلك. الموثوقية مشكلة معقدة لمعالجتها. تجنب البدائل المبسِّطة هو خطوة أولى مهمة في الانتقال من التغطية على مشاكل الموثوقية إلى مواجهتها وحلها.
إعلان
