g613 sva52У меня на сервере 2 диска scsi.
Fedora 3 предлагает при установке их объединить в группу томов LVM.
Имеет ли смысл делать это, если потом на такую файловую систему буду ставить базу данных?
Как Линукс сам отслеживает оптимальность распределения информации по двум томам в группе LVM?
Нужно-ли его как-то дефрагментировать?

а что за БД ?
для БД вообще лучше пользовать raw-device если она это может....

Так, к слову - если уж тебе судьба пользовать Федору, поставь webmin - получишь нормальный интерфейс к оному lvm . Ручками это все конфигурить - можно конечно, но мне кажется, что все таки мазохизм (в SuSe интерфейс имеется, в RHEL4 тоже, а в остальных детях красной шапочки - нету).

А вообще я может и путаю - кажется, в новых Федорах LVM вообще по умолчанию используется.

В любом случае ответ - системные диски объединять через LVM смысла нет. Если очень хочется, есть смысл повесить туда RAID-1 (mirror).

Что значит нет кластерного LVM? Во первых, есть evms, в котором есть практически все. Во вторых, самому LVM кластерность до фени (у меня вот он в кластере работает и не мяукает), а важна эта кластерность софтверным райдам, то есть md (а не lvm-у).

В случае оракла есть весьма даже кластерная


.dba g613 sva52У меня на сервере 2 диска scsi.
Fedora 3 предлагает при установке их объединить в группу томов LVM.
Имеет ли смысл делать это, если потом на такую файловую систему буду ставить базу данных?
Как Линукс сам отслеживает оптимальность распределения информации по двум томам в группе LVM?
Нужно-ли его как-то дефрагментировать?

а что за БД ?
для БД вообще лучше пользовать raw-device если она это может....

одно не противоречит другому. Как раз наиболее распостраненная практика ставить LVM поверх raw devices. При этом решается сразу несколько проблем. Во-первых управление файлами (удаление, создание, уменьшение, увеличение), что на raw devices абсолютно неудобно. Во-вторых преодолевается ограничение на кол-во scsi partitions. Кроме того есть и другие преимущества.

Плохо только, что для Линукса нет OpenSource кластерного LVM, но это уже проблемы другого рода.

(сглючило). Кластерная ASM в случае Оракла.

Я испльзую LVM для
- разметки динамических дисков, так как без него их после хрен найдешь (FibreChannel, iSCSI)
- когда нужно получить увеличенный диск на наборе мелких дисков
- когда надо МНОГО МЕЛКИХ ПАРТИЦИЙ (OCRFile, CSSFile - знакомо?)

Но я пользуюсь SuSe, что сразу дает нормальную GUI, а на старинной допотопной RedHat-е - webmin-ом . ручками возиться с LVM не советую.

PS. В кластере на самом деле надо аккуратно, но в принципе у LVM нет проблем прогнать скан лишний раз и увидеть изменения. Главное - по возможности не менять тома, которые используются.

ocfs ничуть не тормознут, ЕСЛИ использовать его ТОЛЬКО под файлы постоянной длины (база, redo, но не archive logs).

lvm - это ПРОСТО еще одна система партиций на дисках, и как легко догадаться, ему до фени, есть кластер или нет.

evms есть везде кроме Красной Шапочки, так что тут ты видимо крупно пролетел.

(его ibm разработала).

Поставь ocfs и не мучайся, если тебе базу надо на чем то держать в кластере, и если у тебя ядро 2.4 (RHEL3 или SLES8).

.dba Alex Roudnevlvm - это ПРОСТО еще одна система партиций на дисках, и как легко догадаться, ему до фени, есть кластер или нет.
Так почему же пишется что он cluster unaware? А его кластерную версию (той же фирмы) RH продает за 4 с чем-то тысячи.
Alex RoudnevПоставь ocfs и не мучайся, если тебе базу надо на чем то держать в кластере, и если у тебя ядро 2.4 (RHEL3 или SLES8).
я год назад пробовал, счас не помню какой версии. Дык распаковка тар файла на ней длилась чуть ли не вечность, а на обычной ext3 занимало минут 10.

Да, у меня rhel 3, а диски - это FC-SCSI на ЕМС Clariion CX-300.

Ну, редхат это редхат - мало ли чего он продает. Кстати, он продает Cluster Suite совсем не за 4тысячи, а баксов за 200, кажется - туда понапихано немерянно какого то хламу, но зато сделана неплохая дока.

А LVM - пойнт в том, чтто ЗАЧЕМ ему быть cluster aware? Это же статический меппер. /etc/init.d/boot.lvm start (ну или можно ручками vgscan и прочее позвать) - считывает табличку с дисков, делает меппинг, и больше ничего не трогает. Он такой же cluster unaware, как и raw disk.

Кластер должен понимать RAID (md в нашем случае), так как RAID ведет динамические данные, а значит должен их согласоывать. MD это не умеет, это правда. Но только MD != LVM.

OCFS - все верно, tar работает в 10 раз медленнее. Ну так я же написал - ocfs ведет себя как raw device если файлы не меняют длину и атрибуты. А tar только и делает, что меняет. Следовательно, в OCFS хорошо держать базу, REDO, control files, но плохо например log files.


(Но я уже писал - я красной шапочке поставил кол 3 года назад, и с тех пор успешно ее избегаю. Более уродского дистрибутива линукса я еще не встречал в природе.)