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

А я советую написать нам в саппорт, так понимаю, сервера стоят у нас, и уже из исходя из специфики ДЦ подыскать решение :)

Во-первых тема "Бюджетный кластер на Linux'e" и фраза "Возможно файловое хранилище будет на отдельном RAID контроллере, который будет подключен к всем узлам." уже не совпадают. То, про что Вы говорите, называется NAS или SAN - и то и другое достаточно дорогостоящие вещи.

Что касается кластера, то все легко делается на RHEL Cluster Suite, если бы не три глобальнейших проблемы:

1) что Вы будете делать с CARP в условиях датацентра, который не больно то даст свои раутеры настраивать?

2) что Вы будете делать с MySQL, который в принципе не кластеризуется ни одним сегодняшним даже тертьесторонним продуктом, кроме ScaleDB, который находится на стадии тестирования? (все эти MySQL Cluster, MySQL Proxy и прочие поделки не умеют ровным счетом ничего)

3) как Вы научите панель управления хостингом этим управлять? И какую? Все более или менее сильные панели закрыли код.

Все это, конечно можно сделать, были бы программисты. Но это будет титанический труд, который решит только одну проблему - хардверную и никакую другую. Когда же Вы затратите примерно 400-500 тысяч на зарплаты программистов, то с грустью обнаружите, что хардвер горит раз в два года и дает даунтайм на час. Ни один клиент не уйдет из-за такого редкого даунтайма, а значит Вы просто сольете деньги в трубу.

Забудьте про HAC в принципе. В мире хостинга уместны только HPC, сделать которые почти невозможно ввиду того, что часть программной составляющей пишется веб-студиями.

Хотите делать по уму? Тогда думайте как избавиться от программных даунтаймов в рамках одного сервера.

bugsmoran, ну, ndb-cluster то работает нормально и надежно.

Просто не так эффективно, как этого ожидают и Андрейка заливает :)

Это по сути довольно старая разработка Эриксон, на который Mysql AG прикрутили sql-интерфейс в виде sql-нод.

NDB API ведь до сих пор сохранилось. Значит это кому-нибудь нужно.

А потом? Настроил и забыл? А если упало - идем на форум искать очередного Петю "одмина", который это починит?

Попробуйте свободные панели. ispconfig-3 неплохая, с потенциалом.

А что за "программные сбои" такие? Например?

А как часто "ломаются"? Что за такие поломки у Вас, что ломается сервер чаще раза в год и на решение проблемы уходит существенно более часа?

Резервирование всего в 2-3 раза сделает услугу в 4-6 раз дороже.

Упор нужно делать на надежность ДЦ, на скорость реакции техников ДЦ и грамотность ваших администраторов и тех. поддержки.

Даже если сгорит БП, его должны поменять за 10-20 минут и т.д. Вам будет дешевле выплатить компенсации всем вашим клиентам за эти 15 минут в месяц (даже если они будут гореть каждый месяц) чем содержать и обслуживать в 3 раза больший парк оборудования, даже если Вы придумаете как это технически реализовать.

Для начала вам нужно решить, резервируете ли вы мощности в рамках одного надежного ДЦ, либо разделяете узлы кластера географически.

У меня нет опыта с этим storage engine'ом (а он как я понимаю ничего больше, чем storage engine), но ведь ndb - это вообще не кластер.

У него куча недостатков: например, на нем зависают сессии, которые чистятся только руками. Нельзя создавать таблицы с более, чем 128 полями. Игнорируются внешние ключи. Куча проблем с индексами типа того, что нельзя создавать их на TEXT.

И вообще, если это storage engine, то мы можем говорить только о таблицах, а как быть с теми же пользователями?

А самое главное: шаредный хостинг требует дикой производительности и на фоне этого слова "For smaller MySQL database clusters, using MyISAM storage gives better performance over NDB clustered storage." выглядят ужасающе. База - одна из самых злостных мучителей дисков.

bugsmoran, работает? от единичного сбоя на любом из компьютеров защищен ? - значит кластер.

но не пригодный для массового хостинга.

Да нет же :) Я совсем не думаю, что один аккаунт начнет потреблять столько ресурсов, что единичного сервера не хватит. На первом плане скорее как раз повышенная надёжность. Но повышенную надёжность можно реализовать по разному. Тоесть не хочется, чтобы "ведущий" сервер на конкретный момент времени принимал на себя все запросы, а вторичный сервер тупо ждал и ничего не делал вообще.

hacccker, а зря. потому что конкретно эта задача, когда дублирующий сервер просто ждет, попроще будет.

что-о мне кажется, Вы плохо представляете о чем пишите в этом топике

к Вам есть несколько вопросов.

как Вы думаете почему еще никто не предоставляет такого "Облачного хостинга", за вменяемые деньги? рынок хостинга не молод и там есть свои монстры, но у них таких услуг нет