mdadm コマンド、システムの他の部分に RAID アレイを統合するためのスクリプトやツール、監視システムが含まれます。
sdb ディスク (4 GB) は全領域を利用できます。
sdc ディスク (4 GB) は全領域を利用できます。
sdd ディスクは sdd2 パーティション (約 4 GB) だけを利用できます。
sde ディスク (4 GB) は全領域を利用できます。
#mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdcmdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. #mdadm --query /dev/md0/dev/md0: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail. #mdadm --detail /dev/md0/dev/md0: Version : 1.2 Creation Time : Wed May 6 09:24:34 2015 Raid Level : raid0 Array Size : 8387584 (8.00 GiB 8.59 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Wed May 6 09:24:34 2015 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Chunk Size : 512K Name : mirwiz:0 (local to host mirwiz) UUID : bb085b35:28e821bd:20d697c9:650152bb Events : 0 Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 32 1 active sync /dev/sdc #mkfs.ext4 /dev/md0mke2fs 1.42.12 (29-Aug-2014) Creating filesystem with 2095104 4k blocks and 524288 inodes Filesystem UUID: fff08295-bede-41a9-9c6a-8c7580e520a6 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done #mkdir /srv/raid-0#mount /dev/md0 /srv/raid-0#df -h /srv/raid-0ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/md0 7.9G 18M 7.4G 1% /srv/raid-0
mdadm --create コマンドには複数のパラメータが必要です。具体的に言えば、作成するボリュームの名前 (/dev/md*、MD は Multiple Device を意味します)、RAID レベル、ディスク数 (普通この値は RAID-1 とそれ以上のレベルでのみ意味があるにも関わらず、これは必須オプションです)、RAID を構成する物理デバイスを指定する必要があります。RAID デバイスを作成したら、RAID デバイスを通常のパーティションを取り扱うのと同様のやり方で取り扱うことが可能です。すなわち、ファイルシステムを作成したり、ファイルシステムをマウントしたりすることが可能です。ここで作成する RAID-0 ボリュームに md0 と名前を付けたのは偶然に過ぎない点に注意してください。アレイに付けられた番号と冗長性の度合いを関連付ける必要はありません。また、/dev/md0 の代わりに /dev/md/linear のようなパラメータを mdadm に渡すことで、名前付き RAID アレイを作成することも可能です。
#mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sdemdadm: 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?ymdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. #mdadm --query /dev/md1/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail. #mdadm --detail /dev/md1/dev/md1: Version : 1.2 Creation Time : Wed May 6 09:30:19 2015 Raid Level : raid1 Array Size : 4192192 (4.00 GiB 4.29 GB) Used Dev Size : 4192192 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Wed May 6 09:30:40 2015 State : clean, resyncing (PENDING) Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Name : mirwiz:1 (local to host mirwiz) UUID : 6ec558ca:0c2c04a0:19bca283:95f67464 Events : 0 Number Major Minor RaidDevice State 0 8 50 0 active sync /dev/sdd2 1 8 64 1 active sync /dev/sde #mdadm --detail /dev/md1/dev/md1: [...] State : clean [...]
mdadm は物理デバイス同士のサイズが異なる点を指摘しています。さらに、このことによりサイズが大きい側のデバイスの一部の領域が使えなくなるため、確認が求められています。
/dev/md1 を利用することが可能で、ファイルシステムを作成したり、データのコピーを取ったりすることが可能という点に注意してください。
mdadm に --fail オプションを付けることで、ディスク障害を模倣することが可能です。
#mdadm /dev/md1 --fail /dev/sdemdadm: set /dev/sde faulty in /dev/md1 #mdadm --detail /dev/md1/dev/md1: [...] Update Time : Wed May 6 09:39:39 2015 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 Name : mirwiz:1 (local to host mirwiz) UUID : 6ec558ca:0c2c04a0:19bca283:95f67464 Events : 19 Number Major Minor RaidDevice State 0 8 50 0 active sync /dev/sdd2 2 0 0 2 removed 1 8 64 - faulty /dev/sde
sdd ディスクにも障害が発生した場合、データは失われます。この危険性を避けるために、障害の発生したディスクを新しいディスク sdf に交換します。
#mdadm /dev/md1 --add /dev/sdfmdadm: added /dev/sdf #mdadm --detail /dev/md1/dev/md1: [...] Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Wed May 6 09:48:49 2015 State : clean, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 1 Spare Devices : 1 Rebuild Status : 28% complete Name : mirwiz:1 (local to host mirwiz) UUID : 6ec558ca:0c2c04a0:19bca283:95f67464 Events : 26 Number Major Minor RaidDevice State 0 8 50 0 active sync /dev/sdd2 2 8 80 1 spare rebuilding /dev/sdf 1 8 64 - faulty /dev/sde #[...][...] #mdadm --detail /dev/md1/dev/md1: [...] Update Time : Wed May 6 09:49:08 2015 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 1 Spare Devices : 0 Name : mirwiz:1 (local to host mirwiz) UUID : 6ec558ca:0c2c04a0:19bca283:95f67464 Events : 41 Number Major Minor RaidDevice State 0 8 50 0 active sync /dev/sdd2 2 8 80 1 active sync /dev/sdf 1 8 64 - faulty /dev/sde
sde ディスクをアレイから削除することを伝えることが可能です。削除することで、2 台のディスクからなる古典的な RAID ミラーになります。
#mdadm /dev/md1 --remove /dev/sdemdadm: hot removed /dev/sde from /dev/md1 #mdadm --detail /dev/md1/dev/md1: [...] Number Major Minor RaidDevice State 0 8 50 0 active sync /dev/sdd2 2 8 80 1 active sync /dev/sdf
sde ディスク障害が本物で (模倣でない)、sde ディスクを取り外す前にシステムを再起動した場合、sde ディスクは再起動中に検出され、システムに復帰します。カーネルは 3 つの物理ディスクを検出し、それぞれのディスクが同じ RAID ボリュームの片割れであると主張します。さらに別の混乱する状況が考えられます。2 台のサーバで使われていた RAID ボリュームを片方のサーバに集約することを考えてみましょう。ディスクが移動される前、各アレイは正常に実行されていました。カーネルはアレイを検出して、適切なペアを組み立てることが可能です。しかし、片方のサーバに移動されたディスクが前のサーバでは md1 に組み込まれており、さらに新しいサーバが既に md1 という名前のアレイを持っていた場合、どちらか一方の名前が変えられます。
/etc/mdadm/mdadm.conf ファイルを編集することです。以下に例を示します。
例 12.1 mdadm 設定ファイル
# mdadm.conf # # このファイルに関する詳細は mdadm.conf(5) を参照してください。 # # デフォルト (組み込み) 状態ならば、MD スーパーブロックを持つパーティション # (/proc/partitions) とコンテナをすべてスキャンします。以下のようにスキャンする # デバイスを指定することも可能です。必要ならばワイルドカードを使ってください。 DEVICE /dev/sd* # デバイスの自動作成時に使う Debian の標準的なパーミッションを指定します CREATE owner=root group=disk mode=0660 auto=yes # 新規アレイの所属先にローカルシステムを自動登録します HOMEHOST <system> # 監視デーモンに root を警告メールの送信先として通知します MAILADDR root # 既存の MD アレイの定義 ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464 # この設定ファイルは mkconf 3.2.5-3 により # Fri, 18 Jan 2013 00:21:01 +0900 に自動生成されました
DEVICE オプションがあります。これは起動時にシステムが RAID ボリュームの構成情報を自動的に探すデバイスをリストします。上の例では、値をデフォルト値 partitions containers からデバイスファイルを明示したリストに置き換えました。なぜなら、パーティションだけでなくすべてのディスクをボリュームとして使うように決めたからです。
/dev/md* デバイス名にマッチすることを確認する) には不十分です。
#mdadm --misc --detail --brief /dev/md?ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464
/dev 階層のデバイスファイルに現れません。そのため、VG を直接的に操作する危険はありません。
/dev に現れ、他の物理パーティションと同様に取り扱うことが可能です (一般的に言えば、LV にファイルシステムやスワップ領域を作成することが可能です)。
sdb ディスク上の sdb2 パーティション (4 GB)。
sdc ディスク上の sdc3 パーティション (3 GB)。
sdd ディスク (4 GB) は全領域を利用できます。
sdf ディスク上の sdf1 パーティション (4 GB) および sdf2 パーティション (5 GB)。
sdb と sdf が他の 2 台に比べて高速であると仮定しましょう。
pvcreate を使って PV を作成します。
#pvdisplay#pvcreate /dev/sdb2Physical volume "/dev/sdb2" successfully created #pvdisplay"/dev/sdb2" is a new physical volume of "4.00 GiB" --- NEW Physical volume --- PV Name /dev/sdb2 VG Name PV Size 4.00 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID 0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I #for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; donePhysical volume "/dev/sdc3" successfully created Physical volume "/dev/sdd" successfully created Physical volume "/dev/sdf1" successfully created Physical volume "/dev/sdf2" successfully created #pvdisplay -CPV VG Fmt Attr PSize PFree /dev/sdb2 lvm2 --- 4.00g 4.00g /dev/sdc3 lvm2 --- 3.09g 3.09g /dev/sdd lvm2 --- 4.00g 4.00g /dev/sdf1 lvm2 --- 4.10g 4.10g /dev/sdf2 lvm2 --- 5.22g 5.22g
pvdisplay コマンドは既存の PV をリストします。出力フォーマットは 2 種類あります。
vgcreate を使って、これらの PV から VG を構成しましょう。高速なディスクの PV から vg_critical VG を構成します。さらに、これ以外の低速なディスクの PV から vg_normal VG を構成します。
#vgdisplayNo volume groups found #vgcreate vg_critical /dev/sdb2 /dev/sdf1Volume group "vg_critical" successfully created #vgdisplay--- Volume group --- VG Name vg_critical System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 8.09 GiB PE Size 4.00 MiB Total PE 2071 Alloc PE / Size 0 / 0 Free PE / Size 2071 / 8.09 GiB VG UUID bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp #vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2Volume group "vg_normal" successfully created #vgdisplay -CVG #PV #LV #SN Attr VSize VFree vg_critical 2 0 0 wz--n- 8.09g 8.09g vg_normal 3 0 0 wz--n- 12.30g 12.30g
vgdisplay コマンドはかなり簡潔です (そして vgdisplay には 2 種類の出力フォーマットがあります)。同じ物理ディスク上にある 2 つの PV から 2 つの異なる VG を構成することが可能である点に注意してください。また、vg_ 接頭辞を VG の名前に使っていますが、これは慣例に過ぎない点に注意してください。
lvcreate コマンドを少し複雑な構文で実行します。
#lvdisplay#lvcreate -n lv_files -L 5G vg_criticalLogical volume "lv_files" created #lvdisplay--- Logical volume --- LV Path /dev/vg_critical/lv_files LV Name lv_files VG Name vg_critical LV UUID J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT LV Write Access read/write LV Creation host, time mirwiz, 2015-06-10 06:10:50 -0400 LV Status available # open 0 LV Size 5.00 GiB Current LE 1280 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 #lvcreate -n lv_base -L 1G vg_criticalLogical volume "lv_base" created #lvcreate -n lv_backups -L 12G vg_normalLogical volume "lv_backups" created #lvdisplay -CLV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_base vg_critical -wi-a--- 1.00g lv_files vg_critical -wi-a--- 5.00g lv_backups vg_normal -wi-a--- 12.00g
lvcreate に渡します。作成する LV の名前を -n オプションで指定し、サイズを -L オプションで指定します。また、操作対象の VG をコマンドに伝えることが必要です。これはもちろん最後のコマンドラインパラメータです。
/dev/mapper/ に現れます。
#ls -l /dev/mapper合計 0 crw------- 1 root root 10, 236 6月 10 16:52 control lrwxrwxrwx 1 root root 7 6月 10 17:05 vg_critical-lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 6月 10 17:05 vg_critical-lv_files -> ../dm-0 lrwxrwxrwx 1 root root 7 6月 10 17:05 vg_normal-lv_backups -> ../dm-2 #ls -l /dev/dm-*brw-rw---T 1 root disk 253, 0 6月 10 17:05 /dev/dm-0 brw-rw---- 1 root disk 253, 1 6月 10 17:05 /dev/dm-1 brw-rw---- 1 root disk 253, 2 6月 10 17:05 /dev/dm-2
#ls -l /dev/vg_critical合計 0 lrwxrwxrwx 1 root root 7 6月 10 17:05 lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 6月 10 17:05 lv_files -> ../dm-0 #ls -l /dev/vg_normal合計 0 lrwxrwxrwx 1 root root 7 6月 10 17:05 lv_backups -> ../dm-2
#mkfs.ext4 /dev/vg_normal/lv_backupsmke2fs 1.42.12 (29-Aug-2014) Creating filesystem with 3145728 4k blocks and 786432 inodes Filesystem UUID: b5236976-e0e2-462e-81f5-0ae835ddab1d [...] Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done #mkdir /srv/backups#mount /dev/vg_normal/lv_backups /srv/backups#df -h /srv/backupsファイルシス サイズ 使用 残り 使用% マウント位置 /dev/mapper/vg_normal-lv_backups 12G 30M 12G 1% /srv/backups #[...][...] #cat /etc/fstab[...] /dev/vg_critical/lv_base /srv/base ext4 defaults 0 2 /dev/vg_critical/lv_files /srv/files ext4 defaults 0 2 /dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2
vg_critical から分割できる全領域はまだ使い切られていないので、lv_files のサイズを増やすことが可能です。LV のサイズを増やすために lvresize コマンドを使い、LV のサイズの変化にファイルシステムを対応させるために resize2fs を使います。
#df -h /srv/files/ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/mapper/vg_critical-lv_files 5.0G 4.6G 146M 97% /srv/files #lvdisplay -C vg_critical/lv_filesLV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao-- 5.00g #vgdisplay -C vg_criticalVG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 8.09g 2.09g #lvresize -L 7G vg_critical/lv_filesSize of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 7.00 GiB (1792 extents). Logical volume lv_files successfully resized #lvdisplay -C vg_critical/lv_filesLV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao-- 7.00g #resize2fs /dev/vg_critical/lv_filesresize2fs 1.42.12 (29-Aug-2014) Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/vg_critical/lv_files is now 1835008 (4k) blocks long. #df -h /srv/files/ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/mapper/vg_critical-lv_files 6.9G 4.6G 2.1G 70% /srv/files
lv_base のサイズを増加させます。以下の通り lv_base の分割元である vg_critical から分割できる領域は既にほぼ使い切った状態になっています。
#df -h /srv/base/ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/mapper/vg_critical-lv_base 1008M 854M 104M 90% /srv/base #vgdisplay -C vg_criticalVG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 8.09g 92.00m
sdb1 パーティションには、lv_backups に移動しても問題のないアーカイブだけが含まれていた点に気が付いたとしましょう。このため、sdb1 パーティションを vg_critical を構成する PV の 1 つとして再利用することが可能です。こうすることで、vg_critical から lv_base に分割される領域のサイズを増やすことが可能です。これが vgextend コマンドの目的です。もちろん、事前に sdb1 パーティションを PV として準備しなければいけません。vg_critical を拡張したら、先と同様のコマンドを使って先に lv_base のサイズを増加させ、その後に lv_base 上のファイルシステムのサイズを増加させます。
#pvcreate /dev/sdb1Physical volume "/dev/sdb1" successfully created #vgextend vg_critical /dev/sdb1Volume group "vg_critical" successfully extended #vgdisplay -C vg_criticalVG #PV #LV #SN Attr VSize VFree vg_critical 3 2 0 wz--n- 9.09g 1.09g #[...][...] #df -h /srv/base/ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/mapper/vg_critical-lv_base 2.0G 854M 1.1G 45% /srv/base
sda と sdc として現れます。どちらのディスクも以下に示したパーティショニング方針に従ってパーティショニングされます。
#fdisk -l /dev/sdaDisk /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
sda1 と sdc1 パーティション (約 1 GB) から RAID-1 ボリューム md0 を構成します。md0 はルートファイルシステムを保存するために直接的に使われます。
sda2 と sdc2 パーティションから swap パーティションを作成します。スワップ領域のサイズは合計で 2 GB になります。RAM のサイズ 1 GB と合わせれば、ワークステーションで利用できるメモリサイズは十分な量と言えます。
sda5 と sdc5 パーティションおよび sda6 と sdc6 パーティションからそれぞれ約 100 GB の 2 つの新しい RAID-1 ボリューム md1 と md2 を構成します。md1 と md2 は LVM の PV として初期化され、これらの PV から vg_raid VG を構成します。vg_raid は約 200 GB の安全な領域になります。
sda7 と sdc7 はそのまま LVM の PV として初期化され、これらの PV から vg_bulk VG を構成します。vg_bulk はおよそ 200 GB の領域になります。
vg_raid から分割された LV は 1 台のディスク障害に対して耐性を持ちますが、vg_bulk から分割された LV はディスク障害に対する耐性を持たない点を忘れないでください。逆に、vg_bulk は両方のディスクにわたって割り当てられるので、vg_bulk から分割された LV に保存された巨大なファイルの読み書き速度は高速化されるでしょう。
vg_raid から lv_usr、lv_var、lv_home を分割し、各 LV に応じたファイルシステムをホストさせます。さらに、vg_raid からもう一つの大きな LV である lv_movies を分割し、lv_movies に編集済みの最終版の映像をホストさせます。また、vg_bulk からデジタルビデオカメラから取り出したデータ用の大きな lv_rushes と一時ファイル用の lv_tmp を分割します。vg_raid と vg_bulk のどちらから作業領域用の LV を分割するかは簡単に決められるものではありません。つまり、作業領域用の LV は良い性能を必要としますが、編集作業中にディスク障害が起きた場合に作業内容を保護する必要があるでしょうか? この質問の回答次第で、作業領域用の LV を vg_raid か vg_bulk のどちらの VG に作成するかが決まります。
/usr/ をホストしている LV のサイズを簡単に増加することが可能です。