Grow mdadm over lvm

Всем привет.

Есть 2-а сервера на котором сконфигурировано следующее извращение:
Машина имеет 4 диска по 1 Тб.
16 Гб памяти ddr3
Установлен debian squeeze x64:

root@xen2:~# uname -a
Linux xen2 2.6.32-5-xen-amd64 #1 SMP Wed Jan 12 05:46:49 UTC 2011 x86_64 GNU/Linux

Конфигурация дисков:
первые 256 Мб + 32 Гб двух из 4 дисков использовались под raid1 разделы для /boot и swap соответственно
остальное место около 970 Гб на всех 4-ех дисках используется под raid10.
Поверх этого raid10 установлен LVM2 volume group называется xenlvm
/ , /var, /home расположены на lv небольших размеров (сейчас обнаружил, что напутал с выбором lv-ов под диры, ну да не суть):

root@xen2:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/XENLVM-home
9.2G 6.0G 2.8G 69% /
tmpfs 7.6G 0 7.6G 0% /lib/init/rw
udev 7.1G 316K 7.1G 1% /dev
tmpfs 7.6G 0 7.6G 0% /dev/shm
/dev/md3 223M 31M 180M 15% /boot
/dev/mapper/XENLVM-var
9.2G 150M 8.6G 2% /home
/dev/mapper/XENLVM-root
9.2G 2.5G 6.3G 29% /var

Порядка 900 Гб на VG оставлены свободными для создания новых LV, которые предполагается исползовать в качестве блочных девайсов для создания raid 1 c использованием ata over ethernet: вторым блочным устройством для создания такого raid1 должен служить aoe девайс (например e0.1).
Все это нужно чтобы запускать xen-виртуалки для которых дисками будут эти самые raid1 (поверх lvm и aoe).
У машин по две сетевушки. Одной они смотрят в локалку, а вторые служат для соеденения cross кабелем со скоростью 1 Гбит/c для работы с ata over ethernet.

Сразу скажу что это богатство работает:) и довольно шустро, что приятно.


Теперь пример:
xen1 и xen2 - названия машин с одинаковой (описанной выше конфигурацией)
xenlvm - названия volume group на каждой из них
20gigs - название lvm раздела на каждой из них (соответствующего размера)
на машине xen1 том 20gigs вещается по ata over ethernet как e0.1, вот так это выглядит когда смотришь с xen2:

root@xen2:~# aoe-stat
e0.1 21.474GB eth0 4096 up

собираем raid1:
mdadm -C /dev/md5 --level=1 --raid-devices=2 /dev/xenlvm/20gigs /dev/etherd/e0.1

Девайс собирается на ура.
Далее я ставлю туда винду на этот раздел (с Xen-a). Винда летает (c pvops драйвером конечно).

Ну а теперь то зачем я все это писал:) :

В процессе тестирования производительности возник вопрос: а что если мне потребуется увеличить дисковое пространство в виртуалке, ведь это вполне реальный сценарий. Собственно для получения гибкости и отказоустойчивости и было сконфигурировано такое извращение.

Пробую:
1. увеличиваю размеры lv-ов 20gigs на xen1 и xen2.

root@xen2:~# lvextend -L+5G /dev/xenlvm/20gigs

root@xen2:~# lvdisplay /dev/XENLVM/20gigs

--- Logical volume ---
LV Name /dev/XENLVM/20gigs
VG Name XENLVM
LV UUID rp3mvd-C2Ld-S0tv-SBGE-YkyH-h2hh-5pckbr
LV Write Access read/write
LV Status available
# open 0
LV Size 25.00 GiB
Current LE 6400
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 4096
Block device 253:7

Сразу добавлю, что пришлось полностью прибить вещание девайса e0.1 на xen1 и перезапустить его заново, так как aoe-модуль судя по всему не умеет на лету менять размер вещаемых им девайсов.

2. Следующий шаг - увеличить размер /dev/md5 raid1:
его характеристики до попытки увеличения:

md5 : active (auto-read-only) raid1 dm-7[0] etherd/e0.2[1]
20970496 blocks super 1.2 [2/2] [UU]


Увеличиваем размер:

root@xen2:~# mdadm --grow /dev/md5 --size=max
mdadm: component size of /dev/md5 has been set to 20970496K

И тут собственно мы видимо что нифига не изменилось: потому что девайс был размером 20Гб до попытки его увеличить и таким и остался.

Я было начал грешить на AoE -девайс. Но он был не виноват: я создал два тестовых lvm раздела по 5 Гб на xen2 машине , увеличил их на 2 Гб каждый. собрал из них raid1 /dev/md6. сделал mkfs.ext2 на нем. Попытался его увеличить:

root@xen2:~# mdadm --grow /dev/md6 --size=max
mdadm: component size of /dev/md6 has been set to 5241856K

Собственно та же ситуация.

После этого попробовал воспользоваться разными хаутушками с инетов:

http://www.debian-administration.org/articles/424
http://mkfblog.blogspot.com/2007/11/resizing-raid1-system-partition.html
http://www.howtoforge.com/how-to-resize-lvm-software-raid1-partitions-shrink-and-grow

Не помогло.
Я пробовал fail-ить один из разделов и увеличивать raid когда в нем 1 диск:

root@xen2:~# mdadm /dev/md6 --fail /dev/XENLVM/test2 --remove /dev/XENLVM/test2
mdadm: set /dev/XENLVM/test2 faulty in /dev/md6

затем grow:

root@xen2:~# mdadm -G /dev/md6 -z max
mdadm: component size of /dev/md6 has been set to 5241856K

Как видите тот же результат.

Есть у кого-нибудь идеи, если не утомились читать?:)

:( :( Неужто никто не пробовал raid поверх lvm?

извращение)))

Kettler написал:

извращение)))

Может и так. Но если хочеться построить бюджетное решение которое будет и отказоустойчивыми и гибким, то я других вариантов не знаю... ну кроме как заменить софтверный рэйд дисков на аппаратный. А чтобы ресайзить диски виртуалок при этом иметь постоянную отказоустойчивую копию диска виртуалки я других способов не знаю. (ну да есть ISCSI... но у меня его нет)

А если разобрать раид и собрать по новому?

Kettler написал:

А если разобрать раид и собрать по новому?

Так при этом разве суперблок не будет создан заново и данные не будут покоцаны?


О! спасибо тебе добрый человек.

Итак решение простое.
Стопнуть рэйд:
mdadm -S /dev/md0

Собрать рэйд сказав ему что размер девайсов вырос (обновляем инфу в суперблоках каждого девайса):
mdadm -A /dev/md0 -U devicesize /dev/testdeb/blockdev[1-2]

После этого mdadm сможет увидеть что девайс стал больше и сможет корректно выполнить увеличение raid массива:
mdadm -G -z max /dev/md0

Ну и естественно сделает resync.

Да. я эту процедуру проделал на виртуалке линуксовой. С виндой не пробовал еще.

Я помню игрался когда то. Разобрал собрал и всё было норм.
Но не даю гарантию что данные не потеряешь но я не терял.
Ну если не форматнёшь с чего данные потеряешь?
Ведь на lvm за бекапь сначала и пробуй

По ходу получилось

Да, спасибо очень помог.