LUN и Oracle

новый ЛУН на сторадже, монтирую как RAW device, делаю на нем physical volume, потом делаю vgextend, pvmove на больший pv, потом vgreduce и pvremove

Почему бы просто не увеличить существующий LUN на сторедже и не сделать pvresize?

Поэтому вопрос - есть ли у вас такая практика, что база данных бежит на 2 LUNах, объединенных в одну virtual group на уровне ОС, и если да, то как это отражается на производительности?

Да обычное дело вообще-то - отдать хосту кучу LUN'ов по 20Гб и средствами LVM размазать (stripe) по ним VG. Best practice.

Да обычное дело вообще-то - отдать хосту кучу LUN'ов по 20Гб и средствами LVM размазать (stripe) по ним VG. Best practice.

а какой смысл в куче LUN'ов по 20Гб, если они физически (на сторедже) лежат на одном массиве?

Почему бы просто не увеличить существующий LUN на сторедже и не сделать pvresize?

Потому что тогда придется опускать базу данных, насколько я понимаю А по поводу второго - спасибо за ответ, буду знать

Не надо опускать БД, ресайз - это онлайн операция.
Если используется штатный dm-multipath, то ему надо сказать «resize map».

а какой смысл в куче LUN'ов по 20Гб, если они физически (на сторедже) лежат на одном массиве?

Обычно они лежат на разных рейд-гуппах. Плюс больше лунов - больше параллелизма, что тоже хорошо.
Некоторые массивы к этому даже принуждают. Например, на симметриксах размер девайса никогда не был большим. В VMAX он около 240Гб. Если хосту нужен лун большего размера и он не умеет LVM (ESXi к примеру), то приходится из этих девайсов лепить меты (concatentaed или stripe).

Если оракл с ASM-дисками, можно просто ещё один добавить.

Давно же уже можно лепить dynamic pools и при необходимости размазывать конкретный lun по всему пулу ака wide striping.

в таком случае да, согласен.

бежит на 2 LUNах, объединенных в одну virtual group на уровне ОС

AFAIK раньше рекомендовали показывать ОСи побольше лунов - для обхода ограниченности очереди запросов к диску.

Почему бы просто не добавить новый lun как датафайл в тейблспейс, или как асм диск в диск-группу? Зачем лвм?

У HDS - да, давно. А EMC только недавно (в VMAX3) избавились от ограничения на максимальный размер девайса в 240Гб. Хотя тонкие пулы и wide-striping у них тоже появились давно, но механизм отдачи лунов долго не менялся, т.е. те же девайсы по 20Гб, только тонкие и размазанные (wide-striping) по всему пулу.
С одной стороны и хорошо - нарезал хранилку один раз при установке, и больше ничего на ней не делаешь, только отдаешь =)

Я думал они уже давно обошли это, ну что тут поделаешь - емся.

нарезал хранилку один раз при установке, и больше ничего на ней не делаешь

Отдаешь всё-равно скриптами, тч без разницы, а вот геморроя добавляет на хосте, ну и иметь запас дисков, не входящих в RG, никогда не помешает :)

Товарищи! Спасибо всем за ответы. В результате после долгих разговоров с начальством, решилось все дело так: 1) Добавляем новый LUN большего размера к storage pool 2) Map to host 3) xiv_fc_admin -R 4) pvcreate /dev/dm 5) vgextend 6) pvmove old dm--> new dm 7) vgreduce 8) pvremove old dm Таким образом все крутится и работает, теперь осталось разобраться со снэпшотами на сторедже и все :-)

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

Нет, у нас нет ASM дисков :-) И я не сторонник того, чтобы оракл управлял моими дисками :-)

Ну, с GRID'ом вариантов, вроде, нет.