المحتوى عن 'تخزين'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • الإدارة والقيادة
  • مقالات ريادة أعمال عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML
    • HTML5
  • CSS
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • Sass
    • إطار عمل Bootstrap
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 7 نتائج

  1. تتوسع قواعد البيانات بسرعة مع مرور الزمن، وتكاد في بعض الأحيان أن تملأ المساحة التخزينية المتاحة في نظام الملفات كلها. وقد تتعرض أيضًا إلى مشاكل في الإدخال والإخراج نتيجةً لمحاولة عدِّة خدمات الكتابة على (أو القراءة من) القسم نفسه معًا. هذا الدرس سيفيدك لو كنتَ تريد إضافة المزيد من المساحة التخزينية، أو استخدام خصائص جهاز التخزين لزيادة الأداء (ربما عبر استخدام 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
  2. تُحدِّد خصائص مصفوفات 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
  3. تمهيد من المهم أن تأخذ طريقة التخزين بعين الاعتبار عندما تضبط خادومًا، إذ أنَّ أغلبية المعلومات المهمة التي تهتمُ أنت ومستخدموك بها ستُكتَب في مرحلةً ما إلى وسيط تخزين للحصول عليها لاحقًا. ستستفيد من الأقراص المستقلة إذا كانت احتياجاتك بسيطة، لكن إن أردتَ الحصول على أداءٍ عالٍ أو ضمانٍ لعدم فقدان بياناتك، فعندئذٍ ستستفيد من تقنيات مثل 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
  4. نتطرّق في هذا المقال من سلسلة الدروس عن شهادة RHCSA من RedHat لكيفيّة إعداد نظام التخزين وضبطه على RedHat Enterprise Linux 7 باستخدام الأداة Parted وهي الأداة المبدئيّة للتعامل مع وحدات التخزين في RHEL؛ سنقدّم أيضا مدير نظام التخزين System storage manager, SSM الذي يسهّل المهمّة كثيرا. إنشاء التجزئات Partitions والتعديل عليها في RedHat Enterprise Linux تُستَخدم الأداة parted مبدئيا للتعامل مع التجزئات في RHEL؛ ويمكن باستخدامها: عرض جدول التجزئات الحاليّة، التعديل على التجزئات الحاليّة بزيادة حجمها أو نقصه، إنشاء تجزئات جديدة على المساحة الفارغة من القرص أو على أجهزة تخزين جديدة. ملحوظة: نستخدم آلة تخيّلية باستخدام VirtualBox كما هو مشروح في درس تثبيت Red Hat Enterprise Linux باستخدام VirtualBox. أضفنا إليها قرصا تخيّليا جديدا لنختبر عليه أوامر parted. تمكن إضافة القرص التخيلي باختيّار إعدادات الآلة Settings، ثم تحديد التخزين Storage من نافذة الإعدادات ثم إنشاء قرص تخيليّ بالنقر عل أيقونة الإضافة التي تظهر بجانب خيّار Controller: SATA عند الحوم حوله بالمؤشر. يُستحسَن قبل البدء في إنشاء تجزئات جديدة أو التعديل على التجزئات الموجودة التأكّد من عدم استخدام أيّ من التجزئات على القرص. إن كانت لديك مساحة إبدال Swap على القرص فستحتاج لتعطيلها. الطريقة الأسهل لتهيئة هذه المتطلّبات هو إقلاع النظام على وضع الإنقاذ Rescue mode باستخدام وسيط التثبيت (قرص ضوئي أو مفتاح USB): اذهب إلى قائمة الأجهزة الطرفيّة Devices في VirtualBox ثم اختر الأقراص الضوئيّة Optical devices وحدّد مسار ملفّ ISO الخاصّ بتثبيت النظام. بعد إعادة تشغيل النظام والإقلاع على وسيط التثبيت تظهر قائمة الاختيّار التاليّة؛ حدّد خيار Troubleshooting (استكشاف الأخطاء). تظهر قائمة Troubleshooting؛ اختر منها Rescue a Red Hat Enterprise Linux system (أصلح نظاما يستخدم RHEL) انتظر قليلا حتى تظهر لك إمكانيّة تحديد الخيّار. توجد أربعة خيارات اختر منها Skip to shell (تجاوز إلى الصّدفة) بكتابة الرقم الظاهر أمامها (3). تحصُل باتّباع الخطوات السابقة على صدفة يمكنك تنفيذ أوامر Parted منها. إنشاء تجزئة جديدة نستخدم الأمر parted على النحو التالي لإنشاء تجزئة جديدة على القرص sdb (أي القرص الثاني، يُشار للقرص الأوّل بـ sda): # parted /dev/sdb ملحوظة 1: يحتوي المجلّد dev/ على ملفّات خاصّة للتعامل مع العتاد؛ يستخدم النظام الملفّ dev/sda/ للتعامل مع القرص الأوّل في الجهاز، dev/sdb/ مع الثاني، dev/sdc/ مع الثالث، وهكذا. يُشار إلى التجزئات الموجودة على قرص بأرقام: dev/sda1/ التجزئة الأولى من القرص الأول، dev/sda2/ التجزئة الثانية من القرص الأول، dev/sdb1/ التجزئة الأولى من القرص الثاني، وهكذا. ملحوظة 2: يحوي القرص الأول dev/sda/ ملفّات نظام التشغيل المثبّت على الجهاز. تطبيق أوامر بطريقة خاطئة على هذا القرص قد يجعل النظام غير قابل للاستخدام. سيظهر محثّ جديد لإدخال الأوامر الخاصّة بالأداة parted: نفّذ الأمر print في سطر أوامر parted للحصول على قائمة بالتجزئات الحاليّة على القرص: لا توجد حتى الآن أية تجزئة على القرص الذي تبلغ مساحته 8,5GB. سننشئ على هذا القرص تجزئة أوّليّة بمساحة تبلغ 7GB. نهيّئ Format التجزئة بنظام الملفّات xfs الذي يُستخدَم مبدئيا على RHEL؛ إلا أن بإمكانك الاختيار من بين نظم ملفّات أخرى كثيرة. سنبدأ بإنشاء التجزئة باستخدام الأمر mkpart ثم نهيّئها باستخدام الأمر mkfs.fstype؛ إذ أن دعم الأمر mkpart لأنظمة الملفات الحديثة ليس جيّدا. نضبُط في ما يلي لصيقة Label للقرص ثم ننشئ تجزئة أوليّة على القرص dev/sdb/ تبدأ من أول القرص (%0) وتنتهي عند 7GB (أي 7000MB)؛ ثم نستخدم الأمر print في الأداة Parted لعرض جدول تجزئات القرص. أثناء عمليّة الإنشاء يُطلّب منّا نوعيّة نظام الملفّات الذي نريد، نترك الخيار المبدئي. ملحوظة: لصيقة القرص Disk lable (تُسمّى أيضا جدول التجزئة Partition table أو خريطة التجزئة Partition map) هو سجّل يستخدمه النظام للحصول على معلومات عن التجزئة. يدعم الأمر mklable صيغ تجزئة محدّدة من بينها bsd، gpt، msdos وmac. نستخدم الآن الأمر mkfs.xfs لتهيئة التجزئة التي أنشأناها. نخرج من سطر الأوامر الخاص بالأداة Parted بتنفيذ الأمر quit ثم ننفّذ الأمر على النحو التالي: # mkfs.xfs /dev/sdb1 # parted /dev/sdb print لاحظ إرفاق التجزئة أثناء إنشائها ببيانات وصفيّة Meta data خاصّة بنظام الملفّات xfs. تغيير مساحة تجزئة تتيح الأداة Parted أمر resize لتغيير مساحة التجزئة، إلا أن هذا الأمر لا ينطبق سوى على نظم الملفّات القديمة مثل ext2، fat32 وfat16؛ أي أن الطريقة الوحيدة لتغيير مساحة التجزئة هي بحذفها ثم إنشائها من جديد وهو ما يعني حذف محتويات التجزئة وضياعها. تستخدم توزيعة RHEL نمط تجزئة LVM لتلافي هذه الصعوبة في إدارة التجزئات (سنرى كيف يعمل بعد قليل). نعرض في ما يلي لائحة بالتجزئات على القرص sdb ثم نحذف التجزئة الأولى: # parted /dev/sdb print # parted /dev/sdb rm 1 من المستحسَن ألا تستخدم هذا الأمر على نظام إنتاج حقيقي. مدير التجزئات المنطقية Logical volume manager رأينا أنّ تعديل مساحة التجزئات الموجودة على القرص بعد إنشائها بالطريقة التقليديّة المشروحة أعلاه صعب وربما يؤدي لفقدان بيانات؛ لهذا يجب النّظر إلى إمكانيّة الاستعانة بمدير التجزئات المنطقيّة LVM. يعمل مدير التجزئات على تجميع وسائط تخزين عدّة لتبدو كأنها وسيط تخزين واحد ثم إنشاء تجزئات انطلاقا من هذه الوحدة المجمَّعة. تكمُن الميزة التي تقدّمها هذه الطريقة في سهولة تمديد أو تقليص التجزئات المنطقيّة دون مصاعب تُذكر. يبيّن المخطَّط التالي البنية الأساسيّة لمدير التجزئات المنطقيّة. سنشرح في ما يلي أساسيّات استخدام مدير التجزئات المنطقيّة LVM. نهيّئ لهذا الغرض قرصين ملموسين تخيّليّيْن جديديْن بنفس طريقة إنشاء القرص التخيّلي في الفقرات السابقة. سنستخدم القرصيْن لإنشاء مجموعة تجزئة Volume group ننشئ عليها التجزئات المنطقيّة. إنشاء التجزئات الملموسة Physical Volumes نبدأ بإنشاء تجزئتيْن جديدتين ملموستيْن تأخذ كلّ واحدة منهما كامل القرص الذي توجد عليه. بالنسبة للقرص التخيلي الثالث (الأول هو قرص النظام، الثاني هو القرص الذي استخدمناه في الجزء الأول من المقال): # parted /dev/sdc (parted) mklable msdos (parted) mkpart Partition type? primary/secondary? p File system type? [ext2]? Start? 0% End? 100% (parted) print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sdb: 8590MB sector size (logical/physical): 512B/512B Partition Table: msdos Disk flags: Number Start End Size Type File system Flags 1 1049kb 8590MB 8589MB primary quit نعيد نفس الشيء بالنسبة للرابع: # parted /dev/sdd ننفذ بالعودة إلى سطر الأوامر بعد تهيئة التجزئتين الأمرين التاليّين: # pvcreate /dev/sdc1 # pvcreate /dev/sdd1 تظهر في كلّ مرة رسالة بأن إنشاء التجزئة الملموسة تم بطريقة صحيحة. الأمر pvcreate جزء من مدير التجزئات المنطقيّة ومهمّته إنشاء التجزئات الملموسة التي سنجمّعها كما سنرى من أجل إنشاء تجزئات منطقية في ما بعد. إن أردت إظهار معلومات عن التجزئات الملموسة التي أنشأناها بالأمر pvcreate فيمكنك استخدام الأمر pvdisplay: # pvdisplay /dev/sdc1 # pvdisplay /dev/sdd1 يُظهر الأمر اسمَ التجزئة والمجموعة التي تنتمي إليها مع بيانات أخرى. لا توجد لحدّ الساعة مجموعة تجزئات؛ لذا سننشئ واحدة. إنشاء مجموعة تجزئات Volume group يُستخدم الأمر vgcreate لإنشاء مجموعة تجزئات. ننشئ في الأمر التالي مجموعة تجزئات باسم hsoub_vg تتكون من تجزئتين ملمومستين هما dev/sdc/1 و dev/sdd1/: # vgcreate hsoub_vg /dev/sd{c,d}1 تظهر رسالة تفيد بإنشاء مجموعة التجزئات. ستلاحظ الآن عند تنفيذ الأمر pvdisplay /dev/sdv1 اسم المجموعة ضمن معلومات التجزئة. إن أردت رؤية معلومات عن مجموعة التجزئات فيمكنك تنفيذ الأمر vgdisplay: # vgdisplay hsoub_vg إنشاء تجزئات منطقية جهّزنا مجموعة التجزئات؛ يمكننا الآن استخدامها لإنشاء تجزئات منطقية باستخدام الأمر lvcreate. يمكن أن نحدّد مساحة التجزئة إما بالوحدة (GB مثلا) أو بمداها (100 بالمئة)، المعطى الأخير للأمر هو اسم مجموعة التجزئات التي نريد تطبيق الأمر عليها: # lvcreate -L 3G -n vol01_docs hsoub_vg # lvcreate -L 1G -n vol02_logs hsoub_vg # lvcreate -l 100%FREE -n vol03_homes hsoub_vg يحدّد الخيار L- مساحة التجزئة بالوحدة، l- النسبة من المجموعة و n-اسم التجزئة المنطقيّة. في الأمرين الأول والثاني أعلاه أنشأنا تجزئتين منطقيتين مساحتاهما على التوالي 3G و1G. في الأمر الثالث طلبنا أن تأخذ التجزئة كامل المساحة المتبقيّة على مجموعة التجزئة . يمكن باستخدام الأمر lvdisplay إظهار التجزئات المنطقية الموجودة على مجموعة تجزئات كالتالي: # lvdisplay hsoub_vg تهيئة التجزئات المنطقية وتركيبها يمكنك بعد إنشاء التجزئات المنطقيّة تهيئتها بنظام الملفات الذي تريد؛ نستخدم في المثال التالي نظام الملفّات ext4 (من المهمّ اختيار نظام الملفات المناسب؛ xfs مثلا لا يدعم تغيير مساحة التجزئة): # mkfs.ext4 /dev/hsoub_vg/vol01_docs # mkfs.ext4 /dev/hsoub_vg/vol02_logs # mkfs.ext4 /dev/hsoub_vg/vol03_homes لاحظ مسار التجزئات المنطقيّة. توجد مجموعة التجزئات على المسار dev/hsoub_vg/ حيث hsoub_vg هو مجموعة التجزئة، وبداخل المجلّد توجد التجزئات المنطقيّة التي أنشأناها سابقا. يأتي بعد التهيئة تركيبُ التجزئات حتى يمكن استخدامها: # mkdir /mnt/docs /mnt/logs /mnt/homes # mount /dev/hsoub_vg/vol01_docs /mnt/docs # mount /dev/hsoub_vg/vol02_logs /mnt/logs # mount /dev/hsoub_vg/vol03_homes /mnt/homes ملحوظة: يعني التركيب Mounting إتاحة إمكانية الوصول لنظام الملفات انطلاقا من نقطة معينة في شجرة ملفات لينكس. بدون هذه الخطوة لا يمكن استعمال التجزئة. يمكن الآن تخزين الملفّات في المجلّد mnt/docs/ وسيضعها النظام على التجزئة المنطقيّة vol01_docs. ينطبق نفس المبدأ على بقيّة التجزئات والمسارات. حذف التجزئات المنطقية، مجموعة التجزئات والتجزئات الملموسة نستخدم الأوامر vgremove، lvremove وpvremove لحذف تجزئة منطقية، مجموعة تجزئات وتجزئات ملموسة على التوالي. سنحتاج أولا لفصلها (نزع تركيبها) بالأمر umount: # umount /mnt/docs /mnt/logs /mnt/homes # lvremove /dev/hsoub_vg/vol01_docs /dev/hsoub_vg/vol02_logs /dev/hsoub_vg/vol03_homes ستظهر رسالة تطلُب منك تأكيد رغبتك في حذف التجزئات؛ اضغط زر y للتأكيد. ثم نحذف مجموعة التجزئات ومن بعدها التجزئات الملموسة: # vgremove /dev/hsoub_vg # pvremove /dev/sd{b,c}1 سنخرج الآن من وضع الإنقاذ بعد أن رأينا آلية عمل التجزئات المنطقية. استخدم الأمر exit للخروج من وضع الإنقاذ ثم انزع القرص الضوئي التخيلي حتى يستطيع النظام الإقلاع من القرص التخيليّ (يمكن أيضا إطفاء الآلة التخيليّة مباشرة من VirtualBox ونزع القرص الضوئي ثم تشغيلها من جديد). استخدام مدير وسائط التخزين SSM لإنشاء التجزئات المنطقية وإدارتها مدير وسائط التخزين SSM (اختصار لـ System storage manager) هو أداة تعمل واجهةً بين لإدارة وسائط التخزين بطريقة أسهل. رأينا في الفقرات السابقة أنّه يلزم تنفيذ خمسة أوامر لإنشاء تجزئة منطقيّة والبدء في استخدامها (mkfs ، lvcreate ، vgcreate ،pvcreate و mount). يمكن باستخدام ssm اختصار هذه الخطوات في خطوة واحدة. نبدأ بتحديث حزم النظام وتثبيت مدير وسائط التخزين: $ su - Password: # yum update && yum install system-storage-manager ثم نستخدم الأمر ssm لإنشاء تجزئات بنفس الخاصيّات السابقة: # ssm create -s 3G -n vol01_docs -p hsoub_vg --fstype ext4 /mnt/docs /dev/sd{c,d}1 # ssm create -s 1G -n vol02_logs -p hsoub_vg --fstype ext4 /mnt/logs # ssm create -n vol03_homes -p hsoub_vg --fstype ext4 /mnt/homes ملحوظة: تأكد من وجود المجلدات على المسارات mnt/logs ، /mnt/docs/ و mnt/homes/ حتى يمكن تركيب التجزئات عليها. يمكن من الأوامر استنتاجُ عمل الخيارات: المساحة: s-. اسم التجزئة المنطقية: n-. مجموعة التجزئات: p-. نقطة التركيب: المسارات mnt/logs، /mnt/docs/ وmnt/homes/. التجزئات الملموسة: dev/sd{c,d}1/. لم نحدّد في الأمر الأخير مساحة التجزئة؛ في هذه الحالة تأخذ التجزئة كامل المساحة المتبقيّة على مجموعة التجزئات. حدّدنا في الأمر الأول التجزئات الملموسة التي ستتكوّن منها مجموعة التجزئات؛ بينما لم نفعل ذلك في الأمريْن الآخريْن إذ لم نعد نحتاجه بعد إنجاز المهمة في الأمر الأول. نفَّذ ssm في الأوامر أعلاه المهامّ التالية: إعداد التجزئات الملموسة. إنشاء مجموعة تجزئات. إنشاء تجزئات منطقيّة. تهيئة التجزئات المنطقيّة. تركيب التجزئات المنطقيّة. يمكننا الآن عرض معلومات عن التجزئات الملموسة، مجموعات التجزئات والتجزئات المنطقيّة على التوالي بالأوامر: # ssm list dev # ssm list pool # ssm list vol من أهم الميزات التي توفّرها التجزئات المنطقيّة إمكانيّة التعديل على مساحتها (تصغيرها أو تكبيرها) مباشرة. نفرض مثلا أن التجزئة vol02_logs توشك على الامتلاء بينما توجد مساحة فارغة كبيرة على التجزئة vol03_homes. لحد الساعة لا توجد مساحة فارغة على مجموعة التجزئات hsoub_vg لأننا استهلكناها كلَّها بإنشاء تجزئات منطقية عليها؛ يمكن التأكد من ذلك بتنفيذ الأمر ssm list pool: ما سنفعله هو تقليص مساحة التجزئة vol03_homes ثم منح المساحة المقتطعة منها للتجزئة الممتلئة vol02_logs . يعدّل الأمر التالي على التجزئات المنطقيّة بحيث تصبح مساحة vol03_homes تساوي 4GB بدلا من 11GB: # ssm resize -s 4G /dev/hsoub_vg/vol03_homes إن أعدنا تنفيذ الأمر ssm list pool الآن فسنرى وجود مساحة غير مستقلة على المجموعة hsoub_vg. يمكننا الآن زيادة مساحة التجزئة vol02_logs: # ssm resize -s+2G /dev/hsoub_vg/vol02_logs يطلُب الأمر زيادة مساحة التجزئة vol02_logs بـ2GB. يمكن باستخدام الأمر ssm remove حذفُ تجزئة منطقيّة على النحو التالي: # ssm remove /dev/hsoub_vg/vol01_docs ستظهر رسالة تطلب منك التأكيد على خيّار الحذف. لحذف مجموعة تجزئات نحذف التجزئات المنطقيّة أولا ثم ننفّ الأمر: # ssm remove hsoub_vg إدارة التجزئات المعماة بواسطة SSM يتوفّر مدير وسائط التخزين SSM على إمكانيّة تعميّة تجزئات موجودة أو إنشاء تجزئات وتعميّتها. سنحتاج لهذا الغرض لتثبيت حزمة cryptsetup إن لم تكن مثبّتة قبلا، على النحو التالي: # yum update && yum install cryptsetup ثم ننفذ الأوامر التالية لإنشاء تجزئات معمّاة، سيُطلب منك إدخال عبارة سرّ Passphrase وتأكيدها. # ssm create -s 3G -n vol01_docs -p hsoub_vg --fstype ext4 --encrypt luks /mnt/docs /dev/sd{c,d}1 # ssm create -s 1G -n vol02_logs -p hsoub_vg --fstype ext4 --encrypt luks /mnt/logs # ssm create -n vol03_homes -p hsoub_vg --fstype ext4 --encrypt luks /mnt/homes لا تختلف الأوامر عن الأوامر السابقة لإنشاء التجزئات سوى في إضافة الخيار encrypt-- الذي يحدّد نوعيّة التعميّة (luks في حالتنا، وهي طريقة تعميّة ينتشر استخدامها على أنظمة لينكس). يجب أن نضيف التجزئات إلى ملف etc/fstab/ حتى تكون متاحة بعد إقلاع النظام. سنستخدم معرّفات التجزئات UUID التي يمكننا الحصول عليها بتنفيذ الأمر blkid: # blkid -o value UUID /dev/hsoub_vg/vol01_docs # blkid -o value UUID /dev/hsoub_vg/vol02_logs # blkid -o value UUID /dev/hsoub_vg/vol03_homes ثم نضع المحتوى التالي في الملفّ etc/crypttab/ (استخدم المعرفات التي حصلت عليها في الخطوة السابقة): docs UUID=ba77d113-f849-4ddf-8048-13860399fca8 none logs UUID=58f89c5a-f694-4443-83d6-2e83878e30e4 none homes UUID=92245af6-3f38-4e07-8dd8-787f4690d7ac none ثم نضيف ما يلي إلى ملفّ etc/fstab/ (أسفل المحتوى الموجود في الملفّ): # Logical volume vol01_docs: /dev/mapper/docs /mnt/docs ext4 defaults 0 2 # Logical volume vol02_logs /dev/mapper/logs /mnt/logs ext4 defaults 0 2 # Logical volume vol03_homes /dev/mapper/homes /mnt/homes ext4 defaults 0 2 لاحظ أن الاسم الظاهر بعد dev/mapper/ هو نفس المعرّف المحدَّد في الملفّ etc/crypttab/. نفّذ الأمر systemctl reboot لإعادة التشغيل وستجد أنّ النظام يطلُب عبارة السرّ من أجل تركيب التجزئات. ملحوظة: تأكّد من كتابة التعليمات في الملفّات etc/crypttab و etc/fstab/ بطريقة صحيحة؛ وإلا فيمكن ألّا يقلع النظام. إن حدث خطأ ستُطلَب منك كلمة سر الحساب الجذر؛ ويمكنك بعدها تصحيح محتوى الملفّ ثم إعادة تشغيل النظام بالأمر السابق. يمكنك التأكد من أنّ التجزئات رُكِّبت في النقاط التي حدّدناها سلفا بتنفيذ الأمر mount لإظهار نقاط التركيب ثم استخدام grep لاختيار تلك التي توجد بها mnt حيث ركّبنا التجزئات: # mount | grep "mnt" /dev/mapper/logs on /mnt/logs type ext4 (rw,realtime,seclabel,data=ordered) /dev/mapper/docs on /mnt/docs type ext4 (rw,realtime,seclabel,data=ordered) /dev/mapper/homes on /mnt/homes type ext4 (rw,realtime,seclabel,data=ordered) خاتمة رأينا في هذا الدرس مبادئ إعداد نظام التخزين بالطريقة التقليدية وباستخدام أدوات إدارة التجزئات الحديثة مثل lvm و ssm. من المهم الانتباه إلى التعامل مع التجزئات يؤثّر مباشرة على عمل النظام ويمكن لخطأ في تنفيذ أمر مّا أن يجعل النظام غير قابل للاستخدام؛ لذا تدرّب أولا على نظام غير أساسي (أو تخيلي، وهي الطريقة الأسهل) إلى أن تتأكد من فهمك لآلية عمل مختلف الأدوات قبل أن تنتقل إلى بيئة إنتاج. ترجمة -وبتصرّف- للمقال RHCSA Series: Using ‘Parted’ and ‘SSM’ to Configure and Encrypt System Storage – Part 6 لصاحبه Gabriel Cánepa.
  5. تعرفنا في الدرس الماضي على مفهوم حاويات لينكس (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.
  6. منذ زمن سحيق، كانت الذاكرةُ أكثر وظيفة نحتاجها ونعتمد عليها في الحاسوب. ورغم اختلاف التقنيات وأساليب التنفيذ الكامنة وراءها، إلّا أنّ معظم الحواسيب تأتي بالعتاد الضروريّ لمعالجة المعلومات وحفظها بأمان لاستخدامها في المستقبل متى احتجنا لها. لقد صار من المستحيل في عالمنا الحديث تخيل أيّ عمل لا يستفيد من هذه القدرة في الأجهزة، سواء كانت خواديم أو حواسيب شخصية أو كفّيّة. تُعالَج البيانات وتُسجَّل وتُسترجَع مع كل عملية، وفي كل مكان من الألعاب إلى الأدوات المتعلقة بالأعمال، بما فيها المواقع. أنظمة إدارة قواعد البيانات (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.
  7. إن 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.