BootDegradedRaid
Size: 3625
Comment: reworded use cases
|
Size: 4238
Comment: --incremental assembly option
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
## page was renamed from BootDegradedRAID | |
Line 22: | Line 23: |
* Kim uses software RAID since it is less expensive than hardware RAID, and since it is always available on any Ubuntu system with multiple disk devices. She particularly likes it on low-end and small-form-factor servers without built-in Hardware RAID, such as her arrays of blades and 1-U rack mount systems. She uses RAID1 (mirroring) as a convenient mechanism for providing runtime failover of hard disks in Ubuntu. Kim remotely administers her systems, where she has taken great care to use redundant disks in a RAID1 configuration. She absolutely wants to be able to tolerate a RAID degradation event and continue to boot such systems in an unattended manner until she is able to replace the faulty hardware. * Steph also uses software RAID1 on her /boot and / filesystems. Steph is ''always'' physically present at the console when she reboots systems, and she always has spare disks on hand. Steph ''never'' wants to boot into a system with a degraded MD array, and so she's glad that this new feature of Ubuntu will be configurable (booting vs. system recovery shell). |
* Kim uses software RAID since it is less expensive than hardware RAID, and since it is always available on any Ubuntu system with multiple disk devices. She particularly likes it on low-end and small-form-factor servers without built-in Hardware RAID, such as her arrays of blades and 1-U rack mount systems. She uses RAID1 (mirroring) as a convenient mechanism for providing runtime failover of hard disks in Ubuntu. Kim remotely administers her systems, where she has taken great care to use redundant disks in a RAID1 configuration. She absolutely wants to be able to tolerate a RAID degradation event and continue to boot such systems in an unattended manner until she is able to replace the faulty hardware. After rebooting her system following a primary drive failure, the system automatically boots from the secondary drive and brings up the RAID in degraded mode in a fully functional (though unprotected) configuration, since she specified in her system configuration to boot even if the RAID is degraded. * Steph also uses software RAID1 on her /boot and / filesystems. Steph is ''always'' physically present at the console when she reboots systems, and she always has spare disks on hand. Steph ''never'' wants to boot into a system with a degraded MD array. Steph configures her system to trap booting to a degraded array and instead deliver the system to a recovery console, thus more conservatively protecting her data at the expense of yielding her system unbootable in an unattended manner. * HotplugRaid |
Line 35: | Line 36: |
* current mdadm supports the new --incremental assembly. | |
Line 56: | Line 58: |
* Compare with HotplugRaid for a common use and test case. |
Launchpad Entry: https://blueprints.edge.launchpad.net/ubuntu/+spec/boot-degraded-raid
Created: 2008-05-30
Contributors: DustinKirkland
Packages affected: mdadm, grub, initramfs, udev, lvm2
Summary
This specification defines a methodology for enhancing Ubuntu's boot procedures to configure and support booting a system dependent on a degraded RAID1 device.
Rationale
Ubuntu's installer currently supports installation to software RAID1 targets for /boot and /. When one of the mirrored disks fails, and mdadm marks the RAID degraded, it becomes impossible to reboot the system in an unattended manner.
Booting Ubuntu with a failed device in a RAID1 will force the system into a recovery console.
In some cases, this is the desired behavior, as a local system administrator would want to backup critical data, cleanly halt the system, and replace the faulty hardware immediately.
In other cases, this behavior is highly undesired--particularly when the system administrator is remotely located and would prefer a system with redundant disks tolerate a failed device even on reboot.
Use Cases
- Kim uses software RAID since it is less expensive than hardware RAID, and since it is always available on any Ubuntu system with multiple disk devices. She particularly likes it on low-end and small-form-factor servers without built-in Hardware RAID, such as her arrays of blades and 1-U rack mount systems. She uses RAID1 (mirroring) as a convenient mechanism for providing runtime failover of hard disks in Ubuntu. Kim remotely administers her systems, where she has taken great care to use redundant disks in a RAID1 configuration. She absolutely wants to be able to tolerate a RAID degradation event and continue to boot such systems in an unattended manner until she is able to replace the faulty hardware. After rebooting her system following a primary drive failure, the system automatically boots from the secondary drive and brings up the RAID in degraded mode in a fully functional (though unprotected) configuration, since she specified in her system configuration to boot even if the RAID is degraded.
Steph also uses software RAID1 on her /boot and / filesystems. Steph is always physically present at the console when she reboots systems, and she always has spare disks on hand. Steph never wants to boot into a system with a degraded MD array. Steph configures her system to trap booting to a degraded array and instead deliver the system to a recovery console, thus more conservatively protecting her data at the expense of yielding her system unbootable in an unattended manner.
Scope
The scope of this specification is to solve this problem within Ubuntu's software raid support and default bootloader within the Intrepid Ibex development cycle.
Design / Work Items
Bootloader
- grub-install needs to detect (/boot on an md?) or be configured to install grub to multiple devices, thus rendering multiple disks bootable
- should probably also document that manual BIOS changes may be required for disk boot failover to occur properly
MD Error Handling
- current mdadm supports the new --incremental assembly.
- more verbose error hook messages
- teach md error handler how to bring up md in degraded mode
Root Filesystem Wait
- reduce rootfs wait timeout to 30 seconds (DONE)
- option to abort rootfs wait, seems non-trivial, but quite handy
Implementation
Will be documented here as implementation occurs
Outstanding Issues
References
https://blueprints.launchpad.net/ubuntu/+spec/boot-degraded-raid
https://wiki.ubuntu.com/UDS-Intrepid/Report/Server#head-75c995bdf63bb5afe0f08461aba9200b6c95814f
https://lists.ubuntu.com/archives/ubuntu-devel/2007-September/024221.html
http://www.outflux.net/blog/archives/2006/04/23/grub-yaird-mdadm-and-missing-drives/
http://osdir.com/ml/linux.redhat.anaconda.devel/2005-05/threads.html
wiki:120375
wiki:125471
Compare with HotplugRaid for a common use and test case.
BootDegradedRaid (last edited 2010-04-21 10:02:37 by 188-194-18-172-dynip)