فصل 12. مدیریت پیشرفته

این فصل به مرور مفاهیمی که تاکنون به آن‌ها پرداخته‌ایم می‌پردازد، اما با رویکردی متفاوت: بجای نصب یک رایانه تکی، به مطالعه نصب-انبوه روی سیستم‌ها می‌پردازیم؛ بجای نصب RAID یا LVM در زمان نصب، اینکار را به صورت دستی در زمان دیگری که نیاز داشته باشیم انجام می‌دهیم. در نهایت، درباره ابزارهای مانیتورینگ و تکنیک‌های مجازی‌سازی صحبت خواهیم کرد. به همین دلیل، مخاطب این فصل روی مدیرسیستم‌های حرفه‌ای تمرکز دارد و به جنبه‌های شخصی و انفرادی این کار کمتر توجه می‌کند.

12.1. RAID و LVM

فصل 4, نصب presented these technologies from the point of view of the installer, and how it integrated them to make their deployment easy from the start. After the initial installation, an administrator must be able to handle evolving storage space needs without having to resort to an expensive re-installation. They must therefore understand the required tools for manipulating RAID and LVM volumes.

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 در Btrfs

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 feature sets of LVM and RAID and much more.

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

از میان ویژگی‌های آن، توانایی ایجاد snapshot از فایل‌سیستم در هر لحظه از زمان وجود دارد. این رونوشت از snapshot به صورت اولیه هیچ فضایی را اشغال نمی‌کند، داده زمانی تکرار می‌شود که یکی از این رونوشت‌ها تغییر کند. فایل‌سیستم همچنین از فشرده‌سازی شفاف فایل‌ها پشتیبانی و از checksum برای اطمینان از جامعیت داده‌های ذخیره شده استفاده می‌کند.

در هر دو مورد RAID و LVM، کرنل یک دستگاه بلاک-محور فراهم می‌کند، مشابه آن‌هایی که برای درایو هارد دیسک یا یک پارتیشن بکار می‌رود. زمانی که یک برنامه، یا قسمتی از کرنل، درخواست دسترسی به چنین دستگاهی را داشته باشد، زیرسیستم مرتبط با آن فرآیند مسیریابی بلاک به لایه فیزیکی مرتبط را برقرار می‌کند. با توجه به پیکربندی، این بلاک می‌تواند در یک یا چند دیسک فیزیکی ذخیره شده باشد و مکان فیزیکی آن ممکن است به صورت مستقیم مرتبط با مکان بلاک در دستگاه مجازی نباشد.

12.1.1. 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 در صورت وجود افزونگی کافی می‌تواند در زمان بروز نقص دیسک به کار خود ادامه دهد؛ لایه‌های بالایی آن (برنامه‌ها) حتی می‌توانند در صورت بروز مشکل به داده دسترسی داشته باشند. البته که این “حالت ناامن” می‌تواند عملکرد منفی روی سیستم بگذارد و منجر به کاهش سطح افزونگی گردد، بنابراین یک نقص دیسک دیگر، منجر به از دست دادن داده می‌شود. در عمل، تنها یک دیسک تلاش می‌کند که در این حالت تخریبی تا زمان برطرف شدن مشکل قرار بگیرد. زمانی که دیسک جدید جایگزین شود، سیستم RAID می‌تواند با بازسازی داده به حالت امن خود بازگردد. زمانی که آرایه در حالت ناامن یا فاز بازسازی داده قرار می‌گیرد، عملا وقفه‌ای در برنامه‌ها ایجاد نمی‌گردد بجز کاهش سرعت دسترسی به داده.

زمانی که RAID به صورت سخت‌افزاری پیاده‌سازی شود، پیکربندی آن درون ابزار برپایی BIOS قرار می‌گیرد و کرنل یک آرایه RAID را به عنوان یک دیسک مجزا در نظر می‌گیرد، که مانند یک دیسک استاندارد کار خواهد کرد، با این حال نام دستگاه می‌تواند متفاوت باشد (بر اساس درایو بکار رفته).

ما تنها به RAID نرم‌افزاری در این کتاب اشاره می‌کنیم.

12.1.1.1. سطوح مختلف RAID

RAID در حقیقت یک سیستم مجزا نیست، بلکه بازه‌ای از سیستم‌ها در سطوح مختلف است؛ این سطوح با توجه به ساختار و میزان افزونگی داده با یکدیگر فرق دارند. هر چه افزونگی بیشتر باشد، توانایی مواجه به دیسک‌های خراب در زمان نقص سخت‌افزاری بالاتر می‌رود. نقطه مقابل آن زمانی است که فضای موجود برای مجموعه‌ای از دیسک‌ها کاهش یابد؛ که در این صورت به دیسک‌های بیشتری برای ذخیره‌سازی داده نیاز است.

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 تقسیم می‌شوند و بلاک‌های دستگاه مجازی روی این stripe از دیسک‌های فیزیکی قرار می‌گیرند. برای نمونه، در یک تنظیم 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 پیشرفته‌تر نیز صادق است، با اینکه ممکن است از فرآیند افزونگی دیگری استفاده کنند.
به همین دلیل، مهم است که در زمان برپایی آرایه‌های RAID (بجز RAID-0 و خطی) از دیسک‌های با اندازه مشابه یا بسیار نزدیک به هم استفاده شود تا هیچ فضای اضافی تلف نگردد.
یادداشت دیسک‌های کمکی
سطوح RAID که شامل افزونگی داده هستند اجازه استفاده از دیسک‌های بیشتر در آرایه دیسک‌ها را فراهم می‌کنند. از این دیسک‌ها به منظور پشتیبان در زمان بروز نقص برای یکی از دیسک‌های موجود استفاده می‌شود. برای نمونه، در یک تنظیم دو دیسکه همراه با دیسک کمکی، اگر یکی از دیسک‌های اولیه معیوب شود، کرنل به صورت خودکار (و بلافاصله) فضای موجود را با استفاده از دیسک کمکی بازسازی می‌کند، به منظور اینکه اطمینان از عملیات افزونگی داده پس از زمان بازسازی حاصل گردد. از این روش می‌توان به عنوان گام اضافه برای نگهداری از داده‌های بسیار حساس استفاده کرد.
ممکن است به نظر آید که چطور این پیکربندی در مقایسه با استفاده از سه دیسک برای mirroring ممکن است مفید باشد. مزیت استفاده از پیکربندی “دیسک کمکی” این است که می‌تواند بین چندین فضای ذخیره‌سازی RAID به اشتراک گذاشته شود. برای نمونه، می‌توان از سه فضای ذخیره‌سازی mirrored استفاده کرد، همراه با افزونگی داده که در صورت بروز نقص در یکی از دیسک‌ها بکار می‌آید، همراه با هفت دیسک (سه زوج به همراه یک دیسک کمکی) بجای نه دیسک که مورد نیاز سه خانواده سه زوجی است.
این سطح RAID، با وجود هزینه بالا (از آنجا که در بهترین حالت از نصف فضای ذخیره‌سازی استفاده می‌شود) در عمل بسیار مورد استفاده قرار می‌گیرد. درک آن بسیار ساده است و امکان ایجاد پشتیبان‌های ساده وجود دارد: از آنجا که هر دو دیسک شامل محتوای یکسانی هستند، یکی از آن‌ها بدون ایجاد کوچکترین تاثیر منفی روی سیستم می‌تواند تخلیه شود. عملیات خواندن نیز بسیار سریع‌تر خواهد بود چرا که در هر لحظه کرنل به صورت همزمان نصف داده را از هر دو دیسک می‌تواند بخواند، با اینکه عملیات نوشتن آنطور که به نظر می‌آید تاثیر منفی ندارد. در مورد آرایه RAID-1 از N دیسک، حتی در صورت معیوب شدن N-1 دیسک داده کماکان قابل دسترس خواهد بود.
CAUTION RAID is not Backup
RAID systems are not backup mechanisms. While RAID increases the redundancy - and therefore the availability of a system - and protects against disk failures, backups are done to protect data from being altered, deleted, getting corrupted, etc., and to be able to restore them if necessary. To demonstrate this: If you remove one or all files by accident, a RAID will mirror this change, but it will not provide the means to restore the file(s). So while there is clearly an overlap, they are not the same and should be used in conjunction with each other.
RAID-4: این سطح RAID، که کاربرد زیادی ندارد، از N دیسک برای ذخیره‌سازی داده مفید و از یک دیسک اضافی برای ذخیره‌سازی اطلاعات افزونگی استفاده می‌کند. اگر این دیسک اضافی معیوب شود، سیستم می‌تواند با آن N دیسک دیگر محتوای خود را بازسازی کند، به صورتی که N-1 دیسک باقیمانده همراه با دیسک “parity” شامل اطلاعات کافی برای بازسازی تمام اطلاعات هستند.
RAID-4 هزینه زیادی ندارد چرا که تنها شامل یک هزینه افزایشی یک در N می‌باشد که تاثیر بسزایی روی عملیات خواندن ندارد ولی عملیات نوشتن را کند می‌کند. علاوه بر این، از آنجا که نوشتن روی هر یک از N دیسک به معنای نوشتن روی دیسک parity است، این دیسک اضافی شاهد نوشتن‌های بیشتری نسبت به سایر دیسک‌ها است و همین دلیل نیز باعث کاهش طول عمر مفید آن می‌گردد. داده روی آرایه RAID-4 تنها در صورت معیوب شدن یک دیسک از N+1 دیسک موجود ایمن خواهد بود.
RAID-5: RAID-5 مشکل عدم تقارن در RAID-4 را برطرف می‌کند: بلاک‌های parity بین تمام N+1 دیسک دیگر پخش می‌شوند به صورتی که تنها یک دیسک نقش منحصربفرد نداشته باشد.
عملیات خواندن و نوشتن درست مانند RAID-4 است. در اینجا نیز، سیستم تا زمانی بکار خود ادامه می‌دهد که تنها یک دیسک معیوب از N+1 دیسک موجود باشد ولی نه بیشتر.
RAID-6: RAID-6 می‌تواند به عنوان افزونه‌ای برای RAID-5 در نظر گرفته شود، به صورتی که هر سری از N بلاک شامل دو بلاک افزونگی داده است و هر یک از این N+2 بلاک میان N+2 دیسک تقسیم می‌شود.
این سطح RAID در مقایسه با دو سطح قبلی هزینه بیشتری در پی دارد، ولی امنیت بیشتری نیز به همراه می‌آورد چرا که تا دو درایو از 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 دیسک از 2N آرایه تعریف شده بالا که برای هر کدام از زوج‌های RAID-1 فراهم شده است، می‌تواند معیوب شود.
مطالعه بیشتر RAID-10
RAID-10 بیشتر به عنوان مترادفی برای RAID-1+0 استفاده می‌شود، اما در لینوکس به عنوان یک استاندارد بکار گرفته می‌شود. این تنظیم شامل سیستمی است که هر بلاک آن درون دو دیسک متفاوت ذخیره می‌شود، حتی با تعداد دیسک‌های فرد، عملیات رونوشت‌گیری با استفاده از مدل قابل پیکربندی به صورت بهینه انجام می‌شود.
عملکرد کلی سیستم با توجه به سطح افزونگی و مدل پارتیشن‌بندی متفاوت خواهد بود، همچنین فضای ذخیره‌سازی منطقی نیز روی آن تاثیرگذار است.

به طور مشخص، سطح RAID با توجه به محدودیت‌ها و نیازمندی‌های سیستم موجود انتخاب می‌شود. نکته اینکه یک رایانه می‌تواند شامل چندین آرایه RAID منحصربفرد به همراه پیکربندی‌های متفاوت باشد.

12.1.1.2. برپایی RAID

برپایی آرایه‌های RAID نیازمند بسته mdadm است؛ که شامل دستور mdadm برای ایجاد و ویرایش این آرایه‌ها می‌باشد همراه با ابزارهای جانبی و اسکریپت‌هایی که آن را با سایر قسمت‌های سیستم از جمله مانیتورینگ یکپارچه می‌سازد.

مثال ما شامل سروری با چندین دیسک است که برخی از آن‌ها استفاده شده و برخی دیگر که آزاد هستند به عنوان RAID بکار گرفته می‌شوند. در حالت اولیه دیسک‌ها و پارتیشن‌های زیر را در اختیار داریم:

دیسک ۴ گیگابایت sdb کاملا موجود است؛
دیسک ۴ گیگابایت sdc کاملا موجود است؛
در دیسک sdd تنها پارتیشن ۴ گیگابایت sdd2 موجود است؛
در نهایت، دیسک ۴ گیگابایت sde که کاملا موجود است.

با استفاده از این دیسک‌ها می‌خواهیم دو فضای ذخیره‌سازی بوجود آوریم، یکی 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: 7.99GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Mon Feb 28 01:54:24 2022
        Raid Level : raid0
        Array Size : 8378368 (7.99 GiB 8.58 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Mon Feb 28 01:54:24 2022
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

            Layout : -unknown-
        Chunk Size : 512K

Consistency Policy : none

              Name : debian:0  (local to host debian)
              UUID : a75ac628:b384c441:157137ac:c04cd98c
            Events : 0

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sdb
       1       8       16        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done                            
Creating filesystem with 2094592 4k blocks and 524288 inodes
Filesystem UUID: ef077204-c477-4430-bf01-52288237bea0
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.8G   24K  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/sdc2) exceeds size (4189184K) 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 : Mon Feb 28 02:07:48 2022
        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 : Mon Feb 28 02:08:09 2022
             State : clean, resync
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : resync

    Rebuild Status : 13% complete

              Name : debian:1  (local to host debian)
              UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
            Events : 17

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

چند نکته باقی می‌ماند. اول، mdadm تشخیص می‌دهد که دستگاه‌های فیزیکی شامل اندازه‌های متفاوت هستند؛ از آنجا که این امر منجر به گم شدن فضا در دیسک بزرگتر می‌شود، تاییدیه آن مورد نیاز است.

مهمتر از آن به حالت دیسک mirror توجه کنید. حالت عادی در آرایه RAID که به صورت mirror باشد مشابهت کامل محتوا در هر دو دیسک است. با این حال، ضمانتی برای بوجود آمدن این حالت در زمان ایجاد آرایه وجود ندارد. زیرمجموعه RAID خود این ضمانت را ایجاد می‌کند و به محض اینکه دستگاه RAID ساخته شود عملیات همگام‌سازی صورت می‌گیرد. بعد از گذشت زمان (که وابسته به اندازه‌ دیسک‌ها است) آرایه RAID به حالت “فعال” یا “تمیز” تغییر می‌یابد. نکته اینکه در زمان این فاز بازسازی، mirror در یک حالت ناپایدار قرار می‌گیرد که افزونگی داده در آن تضمین نمی‌شود . دیسکی که در این بازه زمانی دچار مشکل گردد ممکن است به حذف داده بینجامد. با توجه به این موضوع، قبل از فاز همگام‌سازی معمولا داده‌های بزرگ و حساس روی آرایه RAID قرار نمی‌گیرند. حتی در حالت ناپایدار نیز، /dev/md1 قابل استفاده است و یک فایل سیستم می‌تواند روی آن ایجاد گردد و داده‌های روی آن قرار گیرند.

نکته آغاز یک mirror در حالت ناپایدار

بعضی وقت‌ها در زمان آغاز mirror از RAID-1 دو دیسک بلافاصله قابل دسترس نخواهند بود، برای نمونه به این دلیل که یکی از دیسک‌ها برای ذخیره داده‌هایی استفاده شده است که دیگری می‌خواهد از آن mirror بگیرد. در چنین شرایطی، امکان ارجاع یک آرایه RAID-1 ناپایدار با استفاده از پارامتر missing بجای نام دستگاه در mdadm وجود دارد. زمانی که از داده در “mirror” رونوشت گرفته شود، دیسک قدیمی می‌تواند به آرایه اضافه گردد. سپس همگام‌سازی صورت می‌گیرد که امکان افزونگی داده با استفاده از دیسک قدیمی را فراهم می‌آورد.

نکته برپایی یک mirror بدون همگام‌سازی

آرایه‌های RAID-1 اغلب به منظور ایجاد یک دیسک جدید و خالی استفاده می‌شوند. از این رو محتوای اولیه دیسک خیلی حائز اهمیت نیست، از این رو باید دانست داده‌ای که پس از ایجاد فایل سیستم در آرایه قرار می‌گیرد قابل دسترس خواهد بود.

شاید این سوال پیش بیاید که هدف از همگام‌سازی دو دیسک در زمان ایجاد آرایه چیست. چرا به یکسان بودن محتوایی که روی ناحیه‌های این آرایه قرار می‌گیرد اهمیت بدهیم وقتی می‌دانیم تنها پس از نوشتن روی آن است که می‌توان به آن‌ها دسترسی داشت؟

خوشبختانه، این فاز همگام‌سازی می‌تواند با استفاده از گزینه --assume-clean در mdadm در نظر گرفته نشود. اگرچه، این گزینه ممکن است منجر به سردرگمی در مواردی شود که داده اولیه خوانده خواهد شد (برای نمونه، وقتی یک فایل سیستم هم اکنون روی دیسک موجود باشد)، به همین دلیل است که به صورت پیشفرض فعال نیست.

اکنون بیایید ببینیم در زمان بروز مشکل برای یکی از آرایه‌های RAID-1 چه اتفاقی می‌افتد. mdadm و به طور خاص گزینه --fail آن، امکان شبیه‌سازی این نقص دیسک را بوجود می‌آورد:

# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
           Version : 1.2
     Creation Time : Mon Feb 28 02:07:48 2022
        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 : Mon Feb 28 02:15:34 2022
             State : clean, degraded 
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 1
     Spare Devices : 0

Consistency Policy : resync

              Name : debian:1  (local to host debian)
              UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
            Events : 19

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

       1       8       48        -      faulty   /dev/sde

محتوای آرایه هنوز قابل دسترس است (و در صورت اتصال به فایل سیستم، وقفه‌ای در برنامه‌ها ایجاد نمی‌شود) اما امنیت داده دیگر تضمین نمی‌شود: در صورت بروز نقص برای دیسک sdd داده از بین می‌رود. به منظور پیشگیری از این خطر دیسک معیوب را با sdf جایگزین می‌کنیم:

# mdadm /dev/md1 --add /dev/sdf
mdadm: added /dev/sdf
# mdadm --detail /dev/md1
/dev/md1:
           Version : 1.2
     Creation Time : Mon Feb 28 02:07:48 2022
        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 : 3
       Persistence : Superblock is persistent

       Update Time : Mon Feb 28 02:25:34 2022
             State : clean, degraded, recovering 
    Active Devices : 1
   Working Devices : 2
    Failed Devices : 1
     Spare Devices : 1

Consistency Policy : resync

    Rebuild Status : 47% complete

              Name : debian:1  (local to host debian)
              UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
            Events : 39

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

       1       8       48        -      faulty   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
           Version : 1.2
     Creation Time : Mon Feb 28 02:07:48 2022
        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 : 3
       Persistence : Superblock is persistent

       Update Time : Mon Feb 28 02:25:34 2022
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 1
     Spare Devices : 0

Consistency Policy : resync

              Name : debian:1  (local to host debian)
              UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
            Events : 41

    Number   Major   Minor   RaidDevice State
       0       8       34        0      active sync   /dev/sdd2
       2       8       64        1      active sync   /dev/sdf

       1       8       48        -      faulty   /dev/sde

در اینجا نیز، کرنل به صورت خودکار فاز بازسازی آرایه را آغاز می‌کند که طی آن با وجود قابل دسترس بودن، آرایه در یک حالت ناپایدار قرار دارد. زمانی که بازسازی تمام شود، آرایه RAID به حالت عادی خود باز می‌گردد. به منظور سازگاری با حالت کلاسیک RAID که از دو دیسک برای mirror استفاده می‌کند، می‌توان دیسک sde را حذف کرد؛

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

از این لحظه، درایو می‌تواند در زمان خاموش شدن سرور یا در صورت پشتیبانی سخت‌افزاری از how-swap به صورت دستی جدا گردد. چنین پیکربندی شامل برخی کنترلرهای SCSI، اغلب دیسک‌های SATA و درایوهای خارجی که روی USB یا Firewire است.

12.1.1.3. پشتیبان‌گیری از پیکربندی

Most of the meta-data concerning RAID volumes are saved directly on the disks that make up these arrays, so that the kernel can detect the arrays and their components and assemble them automatically when the system starts up. However, backing up this configuration is encouraged, because this detection isn't fail-proof, and it is only expected that it will fail precisely in sensitive circumstances. In our example, if the sde disk failure had been real (instead of simulated) and the system had been restarted without removing this sde disk, this disk could start working again due to having been probed during the reboot. The kernel would then have three physical elements, each claiming to contain half of the same RAID volume. In reality this leads to the RAID starting from the individual disks alternately - distributing the data also alternately, depending on which disk started the RAID in degraded mode Another source of confusion can come when RAID volumes from two servers are consolidated onto one server only. If these arrays were running normally before the disks were moved, the kernel would be able to detect and reassemble the pairs properly; but if the moved disks had been aggregated into an md1 on the old server, and the new server already has an md1, one of the mirrors would be renamed.

از این رو، پشتیبان‌گیری از فایل پیکربندی اهمیت می‌یابد. شیوه استاندارد اینکار ویرایش فایل /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*

# 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/md/0  metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0
ARRAY /dev/md/1  metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1
# This configuration was auto-generated on Mon, 28 Feb 2022 01:53:48 +0100 by mkconf

یکی از جزئیات کاربری آن گزینه DEVICE است، که دستگاه‌های مورد نیاز برای جستجوی خودکار اجزای آرایه‌های RAID در سیستم را مشخص می‌کند. در مثال ما، ما گزینه پیشفرض partitions containers را با فهرستی از دستگاه‌ها جایگزین کردیم چرا که قصد استفاده از تمام دیسک و نه قسمت‌هایی از پارتیشن آن را برای برخی آرایه‌ها داشتیم.

دو خط آخر در مثال ما به کرنل اجازه می‌دهند که با استفاده از شماره آرایه عملیات تشخیص و راه‌اندازی آن‌ها را انجام دهد. اطلاعات جانبی ذخیره شده روی دیسک برای جمع‌آوری آرایه‌ها کافی است، ولی نه برای تشخیص شماره آن‌ها (و نام دستگاه /dev/md* منطبق با آن).

خوشبختانه، این خطوط به صورت خودکار تولید می‌شوند:

# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md/0  metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0
ARRAY /dev/md/1  metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1

محتوای این دو خط آخر وابسته به تعداد دیسک‌های استفاده شده در آرایه نیست. پس هنگام جایگزینی یک دیسک معیوب با جدید نیازی به تولید مجدد این خطوط نیست. از طرف دیگر، در زمان ایجاد یا حذف یک آرایه RAID، این فایل باید بروزرسانی گردد.

12.1.2. LVM

LVM که مخفف Logical Volume Manager است، روشی دیگر برای انتزاع دستگاه‌های منطقی از نمونه‌های فیزیکی است که بجای قابلیت اعتماد روی افزایش انعطاف‌پذیری تمرکز دارد. 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 به LV این است که کاملا مستقل از اجزای فیزیکی آن (PV) انجام می‌شود. یک VG تنها با یک قسمت فیزیکی (مانند یک دیسک) می‌تواند به چندین دستگاه منطقی تقسیم شود؛ به طور مشابه، یک VG با چندین دیسک فیزیکی می‌تواند به عنوان یک دستگاه منطقی بزرگ ظاهر شود. تنها محدودیت مشخص این است که اندازه کل اختصاص یافته به LVها نمی‌تواند بیشتر از مجموع اندازه PVها در گروه دستگاه‌ها باشد.

اغلب منطقی است که به منظور داشتن همگنی بین اجزای فیزیکی یک VG، آن را به دستگاه‌های مجازی تقسیم کرد که الگوهای مشابهی در کارکرد داشته باشند. برای نمونه، اگر سخت‌افزار موجود شامل دیسک‌های سریع و کند باشد، دیسک‌های سریع می‌توانند درون یک VG و دیسک‌های کند درون دیگری قرار گیرند؛ تکه‌های اولی می‌توانند به برنامه‌هایی اختصاص یابند که نیازمند دسترسی سریع به دیسک هستند، در صورتی که از دومی برای سایر وظایف متداول دیسک استفاده می‌شود.

در هر صورت، به خاطر بسپارید که یک LV به طور مشخص به هیچ PV متصل نیست. امکان تاثیرگذاری روی جایی که داده از یک LV به صورت فیزیکی می‌آید وجود دارد، اما این امکان برای کاربردهای روزانه الزامی نیست. از طرف دیگر، زمانی که مجموعه فیزیکی از اجزای یک VG گسترش می‌یابند، مکان ذخیره‌سازی فیزیکی منطبق با یک LV می‌توانند بین چند دیسک مهاجرت کنند (به صورتی که درون PVهای اختصاص‌یافته به VG قرار داشته باشند).

12.1.2.2. برپایی LVM

بیایید فرآیند گام به گام برپایی LVM برای یک کاربرد متداول را دنبال کنیم: می‌خواهیم یک موقعیت ذخیره‌سازی پیچیده را ساده کنیم. چنین موقعیتی معمولا با گذشت زمان و گره خوردن مقیاس‌های موقتی انباشتگی صورت می‌گیرد. برای این منظور، سروری را در نظر می‌گیریم که نیازهای ذخیره‌سازی آن طی زمان تغییر کرده است که پارتیشن‌های موجود آن بین چندین دیسک فیزیکی مختلف به مانند یک مسیر مارپیچ قرار گرفته‌اند. به عبارت دیگر، پارتیشن‌های زیر موجود هستند:

درون دیسک sdb،‌ یک پارتیشن ۴ گیگابایت به نام sdb2؛
درون دیسک sdc،‌ یک پارتیشن ۳ گیگابایت به نام sdc3؛
دیسک sdd،‌ با ظرفیت ۴ گیگابایت کاملا موجود؛
درون دیسک sdf،‌ یک پارتیشن ۴ گیگابایت به نام sdf1 و یک پارتیشن ۵ گیگابایت به نام sdf2.

علاوه بر این، تصور می‌کنیم که دیسک‌های sdb و sdf سریع‌تر از دو دیسک دیگر هستند.

هدف ما برپایی یه دستگاه منطقی برای سه برنامه مختلف است: یک سرور فایل که به ۵ گیگابایت فضای ذخیره‌سازی نیاز دارد، یک پایگاه‌داده (۱ گیگابایت) و فضایی برای پشتیبان‌گیری (۱۲ گیگابایت). دوتای اول به عملکرد بالا نیاز دارند اما پشتیبان‌گیری چنین حساسیتی در دسترسی سریع ندارد. تمام این محدودیت‌ها از استفاده پارتیشن‌ها به صورت مستقیم جلوگیری می‌کنند؛ استفاده از 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               yK0K6K-clbc-wt6e-qk9o-aUh9-oQqC-k1T71B

# 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 فهرستی از PVها را با دو قالب خروجی ممکن نمایش می‌دهد.

اکنون بیایید این عناصر فیزیکی را با استفاده از vgcreate درون VG قرار دهیم. PV دیسک‌های سریع را درون VG به نام vg_critical و دیسک‌های کند را درون VG به نام 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               JgFWU3-emKg-9QA1-stPj-FkGX-mGFb-4kzy1G

# 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 مختلف وجود دارد. ما از یک پیشوند vg_ برای نامگذاری VGها استفاده کردیم، اما چیزی بیشتر از رعایت یک استاندارد نیست.

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                Nr62xe-Zu7d-0u3z-Yyyp-7Cj1-Ej2t-gw04Xd
  LV Write Access        read/write
  LV Creation host, time debian, 2022-03-01 00:17:46 +0100
  LV Status              available
  # open                 0
  LV Size                5.00 GiB
  Current LE             1280
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

# lvcreate -n lv_base -L 1G vg_critical
  Logical volume "lv_base" created.
# lvcreate -n lv_backups -L 11.98G vg_normal
  Rounding up size to full physical extent 11.98 GiB
  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 و اندازه آن با گزینه -L مشخص می‌شود. البته، به دستور باید اعلام کنیم که از کدام VG می‌خواهیم استفاده شود.

مطالعه بیشتر گزینه‌های lvcreate

دستور lvcreate شامل چندین گزینه است که چگونگی ایجاد LV را مشخص می‌کند.

ابتدا بیایید گزینه -l را توضیح دهیم، که با استفاده از آن اندازه LV می‌تواند به عنوان تعداد بلاک‌ها در مقایسه با واحدهای “انسانی” که در بالا استفاده کردیم مشخص گردد. این بلاک‌ها که به نام PE یا physical extents در زبان LVM مطرح می‌شوند، واحدهای پیوسته از فضای ذخیره‌سازی در PVها می‌باشند که نمی‌توان آن‌ها را بین LVها تقسیم کرد. زمانی که می‌خواهیم یک فضای ذخیره‌سازی با دقت بالا را برای یک LV تعریف کنیم، برای نمونه استفاده از فضای کامل، استفاده از گزینه -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 Mar  1 00:17 control
lrwxrwxrwx 1 root root       7 Mar  1 00:19 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root       7 Mar  1 00:17 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root       7 Mar  1 00:19 vg_normal-lv_backups -> ../dm-2 
# ls -l /dev/dm-*
brw-rw---- 1 root disk 253, 0 Mar  1 00:17 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Mar  1 00:19 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Mar  1 00:19 /dev/dm-2

NOTE Auto-detecting LVM volumes

زمانی که رایانه راه‌اندازی می‌شود واحد سرویس systemd به نام lvm2-activation به اجرای vgchange -aay می‌پردازد که اینکار گروه‌های مجازی را “فعال” می‌کند: ابتدا به پویش دستگاه‌های موجود می‌پردازد؛ آن‌هایی که توسط گروه‌های فیزیکی برای LVM آماده‌سازی شده‌اند درون زیرسیستم آن قرار می‌گیرند، آن‌هایی که متعلق به گروه‌های مجازی باشند گردآوری شده و گروه‌های مجازی آن أغاز و قابل استفاده می‌گردند. بنابراین هنگام ایجاد یا تغییر گروه‌های LVM نیازی به ویرایش فایل‌های پیکربندی نیست.

با این حال، به یاد داشته باشید که ساختار عناصر LVM (گروه‌های فیزیکی و منطقی همراه با گروه‌های دستگاه) در /etc/lvm/backup پشتیبان‌گیری می‌شوند، که می‌تواند در زمان بروز مشکل (یا اطلاع از عملکرد آن) مورد استفاده قرار گیرد.

برای ساده‌تر کردن کارها، پیوندهای نمادین متعارف نیز در دایرکتوری‌های شامل VGها ایجاد شده است:

# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 Mar  1 00:19 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Mar  1 00:17 lv_files -> ../dm-0 
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Mar  1 00:19 lv_backups -> ../dm-2

سپس LVها می‌توانند مانند پارتیشن‌های استاندارد مورد استفاده قرار گیرند:

# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done                            
Creating filesystem with 3140608 4k blocks and 786432 inodes
Filesystem UUID: 7eaf0340-b740-421e-96b2-942cdbf29cb3
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   24K   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.1.2.3. LVM در گذر زمان

با اینکه توانایی گردآوری پارتیشن‌‌ها یا دیسک‌های فیزیکی بسیار متداول است، این تنها مزیت استفاده از LVM نیست. انعطاف‌پذیری آن در گذر زمان و تغییر رویکرد ذخیره‌سازی، مشخص می‌شود. در مثال ما، تصور کنیم که فایل‌های بزرگ جدیدی قرار است درون سرور فایل قرار گیرند که LV اختصاص‌یافته به آن گنجایش کافی را ندارد. از آنجا که از تمام فضای 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.46.2 (28-Feb-2021)
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 و zfs بدون نیاز به قطع اتصال می‌توانند افزایش یابند؛ کاهش اندازه نیازمند قطع اتصال است. فایل سیستم reiserfs امکان تغییر اندازه آنلاین را در دو جهت فراهم می‌سازد. ext2 مقدس، اما نیازمند قطع اتصال در دو جهت است.

برای توسعه گروهی که از پایگاه‌داده میزبانی می‌کند نیز به همین ترتیب می‌توان اقدام کرد، با این تفاوت که به انتهای فضای ذخیره‌سازی موجود VG رسیدیم:

# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  974M  883M   25M  98% /srv/base
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree   
  vg_critical   2   2   0 wz--n- 7.99g 1016.00m

No matter, since LVM allows adding physical volumes to existing volume groups. For instance, maybe we've noticed that the sdb3 partition, which was so far used outside of LVM, only contained archives that could be moved to lv_backups. We can now recycle it and integrate it to the volume group, and thereby reclaim some available space. This is the purpose of the vgextend command. Of course, the partition must be prepared as a physical volume beforehand. Once the VG has been extended, we can use similar commands as previously to grow the logical volume then the filesystem:

# pvcreate /dev/sdb3
  Physical volume "/dev/sdb3" successfully created.
# vgextend vg_critical /dev/sdb3
  Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize   VFree 
  vg_critical   3   2   0 wz--n- <12.99g <5.99g 
# lvresize -L 2G vg_critical/lv_base
[...]
# resize2fs /dev/vg_critical/lv_base
[...]
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  2.0G  886M  991M  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 درباره این مشکل راهکاری ندارد. از طرف دیگر، اگر نیازمندی این باشد که یک طرح ذخیره‌سازی انعطاف‌پذیر از گروه‌های مستقل ساختار فیزیکی دیسک‌ها تشکیل گردد، به طور مشخص باید از LVM استفاده کرد چرا که RAID درباره این مشکل راهکاری ندارد.

یادداشت اگر عملکرد مهم باشد...

If input/output speed is of the essence, especially in terms of access times, using LVM and/or RAID in one of the many combinations may have some impact on performances, and this may influence decisions as to which to pick. However, these differences in performance are really minor, and will only be measurable in a few use cases. If performance matters, the best gain to be obtained would be to use non-rotating storage media (solid-state drives or SSDs); their cost per megabyte is higher than that of standard hard disk drives, and their capacity is usually smaller, but they provide excellent performance for random accesses. If the usage pattern includes many input/output operations scattered all around the filesystem, for instance for databases where complex queries are routinely being run, then the advantage of running them on an SSD far outweigh whatever could be gained by picking LVM over RAID or the reverse. In these situations, the choice should be determined by other considerations than pure speed, since the performance aspect is most easily handled by using SSDs.

سومین کارکرد قابل ذکر زمانی است که بخواهیم دو دیسک را در یک گروه بزرگ‌تر قرار دهیم، خواه به دلایل عملکرد یا داشتن یک فایل سیستم بزرگ‌تر از فضای هر کدام از دیسک‌ها). اینکار با استفاده از یک RAID-0 (یا حتی RAID خطی) و گروه LVM انجام می‌شود. در این موقعیت، بجز محدودیت‌های خارجی (برای نمونه، در چارچوب سایر رایانه‌ها بودن اگر آن‌ها نیز تنها از RAID استفاده کنند)، پیکربندی مورد نظر معمولا LVM خواهد بود. راه‌اندازی اولیه به ندرت پیچیده‌تر خواهد بود و این افزایش پیچیدگی در صورت تغییر نیازمندی‌ها یا افزودن دیسک‌ها جدید قابلیت انعطاف‌پذیری بیشتری را فراهم می‌آورد.

البته یک مورد بسیار جالب نیز وجود دارد، که سیستم ذخیره‌سازی هم باید برابر نقص سخت‌افزاری مقاوم هم انعطاف‌پذیری لازم درباره اختصاص گروه‌های مختلف را داشته باشد. هیچ یک از راهکارهای RAID یا LVM به تنهایی نمی‌توانند این نیازمندی را پوشش دهند؛ اینجا است که از هر دو به صورت همزمان استفاده می‌کنیم - یا یکی بر فراز دیگری. طرح کلی در این مورد و با توجه به اینکه این دو فناوری به بلوغ رسیده‌اند این است که ابتدا با گروه‌بندی دیسک‌ها در تعداد آرایه‌های کوچک RAID از افزونگی داده اطمینان حاصل کرد سپس از این آرایه‌ها برای گروه‌های فیزیکی LVM استفاده کنیم؛ پارتیشن‌های منطقی از این LVها برای فایل سیستم بوجود می‌آیند. نتیجه این تنظیم این است که هنگامی که یک دیسک دچار نقص می‌گردد، تنها تعداد کمی از آرایه‌های RAID نیازمند بازسازی هستند، که اینکار زمان سپری شده توسط مدیر سیستم برای بازیابی را کاهش می‌دهد.

Let's take a concrete example: the public relations department at Falcot Corp needs a workstation for video editing, but the department's budget doesn't allow investing in high-end hardware from the bottom up. A decision is made to favor the hardware that is specific to the graphic nature of the work (monitor and video card), and to stay with generic hardware for storage. However, as is widely known, digital video does have some particular requirements for its storage: the amount of data to store is large, and the throughput rate for reading and writing this data is important for the overall system performance (more than typical access time, for instance). These constraints need to be fulfilled with generic hardware, in this case two 300 GB SATA hard disk drives; the system data must also be made resistant to hardware failure, as well as some of the user data. Edited video clips must indeed be safe, but video rushes pending editing are less critical, since they're still on the videotapes.

از RAID-1 و LVM به صورت ترکیبی برای رفع این محدودیت‌ها استفاده شده است. دیسک‌ها به دو کنترلر مختلف SATA به منظور بهینه‌سازی دسترسی موازی و کاهش خطر نقص همزمان متصل شده‌اند که به عنوان sda و sdc ظاهر می‌شوند. آن‌ها با توجه به طرح زیر پارتیشن‌بندی شده‌اند:

# sfdisk -l /dev/sda
Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: SAMSUNG MZ7LM960
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: gpt
Disk identifier: BB14C130-9E9A-9A44-9462-6226349CA012

Device         Start        End   Sectors   Size Type
/dev/sda1        2048       4095      2048     1M BIOS boot
/dev/sda2        4096  100667391 100663296    48G Linux RAID
/dev/sda3   100667392  134221823  33554432    16G Linux RAID
/dev/sda4   134221824  763367423 629145600   300G Linux RAID
/dev/sda5   763367424 1392513023 629145600   300G Linux RAID
/dev/sda6  1392513024 1875384974 482871951 230.3G Linux LVM

The first partitions of both disks are BIOS boot partitions.
The next two partitions sda2 and sdc2 (about 48 GB) are assembled into a RAID-1 volume, md0. This mirror is directly used to store the root filesystem.
The sda3 and sdc3 partitions are assembled into a RAID-0 volume, md1, and used as swap partition, providing a total 32 GB of swap space. Modern systems can provide plenty of RAM and our system won't need hibernation. So with this amount added, our system will unlikely run out of memory.
The sda4 and sdc4 partitions, as well as sda5 and sdc5, are assembled into two new RAID-1 volumes of about 300 GB each, md2 and md3. Both these mirrors are initialized as physical volumes for LVM, and assigned to the vg_raid volume group. This VG thus contains about 600 GB of safe space.
The remaining partitions, sda6 and sdc6, are directly used as physical volumes, and assigned to another VG called vg_bulk, which therefore ends up with roughly 460 GB of space.

زمانی که VGها ایجاد شوند، به روشی بسیار منعطف می‌توانند پارتیشن‌بندی گردند. به یاد داشته باشید که LVهای ایجاد شده در vg_raid در صورت نقص دیسک‌ها نیز نگهداری می‌شوند که این مورد درباره LVهای ایجاد شده در 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 مقابل دیگران) درباره امنیت داده است: داده‌ای که روی هر دو عنصر یک mirror از RAID-1 نوشته می‌شود کاملا یکسان است و این امکان وجود دارد که با نادیده‌گرفتن ساختار RAID یکی از دیسک‌ها را به صورت مستقیم متصل کنیم. در صورتی که یک باگ کرنل موجود باشد، برای نمونه اگر اطلاعات جانبی LVM خراب شود، امکان راه‌اندازی حداقلی سیستم برای دسترسی به داده حیاتی مانند ساختار دیسک‌های موجود در آرایه‌های RAID و LVM موجود است؛ این اطلاعات جانبی می‌تواند بازسازی شده و فایل‌ها دوباره قابل دسترس شوند، تا سیستم به حالت عادی خود بازگردد.

The rationale for the second split (md2 vs. md3) is less clear-cut, and more related to acknowledging that the future is uncertain. When the workstation is first assembled, the exact storage requirements are not necessarily known with perfect precision; they can also evolve over time. In our case, we can't know in advance the actual storage space requirements for video rushes and complete video clips. If one particular clip needs a very large amount of rushes, and the VG dedicated to redundant data is less than halfway full, we can re-use some of its unneeded space. We can remove one of the physical volumes, say md3, from vg_raid and either assign it to vg_bulk directly (if the expected duration of the operation is short enough that we can live with the temporary drop in performance), or undo the RAID setup on md3 and integrate its components sda5 and sdc5 into the bulk VG (which grows by 600 GB instead of 300 GB); the lv_rushes logical volume can then be grown according to requirements.