Ну-ну... до балуетесь. Не пытайтесь продавать диск, пока сервер ещё у вас стабильно работает...
Можно не давать поисковикам делать столько соединений через ограничения в robots.txt
Моё имхо, что вы только нагромоздите...
ISPManager Cluster - это конкретный продукт с конкретной структурой под определённый круг задач.
У вас же свой проект (не массовый хостинг), под который можно настроить работу серверов/сайта максимально гибко и именно под ваши задачи.
Лично я думаю, что можно объединить усилия программистов и администраторов, чтобы всё работало максимально стабильно и удобно. Я склонен считать, что под разные задачи и условия необходимы свои решения.
Никто тут и ничего не изобретает. Я рассказываю ТС про его вариант master -> slave со сменой ролей в случае проблем.
Himiko добавил 11.04.2011 в 17:52
Ничего не мешает дублировать и storage.
P.S.: Для MySQL лучше один мощный сервер, который легко справится с нагрузкой + дублирующий на случай отказа основного. (моё ИМХО).
Вот эта автоматика тоже должна быть продумана. Да и вылеты бывают разные. Мастер может быть просто перегружен запросами, которые в итоге сможет выполнить, а запись пойдёт уже на Slave. Много чего продумывется.
Himiko добавил 11.04.2011 в 16:43
Если вы будете балансировать MySQL-запросы по 2-м серверам (без запаса производительности), то при выходе из строя одного сервера, второй ещё может не выдержать возросшей нагрузки.
P.S.: Даже у гугла бывают проблемы и всё на 100% предусмотреть не реально, имхо.
1. Если у вас много операций чтения (SELECT и т.п.), то может быть заметное увеличение производительности. И писать в такой связке (INSERT,UPDATE и т.п.) можно только на MASTER.
И их ещё нужно будет разделить через скрипты, либо доп. средства, чтобы случайно запись не пошла на slave.
2. Панель мало что может контроллировать. Добавление серверов и переконфигурирование тоже потребует ручного вмешательства.
Без администратора(ов) в случае с кластером вам вряд ли получится обойтись.
И вы учтите, что вы покупаете конкретную реализацию кластера и конкретный продукт, который работает в том виде, как это заложили разработчики. Если что-то потребуется поменять, то это будет не в ваших силах...
Himiko добавил 11.04.2011 в 16:29
У кого есть лишние 500к$, тем возможно...
Но всё решаемо просто и дёшево при желании.
И чем тут успокоиться? =)
+1.
Программные решения могут себя годами показывать с лучшей стороны. Главное - предусмотреть их отказоустойчивость. (а с аппаратными это сложнее)
Можно фильтровать на уровне nginx (по фильтру выдавать ошибку 444 к примеру) и уже парсить логи по 444 и заносить в фаервол.
Пишите в саппорт, всё решаемо:)
