يجب على الشركات الصغيرة والمتوسطة التوقف عن الاستناد إلى BackBlaze للحصول على التوجيه

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

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

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

مفهوم SAM-SD، الذي ليس سوى نهج لبناء تخزين مفتوح، مُصمَّم مع وضع سوق التخزين للشركات الصغيرة والمتوسطة في الاعتبار. أما BackBlaze POD فمُصمَّم لسوق نسخ احتياطي استهلاكي متخصص للغاية وكبير النطاق وذو حالة خاصة. SAM-SD مُخصَّص ليُشغَّل من قِبَل الشركات الصغيرة حتى تلك التي لا تضم فريق تقنية معلومات داخليًا. أما POD فمُصمَّم ليُنشر ويُدار من قِبَل فريق هندسة تخزين متخصص بدوام كامل.

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

إتاحة تصميم POD للعموم تُسبب كثيرًا من الارتباك لأنه جزء واحد فقط من كيان أكبر. فتصميم مركز البيانات الكامل وآليات التكرار بين PODs ووسائله ليس عامًا بل خاصًا ومملوكًا. إذ يمثّل POD في حد ذاته عقدة واحدة فقط من مجموعة (أو Vault) ولا يعكس المجموعة نفسها، حيث يجري أهم العمل. في الواقع تصميم POD نفسه ليس أكثر من العمل الذي أنجزه مشروعا Sun Thumper وSAM-SD في العقد الماضي دون قيود الموثوقية. لا ينبغي أن يكون تصميم POD جديدًا بل بديهيًا. وهو تصميم جرى تجنّبه لعقود في مجال تخزين الشركات الصغيرة والمتوسطة لأنه غير قابل للتطبيق بشكل جذري في هذا السياق.

لأن جانبي التجميع والتكرار يُهمَلان حين الحديث عن BackBlaze POD، تُطرح افتراضات ضخمة حول سعة POD ذات عبء أكثر انخفاضًا مما تحصل عليه BackBlaze نفسها من البنية التحتية لـ POD حتى على النطاق الواسع. فعلى سبيل المثال بمصطلحات RAID، يشبه هذا افتراض أن POD يستخدم RAID 6 (بعبء 5% فقط) لأن هذا هو RAID المكوّن الفردي، في حين يُستخدم في الواقع RAID 61 (بعبء 55%). كثير من متخصصي تقنية المعلومات في الشركات الصغيرة والمتوسطة حين يتطلعون لاستخدام تصميم POD يفكرون فعليًا في استخدام RAID 6 فحسب إضافةً إلى استخدام POD واحد فقط. مدى ابتعاد هذا عن نموذج BackBlaze مذهل.

BackBlaze: “تجمع Backblaze Vaults عشرين Storage Pod ماديًا في هيكل افتراضي واحد. يطبّق برنامج Vault ترميز Reed-Solomon الخاص بنا لتوزيع شظايا البيانات على جميع العشرين pod في Vault في آنٍ واحد، مما يُحسّن المتانة بشكل جذري.”

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

بالتعمق في أوجه اختلاف BackBlaze POD في تصميمه عن الاحتياجات المعيارية للأعمال العادية، نجد هذه المشكلات:

• صُمِّم POD ليكون غير موثوق، مُعتمِدًا على طبقة موثوقية وتكرار على المستوى الفائق للـ POD تستلزم نشر عدد كبير من PODs وتكرار البيانات فيما بينها عبر آليات تكرار أو تجميع مخصصة. بدون هذه الطبقة يكون POD كليًا خارج سياقه. يُعرف المستوى الفائق داخليًا بـ BackBlaze Vault.
• صُمِّم POD للنشر في مراكز بيانات مؤسسية مع معالجة دقيقة للاهتزازات وتكييف للطاقة وأنظمة بيئية. وهو أقل مرونة في مواجهة هذه القضايا مقارنةً بالعتاد المؤسسي المعياري.
• صُمِّم POD ليُستبدل عادةً كوحدة كاملة بدلًا من إصلاح العقدة في مكانها. هذا عكس العتاد المؤسسي المعياري ذي المكونات القابلة للتبديل الساخن المُصممة لإصلاحها دون انقطاع وبالتأكيد دون استبدال كامل. نُسمّي هذا حالة استخدام قابلة للتخلص منها أو عابرة.
• صُمِّم POD ليكون منخفض التكلفة جدًا لاحتياجات التخزين البارد والبطيء للغاية. وبينما قد تتوافر هذه الحاجة في الشركات الصغيرة والمتوسطة، إلا أنها في الغالب لا تتوافر.
• صُمِّم POD ليكون عقدة تخزين واحدة عالية السعة في مجموعة ذات سعة هائلة. قليل من الشركات الصغيرة والمتوسطة يمكنها الاستفادة حتى من إمكانيات تخزين POD واحد فضلًا عن مجموعة كبيرة بما يكفي لتبرير تصميم POD.
• صُمِّم BackBlaze POD لاستخدام ترميز مُمحى مخصص لا RAID. إذ إن RAID غير فعّال على هذا النطاق حتى على مستوى POD الواحد.
• صُمِّم POD الفردي لسعة 180 تيرابايت وسعة على نطاق Vault تبلغ 3.6 بيتابايت.

المرجع الحالي لـ BackBlaze POD 5: https://www.backblaze.com/blog/cloud-storage-hardware/

باختصار، BackBlaze POD ركيزة عبقرية لخدمة عبقرية تُلبّي حاجة محددة جدًا بعيدة كل البعد عن احتياجات سوق التخزين للشركات الصغيرة والمتوسطة. احترم BackBlaze على عملها الرائع، لكن لا تحاول محاكاته.