البحث في الموقع

تتراكم البرامج والملفات الخاصة بالمستخدمين مع الزمن ضمن أي نظام تشغيل وحتى عندما يقوم المستخدم بإزالة بعض البرامج فقد تبقى عدة ملفات عالقة للأبد ضمن ملفات نظام التشغيل. يمكن للمستخدم الذي يمتلك مساحات تخزينية تفوق التيرا بايت Tera Byte أن يتجاهل هذه التراكمات، أما المستخدم الذي يمتلك قرصًا صلبًا من نوع SSD والذي يكون عادة بسعات منخفضة فقد يضطر إلى إزالة هذه التراكمات بشكل دوري. يتضمن هذا المقال أبسط الطرق الذي يستطيع المستخدم تنفيذها لتحرير المساحة ضمن توزيعة أوبونتو Ubuntu ويجب على المستخدم مراقبة المساحة الحرة ضمن جهازه باستمرار ليختار الوقت المناسب لتحرير المساحة. فحص المساحة الحرة ضمن توزيعة أوبونتو يستطيع المستخدم التحقق من المساحة الحرة المتبقية على حاسبه الشخصي باستخدام أداة تحليل استخدام القرص Disk Usage Analyzer المتاحة بشكل افتراضي ضمن توزيعة أوبونتو. يمكن البحث عن هذه الأداة ضمن القائمة الرئيسية وبعد تشغيلها يظهر القرص الصلب والمساحة الحرة المتبقية. يستطيع المستخدم البدء بتحرير المساحة عندما تبلغ المساحة المتبقية من القرص الحد الذي يراه مناسبًا ويمكن بعد الانتهاء من عملية التحرير إعادة تفقد المساحة باستخدام نفس الأداة. تحرير مساحة القرص ضمن توزيعتي أوبونتو و لينكس مينت توجد عدة طرق لتحرير مساحة القرص الصلب ضمن توزيعة أوبونتو أو أنظمة التشغيل المبنية على أوبونتو. منها ما يكون عن طريق تنفيذ الأوامر النصية ومنها ما يكون متاحًا باستخدام أدوات ذات واجهات رسومية. تجدر الإشارة إلى أنه من الأفضل أن يتجنب المستخدم العادي تنفيذ بعض العمليات التي لا يتقنها بشكل جيد تجنبًا لأية ضرر يمكن أن يصيب الحاسب. يتم الاعتماد على نسخة أوبنتو 16.04 في هذا المقال ولكن تبقى الخطوات ذاتها من أجل أوبونتو 18.04 وإصدارات أوبونتو المختلفة كما تنطبق هذه التعليمات على الأنظمة المعتمدة على أوبونتو مثل مينت وغيرها. 1. التخلص من الحزم غير المستخدمة قد تحتاج حزمة ما يقوم المستخدم بتثبيتها إلى تثبيت مجموعة من الحزم الضرورية لعملها، تظهر مشكلة عندما يتم إزالة هذه الحزمة دون أن تتم إزالة الحزم المرتبطة بها مما يؤدي إلى تراكمها واستهلاكها لمساحة تخزينية دون جدوى. وجدنا في [نضع هنا رابط المقالة رقم 7](رابط المقالة رقم 7) أنه يمكن استخدام الأمر apt-get الذي يستخدم لتثبيت الحزم من أجل إزالة الرزم عن طريق الأمر autoremove والذي يزيل هذه الرزم العالقة كما أنه يزيل أي نسخ قديمة من نواة نظام التشغيل لينكس والتي يمكن أن تصبح بلا فائدة بعد ترقية النظام. يتم ذلك عبر تنفيذ الأمر التالي في موجه الأوامر وبالطبع فإننا نحتاج إلى صلاحيات مناسبة لتنفيذ عمليات الحذف هذه: sudo apt-get autoremove يظهر الشكل أدناه أنه سيتم تحرير مساحة تعادل 300 ميغابايت من القرص الصلب بعد نجاح تنفيذ هذه العملية ويمكن أن تكون هذه المساحة أكبر وذلك تبعا لطريقة استخدام الحاسب والفترة الزمنية المنقضية منذ آخر عملية تحرير مساحة تم تنفيذها. 2. إزالة التطبيقات غير الضرورية توجد العديد من التطبيقات الموجودة بشكل افتراضي ضمن توزيعة أوبونتو، وقد تمر سنين دون أن يستخدمها أحد وخصوصًا الألعاب وبعض التطبيقات الإضافية وبالتالي يمكن إزالتها. كما ينطبق ذلك على بعض التطبيقات التي ثبّتها المستخدم واستخدمها مرة واحدة ونسي استخدامها أو أنه لم يعد بحاجتها لذلك يجب إزالة هذه التطبيقات إما بالاعتماد على مركز البرمجيات Software Center أو باستخدام موجه الأوامر وتنفيذ الأمر التالي: sudo apt-get remove package-name1 package-name2 3. تنظيف الذاكرة المخبئية Cache الخاصة بالأداة APT تستخدم توزيعة أوبونتو الأداة APT من أجل تثبيت وإدارة وإزالة الحزم البرمجية. تحتفظ هذه الأداة بنسخة من الحزم البرمجية التي تم تحميلها وتثبيتها مسبقًا حتى بعد أن تتم إزالة هذه الحزم البرمجية من النظام. يتم تخزين هذه الحزم ضمن المسار ‎/var/cache/apt/archives. يزداد حجم هذا المجلّد مع الزمن ويمكن التحقق من حجمه عبر تنفيذ الأمر: sudo du -sh /var/cahce/apt يظهر الشكل أنه تم إشغال حوالي 500 ميغابايت من القرص في المجلّد السابق ويجب تحرير هذه المساحة. يمكن تحرير هذه المساحة بطريقتين، إما عن طريق إزالة الرزم التي أصبحت قديمة جدًا والتي لا يمكن إعادة استخدامها بعد اعتماد تحديث ما مما يجعلها بلا قيمة ويتم ذلك بتنفيذ الأمر: sudo apt-get autoclean أو عبر حذف كامل هذه المساحة التخزينية مما يوفر الكثير من المساحة ولكنه قد يجبر المستخدم على تنزيل بعض الحزم البرمجية في حال احتاجها مرة ثانية في حال لم تكن هذه الحزم قديمة ويتم ذلك بتنفيذ الأمر: sudo apt-get clean 4. تفريغ ملفات السجلات ملاحظة: هذه الخطوة تتطلب معرفة متقدمة. تتضمن جميع توزيعات لينكس آليات تسجيل لحفظ جميع العمليات والقيم التي تتغير ضمن النظام. نجد سجلًا خاصًا بنواة نظام التشغيل وسجلًا خاصًا برسائل النظام وسجلًا يحتوي على الأخطاء الخاصة بجميع الخدمات التي تعمل ضمن نظام لينكس سواء كانت من ضمن نظام التشغيل أو أن المستخدم ثبتها على النظام. يزداد حجم هذه السجلات بسرعة كبيرة، إذ تسجّل هذه القيم دون توقف مما يجعل حجم هذه السجلات كبيرًا ويمكن الاطلاع على هذا الحجم عن طريق تنفيذ: journalctl --disk-usage تجدر الإشارة إلى أنه على عكس الحزم فلا يجب حذف جميع السجلات ويجب الاحتفاظ ببعضها لذلك من الشائع أن يحتفظ المستخدم بالسجلات التي لم يمض عليها زمن طويل، يتم تنفيذ الأمر أدناه لإزالة السجلات التي تتضمن المعطيات المتعلقة بالأداء منذ أكثر من ثلاث أيام: sudo journalctl --vacuum-time=3d يظهر الخرج أدناه بعد تنفيذ الأمر السابق: abhishek@itsfoss:~$ journalctl --disk-usage Archived and active journals take up 1.8G in the file system. abhishek@itsfoss:~$ sudo journalctl --vacuum-time=3d Vacuuming done, freed 1.7G of archived journals from /var/log/journal/1b9ab93094fa2984beba73fd3c48a39c 5. إزالة النسخ القديمة من التطبيقات المثبّتة باستخدام مدير الحزم Snap ملاحظة: هذه الخطوة تتطلب معرفة متقدمة. يتيح مدير الحزم Snap الكثير من التطبيقات التي تفيد المستخدمين ولهذا يكون لها شعبية كبيرة مقارنة بمدراء الحزم التقليديين، تكمن المشكلة الأساسية أنّ الحزم المثبّتة عن طريق مدير الحزم Snap تكون أكبر حجمًا من غيرها ومما يزيد من حجم المشكلة أن مدير الحزم Snap يحتفظ بنسختين على الأقل من نفس الحزمة التي يتم تثبيتها وذلك في حال رغب المستخدم العودة إلى نسخة أقدم من نفس الحزمة، نستعرض المساحة التي تستهلكها هذه الأداة عبر تنفيذ الأمر التالي ويظهر الخرج المبين أدناه بعد تنفيذها du -h /var/lib/snapd/snaps 4.0K /var/lib/snapd/snaps/partial 5.6G /var/lib/snapd/snaps نلاحظ أن المساحة المشغولة وصلت إلى خمسة غيغابايت وهذه المساحة كبيرة نسبيًا. مع تفاقم هذه المشكلة عمد أحد المطورين العاملين ضمن فريق تطوير مدير حزم Snap وهو آلان بوب إلى تطوير سكربت Script بسيط يزيل النسخ القديمة من التطبيقات المثبّتة باستخدام مدير الحزم Snap. ننشئ ملف نص برمجي ونضع فيه المحتوى التالي: #!/bin/bash # Removes old revisions of snaps # CLOSE ALL SNAPS BEFORE RUNNING THIS set -eu snap list --all | awk '/disabled/{print $1, $3}' | while read snapname revision; do snap remove "$snapname" --revision="$revision" done يجب إضافة الصلاحيات التنفيذية المناسبة لملف النص البرمجي السابق وتشغيله مع صلاحيات مدير باستخدام sudo. يتم تحرير المساحة المحجوزة التي يمكن تحريرها ونستعرض المساحة بنفس الطريقة السابقة ليكون الخرج بالشكل التالي: du -h /var/lib/snapd/snaps 4.0K /var/lib/snapd/snaps/partial 2.5G /var/lib/snapd/snaps فصلنا أكثر عن هذه الخطوة في مقال مسح حزم Snap المعطلة لتحرير المساحة في لينكس. 6. إزالة الذاكرة الوسيطة الخاصة بالصور المصغّرة thumbnail ملاحظة: هذه الخطوة تتطلب معرفة متقدمة. تنشئ توزيعة أوبونتو صور مُصغَّرة خاصة بالعرض ويخزنها في مجلّد مخفي ضمن المساحة التخزينية الخاصة بالمستخدم وهو ‎~/.cache/thumbnails. يزداد عدد هذه المصغّرات مع الزمن وبالتالي يزداد حجمها مع العلم بأن بعض هذه المصغرات تعود لصور لم تعد موجودة ولهذا يجب إزالتها. يمكن التحقق من حجم الذاكرة الوسيطة الخاصة بالمصغرات عبر تنفيذ الأمر التالي: du -sh ~/.cache/thumbnails يبين الشكل التالي نتيجة تنفيذ هذا الأمر: يفضل تحرير هذه المساحة كل بضعة أشهر ويمكن ذلك بتنفيذ الأمر التالي: rm -rf ~/.cache/thumbnails/* 7. إيجاد وحذف الملفات المتكررة يمكن أن تتكرر الملفات دون إدراك المستخدم وفي حال كانت هذه الملفات ذات حجوم كبيرة كملفات الفيديو أو الصور عالية الدقة فسوف يستهلك ذلك مساحة كبيرة ولهذا يمكن البحث عن هذه الملفات المكررة وإزالتها. يمكن تنفيذ ذلك باستخدام الأداة ذات الواجهات الرسومية FSlint أو باستخدام الأداة FDUPES التي تعمل ضمن موجه الأوامر والتي يبين الشكل أدناه مثالًا على عملها. يمكن للخبراء تنفيذ بعض الخطوات الإضافية لتحرير المزيد من المساحة، ولا يعني ربط الخطوات التالية بالخبراء أن المستخدم العادي لا يجب أن يحاول تنفيذ هذه الخطوات ولكن من الأفضل أن يكون حذرًا وأن يحتفظ بنسخة احتياطية لملفاته المهمة. 8. إزالة نوى لينكس القديمة التي تم تثبيتها بشكل يدوي ملاحظة: هذه الخطوة تتطلب خبرة متقدمة. ناقشنا في الخطوة رقم 1 السابقة استخدام أمر لإزالة نواة نظام لينكس القديمة ولكن يجب الانتباه أنّ هذا الأمر لا يزيل نواة لينكس التي يثبتها المستخدم بشكل يدوي وإنما فقط يزيل ما ثبّته النظام تلقائيًا. تحرر عملية الإزالة هذه الكثير من المساحة وللتحقق من وجود هذه النوى على الجهاز يمكن تنفيذ الأمر التالي: sudo dpkg --list 'linux-image*' لا تختلف إزالة نواة نظام التشغيل عن إزالة أية حزمة برمجية، فبعد أن يظهر الأمر السابق النوى المتاحة يتم تسجيل رقم الإصدار VERSION الذي يجب إزالته وننفذ الأمر التالي: sudo apt-get remove linux-image-VERSION يوصي الخبراء أن يحافظ المستخدم على نسختين أو ثلاث من نوى نظم التشغيل ومن ضمنه أحدث نسخة للنواة مما يتيح العودة إلى نسخة أقدم من النواة في حال ظهور مشكلة ضمن النواة الجديدة. 9. إزالة الحزم اليتيمة ملاحظة: هذه الخطوة تتطلب خبرة متقدمة. نعرّف الحزم اليتيمة على أنّها الحزم التي يتم تثبيتها ضمن النظام لكونها متطلّبًا لحزمة أساسية أخرى وقد حذف المستخدم هذه الخدمة الأساسية وبقيت الحزمة اليتيمة ضمن النظام. وجدنا في الخطوة رقم 1 أنه يمكن تنفيذ أمر لإزالة هذه الحزم ولكن تكمن المشكلة الأساسية إذا ثبت المستخدم هذه الحزم المكمّلة لحزمة ما بشكل يدوي وبالتالي لن يستطيع الأمر السابق إزالتها لأنه لا يستطيع الجزم بأن المستخدم ثبت هذه الحزمة لحاجته لها أم أنها كانت متطلّبًا لحزمة أخرى فيضطر إلى تجاوزها. يجب أن يبحث المستخدم عن هذه الحزم بشكل يدوي ولكن لحسن الحظ توجد عدة أدوات منها ما يمتلك واجهات رسومية مثل gtkorphan والتي تساعد في العثور على الحزم اليتيمة. يتم تثبيت هذه الأداة بتنفيذ الأمر التالي: sudo apt-get install gtkorphan يبين الشكل التالي الواجهة الأساسية للأداة وتجدر الإشارة إلى أنّ المستخدم لا يحتاج لهذه الأداة فعليًا إلا إذا كان بحاجة كل المساحة التخزينية المتاحة لسبب ما. ملاحظة: قد لا تكون الحزمة gtkorphan متوفرة أثناء قراءة المقال، لذا يمكنك استعمال البديل المناسب والمريح لك، مثل deborphan وغيرها. 10. استخدام الأدوات ذات الواجهات الرسومية لتحرير المساحة في أوبونتو توجد عدة سكربتات تستخدم لتحرير المساحة ضمن توزيعة أوبونتو وقد تم ذكر البعض منها كما توجد المزيد منها ما لم تشمله هذا المقال. يصبح تذكر الأوامر صعبًا لدى بعض المستخدمين ولهذا يمكن استخدام الأدوات ذات الواجهات الرسومية وتعد الأداة Stacer واحدة من أهم هذه الأدوات والتي تتسم بسهولة الاستخدام. الخاتمة تضمنت المقالة بعض الخطوات الأساسية لتحرير المساحة ضمن توزيعة أوبونتو والأنظمة المعتمدة عليها، حيث أنّ بعض هذه الخطوات بسيطة ويجب على جميع المستخدمين تنفيذها بشكل دوري ومنها ما يتطلب أنْ يكون المستخدم خبيرًا ويمكن تجنبها لوقت الحاجة الفعلية للمساحة ويترك تقدير ذلك للمستخدم وحاجته الفعلية للمساحة. ترجمة وبتصرف للمقال ‎7 Simple Ways to Free Up Space on Ubuntu and Linux Mint لصاحبه Abhishek Prakash. اقرأ أيضًا التعرف على اختناقات الأداء في نظام لينكس باستخدام الأدوات مفتوحة المصدر كيفية تثبيت التطبيقات في لينكس كيف تفهم هيكلية نظام الملفات في لنكس

منذ زمن سحيق، كانت الذاكرةُ أكثر وظيفة نحتاجها ونعتمد عليها في الحاسوب. ورغم اختلاف التقنيات وأساليب التنفيذ الكامنة وراءها، إلّا أنّ معظم الحواسيب تأتي بالعتاد الضروريّ لمعالجة المعلومات وحفظها بأمان لاستخدامها في المستقبل متى احتجنا لها. لقد صار من المستحيل في عالمنا الحديث تخيل أيّ عمل لا يستفيد من هذه القدرة في الأجهزة، سواء كانت خواديم أو حواسيب شخصية أو كفّيّة. تُعالَج البيانات وتُسجَّل وتُسترجَع مع كل عملية، وفي كل مكان من الألعاب إلى الأدوات المتعلقة بالأعمال، بما فيها المواقع. أنظمة إدارة قواعد البيانات (DataBase Management Systems – DBMS) هي برمجيات عالية المستوى تعمل مع واجهات برمجة تطبيقات (APIs) أدنى منها في المستوى، وتلك الواجهات بدورها تهتم بهذه العمليات. لقد تم تطوير العديد من أنظمة إدارة قواعد البيانات (كقواعد البيانات العلائقيّة relational databases، وnoSQL، وغيرها) لعقود من الزمن للمساعدة على حلّ المشكلات المختلفة، إضافة إلى برامج لها (مثل MySQL ,PostgreSQL ,MongoDB ,Redis، إلخ). سنقوم في هذا المقال بالمرور على أساسيّات قواعد البيانات وأنظمة إدارة قواعد البيانات. وسنتعرف من خلالها على المنطق الذي تعمل به قواعد البيانات المختلفة، وكيفية التفرقة بينها. أنظمة إدارة قواعد البياناتإن مفهوم نظام إدارة قاعدة البيانات مظلّةٌ تندرج تحتها كلّ الأدوات المختلفة أنواعها (كبرامج الحاسوب والمكتبات المضمّنة)، والتي غالبًا تعمل بطرق مختلفة وفريدة جدًّا. تتعامل هذه التطبيقات مع مجموعات من المعلومات، أو تساعد بكثرة في التعامل معها. وحيث أن المعلومات (أو البيانات) يُمكِن إن تأتي بأشكال وأحجام مختلفة، فقد تم تطوير العشرات من أنظمة قواعد البيانات، ومعها أعداد هائلة من تطبيقات قواعد البيانات منذ بداية النصف الثاني من القرن الحادي والعشرين، وذلك من أجل تلبية الاحتياجات الحوسبيّة والبرمجية المختلفة. تُبنى أنظمة إدارة قواعد البيانات على نماذج لقواعد البيانات: وهي بُنى محدّدة للتعامل مع البيانات. وكل تطبيق ونظام إدارة محتوى جديد أنشئ لتطبيق أساليبها يعمل بطريقة مختلفة فيما يتعلق بالتعريفات وعمليات التخزين والاسترجاع للمعلومات المُعطاة. ورغم أنّ هناك عددًا كبيرًا من الحلول التي تُنشئ أنظمة إدارة قواعد بيانات مختلفة، إلّا أنّ كلّ مدة زمنية تضمّنت خيارات محدودة صارت شائعة جدًّا وبقيت قيد الاستخدام لمدة أطول، والغالب أنّ أكثرها هيمنة على هذه الساحة خلال العقدين الأخيرين (وربما أكثر من ذلك) هي أنظمة إدارة قواعد البيانات العلائقيّة (Relational Database Management Systems – RDBMS). أنواع قواعد البياناتيستخدم كلُّ نظام إدارة بياناتٍ نموذجًا لقواعد البيانات لترتيب البيانات التي يديرها منطقيًّا. هذه النماذج (أو الأنواع) هي الخطوة الأولى والمحدّد الأهم لكيفية عمل تطبيق قواعد البيانات وكيفية تعامله مع المعلومات وتصرفه بها. هناك بعض الأنواع المختلفة لنماذج لقواعد البيانات التي تعرض بوضوع ودقّة معنى هيكلة البيانات، والغالب أن أكثر هذه الأنواع شهرةً قواعدُ البيانات العلائقيّة. ورغم أنّ النموذج العلائقيّ وقواعد البيانات العلائقيّة (relational databases) مرنة وقويّة للغاية –عندما يعلم المبرمج كيف يستخدمها–، إلّا أنّ هناك بعض المشكلات التي واجهات عديدين، وبعض المزايا التي لم تقدمها هذه الحلول. لقد بدأت حديثًا مجموعة من التطبيقات والأنظمة المختلفة المدعوّة بقواعد بيانات NoSQL بالاشتهار بسرعة كبيرة، والتي قدمت وعودًا لحل هذه المشكلات وتقديم بعض الوظائف المثيرة للاهتمام بشدّة. بالتخلص من البيانات المهيكلة بطريقة متصلّبة (بإبقاء النمط المعرّف في النموذج العلائقيّ (relational model))، تعمل هذه الأنظمة بتقديم طريقة حرّة أكثر في التعامل مع المعلومات، وبهذا توفّر سهولة ومرونة عاليتين جدًّا؛ رغم أنّها تأتي بمشاكل خاصة بها –والتي تكون بعضها جدّيّة– فيما يتعلق بطبيعة البيانات الهامّة والتي لا غنى عنها. النموذج العلائقيّيقدّم النظام العلائقيّ الذي ظهر في تسعينات القرن الماضي طريقة مناسبة للرياضيات في هيكلة وحفظ واستخدام البيانات. توسّع هذه الطريقة من التصاميم القديمة، كالنموذج المسطّح (flat)، والشبكيّ، وغيرها، وذلك بتقديمها مفهوم "العلاقات". تقدّم العلاقات فوائد تتعلق بتجميع البيانات كمجموعات مقيّدة، تربط فيها جداول البيانات –المحتوية على معلومات بطريقة منظمة (كاسم شخص وعنوانه مثلاً)– كل المدخلات بإعطاء قيم للصفات (كرقم هوية الشخص مثلًا). وبفضل عقود من البحث والتطوير، تعمل أنظمة قواعد البيانات التي تستخدم النموذج العلائقيّ بكفاءة وموثوقيّة عاليتين جدًّا. أضف إلى ذلك الخبرة الطويلة للمبرمجين ومديري قواعد البيانات في التعامل مع هذه الأدوات؛ لقد أدّى هذا إلى أن يصبح استخدام تطبيقات قواعد البيانات العلائقيّة الخيار الأمثل للتطبيقات ذات المهام الحرجة، والتي لا يمكنها احتمال فقدان أيّة بيانات تحت أيّ ظرف، وخاصة كنتيجة لخلل ما أو لطبيعة التطبيق نفسه الذي قد يكون أكثر عرضة للأخطاء. ورغم طبيعتها الصارمة المتعلقة بتشكيل والتعامل مع البيانات، يمكن لقواعد البيانات العلائقيّة أن تكون مرنة للغاية وأن تقدم الكثير، وذلك بتقديم قدر ضئيل من المجهود. التوجّه عديم النموذج (Model-less) أو NoSQLتعتمد طريقة NoSQL في هيكلة البيانات على التخلص من هذه القيود، حيث تحرر أساليب حفظ، واستعلام، واستخدام المعلومات. تسعى قواعد بيانات NoSQL إلى التخلص من العلائقات المعقدة، وتقدم أنواع عديدة من الطرق للحفاظ على البيانات والعمل عليها لحالات استخدام معينة بكفاءة (كتخزين مستندات كاملة النصوص)، وذلك من خلال استخدامها توجّها غير منظم (أو الهيكلة على الطريق / أثناء العمل). أنظمة إدارة قواعد بيانات شائعةهدفنا في هذا المقال هو أن نقدم لك نماذج عن بعض أشهر حلول قواعد البيانات وأكثرها استخدامًا. ورغم صعوبة الوصول إلى نتيجة بخصوص نسبة الاستخدام، يمكننا بوضوح افتراض أنّه بالنسبة لغالب الناس، تقع الاختيارات بين محرّكات قواعد البيانات العلائقيّة، أو محرك NoSQL أحدث. لكن قبل البدء بشرح الفروقات بين التطبيقات المختلفة لكل منهما، دعنا نرى ما يجري خلف الستار. أنظمة إدارة قواعد البيانات العلائقيّةلقد حصلت أنظمة إدارة قواعد البيانات العلائقيّة على اسمها من النموذج الذي تعتمد عليه، وهو النموذج العلائقيّ الذي ناقشناه أعلاه. إنّ هذه الأنظمة –الآن، وستبقى لمدة من الزمن في المستقبل– الخيار المفضّل للحفاظ على البيانات موثوقة وآمنة؛ وهي كذلك كفؤة. تتطلب أنظمة إدارة قواعد البيانات العلائقيّة مخططات معرفة ومحددة جيدًا –ولا يجب أن يختلط الأمر مع تعريف PostgreSQL الخاص بهذه الأنظمة– لقبول هذه البيانات. تشكّل هذه الهيئات التي يحددها المستخدم كيفية حفظ واستخدام البيانات. إنّ هذه المخططات شبيهة جدًّا بالجداول، وفيها أعمدة تمثّل عدد ونوع المعلومات التي تنتمي لكل سجل، والصفوف التي تمثّل المدخلات. من أنظمة إدارة قواعد البيانات الشائعة نذكر: SQLite: نظام إدارة قواعد بيانات علائقيّة مضمّن قويّ جدًّا.MySQL: نظام إدارة قواعد بيانات علائقيّة الأكثر شهرة والشائع استخدامه.PostgreSQL: أكثر نظام إدارة قواعد بيانات علائقيّة كيانيّ (objective-RDBMS) متقدم وهو متوافق مع SQL ومفتوح المصدر.ملاحظة: لمعرفة المزيد عن أنظمة إدارة قواعد بيانات NoSQL، راجع المقالة التالية عن الموضوع: A Comparison Of NoSQL Database Management Systems. أنظمة قواعد بيانات NoSQL (أو NewSQL)لا تأتي أنظمة قواعد بيانات NoSQL بنموذج كالمستخدم في (أو الذي تحتاجه) الحلول العلائقيّة المهيكلة. هناك العديد من التطبيقات، وكلّ منها تعمل بطريقة مختلفة كليًّا، وتخدم احتياجات محدّدة. هذه الحلول عديمة المخططات (schema-less) إمّا تسمح تشكيلات غير محدودة للمدخلات، أو –على العكس– بسيطة جدًّا ولكنها كفؤة للغاية كمخازن قيم معتمد على المفاتيح (key based value stores) مفيدة. على خلاف قواعد البيانات العلائقيّة التقليديّة، يمكن تجميع مجموعات من البينات معًا باستخدام قواعد بيانات NoSQL، كـ MongoDB مثلًا. تُبقي مخازن المستندات هذه كل قطعة من البيانات مع بعضها كمجموعة واحدة (أي كملف) في قاعدة البيانات. يمكن تمثيل هذه المستندات ككيانات بيانات منفردة، مثلها في ذلك كمثل JSON، ومع ذلك تبقى كراسات، وذلك يعتمد على خصائصها. ليس لقواعد بيانات NoSQL طريقة موحدة للاستعلام عن البيانات (مثل SQL لقواعد البيانات العلائقيّة) ويقدم كلّ من الحلول طريقته الخاصّة للاستعلام. ملاحظة: لمعرفة المزيد عن أنظمة إدارة قواعد البيانات العلائقيّة، ألق نظرة على هذه المقالة المتعلقة بالموضوع: A Comparison Of Relational Database Management Systems. مقارنة بين أنظمة إدارة قواعد بيانات SQL و NoSQLمن أجل الوصول إلى نتيجة بسيطة ومفهومة، لنحلّل أولًا الاختلافات بين أنظمة إدارة قواعد البيانات: هيكلية ونوع البيانات المحتفظ بها:تتطلب قواعد البيانات العلائقيّة SQL هيكلة ذات خصائص محدّدة للحفاظ على البيانات، على خلاف قواعد بيانات NoSQL التي تسمح بعمليات انسياب حُرّ (free-flow operations). الاستعلام: وبغضّ النظر عن تراخيصها، تستخدم كلّ قواعد البيانات العلائقيّة معيار SQL إلى حدّ ما، ولهذا يمكن الاستعلام فيها بلغة SQL (أي Structured Query Language). أما قواعد بيانات NoSQL فلا تستخدم طريقة محدّدة للعمل على البيانات التي تديرها. التحجيم: يمكن تحجيم كلي الحلين عموديًّا (أي بزيادة موارد النظام). لكن لكون حلول NoSQL تطبيقات أحدث (وأبسط)، فهذا يجعلها تقدّم وسائل أسهل بكثير لتحجيمها أفقيًّا (أي بإنشاء شبكة عنقودية cluster من أجهزة متعدّدة). المتانة Reliability: عندما يتعلق الأمر بالمتانة والثقة الآمنة بالقَيد المنفّذ، تبقى قواعد بيانات SQL الخيار الأفضل. الدعم: لأنظمة إدارة قواعد البيانات العلائقيّة تاريخ طويل استمر لعقود من الزمن. إنها شائعة جدًّا، ومن السهل إيجاد دعم سواء مجانيّ أو مدفوع. إذا حدثت مشكلة، فمن الأسهل حلّها عليها من قواعد بيانات NoSQL التي شاعت حديثًا، وخاصة إذا كان الحلّ موضع السؤال ذا طبيعة معقّدة (مثل MongoDB). احتياجات حفظ واستعلام البيانات المعقدة: إنّ قواعد البيانات العلائقيّة بطبيعتها الخيار الأمثل لاحتياجات حفظ البيانات والاستعلامات المعقّدة. إنها أكثر كفاءة وتتفوق في هذا المجال. ترجمة -وبتصرّف- للمقال Understanding SQL And NoSQL Databases And Different Database Models لصاحبه O.S. Tezer.

تتوسع قواعد البيانات بسرعة مع مرور الزمن، وتكاد في بعض الأحيان أن تملأ المساحة التخزينية المتاحة في نظام الملفات كلها. وقد تتعرض أيضًا إلى مشاكل في الإدخال والإخراج نتيجةً لمحاولة عدِّة خدمات الكتابة على (أو القراءة من) القسم نفسه معًا. هذا الدرس سيفيدك لو كنتَ تريد إضافة المزيد من المساحة التخزينية، أو استخدام خصائص جهاز التخزين لزيادة الأداء (ربما عبر استخدام RAID)، أو تتطلّع إلى استعمال ميزات أخرى للتخزين. سيعلِّمُك هذا الدرس طريقة تغيير مجلد تخزين بيانات MySQL. المتطلبات المسبقة للمتابعة مع هذا الدرس يجب أن يكون عندك: - خادوم CentOS 7 مع حساب مستخدم ليس جذرًا لكنه يمتلك امتيازات الجذر باستعمال الأمر sudo، وفيه خادوم MariaDB مثبت مسبقًا، يمكنك معرفة المزيد من المعلومات حول ضبط CentOS 7 بقراءة درس الضبط المبدئي لخادوم CentOS 7، وإذا لم تثبت MariaDB من قبل، فسيساعدك درس تثبيت وإعداد نظامي إدارة قواعد البيانات MySQL وPostgreSQL على ذلك. سننقل البيانات من جهاز تخزينٍ موصولٍ (mounted) في نقطة الوصل ‎/mnt/volume-nyc1-01. يمكنك معرفة المزيد من المعلومات عن أجهزة التخزين والأقسام وكيفية استخدامها في درس «كيفية إجراء مهام إدارة أجهزة التخزين البسيطة في لينكس». سيعلّمك هذا الدرس طريقة نقل مجلد تخزين بيانات MySQL إلى مكانٍ جديد بغض النظر عن وسيط التخزين الذي تستخدمه (قرص صلب، أو مصفوفة RAID، أو تخزين شبكي). الخطوة الأولى: نقل مجلد بيانات MariaDB لكي نحضِّر لنقل مجلد بيانات MariaDB فلنحاول معرفة مساره الحالي عبر بدء جلسة تفاعلية بتسجيل الدخول بحساب المستخدم root: mysql -u root -p أدخِل كلمة المرور عند طلبها، ثم نفِّذ التعليمة التالية من سطر أوامر mysql: select @@datadir; الناتج: +-----------------+ | @@datadir | +-----------------+ | /var/lib/mysql/ | +-----------------+ 1 row in set (0.00 sec) الناتج السابق يُظهِر أنَّ قواعد MariaDB مضبوطة لاستخدام مجلد تخزين البيانات المبدئي ‎/var/lib/mysql/‎، وهذا هو مسار المجلد الذي علينا نقله؛ نفِّذ الأمر exit للخروج: exit لكي نضمن سلامة البيانات، علينا أولًا إغلاق خادوم MariaDB قبل تعديل مجلد البيانات: sudo systemctl stop mariadb الأمر systemctl لا يُظهِر نتيجة تنفيذ أوامر إدارة الخدمات، لذا إذا أردتَ التحقق أنَّ الخادوم قد أُغلِق بنجاح، فنفِّذ الأمر الآتي: sudo systemctl status mariadb انظر إلى آخر سطر من ناتج الأمر السابق الذي يجب أن يخبرك أنَّ الخادوم قد توقف عن العمل: . . . Dec 16 18:29:26 mysql systemd[1]: Stopped MariaDB database server. سننسخ مجلد قواعد البيانات الموجود حاليًا إلى المكان الجديد باستخدام rsync وذلك بعد إغلاق الخادوم. سنستخدم الخيار ‎-a للحفاظ على الأذونات وخصائص المجلد الأخرى، وسيزودنا الخيار ‎-v بمخرجات توضِّح سير عملية النسخ. ملاحظة: احرص على عدم وجود خط مائل (/) في نهاية مسار المجلد الذي ستُنسَخ البيانات منه، والذي قد يُضاف تلقائيًا إذا كنتَ تُكمِل المسار باستعمال زر tab، فإذا كان الخط المائل موجودًا فسينسخ الأمر rsync المجلد نفسه وليس محتوياته. sudo rsync -av /var/lib/mysql /mnt/volume-nyc1-01 بعد إكمال تنفيذ أمر rsync السابق، فأعد تسمية المجلد الحالية وأضف إليه اللاحقة ‎.bak (لتعرف أنه نسخة احتياطية وليس المجلد الأصل) وأبقِه موجودًا حتى تتأكد من نجاح عملية النقل؛ أعدنا تسميته لتفادي الخلط بين الملفات الموجودة في المكان القديم والجديد: sudo mv /var/lib/mysql /var/lib/mysql.bak سنشرع الآن بتعديل ضبط قواعد البيانات. الخطوة الثانية: الإشارة إلى مكان تخزين البيانات الجديد هنالك طرائق عدِّة لتجاوز القيم المضبوطة في MySQL، إذ تُضبَط التعليمة datadir مبدئيًا إلى ‎/var/lib/mysql في ملف ‎/etc/my.cnf، لذا لنعدِّل هذا الملف لتغيير المسار إلى المجلد الجديد: sudo vi /etc/my.cnf ابحث عن السطر الذي يبدأ بالكلمة datadir=‎ وغيّر المسار الذي يُشير إليه إلى المسار الجديد. ولوجود ملف المقبس (socket file) في مجلد البيانات القديم، فعلينا تحديثه ليشير إلى المكان الجديد أيضًا: [mysqld] . . . datadir=/mnt/volume-nyc1-01/mysql socket=/mnt/volume-nyc1-01/mysql/mysql.sock . . . بعد تحديث الأسطر السابقة الموجودة في الملف، فلنضف ضبطًا خاصًا بعميل mysql وذلك بإضافة الضبط الآتي إلى نهاية الملف (لكي لا نُقسِّم تعليمات الضبط الخاصة بخادوم MySQL إلى قسمين) لكن قبل السطر الذي يحتوي على الكلمة include: [client] port=3306 socket=/mnt/volume-nyc1-01/mysql/mysql.sock !includedir /etc/my.cnf.d بعد أن تنتهي من تعديل الملف، فاضغط على زر Escape ثم اكتب ‎:wq!‎ لحفظ الملف والخروج من المحرر. الخطوة الثالثة: إعادة تشغيل خادوم MariaDB بعد أن حدثنا الضبط ليشير إلى مسار المجلد الجديد، فيمكننا الآن تشغيل خادوم MariaDB والتأكد من عمله بشكل سليم: sudo systemctl start mariadb sudo systemctl status mariadb للتأكد أننا نستعمل المجلد الموجود في المسار الجديد لتخزين البيانات، فسنتصل عبر عميل mysql: mysql -u root -p وننظر إلى قيمة datadir مجددًا: select @@datadir; الناتج: +----------------------------+ | @@datadir | +----------------------------+ | /mnt/volume-nyc1-01/mysql/ | +----------------------------+ 1 row in set (0.01 sec) نفِّذ exit للخروج من العميل. بعد أن أعدت تشغيل خادوم MariaDB وتأكدت أنَّه يستعمل المكان الجديد، فخذ وقتك للتحقق من سلامة بياناتك وأنَّ قواعد بياناتك تعمل دون مشاكل، وبعدئذٍ تستطيع حذف المجلد الاحتياطي بالأمر sudo rm -rf /var/lib/mysql.bak. الخلاصة تعلمنا في هذا الدرس طريقة نقل مجلد بيانات MariaDB إلى مسارٍ جديد، وهذه الطريقة ستعمل مهما كانت تقنية التخزين التي يعتمدها وسيط التخزين الذي ستستعمله. ولمّا كانت قواعد بيانات MariaDB مشتقةً من MySQL، فيمكنك معرفة المزيد من المعلومات حول إدارة مجلدات البيانات في القسمين الآتيين من توثيق MySQL الرسمي: The MySQL Data Directory و Setting Up Multiple Data Directories. ترجمة –وبتصرّف– للمقال How To Change a MariaDB Data Directory to a New Location on CentOS 7 لصاحبته Melissa Anderson

تُحدِّد خصائص مصفوفات RAID بطريقة الضبط والعلاقة بين الأقراص، وهذا يُسمى «مستوى RAID» ‏(RAID level). أكثر مستويات RAID شيوعًا هي: RAID 0 يدمج مستوى RAID 0 بين جهازين أو أكثر عبر توزيع البيانات عليها، وكما ذكرنا في الدرس السابق (مقدمة إلى اصطلاحات ومفاهيم RAID ) ، التوزيع (striping) هو الآلية التي تُقسِّم البيانات إلى أجزاء (chunks) ثم تكتب تلك الأجزاء بشكلٍ تناوبي على كل قرص في المصفوفة. الفائدة من اتباع هذه الطريقة هي أنَّ البيانات موزَّعة، ويمكن الاستفادة من كل قرص لإجراء عمليات القراءة والكتابة؛ وبالتالي سيكون الأداء النظري لمصفوفة RAID 0 هو حاصل ضرب أداء أحد الأقراص بالعدد الكلي لها (الأداء العملي والحقيقي سيكون أقل من ذلك). ميزة أخرى هي أنَّ المساحة القابلة للاستخدام من المصفوفة هي مجموع مساحات الأقراص المُشكِّلة لها. صحيحٌ أنَّ هذا المستوى يوفِّر أداءً رائعًا، إلا أنَّه يعاني من سلبيات ذات أهمية كبيرة. فلمّا كانت البيانات ستُقسَّم بين عدد من الأقراص في المصفوفة، فإن فشل أحد الأجهزة سيؤدي إلى توقف كامل المصفوفة عن العمل وستفقد جميع البيانات. وعلى النقيض من معظم مستويات RAID الأخرى، لا نستطيع إعادة بناء مصفوفات RAID 0، إذ لا توجد مجموعة من الأقراص التي تحتوي معلومات كافية عن محتوى المصفوفة للمساعدة في إعادة بنائها. إذا كنتَ ستستخدم مصفوفات RAID 0، فسيصبح أخذ نسخ احتياطية أمرًا شديد الأهمية، حيث ستفشل المصفوفة في حال فشل أحد الأقراص المكوِّنة لها. RAID 1 مستوى RAID 1 هو المستوى الذي يُنشِئ نسخةً انعكاسيةً بين جهازَين أو أكثر. أي أنَّ كل المعلومات التي تُكتَب على المصفوفة ستُكتَب بدورها مرتين في كلا القرصين المشكلَين للمجموعة. وهذا يعني أنَّ كل قرص سيحتوي على كامل البيانات الموجودة في المصفوفة، وهذا يوفِّر قدرةً تعويضيةً (redundancy) في حال فشل أحد الأقراص. ستتمكن من الوصول إلى بياناتك في مصفوفات RAID 1 في حال بقي قرصٌ وحيدٌ في المصفوفة سليمًا ويعمل دون مشاكل، ويمكن إعادة بناء المصفوفة باستبدال الأقراص التالفة، ومن ثم ستُستخدَم بقية الأقراص السليمة لنسخ البيانات إلى القرص الجديد. هنالك بعض المساوئ لهذا الضبط، فسرعة القراءة النظرية –كما في مستوى RAID 0– يمكن أن تُحسَب بضرب سرعة القراءة لأحد الأقراص بعددها. لكن سرعة الكتابة النظرية القصوى هي سرعة أبطأ قرص في المصفوفة، وذلك لأنَّ كل البيانات يجب أن تُكتَب على كل قرص في المصفوفة. إضافةً إلى ما سبق، المساحة التخزينية الكلية للمصفوفة ستكون مساويةً لمساحة أصغر قرص، لذا إذا كانت لدينا مصفوفة RAID 1 فيها قرصين لهما نفس القدرة التخزينية، فستكون القدرة التخزينية الإجمالية للمصفوفة مساوية لمساحة أحدهما. وإضافة أقراص أخرى سيزيد من عدد النسخ التعويضية للبيانات، ولن يزيد في المساحة المتوافرة. RAID 5 يملك RAID 5 بعض ميزات مستويي RAID السابقَين، لكن له أداءٌ مختلفٌ وسلبياتٌ مختلفة. ففي مستوى RAID 5، ستوزَّع البيانات على الأقراص بنفس الطريقة التي يتبعها المستوى RAID 0، لكن لكل جزء من البيانات التي تُكتَب على المصفوفة فستُكتَب معلومات parity على أحد الأقراص، والتي هي قيمةٌ محسوبةٌ رياضيًا التي تُستخدَم لتصحيح الأخطاء وإعادة بناء معلومات المصفوفة. سيتم تغيير القرص الذي سيستلم معلومات parity المحسوبة (بدلًا من البيانات الحقيقية) بعد كتابة كل جزء من البيانات. لهذا المستوى بعض المزيات المهمة. فمثل بقية المستويات التي توزِّع البيانات على أكثر من قرص، فإن أداء القراءة سيزداد نتيجةً للقدرة على القراءة من عدِّة أقراص معًا. ويمكن لمصفوفات RAID 5 أن تعمل حتى لو فشل أحد الأقراص في المصفوفة. حيث ستسمح معلومات parity بإكمال إعادة بناء البيانات إن حدث ذلك؛ وذلك لأنَّ معلومات parity موزعة (بعض مستويات RAID الأقل شيوعًا تستخدم قرصًا مخصصًا لمعلومات parity)، حيث يملك كل قرصٍ قدرًا متساويًا من معلومات parity. وصحيحٌ أنَّ المساحة التخزينية القابلة للاستخدام في مصفوفات RAID 1 مساوية لمساحة أحد الأقراص (وذلك لأنَّ جميع الأقراص فيها نسخ متماثلة من البيانات)، لكن في RAID 5، يمكن تحقيق القدرة التعويضية بالاستغناء عن المساحة التخزينية لقرصٍ وحيد، فمثلًا إذا كان لدينا أربعة أقراص 100G في مصفوفة RAID 5 فسينتج عنها مساحة تخزينية تساوي 300G (أما 100G الضائعة فستُستَخدم لتخزين معلومات parity). وكما في المستويات الأخرى، هنالك سلبياتٌ لمصفوفات RAID 5 التي يجب أخذها بعين الاعتبار. فقد تؤدي إلى تقليل أداء النظام نتيجةً لحساب معلومات parity ديناميكيًا طوال الوقت، وهذا قد يؤثر على الأداء عند كل عملية كتابة على المصفوفة. وإذا فشل أحد الأقراص في المصفوفة وأصبحت المصفوفة ذات حالة منخفضة، فسيؤدي ذلك أيضًا إلى بطئ شديد عند القراءة منها (لأنَّ البيانات الناقصة ستُحسَب من بقية الأقراص). بالإضافة إلى ذلك، عند محاولة إصلاح المصفوفة بعد استبدال القرص التالف، فيجب قراءة كل قرص بأكمله واستخدام المعالج لحساب البيانات الناقصة لإعادة بناء المصفوفة. وهذا قد يُجهِد بقية الأقراص، مما يؤدي أحيانًا إلى فشلٍ إضافيٍ في أحد الأقراص، مما يؤدي في النهاية إلى فقدان البيانات. RAID 6 يَستخدم مستوى RAID 6 بنيةً قريبةً من مستوى RAID 5، لكن مع مضاعفة كمية معلومات parity. هذا يعني أنَّ المصفوفة ستصمد حتى لو حدث عطب بقرصين. وهذه ميزة مهمة جدًا لزيادة احتمال حدوث عطب آخر أثناء عملية إعادة بناء المصفوفة عند حدوث خطأ. وفي هذا المستوى –كغيره من المستويات التي تستخدم التوزيع– سيكون أداء القراءة جيد إجمالًا. وجميع ميزات RAID 5 تنطبق أيضًا على RAID 6. أما مساوئ هذا المستوى، فهي استخدام مساحة تخزينية أكبر لمعلومات parity، وهذا يعني أنَّ المساحة الإجمالية للمصفوفة هي مجموع مساحات جميع الأقراص المكوِّنة لها منقوصًا منها مساحة قرصين. إضافةً إلى أنَّ العمليات الحسابية اللازمة لإنشاء معلومات parity لمستوى RAID 6 أكثر تعقيدًا من RAID 5، مما يعني أداءً أسوأ للكتابة مقارنةً مع RAID 5. يعاني مستوى RAID 6 من نفس المشاكل التي تحدث في RAID 5 عندما تصبح المصفوفة بحالة منخفضة، لكن وجود قرص إضافي للتعويض سيقل احتمال حدوث مشاكل إضافية تؤدي إلى حذف جميع البيانات عند عمليات إعادة البناء. RAID 10 يمكن تطبيق مستوى RAID 10 بعدِّة طرائق، والتي ستؤثِّر على خصائصه: مستويا 1 و 0 متشعبان تقليديًا، يُشير مستوى RAID 10 إلى مستوى متشعب، والذي يُنشَأ بضبط مصفوفتَي RAID 1 أو أكثر أولًا، ثم استخدام تلك المصفوفات كمكونات لإنشاء مصفوفة RAID 0 موزّعة. ويدعى هذا المستوى حاليًا أحيانًا باسم RAID 1+0 للإشارة إلى هذه العلاقة. وبسبب تصميم هذا المستوى، فإن العدد الأدنى للأقراص هو أربعة وذلك لإنشاء مصفوفة RAID 1+0 (أي مستوى RAID 0 يستعمل مصفوفتَي RAID 1 تتألف كلٌ منهما على قرصين). تملك مصفوفات RAID 1+0 أداءً عاليًا شبيهًا بمصفوفات RAID 0، لكن بدلًا من الاعتماد على أقراص مفردة لتوزيع البيانات، فسيتم استخدام مصفوفة منسوخة نسخًا انعكاسيًا (mirrored array)، مما يعني توفير قدرة تعويضية. يمكن أن يتحمل هذا النوع من الضبط أيّة أخطاء ومشاكل في الأقراص لطالما بقي قرصٌ وحيدٌ يعمل في كل مصفوفة RAID 1 مُشكِّلة للمصفوفة النهائية. يمكن أن يتحمل هذا المستوى عددًا مختلفًا من المشاكل اعتمادًا على مكان وقوعها. ولأنَّ مصفوفات RAID 1+0 توفِّر أداءً عاليًا وقدرةً تعويضيةً، فهي خيارٌ ممتازٌ إن لم تكن مقيدًا بعددٍ معيّنٍ من الأقراص. RAID 10 عبر mdadm لدى برمجية mdadm في لينكس نسخةٌ خاصةٌ بها من RAID 10، والتي تحمل نفس فوائد RAID 1+0 لكن تُغيّر في طريقة تنفيذها لكي تكون مرنةً أكثر وتوفِّر ميزاتٍ إضافيةٍ. وكما في مستوى RAID 1+0، مستوى RAID 10 في mdadm يسمح بتوزيع البيانات ونسخها أكثر من مرة. لكن الأقراص لن تُرتَّب كمجموعتَين منسوختين نسخًا انعكاسيًا، وإنما سيقرِّر مدير النظام عدد النسخ التي ستُكتَب على المصفوفة. ستُجزَّأ البيانات وتُكتَب على المصفوفة بأكثر من نسخة، مع الحرص على أن تُكتَب كل نسخة من البيانات على قرصٍ فيزيائيٍ منفصل. والنتيجة النهائية هو وجود نفس العدد من النسخ، لكن طريقة بناء المصفوفة تختلف (أي لن يكون فيها «تشعب»). هذا الضبط لمستوى RAID 10 له ميزات تجعله متفوقًا عن RAID 1+0، فلأنه لا يعتمد على تشعّب المصفوفات فذلك يعني أننا نستطيع استخدام رقم فردي من الأقراص ويمكن أيضًا تقليل عدد الأقراص الأدنى (ليصبح 3 فقط). يمكن أيضًا ضبط عدد النسخ. وستصبح الإدارة أبسط لأنك ستحتاج إلى إدارة مصفوفة وحيدة، ويمكنك استخدام أقراص بديلة (كقطع غيار) لكامل المصفوفة، بدلًا من إمكانية استخدامها لمصفوفة متشعبة وحيدة. الخلاصة أكثر مستوى من مستويات RAID يناسب خادومك يعتمد تمامًا على حالات استخدامك له وعلى هدفك من المصفوفة. التكلفة والقيود التي يضعها العتاد سيؤثران أيضًا على عملية تقرير مستوى RAID المناسب. ترجمة -وبتصرّف- للمقال An Introduction to RAID Terminology and Concepts لصاحبه Justin Ellingwood

تمهيد من المهم أن تأخذ طريقة التخزين بعين الاعتبار عندما تضبط خادومًا، إذ أنَّ أغلبية المعلومات المهمة التي تهتمُ أنت ومستخدموك بها ستُكتَب في مرحلةً ما إلى وسيط تخزين للحصول عليها لاحقًا. ستستفيد من الأقراص المستقلة إذا كانت احتياجاتك بسيطة، لكن إن أردتَ الحصول على أداءٍ عالٍ أو ضمانٍ لعدم فقدان بياناتك، فعندئذٍ ستستفيد من تقنيات مثل RAID. سنتحدث في هذا الدرس عن اصطلاحات RAID ومفاهيمها الشائعة، وسنناقش بعض ميزات (ومساوئ) استخدام مصفوفات RAID، وسنتحدث عن الاختلافات بين طرائق تنفيذ تقنية RAID. ما هي مصفوفة RAID؟ ترمز الكلمة RAID إلى «Redundant Arrays of Independent Disks» وهي تعني «مصفوفة الأقراص التعويضية المستقلة»، أي استخدام عدِّة أقراص بأنماط مختلفة مما يمنح مدراء الأنظمة أداءً أفضل أو قدرةً تعويضيةً (ضد فشل الأقراص) مقارنةً بمجموعةٍ من الأقراص التي تعمل بمفردها. يمكن تطبيق RAID على الأقراص الخام أو على الأقسام الموجودة في قرصٍ ما. متى يُفضَّل استخدام RAID؟ الفائدة الأساسية من مصفوفات RAID هي القدرة على تعويض فقدان البيانات والزيادة في الأداء. القدرة التعويضية تعني زيادةً في إتاحية (availability) البيانات المخزنة، وهذا يعني أننا سنتمكن من الوصول إلى المعلومات المخزنة عند حدوث بعض الحالات مثل فشل أحد أقراص التخزين، وسيتمكن النظام من إكمال عمله إلى أن يُستبَدل القرص المعطوب. لكن هذا لا يعني أنَّ هذه هي آلية نسخ احتياطي (يجب أخذ نسخ احتياطية لمصفوفات RAID كغيرها من أنواع التخزين)، وإنما الغرض من هذه الآلية هو تقليل الانقطاعات عند حدوث مشكلة. فائدةٌ أخرى رئيسيةٌ توفرها مصفوفات RAID في بعض الحالات هي الزيادة في الأداء، فعادةً ستكون سرعة الكتابة أو القراءة على وسائط التخزين محدودة (ومرتبطة) بسرعة الكتابة على قرصٍ وحيد، أما البيانات في مصفوفات RAID فهي إما موجودة نفسها في أكثر من قرص (redundant) أو موزعة على أكثر من قرص (distributed)، وهذا يعني أننا نستطيع استخدام عدِّة أقراص لكل عملية قراءة مما يزيد من كمية البيانات التي يمكن قراءتها في الثانية؛ ويمكن أيضًا تحسين سرعة عمليات الكتابة في بعض حالات الضبط التي يمكن فيها كتابة قسم من البيانات على كل قرص. بعض الجوانب السلبية في مصفوفات RAID تتضمن زيادةً في تعقيد عملية الإدارة وعادةً تؤدي إلى إنقاص المساحة التخزينية المتوافرة. وهذا يعني تكاليف إضافية يجب دفعها للحصول على نفس مقدار المساحة التخزينية القابلة للاستخدام. هنالك مصاريف أخرى تتضمن استخدام قطع عتاديّة خاصة عندما لا تريد إدارة المصفوفة عبر أدواتٍ برمجيةٍ فقط. إحدى السلبيات الأخرى للمصفوفات المضبوطة للحصول على أداءٍ عالٍ دون قدرة تعويضية هي الزيادة في احتمال فقدات البيانات، حيث تعتمد البيانات المخزنة على الأقراص في تلك الحالات على أكثر من وسيط تخزين وحيد، مما يزيد من احتمال فقدان البيانات نتيجة عطب في أحد الأقراص. مصفوفات RAID التي تعتمد على العتاد، والتي تعتمد على البرمجيات، والتي تعتمد على البرمجيات بمساعدة العتاد يمكن إنشاء وإدارة مصفوفات RAID بمختلف التقنيات. وهي: مصفوفات RAID التي تعتمد على العتاد هنالك قطعٌ عتاديةٌ مخصصة تسمى «متحكمات RAID» ‏(RAID controllers) أو «بطاقات RAID» ‏(RAID cards) يمكن أن تستعمل لإعداد وإدارة مصفوفات RAID بمعزل عن نظام التشغيل، وهذا معروفٌ بالمصطلح «hardware RAID». تملك متحكمات RAID العتادية معالجًا منفصلًا لإدارة أجهزة RAID. لمصفوفات RAID التي تعتمد على العتاد عدِّة ميزات، نذكر منها: الأداء: متحكمات RAID العتادية (الحقيقة) لا تأخذ من وقت المعالج لإدارة الأقراص الموجودة ضمن المصفوفة. وهذا يعني أنَّك لن تُسبِّب تقليل أداء الخادوم لإدارة أجهزة التخزين. توفِّر المتحكمات ذات الجودة العالية تخزينًا مؤقتًا كبيرًا وله أثرٌ كبيرٌ على الأداء. إخفاء تعقيدات المصفوفة: ميزة أخرى لاستخدام متحكمات RAID هي أنَّها تخفي طريقة ترتيب الأقراص وإدارتها عن نظام التشغيل، حيث ستُمثِّل متحكماتُ RAID المصفوفةَ على أنها وحدة تخزينٍ منطقيةٍ وحيدةٍ. وليس من الضروري أن يفهم نظام التشغيل طريقة ترتيب مصفوفة RAID؛ إذ أنَّه سيتعامل مع كامل المصفوفة على أنها قرصٌ وحيدٌ. سيُتاح استخدام المصفوفة عند الإقلاع: بسبب أنَّ المصفوفة مدارة بشكلٍ كامل عتاديًا دون تدخل البرمجيات، فهذا يعني أنها متاحة الاستخدام عند الإقلاع، مما يسمح بإنشاء نظام الملفات الرئيسي (الذي سيُثبَّت داخله نظام التشغيل) داخل مصفوفة RAID. لكن هنالك بعض السلبيات لمصفوفات RAID التي تعتمد على العتاد: احتكار الشركات: لأن مصفوفات RAID العتادية مدارةٌ من برمجيات تجارية موجودة داخل العتاد، فهذا يعني أنَّنا يجب أن نستعمل المصفوفة مع نوع العتاد الذي أنشأها فقط؛ فلو تعطل متحكم RAID، ففي أغلب الحالات يجب أن نضع شريحة مماثلة أو شريحة متوافقة مع الشريحة القديمة بدلًا عنه. يَنصح بعض مدراء الأنظمة بشراء أكثر من متحكم RAID من نفس النوع كاحتياطٍ في حال حدثت مشكلة. الكلفة العالية: متحكمات RAID ذات الجودة العالية تكون ذات سعر مرتفع عادةً. مصفوفات RAID التي تعتمد على البرمجيات يمكن أيضًا ضبط RAID داخل نظام التشغيل نفسه. ولأنَّ العلاقة بين الأقراص ستُعرَّف وتُضبَط داخل نظام التشغيل عوضًا عن استخدام جهاز عتادية منفصل، فستسمى تلك المصفوفات بمصفوفات «software RAID». بعض ميزات مصفوفات RAID البرمجية: المرونة: لمّا كانت مصفوفات RAID التي تعتمد على البرمجيات تُدار داخل نظام التشغيل، فيمكن بسهولة ضبط أجهزة التخزين المتاحة دون تغيير شيء في ضبط العتاد. عملية إنشاء مصفوفات RAID في لينكس هي عملية مرنة للغاية، حيث يُسمَح بضبط مختلف أنواع ومستويات RAID. مفتوحة المصدر: البرمجيات التي نستعملها لضبط مصفوفات RAID في الأنظمة مفتوحة المصدر مثل لينكس و FreeBSD هي برمجيات مفتوحة المصدر أيضًا، وضبط المصفوفات متاحٌ لك وغير مخفي، ويمكن بكل سهولة قراءته وتطبيقه على أنظمة أخرى. فمثلًا، إذا كانت لدينا مصفوفة RAID أنشأناها على نظام أوبنتو، فسنتمكن ببساطة من نقلها إلى خادوم CentOS لاحقًا. هنالك احتمالٌ ضئيلٌ في أنَّك ستفقد الوصول إلى بياناتك بسبب بعض الاختلافات بين البرمجيات. لا توجد تكلفة إضافية: لا يتطلب إنشاء مصفوفات RAID برمجية أيّة قطع عتادية خاصة، لذا لن تكون هنالك تكلفة إضافية على خادومك عند استخدامها. بعض سلبيات استخدام مصفوفات RAID البرمجية: التبعية للبرمجيات: صحيحٌ أنَّ مصفوفات RAID البرمجية غير مرتبطة بعتاد معيّن، لكن عادةً سترتبط ببرمجية معيّنة التي أنشأتها فيها. فمثلًا يستخدم لينُكس mdadm بينما FreeBSD يستعمل مصفوفات RAID مبنية على GEOM، ولنظام ويندوز له نسخةٌ خاصةٌ به من البرمجيات التي تُتيح إنشاء مصفوفات RAID برمجية. وعلى الرغم من أنَّ مختلف نسخ البرمجيات المفتوحة المصدر يمكن أن تُصدِّر ضبطها فيما بينهما، إلا أنَّه لا يحتمل أن تتوافق الصيغة نفسها مع بقية برمجيات RAID. مشاكل في الأداء: قديمًا كانوا ينتقدون مصفوفات RAID البرمجية لأنها تُسبِّب بحملٍ إضافيٍ على النظام. فسيُستعمَل المعالج المركزي والذاكرة لإدارة المصفوفة، والتي كانت يمكن أن تُستعمَل لأمورٍ أخرى. لكن البرمجيات مثل mdadm التي تعمل على عتادٍ حديث قد أطاحت بهذا المخاوف، أي أنَّ استعمال المعالج يكون أصغريًا في أغلبية الحالات ولا نأخذه بعين الاعتبار. مصفوفات RAID التي تعتمد على البرمجيات بمساعدة العتاد النوع الثالث من مصفوفات RAID يدعى «hardware-assisted software RAID» أو «firmware RAID» أو «fake RAID». عمومًا يوفر هذا النوع ميزات RAID بتضمينه داخل اللوحة الأم أو عبر بطاقات RAID رخيصة الثمن. يتم تطبيق هذا النوع من المصفوفات عبر استخدام برمجيات على المتحكم أو البطاقة لإدارة مصفوفة RAID، لكنه يستخدم وحدة المعالجة المركزية لتشغيل تلك البرمجيات. ميزات هذا النوع من المصفوفات: دعم إقلاع أكثر من نظام تشغيل: وذلك لأنَّ مصفوفة RAID ستعمل عند الإقلاع، لذا يمكن استخدام أكثر من نظام تشغيل للمصفوفة، وهذا غير ممكن إذا استعملنا مصفوفات RAID برمجية. من سلبياتها: دعم محدود لمستويات RAID: عادةً تدعم RAID 0 أو RAID 1 فقط. تتطلب عتادًا خاصًا: مثل مصفوفات RAID العتادية، هذا النوع مقيدٌ بالعتاد الذي أنشأه ويديره، وهذه مشكلة كبيرة في حال كان موجودًا ضمن اللوحة الأم، فلو فشل متحكم RAID أو تعطل، فهذا يعني أنَّ عليك استبدال اللوحة الأم كلها لكي تستطيع الوصول مرةً أخرى إلى بياناتك. مشاكل في الأداء: مثل مصفوفات RAID العتادية، لا يوجد هنا معالج خاص بإدارة RAID، ويجب أن يتشارك المتحكم مع نظام التشغيل باستخدام المعالج المركزي. أغلبية مدراء الأنظمة يبقون بعيدين عن هذا النوع من مصفوفات RAID، لأنها تعاني من اجتماع مشاكل النوعَين الآخرَين. الاصطلاحات المستخدمة عند الحديث عن مصفوفات RAID سيساعدك التعرف على بعض هذه الاصطلاحات على فهم RAID بشكل أفضل. هذه بعض المصطلحات الشائعة التي قد تصادفك: مستوى RAID ‏(RAID level): يشير «مستوى RAID» إلى العلاقة التي تجمع أجهزة التخزين. يمكن ضبط الأقراص بعدِّة طرائق، مما يؤدي إلى خصائص مختلفة للتعويض وللأداء. التوزيع (Striping): «التوزيع» هو عملية تقسيم البيانات المكتوبة على المصفوفة إلى أكثر من قرص. تُستخدَم هذه التقنية من مختلف مستويات RAID. عندما توزَّع البيانات على المصفوفة، فستُقسَّم إلى أجزاء صغيرة، ثم يكُتَب كل جزء إلى قرص واحد أو أكثر من الأقراص المُشكِّلة للمصفوفة. حجم الجزء (Chunk Size): عند توزيع البيانات، سيُحدِّد «حجم الجزء» مقدار البيانات التي سيحتوي كل جزء عليها. وتعديل حجم الجزء ليُطابِق خصائص الدخل والخرج التي تتوقعها قد يساعد في زيادة أداء المصفوفة. آلية تعادل القيمة (Parity): هذه آلية يتم إنجازها عبر حساب المعلومات من كتل البيانات (data blocks) المكتوبة إلى المصفوفة. وقد تستخدم معلومات parity لإعادة بناء البيانات إذا فشل أحد الأقراص. قد توضع معلومات parity في قرص منفصل عن الأقراص التي تحتوي البيانات التي تُحسَب بيانات parity منها، وتوزَّع في أغلبية حالات الضبط على عدِّة أجهزة للمقدرة على تعويض فشل أحد الأقراص ولزيادة الأداء. مصفوفات ذات الحالة المخفَّضة (Degraded Arrays): يمكن أن تعاني المصفوفات التي لها قدرة تعويضية (redundancy) أنواعًا مختلفةً من فشل الأقراص دون خسارة البيانات. فعندما تخسر المصفوفة قرصًا لكنها تستطيع إكمال عملها، فيُقال أنَّها أصبحت «بحالة مُخفَّضة» (degraded mode). يمكن إعادة بناء المصفوفات ذات الحالة المخفَّضة لترجع كما كانت بعد استبدال القرص المعطوب، لكنها قد تعاني من أداءٍ منخفض أثناء تلك الفترة. إعادة المزامنة (Resilvering أو Resyncing): «إعادة المزامنة» هو المصطلح المستخدم لإعادة بناء مصفوفة ذات الحالة المخفَّضة. واعتمادًا على ضبط RAID ونوع الفشل، سنتمكن من إجراء عملية إعادة المزامنة إما بنسخ البيانات من الملفات الموجودة في المصفوفة، أو عبر حساب البيانات باستخدام معلومات parity‏ (parity information). المصفوفات المتشعبة (Nested Arrays): يمكن دمج مجموعات من مصفوفات RAID في مصفوفات أكبر. ونفعل ذلك عادةً للاستفادة من ميزات مستويي RAID أو أكثر. عادةً تُستخدَم المصفوفات ذات القدرة التعويضية (مثل RAID 1 أو RAID 5) كمكونات لإنشاء مصفوفة RAID 0 لزيادة الأداء. الامتداد (Span): للأسف، مصطلح «الامتداد» له معانٍ مختلفة عندما نتحدث عن المصفوفات. ..- في سياقات معيّنة، «الامتداد» يعني وصل قرصين أو أكثر مع بعضهما لتمثيلهما كجهاز منطقي وحيد، بدون تحسين في الأداء أو القدرة التعويضية. وهذا يُعرَف أيضًا بالترتيب الخطي (linear arrangement) عند التعامل مع برمجية mdadm في لينكس. ..- يمكن أن يشير «الامتداد» إلى المصفوفات التي تُجمَّع مع بعضها لإنشاء مستوى جديد من مستويات RAID وذلك في المصفوفات المتشعبة، مثل المصفوفات من المستوى RAID 10 (أي RAID 1+0). التحقق (Scrubbing أو Checking): هي عملية قراءة كل كتلة في المصفوفة للتأكد من عدم وجود أخطاء. وهذا يساعد في التأكد من أنَّ البيانات متماثلة في أكثر من وسيط تخزين، وسيمنع ذلك من حدوث أخطاء قد تؤدي إلى تلف في البيانات، وخصوصًا خلال العمليات الحساسة مثل إعادة بناء المصفوفة. ترجمة -وبتصرّف- للمقال An Introduction to RAID Terminology and Concepts لصاحبه Justin Ellingwood

تعرفنا في الدرس الماضي على مفهوم حاويات لينكس (LXC)، مبدأ عملها وكيفية تثبيتها، سنشرع في هذا الدرس إلى كيفية بدء تشغيلها واستعمالها. لا يملك LXC عفريتًا (daemon) يعمل طوال الوقت، لكنه يملك مهام upstart: المهمة ‎/etc/init/lxc-net.conf: هي مهمة اختيارية تعمل فقط إذا حَدَّد الملف ‎/etc/default/lxc الخاصية USE_LXC_BRIDGE (قيمتها هي true افتراضيًا)؛ حيث تهيِّء جسر NAT لكي تستخدمه الحاويات. المهمة ‎/etc/init/lxc.conf: تعمل إذا كانت الخاصية LXC_AUTO (قيمتها true افتراضيًا) مضبوطة إلى true في ‎/etc/default/lxc؛ حيث تبحث عن القيود في المجلد ‎/etc/lxc/auto‎/‎ حيث توجد وصلات رمزية إلى ملفات الضبط للحاويات التي يجب أن تُشغَّل في وقت الإقلاع. المهمة ‎/etc/init/lxc-instance.conf: تُستخدَم من ‎/etc/init/lxc.conf للبدء التلقائي لتشغيل حاوية. التخزين يدعم LXC عدّة أنماط من التخزين لجذر نظام ملفات الحاوية؛ افتراضيًا يكون مجلدًا بسيطًا، لأنه لا يتطلب أي ضبط مسبق للمضيف طالما أن نظام الملفات فيه مساحة تخزينية كافية؛ وهو لا يتطلب أيضًا امتيازات الجذر لإنشاء المخزن، لذلك سيكون ملائمًا للاستخدام دون امتيازات؛ جذر نظام الملفات للاستخدام مع امتيازات موجود افتراضيًا في ‎/var/lib/lxc/C1/rootfs، بينما جذر نظام الملفات للحاويات التي تعمل دون امتيازات يكون في ‎~/.local/share/lxc/C1/rootfs، إذا حُدِّد lxcpath خاص في lxc.system.com، فإن جذر نظام ملفات الحاوية سيكون موجودًا في ‎$lxcpath/C1/rootfs. نسخة snapshot باسم C2 لحاوية C1 التي تُخزَّن في مجلد ستصبح حاوية overlayfs، بجذر نظام ملفات هو overlayfs:/var/lib/lxc/C1/rootfs:/var/lib/lxc/C2/delta0، أنواع التخزين الأخرى تتضمن loop، و btrfs، و LVM، و zfs. حاوية تعتمد على تخزين btrfs تبدو عمومًا مثل حاوية تعتمد على التخزين في مجلد، ويكون جذر نظام الملفات في نفس المكان؛ لكن جذر نظام الملفات يحتوي على حجم فرعي (subvolume)، لذلك تكون نسخة snapshot مُنشَأة باستخدام نسخة snapshot لحجم فرعي. جذر نظام الملفات لحاوية تستخدم LVM يمكن أن يكون أي حجم منطقي منفصل؛ اسم مجموعة الحجوم الافتراضي يمكن أن يُحدَّد في ملف lxc.conf؛ ويُضبَط نوع وحجم نظام الملفات لكل حاوية باستخدام lxc-create. جذر نظام الملفات لحاوية تستخدم zfs هو نظام ملفات zfs منفصل، وموصول في المكان التقليدي ‎/var/lib ‎/lxc/C1/rootfs، يمكن تحديد zfsroot باستخدام lxc-create، ويمكن تحديد قيمة افتراضية في ملف lxc.system.conf. المزيد من المعلومات حول إنشاء الحاويات بمختلف طرائق التخزين يمكن أن توجد في صفحة دليل lxc-create. القوالب يتطلب إنشاء حاوية عادةً إنشاء جذر نظام ملفات للحاوية؛ يفوض الأمر lxc-create هذا العمل إلى القوالب (templates)، التي تكون عادةً خاصة بالتوزيعة؛ قوالب lxc التي تأتي مع lxc يمكن أن توجد في مجلد ‎/usr/share/lxc/templates، بما فيها القوالب لإنشاء أوبنتو، ودبيان، وفيدورا، وأوراكل، وسنتوس، وجنتو بالإضافة لغيرها. إنشاء صور للتوزيعات في أغلب الحالات يتطلب القدرة على إنشاء عقد أجهزة، ويتطلب ذلك أدوات التي ليست متوفرة في بقية التوزيعات، وعادةً يستغرق هذا الأمر وقتًا طويلًا؛ فلذلك يأتي lxc بقالب download، الذي ينزل صور مبنية مسبقًا للحاويات من خادوم lxc مركزي؛ أهم حالة استخدام هي السماح بإنشاء بسيط لحاويات دون امتيازات بواسطة مستخدمين غير الجذر، الذين لن يستطيعوا ببساطة تشغيل الأمر debootstrap. عند تشغيل lxc-create، فجميع الخيارات التي تأتي بعد «--» تُمرَّر إلى القالب؛ ففي الأمر الآتي، تمرر الخيارات ‎--name و ‎--template و ‎--bdev إلى lxc-create، بينما يمرر الخيار ‎--release إلى القالب: lxc-create --template ubuntu --name c1 --bdev loop -- --release trusty يمكنك الحصول على مساعدة حول الخيارات المدعومة في حاوية معينة بتمرير الخيار ‎--help واسم القالب إلى الأمر lxc-create؛ فعلى سبيل المثال، للحصول على مساعدة حول تنزيل قالب: lxc-create --template download --help البدء التلقائي يدعم LXC تعليم الحاويات لكي تُشغَّل عند إقلاع النظام؛ ففي الإصدارات قبل أوبنتو 14.04، كان يتم ذلك باستخدام وصلات رمزية في المجلد ‎/etc/lxc/auto؛ وبدءًا من أوبنتو 14.04، يتم ذلك عبر ملفات ضبط الحاوية؛ القيد: lxc.start.auto = 1 lxc.start.delay = 5 يعني أن على الحاوية البدء عند إقلاع النظام ويجب الانتظار 5 ثواني قبل بدء تشغيل الحاوية التالية؛ يدعم LXC أيضًا ترتيب وتجميع الحاويات، وأيضًا إعادة الإقلاع وإيقاف التشغيل عبر مجموعات autostart؛ راجع صفحات دليل lxc-autostart و lxc-container.conf للمزيد من المعلومات. AppArmor يأتي LXC مع ملف ضبط AppArmor مهمته هي حماية المضيف من الإساءة العرضية للامتيازات داخل الحاوية؛ على سبيل المثال، لن تكون الحاوية قادرةً على الكتابة إلى ‎/proc/sysrq-trigger أو أغلبية ملفات ‎/sys. الملف usr.bin.lxc-start يدخل حيز التنفيذ عند تشغيل lxc-start؛ يمنع ملف الضبط lxc-start من وصل أنظمة ملفات جديدة خارج نظام ملفات الجذر الخاص بالحاوية؛ قبل تنفيذ init للحاوية، فإن LXC يطلب تبديلًا لملف ضبط الحاوية؛ افتراضيًا، هذا الضبط هو السياسة lxc-container-default المعرَّفة في ملف الضبط ‎/etc/apparmor.d/lxc/lxc-default. يمنع هذا الضبط الحاوية من الوصول إلى مسارات خطرة، ومن وصل أغلبية أنظمة الملفات. لا يمكن تقييد البرامج في الحاوية أكثر من ذلك؛ فعلى سبيل المثال، خادوم MySQL الذي يعمل ضمن نطاق الحاوية (مما يحمي المضيف) لا يمكن أن يدخل في نطاق ملف ضبط MySQL (لحماية الحاوية). لا يدخل lxc-execute ضمن سلطة AppArmor، لكن الحاوية التي يُنشِئها (spawn) ستكون مقيدةً. تعديل سياسات الحاوية إذا وجدت أن lxc-start لا يعمل بسبب تقييد في الوصول من سياسة AppArmor، فيمكنك تعطيل ملف ضبط lxc-start بتنفيذ: sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disabled/ هذا سيجعل lxc-start يعمل دون قيود، لكن ستبقى الحدود موجودةً للحاوية نفسها، وإذا أردت إزالة التقييد عن الحاوية، فعليك بالإضافة إلى تعطيل ملف الضبط usr.bin.lxc-start أن تضيف السطر: lxc.aa_profile = unconfined إلى ملف ضبط الحاوية. يأتي LXC مع سياسات بديلة للحاويات، فإذا أردت إنشاء حاويات داخل حاويات (تشعب)، فعليك استخدام ملف الضبط lxc-container-default-with-nasting بإضافة السطر الآتي إلى ملف ضبط الحاوية: lxc.aa_profile = lxc-container-default-with-nesting إذا أردت استخدام libvirt داخل الحاويات، فستحتاج إلى تعديل تلك السياسة (المعرفة في ‎‎/etc/apparmor.d/lxc/lxc-default-with-nasting) وإزالة التعليق عن السطر الآتي: mount fstype=cgroup -> /sys/fs/cgroup/**, ثم أعد تحميل السياسة. لاحظ أن سياسة التشعب للحاويات ذات الامتيازات هي أقل أمانًا من السياسة الافتراضية، حيث تسمح للحاويات بإعادة وصل ‎/sys و ‎/proc في أمكان غير قياسية، مما يتجاوز سياسة AppArmor؛ لا تملك الحاويات دون امتيازات هذا التأثير الجانبي، ﻷن جذر الحاوية لا يمكنه الكتابة إلى ملفات proc و sys المملوكة من الجذر. إذا أردت تشغيل الحاوية بملف ضبط مخصص، فبإمكانك إنشاء ملف ضبط في ‎/etc/apparmor.d/lxc، ويجب أن يبدأ اسمه بالكلمة lxc-‎ لكي يُسمَح لبرنامج lxc-start بالانتقال إليه؛ ملف lxc-default يتضمن إعادة استعمال الملف المجرد ‎/etc/apparmor.d/abstraction/lxc/container-base؛ طريقة سهلة لإنشاء ملف ضبط جديد هي فعل المثل، ثم إضافة الأذونات الإضافية في نهاية السياسة. حَمِّل الضبط الجديد بعد إنشاءه كما يلي: sudo apparmor_parser -r /etc/apparmor.d/lxc-containers سيُحمَّل هذا الضبط تلقائيًا بعد إعادة الإقلاع، ﻷنه يُقرَأ من الملف ‎/etc/apparmor.d/lxc-containers؛ وفي النهاية ولجعل الحاوية CN تستخدم ملف الضبط الجديد lxc-CN-profile، فأضف السطر الآتي إلى ملف الضبط: lxc.aa_profile = lxc-CN-profile مجموعات التحكم إن مجموعات التحكم (cgroups) هي ميزة من ميزات النواة توفر تجميع للمهام تجميعًا هيكليًا، وإسناد وتحديد الموارد لكل مجموعة تحكم؛ تُستخدَم في الحاويات للحد من الوصول إلى الأجهزة الكتلية أو المحرفية (block or character devices) وتجمِّد عمل الحاويات؛ يمكن استعمالها أيضًا لتحديد استخدام الذاكرة وإيقاف الدخل أو الخرج، وضمانة استخدام أصغري للمعالج، والسماح للحاوية بالوصول إلى معالجات محددة. افتراضيًا، سيُسند للحاوية CN ذات امتيازات مجموعةُ تحكمٍ باسم ‎/lxc/CN؛ وفي حال حدوث تضارب بالاسم (الذي قد يحدث عند استخدام lxcpaths مخصصة)، فستُضاف لاحقة «‎-n» حيث n هو رقم صحيح يبدأ من الصفر، ويُسنَد إلى اسم مجموعة التحكم. افتراضيًا، سيُسند للحاوية CN دون امتيازات مجموعة تحكم باسم CN في مجموعة التحكم الخاصة بالمهمة التي بدأت الحاوية، على سبيل المثال ‎/usr/1000.user/1.session/CN سيُمنَح جذر الحاوية ملكية المجموعة للمجلد (لكن ليس جميع الملفات)، وهذا ما سيسمح بإنشاء مجموعات تحكم فرعية. وفي أوبنتو 14.04، يستخدم LXC مدير مجموعات التحكم cgmanager لإدارة مجموعات التحكم؛ يستقبل مدير مجموعات التحكم طلبات D-Bus عبر مقبس يونكس ‎/sys/fs/cgroup/cgmanager/sock؛ يجب أن يُضاف السطر الآتي لاستخدام آمن للحاويات المتشعبة: lxc.mount.auto = cgroup إلى ملف ضبط الحاوية، مما يصل المجلد ‎/sys/fs/cgroup/cgmanager وصلًا ترابطيًا (bind-mounted) إلى الحاوية؛ ويجب على الحاوية في المقابل تشغيل وسيط إدارة مجموعات التحكم (ويتم ذلك افتراضيًا إذا كانت الحزمة cgmanager مثبتةً على الحاوية) الذي سينقل المجلد ‎/sys/fs/cgroup/cgmanager إلى ‎/sys/fs/cgroup‎/cgmanager.lower ثم سيبدأ الاستماع إلى الطلبات للوسيط على مقبسه ‎/sys/fs/cgroup ‎/cgmanager‎/sock؛ سيتأكد مدير مجموعات التحكم في المضيف أن الحاويات المتشعبة لن تستطيع «الهروب» من مجموعات التحكم المُسندَة إليها أو إنشاء طلبات غير مصرح لها بها. الاستنساخ للتزويد السريع بالحاويات، ربما تريد تخصيص حاوية تبعًا لحاجاتك ثم تُنشِئ عدَّة نسِخٍ منها؛ ويمكن فعل ذلك بالبرنامج lxc-clone. الاستنساخ إما أن يكون عبر snapshots أو بنسخ حاوية أخرى؛ فالنسخ هو إنشاء حاوية جديدة منسوخة من الأصلية، وتأخذ مساحة تخزينية مثل الحاوية الأصلية؛ أما snapshot فإنها تستخدم قدرة آلية التخزين على إنشاء snapshots لإنشاء حاوية النسخ-عند-الكتابة (copy-on-write) تُشير إلى الحاوية الأولى؛ يمكن إنشاء snapshots للحاويات المخزنة في btrfs، و LVM، و zfs، وتلك التي تكون مخزنة في مجلدات؛ حيث كل آلية تخزين لها خصوصياتها؛ فمثلًا، حاويات LVM التي ليست thinpool-provisioned لا تدعم إنشاء snapshots من snapshots؛ ولا يمكن حذف حاويات zfs مع snapshots قبل أن تُطلَق (release) جميع snapshots؛ ويجب أن يُخطط جيدًا لحاويات LVM فقد لا يدعم نظام الملفات أن يزيد حجمه. لا يعاني btrfs من تلك السلبيات، لكنه يعاني من أداء fsync منخفض يسبب جعل dpkg و apt-get أبطئ. تُنشَأ snapshots من الحاويات المخزنة في مجلدات عبر نظام الملفات؛ فمثلًا يكون لحاوية ذات امتيازات C1 جذر نظام ملفات في ‎/var/lib/lxc/C1/rootfs، وستبدأ نسخة snapshot للحاوية C1 باسم C2 بجذر نظام الملفات للحاوية C1 موصولًا للقراءة فقط في ‎/var/lib/lxc/C2/delta0؛ كل ما يهم في هذه الحالة أنه لا يفترض أن تعمل أو تحذف الحاوية C1 أثناء عمل C2؛ من المستحسن اعتبار الحاوية C1 هي حاوية أساسية واستخدام نسخة snapshot لها فقط. لنفترض أن لدينا حاوية باسم C1، فيمكن إنشاء نسخة منها باستخدام الأمر: sudo lxc-clone -o C1 -n C2 يمكن إنشاء snapshot باستخدام: sudo lxc-clone -s -o C1 -n C2 راجع صفحة دليل lxc-clone لمزيد من المعلومات. Snapshots LXC يدعم snapshots لتسهيل دعم نسخ snapshot لتطوير تكراري للحاوية؛ فعندما تعمل على حاوية C1 -وقبل إنشاء تغيير خطير وصعب العكس- يمكنك إنشاء snapshot: sudo lxc-snapshot -n C1 التي هي نسخة snapshot باسم «snap0» في مجلد ‎/var/lib/lxcsnaps أو ‎$HOME/.local ‎/share/lxcsnaps، النسخة الثانية ستُسمى «snap1» وهكذا؛ يمكن عرض النسخ الموجودة حاليًا باستخدام الأمر lxc-snapshot -L -n C1، ويمكن أن تُستعاد نسخة snapshot وتمحى حاوية C1 الحالية باستخدام الأمر lxc-snapshot -r snap1 -n C1، وبعد تنفيذ أمر الاستعادة، فستبقى النسخة snap1 موجودةً. تُدعَم snapshots لحاويات btrfs، و lvm، وzfs، و overlayfs؛ إذا استدعي الأمر lxc-snapshot على حاوية تُخزَّن في مجلد، فسيسجل خطأ وستُنشَأ نسخة copy-clone؛ وسبب ذلك أنه لو أنشأ المستخدم نسخة overlayfs snapshot لحاوية تخزن في مجلد، فسينعكس جزء من تغيرات الحاوية الأصلية على نسخة snapshot؛ إذا كنت تريد إنشاء snapshots لحاوية C1 مخزنة في مجلد، فيمكن إنشاء نسخة overlayfs للحاوية C1، ويجب ألّا تلمس C1 بعد ذلك قط، لكن يمكن أن نعدِّل overlayfs وننسخها نسخ snapshots كما نريد، أي: lxc-clone -s -o C1 -n C2 lxc-start -n C2 -d # make some changes lxc-stop -n C2 lxc-snapshot -n C2 lxc-start -n C2 # etc الحاويات العابرة «الحاويات العابرة» (Ephemeral containers) هي حاويات تستخدم لمرة واحدة فقط؛ فليكن لدينا حاوية موجودة مسبقًا باسم C1، فيمكنك إنشاء حاوية عابرة باستخدام: lxc-start-ephemeral -o C1 ستبدأ الحاوية كنسخة snapshot للحاوية C1، وستطبع التعليمات للدخول إلى الحاوية على الطرفية، وستدمر الحاوية العابرة بعد إيقاف التشغيل، راجع صفحة الدليل lxc-start-ephemeral لمزيد من الخيارات. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: LXC.

إن Squid هو خادوم تخزين وسيط للويب (web proxy cache server) الذي يوفر خدمات الوساطة والتخزين لبروتوكول نقل النص الفائق (HTTP)، وبروتوكول نقل الملفات (FTP)، وغيرهما من بروتوكولات الشبكة الشهيرة؛ يمكن أن يدعم Squid التخزين والوساطة لطلبات طبقة المقابس الآمنة (SSL) وتخزين طلبيات DNS؛ ويدعم Squid أيضًا بروتوكولات تخزين مخبأ مختلفة، مثل بروتوكول تخزين الإنترنت (Internet Cache Protocol اختصارًا ICP)، وبروتوكول تخزين النص الفائق (Hyper Text Caching Protocol اختصارًا HTCP)، وبروتوكول تخزين مصفوفة التوجيه (Cache Array Routing Protocol اختصارًا CARP)، وبروتوكول تنسيق تخزين الويب (Web Cache Coordination Protocol اختصارًا WCCP). إن الخادوم الوسيط Squid هو حل ممتاز لاحتياجاتٍ كثيرةً للوساطة أو التخزين المؤقت، والتوسع من مكتب فرعي إلى شبكة الشركة الكبيرة وذلك بتوفير آليات مراقبة وتحكم في الوصول للمعاملات المهمة باستخدام بروتوكول إدارة الشبكة المبسط (Simple Network Management Protocol اختصارًا SNMP). عند اختيار حاسوب ليعمل كخادوم Squid، فتأكد أنه مضبوط مع كمية كبيرة من الذاكرة الفيزيائية، حيث يستخدم Squid التخزين في الذاكرة لزيادة الأداء. التثبيتأدخِل الأمر الآتي في الطرفية لتثبيت خادوم Squid: sudo apt-get install squid3الضبطيُضبَط Squid بتعديل التعليمات الموجودة ضمن ملف الضبط ‎/etc/squid3/squid.conf؛ الأمثلة الآتية تعرض بعض التعليمات التي يمكن تعديلها لتغيير سلوك خادوم Squid؛ للمزيد من التفاصيل المعمَّقة حول Squid، فانظر إلى قسم المصادر. تنويه: قبل تعديل ملف الضبط، تأكد أنك ستُنشِئ نسخةً من الملف الأصلي وتحميها من الكتابة كي تحصل على الإعدادات الافتراضية كمرجعٍ لك، أو أن تعيد استخدامها وقت الحاجة. انسخ الملف ‎/etc/squid/squid.conf واحمهِ من الكتابة بإدخال الأوامر الآتية في الطرفية: sudo cp /etc/squid3/squid.conf /etc/squid3/squid.conf.original sudo chmod a-w /etc/squid3/squid.conf.originalلضبط خادوم Squid لكي يستمع إلى منفذ TCP ذو الرقم 8888 بدلًا من منفذ TCP الافتراضي 3128، فعدِّل التعليمة http_port كما يلي: http_port 8888عدِّل التعليمة visible_hostname لكي تعطي خادوم Squid اسم مضيف خاص به؛ هذا الاسم لا يفترض أن يكون نفس اسم المضيف للحاسوب؛ ضُبِطَ في هذا المثال إلى weezie: visible_hostname weezieباستخدام التحكم في الوصول الخاص بخادوم Squid، ربما تضبط استخدام خدمات الإنترنت التي يكون فيها Squid وسيطًا لتتوفر للمستخدمين الذي يملكون عناوين IP معيّنة؛ ففي هذا المثال، سنسمح بالوصول لمستخدمي الشبكة الفرعية 192.168.42.0/24 فقط: أضف ما يلي إلى نهاية قسم ACL من ملف ضبط ‎/etc/squid3/squid.conf: acl fortytwo_network src 192.168.42.0/24ثم أضف ما يلي إلى بداية قسم http_access في ملف ‎/etc/squid3/squid.conf: http_access allow fortytwo_networkباستخدام ميزات التحكم بالوصول الممتازة التي يوفرها Squid؛ فربما تضبط استخدام خدمات الإنترنت التي يكون فيها Squid وسيطًا كي تتوفر فقط أثناء ساعات العمل العادية؛ على سبيل المثال، سنحاكي وصول الموظفين خلال ساعات العمل من 9:00AM إلى 5:00PM ومن الاثنين إلى الجمعة، الذين يستخدمون الشبكة الفرعية 10.1.42.0/42: أضف ما يلي إلى نهاية قسم ACL في ملف ‎/etc/squid3/squid.conf: acl biz_network src 10.1.42.0/24 acl biz_hours time M T W T F 9:00-17:00ثم أضف ما يلي إلى أعلى قسم http_access في ملف ‎/etc/squid3/squid.conf: http_access allow biz_network biz_hoursملاحظة: بعد عمل تغيرات إلى ملف الضبط ‎/etc/squid3/squid.conf، فاحفظ الملف ثم أعد تشغيل خادوم Squid لكي تأخذ التغيرات مجراها بإدخال الأمر الآتي في الطرفية: sudo service squid3 restartمصادرموقع Squid.صفحة ويكي أوبنتو «Squid».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Squid - Proxy Server.