أقراص نظام التشغيل البطيئة وأقراص البيانات السريعة

على مر السنين وجدت أن الناس كثيراً ما يميلون نحو تخزين البيانات عالي الأداء وعالي الموثوقية لقسم نظام التشغيل، لكنهم يختارون تخزيناً بطيئاً و“فعّالاً من حيث التكلفة” لمخازن البيانات الحيوية. ويدهشني مدى تكرار حدوث ذلك، والآن مع ظهور المشعّلات الافتراضية (Hypervisors) أرى السلوك ذاته يتكرر هناك أيضاً، مما يُضاعف المشكلات القائمة سابقاً.

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

في حالات كثيرة، سواء في محاولة تصميم أداء أو موثوقية أعلى أو بسبب ضرورة تقنية، أجد أن الناس يفصلون مصفوفات التخزين ويضعون المشعّلات الافتراضية وأنظمة التشغيل على مصفوفة وبيانات على أخرى. لكن ما يصدمني هو أن المصفوفات المخصصة للمشعّل الافتراضي أو نظام التشغيل كثيراً ما تكون ضخمة جداً في السعة وعالية للغاية في الأداء، كثيراً ما تتضمن أقراصاً دوارة بسرعة 15,000 دورة في الدقيقة أو حتى محركات أقراص صلبة بتكلفة باهظة. وغالباً في تهيئة RAID 1 (وفقاً للمعايير الشائعة من عام 1998.)

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

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

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

حتى التخزين البطيء يكون في الغالب أسرع بأضعاف مضاعفة مما هو ضروري لأنشطة تسجيل النظام. وفي تلك الحالات النادرة التي يكون فيها التسجيل مكثفاً جداً لدينا خيارات عديدة للتعامل مع هذه المشكلة. الحل الأكثر وضوحاً وشيوعاً هو إرسال السجلات إلى مصفوفة أقراص غير المستخدمة من قبل نظام التشغيل أو المشعّل الافتراضي. وهذا حل سهل جداً ومفيد عملياً في الحالات التي يستوجبه الأمر. الحل الآخر الشائع والمفيد للغاية هو ببساطة الامتناع عن الاحتفاظ بالسجلات على الجهاز المحلي وإرسالها إلى أداة تجميع السجلات عن بُعد كـ Splunk أو Loggly أو ELK.

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

هذا لا يعني أن ملفات نظام هذه الأنظمة لا ينبغي نسخها احتياطياً، ينبغي ذلك بالطبع (في معظم الحالات). لكن في حال فشلت النسخ الاحتياطية أيضاً، نادراً ما يُشكّل فقدان قسم نظام التشغيل أو نظام الملفات كارثة، بل مجرد إزعاج. ثمة طرق للتعافي في تقريباً جميع الحالات دون الوصول إلى البيانات الأصلية، طالما أن نظام ملفات “البيانات” منفصل. ونظراً لطبيعة أنظمة التشغيل والمشعّلات الافتراضية حيث التغيير نادر، يمكن أن تكون النسخ الاحتياطية أقل تكراراً، ربما مُشغَّلة يدوياً فقط عند تطبيق التحديثات!

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

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

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

حين يتعين فصل نظام التشغيل أو المشعّل الافتراضي عن المصفوفات التي تحتوي على البيانات، وهو ما قد يحدث لأسباب عديدة، نسعى عموماً إلى الحصول على موثوقية معقولة بتكلفة منخفضة. وعند استخدام التخزين التقليدي (الأقراص المحلية) يعني هذا استخدام أقراص دوارة صغيرة وبطيئة ومنخفضة التكلفة لتخزين نظام التشغيل، في الغالب في تهيئة RAID 1 البسيطة. مثال من الواقع العملي هو استخدام أقراص SATA “صديقة للبيئة” بسرعة 5400 دورة في الدقيقة بأصغر أحجام ممكنة. تستهلك هذه الأقراص طاقة قليلة وتكلفة اقتنائها منخفضة جداً. وتُتجنب محركات SSD ومحركات SAS عالية السرعة لأنها تُكلّف علاوة مقابل حماية غير ذات صلة وأداء يُهدر بالكامل.

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

أخيراً، والأكثر أهمية، تتمثل القاعدة العامة المتبعة مع المشعّلات الافتراضية في تثبيتها على بطاقات SD أو محركات أقراص USB بدلاً من التخزين التقليدي نظراً لكون احتياجاتها في الأداء والموثوقية أقل بكثير حتى من أنظمة التشغيل التقليدية. فعادةً لو تعطّل قرص من هذا النوع أثناء تشغيل النظام، سيظل النظام يعمل دون أي مشكلة إذ لا يُستخدم القرص أبداً بعد إقلاع النظام في البداية. ولن تظهر مشكلة إلا عند إعادة التشغيل حيث يمكن في تلك الحالة استخدام جهاز إقلاع احتياطي كبطاقة SD ثانية أو عصا USB. وهذه هي التوصية الرسمية لـ VMware vSphere، وكثيراً ما يوصي بها ممثلو Microsoft لـ HyperV وهي مدعومة رسمياً من قِبَل موردي OEM لـ HyperV، وكثيراً ما يُوصى بها وإن كانت غير مدعومة على نطاق واسع لأنظمة Xen وXenServer وKVM. واستخدام بطاقات SD أو محركات USB لتخزين المشعّل الافتراضي يحوّل خادم الافتراضية فعلياً إلى نظام مدمج. وبينما قد يبدو هذا غير مألوف لمديري الأنظمة المعتادين على التفكير في الأقراص التقليدية بوصفها ضرورة للخوادم، فمن المهم تذكر أن الأنظمة المؤسسية الحيوية عالية الأهمية كأجهزة التوجيه والمحولات تدوم عقوداً وتستخدم هذه الاستراتيجية ذاتها لهذه الأسباب ذاتها.

الاستراتيجية الشائعة للمشعّلات الافتراضية في هذا النمط المدمج مع بطاقات SD أو محركات USB هي امتلاك جهازَين من هذا القبيل، قد يكون أحدهما بطاقة SD والآخر محرك USB، كل منهما يحتوي على نسخة من المشعّل الافتراضي. فإذا تعطّل أحد الجهازين، يكون الإقلاع إلى الجهاز الثاني فعّالاً تقريباً مثل نظام RAID 1 التقليدي. لكن على خلاف معظم إعدادات RAID 1 التقليدية، لدينا أيضاً وسيلة سهلة نسبياً لاختبار تحديثات النظام بتحديث جهاز إقلاع واحد فقط في المرة الواحدة واختبار العملية قبل تحديث جهاز الإقلاع الثاني، مما يمنحنا خياراً احتياطياً موثوقاً ومختبراً جيداً في حال سارت عملية تحديث الإصدار بشكل خاطئ. وهذه العملية كانت في الواقع شائعة في أنظمة UNIX RISC الكبيرة حيث كانت أجهزة الإقلاع في الغالب مجموعات RAID 1 برمجية محلية تدعم ممارسة مماثلة، وكانت شائعة بشكل خاص في أوساط AIX وSolaris.

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

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

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