ملاحظة من Zima
شكرًا لك، Ted، على توثيق ZimaCube 2 كنظام ينمو على طبقات بدلًا من كونه جهازًا جاهزًا مكتملًا. يسجل بناؤك ضمن Pioneer Program الترقيات الناجحة واختبارات التخزين المعيارية وترحيل Immich والأجزاء التي قاومت — بما في ذلك مسار Thunderbolt الذي تحول في النهاية إلى حل OCuLink. ومن خلال نشر القياسات والحلول البديلة والأخطاء وقرارات العتاد المتغيرة مع تطور عملية البناء، فإنك تقدم للمجتمع شيئًا أكثر فائدة من ورقة مواصفات نهائية: سجلًا يوضح كيفية تطور مختبر منزلي حقيقي يعمل بنظام ZimaOS.
— Zima
تعرّف إلى ted-knight
يوثق Ted-knight أحد أكثر عمليات بناء ZimaCube 2 منهجية ضمن Pioneer Program. ولا يتمحور مشروعه ZimaCube 2 Build حول إعداد نهائي واحد. بل ينقسم المشروع إلى مراحل، مع اختبار كل طبقة قبل إضافة الطبقة التالية.
الهدف من عملية البناء واضح ومباشر: إنشاء جهاز NAS يمكن الوثوق به لحفظ البيانات المهمة اليوم، مع ترك مساحة كافية للاستضافة الذاتية والوسائط والذكاء الاصطناعي المحلي وأعباء العمل الأخرى مستقبلًا. وقد قاد ذلك ted إلى العمل على بنية التخزين وZFS وbtrfs وترقيات الذاكرة وNVMe وتوسعة OCuLink والاختبارات المعيارية ودمج ZimaOS وترحيل Immich، إضافة إلى خارطة طريق تزداد تفصيلًا لما قد يصبح عليه الجهاز لاحقًا.
بدأ باستخدام ZimaCube 2 Standard: نظام مزود بمعالج Intel Core i3-1215U وذاكرة DDR5 بسعة 8GB ووحدة تخزين NVMe للنظام بسعة 256GB. ولم يدم الإعداد الأصلي طويلًا.
بناء أساس التخزين قبل إضافة المزيد من الخدمات
لم تكن الأولوية الأولى لدى Ted هي ملء الخادم بالتطبيقات، بل تحديد المكان الذي ينبغي أن تعيش فيه الأنواع المختلفة من البيانات.
يستخدم النظام الناتج عدة طبقات تخزين، لكل منها مهام مختلفة عن قصد. يظل ZimaOS على وحدة Kingston NVMe بسعة 256GB مخصصة له. وأصبحت وحدة Crucial P510 NVMe بسعة 2TB باسم Arctic-Storage، وهي طبقة btrfs لبيانات التطبيقات وصور Docker وقواعد البيانات وغيرها من أعباء العمل النشطة. وتشكل أربع وحدات NVMe بسعة 2TB طبقة glacier، وهي مجموعة ZFS بنظام RAIDZ1 توفر نحو 5.5TB من المساحة القابلة للاستخدام. ولاحقًا، أصبحت أربع وحدات Seagate IronWolf بسعة 4TB مجموعة btrfs بنظام RAID5 وسعة 12TB للوسائط المجمعة والبيانات الأقل استخدامًا.
تتعلق البنية بدرجة أقل بجعل كل محرك يتصرف بالطريقة نفسها، وبدرجة أكبر بمواءمة التخزين مع أعباء العمل. تنتمي قواعد البيانات ذات عمليات الإدخال والإخراج العشوائية الكثيفة إلى P510 السريع. ويمكن أن تستقر أعباء العمل التسلسلية الأكبر والبيانات التي تستفيد من مجاميع فحص ZFS والتكرار على glacier. أما الوسائط المجمعة فيمكن نقلها إلى طبقة IronWolf الأعلى سعة.
عندما لم يعمل Thunderbolt 4، تغيّرت البنية
من أكثر الجوانب فائدة في مشروع ted أن التجارب الفاشلة بقيت موثقة.
كانت الخطة الأصلية تقضي بتوصيل صندوق Aoostar TB4S-OC ذي منافذ NVMe الأربعة بجهاز ZimaCube 2 عبر Thunderbolt 4. اختبر Ted كابلات مختلفة بسرعة 40Gbps، ومنفذي Thunderbolt، والطاقة الخارجية، وسلوك النواة الأساسي، لكن الصندوق ظل عاجزًا عن إنشاء اتصال PCIe مستقر.
أشار التحقيق في النهاية إلى التفاعل بين إعداد Thunderbolt في ZimaOS ووحدة التحكم ASMedia ASM2462PDX داخل الصندوق. وبدلًا من الاستمرار في فرض الخطة الأصلية، غيّر ted البنية.
وُضع محول PCIe x4 إلى OCuLink في الفتحة 1. وانتقل صندوق Aoostar من Thunderbolt إلى اتصال OCuLink مباشر. ظهرت محركات NVMe الأربعة جميعًا عند الإقلاع الأول، من دون مشكلات النفق والمصادقة التي أعاقت إعداد Thunderbolt.
أثر التغيير أيضًا في الخطط اللاحقة. أصبحت الفتحة 1 مشغولة بالتخزين، بينما ظل منفذا Thunderbolt متاحين لتجارب مستقبلية مثل الشبكات المباشرة أو مسار مختلف لوحدة eGPU. لم يتحول فشل الاتصال ببساطة إلى ملاحظة هامشية لاستكشاف الأخطاء وإصلاحها؛ بل غيّر خارطة طريق الجهاز بأكمله.
قياس أداء التخزين بدلًا من افتراض أي طبقة كانت أسرع
وبمجرد أن أصبح التخزين جاهزًا، قاس ted أداءه.
يستخدم عمله في المرحلة 1.5 fio لمقارنة مجموعة glacier بنظام ZFS RAIDZ1 مع Arctic-Storage، بدلًا من التعامل مع «NVMe» كفئة أداء واحدة. أظهر الاختبار البارد وصول glacier إلى 1,726 ميجابايت/ثانية في الكتابة التسلسلية و2,591 ميجابايت/ثانية في القراءة التسلسلية، بينما كانت طبقة Arctic ذات محرك الأقراص الواحد أقوى بكثير في الإدخال والإخراج العشوائي، إذ وصلت في موضعها الأصلي إلى 205,588 IOPS للقراءة العشوائية بحجم 4K.
ظهرت النتيجة الأكثر إثارة للاهتمام عندما دخلت ذاكرة ZFS ARC في المعادلة. إذ أمكن تلبية القراءات المتكررة من glacier من ذاكرة RAM بدلًا من العودة إلى محركات NVMe. ومع إعداد الذاكرة السابق البالغ 16 جيجابايت، بلغت القراءات العشوائية الدافئة نحو 83,929 IOPS بدلًا من نتيجة القراءة الباردة البالغة 14,781 IOPS.
أثّرت هذه النتيجة لاحقًا في قرار آخر متعلق بالمكونات. رقّى Ted الجهاز إلى 32 جيجابايت باستخدام وحدتي DDR5 بسعة 16 جيجابايت لكل منهما، منتقلًا من الذاكرة أحادية القناة إلى ثنائية القناة. بعد الترقية، ارتفعت قراءات ARC العشوائية الدافئة مجددًا إلى 126,816 IOPS — أي تحسن مقاسه 51 بالمئة مقارنة بالنتيجة السابقة.
كما شككت المعايير في موضع Crucial P510 الأصلي. ففي الحجرة السابعة من طراز Standard، كان معدل النقل التسلسلي مقيّدًا بالجسر. نقل Ted محرك الأقراص إلى فتحة M.2 المدمجة، وقاس ارتفاع سرعة القراءة التسلسلية من 874 ميجابايت/ثانية إلى 1,677 ميجابايت/ثانية، بينما ارتفع أداء القراءة العشوائية بحجم 4K من 205,588 إلى 403,078 IOPS.
لم يكن الدرس ببساطة أن إحدى الفتحات كانت أسرع. فقد غيّرت القياسات مواضع أعباء العمل، وحددت الترقيات التي تستحق التنفيذ فعليًا.
تشغيل ZFS إلى جانب ZimaOS
يكشف هذا التصميم أيضًا عن حدّ فاصل مثير للاهتمام بين ما يديره ZimaOS أصليًا وما يمكن لمستخدم متمرس إضافته تحته.
يستخدم Ted عمدًا btrfs مع Arctic-Storage ومجموعة IronWolf، لأن وحدات التخزين هذه تتكامل طبيعيًا مع ZimaOS. أما مجموعة glacier فمختلفة؛ إذ أُنشئت كمصفوفة ZFS RAIDZ1 من سطر الأوامر، ما أتاح لـ ted مجموعات بيانات ZFS، وعمليات التحقق، والتخزين المؤقت عبر ARC، واللقطات، ونموذج تخزين كان أنسب لبعض أعباء العمل التي خطط لها.
وتأتي هذه المرونة مع جانب سلبي بسيط: مجموعات تخزين ZFS التي تُنشأ من سطر الأوامر لا تظهر كوحدات تخزين أصلية في ZimaOS ضمن الواجهة.
حلّ Ted البديل بسيط وعملي. فهو يعرض مجموعات بيانات ZFS الفردية عبر روابط رمزية ضمن /DATA، مما يتيح ظهور مسارات مثل مستندات glacier والوسائط والنسخ الاحتياطية وتخزين الأجهزة الافتراضية داخل تطبيق الملفات في ZimaOS، مع بقاء مجموعة التخزين الأساسية مُدارة عبر ZFS.
اكتشف مشكلة أخرى في وضوح استخدام الذاكرة. يمكن لـ ZimaOS الإبلاغ عن أن جزءًا كبيرًا من ذاكرة RAM «مستخدم» عندما تملأ ذاكرة ZFS ARC الخاملة في الأصل. btop وتحكي إحصاءات ARC قصة أكثر فائدة: تستهلك ذاكرة التخزين المؤقت الذاكرة لأنها متاحة، ويمكن لـ ZFS تحريرها عندما تحتاج التطبيقات إلى المزيد.
هذا هو نوع الملاحظات الذي يهم في مشروع Pioneer. لا يوضح Ted ما الذي يعمل في ZimaOS فحسب؛ بل يوثّق أيضًا أين يصل إعداد التخزين المتقدم إلى حدود واجهة المستخدم الحالية، وما يفعله عندما يبلغ تلك الحدود.
نقل مكتبة Immich موجودة من دون فقدان سجلها
تصبح بنية التخزين أكثر أهمية بكثير عندما تبدأ البيانات التي لا يمكن تعويضها بالانتقال إليها.
بالنسبة إلى ted، كان ذلك الاختبار هو Immich. فقد كان لديه بالفعل مثيل Immich يعمل على خادم ZimaOS قديم من صنعه، وأراد نقله إلى ZimaCube 2 من دون البدء من جديد.
شمل الترحيل 14,505 صورة و925 فيديو — بإجمالي 134 جيجابايت. لكن البيانات المهمة لم تقتصر على ملفات الصور. فقد كانت الألبومات والأشخاص والتعرّف على الوجوه والذكريات والروابط المشتركة وغيرها من البيانات الوصفية مخزنة في PostgreSQL.
وباستخدام تطبيق الملفات في ZimaOS عبر الشبكة المحلية، نسخ ted كليهما /DATA/Gallery/immich والمجلد الكامل /DATA/AppData/immich المجلد، بما في ذلك pgdata. أُوقِف مثيل Immich المصدر قبل النسخ لضمان اتساق بيانات PostgreSQL.
بعد الترحيل، ظل الحساب والألبومات ومعلومات الوجوه والذكريات والمكتبة سليمة، مع عدم الإبلاغ عن أي فقدان للبيانات. ثم تحقّق Ted من قاعدة بيانات PostgreSQL مباشرةً بدلًا من افتراض أن نجاح تسجيل الدخول يعني بقاء كل شيء.
إذا كنت تخطط لعملية نقل مماثلة، فإن دليل ترحيل Immich إلى ZimaCube 2 يوضح هذا التمييز المهم نفسه: لا يكفي نقل مكتبة الوسائط وحدها — بل يجب نقل قاعدة البيانات معها.
من ترحيل بحجم 134 جيجابايت إلى 725 جيجابايت من الصور والفيديوهات المستضافة ذاتيًا
لم تنتهِ مرحلة Immich عند نجاح ترحيل الخادم القديم.
ما بدأ على أنه نقل لمكتبة ZimaOS موجودة تحوّل إلى انتقال أكبر بكثير بعيدًا عن استخدام iCloud كمكان التخزين الرئيسي لصور وفيديوهات ted. وبدأ هاتف iPhone الخاص به نقل مكتبة iCloud الأصلية إلى Immich الذي يعمل على ZimaCube 2.
بنهاية تلك المرحلة، كان الخادم يضم 63,665 عنصرًا بإجمالي 725 جيجابايت: 55,604 صورة و8,061 فيديو.
لم يكن الهدف التظاهر بإمكانية استبدال كل خدمة سحابية من Apple. فما زال Ted يرى أن نسخ الأجهزة الاحتياطية والرسائل وغيرها من البيانات الخاصة بنظام iOS من الأمور المنطقية للاحتفاظ بها ضمن خطة iCloud أصغر. كان التغيير أكثر تركيزًا: نقل مكتبة الصور والفيديو الكبيرة إلى مساحة تخزين يتحكم بها، مع الإبقاء على الخدمات السحابية التي لا تزال تؤدي غرضًا مفيدًا.
أوجد ذلك القرار أيضًا مسؤولية جديدة. لا تصبح مكتبة الصور المستضافة ذاتيًا أكثر أمانًا من نسخة سحابية إلا عند نسخها احتياطيًا بطريقة صحيحة. لذلك تمتد ملاحظات ترحيل Ted إلى نسخة ثانية على TrueNAS، مما يضع الأساس لمرحلة النسخ الاحتياطي الأوسع وفق قاعدة 3-2-1، التي لا تزال ضمن خارطة الطريق.
البناء حول ما يسهّله ZimaOS — وقياس ما تبقى
اختار Ted نظام ZimaOS عن قصد. فبعد سنوات من استخدام Synology وكونه مستخدمًا قديمًا لـ CasaOS، أراد نموذج التطبيقات الأنظف الذي يركّز على Docker، مع الاحتفاظ بإمكانية الوصول إلى النظام الأساسي عندما يتطلب البناء شيئًا أكثر تقدمًا.
تستفيد عدة أجزاء من المشروع من هذا التوازن. نقلت أداة ترحيل AppData المدمجة بيانات تطبيقات Docker بعيدًا عن محرك النظام إلى Arctic-Storage، من دون إعادة بناء كل تطبيق. وقدّمت أداة الملفات Files سير العمل عبر الشبكة المحلية المستخدم لترحيل Immich. وتشمل الأدوات الأصلية fio, zpool, zfs, nvme، و iostat أتاح ذلك قياس بنية التخزين وإدارتها تحت الطبقة الرسومية.
تكشف أجزاء أخرى عن المواضع التي لا تزال فيها التجربة أقل تكاملًا. يحتاج تخزين ZFS المُنشأ عبر CLI إلى حل بديل باستخدام الروابط الرمزية. وتجعل ARC قراءة مقدار ذاكرة RAM القياسي أمرًا سهل الالتباس. كما فرض سلوك Thunderbolt إعادة تصميم العتاد.
تجعل هذه الملاحظات المشروع أكثر قيمة من عرض توضيحي تنجح فيه كل تجربة من المحاولة الأولى. يوثّق Ted الفاصل بين تجربة ZimaOS البسيطة والعمل الأعمق في المختبر المنزلي الذي يبدأ عندما يقرر شخص ما تجاوزه.
ما بُني بالفعل — وما يزال ضمن خارطة الطريق
يصف عنوان مستودع ted الوجهة بأنها خادم NAS متواضعًا مدعومًا بالذكاء الاصطناعي، لكن المشروع يُبنى عمدًا على مراحل.
الأساس موجود بالفعل. التخزين متعدد المستويات قيد التشغيل. مجموعة ZFS RAIDZ1 المسماة glacier تعمل بكفاءة. نُقلت Arctic-Storage إلى منفذ M.2 المدمج. وصلت الذاكرة إلى 32GB بتكوين ثنائي القناة. مجموعة IronWolf RAID5 موجودة. اكتملت اختبارات أداء التخزين. اكتملت عملية ترحيل Immich ودمج مكتبة صور iCloud الأوسع.
لا تزال طبقة الوسائط في طور النمو. تم إنشاء مجموعة IronWolf للوسائط المجمّعة، بينما تظل Jellyfin ومجموعة *arr الأوسع جزءًا من أعمال المرحلة الثانية الحالية.
لا تزال طبقات الذكاء الاصطناعي في مراحل لاحقة. تضع خارطة طريق Ted حاليًا اختبار Ollama المعتمد على وحدة المعالجة المركزية فقط في المرحلة 4a، يليه مسار eGPU مزود بـ RTX 4090 في المرحلة 4b، ثم البحث الدلالي عبر وحدات التخزين المحلية في المرحلة 5.
هذا التمييز مهم. يجري بالفعل إعداد ZimaCube 2 للذكاء الاصطناعي المحلي من خلال توزيع التخزين وسعة الذاكرة وقرارات PCIe وتخطيط أعباء العمل، لكن المشروع لم يصل بعد إلى المرحلة التي ينبغي فيها تقديم الاستدلال باستخدام وحدة معالجة الرسومات بوصفه نتيجة مكتملة.
للقراء الذين يستكشفون هذا الاتجاه المستقبلي الآن، يتناول دليلنا حول الذكاء الاصطناعي المحلي على ZimaCube 2 كيفية ملاءمة Ollama والذاكرة وتوسعة PCIe وترقيات وحدة معالجة الرسومات اللاحقة مع خارطة طريق مماثلة لمختبر منزلي.
بناء يتغير عندما تتغير الأدلة
النمط الأكثر ثباتًا في مشروع ted ليس ZFS أو Immich أو أي قطعة عتاد بعينها، بل الاستعداد لتغيير القرار بعد قياس ما حدث فعليًا.
لم يعمل الغلاف المزود بـ Thunderbolt، لذلك انتقل مسار التخزين إلى OCuLink.
لم يتمكن P510 من الاستفادة من إمكاناته في الحجرة السابعة، لذلك نُقل إلى فتحة M.2 المدمجة.
كان أداء ZFS ARC أفضل من المتوقع، فتحولت الذاكرة إلى ترقية للأداء بدلًا من كونها مجرد سعة إضافية.
نجحت عملية ترحيل Immich بسعة 134 GiB من دون فقدان قاعدة البيانات، لذلك توسعت التجربة لنقل مئات الجيجابايت الإضافية من iCloud.
تترك كل مرحلة وراءها قياسات وأوامر وأخطاء وافتراضات محدثة للمرحلة التالية. وهذا يجعل المستودع مفيدًا حتى لمن لا يبني تكوين التخزين نفسه تمامًا.
لا تزال القصة قيد الكتابة
لا تزال قصة ted-knight وZima قيد الكتابة. بدأ ZimaCube 2 كنموذج Standard بسعة 8GB، وتحول بالفعل إلى نظام تخزين متعدد الطبقات يضم btrfs وZFS RAIDZ1 وتوسعة OCuLink NVMe وذاكرة ثنائية القناة بسعة 32GB وأرشيف IronWolf RAID5 ومكتبة Immich مستضافة ذاتيًا تحتوي على مئات الجيجابايت من الوسائط الشخصية.
لا تزال المراحل التالية مفتوحة عمدًا: Jellyfin ومجموعة الوسائط، وسير عمل أقوى للنسخ الاحتياطي، والذكاء الاصطناعي المحلي المعتمد على وحدة المعالجة المركزية فقط، ومسار مستقبلي لوحدة معالجة الرسومات، والبحث الدلالي، وأي تغييرات أخرى تفرضها القياسات على ted أثناء التقدم.
إذا كنت تريد متابعة عملية البناء مع انتقال هذه المراحل من خارطة الطريق إلى نتائج فعلية، فتابع عملية بناء ZimaCube 2 المستمرة التي ينفذها ted-knight على GitHub.
