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

AGAVA подойдет? В договоре в основном "мы ничего не гарантируем", "мы не обязаны", "мы не несет ответственность за" итд... И это правильные договоры, с позиции компании :)

А ну извините, у меня не стойка, и не SLA и вообще я из деревни :)

Я вам выше привел пример, и рассказал какой был даунтайм, т.е. это не оценка возможного, а констатация факта. А вы мне опять про теорию устранения любой проблемы за 1 час.

Та почему.. какой вы видели самый дешевый хостинг? 2$? 1? Ну вот представьте, было 2$, стало 4$. Размыть можно тем, что дать больше места или ещё чего-то... Ничего ж страшного что цена стала не 2, а 4$ Вот вам пример линейного роста цены. Аналогично можно на прибыль пересмотреть, кто-то хочет 100% накрутки, а кому-то и 50% достаточно...

И ещё, пишите пожалуйста без ваших "Я", а то "клястер", "генияльную" мне режет глаз. Или у вас не русский акцент?

hacccker добавил 06.12.2010 в 01:33

Согласен, поэтому покачаемся тут ещё... )

Подойдет. В оферте (+ приложение 1) указаны например и такие пункты как:

и

А в самом минимальном тарифном плане (Lite) указан бекап с конкретным расписанием.

Так что ищите дальше. И прежде чем приводить следующий "пример" (как и Andreyka) - внимательно ознакомьтесь с офертой сами, чтобы снова не сесть в лужу.

Выше это где?

Если не сложно - укажите, пожалуйста, конкретный пост. Я бегло просмотрел тред - больше невразумительного лепета про проблемы с панелью ISP от Вас не заметил, извините если был невнимателен.

Пример реального описания проблемы & решения это типа: "Cгорел БП арендуемого сервера. Поддержка меняла его XXX часов. Чтобы подобные казусы не вызывали такой простой - сделал YYY." Hint: сравнительно сложную операцию, да еще и сопряженную с заменой оборудования - Вам сделают не быстро. А вот ребут по питанию или поменять местами диски в хотсвапе - за несколько минут в любом нормальном ДЦ.

Понимаете. Технические слова нечто вполне конкретное значат. Вы говорите: "стоимость может возрасти линейно, в зависимости от количества серверов в кластере". Ну так вот - значит это глупость. Это значит что если у Вас было 2 сервера и тариф был 2$, то для 10 серверов будет 20$. Вот что значит линейный рост. Школу прогуляли?

Проблема с апачем, насколько я помню вывод gdb, была в том, что suexec конкретно тупил при старте, перечитывая всех юзеров + открывая для каждого свой suexec log. Вероятно потом это пофиксили.

Зачем держут - я не знаю, подозреваю для защиты от рейдерских атак.

Andreyka добавил 06.12.2010 в 07:15

Я предлагаю обдумать на счет mysql. Если файловая система имеет линейный рост в себестоимости, то mysql cluster (ndb) увеличит ее в геометрической прогрессии, так как зело выедает память:

A disadvantage is that the entirely memory based clustering engine The memory requirements for each individual node participating in a MySQL Cluster would be the equation of twice the size of stored data in the database +10% divided by the number of nodes (single node ram requirements = (SizeOfDatabase * NumberOfReplicas * 1.1) / NumberOfDataNodes). Можно данные на диске, но индексы все равно только в оперативке.

Если же делать через полную синхронизацию mysqlproxy+lua, то будут сильные тормоза, так как каждая модификация должна пройти и на соседе.

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

Так что я бы предложил сделать на 4-х серверах:

2 под файлы - работают оба

2 под mysql+drbd - файловер (только 1 работает), но нет проблем с вышеописанным гемором

И да - под это можно организовать в принципе любую панель (cpanel,directadmin,ispmanager).

myhand, что вы мне пытайтесь доказать? Что кластер мне не нужен, т.к. быстрее сменить оборудование? Мне уже честно говоря надоело из пустого в порожнее...

Andreyka, на счет MySQL у меня такая идея...

Репликация + Балансировка. Объясню...

Два сервера работают с разными наборами БД, ну такая себе балансировка (30 БД на одном сервере и 30 на другом, все работают постоянно) и каждый из серверов синхронизируется с другим, ну всмысле реплицируется только другая группа. Если один сервер упал, то другой берёт вторую группу БД на себя (из своей копии которая отстаёт во времени от оригинальной)

Не знаю доступно ли объяснил :)

Такой вариант возможен? Я думаю при гигабитной сетке между серверами отставание будет не сильно большое. Имхо в случае краха сервера, лучше вернуться на 5-10 минут назад, чем лежать мёртво...

Не без интереса почитал тему.

Позволю себе чуть отойти от технической стороны, но не от вопроса. ИМХО для шаред хостинга кластер это как жигули обслуживать в сервисном центре BMW. Если проект крупный - он как минимум на VDS сидит, а скорее всего на своем сервере. Посещаемость, а соответственно скорость изменения информации у обычного сайта на шареде невелики. У кого много - тех перетаскивают на более дорогие тарифы и проч. А для небольшого сайта актуальность даже сутки - не так уж и безнадежно потерянные данные. Да, клиенты поворчат - особенно владельцы форумов, но большая часть вообще может не заметить проблемы с откатом данных на несколько часов или даже сутки. Здесь (опять же ИМХО) проще и выгоднее держать резерв по оборудованию (или по его загрузке) и регулярные резервные копии. Из которых просто восстанавливать данные, если что то совсем уж упало и сдохло. При текущих ценах на шаред выйти с ценой выше в 2 раза, мотивируя это тем, что у нас кластер...Мне как клиенту, который далек от ТИ тематики вообще пофигу, это не мои проблемы. Зато я ценю, когда мне без проблем отдают бекап за месяц назад, за вчера и предыдущую неделю. И при таком раскладе я прощу если сайт раз в год будет недоступен сутки по техническим проблемам. Но когда недоступен мой бэкап - я в ярости. Мониторинг железа, чтение логов, замена оборудования не дожидаясь его отказа - это спасет от многих проблем. Ну или виртуализация, без сложных кластерных схем. Ведь это продукт не эксклюзивный, он относительно недорогой, и решения в нем должны быть такими же.

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

Доступно. Сделать вполне реально.

Andreyka добавил 06.12.2010 в 10:47

Хорошие хостинги дают отдельно управление своими бекапами - там видно все файлы с историей, и есть возможность восстановить самому что надо и куда надо

Разумеется, это стоит хороших денег, но оно того стоит

Ждем бета тестирования мега шаред кластера.

Сделать можно все, но нужно ли это и как это потом обслуживать, это уже другой и более серьезный вопрос. Если вы точно уверены, что вам нужно, подумайте хорошо над 2-й частью вопроса.

Того кто это будет вам настраивать, нужно нанимать на полный рабочий день и требовать вести полную техническую документацию. Стоимость в итоге получится примерно такая как я написал выше. Меньше чем за $3-4K/месяц вряд ли кто-то подпишется на такое даже в вашей деревне.

V(o)ViK, у опытных инженеров уже рука набита, так что есть и рыбы документации и настройки, а это удешевляет создание.

И да - следить за кластером не нужно, в этом его плюс.

Вы хоть раз такой кластер видели? Только не под конкретный проект, а для шареда.

Я - нет. Обычно "головняков" только прибавляется.