Интересует кто какими методами пользуется для повышения отказоустойчивости сервера на базе Linux, больше даже интересуют бюджетные варианты, для начала перечислю что вспомнил из основных:- установка УПС;
- рейд аппаратный или программный на крайняк;далее предполагаю что должно помочь монтирование корневой файловой системы в readonly режиме (кто что может сказать по этому поводу?)
Все что я перечислил в большей степени относиться к проблемам с жестким диском,т.к. все же он страдает чаще всего, от некоректного выключения, неправильных действий пользователя, пинков и т.п.
Что вы можете сказать по этому поводу и что еще может помочь?
Хотелось бы минимизировать вероятность возникновения проблем как с аппаратной так и с программной частью.
Интересна, как вариант, возможность загрузки с карты памяти монтирующейся в режиме RO, а все логи и прочее писать на жесткий диск. В данном случае данным вообще вроде как получается навредить ничего не сможет, т.к. на карте механики нет, на чтение вроде тоже ограничений нет.
> далее предполагаю что должно помочь монтирование корневой файловой системы в readonly режиме
> (кто что может сказать по этому поводу?)нафига? от аппаратных проблем это не спасёт, а гемора прибавит...
По опыту, неисправности обычно такие (от наиболее частых - к менее частым)
1. Нестабильность питания.
Ставим УПС.
2. HDD
Делаем рейд, для линуха вполне достаточно программного.
3. Вентиляторы.
Использовать вентиляторы и корпус сервера, где их замена возможна "на горячую". Где "на горячую" невозможна замена - использовать пассивное охлаждение по возможности.
4. Блок питания.
Резервирование БД есть только в серверных корпусах.Этого вполне достаточно по аппаратной части.
По желанию - агрегирование сетевых интерфейсов.P.S. А вообще всё зависит от назначения сервера и его приложений.
Может проще и дешевле поставить 2 десктопных машины(без рейд, без упс, без дублирования БП и сети) и собрать кластер.
> P.S. А вообще всё зависит от назначения сервера и его приложений.
> Может проще и дешевле поставить 2 десктопных машины(без рейд, без упс, без
> дублирования БП и сети) и собрать кластер.Ну если машина десктопная - то поставить "второй" винчестер в пару - не велика относительная разница в цене. Так что я за рейд, в т.ч. и софтовый.
Я бы ещё добавил (в случае необходимости, разумеется!) сюда же построение кластера из 2-х серверов на связке heartbeat+drbd. Поднимал как-то для биллинга UTM. Довольно таки долго и безотказно работал. Но это, повторюсь, уже по желанию. Потому как есть и свои подводные камни в этом решении. :)
>[оверквотинг удален]
> - установка УПС;
> - рейд аппаратный или программный на крайняк;
> далее предполагаю что должно помочь монтирование корневой файловой системы в readonly режиме
> (кто что может сказать по этому поводу?)
> Все что я перечислил в большей степени относиться к проблемам с жестким
> диском,т.к. все же он страдает чаще всего, от некоректного выключения, неправильных
> действий пользователя, пинков и т.п.
> Что вы можете сказать по этому поводу и что еще может помочь?
> Хотелось бы минимизировать вероятность возникновения проблем как с аппаратной так и с
> программной частью.Ну стоит добавить следующие вещи:
По поводу отказоустойчивости конкретно одного сервера:
сервер с двумя блоками питания воткнутыми в две независимых линии +
bonding +По поводу кластеризации, для начала:
DRBD +
OCFS2 (лишь пример) +
(carp + репликация СУБД, если требуется и т.п.) или держать всё внутри виртуалок на XEN и пользоваться живой миграциейА по поводу readonly, это полезно лишь тем, что в случай "некорректной перезагрузки", вероятность загубить систему уменьшается на порядок. А на самом деле, с появлением журналируемых FS, лично я как-то привык не ломать себе так мозг на подобную тему :)