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

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

12.1. ‏RAID وLVM

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

RAID and LVM are both techniques to abstract the mounted volumes from their physical counterparts (actual hard-disk drives or partitions thereof); the former ensures the security and availability of the data in case of hardware failure by introducing redundancy, the latter makes volume management more flexible and independent of the actual size of the underlying disks. In both cases, the system ends up with new block devices, which can be used to create filesystems or swap space, without necessarily having them mapped to one physical disk. RAID and LVM come from quite different backgrounds, but their functionality can overlap somewhat, which is why they are often mentioned together.

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

While LVM and RAID are two distinct kernel subsystems that come between the disk block devices and their filesystems, btrfs is a filesystem, initially developed at Oracle, that purports to combine the featuresets of LVM and RAID and much more.

→ https://btrfs.wiki.kernel.org/index.php/Main_Page

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

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

12.1.1. ‏Software RAID

RAID means Redundant Array of Independent Disks. The goal of this system is to prevent data loss and ensure availability in case of hard disk failure. The general principle is quite simple: data are stored on several physical disks instead of only one, with a configurable level of redundancy. Depending on this amount of redundancy, and even in the event of an unexpected disk failure, data can be losslessly reconstructed from the remaining disks.

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

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

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

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

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

‏Linear RAID: Even though the kernel's RAID subsystem allows creating “linear RAID”, this is not proper RAID, since this setup doesn't involve any redundancy. The kernel merely aggregates several disks end-to-end and provides the resulting aggregated volume as one virtual disk (one block device). That is about its only function. This setup is rarely used by itself (see later for the exceptions), especially since the lack of redundancy means that one disk failing makes the whole aggregate, and therefore all the data, unavailable.
‏RAID-0: لا يقدم هذا المستوى أية فائض أيضًا، لكن الأقراص لا تتقاطر خلف بعضها بشكل بسيط: بل تقسم إلى شرائط stripes، ويتم تخزين أجزاء القرص الظاهري على الشرائط بشكل متناوب بين الأقراص الفيزيائية. في نظام RAID-0 ذو قرصين، مثلًا، تُخَزَّن الأجزاء الزوجية من القرص الظاهري على القرص الفيزيائي الأول، والأجزاء الفردية على القرص الفيزيائي الثاني.
This system doesn't aim at increasing reliability, since (as in the linear case) the availability of all the data is jeopardized as soon as one disk fails, but at increasing performance: during sequential access to large amounts of contiguous data, the kernel will be able to read from both disks (or write to them) in parallel, which increases the data transfer rate. The disks are utilized entirely by the RAID device, so they should have the same size not to lose performance.
RAID-0 use is shrinking, its niche being filled by LVM (see later).
‏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: This isn't strictly speaking, a RAID level, but a stacking of two RAID groupings. Starting from 2×N disks, one first sets them up by pairs into N RAID-1 volumes; these N volumes are then aggregated into one, either by “linear RAID” or (increasingly) by LVM. This last case goes farther than pure RAID, but there is no problem with that.
تتحمل مصفوفات 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 : Tue Jun 25 08:47:49 2019
        Raid Level : raid0
        Array Size : 8378368 (7.99 GiB 8.58 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Tue Jun 25 08:47:49 2019
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

        Chunk Size : 512K

Consistency Policy : none

              Name : mirwiz:0  (local to host debian)
              UUID : 146e104f:66ccc06d:71c262d7:9af1fbc7
            Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       32        0      active sync   /dev/sdb
       1       8       48        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks: done                            
Creating filesystem with 2094592 4k blocks and 524288 inodes
Filesystem UUID: 413c3dff-ab5e-44e7-ad34-cf1a029cfe98
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 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   36M  7.4G   1% /srv/raid-0

The mdadm --create command requires several parameters: the name of the volume to create (/dev/md*, with MD standing for Multiple Device), the RAID level, the number of disks (which is compulsory despite being mostly meaningful only with RAID-1 and above), and the physical drives to use. Once the device is created, we can use it like we'd use a normal partition, create a filesystem on it, mount that filesystem, and so on. Note that our creation of a RAID-0 volume on md0 is nothing but coincidence, and the numbering of the array doesn't need to be correlated to the chosen amount of redundancy. It is also possible to create named RAID arrays, by giving mdadm parameters such as /dev/md/linear instead of /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 : Tue Jun 25 10:21:22 2019
        Raid Level : raid1
        Array Size : 4189184 (4.00 GiB 4.29 GB)
     Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Tue Jun 25 10:22:03 2019
             State : clean, resyncing 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : resync

     Resync Status : 93% complete

              Name : mirwiz:1  (local to host debian)
              UUID : 7d123734:9677b7d6:72194f7d:9050771c
            Events : 16

    Number   Major   Minor   RaidDevice State
       0       8       64        0      active sync   /dev/sdd2
       1       8       80        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 : Tue Jun 25 11:03:44 2019
             State : clean, degraded 
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 1
     Spare Devices : 0

Consistency Policy : resync

              Name : mirwiz:1  (local to host debian)
              UUID : 7d123734:9677b7d6:72194f7d:9050771c
            Events : 20

    Number   Major   Minor   RaidDevice State
       -       0        0        0      removed
       1       8       80        1      active sync   /dev/sdd2

       0       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 : Tue Jun 25 11:09:42 2019
             State : clean, degraded, recovering 
    Active Devices : 1
   Working Devices : 2
    Failed Devices : 1
     Spare Devices : 1

Consistency Policy : resync

    Rebuild Status : 27% complete

              Name : mirwiz:1  (local to host debian)
              UUID : 7d123734:9677b7d6:72194f7d:9050771c
            Events : 26

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

       0       8       64        -      faulty   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
       Update Time : Tue Jun 25 11:10:47 2019
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 1
     Spare Devices : 0

Consistency Policy : resync

              Name : mirwiz:1  (local to host debian)
              UUID : 7d123734:9677b7d6:72194f7d:9050771c
            Events : 39

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

       0       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
       2       8       96        0      active sync   /dev/sdd2
       1       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
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# 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=146e104f:66ccc06d:71c262d7:9af1fbc7
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=7d123734:9677b7d6:72194f7d:9050771c

# This configuration was auto-generated on Tue, 25 Jun 2019 07:54:35 -0400 by mkconf

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

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

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

# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=146e104f:66ccc06d:71c262d7:9af1fbc7
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=7d123734:9677b7d6:72194f7d:9050771c

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

12.1.2. LVM

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

12.1.2.1. مفاهيم LVM

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

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

A number of PVs can be clustered in a VG (Volume Group), which can be compared to disks both virtual and extensible. VGs are abstract, and don't appear in a device file in the /dev hierarchy, so there is no risk of using them directly.

النوع الثالث من المكونات هو 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:

# 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               z4Clgk-T5a4-C27o-1P0E-lIAF-OeUM-e7EMwq

# 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.00g  3.00g
  /dev/sdd      lvm2 ---   4.00g  4.00g
  /dev/sdf1     lvm2 ---   4.00g  4.00g
  /dev/sdf2     lvm2 ---  <5.00g <5.00g

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

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

# 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               7.99 GiB
  PE Size               4.00 MiB
  Total PE              2046
  Alloc PE / Size       0 / 0   
  Free  PE / Size       2046 / 7.99 GiB
  VG UUID               wAbBjx-d82B-q7St-0KFf-z40h-w5Mh-uAXkNZ

# 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-   7.99g   7.99g
  vg_normal     3   0   0 wz--n- <11.99g <11.99g

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

We now have two “virtual disks”, sized about 8 GB and 12 GB respectively. Let's now carve them up into “virtual partitions” (LVs). This involves the lvcreate command, and a slightly more complex syntax:

# 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                W6XT08-iBBx-Nrw2-f8F2-r2y4-Ltds-UrKogV
  LV Write Access        read/write
  LV Creation host, time debian, 2019-11-30 22:45:46 -0500
  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           254:0

# lvcreate -n lv_base -L 1G vg_critical
  Logical volume "lv_base" created.
# lvcreate -n lv_backups -L 11.98G vg_normal
  Rounding up size to full physical extent 11.98 GiB
  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--- 11.98g

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

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

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

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

It is also possible to hint at the physical location of an LV, so that its extents are stored on a particular PV (while staying within the ones assigned to the VG, of course). Since we know that sdb is faster than sdf, we may want to store the lv_base there if we want to give an advantage to the database server compared to the file server. The command line becomes: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Note that this command can fail if the PV doesn't have enough free extents. In our example, we would probably have to create lv_base before lv_files to avoid this situation – or free up some space on sdb2 with the pvmove command.

ينتهي المطاف بالحيزات المنطقية بعد إنشائها كملفات أجهزة كتلية في /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

NOTE Auto-detecting LVM volumes

عند إقلاع الحاسب، تنفذ وحدة الخدمة 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.44.5 (15-Dec-2018)
Discarding device blocks: done                            
Creating filesystem with 3140608 4k blocks and 786432 inodes
Filesystem UUID: b9e6ed2f-cb37-43e9-87d8-e77568446225
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 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   41M   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  4.9G  4.2G  485M  90% /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- 7.99g 1.99g
# lvresize -L 6G vg_critical/lv_files
  Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents).
  Logical volume vg_critical/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---- 6.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.44.5 (15-Dec-2018)
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 1572864 (4k) blocks long.

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  5.9G  4.2G  1.5G  75% /srv/files

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

Not all filesystems can be resized online; resizing a volume can therefore require unmounting the filesystem first and remounting it afterwards. Of course, if one wants to shrink the space allocated to an LV, the filesystem must be shrunk first; the order is reversed when the resizing goes in the other direction: the logical volume must be grown before the filesystem on it. It is rather straightforward, since at no time must the filesystem size be larger than the block device where it resides (whether that device is a physical partition or a logical volume).

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

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

# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  976M  882M   28M  97% /srv/base
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree   
  vg_critical   2   2   0 wz--n- 7.99g 1016.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.99g <1.99g
# [...]
[...]
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  2.0G  882M  994M  48% /srv/base

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

LVM also caters for more advanced uses, where many details can be specified by hand. For instance, an administrator can tweak the size of the blocks that make up physical and logical volumes, as well as their physical layout. It is also possible to move blocks across PVs, for instance, to fine-tune performance or, in a more mundane way, to free a PV when one needs to extract the corresponding physical disk from the VG (whether to affect it to another VG or to remove it from LVM altogether). The manual pages describing the commands are generally clear and detailed. A good entry point is the lvm(8) manual page.

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 على القرصين على التوازي، ما يسمح بسرعات قراءة أو كتابة أكبر للملفات الكبيرة.

We will therefore create the lv_var and lv_home LVs on vg_raid, to host the matching filesystems; another large LV, lv_movies, will be used to host the definitive versions of movies after editing. The other VG will be split into a large lv_rushes, for data straight out of the digital video cameras, and a lv_tmp for temporary files. The location of the work area is a less straightforward choice to make: while good performance is needed for that volume, is it worth risking losing work if a disk fails during an editing session? Depending on the answer to that question, the relevant LV will be created on one VG or the other.

We now have both some redundancy for important data and much flexibility in how the available space is split across the applications.

ملاحظة لماذا ثلاثة حيزات 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 حسب الحاجة.