понедельник, 5 ноября 2007 г.

Чудеса поиска в Яндексе.

В предыдущем посте я писал про то, что искал Яндексом ответы на его собсвенные вопросы =). И вот какое чудо – только то обновляю страницу с выдачей про LVM и “опаньки (c) (tm)” – в выдаче появляется линк на этот чудесный текст о том, почему же Linux лучше чем FreeBSD для серверного (и не только) использования.


Вот небольшая выдержки именно по теме LVM:






2. В *BSD нет нормально LVM. http://www.vinumvm.org -- можете радостно закричать Вы, и будете совершенно неправы, потому что я сказал "HОРМАЛЬHОГО" (не говоря уж про то, что vinum работает только во FreeBSD). Hормальный LVM должен уметь не просто объединять несколько физических томов в один логический, он еще должен поддерживать массу других полезных операций, как, например, изменение размеров логического тома в on-line, или поддержание volume snapshot. Кроме того, для того, чтобы LVM был эффективен, в системе должен быть еще и файловая система, которую можно было бы хотя бы расширять на лету. Вы, конечно, можете сказать, что это все суета сует, и для настоящего интернет-сервера, которым рулит настоящий чебурашка, это все не нужно. Hо, уж поверьте моему опыту -- нужно, очень нужно. Пример номер раз: на разделе например /var заканчивается место. Hапример, из-за того, что клиенты прочухали радость электронной почты и теперь шлют сверстанную для полиграфии книжку (с картинками -- метров так на шестьсот) по электронной почте. Реальный случай, кстати. Предположим, что админ хоть и настоящий чебурашка, но такого не мог представить даже в страшном сне, и теперь место на разделе заканчивается, хотя вообще на винте места хоть дупой ешь. Что сделает пингвиноид на своем задрипанном пингвиниксе? Правильно -- если у него нет комплекса на слово "популярность", то /var у него живет где-нибудь на /dev/vg00/lv04, причем стоит на нем reiserfs. Так что он спокойно говорит lvextend -L+1G /dev/vg00/lv04 (свободное место на винте он, скорее всего, оставил, потому что при наличии нормального LVM нет смысла разбивать диск так, чтобы он был сразу занят весь), после чего говорит resize_reiserfs /dev/vg00/lv04, говорит df -k, убеждается, что с местом теперь все в порядке, и идет заниматься своими делами дальше. Причем, прошу отметить, делает он все это на лету, ничего не размонтируя, не выключая и т.п. Очень, знаете ли, удобно. Тем более, что в линуксе есть аж три файловые системы, которые можно расширять на лету -- ReiserFS, XFS и JFS. И даже одна, которую можно сжимать -- ReiserFS. Мне как-то приходилось перераспределять на лету место между разделами -- когда я на домашней тачке компилировал OpenOffice, с деревом компиляции в 3G. Компиляцию я, само собой, не прерывал. Было бы любопытно услышать, как бы Вы выкрутились из такой ситуации не приостанавливая обслуживания. Впрочем, есть и пример номер два, из которого Вы выкрутиться в любом случае не сможете -- за отсутствием необходимой фичи. Представьте себе базу данных гигов в 20 (маленькая, на самом деле, базейка). Hапример, на оракле. Представьте, что в сутки изменений в эту базу капает аж на полгига архивных журналов. Что, в свою очередь, приводит к неприятному следствию -- делать полный бэкап этой базы очень затруднительно, поскольку, заморозив файлы данных (командой alter tablespace blabla begin backup), Вы просто не успеваете перелить их куда-нибудь до того, как база данных начнет орать, что ей некуда класть данные. Ужасно, правда? Hа самом деле, решается элементарно -- если файлы данных лежат на логическом томе. Пингвиноид может просто создать т.н. snapshot volume, зарезервировать например полгига места под изменения (уж за сутки-то данные сольются), после чего сказать begin backup, засинхронизировать снэпшот тома и тут же сказать end backup. Все, задачка решена -- на снэпшоте теперь лежит эта файловая система в момент синхронизации (по сути, это COW-копия базового тома -- если в базовом какие-то блоки меняются, копии старых переносятся на снэпшот). Как только файлы данных будут скопированы, снэпшот можно удалить. Кстати, в линуксе есть целых два LVM, которые умеют это делать: штатный от систины и EVMS от IBM. Последний сделан плагинами, и понимает разделы не только штатного LVM, но еще и AIX и OS/2 LVM. И он, кстати, будет в 2.5.


Так что правда нет реализации LVM для *BSD систем? =(

Комментариев нет: