الحدود والحصص

حدود نشر Rediacc. ثلاثة منها صارمة ولا يمكن تغييرها بإضافة الأجهزة: حد 61 خدمة لكل مستودع (تخصيص مساحة العناوين)، الحد الأدنى للنواة 6.1 (متطلبات CRIU)، وحد Let’s Encrypt بـ 50 شهادة بأحرف بدل لكل نطاق مسجل في الأسبوع. كل شيء آخر مرن: يتحرك عندما تضيف أجهزة. اعرف الفرق قبل أن تلتزم بطوبولوجيا معينة.

الخدمات لكل مستودع

يدعم كل مستودع ما يصل إلى 61 خدمة تعمل في وقت واحد.

هذا حد صارم يحدده نطاق عناوين الشبكة المخصص لكل مستودع. تحصل كل خدمة على عنوان IP خاص مخصص، ويستوعب كتلة عناوين كل مستودع 61 فتحة خدمة بالضبط.

لاحظ: الوصول إلى 61 خدمة في مستودع واحد يشير عادة إلى مشكلة معمارية، وليس قيد من Rediacc. الحل هو نقل المساعدين ووكلاء المراقبة إلى مستودع منفصل بحدود عزل خاصة، أو تقليل عدد العمليات المستقلة المتوازية داخل التطبيق نفسه.

المستودعات لكل جهاز

لا يوجد حد أقصى صارم يفرضه Rediacc. يعتمد الحد العملي على موارد جهازك:

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

عمليات النشر النموذجية تشغل من 10 إلى 50 مستودعاً لكل جهاز بدون مشاكل. الأجهزة التي تحتوي على 32 جيجابايت أو أكثر من الذاكرة العشوائية و500 جيجابايت أو أكثر من التخزين تشغل بانتظام أكثر من 100 مستودع.

حد معرف الشبكة على مستوى النظام

يتم تعيين معرف شبكة فريد لكل مستودع، وهو رقم يستخدم لحساب نطاق عنوان IP الخاص به. يتم مشاركة هذا المجمع عبر جميع الأجهزة والمستودعات المدارة بنفس إعدادات Rediacc.

الحد	القيمة
إجمالي معرفات الشبكة المتاحة	~261,944
النطاق	لكل إعداد (مشترك عبر جميع الأجهزة في الإعداد)

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

التفريعات

لا يوجد حد لعدد التفريعات النشطة لمستودع ما. كل تفريع هو نسخة كاملة بنظام النسخ عند الكتابة مع تخزين مشفر خاص وعناوين شبكة و Docker daemon خاص. تستهلك التفريعات مساحة قرص تتناسب مع البيانات المكتوبة إليها بعد الإنشاء (وليس الحجم الكامل للمستودع الأصلي).

المنافذ الخارجية

المنافذ النشطة دائماً

لا يتم فتح المنافذ إلا بعد تهيئة عنوان IP عام باستخدام rdc config infra set --public-ipv4. حتى ذلك الحين، لا توجد منافذ مفتوحة على الجهاز. بعد التهيئة:

المنفذ	البروتوكول	الغرض
80	TCP	HTTP: يتم التعامل معه بواسطة Traefik؛ يعيد 404 للنطاقات غير المهيأة، ولا يتم تمريره لأي خدمة
443	TCP	HTTPS: نفس ما سبق؛ يتم رفض الطلبات التي لا تحتوي على مسار مطابق في طبقة البروكسي
10000–10010	TCP	نطاق ديناميكي لتوجيه TCP المدار بواسطة Rediacc

يختلف HTTP/HTTPS عن منافذ TCP الخام: على الرغم من أن المنفذين 80 و443 مفتوحان، يتم التحقق من كل طلب بواسطة البروكسي العكسي مقابل جدول توجيه صريح. بدون خدمة مهيأة ونطاق مطابق، لا يتم الوصول إلى أي كود تطبيق ولا يتم كشف أي بيانات.

توجيه TCP/UDP الاختياري

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

لكشف منفذ من خدمة معينة:

labels:
  - "rediacc.tcp_ports=5432"   # expose PostgreSQL from this container
  - "rediacc.udp_ports=53"     # expose DNS from this container

لفتح منفذ على مستوى الجهاز (متاح لجميع الخدمات):

rdc config infra set -m server-1 --tcp-ports 25,587,993   # mail server
rdc config infra push -m server-1

مرجع CLI: rdc config infra set · rdc config infra push

لا تكشف منافذ قواعد البيانات أو الذاكرة المؤقتة خارجياً إلا إذا كان لديك متطلب محدد. استخدم المسارات التلقائية عبر HTTPS لخدمات الويب وأبقِ خدمات التخزين داخلية.

مخزن البيانات

مخزن البيانات هو مجمع بحجم ثابت يتم إنشاؤه عند إعداد الجهاز لأول مرة. لا يزداد حجمه تلقائياً.

الحد الأدنى الموصى به: 50 جيجابايت
الحجم الأقصى: محدود بقرصك. يمكن لمجمع واحد أن يمتد على قرص كامل.
تغيير الحجم: استخدم rdc datastore resize لتغيير حجم التجمع (يجب أن تكون جميع المستودعات غير محمّلة أولاً).
نظام الملفات: يستخدم Rediacc نظام BTRFS داخلياً للنسخ اللحظية بنظام النسخ عند الكتابة والتفريع الفعال. يتطلب جهازاً يعمل بنواة Linux 6.1 أو أحدث للاستقرار الكامل في الإنتاج.

لكل مستودع حجم أقصى يُضبط عند الإنشاء (الافتراضي: 10 جيجابايت). استخدم rdc repo resize لتغييره يدوياً، أو اضبط سياسة حجم تلقائية ليقوم الجهاز بتوسيعه أثناء التشغيل عند امتلائه (مقيّداً بسقف صريح لكل مستودع واحتياطي مساحة التجمع). ينطبق auto-grow على المستودعات الفردية فقط؛ التجمع نفسه لا يُوسَّع تلقائياً أبداً.

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

مسارات HTTP

تحصل كل خدمة تحمل التسمية rediacc.service_port على مسار HTTPS واحد تلقائياً. لا يوجد حد لعدد الخدمات التي تحتوي على مسارات، وفقاً للحد الأقصى البالغ 61 خدمة لكل مستودع.

يتم إصدار شهادات TLS بأحرف بدل لكل مستودع عند أول عملية نشر عبر Let’s Encrypt (تحدي Cloudflare DNS-01). يُحدد Let’s Encrypt الإصدار بـ 50 شهادة لكل نطاق مسجل في الأسبوع. نظراً لأن Rediacc يستخدم شهادة بأحرف بدل واحدة لكل مستودع (وليس لكل خدمة)، فإن عملية النشر التي تُنشئ أكثر من 50 مستودعاً جديداً في أسبوع واحد ستصل إلى هذا الحد.

تعيد التفريعات استخدام شهادة أحرف البدل الموجودة للمستودع الأصلي ولا تستهلك أي حصة من الشهادات.

نقطة التحقق / الاستعادة (CRIU)

الترحيل المباشر عبر CRIU له القيود التالية:

اختياري: يتم أخذ نقاط التحقق فقط للحاويات التي تحمل التسمية rediacc.checkpoint=true. يتم استبعاد قواعد البيانات والخدمات عديمة الحالة افتراضياً وتبدأ من جديد عند الاستعادة.
متطلبات النواة: Linux 6.1 أو أحدث على كل من الجهاز المصدر والجهاز الوجهة.
وضع الشبكة: يتطلب CRIU وضع الشبكة المضيف. لا يمكن أخذ نقاط تحقق للحاويات التي تستخدم تكوينات شبكة مخصصة.
الذاكرة: يساوي حجم بيانات نقطة التحقق الذاكرة المقيمة للعملية التي تم أخذ نقطة تحقق لها. مجموعات البيانات الكبيرة في الذاكرة (مثل تطبيق Node.js يخزن 4 جيجابايت من البيانات مؤقتاً) تنتج ملفات نقاط تحقق بحجم 4 جيجابايت.
اتصالات TCP: يجب أن تتحمل التطبيقات فقدان الاتصال أثناء الاستعادة. لا يتم الحفاظ على اتصالات TCP النشطة أبداً. العملية المستعادة ترى المقابس على أنها مغلقة ويجب إعادة الاتصال. ينطبق هذا على الاستعادة على نفس الجهاز وعبر الأجهزة على حد سواء.
الاستنساخ الحي على نفس الجهاز يعيد توجيه عناوين الأصل: يعمل rdc repo fork --parent X --tag Y --checkpoint متبوعًا بـ rdc repo up بينما يستمر المستودع الأصل في العمل. تحمل العمليات المستعادة عناوين loopback الخاصة بالأصل لحظة الـ checkpoint، لذا يعيد النظام توجيهها بشفافية إلى عناوين الفورك نفسه (الخدمة ذاتها، نسخة الفورك من البيانات). لا يزال أول استخدام لاتصال TCP مستعاد يفشل ويجب على التطبيق إعادة الاتصال، وفق بند TCP أعلاه.

النسخ الاحتياطي

الحد	القيمة
وجهات النسخ الاحتياطي لكل مستودع	غير محدود
مهام النسخ الاحتياطي المتزامنة	1 لكل مستودع (تصطف المهام في قائمة الانتظار إذا تم تشغيلها بشكل متزامن)
تكرار النسخ الاحتياطي	لا يوجد حد أدنى للفاصل الزمني المفروض؛ محدود بعرض نطاق التخزين الخاص بك. استخدم `rdc config backup-strategy set --name <name> --bwlimit "6M"` لتحديد سرعة الرفع (بصيغة rclone `--bwlimit`: بسيط `6M`، اتجاهي `6M:off`، أو جدول زمني `08:00,3M;22:00,10M`)
الاحتفاظ	يتم التحكم فيه بواسطة مزود التخزين الخاص بك (S3، Cloudflare R2، إلخ). لا يفرض Rediacc سياسات الاحتفاظ.
النسخ الاحتياطي عبر الأجهزة	مدعوم؛ يجب أن يحتوي الجهاز الوجهة على مساحة كافية في مخزن البيانات

CLI و API

الحد	القيمة
أوامر `rdc` المتزامنة على نفس الجهاز	غير محدود (كل أمر يفتح اتصال SSH خاصاً به)
التزامن الافتراضي لبدء المستودعات المتوازية	3 (قابل للتعديل باستخدام `--concurrency`)
مهلة اتصال SSH	30 ثانية للاتصال الأولي
مدة جلسة `rdc`	بدون مهلة؛ العمليات طويلة المدى تحافظ على الاتصال نشطاً

إصدارات نظام التشغيل المدعومة

يجب أن تعمل الأجهزة البعيدة بأحد الأنظمة التالية لتلبية متطلبات Rediacc الخاصة بالنواة ونظام الملفات وعزل الشبكة. هذه القائمة هي المجموعة الرسمية المختبرة في CI (مصفوفة Bridge Workers) ويجب أن تظل متزامنة مع المتطلبات:

نظام التشغيل	الحد الأدنى للإصدار	النواة الافتراضية	ملاحظات
Ubuntu	24.04 LTS (موصى به)	6.8	AppArmor افتراضي.
Debian	13 (Trixie)؛ 12 Bookworm يعمل أيضاً	6.12 (6.1 على Debian 12)
Fedora	43	6.12	SELinux مفعّل افتراضياً.
openSUSE Leap	16.0	6.4+	AppArmor افتراضي.
Oracle Linux	10 (UEK)	UEK 7+	UEK يحتفظ بـ btrfs؛ SELinux مفعّل افتراضياً.

الحد الأدنى المطلوب للنواة: 6.1. يتم رفض الأجهزة التي تعمل بنواة أقدم عند الإعداد برسالة خطأ واضحة.

لماذا النواة 6.1؟ يستخدم Rediacc نظام BTRFS لتخزين المستودعات المشفرة والتفريع بنظام النسخ عند الكتابة. قدم Linux 6.1 تحسينات حاسمة في BTRFS تقلل بشكل كبير من أوقات التحميل لمخازن البيانات الكبيرة، وتحسن أداء حذف اللقطات، وتصلح مشاكل سلامة البيانات الموجودة في النواة الأقدم. النواة 6.1 مطلوبة أيضاً لبرامج عزل الشبكة على مستوى النواة التي تفرض العزل بين المستودعات، وتعيد كتابة استدعاءات bind() بشفافية وتمنع الاتصالات بين المستودعات.

لماذا لا Rocky Linux 10 / نواة RHEL 10 الافتراضية؟ نواة RHEL 10 الافتراضية لا تأتي مع وحدة btrfs (يفشل modprobe btrfs بـ “Module btrfs not found”). لا يمكن لواجهة التخزين المشفرة في Rediacc العمل بدون btrfs. Oracle Linux 10 هو الهدف الوحيد المتوافق مع RHEL في القائمة المدعومة لأنه يعتمد افتراضياً على Unbreakable Enterprise Kernel (UEK) الذي يحتفظ بـ btrfs. راجع المتطلبات: لماذا UEK؟ للشرح الكامل.

مصفوفة ميزات النواة

اقرأ المصفوفة كنظرة سريعة على ما يوفره كل نظام تشغيل مختبر في CI بشكل افتراضي. جميع الأنظمة الخمسة تستوفي كل المتطلبات، لذا هذا مرجع للمشغلين وليس معيار قبول.

نظام التشغيل	وحدة btrfs	cgroups v2	Landlock (ABI 1 أو أعلى)	خطافات eBPF cgroup
Ubuntu 24.04	مدمجة	unified hierarchy	نعم (5.13+)	نعم
Debian 13	مدمجة	unified hierarchy	نعم	نعم
Fedora 43	مدمجة	unified hierarchy	نعم	نعم
openSUSE Leap 16.0	مدمجة	unified hierarchy	نعم	نعم
Oracle Linux 10 (UEK)	مدمجة (عبر UEK)	unified hierarchy	نعم	نعم