كيفية تهيئة تخزين الكائنات S3 لـ ownCloud Infinite Scale

يُمكن لخدمة ownCloud Infinite Scale استخدام تخزين الكائنات المتوافق مع S3 لتخزين ملفات البيانات الثنائية الكبيرة (blobs)، مع الاحتفاظ ببيانات تعريف الملفات على نظام ملفات متوافق مع معيار POSIX. هذا التقسيم هو المفهوم الأساسي الذي يجب فهمه: فـ S3 ليس بديلاً جاهزاً لكل دليل بيانات محلي. في s3ngالتصميم المدعوم، يحتفظ تخزين الكائنات بمحتوى الملفات الثنائية، بينما تبقى بيانات التعريف على تخزين متوافق مع معيار POSIX، مثل نظام الملفات المحلي أو NFS.

يتبع هذا الدليل وثائق التخزين الحالية الخاصة بـ ownCloud Infinite Scale والمتاحة في أكتوبر 2026. وهو مكتوب للمسؤولين الجدد على s3ngبرنامج التشغيل والذين يرغبون في الحصول على تكوين يمكنهم فهمه قبل تكييفه مع Docker Compose أو systemd أو Kubernetes أو طريقة نشر أخرى.

المراجع الرسمية المستخدمة في هذا الدليل هي وثائق تخزين ownCloud S3 ، وتكوين خدمة Storage-Users ، والاعتبارات العامة للتخزين .

ما معنى S3 في ownCloud Infinite Scale؟

S3 هي واجهة برمجة تطبيقات لتخزين الكائنات، قدمتها أمازون في الأصل. تقوم خدمة متوافقة مع S3 بتخزين البيانات ككائنات داخل حاوية تخزين، وتتيح إجراء العمليات من خلال واجهات برمجة تطبيقات تعتمد على بروتوكول HTTP. يستخدم ownCloud Infinite Scale s3ngبرنامج تشغيل التخزين لوضع ملفات ثنائية كبيرة (blobs) في هذه الحاوية.

يشير تخزين POSIX إلى نظام ملفات يوفر سلوك نظام الملفات الذي تتوقعه Infinite Scale للبيانات الوصفية. مع هذا النظام s3ng، لا تُنقل البيانات الوصفية إلى حاوية S3. تُوثّق ownCloud صراحةً أن الكائنات الثنائية الكبيرة (blobs) تُنقل إلى S3 بينما تبقى البيانات الوصفية على تخزين POSIX.

يمنع هذا التمييز خطأً شائعاً: توجيه Infinite Scale إلى حاوية تخزين والافتراض بأن حالة الخادم بأكملها موجودة هناك. هذا غير صحيح. يجب أن تشمل خطة النسخ الاحتياطي والاستعادة بيانات التعريف الخاصة بنظام POSIX وبيانات الكائنات الثنائية الكبيرة (blobs) الخاصة بـ S3.

الخطوة 1: تجهيز الحاوية، وتخزين البيانات الوصفية، وبيانات الاعتماد، ومسار الشبكة

قبل تغيير Infinite Scale، جهّز أربعة أشياء:

• حاوية S3 مخصصة.
• مسار متوافق مع معيار POSIX s3ngللبيانات الوصفية. بالنسبة للنشر متعدد العقد، توصي ownCloud بالتفكير ملياً في التخزين المشترك؛ ويُستخدم نظام ملفات الشبكة (NFS) عادةً عندما تحتاج عدة مثيلات من Infinite Scale إلى الوصول إلى مسار البيانات الوصفية.
• مفتاح وصول ومفتاح سري مع أذونات الوصول المطلوبة فقط من قبل Infinite Scale.
• إمكانية الوصول إلى الشبكة من مضيف أو حاوية Infinite Scale إلى نقطة نهاية S3، عادةً عبر HTTPS.

لا تجعل الحاوية عامة. يستخدم Infinite Scale بيانات اعتماد للتحقق من هوية الحاوية؛ لذا فإن الوصول العام ليس مطلوبًا ولا مرغوبًا فيه. تجنب أيضًا إعادة استخدام بيانات اعتماد المسؤول العامة عندما يكون من الممكن إنشاء هوية خدمة مخصصة.

إذا كنت تستخدم خدمة Amazon S3، فإن نقطة النهاية والمنطقة تتبعان معايير AWS. أما إذا كنت تستخدم موفر خدمة آخر متوافق مع S3، فتأكد من تنسيق نقطة النهاية، وسلوك المنطقة، ومتطلبات TLS، وبنية السياسة في وثائق ذلك الموفر. وتحذر ownCloud تحديدًا من أن بعض السلوكيات، مثل تفاصيل التشفير، قد تختلف بين الموفرين.

الخطوة الثانية: قم بتفعيل برنامج تشغيل S3ng وقم بتوفير إعدادات اتصال S3

إعدادات التخزين الأساسية هي STORAGE_USERS_DRIVER=s3ng. خدمة Storage-Users هي مكون Infinite Scale المسؤول عن تخزين ملفات المستخدم. كما يُبقي التكوين الرسمي برنامج تشغيل تخزين النظام على ocisالواجهة الخلفية العادية.

تبدو مجموعة المتغيرات البيئية الدنيا على النحو التالي:

STORAGE_USERS_DRIVER=s3ng
STORAGE_USERS_S3NG_ROOT=/var/lib/ocis/storage/users
STORAGE_SYSTEM_DRIVER=ocis

STORAGE_USERS_S3NG_ENDPOINT=https://s3.example.com
STORAGE_USERS_S3NG_REGION=us-east-1
STORAGE_USERS_S3NG_ACCESS_KEY=YOUR_ACCESS_KEY
STORAGE_USERS_S3NG_SECRET_KEY=YOUR_SECRET_KEY
STORAGE_USERS_S3NG_BUCKET=ocis-files

القيم المذكورة هي قيم افتراضية. استخدم نقطة النهاية والمنطقة والمجموعة وبيانات الاعتماد الصادرة من مزود الخدمة. لا تقم بتحميل المفتاح السري إلى مستودع Git عام. في إدارة الحاويات، يُفضل استخدام آلية إدارة الأسرار الخاصة بالمنصة بدلاً من تضمين بيانات الاعتماد مباشرةً في ملف Compose أو ملف البيان.

تحدد طريقة النشر مكان وضع هذه المتغيرات. ففي نشر Docker Compose، قد تُوضع ضمن environmentقسم خدمة Infinite Scale أو تُحمّل من ملف بيئة. أما في نشر systemd، فيمكن استخدام ملف بيئة أو إعدادات الوحدة. بينما في Kubernetes، تُضاف هذه المتغيرات عادةً عبر Secret وDeployment أو StatefulSet. أسماء المتغيرات هي الجزء المهم، أما الصيغة المحيطة بها فتعتمد على منصتك.

الخطوة 3: منح أذونات الوصول إلى الحاوية التي تحتاجها Infinite Scale

سياسة الحاوية هي قاعدة من قواعد إدارة الهوية والوصول (IAM) تتحكم في الإجراءات التي يمكن للهوية المُصادق عليها تنفيذها على الحاوية وكائناتها. ينشر ownCloud نمط سياسة مطلوبًا لبرنامج s3ngالتشغيل.

استبدل bucket-nameفي السياسة التالية اسم حاوية التخزين الحقيقية الخاصة بك:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::bucket-name"]
    },
    {
      "Sid": "ActionsInBucketContext",
      "Effect": "Allow",
      "Action": [
        "s3:*Object",
        "s3:*MultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": ["arn:aws:s3:::bucket-name/*"]
    }
  ]
}

لا تحلّ مشكلة رفض الوصول بمنح الصلاحيات s3:*لجميع الحاويات في الحساب. ابدأ بالأذونات الموثقة الخاصة بالحاويات، ثم عدّلها فقط عندما يتطلب موفر خدمة S3 الخاص بك أذونات مكافئة خاصة به.

الخطوة الرابعة: أعد تشغيل برنامج Infinite Scale وتحقق من مسار التخزين

طبّق الإعدادات باستخدام إجراء إعادة التشغيل المعتاد لبيئة النشر الخاصة بك. على سبيل المثال، قد يستخدم تثبيت systemd إجراءً معينًا systemctl restart ocis، بينما يقوم نشر Compose بإعادة إنشاء حاويات الخدمة المتأثرة أو إعادة تشغيلها. تحقق من السجلات فور بدء التشغيل بحثًا عن أخطاء المصادقة، أو DNS، أو TLS، أو المنطقة، أو الأذونات.

يُثبت عرض قائمة الحاويات باستخدام واجهة سطر الأوامر لمزود خدمة S3 أن المضيف وبيانات الاعتماد يمكنهما الوصول إلى الحاوية، ولكنه لا يُثبت بحد ذاته أن Infinite Scale يكتب البيانات الثنائية الكبيرة (blobs) بشكل صحيح. يُعدّ الاختبار الشامل الأفضل هو تشغيل Infinite Scale، وتحميل ملف صغير عبر واجهة الويب الخاصة بـ ownCloud، ثم تنزيله مرة أخرى، ومراجعة سجلات الخدمة بحثًا عن أي أخطاء.

إذا كان إصدار Infinite Scale المُثبّت لديك يتضمن أمر صيانة مخزن البيانات الثنائية الكبيرة (blobstore) الموثّق من قِبل ownCloud، فيمكنك استخدامه أيضًا ocis storage-users blobstore check. يصف ownCloud هذا الأمر بأنه عملية تحميل/تنزيل/حذف ذهابًا وإيابًا لمخزن البيانات الثنائية الكبيرة المُكوّن. راجع وثائق التحقق الرسمية من مخزن البيانات الثنائية الكبيرة لمعرفة الصيغة الخاصة بالإصدار.

لا تتوقع ظهور أسماء الملفات الأصلية ككائنات S3 عادية

من أكثر المفاهيم الخاطئة شيوعًا هو تصفح حاوية التخزين وتوقع وجود بنية مجلدات مألوفة للمستخدم، مثل `<اسم المجلد>` Documents/report.pdf. تتعامل Infinite Scale مع S3 كمخزن للكائنات الثنائية الكبيرة (blobs)، وليس كنظام ملفات موجه للمستخدم. s3ngيعتمد تنسيق المفتاح الموثق على معرّفات المساحة ومعرّفات الكائنات الثنائية الكبيرة، بينما يُعاد بناء مساحة الاسم المقروءة من البيانات الوصفية.

هذا يعني أنه لا ينبغي عليك إعادة تسمية أو تنظيم أو حذف العناصر داخل الحاوية يدويًا لمجرد أن مفاتيحها تبدو غير مألوفة. يمكنك إدارة ملفات المستخدم من خلال ownCloud. قد يؤدي التلاعب المباشر بالحاوية إلى قطع العلاقة بين البيانات الوصفية والكائنات الثنائية الكبيرة.

التحميلات الكبيرة: تحقق من حجم الجزء متعدد الأجزاء قبل الإنتاج

تستخدم خدمة S3 خاصية التحميل متعدد الأجزاء لتقسيم الملفات الكبيرة إلى أجزاء. يوفر ownCloud وثائق STORAGE_USERS_S3NG_PUT_OBJECT_PART_SIZEللتحكم في حجم الجزء. القيمة الافتراضية الموثقة هي 16 ميجابايت عند عدم تحديد قيمة صريحة.

تسمح خدمة Amazon S3 بحد أقصى 10,000 جزء في عملية تحميل متعددة الأجزاء. وبحجم جزء يبلغ 16 ميجابايت، يُعادل ذلك تقريبًا 160 جيجابايت قبل أن يُصبح حد عدد الأجزاء مشكلة. إذا كان المستخدمون لديك يُحمّلون بانتظام ملفات كبيرة، فاحسب حجم الجزء المطلوب قبل بدء التشغيل بدلًا من انتظار فشل عملية نقل كبيرة.

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

المشاكل الشائعة وما يجب فحصه أولاً

قم بعمل نسخة احتياطية من كائنات S3 الثنائية وبيانات POSIX الوصفية معًا

مع ذلك s3ng، لا يمثل المخزن سوى نصف حالة التخزين. تشير وثائق النسخ الاحتياطي الخاصة بـ ownCloud إلى أن إعداد S3 الموزع يجب أن يشمل التكوين، وبيانات النظام، والبيانات الوصفية، والكائنات الثنائية الكبيرة (blobs). وبالمثل، تتطلب وثائق الاستعادة استعادة مجموعات البيانات هذه بشكل متسق.

بالنسبة لخدمة الإنتاج، وثّق عملية ربط البيانات الوصفية، ومخزن البيانات، وبيانات الاعتماد أو الدور، وملفات التكوين، وإجراءات النسخ الاحتياطي في نفس دليل التشغيل. اختبر عملية الاستعادة قبل الاعتماد على التصميم. المراجع الرسمية ذات الصلة هي دليل النسخ الاحتياطي واعتبارات الاستعادة الخاصة بـ ownCloud .

نقطة البداية الموصى بها

بالنسبة للنشر الأول، حافظ على التصميم بسيطًا: استخدم حاوية S3 مخصصة واحدة للكائنات الثنائية الكبيرة، ومسار بيانات تعريف POSIX ثابت واحد، وهوية خدمة مخصصة مع أذونات الحاوية الموثقة، وHTTPS لنقطة نهاية تخزين الكائنات، وإعدادات multipart الافتراضية ما لم تتطلب أحجام الملفات المتوقعة تغييرًا.

بعد إتمام عملية التهيئة، تحقق من صحة ثلاث طبقات بشكل منفصل: الوصول إلى الشبكة وبيانات الاعتماد الخاصة بالمخزن، وبدء تشغيل Infinite Scale دون أخطاء في التخزين، وعملية تحميل/تنزيل فعلية عبر ownCloud. بمجرد اجتياز هذه الاختبارات، انتقل إلى المراقبة، والنسخ الاحتياطي، وقواعد دورة الحياة، وتحسين الأداء. هذا التسلسل يُسهّل عملية استكشاف الأخطاء وإصلاحها بشكل كبير، لأن كل اختبار يُجيب على سؤال مختلف بدلاً من اعتبار "S3 يعمل" نتيجةً واحدةً شاملةً أو غير شاملة.