كلمة من Zima
شكرًا لك، MorgothTheBauglir، على إظهار المدى الذي يمكن أن تصل إليه منصة خادم منزلي مدمجة عندما تُعامل التوسعة كأداة تصميم لا كحد ثابت. فمن اكتشاف ZimaOS على جهاز NAS من تصميمك إلى تحويل ZimaBoard 2 إلى نقطة التحكم في نظام تخزين يتجاوز 350 تيرابايت، يعكس عملك نوع التجارب العملية التي تجعل مجتمعات الاستضافة الذاتية ذات قيمة.
نقدّر خصوصًا أنك شاركت أكثر من مجرد رقم السعة النهائية. فقد وثّقت التصميم، وشرحت اختيارات العتاد والمفاضلات، وأجبت عن أسئلة مستخدمي المختبرات المنزلية الآخرين، وحافظت على صراحتك مع استمرار نمو النظام ووصوله في النهاية إلى حد أداء جديد. تمنح هذه الشفافية البناة الآخرين شيئًا أكثر فائدة من مجرد عرض: مشروعًا حقيقيًا يمكنهم دراسته وطرح الأسئلة حوله والتعلم منه.
— Zima
تعرّف على MorgothTheBauglir
MorgothTheBauglir هو الاسم الذي يستخدمه على Reddit صاحب التصميم الذي قُدّم باسم Igor في دراسة الحالة السابقة على ZimaSpace حول سعة 350 تيرابايت. وقد وصفه ذلك الملف بأنه مهندس شبكات من البرازيل لديه اهتمام طويل الأمد بأجهزة الكمبيوتر وبنية الخوادم وإدارة البيانات. ويتبع عمله في مختبره المنزلي النمط نفسه: الحفاظ على حجم عملي، وإعادة استخدام العتاد المفيد حيثما كان ذلك منطقيًا، وترك مساحة كافية لمواصلة التجارب.
انتقلت قصته مع Zima من اكتشاف ZimaOS على جهاز NAS من تصميمه إلى تحويل ZimaBoard 2 إلى نقطة التحكم في تصميم تخزين تجاوز 350 تيرابايت. ويواصل نشاطه العلني على Reddit هذا النهج العملي من خلال مناقشات حول التخزين ووحدات HBA والافتراضية والشبكات والاستضافة الذاتية وZimaOS. يمكنك متابعة MorgothTheBauglir على Reddit للاطلاع على استمرار المشاريع والنقاشات خارج هذه الصفحة.
من ZimaOS إلى ZimaBoard 2 مخصص
بدأت الرحلة نحو ZimaBoard 2 بالبرمجيات. ووفقًا لدراسة الحالة الأصلية على ZimaSpace، تعرّف Igor أول مرة على ZimaOS من خلال NAS Compares وثبّته على جهاز NAS من تصميمه. وما برز لم يكن ميزة واحدة، بل مزيجًا من واجهة مصقولة وتشغيل خفيف وسير عمل للاستضافة الذاتية بدا سهلًا دون أن يخفي العتاد الأساسي.
بعد انضمامه إلى مجتمع IceWhale، فاز بجهاز ZimaBoard 2 832 في إحدى الفعاليات، ثم انتقل سريعًا إلى ZimaBoard 2 1664 الأعلى فئة. وقد منح ذلك تجربة التخزين التالية ما لم يوفره حاسوب mini-PC عام سابق بالحجم المدمج نفسه: مسار توسعة PCIe مباشرًا يمكن اعتباره نقطة انطلاق لنظام أكبر بكثير.
تحويل مسار توسعة PCIe واحد إلى أكثر من 350 تيرابايت
بدأ المشروع الذي جعل هذه التجميعة لافتة باعتباره NAS بسعة 80 تيرابايت، واستمر في التوسع. وبحلول يناير 2026، أعاد MorgothTheBauglir بناءه حول ZimaBoard 2 داخل رف صغير بحجم 10 بوصات، ودفع سعة التخزين المختلطة إلى أكثر من 350 تيرابايت.
جمعت سلسلة العتاد الأساسية بين ZimaBoard 2 ووحدة HBA من نوع IBM M1210 وموسّع SAS من نوع Adaptec AEC-82885T. وحول هذه المكونات، استخدم مزيجًا من محركات HDD وSSD، إلى جانب توزيع مخصص للطاقة، وقطاعات ألومنيوم، وكابلات كثيرة، وأنظمة تبريد، وحوامل مطبوعة ثلاثيًا. وكانت النتيجة أقرب إلى هيكل تخزين مدمج مصمم حول الأجزاء والسعة والمساحة المتاحة تحديدًا، منها إلى NAS جاهز من السوق.
وثّقت ZimaSpace البنية ومكدس البرمجيات وقرارات التوسعة في دراسة حالة تخزين ZimaBoard 2 بسعة 350 تيرابايت أو أكثر. ويضيف سجل التجميعة على Reddit التفاصيل العملية من ورشة العمل: مشكلات تدفق الهواء، وحوامل الأقراص، والأجزاء المطبوعة ثلاثيًا، وتوجيه الكابلات، وتوزيع الطاقة، والحيل الصغيرة اللازمة لجعل الرف الكثيف عمليًا.
كانت التوسعة أداة التصميم
بالنسبة إلى هذه التجميعة، لم تكن ميزة ZimaBoard 2 المهمة مجرد إمكانية توصيل المزيد من وحدات التخزين، بل إن فتحة PCIe كانت قادرة على قبول HBA حقيقي مباشرةً. وقد سمح ذلك للنظام بالانتقال من لوحة مدمجة إلى بنية توسعة SAS من دون تحويل المضيف نفسه إلى خادم تقليدي كبير.
شرح MorgothTheBauglir الفرق بعبارات بسيطة: إذ يغيّر دعم HBA المباشر طريقة تصميم NAS مدمج وعالي الكثافة. بقيت اللوحة صغيرة، بينما أصبحت بنية التخزين المحيطة بها أكبر بكثير.
كان التبريد والطاقة والمساحة جزءًا من مشكلة التخزين
لم تكن السعة القيد الوحيد. فقد فرض الطقس الدافئ، والأقراص المؤسسية، ومحدودية المساحة المنزلية، ورف كثيف بعرض 10 بوصات، تصميم تدفق الهواء وتوزيع الطاقة بالتزامن مع مسار البيانات. وكان لا بد أن تعمل المراوح، وحوامل الأقراص، وموضع مزود الطاقة، ومسارات الكابلات ضمن التخطيط المادي نفسه.
وهذا أحد أسباب فائدة البناء فيما يتجاوز سعة التخزين البارزة. فهو يوضح أن التخزين المنزلي كبير السعة لا يقتصر عادةً على توصيل مزيد من الأقراص؛ إذ يصبح التخطيط الميكانيكي، والحرارة، والطاقة، والكابلات، وقابلية الصيانة جزءًا من البنية.
اختيار البرامج وفقًا للقيد
اتبعت برامج التخزين المنطق نفسه الذي يضع القيود أولًا. فبدل بناء المجموعة بأكملها حول بنية ZFS تستهلك قدرًا كبيرًا من الذاكرة، استخدم طبقة المحاكاة الافتراضية Proxmox VE، وآلة افتراضية خفيفة بنظام Windows IoT لتشغيل مهام إدارة التخزين، وStableBit DrivePool لتجميع الأقراص بمرونة وتكرار المجلدات عبر أقراص متفاوتة السعة.
كان ملخّصه في دراسة حالة ZimaSpace متعمّدًا في بساطته: "لا يحتاج الجميع إلى RAID." لم تكن الفكرة أن تصميمًا واحدًا للتخزين أفضل عالميًا من غيره، بل أن حزمة البرامج ينبغي أن تتوافق مع العتاد الفعلي، ونموذج الاسترداد، وعبء العمل، بدل اختيارها لأنها الخيار الأكثر تعقيدًا المتاح.
مشاركة تفاصيل البناء، لا النتيجة فقط
يُعد سجلّ البناء العلني جزءًا مهمًا من القصة. فلم يكتفِ MorgothTheBauglir بنشر صورة للرف بعد اكتماله؛ بل أدرج المكوّنات الرئيسية، ووضع روابط لنماذج الطباعة ثلاثية الأبعاد، ووصف مشكلات التجميع، ودعا إلى طرح الأسئلة حول القطع والصعوبات. وفي النقاش الذي تلا ذلك، أجاب عن أسئلة تتعلق باستهلاك الطاقة، وسرعة الشبكة، واستخدام التخزين، ومقاطع الألومنيوم، وحوامل الأقراص، والترقيات المستقبلية.
وتظهر النبرة العملية نفسها في نقاشاته الأوسع حول الاستضافة الذاتية. فعلى ملفه الشخصي في Reddit، أوصى باستخدام أساليب HBA في وضع IT لتوسعة SATA، ووصف ZimaOS في نقاش لاحق حول الترحيل بأنه خياره لسهولة الاستخدام، مع اقتراح المحاكاة الافتراضية عبر Proxmox عندما تكون اللقطات والاستعادة والتراجع وسهولة الترحيل من الأولويات.
دفع البناء حتى ظهر الحد
لم تتوقف القصة عند 350 تيرابايت. ومع تجاوز النظام 450 تيرابايت، أبلغ MorgothTheBauglir عن تباطؤ عمليات النقل عبر الشبكة، إلى جانب ضغط مستمر على وحدة المعالجة المركزية وكثرة المقاطعات. كان إعداد ZimaBoard 2 مناسبًا لمرحلة 350 تيرابايت، لكن عبء العمل الأكبر أظهر عنق الزجاجة التالي.
وبدلًا من اعتبار ذلك فشلًا، غيّر البنية. انتقلت حوسبة التخزين الأساسية إلى مضيف أعلى أداءً بذاكرة أكبر، واتصال PCIe أسرع، و10GbE، بينما واصل الحامل وأعمال التوسعة تطورهما. ويُعد تحديثه بسعة 450 تيرابايت على Reddit متابعة مفيدة، لأنه يوثق النقطة التي أصبح عندها التصميم المدمج الناجح كبيرًا بما يكفي لتبرير استخدام فئة مختلفة من المضيفين.
هذا التدرج درس أكثر فائدة من ادعاء السعة غير المحدودة. فقد أتاح ZimaBoard 2 تجربة تخزين منزلي عالية الكثافة على نحو غير معتاد؛ ثم قدمت التجربة معلومات واقعية حول مدى ملاءمة المنصة وحول النقطة التي تجاوز فيها عبء العمل إمكاناتها.
ما ظل ثابتًا
وعبر التغييرات التي طرأت على الأجهزة، تظل العادات الهندسية نفسها واضحة: استخدام مسار التوسعة الذي يحل المشكلة الحالية، وتجنب التعقيد الذي لا يبرر تكلفته، وجعل التصميم الميكانيكي جزءًا من بنية النظام، ومشاركة قدر كافٍ من التفاصيل حتى يتمكن الآخرون من التعلم من النتيجة.
ولهذا السبب أيضًا تكتسب العلاقة بين قصة المستخدم هذه ودراسة الحالة التقنية أهميتها. تشرح مقالة 350 تيرابايت البنيةَ، بينما تسجل هذه الصفحة تفاصيل المُنشئ الذي يقف وراءها، والقرارات التي قادت إلى ذلك، وما حدث عندما واصل المشروع نموه.
القصة لا تزال قيد الكتابة
لا تزال قصة MorgothTheBauglir وZima قيد الكتابة. انتقل المشروع بالفعل من خادم NAS أصغر بنظام DIY إلى نظام ZimaBoard 2 بسعة تتجاوز 350 تيرابايت، ثم دخل مرحلة جديدة تجاوزت 450 تيرابايت. ولا يزال الحامل، ومجمّع التخزين، واختيارات البرمجيات تتغير مع ظهور قيود جديدة.
إذا كنت تريد التفاصيل التقنية لمرحلة ZimaBoard 2، فاقرأ دراسة الحالة الكاملة لـ ZimaBoard 2 بسعة 350 تيرابايت. ولمعرفة ما الذي يبنيه ويختبره ويوصي به لاحقًا، تابع MorgothTheBauglir على Reddit.
