Бюджетный кластер на Linux'e

При плановой смене HDD простоя в принципе быть не должно. Вынуть диск из хотсвапа и вставить новый - дело минут (это как раз пример операции, которую в нормальном ДЦ Вам сделаю быстро, как и ребут).

Если новый диск не могут предоставить Вам сотрудники ДЦ быстро - озаботьтесь предварительно, заранее, чтобы он был у Вас. Просто добавив в некоторую часть рейдов диски как Hot Spare. Просто, ведь правда?

Совсем небольшая избыточность - и рейды не будут долго работать без дисков. Даже если поломался диск на сервере без hot spare.

И если сломается "что-то серьезнее" - Вам максимум понадобится новый сервер. Думаю, Вам несложно будет немного подумать и решить данную проблему совершенно аналогично предыдущему примеру.

Берем его диски - втыкаем в резервный сервер. И все продолжает работать. (Кстати, резервный сервер можно занять полезной работой, пока он не понадобится.) А со сгоревшим разбираемся в обычном порядке - просим ДЦ заменить оборудование.

Это Вам кажется, что он "простой" и "не дорогой". А другим - так не кажется. Почитайте тред.

Ну потому, что все реальные "проблемы", которые у Вас возникли - можно и нужно решать более простыми и дешевыми способами.

Тем что хостинг это не кони...

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

А если по существу, то он пытается доказать, что строительство кластера ради кластера (через все 10 страниц это идет красной нитью) - не есть грамотный шаг. Кластер ни в какой его конфигурации надежности (в случае шареда) не принесет. Производительность еще может быть, но надежность никогда.

Кроме того, Вы все время забываете ради чего хотите кластер. То Вы говорите про надежность, то про производительность (даже измеряете избыточность на 6-й странице). Для первого нужны кластеры высокой доступности, для второго кластеры высокой производительности. Строятся они по разному и по сути взаимоисключающие.

Но так как у Вас кластер - самоцель, то Вам похоже все равно, что строить.

Именно поэтому и я Вам задавал наводящие вопросы. Но Вы в ответах останавливались как раз перед этой развилкой.

Кластер не исключает бэкапы и не заменяет их.

Если аккаунт клиента взломают и удалят все его данные, эта операция успешно синхронизируется на все узлы кластера. Ваши действия после этого ?

Клиент случайно удалил нужную базу/таблицу. Привести еще примеры ?

Предположим, некий админ, настраивает вам кластер. Все успешно работает ну скажем год. Вы про него забыли, как и он про вас. Тут случается какая-то проблема, которая была не предусмотрена заранее и описания ее решения у вас в документации нет. Админ который настраивал с семьей и детьми уехал в отпуск на 2 недели. Ваши дальнейшие действия ?

Раз уж вы пытаетесь оценивать отказоустойчивость, риски и т.д. попробуйте оценить их в такой ситуации.

Материки горят раз 10 лет (причем с серверным оборудованием я такого вообще не встречал, повезло ?), а человек в отпуск ездит каждый год.

Я не пытаюсь доказать вам, что кластер это плохо, я говорю, что дешево и сердито применительно к шаред хостингу не получится.

Ну это не совсем верно - высокая доступность и производительность совсем не взаимоисключающие понятия, скорее наоборот - высокая доступность в качестве бонуса содержит высокую производительность из-за использования резервируемых мощностей. Пример - VmWare HA, простаивающие зарезервированные мощности процессора заняты. Это, конечно, в контексте web систем, не числодробилок.

Кластер позволит сделать тоже самое, но только в автоматическом режиме. Чего собственно и хочет ТС.

Andreyka добавил 07.12.2010 в 11:31

Вот именно по этому и надо делать ТЗ, в которых будет список предусматриваемых проблем, которые должны быть решены автоматически.

Это объеденены два типа кластера. То есть более мелкие собраны как HAC, а далее эти кластеры объеденены в HPC. То есть в HPC атомарная единица уже не отдельный сервер, а кластер.

Может это так и не выглядит с первого взгляда, но оно так и есть.

Телепатически что-ли позволит отправить заявку на замену оборудования?

ТС хочет странного. Короче всего это можно выразить пока словосочетанием "хочу зашибись!" Вот другим тут, кроме Вас, эта хотелка понятной не кажется.

А "неавтоматические" проблемы Вашего клястера Пушкин лечить будет? Вы готовы предоставить своему решению поддержку 24x7? Сколько это стоит?

1. Зачем телепатически? Живая нода отправит email об упавшей владельцу. А владелец уже предпримет меры.

2. ТС хочет простого, и я знаю то, что ему действительно надо.

3. Можно автоматизировать решение всех проблем, вопрос только в цене. Поэтому я и писал - нужно подготовить ТЗ и бюджет.

понятно, тут скоре всего если серверов будет 10-20-30 штук, то может будет выгода, а если 2-3-4, то разница минимальная...

Смысл в том, что можно делать плавный рост, по нарастающей