ну если Вы админ локалхоста, то да, причин не вижу. А если это продакшн сервер, и не дай бог если их больше одного (или 10-20-30) в кластере, и еще более не дай бог, он не Ваш, а Вы просто его обслуживаете и когда-нибудь можете передать его на обслуживание другому человеку, то ставить из сорцов — это моветон )
Правильный вопрос был бы — почему просто не собрать рпм-ку из исходников самой свежей версии и поддерживать ее. Ну это да… только рпм-ки собирать нужно уметь, и как показывает опыт не все это умеют :)
в реми дибильные зависимости у php 5.3, а точнее у расширений php 5.3, которые тянут за собой кучу конфликтов. php 5.2.9 лежит в testing репозитории, при этом ставится нормально и без конфликтов.
Единственное вспомнил. По установке дрбд на центос. DRBD в центосе, как оказалось сейчас сломано. Т.е. у меня не получилось запустить его с последним ядром, которое идет в составе центоса. Модуль из src.rpm тоже собрать не получилось. Качал вот отсюда oss.linbit.com/drbd/ тарбол с 8.3.7. Там внутри есть .spec файл, из которого замечательным образом собираются в rpm-ки все пакеты и модули.
Насчет этого я даже и не знаю, что писать. Настройка Heartbeat стандартная, drbd тоже стандартное. По ним есть куча хаутушек в интернете. Так же можете поискать в сети выпуск журнала системный администратор за февраль 2007. Там в общих чертах описана настройка heartbeat и drbd как раз для люстры. Есть некоторые недочеты, но при чтении документации они нивелируются.
сейчас как раз занимаюсь люстрой.
Во-первых Вы не указали важный факт — у люстры НЕТ фейловера и репликации. Т.е. если Вы хотите у себя отказоустойчивость, то потребуется либо шаред сторадж + heartbeat, либо drbd + heartbeat. Это раз.
Два — Ваша статья претендует на хауту, но в ней нет важных моментов. Например в продакшене требуется отключить дебаг на серверах и клиенах: echo 0 > /proc/sys/lnet/debug. С дебагом работает значительно медленнее.
Так же не сказано, что по дефолту файлы страйпятся из принципа — один файл->одна нода. Это можно и нужно изменять. Но на массивах с большими (> 1M) файлами. Почитать об этом можно вот тут: blogs.sun.com/atulvid/entry/improving_performance_of_small_files
Три, это вопрос уже тем, кто использует люстру в продакшене. Как быть с мелкими файлами? У меня просто чудовищно низкая скорость записи/чтения мелких файлов.
ага — синус-лифтинг. стоит как имплантат. в этих случаях цена нового зуба состоит из 3ех вещей — стоимость имплантата ~ 20 штук, синус-лифтинг ~ 20 штук, сама коронка ~ 20 штук. И того — 50-60 тыр. Это мне все врачи рассказали после того, как вытащили у меня две верхних 6ки :(
Правильный вопрос был бы — почему просто не собрать рпм-ку из исходников самой свежей версии и поддерживать ее. Ну это да… только рпм-ки собирать нужно уметь, и как показывает опыт не все это умеют :)
ага, только не такие, как в фантастики с жирными цветными лучами от которых убежать можно :)
Во-первых Вы не указали важный факт — у люстры НЕТ фейловера и репликации. Т.е. если Вы хотите у себя отказоустойчивость, то потребуется либо шаред сторадж + heartbeat, либо drbd + heartbeat. Это раз.
Два — Ваша статья претендует на хауту, но в ней нет важных моментов. Например в продакшене требуется отключить дебаг на серверах и клиенах: echo 0 > /proc/sys/lnet/debug. С дебагом работает значительно медленнее.
Так же не сказано, что по дефолту файлы страйпятся из принципа — один файл->одна нода. Это можно и нужно изменять. Но на массивах с большими (> 1M) файлами. Почитать об этом можно вот тут: blogs.sun.com/atulvid/entry/improving_performance_of_small_files
Три, это вопрос уже тем, кто использует люстру в продакшене. Как быть с мелкими файлами? У меня просто чудовищно низкая скорость записи/чтения мелких файлов.