استضافة Moodle للتعليم: منصة تدريب لا تسقط يوم الاختبار
منصة Moodle تنجح أو تسقط بحسب استعدادها للذروة المتزامنة يوم الاختبار. تعرف على المواصفة لكل 100 و500 و1000 متعلم متزامن، ولماذا PHP OPcache وRedis للجلسات هما الفرق بين نظام صامد ونظام يتجمّد.
منصة Moodle لا تُختبر في يوم عادي بل في يوم الاختبار، حين يدخل مئات المتعلمين في نفس الدقيقة. القاعدة العملية أن كل مئة متعلم متزامن يحتاجون نحو نواتين معالج وأربعة إلى ستة جيجابايت رام على خادم مضبوط، فخمسمئة متزامن يحتاجون من ستة إلى ثمانية أنوية واثني عشر جيجابايت رام فأكثر، وألف متزامن يبدأون من فصل قاعدة البيانات على خادم مستقل مع خادم تطبيق قوي. الفرق الحاسم ليس في حجم الباقة وحده بل في ثلاث ضبطات: تفعيل PHP OPcache لتخزين الكود المترجم فيقلّ حمل المعالج بنسبة تتجاوز 50%، ونقل الجلسات إلى Redis بدل ملفات القرص فتتحمّل المنصة الذروة، وضبط قاعدة البيانات MariaDB لتخديم الاستعلامات المتكررة من الذاكرة. الاستضافة داخل السعودية تعطي زمن استجابة نحو 8ms من الرياض، وهذا يعني أن فتح صفحة الاختبار وحفظ الإجابة يحدثان فوراً لا بعد تأخير يقلق الطالب. أضف نسخة احتياطية مجدولة قبل بداية كل فصل دراسي، وبقاء بيانات الطلاب على سيرفر سعودي احتراماً لسيادة البيانات، فتحصل على منصة تدريب تصمد يوم الحاجة.
نمط الحمل التعليمي مختلف تماماً
أغلب المواقع تتلقى زيارات موزّعة على اليوم، أما منصة التعلّم فحملها متكتّل في ذُرى حادة. قبل الاختبار بدقائق يفتح الطلاب الصفحة دفعة واحدة، وعند انتهاء الوقت يضغط الجميع زر التسليم في ثوانٍ متقاربة. هذا النمط يعني أن متوسط الحمل اليومي مضلّل تماماً، فالخادم قد يعمل بنسبة 10% طوال اليوم ثم يقفز إلى 100% لعشر دقائق. تصميم المواصفة على المتوسط كارثة، والصحيح تصميمها على الذروة المتوقعة زائد هامش أمان 30%.
هناك فرق بين المتعلم المسجّل والمتعلم المتزامن. جامعة فيها عشرة آلاف طالب قد لا يتجاوز متزامنها وقت أكبر اختبار ألفاً وخمسمئة. احسب الذروة من أكبر اختبار متوقع في نفس اللحظة لا من إجمالي المسجّلين، فهذا يوفّر عليك شراء موارد لا تُستخدم إلا نظرياً.
المواصفة لكل حجم بالأرقام
الجدول التالي يربط عدد المتعلمين المتزامنين بباقات كلاود، مع الضبطات الإلزامية لكل مستوى:
| المتزامن | الباقة | إضافات مقترحة | ضبط إلزامي | التكلفة السنوية التقريبية |
|---|---|---|---|---|
| حتى 100 | أعمال 4vCPU/8GB | نسخ احتياطي يومي 30 يوماً (2,000) | OPcache + Redis جلسات | نحو 13,500 ريال |
| حتى 500 | مؤسسة 8vCPU/16GB | +4GB RAM (1,200) + نسخ يومي (2,000) | OPcache + Redis + ضبط MariaDB | نحو 21,200 ريال |
| حتى 1000 | مؤسسة + قاعدة بيانات على خادم ثانٍ | خادم DB نمو + نسخ يومي + DDoS (1,200) | فصل الطبقات + Redis كاش | نحو 29,000 ريال |
الأسعار سنوية شاملة ضريبة القيمة المضافة 15%. باقة أعمال تبدأ من 11,500 ريال ومؤسسة من 18,000، مع تفعيل تلقائي خلال ثوانٍ. راجع التفاصيل في صفحة الأسعار والباقات أو ابدأ التخصيص من صفحة الخادم السحابي. لاحظ أن إضافة الرام عندنا +2GB بـ600 ريال، فأربعة جيجابايت تكلّف 1,200 ريال سنوياً، وإضافة نقل البيانات +1TB بـ1,150 ريالاً إن كانت منصتك تبثّ فيديو تعليمياً كثيفاً.
PHP OPcache: أول ضبطة تفعلها
Moodle تطبيق PHP ضخم فيه آلاف الملفات، وبدون OPcache يعيد المعالج ترجمة الكود مع كل طلب، وهذا هدر صريح. تفعيل OPcache يخزّن الكود المترجم في الذاكرة فينخفض استهلاك المعالج بنسبة تتجاوز النصف تحت الحمل. القيم المقترحة: opcache.memory_consumption بين 256 و512 ميجابايت لمنصة كبيرة، وopcache.max_accelerated_files عند 20000 على الأقل لأن ملفات Moodle كثيرة، وopcache.validate_timestamps مطفأة في الإنتاج مع مسح الكاش يدوياً عند التحديث. هذه الضبطة وحدها قد تضاعف قدرة نفس السيرفر على استيعاب المتزامن.
Redis للجلسات: الفرق يوم الذروة
افتراضياً تخزّن Moodle جلسات المستخدمين كملفات على القرص، وهذا يصبح عنق زجاجة قاتلاً حين يدخل خمسمئة طالب في دقيقة، لأن كل طلب يقفل ملف الجلسة ويفتحه. نقل الجلسات إلى Redis يجعلها في الذاكرة فتُخدّم في أجزاء من الميلي ثانية، ويحل مشكلة تعارض الأقفال تماماً. استخدم Redis أيضاً كطبقة كاش للتطبيق (Application Cache) فتخفّف الضغط عن قاعدة البيانات بشكل كبير. Redis خفيف ويعمل على نفس الخادم للأحجام المتوسطة، ويُنقل لخادم مستقل عند الألف متزامن.
ضبط قاعدة البيانات MariaDB
قاعدة البيانات هي المورد الأول الذي ينهار يوم الاختبار إن أُهملت. أهم قيمة هي innodb_buffer_pool_size التي يُفضّل أن تساوي 60% إلى 70% من رام خادم قاعدة البيانات، فتُخدّم الاستعلامات المتكررة من الذاكرة لا من القرص. اضبط أيضاً:
- innodb_buffer_pool_size = نحو 10GB على خادم بستة عشر جيجابايت رام.
- innodb_log_file_size = من 512 ميجابايت إلى 1 جيجابايت لتحمّل موجات الكتابة وقت التسليم.
- max_connections = 300 إلى 500 حسب المتزامن المتوقع.
- tmp_table_size وmax_heap_table_size = 128 ميجابايت لتقليل الجداول المؤقتة على القرص.
عند الألف متزامن، افصل قاعدة البيانات على خادم مستقل حتى لا يتنافس التطبيق والقاعدة على نفس الأنوية والذاكرة. هذا الفصل هو أكبر قفزة أداء بعد OPcache وRedis.
النسخ الاحتياطي قبل الفصول وسيادة البيانات
خطأ التحديث الفاشل أو الحذف العرضي يحدث دائماً في أسوأ توقيت. فعّل النسخ الاحتياطي اليومي بثلاثين يوم احتفاظ، وخذ نسخة يدوية إضافية قبل بداية كل فصل دراسي وقبل أي تحديث لإصدار Moodle. النسخة تشمل قاعدة البيانات ومجلد moodledata معاً لأن استرجاع أحدهما دون الآخر لا ينفع. أما سيادة البيانات فمسألة جدية في التعليم: بيانات الطلاب ودرجاتهم ومعلوماتهم الشخصية يجب أن تبقى على سيرفر سعودي، وزمن الاستجابة نحو 8ms من الرياض يجعل التجربة سلسة للطالب والمعلم على حد سواء. إن كنت تشغّل أدوات ذكاء اصطناعي مساعدة للتصحيح أو التلخيص، فصفحة استضافة الذكاء الاصطناعي تعطيك قالباً جاهزاً على نفس البنية السعودية.
المحتوى الثابت وضبط المهام المجدولة
جزء كبير من حمل منصة Moodle ليس صفحات ديناميكية بل ملفات ثابتة: صور الدروس، ملفات PDF، مقاطع فيديو، وملفات JavaScript وCSS. تخديم هذه الملفات مباشرة من خادم الويب دون المرور بمعالجة PHP يخفّف الحمل كثيراً، لذا فعّل التخزين المؤقت للمتصفح (browser caching) عبر ترويسات الاستجابة بمدة صلاحية طويلة للملفات الثابتة، فيحمّلها الطالب مرة واحدة ثم تُخدّم من متصفحه في الزيارات التالية. إذا كانت منصتك تبثّ فيديو تعليمياً كثيفاً، فراقب استهلاك نقل البيانات، وإضافة النقل عندنا +1TB بـ1,150 ريالاً سنوياً تكفي أغلب المنصات المتوسطة.
المهام المجدولة (cron) في Moodle مسألة حساسة تُغفل كثيراً. Moodle يعتمد على تشغيل cron كل دقيقة لإرسال الإشعارات، ومعالجة قوائم الانتظار، وتحديث الفهارس، وتصحيح المهام المؤجلة. إذا لم يعمل cron بانتظام، تتراكم المهام وتظهر مشاكل غامقة يوم الاختبار مثل عدم إرسال إشعارات أو تأخر ظهور الدرجات. اضبط cron على التشغيل كل دقيقة بالضبط، وخصّص له موارد كافية بحيث لا يتنافس مع طلبات المستخدمين وقت الذروة. عند الأحجام الكبيرة، وجّه معالجة المهام الثقيلة (مثل توليد التقارير أو النسخ الاحتياطي) إلى ساعات الليل بعيداً عن أوقات الاختبارات، فتبقى الموارد كاملة للطلاب نهاراً. راقب أيضاً سجل مهام cron من لوحة إدارة Moodle، فإذا رأيت مهمة تستغرق وقتاً طويلاً بشكل غير معتاد فهي مؤشر على استعلام بطيء في قاعدة البيانات يستحق الفحص قبل أن يتفاقم يوم الذروة.
قائمة تحقق قبل يوم الاختبار
اختر الباقة حسب أكبر اختبار متزامن متوقع لا إجمالي الطلاب، وأضف هامش 30%. فعّل OPcache وانقل الجلسات إلى Redis قبل أي شيء آخر، فهما أرخص من ترقية الباقة وأكثر أثراً. اضبط MariaDB بقيم buffer pool أعلاه، وأجرِ اختبار حمل تجريبياً بعدد متزامن قريب من الذروة قبل الاختبار الحقيقي بأسبوع. خذ نسخة احتياطية يدوية صباح يوم الاختبار. عند تجاوز خمسمئة متزامن بثبات، افصل قاعدة البيانات على خادم مستقل من صفحة الخادم السحابي. راجع أيضاً إعدادات مهلة الجلسة حتى لا تُطرد جلسات الطلاب أثناء اختبار طويل، فطرد جلسة في منتصف الاختبار كارثة يمكن تفاديها بضبط بسيط. الخلاصة: صمّم على الذروة، وفعّل الكاش، وافصل الطبقات عند الكبر.
