Product SiteDocumentation Site

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

12.1. ‏RAID وLVM
12.1.1. ‏Software RAID
12.1.2. LVM
12.1.3. ‏RAID أو LVM؟
12.2. الحوسبة الظاهرية
12.2.1. ‏Xen
12.2.2. ‏LXC
12.2.3. المحاكاة في KVM
12.3. التثبيت المؤتمت
12.3.1. ‏Fully Automatic Installer (FAI)‎
12.3.2. تغذية مثبت دبيان
12.3.3. ‏Simple-CDD: كل الحلول في حل واحد
12.4. المراقبة
12.4.1. إعداد Munin
12.4.2. إعداد Nagios
يعيد هذا الفصل النظر في بعض القضايا التي ناقشناها سابقاً، لكن من وجهة نظر مختلفة: سوف ندرس تجهيز الأنظمة الكبيرة بدلاً من تجهيز حاسوب مفرد؛ وسوف نتعلم ضبط 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.
في حال استخدام 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 ذات 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 الملائم يعتمد على متطلبات وقيود كل تطبيق. لاحظ أن الحاسوب الواحد يمكن أن يحوي عدة مصفوفات 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، وأنه يمكن إنشاء نظام ملفات عليه، كما يمكن نسخ البيانات إليه أيضًا.
دعنا نرى ما سيحدث عندما يتعطل أحد عناصر مصفوفة 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 التي يطبق عليها طبعًا، وهذا هو المعامل الأخير في التعليمة.
ينتهي المطاف بالحيزات المنطقية بعد إنشائها كملفات أجهزة كتلية في /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
لتسهيل الأمور، يتم إنشاء اختصارات رمزيّة أيضًا في مجلدات بأسماء 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
يمكننا توسعة الحيز الذي يستضيف قاعدة البيانات بنفس الأسلوب، لولا أننا وصلنا لحدود المساحة المتاحة على المجموعة:
# 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

12.1.3. ‏RAID أو LVM؟

يقدم كلٌّ من RAID وLVM ميزات لا تقبل الجدل عندما يبتعد المرء عن الحالة البسيطة للحاسوب المكتبي ذي القرص الواحد حيث لا تتغير الاستخدامات مع مرور الزمن. لكن RAID وLVM يتباعدان في اتجاهين مختلفين، وتتباعد أهدافهما، ومن المقبول أن يتسائل المرء عن أي التقنيتين يجب أن يتبناها. الإجابة الأنسب ستعتمد طبعاً على الحاجات الحالية والمتوقعة.
هناك عدة حالات بسيطة حيث لا تظهر فيها أي تساؤلات فعلية. إذا كان الهدف هو حماية البيانات من عطب العتاد، فالحل طبعاً هو إعداد RAID مع مصفوفة أقراص ذات فائض تخزيني، نظرًا لأن LVM لا يعالج هذه المشكلة أبداً. من جهة أخرى، إذا كان هناك حاجة لتصميم تخزيني مرن تستقل فيه الحيزات التخزينية عن المخطط الفيزيائي للأقراص، عندها RAID لا يساعد كثيراً وLVM هو الخيار الطبيعي.
حالة الاستخدام الثالثة الجديرة بالاهتمام هي عندما يحتاج المرء جمع قرصين في حيز تخزيني واحد، وذلك بهدف زيادة الأداء أو للحصول على نظام ملفات أكبر من سعة الأقراص المتوفرة. يمكن معالجة هذه الحالة باستخدم 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.