فصل 12. الإدارة المتقدمة

يعيد هذا الفصل النظر في بعض القضايا التي ناقشناها سابقاً، لكن من وجهة نظر مختلفة: سوف ندرس تجهيز الأنظمة الكبيرة بدلاً من تجهيز حاسوب مفرد؛ وسوف نتعلم ضبط LVM و RAID يدوياً بدل الضبط الآلي عند التثبيت، حتى نتمكن من تعديل الخيارات التي حددناها سابقاً. أخيراً، سوف نتحدث عن أدوات المراقبة وتقنيات المحاكاة. أي أن هذا الفصل موجَّه لمديري النظم المحترفين أكثر مما يركز على ما يهم الأفراد الذين يديرون شبكة منزلية.

12.1. ‏RAID وLVM

استعرض فصل 4, التثبيت هذه التقنيات من وجهة نظر برنامج التثبيت، والطريقة التي دمجت فيها هذه التقنيات حتى يكون إعدادها سهلاً منذ البداية. يجب على مدير النظام أن يستطيع معالجة الحاجات المتزايدة للمساحة التخزينية بعد التثبيت الأولي للنظام، دون اللجوء إلى عملية إعادة التثبيت المكلفة (من ناحية الوقت والجهد). أي أن مدير النظام يجب أن يستخدم الأدوات المطلوبة لتعديل نظامي LVM و RAID بمهارة.

تستخدم تقنيتا LVM و RAID لعزل الحيز التخزيني المتاح لنظام الملفات عن الحيز التخزيني الفيزيائي (الأقراص الصلبة الفعلية أو الأقسام partitions)؛ تحمي تقنية RAID البيانات من خلال التخزين الفائض، بينما تجعل تقنية LVM إدارة البيانات أكثر مرونة واستقلالاً عن السعة الحقيقية للأقراص التي تحميل تلك البيانات. في الحالتين، يعتمد النظام على أجهزة تخزينية جديدة، يمكن استخدامها لإنشاء نظم ملفات أو مساحات swap، دون أن ترتبط بقرص فيزيائي واحد. إن جذور التقنيتين مختلفة كثيرًا، لكن وظائفهما متشابهة نوعًا ما، ولهذا غالبًا ما تذكران معًا.

منظور Btrfs يجمع بين LVM وRAID

في حين أن RAID و LVM هما نظامان فرعيان للنواة يعملان بين أجهزة التخزين وبين نظام الملفات، btrfs هو نظام ملفات جديد، طورته أوراكل في البداية، يهدف للجمع بين مزايا RAID و LVM وأكثر من ذلك. إن معظم أجزاء النظام جاهزة، بالرغم من أنها لا تزال تعتبر ”تجريبية“ لأن تطويرها غير مكتمل (بعض المزايا لم تصل مرحلة التطبيق بعد)، وقد شهد بعض الاستخدامات في البيئات الإنتاجية.

→ http://btrfs.wiki.kernel.org/

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

في حال استخدام RAID أو LVM، توفر النواة ملف جهاز تخزيني (كتلي) block device file، يشبه الملفات التي تمثل الأقراص الصلبة أو أقسام الأقراص. عندما يحتاج أحد التطبيقات، أو أحد أجزاء النواة، للوصول إلى كتلة block من جهاز تخزيني من هذا النوع، يعمل النظام الفرعي المناسب (نظام LVM أو RAID) على توجيه هذه الكتلة إلى الطبقة الفيزيائية الموافقة. وحسب إعداد النظام، يمكن أن تُخزَّن هذه الكتلة على قرص فيزيائي واحد أو أكثر، كما أن موقعها الفيزيائي قد لا يرتبط بموقعها ضمن الجهاز المنطقي.

12.1.1. ‏Software RAID

كلمة RAID تعني Redundant Array of Independent Disks. يهدف هذا النظام إلى حماية البيانات من الضياع في حال عطب القرص الصلب. المبدأ العام بسيط جدًا: تخزن البيانات على عدة أقراص فيزيائية بدلًا من تخزينها على قرص واحد، ويكون مستوى التخزين الفائض قابلاً للضبط. بالاعتماد على هذا التخزين الفائض، يمكن استعادة البيانات دون أية خسارة حتى في حال تعطل أحد الأقراص بشكل غير متوقع.

يمكن تطبيق RAID باستخدام عتاد خاص (وحدات RAID مدمجة في متحكِّمات SCSI أو SATA) أو برمجيًا (عبر النواة). سواء كان النظام يعتمد على العتاد أو البرمجيات، يستطيع RAID أن يبقى في الخدمة عند عطب أحد الأقراص إذا كان هناك تخزين فائض كاف؛ إذا يمكن للطبقة العليا (التطبيقات) أن تستمر بالوصول إلى البيانات بغض النظر عن العطل. طبعاً، يمكن أن يؤثر ”وضع degraded“ هذا على الأداء، كما أن الفائض التخزيني ينخفض، ما يعني إمكانية خسارة البيانات إذا حصل عطل آخر في الأقراص. ولهذا لا يتم الاعتماد على degraded mode عمليًا إلا خلال المدة اللازمة لاستبدال القرص المعطوب. يستطيع نظام RAID إعادة بناء المعلومات اللازمة للعودة إلى الوضع الآمن بعد تثبيت القرص الجديد. لن تلاحظ البرمجيات أي شيء، أو ربما تشعر ببعض البطء في سرعة الوصول إلى البيانات عندما تكون المصفوفة في الوضع degraded أو أثناء مرحلة إعادة بناء البيانات المفقودة.

عندما يعتمد على العتاد لبناء مصفوفات RAID، فغالباً ما يتم إعداد النظام عبر أداة إعداد BIOS، وتعتبر النواة مصفوفة RAID كقرص واحد، يعمل مثل قرص فيزيائي قياسي، إلا أن اسم الجهاز قد يختلف (تبعاً لبرنامج التعريف).

سوف نركز على RAID البرمجي فقط في هذا الكتاب.

12.1.1.1. مستويات RAID المختلفة

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

‏Linear RAID: مع أن نظام RAID الفرعي في النواة يدعم إنشاء ”Linear RAID“، إلا أن هذا النوع ليس RAID أصلاً، إذا أن هذا الإعداد ليس فيه أي فائض. كل ما يحدث هو أن النواة تجمع عدة أقراص مع بعضها بأسلوب end-to-end (نهاية القرص الأول مع بداية الثاني وهكذا) وتقدم مجموع الحجم التخزيني بشكل قرص ظاهري واحد (one block device). هذه هي وظيفته كلها. نادرًا ما يستخدم هذا النمط وحده (اقرأ الفقرات التالية لتتعرف على الحالات الاستثنائية)، خصوصًا أن افتقاره للفائض يعني أن تعطل أحد الأقراص سيودي بالمجموع التخزيني كله، مع بياناته.
‏RAID-0: لا يقدم هذا المستوى أية فائض أيضًا، لكن الأقراص لا تتقاطر خلف بعضها بشكل بسيط: بل تقسم إلى شرائط stripes، ويتم تخزين أجزاء القرص الظاهري على الشرائط بشكل متناوب بين الأقراص الفيزيائية. في نظام RAID-0 ذو قرصين، مثلًا، تُخَزَّن الأجزاء الزوجية من القرص الظاهري على القرص الفيزيائي الأول، والأجزاء الفردية على القرص الفيزيائي الثاني.
لا يسعى هذا النظام لزيادة الوثوقية، نظرًا لأن كافة البيانات ستضيع إذا فشل أحد الأقراص (كما في حالة Linear RAID)، لكنه يهدف لرفع الأداء: سوف تتمكن النواة أثناء الوصول التسلسلي لكميات كبيرة من البيانات المستمرة من القراءة من القرصين معًا (أو الكتابة عليهما معًا) على التوازي، وهو ما يزيد مستوى نقل البيانات. على أية حال، فإن استخدام RAID-0 في تناقص، بعد أن احتلّ LVM مكانه في تحقيق هذه الميزة (انظر لاحقاً).
‏RAID-1: يعرف هذا المستوى أيضًا باسم ”RAID mirroring“، وهو الأبسط والأكثر انتشاراً. يعتمد هذا المستوى –في شكله المعياري– على قرصين فيزيائيين لهما السعة ذاتها، ويعطي قرصًا منطقيًا له نفس السعة أيضًا. تخزن البيانات نفسها على القرصين، ولذلك كان ”mirror“ هو الاسم الثاني لهذا المستوى. إذا تعطّل أحد القرصين، تبقى البيانات متوفرة على الآخر. يمكن طبعاً إعداد RAID-1 على أكثر من قرصين بالنسبة للبيانات الهامة جدًا، لكن هذا سيزيد نسبة الكلفة للمساحة التخزينية.
ملاحظة سعة الأقراص وسعة العنقود
إذا تم إعداد قرصين من سعتين مختلفتين في مرآة RAID-1، لن يستخدم القرص الأكبر بشكل كامل، لأنه سيحوي نفس البيانات التي يحويها القرص الأصغر فقط. أي أن المساحة المتوفرة للاستخدام في قرص RAID-1 الناتج ستطابق سعة أصغر قرص في المصفوفة. هذا القانون ينطبق على مستويات RAID اللاحقة أيضًا، رغم أن الفائض مخزن بأسلوب مختلف.
لذلك كان مهماً أن تجمع الأقراص ذات السعات المتساوية أو المتقاربة جدًا عند إعداد مصفوفات RAID (ما عدا RAID-0 و Linear RAID)، حتى تتجنب الهدر في الموارد.
ملاحظة الأقراص الاحتياطية
يمكن إضافة أقراص أكثر مما هو مطلوب للمصفوفة في مستويات RAID التي تحتوي على فائض. يمكن استخدام الأقراص الإضافية كبديل عندما يتعطّل أحد الأقراص الرئيسية. مثلًا، في حالة تطبيق مرآة بقرصين مع قرص احتياطي واحد، سوف تعيد النواة بناء المرآة تلقائيًا (وفوريًا) باستخدام القرص الاحتياطي إذا تعطّل أحد القرصين الرئيسيين. يمكن اعتماد هذا الأسلوب كخط أمان إضافي للبيانات الحساسة.
قد يتساءل المرء عن سبب تفضيل هذا الأسلوب على إعداد مرآة بثلاثة أقراص ببساطة. إن ميزة إعداد ”القرص الاحتياطي“ هي إمكانية مشاركة القرص الاحتياطي بين عدة مصفوفات RAID. يمكن مثلًا، إعداد ثلاثة مصفوفات RAID-1، مع ضمان حماية الفائض حتى في حال تعطل أحد الأقراص باستخدام سبعة أقراص فقط (ثلاثة أزواج واحتياطي واحد)، بدلاً من تسعة أقراص كنا سنحتاجها لإعداد ثلاثة مرايا ثلاثية.
بالرغم من ارتفاع كلفة هذا المستوى (نظراً لأن المساحة التخزينية المتاحة تساوي نصف المساحة الفيزيائية في أحسن الأحوال)، إلا أنه استخدامه منتشر عملياً. فهم هذا المستوى بسيط، وهو يؤدي عملية نسخ احتياطي بسيطة جدًا: بما أن القرصين يخزنان المحتوى نفسه، يمكن فصل أحدهما مؤقتًا دون التأثير على عمل النظام. غالبًا ما يكون أداء الأقراص عند القراءة مرتفعاً، لأن النواة تستطيع قراءة نصف البيانات من كل قرص على التوازي، في حين لا ينخفض الأداء كثيراً عند الكتابة. تبقى البيانات متاحة في مصفوفة RAID-1 ذات N قرص، حتى في حال تعطل N-1 قرص.
‏RAID-4: هذا المستوى من RAID غير منتشر كثيراً. يستخدم هذا المستوى N قرص لتخزين البيانات المفيدة، وقرص إضافي لتخزين معلومات فائضة. إذا تعطل القرص الإضافي، يستطيع النظام إعادة بناء محتوياته اعتمادًا على الأقراص الأخرى. أما إذا تعطل أحد أقراص المعلومات فيستخدم النظام الأقراص المتبقية منها (N-1 قرص) مع القرص الإضافي (قرص الازدواجية – ‎“parity” disk) لإعادة بناء البيانات المفقودة.
إن كلفة RAID-4 ليست مرتفعة جداً بما أن الزيادة في الكلفة هي 1 إلى N كما أنه تأثيره على سرعة القراءة غير ملحوظ، لكن أداء الكتابة ينخفض. من ناحية أخرى، عند كل عملية كتابة على أحد أقراص المعلومات يجب الكتابة على قرص الازدواجية أيضًا، ما قد يؤدي لتقصير عمره بشكل كبير. تبقى البيانات في مصفوفة RAID-4 بأمان في حال عطب قرص واحد (من المصفوفة كلها ذات N+1 قرص).
‏RAID-5: يعالج المستوى RAID-5 مشكلة اللاتناظر التي يعاني منها RAID-4: حيث تنتشر معلومات الازدواجية على جميع الأقراص في مصفوفة N+1، ولا يوجد دور محدد لأي قرص منها.
أداء القراءة والكتابة مطابق لأداء RAID-4. كما أن النظام هنا أيضًا يتحمل تعطل قرص واحد فقط (من أصل N+1 قرص).
‏RAID-6: يمكن اعتبار RAID-6 كامتداد للمستوى RAID-5، إذ أن كل سلسلة مؤلفة من N كتلة تحتاج إلى كتلتين فائضتين، وكل سلسلة من N+2 كتلة تنتشر على N+2 قرص.
كلفة هذا المستوى أعلى بقليل من المستويين السابقين، لكنه يزيد مستوى الأمان إذا يستطيع العمل حتى لو تعطل قرصين (من أصل N+2) دون تأثر البيانات. الجانب السلبي هو أن عمليات الكتابة على الأقراص تحتاج لكتابة كتلة بيانات واحدة وكتلتين فائضتين، وهذا يجعل الكتابة أبطأ.
‏RAID-1+0: للأمانة العلمية هذا ليس مستوى RAID، لكنه تركيب لمستويين وراء بعضهما. إذا كان لدينا N‏×2 قرص، يمكننا أن نجمع كل زوج منها للحصول على N قرص من مستوى RAID-1؛ ثم نجمع هذه الأقراص في قرص واحد إما باستخدام ”linear RAID“ أو عبر LVM. إذا استخدمنا LVM فإننا نتجاوز حدود RAID، لكن هذه ليست مشكلة في الواقع.
تتحمل مصفوفات RAID-1+0 تعطل عدة أقراص: فالمصفوفة الموضحة سابقاً يمكن أن تتحمل تعطل N قرص إذا كانت تحوي ‎2×‎N قرص، بشرط أن ينجو قرص واحد على الأقل من كل زوج من أقراص RAID-1.
التعمق أكثر RAID-10
يعتبر RAID-10 كمرادف للمستوى RAID-1+0 عموماً، لكن هناك خاصية في لينكس تجعل الثاني حالة خاصة من الأول. يسمح هذا الإعداد ببناء نظام تُخزَّن فيه كل كتلة على قرصين مختلفين، حتى لو كان عدد الأقراص في النظام فردياً، ويتبع توزيع النسخ على الأقراص نموذجاً محدداً يمكن تعديله.
سيختلف مستوى الأداء تبعاً لنموذج التقسيم المتبع ومستوى الفائض، وحمل الحيز التخزيني المنطقي.

من الواضح أن اختيار مستوى RAID الملائم يعتمد على متطلبات وقيود كل تطبيق. لاحظ أن الحاسوب الواحد يمكن أن يحوي عدة مصفوفات RAID ذات مستويات مختلفة.

12.1.1.2. إعداد RAID

يحتاج إعداد RAID لحزمة mdadm؛ التي توفر الأمر mdadm الذي يستخدم لإنشاء وتعديل مصفوفات RAID، كما توفر أيضًا سكربتات وأدوات تدمج البرنامج في أجزاء نظام التشغيل الأخرى، بما فيه نظام المراقبة.

مثالنا هو مُخدِّم فيه عدد من الأقراص، بعضها مستخدم، والباقي متاح لإعداد مصفوفة RAID. هذه هي الحالة الإبتدائية للأقراص والأقسام:

القرص sdb، ‏4 غ.ب، متاح بالكامل؛
القرص sdc، ‏4 غ.ب، متاح بالكامل أيضاً؛
القسم sdd2 من القرص sdd متاح (حوالي 4 غ.ب)؛
أخيراً، القرص sde، أيضاً 4 غ.ب متاح بالكامل.

سوف نستخدم هذه العناصر الفيزيائية لبناء حيزين تخزينيين، أحدهما RAID-0، والآخر RAID-1 (مرآة). دعنا نبدأ ببناء حيز RAID-0:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
# mdadm --query /dev/md0
/dev/md0: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed May  6 09:24:34 2015
     Raid Level : raid0
     Array Size : 8387584 (8.00 GiB 8.59 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Wed May  6 09:24:34 2015
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : mirwiz:0  (local to host mirwiz)
           UUID : bb085b35:28e821bd:20d697c9:650152bb
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 2095104 4k blocks and 524288 inodes
Filesystem UUID: fff08295-bede-41a9-9c6a-8c7580e520a6
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/raid-0
# mount /dev/md0 /srv/raid-0
# df -h /srv/raid-0
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.9G   18M  7.4G   1% /srv/raid-0

يحتاج الأمر mdadm --create عدة متغيرات: اسم الحيز الذي سيتم إنشاؤه (/dev/md*، حيث ترمز md إلى Multiple Device―”أجهزة متعددة“)، ومستوى RAID، وعدد الأقراص (هذا المتغير إلزامي رغم أنه لا يفيد إلا مع مستويات RAID-1 وما فوق)، والأجهزة الفيزيائية التي ستستخدم. بعد إنشاء الحيز، يمكننا استخدامه كما نستخدم أي قسم عادي، فيمكن إنشاء نظام ملفات عليه، وربطه بشجرة الملفات، وغير ذلك. لاحظ أن إنشاء حيز RAID-0 على md0 هو محض صدفة، وترقيم المصفوفة لا يشترط أن يتعلق بمستوى RAID المختار. كما يمكن إنشاء مصفوفات RAID بأسماء محددة، عبر إعطاء mdadm متغير مثل /dev/md/linear بدلاً من /dev/md0.

يتم إنشاء RAID-1 بأسلوب مشابه، ولا تظهر الاختلافات إلا بعد عملية الإنشاء:

# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1%
Continue creating array؟ y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
# mdadm --query /dev/md1
/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.2
  Creation Time : Wed May  6 09:30:19 2015
     Raid Level : raid1
     Array Size : 4192192 (4.00 GiB 4.29 GB)
  Used Dev Size : 4192192 (4.00 GiB 4.29 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Wed May  6 09:30:40 2015
          State : clean, resyncing (PENDING) 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       1       8       64        1      active sync   /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
          State : clean
[...]

هناك بضعة ملاحظات. أولاً، يلاحظ mdadm اختلاف سعة العناصر الفيزيائية؛ وبما أن هذا يعني ضياع بعض المساحة من العنصر الأكبر، يطلب من المستخدم تأكيد العملية.

الأهم من هذا هو حالة المرآة. لاحظ كيف كانت resyncing ثم انتقلت إلى active. إن الحالة الطبيعية لمرآة RAID هي أن تتطابق محتويات القرصين. لكن لا شيء يضمن هذا التطابق عند إنشاء المصفوفة أول مرة، ولذلك يعمل نظام RAID الفرعي على ضمان هذا بنفسه، ويبدأ طور مزامنة المحتويات بعد إنشاء المصفوفة مباشرة. بعد فترة من الزمن (تختلف المدة حسب حجم الأقراص الفعلي...)، تنتقل مصفوفة RAID إلى حالة ”active“ أو ”clean“. لاحظ أن المصفوفة تكون في الوضع degraded خلال طور إعادة البناء، وأن الفائض التخزيني غير جاهز بعد. إذا تعطل قرص أثناء مرحلة الخطر تلك، فسوف يؤدي ذلك إلى خسارة البيانات كلها. لكن نادرًا ما تستخدم مصفوفات RAID الجديدة لتخزين كميات كبيرة من البيانات الحساسة قبل أن تنتهي مرحلة تهيئتها الأولية. لاحظ أيضًا أن /dev/md1 جاهز للاستخدام حتى في وضع degraded، وأنه يمكن إنشاء نظام ملفات عليه، كما يمكن نسخ البيانات إليه أيضًا.

تلميح إنشاء مرآة في وضع degraded

أحيانًا لا يكون القرصان جاهزين فورًا لحظة إنشاء مرآة RAID-1، مثلاً يمكن أن أحد القرصين الذين نريد استخدامهما مستخدم أصلاً لتخزين البيانات التي نريد نقلها إلى المصفوفة. في مثل هذه الحالات، من الممكن إنشاء مصفوفة RAID-1 في الوضع degraded باستخدام قرص واحد من خلال تمرير missing كمعامل للأمر mdadm بدلاً من تمرير اسم الملف الذي يمثل القرص. بعد نسخ البيانات إلى ”المرآة“، يمكن إضافة القرص القديم إلى المصفوفة. عندها تبدأ عملية المزامنة، للوصول إلى الحالة الآمنة التي أردناها في البداية.

تلميح إعداد مرآة بدون مزامنة

تستخدم مصفوفات RAID-1 بعد إنشائها غالبًا كأقراص جديدة، وتعامل على أنها فارغة. أي أن المحتويات الأولية للقرص عديمة القيمة، لأن كل ما نحتاجه هو أن نتأكد أننا سوف نستطيع لاحقاً الوصول البيانات التي سنكتبها بعد إنشاء الحيز التخزيني الجديد، خصوصاً نظام الملفات.

قد يتساءل المرء عندئذ عن فائدة مزامنة الأقراص عند إنشائها. ما الفرق إذا كانت محتويات المصفوفة متزامنة إذا كنا لن نقرأ من المصفوفة شيئًا قبل محوها وتهيئتها؟

لحسن الحظ، يمكن تفادي طور المزامنة هذا بتمرير الخيار‎ --assume-clean للأمر mdadm. لكن هذا الخيار قد يسبب مفاجآت لو حاولنا قراءة البيانات الأولية (مثلاً إذا كانت الأقراص الفيزيائية تحوي نظام ملفات مسبقًا)، لذلك فإن هذا الخيار معطل افتراضيًا.

دعنا نرى ما سيحدث عندما يتعطل أحد عناصر مصفوفة RAID-1. يمكن محاكاة عطب قرص ما باستخدام الخيار --fail مع الأمر mdadm:

# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Wed May  6 09:39:39 2015
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 19

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       0        0        2      removed

       1       8       64        -      faulty   /dev/sde

تبقى محتويات المصفوفة متاحة (وإذا كانت مرتبطة بشجرة الملفات، فلن تشعر التطبيقات بشيء)، لكن البيانات لم تعد بأمان: فإذا تعطل القرص sdd أيضًا، سوف تضيع البيانات. نحن لا نريد أن نخاطر بذلك، ولهذا سوف نستبدل القرص المعطوب بقرص جديد، sdf:

# mdadm /dev/md1 --add /dev/sdf
mdadm: added /dev/sdf
# mdadm --detail /dev/md1
/dev/md1:
[...]
   Raid Devices : 2
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Wed May  6 09:48:49 2015
          State : clean, degraded, recovering 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

 Rebuild Status : 28% complete

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 26

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      spare rebuilding   /dev/sdf

       1       8       64        -      faulty   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Wed May  6 09:49:08 2015
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 41

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      active sync   /dev/sdf

       1       8       64        -      faulty   /dev/sde

هنا أيضاً تبدأ النواة طور إعادة بناء تلقائيًا، وتبقى المصفوفة خلال هذا الطور في الوضع degraded أيضًا لكنها متاحة للوصول. ترجع مصفوفة RAID-1 إلى الحالة الطبيعية فور انتهاء إعادة البناء. يمكن عندها أن نخبر النظام أننا سوف نزيل القرص sde من المصفوفة، حتى تبقى كمرآة RAID كلاسيكية بقرصين فقط:

# mdadm /dev/md1 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      active sync   /dev/sdf

عند هذه اللحظة يمكن فصل القرص الفيزيائي عند إيقاف تشغيل المخدم، أو يمكن حتى فصلها مباشرة إذا كان العتاد يسمح بالتبديل الساخن hot-swap. تسمح بعض متحكمات SCSI، ومعظم أقراص SATA، والسواقات الخارجية التي تعمل عبر USB أو Firewire بهذا النوع من التبديل.

12.1.1.3. النسخ الاحتياطي للإعدادات

تُحفَظ معظم البيانات الفوقية (meta-data) الخاصة بمصفوفات RAID مباشرة على الأقراص التي تنتمي لهذه المصفوفات، حتى تتعرف النواة على المصفوفات ومكوناتها وتجمعها آليًا عند إقلاع النظام. لكن الأفضل أخذ نسخة احتياطية عن هذه البيانات، لأن عملية التعرف هذه قد تفشل، ومن المتوقع ألا تفشل هذه العملية إلا في الظروف الحساسة. فلو كان عطل القرص sde في مثالنا حقيقيًا (وليس ظاهريًا كما فعلنا) ثم أعيد تشغيل النظام دون إزالة هذا القرص sde، فقد يعود هذا القرص إلى العمل ثانية نتيجة عملية الاستكشاف أثناء إعادة الإقلاع. سوف تصطدم النواة إذًا بثلاثة أقراص فيزيائية، كلٌّ منها يدعي أنه يحوي نصف الحيز التخزيني المقابل للمصفوفة نفسها. أو يمكن أن يحدث التباس عند دمج مصفوفات RAID من مخدمين إلى مخدم واحد فقط. إذا كانت هذه المصفوفات تعمل بشكل صحيح قبل نقل الأقراص، سوف تتمكن النواة من التعرف على الأزواج وجمعها بشكل صحيح؛ لكن إذا كانت الأقراص على المخدم القديم مجموعة مع بعضها في مصفوفة اسمها md1، وكان المخدم الجديد يحوي md1 أيضًا، فسوف تعاد تسمية إحدى المرآتين.

إذاً لا بد من أخذ نسخة احتياطية عن الإعدادات، حتى لو كانت للاستئناس فقط. الطريقة المعيارية لعمل هذا هي تحرير الملف /etc/mdadm/mdadm.conf، إليك مثالاً عن هذا الملف:

مثال 12.1. ملف إعداد mdadm

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
DEVICE /dev/sd*

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

# This configuration was auto-generated on Thu, 17 Jan 2013 16:21:01 +0100
# by mkconf 3.2.5-3

أحد أهم التفاصيل هو خيار DEVICE، الذي يعدد الأجهزة التي يفحصها النظام بحثًا عن مكونات مصفوفات RAID عند الإقلاع. لقد استبدلنا في مثالنا القيمة الافتراضية – partitions containers – بلائحة واضحة تسرد أسماء ملفات الأجهزة، ذلك لأننا اخترنا استخدام بعض الأقراص الكاملة وليس الأقسام فقط.

آخر سطرين في مثالنا يسمحان للنواة بإسناد رقم الحيز المناسب إلى المصفوفة المناسبة. إن البيانات الفوقية المخزنة على الأقراص نفسها تكفي لإعادة جمع المصفوفات، لكنها لا تكفي لمعرفة رقم الحيز (ولا معرفة اسم /dev/md* الموافق للجهاز).

لحسن الحظ، يمكن توليد هذه الأسطر آليًا:

# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

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

12.1.2. LVM

Logical Volume Manager ًأو اختصارا LVM هو أسلوب آخر لعزل الأقراص التخزينية المنطقية عن الأقراص الفيزيائية، وهو يركز على زيادة المرونة بدلاً من زيادة الوثوقية. يسمح LVM بتغيير القرص المنطقي بشكل شفاف بالنسبة للتطبيقات؛ فمثلاً، يمكن إضافة أقراص فيزيائية جديدة، ونقل البيانات إليها، وإزالة القديمة، دون فصل القرص المنطقي عن شجرة الملفات.

12.1.2.1. مفاهيم LVM

هذه المرونة نحرزها من خلال مستوى من العزل يشمل ثلاثة مفاهيم.

الأول هو PV، أي Physical Volume (الحيز الفيزيائي) وهو أقرب وحدة إلى العتاد: يمكن أن يتألف من قسم من أحد الأقراص، أو قرص كامل، أو أي جهاز كتلي آخر (بما في ذلك مصفوفات RAID على سبيل المثال). لاحظ أنه عندما يتم إعداد عنصر فيزيائي ليشغل دور PV في LVM، فيجب التعامل معه من LVM فقط، وإلا فإن النظام سوف يضطرب.

يمكن تجميع عدة PV ضمن VG ‏(Volume Group)، التي يمكن أن نعتبرها بمثابة أقراص ظاهرية قابلة للتوسعة. إن VGs مكونات مجردة، ولا تظهر بشكل ملفات أجهزة في فرع /dev، لذلك لا يمكن استخدامها مباشرة.

النوع الثالث من المكونات هو LV‏ (Logical Volume – الحيز المنطقي)، وهو قطعة من VG؛ فإذا اعتبرنا VG بمثابة قرص، عندها يقابل LV القسم من القرص. يظهر LV كجهاز كتلي له مدخلة في /dev، ويمكن استخدامه كما يستخدم أي قسم فيزيائي آخر (لاستضافة نظام ملفات أو مساحة swap عادة).

أهم شيء هنا هو أن تقسيم VG إلى LVs مستقل تمامًا عن المكونات الفيزيائية للـ VG (وهي PVs). يمكن تقسيم VG يتألف من مكون فيزيائي واحد (قرص مثلاً) إلى دزينة من الأقراص المنطقية؛ كما يمكن أن يتألف VG من العديد من الأقراص الفيزيائية ثم يظهر كحيز منطقي كبير مفرد. القيد الوحيد طبعاً هو أن الحجم الكلي المتاح للتخزين على LVs لا يمكن أن يكون أكبر من السعة الكلية للحيزات الفيزيائية في الـVG.

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

وعلى أية حال، تذكر أن LV لا يرتبط مباشرة بأي PV معيّن. من الممكن التأثير على موقع تخزين بيانات أحد الحيزات المنطقية فيزيائيًا، لكن هذه الإمكانية ليست جوهرية في الاستخدامات العادية. وعلى صعيد آخر: عندما تتطور المكونات الفيزيائية للـVG، يمكن تهجير مواقع التخزين الفيزيائية لأحد LVs بين الأقراص (مع البقاء ضمن PVs المخصصة للـVG بالطبع).

12.1.2.2. إعداد LVM

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

من القرص sdb، القسم sdb2، الحجم 4 غ.ب؛
من القرص sdc، القسم sdc3، الحجم 3 غ.ب؛
القرص sdd، متاح بالكامل، 4 غ.ب؛
من القرص sdf، القسم sdf1، ‏4 غ.ب؛ والقسم sdf2، ‏5 غ.ب.

بالإضافة لذلك، دعنا نفترض أن القرصين sdb وsdf أسرع من البقية.

هدفنا هو إعداد ثلاثة حيزات منطقية لثلاثة تطبيقات: مخدم ملفات يحتاج 5 غ.ب. من المساحة التخزينية، وقاعدة بيانات (1 غ.ب) وبعض المساحة للنسخ الاحتياطية (12 غ.ب). يحتاج التطبيقان الأوليان أداء جيداً، بينما النسخ الاحتياطية أقل حرجاً من حيث الحاجة لسرعة النقل. تمنعنا كل هذه القيود من استخدام الأقسام المتاحة مباشرة كما هي؛ لكن يمكن أن يسمح استخدام LVM بعزل الحجم الفيزيائي للأجهزة، بحيث يبقى القيد الوحيد هو المساحة الكلية المتوفرة فقط.

الأدوات المطلوبة كلها في حزمة lvm2 واعتمادياتها. بعد تثبيتها، يتطلب إعداد LVM ثلاث خطوات، تقابل المستويات الثلاث للمفاهيم.

أولاً، نجهز الحيزات الفيزيائية باستخدام pvcreate:

# pvdisplay
# pvcreate /dev/sdb2
  Physical volume "/dev/sdb2" successfully created
# pvdisplay
  "/dev/sdb2" is a new physical volume of "4.00 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/sdb2
  VG Name               
  PV Size               4.00 GiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I

# for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done
  Physical volume "/dev/sdc3" successfully created
  Physical volume "/dev/sdd" successfully created
  Physical volume "/dev/sdf1" successfully created
  Physical volume "/dev/sdf2" successfully created
# pvdisplay -C
  PV         VG   Fmt  Attr PSize PFree
  /dev/sdb2       lvm2 ---  4.00g 4.00g
  /dev/sdc3       lvm2 ---  3.09g 3.09g
  /dev/sdd        lvm2 ---  4.00g 4.00g
  /dev/sdf1       lvm2 ---  4.10g 4.10g
  /dev/sdf2       lvm2 ---  5.22g 5.22g

حتى الآن، كل شيء على ما يرام؛ لاحظ أنه يمكن إعداد PV على قرص كامل كما يمكن ذلك على أقسام الأقراص. يسرد الأمر pvdisplay الحيزات الفيزيائية الموجودة، وذلك في صيغتين مختلفتين للخرج، كما هو موضح أعلاه.

دعنا الآن نجمع هذه العناصر الفيزيائية في VG باستخدام vgcreate. سوف نجمع الحيزات الفيزيائية من الأقراص السريعة فقط في مجموعة اسمها vg_critical؛ أما المجموعة الأخرى، vg_normal، فسوف تحوي عناصر سريعة وأخرى بطيئة.

# vgdisplay
  No volume groups found
# vgcreate vg_critical /dev/sdb2 /dev/sdf1
  Volume group "vg_critical" successfully created
# vgdisplay
  --- Volume group ---
  VG Name               vg_critical
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               8.09 GiB
  PE Size               4.00 MiB
  Total PE              2071
  Alloc PE / Size       0 / 0   
  Free  PE / Size       2071 / 8.09 GiB
  VG UUID               bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp

# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2
  Volume group "vg_normal" successfully created
# vgdisplay -C
  VG          #PV #LV #SN Attr   VSize  VFree 
  vg_critical   2   0   0 wz--n-  8.09g  8.09g
  vg_normal     3   0   0 wz--n- 12.30g 12.30g

الأوامر هنا أيضًا واضحة جداً ( كما أن vgdisplay يوفر صيغتين للخرج). لاحظ أنه من الممكن استخدام قسمين من القرص الفيزيائي نفسه في مجموعتين مختلفتين. لاحظ أيضًا أننا استخدمنا بادئة vg_ عند تسمية VGs التي أنشأناها ولكن هذا مجرد اصطلاح.

لدينا الآن ”قرصين ظاهريين“، أحجامهما تقريبًا 8 غ.ب و 12 غ.ب على التوالي. دعنا الآن نقطعهما إلى ”أقسم ظاهرية“ (LVs). نحتاج الأمر lvcreate، ونحتاج أيضًا تعليمة أكثر تعقيداً بقليل:

# lvdisplay
# lvcreate -n lv_files -L 5G vg_critical
  Logical volume "lv_files" created
# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg_critical/lv_files
  LV Name                lv_files
  VG Name                vg_critical
  LV UUID                J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT
  LV Write Access        read/write
  LV Creation host, time mirwiz, 2015-06-10 06:10:50 -0400
  LV Status              available
  # open                 0
  LV Size                5.00 GiB
  Current LE             1280
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

# lvcreate -n lv_base -L 1G vg_critical
  Logical volume "lv_base" created
# lvcreate -n lv_backups -L 12G vg_normal
  Logical volume "lv_backups" created
# lvdisplay -C
  LV         VG          Attr     LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync  Convert
  lv_base    vg_critical -wi-a---  1.00g                                           
  lv_files   vg_critical -wi-a---  5.00g                                           
  lv_backups vg_normal   -wi-a--- 12.00g

يوجد معاملان مطلوبان عند إنشاء الحيزات المنطقية؛ ويجب تمريرهما إلى الأمر lvcreate كخيارات. الأول هو اسم LV الذي سوف ننشئه ويحدد بالخيار -n، والثاني هو حجم LV ويعطى عمومًا بالخيار -L. نحتاج أيضًا إعلام الأمر باسم VG التي يطبق عليها طبعًا، وهذا هو المعامل الأخير في التعليمة.

التعمق أكثر خيارات lvcreate

للأمر lvcreate العديد من الخيارات تسمح بضبط عملية إنشاء LV.

دعنا أولاً نشرح الخيار -l، الذي يسمح بتحديد حجم الحيز المنطقي كعدد من الكتل (بدلاً من استخدام الواحدات ”البشرية“ كما فعلنا في المثال السابق). هذه الكتل (التي تدعى PEs، أي physical extents، بحسب مصطلحات LVM) هي وحدات متجاورة من المساحة التخزينية في الحيزات الفيزيائية، ولا يمكن أن تقسم الواحدة منها بين الحيزات المنطقية. عندما يحتاج المرء لتحديد السعة التخزينية للحيز المنطقي بدقة أكبر، مثلاً لاستخدام كامل المساحة المتوفرة، سيكون الخيار -l مفضلاً على الخيار -L غالبًا.

من الممكن أيضاً الإشارة إلى الموقع الفيزيائي لتخزين LV، بحيث تخزن ”استطالاته“ (extents) على PV معين (مع البقاء ضمن الحيزات الفيزيائية المخصصة للـVG طبعاً). نظراً لأننا نعلم أن sdb أسرع من sdf، ربما نريد تخزين lv_base هناك إذا أردنا منح الأفضلية لمخدم قاعدة البيانات على مخدم الملفات. يصبح الأمر كالتالي: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. لاحظ أن هذا الأمر قد يفشل إذا لم يحو الحيز الفيزيائي عدداً كافياً من الاستطالات الحرة. في هذا المثال، لعلنا سنحتاج إلى إنشاء lv_base قبل lv_files لتفادي هذا الموقف ― أو إلى تحرير بعض المساحة على sdb2 باستخدام الأمر pvmove.

ينتهي المطاف بالحيزات المنطقية بعد إنشائها كملفات أجهزة كتلية في /dev/mapper/:

# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Jun 10 16:52 control
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jun 10 17:05 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jun 10 17:05 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Jun 10 17:05 /dev/dm-2

ملاحظة التعرف الآلي على حيزات LVM

عند إقلاع الحاسب، تنفذ وحدة الخدمة lvm2-activation التابعة لنظام systemd الأمر vgchange -aay ”لتنشيط activate“ مجموعات الحيزات: حيث يفحص الأجهزة المتوفرة؛ وتُسجَّل الأجهزة التي تمت تهيئتها كحيزات فيزيائية ضمن نظام LVM الفرعي، وتجمَع الحيزات التي تنتمي لمجموعات في مجموعاتها، ثم تنشط الحيزات المنطقية وتصبح متوفرة. لا حاجة إذاً لتحرير أي ملفات إعداد عند إنشاء أو تعديل حيزات LVM.

لكن لاحظ أن خريطة عناصر LVM ( الحيزات الفيزيائية والمنطقية، والمجموعات) تُنسَخ احتياطيًا إلى /etc/lvm/backup، وهذه قد تفيد في حال حدوث مشكلة (أو لاختلاس النظر تحت الغطاء).

لتسهيل الأمور، يتم إنشاء اختصارات رمزيّة أيضًا في مجلدات بأسماء VGs نفسها:

# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_backups -> ../dm-2

يمكن استخدام LVs عندها مثل أي قسم نظامي تماماً:

# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 3145728 4k blocks and 786432 inodes
Filesystem UUID: b5236976-e0e2-462e-81f5-0ae835ddab1d
[...]
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/backups
# mount /dev/vg_normal/lv_backups /srv/backups
# df -h /srv/backups
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_normal-lv_backups   12G   30M   12G   1% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base    /srv/base       ext4 defaults 0 2
/dev/vg_critical/lv_files   /srv/files      ext4 defaults 0 2
/dev/vg_normal/lv_backups   /srv/backups    ext4 defaults 0 2

من وجهة نظر التطبيقات، تم تحويل الأقسام الصغيرة العديدة إلى حيز كبير واحد بحجم 12غ.ب، وله اسم ألطف.

12.1.2.3. ‏LVM مع الزمن

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

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  5.0G  4.6G  146M  97% /srv/files
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync  Convert
  lv_files vg_critical -wi-ao-- 5.00g
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   2   2   0 wz--n- 8.09g 2.09g
# lvresize -L 7G vg_critical/lv_files
  Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 7.00 GiB (1792 extents).
  Logical volume lv_files successfully resized
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync  Convert
  lv_files vg_critical -wi-ao-- 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/vg_critical/lv_files is now 1835008 (4k) blocks long.

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  6.9G  4.6G  2.1G  70% /srv/files

تحذير تحجيم نظم الملفات

لا تدعم جميع نظم الملفات التحجيم أثناء الاتصال (online resizing)؛ بالتالي يجب فصل نظام الملفات أولاً (unmount) ثم إعادة ربطه بعد إنهاء العملية. طبعاً إذا كان هناك رغبة بتصغير المساحة المخصصة لأحد الحيزات المنطقية، فيجب تقليص نظام الملفات اولاً؛ أما في حال التكبير فيكون الترتيب معكوساً: حيث يجب تكبير الحيز المنطقي قبل توسعة نظام الملفات داخله. هذا منطقي تمامًا، فلا يمكن أن يكون حجم نظام الملفات أكبر من حجم الجهاز الكتلي الذي يحويه بأي حال من الأحوال (سواء كان الجهاز قسمًا فيزيائياً أو كان حيز تخزين منطقي).

يمكن توسعة نظم الملفات ext3، وext4 و xfs دون فصل الاتصال (online)؛ أما التقليص فيحتاج الفصل عن شجرة الملفات. يسمح نظام الملفات reiserfs بالتحجيم أثناء الاتصال في الاتجاهين. أما صاحب الجلالة ext2 فلا يسمح بأي منهما، ويحتاج للفصل في جميع الحالات.

يمكننا توسعة الحيز الذي يستضيف قاعدة البيانات بنفس الأسلوب، لولا أننا وصلنا لحدود المساحة المتاحة على المجموعة:

# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 1008M  854M  104M  90% /srv/base
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree 
  vg_critical   2   2   0 wz--n- 8.09g 92.00m

لا مشكلة، حيث يسمح LVM بإضافة حيزات فيزيائية إلى المجموعات القائمة مسبقًا. مثلاً، ربما لاحظنا أن القسم sdb1 الذي كان يستخدم خارج نظام LVM حتى الآن، كان يحتوي على أرشيفات يمكن نقلها إلى lv_backups. يمكننا الآن إعادة استخدام القسم ودمجه في مجموعة الحيزات الحالية، واستثمار بعض المساحة الحرة. هذه هي وظيفة الأمر vgextend. طبعاً يجب تهيئة القسم كحيز فيزيائي قبل ذلك. بعد توسيع المجموعة، يمكننا استخدام أوامر مشابهة للسابقة لتمديد الحيز المنطقي وتوسعة نظام الملفات بعد ذلك:

# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created
# vgextend vg_critical /dev/sdb1
  Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   3   2   0 wz--n- 9.09g 1.09g
# [...]
[...]
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  2.0G  854M  1.1G  45% /srv/base

التعمق أكثر LVM متقدم

يسمح LVM باستخدامات متقدمة أكثر، حيث يمكن تحديد الكثير من التفاصيل يدوياً. مثلاً، يستطيع مدير النظام تعديل حجم الكتل التي تتركب منها الحيزات الفيزيائية والمنطقية، كما يستطيع ضبط تخطيطها الفيزيائي (physical layout). من الممكن أيضًا نقل الكتل بين الحيزات الفيزيائية، لضبط الأداء بدقة مثلاً، أو تحرير PV معين عند الحاجة لإخراج القرص الفيزيائي الموافق من المجموعة (سواء لنقله إلى VG أخرى أو إزالته من LVM بالكامل) كتيبات التعليمات التي تصف الأوامر واضحة ومفصلة بشكل عام. صفحة lvm(8)‎ هي نقطة بدء جيدة.

12.1.3. ‏RAID أو LVM؟

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

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

ملاحظة إذا كان الأداء مهمًا…

إذا كانت سرعة الدخل والخرج جوهرية، خصوصًا من ناحية أزمنة الوصول، فإن استخدام LVM أو RAID أو جمعهما معاً بإحدى الطرق قد يؤثر على الأداء، وأحياناً يجب أخذ هذا بعين الاعتبار عند اختيار إحدى التقنيتين. إلا أن هذه الاختلافات في الأداء صغيرة حقاً، ولا يمكن قياسها إلا في حالات قليلة. إذا كان الأداء مهمًا، فإن أكبر زيادة يمكن الحصول عليها تكون باستخدام وسائط تخزين غير ميكانيكية (سواقات الحالة الصلبة SSD – ‏solid-state drives)؛ كلفة الميغابايت في هذه الوسائط أعلى من كلفته في الأقراص الصلبة العادية، كما أن سعتها أصغر عادة، لكنها تقدم أداء باهراً للوصول العشوائي. إذا كان نمط الاستخدام يشتمل على العديد من عمليات الدخل والخرج المنتشرة على أنحاء نظام الملفات، كما في حالة قواعد البيانات التي تجرى عليها استعلامات معقدة مثلاً، فإن جدوى تشغيلها على SSD أكبر بكثير من استخدام LVM بدلاً من RAID أو العكس. يجب اتخاذ القرار في هذه الحالات اعتماداً على معايير أخرى غير السرعة، نظراً لأن موضوع الأداء يمكن معالجته بسهولة باستخدام SSD.

حالة الاستخدام الثالثة الجديرة بالاهتمام هي عندما يحتاج المرء جمع قرصين في حيز تخزيني واحد، وذلك بهدف زيادة الأداء أو للحصول على نظام ملفات أكبر من سعة الأقراص المتوفرة. يمكن معالجة هذه الحالة باستخدم RAID-0 (أو حتى linear-RAID) أو باستخدام LVM. في هذه الحالة، يقع الاختيار على LVM ما لم تكن هناك قيود إضافية (الانسجام مع بقية الحواسيب إذا كانت تعتمد على RAID مثلاً). الإعداد الأولي لنظام LVM أكثر تعقيداً بقليل، ولكن المرونة الإضافية التي يوفرها تعوض هذه الزيادة الطفيفة في التعقيدات عندما تتغير المتطلبات التخزينية أو إذا دعت الحاجة لإضافة أقراص جديدة.

ثم نصل طبعاً إلى حالة الاستخدام الشيقة حقاً، وهي عندما نحتاج نظاماً تخزينياً يقاوم أعطال العتاد ومرناً من ناحية توزيع الحيزات التخزينية. لا يستطيع RAID وحده ولا LVM معالجة المتطلبين معاً؛ هذه هي الحالة التي نستخدم فيها الاثنين في الوقت نفسه — أو بالأحرى، نستخدم أحدهما فوق الآخر. أكثر طريقة مستخدمة منذ وصل RAID و LVM إلى مرحلة النضج هي ضمان حماية البيانات أولاً من خلال جمع الأقراص في عدد صغير من مصفوفات RAID الكبيرة، ثم استخدام هذه المصفوفات كحيزات فيزيائية لنظام LVM؛ بعدها تقطع LVs إلى أقسام منطقية لإنشاء نظم الملفات. إن ميزة هذا الأسلوب هي أنه عندما يتعطل قرص ما، سنحتاج لإعادة بناء عدد صغير من مصفوفات RAID، وبالتالي اختصار الوقت الذي يقضيه مدير النظام في الاستعادة.

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

سوف نجمع RAID-1 و LVM معاً لإيفاء هذه الشروط. سوف نصل القرصين إلى متحكمي SATA مختلفين لتحسين الوصول المتوازي وتخفيف خطر الأعطال المتزامنة، بالتالي سوف يظهر القرصان باسمي sda وsdc. سوف نقطِّع القرصين وفق المخطط التالي:

# fdisk -l /dev/sda

Disk /dev/sda: 300 GB, 300090728448 bytes, 586114704 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00039a9f

Device    Boot     Start       End   Sectors Size Id Type
/dev/sda1 *         2048   1992060   1990012 1.0G fd Linux raid autodetect
/dev/sda2        1992061   3984120   1992059 1.0G 82 Linux swap / Solaris
/dev/sda3        4000185 586099395 582099210 298G 5  Extended
/dev/sda5        4000185 203977305 199977120 102G fd Linux raid autodetect
/dev/sda6      203977306 403970490 199993184 102G fd Linux raid autodetect
/dev/sda7      403970491 586099395 182128904  93G 8e Linux LVM

جمعنا القسمين الأولين من كل قرص (حوالي 1 غ.ب) في حيز RAID-1، هو md0. هذه المرآة ستستخدم مباشرة لتخزين نظام الملفات الجذر.
استخدمنا القسمين sda2 وsdc2 كقسمي swap، ما منحنا مساحة تبديل سعتها الكلية 2 غ.ب. ومع 1 غ.ب من الذاكرة RAM، أصبحت كمية الذاكرة المتوفرة لمحطة العمل مريحة.
جمعنا القسمين sda5 وsdc5، كما جمعنا sda6 وsdc6 في حيزي RAID-1 حجم كل منهما حوالي 100 غ.ب، هما md1 وmd2. تمت تهيئة كل من هاتين المرآتين كحيز LVM فيزيائي، وتم تخصيصهما للمجموعة vg_raid. هذه VG تحوي تقريبًا 200 غ.ب من المساحة المؤمنة.
استخدمنا القسمين المتبقيين، sda7 وsdc7، مباشرة بشكل حيزات فيزيائية، وخصصناهما لمجموعة حيزات أخرى تدعى vg_bulk، حيث أصبحت تحوي تقريبًا 200 غ.ب من المساحة.

بعد إنشاء VGs، يمكن تقطيعها بطريقة مرنة جداً. يجب أن نأخذ بعين الاعتبار أن LVs التي ننشئها في vg_raid ستبقى محفوظة حتى لو تعطل أحد القرصين، لكن هذا لا ينطبق على LVs التي ننشئها في vg_bulk؛ من ناحية أخرى، سوف تحجز الحيزات المنطقية في vg_bulk على القرصين على التوازي، ما يسمح بسرعات قراءة أو كتابة أكبر للملفات الكبيرة.

إذن سوف ننشئ الحيزات المنطقية lv_usr وlv_var وlv_home على vg_raid، لتخزين نظم الملفات المقابلة لها؛ وسنستخدم حيز منطقي آخر كبير باسم lv_movies لتخزين النسخ النهائية من الأفلام بعد التحرير. سوف نقسم الـVG الأخرى إلى حيز كبير باسم lv_rushes، للبيانات القادمة مباشرة من كميرات الفيديو الرقمية، وlv_tmp للملفات المؤقتة. تحديد موقع مساحة العمل ليس خياراً واضحاً تماماً: في حين أن الأداء الجيد مطلوب لذلك القسم، هل يستحق هذا المخاطرة بخسارة العمل إذا تعطل أحد الأقراص أثناء جلسة التحرير؟ اعتماداً على إجابة ذلك السؤال، سوف ننشئ الحيز المنطقي المناسب على إحدى المجموعتين.

الآن أصبح لدينا بعض الفائض يضمن لنا حماية البيانات الهامة ومرونة كبيرة في توزيع المساحة المتوفرة بين التطبيقات. على فرض أن هناك حاجة لتثبيت برمجيات جديدة لاحقًا (لتحرير المقاطع الصوتية مثلاً)، يمكن توسيع الحيز المنطقي المقابل لنظام ملفات /usr/ بسهولة.

ملاحظة لماذا ثلاثة حيزات RAID-1؟

كان يمكن إعداد حيز RAID-1 واحد فقط ليعمل كحيز فيزيائي نضع عليه vg_raid. فلم أنشأنا ثلاثة منها إذاً؟

السبب وراء القسم الأول (فصل md0 عن البقية) هو أمان البيانات: فالبيانات التي تكتب على مرايا RAID-1 هي نفسها على جميع الأقراص، ولذلك يمكن تجاوز طبقة RAID وربط أحد أقراص المصفوفة مباشرة. في حال مواجهة علة في النواة مثلاً، أو إذا تضررت البيانات الفوقية التي تُعرّف LVM، يمكن عندها إقلاع نظام أصغري يسمح بالوصول إلى البيانات الحساسة مثل مخطط الأقراص في حيزات RAID وLVM؛ يمكن حينئذ إعادة بناء البيانات الفوقية والوصول للملفات ثانية، بحيث يعود النظام إلى حالته النظامية.

أما السبب وراء القسم الثاني (فصل md1 عن md2) فهو أقل وضوحاً، والداعي له هو عدم ثقتنا بطبيعة التغييرات التي سنحتاجها في المستقبل. قد لا نعرف الحاجات التخزينية للمستخدمين بدقة عند تجميع محطة العمل أول مرة، كما يمكن أن تتغير هذه الحاجات مع مرور الزمن. في حالتنا، لا يمكننا معرفة الأحجام التخزينية اللازمة للقطات الخام (rushes) ومقاطع الفيديو المكتملة مسبقاً. إذا احتاج أحد المقاطع لعدد كبير من اللقطات، وكان أكثر من نصف VG المخصصة للحيزات المؤمنة فارغاً، يمكننا إعادة استخدام بعض المساحة غير اللازمة منها. يمكننا إزالة أحد الحيزات الفيزيائية، ولنقل md2، من vg_raid ثم نضيفه إلى vg_bulk مباشرة (إذا كانت المدة المتوقعة لإنهاء العملية قصيرة بحيث نستطيع قبول الانخفاض المؤقت في الأداء)، أو نلغي مصفوفة RAID على md2 وندمج مكوناتها (sda6 وsdc6) مع VG غير المؤمنة (التي ستكبر بمقدار 200 غ.ب بدلاً من 100 غ.ب)؛ بعدها يمكن توسعة الحيز المنطقي lv_rushes حسب الحاجة.