LVM في Linux: الأقراص المادية والمجموعات والأحجام المنطقية عملياً

LVM (Logical Volume Manager) هو مدير الأحجام المنطقية في Linux، ويفصل أنظمة الملفات عن الأقراص المادية. فبدلاً من ربط /var بالقسم /dev/sdb1 بشكل جامد، تضع الأقراص في مجمّع مشترك وتقطع منه أحجاماً بالمقاس المطلوب. وعندما ينفد المكان يكبر الحجم بأمر واحد، دون إعادة تشغيل ودون إيقاف الخدمة. وفيما يلي نشرح بنية LVM في Linux، وكيف تُنشئ الأحجام من الصفر، وتوسّعها، وتأخذ لقطة، وتتجنب الأخطاء الشائعة دون فقدان البيانات.

لماذا يُستخدم LVM إذا توفرت الأقسام العادية

القسم العادي قطعة متصلة من قرص واحد. يُحدَّد حجمه عند التقسيم، ولا يمكن توسيعه إلا إذا كان بعده مساحة فارغة مباشرة. وإذا نفد القرص يلزمك شراء قرص جديد، ونقل البيانات، وإعادة كتابة /etc/fstab، وإيقاف الخدمة طوال ذلك.

يحل LVM ثلاث مشكلات:

• حجم مرن. يمكن توسيع الحجم المنطقي (وتصغير ext4 أيضاً) في أي لحظة.
• دمج الأقراص. تتحول عدة أقراص مادية إلى مجمّع واحد، ويمكن أن يمتد حجم منطقي واحد على قرصين.
• اللقطات. نسخة فورية من الحجم قبل التحديث أو نقل قاعدة البيانات أو أي عملية محفوفة بالمخاطر.

لذلك يقترح مثبّتا Ubuntu Server وRHEL وRocky وAlmaLinux LVM افتراضياً، ويُستخدم في الخوادم التي تحمل بيانات في معظم الأحيان.

المستويات الثلاثة لـLVM: PV وVG وLV

تتلخص منطقة LVM كلها في ثلاثة مفاهيم. تشبيه مفيد: الأقراص أكياس الطحين، والمجموعة هي المستودع المشترك، والأحجام المنطقية هي الحصص التي تأخذها من المستودع.

داخل VG تُقسَّم المساحة إلى مقاطع تسمى الـextents (PE، physical extents)، أي كتل بحجم ثابت، وهو 4 ميبيبايت افتراضياً. والحجم المنطقي مجرد مجموعة من هذه المقاطع، لا يلزم أن تكون متتالية، ويمكن أن تقع على أقراص مختلفة. ولهذا يسهل توسيع الحجم: يضيف LVM إليه مقاطع فارغة من أي مكان.

يمكن الوصول إلى الحجم المنطقي بمسارين متكافئين: /dev/data_vg/app و/dev/mapper/data_vg-app. وفي الداخل يكون هذا الجهاز من نوع device-mapper في النواة.

كيف ترى ما هو موجود

تأكد أولاً من تثبيت الحزمة: في Debian وUbuntu اسمها lvm2 (sudo apt install lvm2)، وهي مثبتة افتراضياً في عائلة RHEL. وللنظرة العامة توجد أوامر قصيرة وأخرى مفصّلة:

$ sudo pvs
  PV         VG      Fmt  Attr PSize   PFree
  /dev/sdb   data_vg lvm2 a--  <20.00g      0
  /dev/sdc   data_vg lvm2 a--  <20.00g  <10.00g

$ sudo vgs
  VG      #PV #LV #SN Attr   VSize  VFree
  data_vg   2   1   0 wz--n- 39.99g <10.00g

$ sudo lvs
  LV   VG      Attr       LSize  Pool Origin Data%  Meta%
  app  data_vg -wi-ao---- 30.00g

للتفاصيل تعرض pvdisplay وvgdisplay وlvdisplay معلومات أوسع. أما الصورة الكاملة مع الأقسام العادية فيعرضها lsblk، حيث تظهر الأحجام المنطقية بالنوع lvm.

$ lsblk /dev/sdb /dev/sdc
NAME             MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sdb                8:16   0  20G  0 disk
└─data_vg-app    253:0    0  30G  0 lvm  /srv/app
sdc                8:32   0  20G  0 disk
└─data_vg-app    253:0    0  30G  0 lvm  /srv/app

يتضح أن الحجم app بمساحة 30 غيغابايت يقع على قرصين، كل منهما 20 غيغابايت، وهذا لا يمكن تنفيذه بقسم عادي.

LVM من الصفر: من قرص خام إلى حجم مركّب

لنفترض أنه أُضيف إلى الخادم قرص فارغ /dev/sdb، ونحتاج إلى حجم بسعة 15 غيغابايت لبيانات التطبيق. تحقق من اسم القرص بـlsblk مرتين: كل الأوامر التالية تمحو البيانات على الجهاز المحدد.

الخطوة 1. إنشاء وحدة مادية

$ sudo pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created.

يمكن إعطاء LVM القرص كاملاً، ويمكن أيضاً إنشاء قسم أولاً بـfdisk أو parted بنوع «Linux LVM» ثم تحديده (/dev/sdb1). والقسم أوضح للمسؤولين الآخرين، ويحمي من تقسيم القرص عن طريق الخطأ فوق LVM، بينما يكون القرص الكامل أسهل في التوسعة في السحابة.

الخطوة 2. إنشاء مجموعة الأحجام

$ sudo vgcreate data_vg /dev/sdb
  Volume group "data_vg" successfully created

الخطوة 3. تقطيع حجم منطقي

$ sudo lvcreate -n app -L 15G data_vg
  Logical volume "app" created.

يحدد الخيار -L الحجم المطلق، أما -l فيحدد الحجم بالمقاطع أو بالنسبة المئوية: -l 100%FREE يأخذ كل المساحة الحرة في المجموعة، و-l 50%VG يأخذ نصفها. ومن الممارسات الجيدة ترك مساحة حرة في VG: يمكن إضافتها لاحقاً لأي حجم، أو تخصيصها للقطات.

الخطوة 4. نظام الملفات والربط

$ sudo mkfs.ext4 /dev/data_vg/app
$ sudo mkdir -p /srv/app
$ sudo mount /dev/data_vg/app /srv/app
$ df -h /srv/app
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/data_vg-app   15G   24K   14G   1% /srv/app

لكي يُربط الحجم بعد إعادة التشغيل أضف سطراً إلى /etc/fstab. ومسار /dev/mapper/... ثابت للأحجام المنطقية، فيمكن استخدامه أو استخدام UUID من blkid:

/dev/mapper/data_vg-app  /srv/app  ext4  defaults  0 2

تحقق من الإدخال بالأمر sudo mount -a قبل إعادة التشغيل، فخطأ في fstab قد يترك الخادم في وضع الطوارئ.

كيف توسّع حجم LVM دون إيقاف الخدمة

هذا هو السبب الرئيسي لاستخدام LVM. يكبر الحجم وهو مركّب، والتطبيق يواصل الكتابة. ويعتمد السيناريو على وجود مساحة حرة في المجموعة.

إذا كانت هناك مساحة حرة في VG

$ sudo vgs data_vg
  VG      #PV #LV #SN Attr   VSize   VFree
  data_vg   1   1   0 wz--n- <20.00g <5.00g

$ sudo lvextend -r -L +4G /dev/data_vg/app
  Size of logical volume data_vg/app changed from 15.00 GiB to 19.00 GiB.
  Logical volume data_vg/app successfully resized.
resize2fs 1.47.0
Filesystem at /dev/mapper/data_vg-app is mounted on /srv/app; on-line resizing required

المفتاح هنا هو -r (--resizefs): فهو يوسّع نظام الملفات مباشرةً بعد توسيع الحجم. ومن دونه يكبر الحجم، لكن df -h يُظهر الحجم القديم، لأن نظام الملفات لا يعرف بالمساحة الجديدة. وهذا أكثر الأخطاء شيوعاً، وحلّه تشغيل resize2fs لـext4 أو xfs_growfs لـXFS يدوياً.

$ sudo resize2fs /dev/data_vg/app      # ext4، يُذكر الجهاز
$ sudo xfs_growfs /srv/app             # XFS، تُذكر نقطة الربط

لاحظ الفرق: -L +4G يضيف 4 غيغابايت، بينما -L 4G يضبط الحجم النهائي على 4 غيغابايت. ولإعطاء الحجم كل المساحة المتبقية استخدم -l +100%FREE.

إذا نفدت المساحة في VG: إضافة قرص

وصّل القرص الجديد (وفي السحابة ألحق حجماً جديداً)، واعثر عليه بـlsblk، ثم أضفه إلى المجموعة:

$ sudo pvcreate /dev/sdc
$ sudo vgextend data_vg /dev/sdc
  Volume group "data_vg" successfully extended
$ sudo lvextend -r -l +100%FREE /dev/data_vg/app

ثلاثة أوامر دون أي توقف. ونظام الملفات الآن يعيش على قرصين، والتطبيق لا يلاحظ ذلك.

إذا كبّرت القرص في السحابة

في السحابة يكون الأسهل غالباً عدم إضافة قرص، بل تكبير القرص الموجود. عندها ترى النواة الحجم الجديد، ويجب تمديد الوحدة المادية بالأمر pvresize:

$ sudo pvresize /dev/sdb
  Physical volume "/dev/sdb" changed
$ sudo lvextend -r -l +100%FREE /dev/data_vg/app

إذا كانت الوحدة المادية منشأة على قسم (/dev/sdb1)، فوسّع القسم أولاً، مثلاً بالأداة growpart /dev/sdb 1 من حزمة cloud-guest-utils، ثم نفّذ pvresize /dev/sdb1.

هل يمكن تصغير حجم LVM

يمكن ذلك، لكن ليس لكل أنظمة الملفات، وليس أثناء التشغيل. XFS لا يمكن تصغيره إطلاقاً، بل يُعاد إنشاؤه مع نقل البيانات. أما ext4 فيُصغَّر، لكن بعد فصله:

$ sudo umount /srv/app
$ sudo lvreduce -r -L 10G /dev/data_vg/app

مع الخيار -r يتحقق LVM من نظام الملفات بنفسه (e2fsck) ويضغطه قبل تصغير الحجم. ومن دونه قد تقطع حجماً أصغر من نظام الملفات فتتلف البيانات. وقبل التصغير خذ دائماً نسخة احتياطية.

لقطات LVM: نسخة من الحجم قبل عملية محفوفة بالمخاطر

اللقطة (snapshot) هي نسخة فورية من حجم منطقي. تُنشأ في أجزاء من الثانية ولا تنسخ البيانات: يعمل LVM بمبدأ copy-on-write، فيحفظ في اللقطة فقط الكتل التي تتغير في الحجم الأصلي بعد إنشائها. لذلك تحتاج اللقطة إلى مساحة في VG بقدر حجم التغييرات فقط، لا بقدر الحجم كله.

$ sudo lvcreate -s -n app_before_upgrade -L 2G /dev/data_vg/app
  Logical volume "app_before_upgrade" created.

$ sudo lvs data_vg
  LV                 VG      Attr       LSize  Origin Data%
  app                data_vg owi-aos--- 19.00g
  app_before_upgrade data_vg swi-a-s---  2.00g app    0.01

يعرض العمود Data% مدى امتلاء مخزن التغييرات. إذا وصل إلى 100% تصبح اللقطة الكلاسيكية غير صالحة، ولا يبقى إلا حذفها. اختر الحجم بهامش يكفي للتغييرات المتوقعة، وراقب اللقطات الطويلة عبر lvs أو وسّعها بالأمر lvextend.

كيف ترجع إلى اللقطة

إذا سار التحديث بشكل سيئ، أعد الحجم إلى الحالة وقت اللقطة:

$ sudo umount /srv/app
$ sudo lvconvert --merge /dev/data_vg/app_before_upgrade
  Merging of volume data_vg/app_before_upgrade started.
$ sudo mount /srv/app

بعد الدمج تختفي اللقطة. وإذا تعذّر فصل الحجم (مثل جذر النظام)، يتأجل الدمج إلى التفعيل التالي للحجم، أي إلى إعادة التشغيل.

إذا سار كل شيء على ما يرام

تُحذف اللقطة حتى لا تبطئ الكتابة ولا تشغل مساحة:

$ sudo lvremove /dev/data_vg/app_before_upgrade

ومن المفيد تركيب اللقطة للقراءة فقط، لأخذ نسخة احتياطية متسقة من نظام يعمل: mount -o ro ثم النسخ بـrsync أو tar. وفي XFS أضف الخيار nouuid، وإلا فسيرفض الربط بسبب تطابق UUID مع الأصل.

LVM وRAID: لا تخلط بين المهمتين

LVM لا يحمي من عطل القرص بذاته. إذا امتد الحجم على قرصين وتعطل أحدهما، يُفقد الحجم كله، لا نصفه. ولتحمّل الأعطال يُوضع RAID (mdadm) تحت LVM، أو يُستخدم وضع المرآة المدمج في LVM (lvcreate --type raid1 -m 1).

ولا يغني RAID ولا اللقطات عن النسخ الاحتياطية. فاللقطة موجودة على الأقراص نفسها التي فيها الأصل، وRAID يعكس بإخلاص حتى الحذف العرضي بـrm -rf. تحتاج إلى نسخة منفصلة على وسيط آخر.

ورقة مرجعية لأوامر LVM

الأخطاء الشائعة

• وُسّع الحجم لكن df يُظهر الحجم القديم. نُسي الخيار -r. نفّذ resize2fs أو xfs_growfs.
• Insufficient free space. لا توجد مقاطع حرة في المجموعة: تحقق من vgs وأضف قرصاً بـvgextend أو مدّد الوحدة المادية.
• Device /dev/sdc excluded by a filter. بقيت على القرص تقسيمة أو توقيع نظام ملفات قديم. إذا كانت البيانات عليه غير مطلوبة بالتأكيد، فامسحها بالأمر wipefs -a /dev/sdc.
• اللقطة أصبحت Invalid. امتلأ مخزن التغييرات بنسبة 100%. لا يمكن استعادتها، ولا يبقى إلا حذفها، وفي المرة القادمة خصص مساحة أكبر.

الخلاصة

LVM في Linux ثلاث طبقات: الأقراص المادية (PV) تُجمع في مجموعة (VG)، ومنها تُقطَّع الأحجام المنطقية (LV). وهذا يمنح ما لا تمنحه الأقسام العادية: توسيع الحجم أثناء التشغيل بـlvextend -r، وإضافة الأقراص دون توقف، واللقطات قبل التغييرات الخطرة. وتذكر أن LVM لا يغني عن RAID ولا عن النسخ الاحتياطية. وقد جرى شرح تقسيم الأقراص وLVM وRAID والحصص عملياً في درس Linux.