| 1 | [[PageOutline]] |
| 2 | |
| 3 | = about Software RAID = |
| 4 | |
| 5 | = mdadm = |
| 6 | * [http://www.ubuntulinux.jp/getubuntu/releasenotes/810overview Ubuntu 8.10 技術概要 | Ubuntu Japanese Team] #起動時のデグレードRAID設定 |
| 7 | |
| 8 | * /etc/initramfs-tools/conf.d/mdadm |
| 9 | {{{ |
| 10 | # BOOT_DEGRADED: |
| 11 | # Do you want to boot your system if a RAID providing your root filesystem |
| 12 | # becomes degraded? |
| 13 | # |
| 14 | # Running a system with a degraded RAID could result in permanent data loss |
| 15 | # if it suffers another hardware fault. |
| 16 | # |
| 17 | # However, you might answer "yes" if this system is a server, expected to |
| 18 | # tolerate hardware faults and boot unattended. |
| 19 | |
| 20 | BOOT_DEGRADED=false |
| 21 | }}} |
| 22 | * /etc/mdadm/mdadm.conf |
| 23 | {{{ |
| 24 | # instruct the monitoring daemon where to send mail alerts |
| 25 | MAILADDR root |
| 26 | }}} |
| 27 | * /etc/default/mdadm |
| 28 | {{{ |
| 29 | # AUTOCHECK: |
| 30 | # should mdadm run periodic redundancy checks over your arrays? See |
| 31 | # /etc/cron.d/mdadm. |
| 32 | AUTOCHECK=true |
| 33 | |
| 34 | # START_DAEMON: |
| 35 | # should mdadm start the MD monitoring daemon during boot? |
| 36 | START_DAEMON=true |
| 37 | }}} |
| 38 | * /etc/cron.d/mdadm |
| 39 | {{{ |
| 40 | # By default, run at 01:06 on every Sunday, but do nothing unless the day of |
| 41 | # the month is less than or equal to 7. Thus, only run on the first Sunday of |
| 42 | # each month. crontab(5) sucks, unfortunately, in this regard; therefore this |
| 43 | # hack (see #380425). |
| 44 | 6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet |
| 45 | }}} |
| 46 | |
| 47 | == dpkg-reconfigure mdadm == |
| 48 | * [ ... ] がデフォルト値 |
| 49 | |
| 50 | * sudo dpkg-reconfigure mdadm |
| 51 | 1. /etc/default/mdadm AUTOCHECK |
| 52 | {{{ |
| 53 | ┌───────────────────────────┤ Configuring mdadm ├ |
| 54 | │ │ |
| 55 | │ If your kernel supports it (>> 2.6.14), mdadm can periodically check the │ |
| 56 | │ redundancy of your MD arrays (RAIDs). This may be a resource-intensive │ |
| 57 | │ process, depending on your setup, but it could help prevent rare cases │ |
| 58 | │ of data loss. Note that this is a read-only check unless errors are │ |
| 59 | │ found; if errors are found, mdadm will try to correct them, which may │ |
| 60 | │ result in write access to the media. │ |
| 61 | │ │ |
| 62 | │ The default, if turned on, is to run the checks on the first Sunday of │ |
| 63 | │ every month at 01:06 o'clock. │ |
| 64 | │ │ |
| 65 | │ Should mdadm run monthly redundancy checks of the MD arrays? │ |
| 66 | │ │ |
| 67 | │ [<Yes>] <No> │ |
| 68 | │ │ |
| 69 | └────────────────────────────────────── |
| 70 | }}} |
| 71 | 1. /etc/default/mdadm START_DAEMON |
| 72 | {{{ |
| 73 | ┌──────────────────────────┤ Configuring mdadm ├ |
| 74 | ─│ │ |
| 75 | │ The MD (RAID) monitor daemon sends email notifications in response to │ |
| 76 | │ important MD events (such as a disk failure). You probably want to │ |
| 77 | │ enable it. │ |
| 78 | │ │ |
| 79 | │ Do you want to start the MD monitoring daemon? │ |
| 80 | │ │ |
| 81 | │ [<Yes>] <No> │ |
| 82 | │ │ |
| 83 | └────────────────────────────────────── |
| 84 | }}} |
| 85 | 1. /etc/mdadm/mdadm.conf MAILADDR |
| 86 | {{{ |
| 87 | ┌─────────────────────────┤ Configuring mdadm ├─ |
| 88 | ─ │ Please enter the email address of the user who should get the email │ |
| 89 | │ notification for important MD events. │ |
| 90 | │ │ |
| 91 | │ Recipient for email notifications: │ |
| 92 | │ │ |
| 93 | │ root_________________________________________________________________ │ |
| 94 | │ │ |
| 95 | │ <Ok> │ |
| 96 | │ │ |
| 97 | └───────────────────────────────────── |
| 98 | }}} |
| 99 | 1. /etc/initramfs-tools/conf.d/mdadm BOOT_DEGRADED |
| 100 | {{{ |
| 101 | ┌───────────────────────────┤ Configuring mdadm ├ |
| 102 | │ │ |
| 103 | │ If your root filesystem is on a RAID, and a disk is missing at boot, it │ |
| 104 | │ can either boot with the degraded array, or hold the system at a │ |
| 105 | │ recovery shell. │ |
| 106 | │ │ |
| 107 | │ Running a system with a degraded RAID could result in permanent data │ |
| 108 | │ loss if it suffers another hardware fault. │ |
| 109 | │ │ |
| 110 | │ If you do not have access to the server console to use the recovery │ |
| 111 | │ shell, you might answer "yes" to enable the system to boot unattended. │ |
| 112 | │ │ |
| 113 | │ Do you want to boot your system if your RAID becomes degraded? │ |
| 114 | │ │ |
| 115 | │ <Yes> [<No>] │ |
| 116 | │ │ |
| 117 | └────────────────────────────────────── |
| 118 | }}} |
| 119 | * apply settings... |
| 120 | {{{ |
| 121 | * Stopping MD monitoring service mdadm --monitor [ OK ] |
| 122 | Generating array device nodes... done. |
| 123 | Removing any system startup links for /etc/init.d/mdadm-raid ... |
| 124 | update-initramfs: Generating /boot/initrd.img-2.6.24-24-server |
| 125 | Warning: LBA32 addressing assumed |
| 126 | Added Linux * |
| 127 | Added LinuxOLD |
| 128 | The Master boot record of /dev/sda has been updated. |
| 129 | Warning: /dev/sdb is not on the first disk |
| 130 | The Master boot record of /dev/sdb has been updated. |
| 131 | 2 warnings were issued. |
| 132 | * Starting MD monitoring service mdadm --monitor [ OK ] |
| 133 | }}} |