https://slinkov.ru/openforum/vsluhforumID1/90966.html Интересует кто какими методами пользуется для повышения отказоустойчивости сервера на базе Linux, больше даже интересуют бюджетные варианты, для начала перечислю что вспомнил из основных:<br><br>- установка УПС;<br>- рейд аппаратный или программный на крайняк;<br><br>далее предполагаю что должно помочь монтирование корневой файловой системы в readonly режиме (кто что может сказать по этому поводу?)<br><br>Все что я перечислил в большей степени относиться к проблемам с жестким диском,т.к. все же он страдает чаще всего, от некоректного выключения, неправильных действий пользователя, пинков и т.п.<br><br>Что вы можете сказать по этому поводу и что еще может помочь?<br>Хотелось бы минимизировать вероятность возникновения проблем как с аппаратной так и с программной частью.<br> https://slinkov.ru/openforum/vsluhforumID1/90966.html#5 Fri, 18 Feb 2011 07:49:02 GMT &gt;[оверквотинг удален]<br>&gt; - установка УПС; <br>&gt; - рейд аппаратный или программный на крайняк; <br>&gt; далее предполагаю что должно помочь монтирование корневой файловой системы в readonly режиме <br>&gt; (кто что может сказать по этому поводу?) <br>&gt; Все что я перечислил в большей степени относиться к проблемам с жестким <br>&gt; диском,т.к. все же он страдает чаще всего, от некоректного выключения, неправильных <br>&gt; действий пользователя, пинков и т.п.<br>&gt; Что вы можете сказать по этому поводу и что еще может помочь? <br>&gt; Хотелось бы минимизировать вероятность возникновения проблем как с аппаратной так и с <br>&gt; программной частью.<br><br>Ну стоит добавить следующие вещи:<br><br>По поводу отказоустойчивости конкретно одного сервера:<br>сервер с двумя блоками питания воткнутыми в две независимых линии +<br>bonding + <br><br>По поводу кластеризации, для начала:<br>DRBD +<br>OCFS2 (лишь пример) + <br>(carp + репликация СУБД, если требуется и т.п.) или держать всё внутри виртуалок на XEN и пользоваться живой миграцией<br><br>А по поводу readonly, это полезно https://slinkov.ru/openforum/vsluhforumID1/90966.html#4 Fri, 18 Feb 2011 05:39:15 GMT Я бы ещё добавил (в случае необходимости, разумеется!) сюда же построение кластера из 2-х серверов на связке heartbeat+drbd. Поднимал как-то для биллинга UTM. Довольно таки долго и безотказно работал. Но это, повторюсь, уже по желанию. Потому как есть и свои подводные камни в этом решении. :)<br><br> https://slinkov.ru/openforum/vsluhforumID1/90966.html#3 Fri, 18 Feb 2011 04:37:53 GMT &gt; P.S. А вообще всё зависит от назначения сервера и его приложений.<br>&gt; Может проще и дешевле поставить 2 десктопных машины(без рейд, без упс, без <br>&gt; дублирования БП и сети) и собрать кластер.<br><br>Ну если машина десктопная - то поставить "второй" винчестер в пару - не велика относительная разница в цене. Так что я за рейд, в т.ч. и софтовый.<br><br><br> https://slinkov.ru/openforum/vsluhforumID1/90966.html#2 Fri, 18 Feb 2011 03:38:52 GMT <br>&gt; далее предполагаю что должно помочь монтирование корневой файловой системы в readonly режиме <br>&gt; (кто что может сказать по этому поводу?) <br><br>нафига? от аппаратных проблем это не спасёт, а гемора прибавит...<br><br>По опыту, неисправности обычно такие (от наиболее частых - к менее частым)<br>1. Нестабильность питания.<br>Ставим УПС.<br>2. HDD<br>Делаем рейд, для линуха вполне достаточно программного.<br>3. Вентиляторы. <br>Использовать вентиляторы и корпус сервера, где их замена возможна "на горячую". Где "на горячую" невозможна замена - использовать пассивное охлаждение по возможности.<br>4. Блок питания.<br>Резервирование БД есть только в серверных корпусах.<br><br>Этого вполне достаточно по аппаратной части.<br>По желанию - агрегирование сетевых интерфейсов.<br><br>P.S. А вообще всё зависит от назначения сервера и его приложений.<br>Может проще и дешевле поставить 2 десктопных машины(без рейд, без упс, без дублирования БП и сети) и собрать кластер.<br> https://slinkov.ru/openforum/vsluhforumID1/90966.html#1 Thu, 17 Feb 2011 14:20:06 GMT Интересна, как вариант, возможность загрузки с карты памяти монтирующейся в режиме RO, а все логи и прочее писать на жесткий диск. В данном случае данным вообще вроде как получается навредить ничего не сможет, т.к. на карте механики нет, на чтение вроде тоже ограничений нет.<br><br>