الملخص التنفيذي
صُممت تقنية RAID لعصر كانت فيه الأقراص صغيرة السعة، والقدرات التخزينية محدودة، وأحمال التخزين بسيطة نسبيًا. ومع تضخم أحجام البيانات، أصبحت الافتراضات التي بُنيت عليها RAID أقل توافقًا مع البنية التحتية الحديثة. فالسعات الكبيرة للأقراص تطيل عمليات إعادة البناء وتزيد احتمال التعرض لأعطال إضافية، بينما يمكن للتصميم القائم على مستوى الكتل (Block)، والاعتماد على وحدة تحكم RAID (RAID Controller) متخصصة، واختناقات وحدة التحكم (Controller)، والارتباط بمورّد محدد، ومحدودية المرونة أن تقيّد التوسع. كما أن RAID لا يقدم معالجة قوية لمشكلة تلف البيانات الصامت، ولا للتعقيد التشغيلي المصاحب لإدارة مصفوفات (Arrays) ضخمة. والنتيجة بنية تخزين تستهلك السعة والوقت وجهد الإدارة، بينما تركز جزءًا كبيرًا من المخاطر في العتاد.
النهج الحديث، مثل Xendure، ينبغي أن يتعامل مع التخزين باعتباره نظامًا قابلًا للتوسع يستوعب النمو المستمر للبيانات، ومساحات الأسماء (Namespaces) كبيرة، وحماية فعالة، ووصولًا مرنًا، وتشغيلًا مرن وقادر على تحمّل الأعطال (resilient) من دون الاعتماد على وحدة التحكم (Controller) واحدة أو مورّد واحد. وتوفر معماريات التخزين الموزعة مسارًا عمليًا لتحقيق ذلك، عبر توزيع البيانات والحماية بين العُقد (Nodes) وتحسين قابلية التوسع والإضافة.
مقدمه
يعود مفهوم RAID — أي مصفوفة زائدة من الأقراص منخفضة التكلفة (Redundant Array of Inexpensive Disks) — إلى نحو عام 1980. في ذلك الوقت كانت الأقراص التي نعرفها اليوم باسم أقراص المؤسسات (Enterprise Drives)، والتي توفر أداءً أعلى ومقاومة أفضل لفقدان البيانات، باهظة الثمن جدًا.
بدأ الباحثون تدريجيًا في تبني فكرة توزيع البيانات على عدد أكبر من الأقراص الأقل تكلفة لتحقيق أداء وموثوقية أعلى. وأصبحت هذه الفكرة أساس تقنية RAID، ثم أصبحت لسنوات طويلة أحد الأسس الرئيسية لصناعة التخزين عالميًا.
ورغم أن RAID ما يزال مكوّنًا أساسيًا في كثير من أنظمة التخزين، فإن التطور السريع في قطاع تقنية المعلومات والانفجار الهائل في حجم البيانات كشفا محدوديات هذه التقنية القديمة. وأصبحت هذه المحدوديات مصدر قلق كبير لمسؤولي تقنية المعلومات (IT)، ومصدرًا لتكاليف غير متوقعة في البنية التحتية، وفي بعض الحالات سببًا في فقدان كارثي للبيانات.
ما نقاط الضعف في تصميم RAID في عصر البيانات الضخمة؟
صُممت لعدد صغير من الأقراص
صُممت RAID في زمن كان فيه امتلاك خمسة أقراص صلبة، سعة كل منها 10 GB، أمرًا استثنائيًا. لذلك بُني نموذج الحماية حول أعداد صغيرة نسبيًا من الأقراص، وعلى افتراض فقدان قرص واحد أو قرصين فقط.
في RAID 5 يمكن تحمّل فقدان قرص واحد من مصفوفة (Array)، بينما يمكن لـRAID 6 تحمّل فقدان قرصين مع بقاء البيانات متاحة. عمليًا، غالبًا ما يتم إبقاء مصفوفة (Array) دون نحو 10 أقراص، لأن زيادة عدد الأقراص ترفع احتمال حدوث أكثر من العطل أو العطلين اللذين يستطيع نظام الحماية تحملهما، ما قد يؤدي في النهاية إلى فقدان كامل للبيانات. وحتى في مصفوفات (Arrays) الصغيرة، لا توجد ضمانة بأن قرصين أو ثلاثة أقراص لن تتعطل في الفترة الزمنية نفسها. كما أن الأقراص الموجودة في مصفوفة (Array) واحدة تبدأ العمل غالبًا في الوقت نفسه، وهو ما قد يزيد احتمال حدوث أعطال مترابطة.
قد يكون هذا الأسلوب مقبولًا في بيئة صغيرة تضم 30 أو 40 قرصًا، لكنه يصبح غير عملي مع زيادة عدد الأقراص. فمثلًا، في بيئة تضم 1,000 قرص، لم يعد من العملي تقسيمها إلى مجموعات من عشرة أقراص وتخصيص قرصين من كل مجموعة للالتكرار الاحتياطي (Redundancy). كما يرتفع احتمال تعطل الأقراص كلما زاد عددها. وعندما نتحدث عن بيئات تضم ملايين الأقراص، مثل بنية Google التحتية، يصبح واضحًا أن RAID التقليدية لا يمكن أن تكون أساسًا مناسبًا لهذا الحجم.
صُممت لسعات تخزينية صغيرة
صُممت RAID في وقت كانت فيه سعة 10 GB تُعد سعة كبيرة للقرص الصلب. عند هذا المستوى، لم تكن إعادة بناء مصفوفة (Array) بعد تعطل قرص تستغرق وقتًا مفرطًا.
ومع النمو السريع في سعات الأقراص، وأصبحت أقراص 6 TB و8 TB شائعة، ازدادت أوقات الإصلاح وإعادة البناء بشكل كبير. وفي كثير من أنظمة RAID المعتمدة على التكافؤ (Parity)، مثل RAID 5، قد تستغرق إعادة البناء، عند ضبطها لأعلى أداء، 48 ساعة أو أكثر، مع انخفاض أداء نظام التخزين بنحو 50%. وقد تكون RAID 6 أكثر تحديًا.
ولأن هذا الانخفاض في الأداء غير مقبول غالبًا، تُشغّل عمليات إعادة البناء (Rebuild) عادةً في الخلفية لتقليل تأثيرها على أحمال العمل الإنتاجية (Production Workloads). لكن المقابل هو أن عملية إعادة البناء (Rebuild) قد تستغرق عدة أضعاف الوقت. وإذا تعطل قرص آخر خلال هذه الفترة، فقد تصبح مصفوفة (Array) بأكملها غير قابلة للاستعادة.
تشير التقديرات إلى أن Google كانت تستخدم بين 10 و15 إكسابايت من البيانات في عام 2026 (الإكسابايت الواحد يساوي مليون تيرابايت)، وهو حجم يقع أساسًا خارج افتراضات تصميم RAID التقليدية.
صُممت للوصول على مستوى الكتل (Block) فقط
تجمع RAID جميع الأقراص في مصفوفة (Array) واحدة وتعرضها لنظام التشغيل المتصل باعتبارها جهاز وصول على مستوى الكتل (Block-Level Access Device)، أو ببساطة قرصًا واحدًا كبيرًا. ثم يتم إنشاء LUNs (Logical Units) على هذا القرص، ويظهر كل LUN لنظام التشغيل كقرص منفصل.
لا تستطيع كثير من وحدات تحكم RAID (RAID Controllers) إنشاء LUNs أكبر من 32 أو 64 TB، ولذلك قد لا يرى نظام التشغيل قرصًا أكبر من هذه السعة. لا يمثل ذلك عادةً مشكلة عند التعامل مع قواعد البيانات أو خوادم البريد (Mail Servers)، لكنه يصبح مشكلة كبيرة عند التعامل مع مئات التيرابايت من أرشيفات الفيديو أو مستودعات النسخ الاحتياطي. والنتيجة هي عدد كبير من وحدات تخزين (Volumes) المنفصلة التي يتعين على مسؤولي النظام دمجها بطريقة ما مرة أخرى للحصول على رؤية موحدة للبيانات.
تعتمد على العتاد (Hardware) متخصص
في مصفوفة RAID (RAID Array)، تعد عمليات الكتابة والقراءة المتزامنة لشرائط البيانات (Data Stripes) — وهي الأجزاء التي تُقسّم إليها البيانات الأصلية — أمرًا بالغ الأهمية. فإذا فشل أحد الأقراص العشرة مثلًا في الاستجابة ضمن مهلة الاستجابة (Timeout) المحدد في وحدة تحكم RAID (RAID Controller)، فقد تتعطل عمليات القراءة والكتابة، وقد يعتبر وحدة التحكم (Controller) مصفوفة (Array) بأكملها، أو حتى قرصًا سليمًا، في حالة فاشل (Failed).
وهذا أحد أسباب اعتماد أنظمة RAID عادةً على أقراص أقراص NearLine SAS (NearLine SAS) أو أقراص SATA للمؤسسات (Enterprise SATA) على الأقل. فقد لا يوفر القرص المكتبي زمن استجابة يمكن التنبؤ به بما يكفي، ما قد يتسبب في سلوك غير صحيح من وحدة تحكم RAID (RAID Controller). وبالنسبة للأقراص المخصصة لبيئات RAID، يُتوقع عادةً أن يكون TLER أقل من عدة ثوانٍ، بينما قد تستغرق الأقراص المكتبية وقتًا أطول بكثير للاستجابة للخطأ.
قد تكون أقراص NL-SAS وأقراص SATA للمؤسسات (Enterprise SATA) أغلى عدة مرات من الأقراص المكتبية المماثلة، ما يرفع تكلفة التخزين بشكل كبير. إضافة إلى ذلك، وبسبب مشكلات مثل مشكلة فجوة الكتابة (Write Hole)، غالبًا ما تُنفّذ خوارزميات RAID في العتاد (Hardware) متخصصة. وقد يمثل هذا العتاد (Hardware) جزءًا كبيرًا من تكلفة نظام التخزين، وعند تعطله قد يتطلب الاستبدال بمكوّن خاص من نفس المورّد وبسعر يحدده المصنع.
ليست محسّنة لأقصى سعة قابلة للاستخدام مع حماية قوية
في RAID 5 التقليدية، تستهلك التكافؤ (Parity) نحو 20 إلى 25% من السعة الخام. وعند استخدام RAID 6 للحصول على حماية أقوى، قد ترتفع تكلفة التكافؤ (Parity) إلى نحو 25 إلى 35%.
المشكلة الأساسية هي أنه رغم التضحية بهذه النسبة من السعة، تبقى الحماية محدودة بفشل قرص واحد أو قرصين فقط داخل كل مصفوفة (Array). فمثلًا، تخيل بيئة تضم 1,000 قرص مكوّنة من مئة مصفوفة RAID 6 (RAID 6 Array)، تضم كل واحدة منها ثمانية أقراص بيانات وقرصَي التكافؤ (Parity). رغم تخصيص 200 قرص للالتكافؤ (Parity)، تستطيع كل مصفوفة (Array) منفردة تحمّل فشل قرصين فقط. أما العطل الثالث في أي مصفوفة (Array)، فقد يجعل البيانات الموجودة فيها غير متاحة.
صُممت دون وضع الصيانة التشغيلية في الحسبان
عند تعطل قرص في مصفوفة RAID (RAID Array)، يجب على المسؤول استبداله بسرعة حتى تبدأ عملية إعادة البناء (Rebuild) فورًا. وإذا لم يكن المسؤول على علم بالعطل أو تأخر الاستبدال، فقد يتعطل قرص آخر وتضيع مصفوفة (Array) بالكامل.
يمكن تخصيص قرص احتياطي ساخن (Hot Spare) لتقليل هذا الخطر، لكن ذلك يستهلك أقراصًا إضافية وSlots في وحدة التحكم (Controller). ويمكن للوحدات التحكم (Controllers) الأعلى تكلفة توفير قرص احتياطي ساخن عام (Global Hot Spare) وتقليل المشكلة إلى حد ما. ومع ذلك، كقاعدة عامة، تتطلب بيئات RAID استبدال الأقراص المعطلة بأسرع وقت ممكن لتقليل خطر فقدان البيانات بالكامل.
صُممت دون مرونة في نمو البيانات
لا يمكن عادةً تغيير إعدادات مصفوفة RAID (RAID Array) من دون إعادة بناء مصفوفة (Array) أو إنشائها من جديد. بمعنى آخر، عندما يريد المسؤول تغيير الإعدادات (Configuration) مصفوفة (Array)، يجب أولًا أخذ النسخ الاحتياطي (Backup) من البيانات الحالية، ثم حذف مصفوفة (Array)، ثم إنشاء الإعدادات (Configuration) جديدة.
وعند الوصول إلى عشرات أو مئات التيرابايت، يمكن أن تصبح السعة المؤقتة المطلوبة لهذا النسخ الاحتياطي (Backup)، فضلًا عن عملية النسخ نفسها، تحديًا تشغيليًا كبيرًا.
صُممت دون حماية من تلف البيانات الصامت
من المعروف منذ فترة طويلة أن البيانات المخزنة على الأقراص الصلبة يمكن أن تتعرض للتلف والأخطاء لأسباب متعددة، منها الإشعاع الكوني وأخطاء البرمجيات الثابتة (Firmware). ورغم أن مصنّعي الأقراص قد يحددون معدل خطأ يقارب خطأ واحدًا لكل 10^16 بت، فقد أظهرت أبحاث، مثل دراسات CERN، أن معدلات الخطأ في الواقع قد تكون أعلى.
ومع النمو الأُسّي في كمية البيانات المخزنة عالميًا، يصبح حتى معدل الخطأ الضئيل ذا أهمية كبيرة. وقد قدرت CERN أنه في مصفوفة (Array) بحجم 97 Petabyte، قد يصل حجم البيانات المتضررة المقابلة إلى نحو 120 GB.
وتُعرف هذه الظاهرة باسم تلف البيانات الصامت (Silent Data Corruption)، وهي خطيرة بشكل خاص على تطبيقات مثل الأنظمة المالية، حيث يمكن حتى لبت واحد تالف أن يؤثر نظريًا في قيمة مالية كبيرة.
لا تقوم أنظمة RAID التقليدية عمومًا بالتحقق المستمر من صحة البيانات المخزنة للكشف عن هذا النوع من التلف. فوحدة تحكم RAID (RAID Controller) يفترض عمليًا أن البيانات التي كُتبت على القرص صحيحة — وهو افتراض يصبح أكثر خطورة كلما وصل نظام التخزين إلى أحجام هائلة.
اختناقات وحدة التحكم (Controller)
من نقاط ضعف RAID الأخرى وجود اختناق في وحدة التحكم (Controller). ففي نظام RAID، يكون وحدة التحكم (Controller) مسؤولةًا عن توزيع البيانات على أقراص مصفوفة (Array) أثناء الكتابة وإعادة تجميعها أثناء القراءة.
وبالتالي يمكن أن يصبح وحدة تحكم RAID (RAID Controller) نفسه نقطة اختناق للأداء والتكرار الاحتياطي (Redundancy). تعتمد سرعة القراءة والكتابة على واجهة وحدة التحكم (Controller) وقدرات المعالجة الداخلية لديه. وإذا تعطل وحدة التحكم (Controller)، فقد يصبح نظام RAID بأكمله والبيانات المخزنة عليه غير قابلين للوصول.
قد تستخدم أنظمة RAID الأعلى تكلفة وحدتا تحكم (Dual Controllers) واتصالات تعدد المسارات (Multipath)، لكن القيود الأساسية تبقى موجودة. وحتى لو كان وحدة التحكم (Controller) قادرًا على الاتصال بآلاف الأقراص عبر أنظمة JBOD الحديثة، فإن الأداء الإجمالي لا يمكن أن يتجاوز قدرات المعالجة الداخلية وواجهة وحدة التحكم (Controller).
كما تفرض وحدات التحكم (Controllers) حدودًا أخرى. فمثلًا، لا تستطيع كثير من وحدات التحكم (Controllers) المتوسطة دعم أكثر من عدد محدد من الأقراص، مثل 192 قرصًا، وتحتاج إلى وحدة التحكم (Controller) إضافي بعد تجاوز هذا الحد.
الاعتماد المتعمد على المورّد
هذه ليست بالضرورة نقطة ضعف في تصميم RAID نفسه، لكن بعض مورّدي التخزين يفرضون أحيانًا قيودًا على المنتجات تشجع العملاء على استبدال المعدات وشراء العتاد (Hardware) أحدث وفق دورة محددة.
فمثلًا، تدعم بعض وحدات التحكم (Controllers) أقراصًا صلبة حتى سعة معينة فقط. وعندما تتوفر أقراص ذات سعات أكبر، قد تمنع قيود التوافق (Compatibility) أو البرمجيات الثابتة (Firmware) العملاء من استخدامها. وفي النهاية تصبح المحافظة على المعدات القديمة غير مجدية اقتصاديًا، فيُدفع العميل نحو العتاد (Hardware) أحدث من المورّد. وغالبًا ما يخطط مورّدو التخزين لدورات تحديث العتاد (Hardware) بحدود خمس سنوات.
ماذا ينبغي فعله؟
دفعت محدوديات RAID معماريي أنظمة التخزين إلى تطوير أنظمة تتجنب هذه القيود الأساسية في التصميم. وتعتمد كثير من هذه المعماريات الحديثة، ومنها Xendure، على Distributed الأنظمة (Systems) مصممة لتوفير التخزين على مستوى الـPetabyte وما بعده.
يعالج Xendure المحدوديات المذكورة من خلال معماريته الموزعة وقدراته المصممة لهذا الغرض:
مصمم لسعة وعدد أقراص شبه غير محدودين: يعتمد Xendure على المعمارية الموزعة (Distributed Architecture) مكوّنة من العُقد (Nodes) متصلة بالشبكة. وقد صُمم للتعامل مع أعداد ضخمة جدًا من الأقراص وسعات هائلة. وعلى عكس RAID، تزداد مزاياه كلما زاد عدد الأقراص والسعة. ويُعد تشغيل آلاف الأقراص وعشرات البيتابايت (Petabytes) داخل Xendure العنقود (Cluster) مقياس تشغيل طبيعيًا.
مصمم من دون اختناق مركزي: Xendure موزع بطبيعته. وعند الحاجة إلى سعة أو أداء إضافي، يمكن إضافة العُقد (Nodes) جديدة دون إعادة تصميم النظام القائم. وعلى عكس RAID، حيث قد تؤدي إضافة الأقراص إلى تعقيد تشغيلي إضافي، فإن إضافة العُقد (Nodes) وأقراص إلى Xendure عملية التوسع (Scaling) مباشرة. وبما أن Xendure العميل (Client) يصل إلى جميع العُقد (Nodes) بالتوازي، فإن زيادة عدد العُقد (Nodes) ترفع الأداء الإجمالي إلى جانب زيادة السعة.
مصمم للوصول الموحد إلى الملفات: صُمم Xendure للوصول القائم على الملفات، بما في ذلك الملفات شديدة الكِبر. ويوفر عدة طرق للوصول، منها واجهة برمجة التطبيقات REST (REST API) وتركيب نظام الملفات (File-System Mounting) وحزم تطوير البرمجيات (SDKs)، بحيث تستطيع التطبيقات والمستخدمون الوصول إلى بياناتهم بسهولة. ولا يستخدم Xendure نموذج LUN أو قسم (Partition) التقليدي؛ بل يستخدم مساحات الأسماء (Namespaces)، بحيث يمكن عرض كامل سعة عنقود (Cluster) متعدد البيتابايت (Petabytes) كمساحة موحدة.
مصمم حول العتاد (Hardware) متاح وغير احتكاري (Proprietary): يستخدم Xendure العتاد (Hardware) متوفرًا بسهولة في السوق. ولا يرتبط أي مكوّن بمنصة العتاد (Hardware) احتكارية، لذلك يمكن استبدال المكوّن المعطل بقطعة قياسية متاحة في السوق. لا يوجد اعتماد على مصنع واحد، ولا يُجبر العملاء على دفع سعر إضافي (Premium) مقابل مكونات احتكاري (Proprietary). كما يقلل استخدام العتاد (Hardware) القياسي من منحنى التعلم؛ فالمسؤولون الذين لديهم خبرة في شبكات IP والعتاد (Hardware) التقليدي وأنظمة التشغيل يستطيعون التعامل مع المنصة دون الحاجة إلى إتقان منظومة العتاد (Hardware) خاصة بمورّد بعينه.
مصمم للاستفادة الفعالة من السعة مع حماية قوية للبيانات: على عكس RAID التقليدية، يستخدم Xendure خوارزمية BitExpander لحماية البيانات. وتتيح BitExpander مستويات حماية يصعب تحقيقها باستخدام RAID التقليدية. فمثلًا، في الإعدادات (Configuration) من نوع 16/20، تُقسّم البيانات إلى 16 جزءًا ثم يتم توسيعها إلى 20 جزءًا، ما يسمح باستعادة البيانات الأصلية حتى عند فقدان أربعة أجزاء. وفي مجموعة من 20 قرصًا، يعني ذلك إمكانية استعادة البيانات حتى في حال تعطل أربعة أقراص في الوقت نفسه، مع استخدام أقل من 20% من السعة الخام للحماية.
إضافة إلى ذلك، يستخدم مسار البيانات (Data Path) في Xendure Checksum بطول 160-bit للتحقق من البيانات المخزنة والحماية من تلف البيانات الصامت (Silent Data Corruption). كما يستطيع Xendure تطبيق مستويات حماية مختلفة على ملفات مختلفة؛ فمثلًا يمكن استخدام الإعدادات (Configuration) 16/20 لملف، والإعدادات (Configuration) أقوى 10/20 لملف حرج، بحيث تبقى البيانات متاحة حتى لو تعطلت عشرة أقراص من أصل عشرين في الوقت نفسه.
مصمم للإدارة المباشرة: يمكن إدارة النظام بالكامل عبر واجهة المستخدم الرسومية عبر الويب (Web GUI) أو CLI. وإضافة الأقراص والعُقد (Nodes) أو إزالتها عملية مباشرة. عند إضافة العقدة (Node) أو قرص، تصبح سعته مرئية وقابلة للاستخدام دون الحاجة إلى تعديل الإعدادات (Configuration) الحالية. وإذا تعطل قرص أو العقدة (Node)، يبدأ النظام تلقائيًا عملية إعادة البناء (Rebuild) باستخدام السعة المتاحة، دون الحاجة إلى تدخل المسؤول. كما تستخدم المنصة العتاد (Hardware) تقليديًا مألوفًا لمسؤولي تقنية المعلومات (IT)، ما يسهّل التعلم والصيانة المستمرة.
في المحصلة، Xendure هو نظام تخزين مصمم للالبيانات الضخمة (Big Data) ويعالج القيود الأساسية في معمارية RAID التقليدية.