Как построить правильный маштабируемый кластер.

у меня сервер - обычный Celeron с 512 метрами памяти, винт вроде 80 гигов (не помню)

суммарный трафик по всем сайтам на сервере тоже около 20-30К - все летает,

в среднем показания top: 0.3, 0.3, 0.3

размер страницы в среднем тоже около 100К

+ дополнительно на апаче поставлен mod_gzip, который чуть сильнее грузит проц

ВСЕ ЛЕТАЕТ!

но для этого пришлось конкретно переработать скрипты и базу,

так что не тратьте деньги на оборудование, перепишите ПО

Считаем что есть некая критическая точка, после которой надо маштабироватся. То есть, тяжело поверить, что если, например, Яндекс перепишет все свои скрипты например, на ассемблере, то сможет весь уместится на одном сервере.

Есть, картинки, есть скрипты, базы, балансировка нагрузки, резервные копии, генерация и рассылка сообщений пользователям, rss импорт/експорт и т.д.

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

SantaClaus, для начала надо понять, где тонкое место. "too many connection" вам кто говодит? MySQL или Web-сервер?

Если MySQL, то его лучше вынести на отдельный сервер, притом с 64-битной архитектурой. Если слишком большая нагрузка на базу, то можно сделать 2 сервера, с которых будут делаться SELECT'ы (на один из них будут делаться также команды на запись, а на втором можно просто настроить репликацию базы).

Если web-сервер, то смотрите, какие файлы больше всего жрут ресурсов, статика или скрипты. Если статика, то перевести её на nginx, а главное проверить, что нету личеров на картинки (не так давно на одном проекте пришлось забанить всех клиентов с "неправильным" HTTP_REFERER после чего нагрузка упала раз в 5 и трафик с китайских ip - до нуля :)). Если скрипты, отлаживать скрипты, оптимизировать работу с базой, настроить кеширование, но не допуская огромного количества файлов в одной директории.

Не такая большая посещаемость что бы валить такой сервер если проект "среднестатический"? Возможно есть смысл оптимизировать скрипты, "в среднем" такой сервер должен в 2 раза больше держать без проблем и иметь ещё запас хороший.

А кто говорит too many connection?

Как первый из вариантов - все статические картинки/файлы вынести на отдельный сервер.

вот тут мне закинули (обсуждать и осуждать не буду):

почему бредовый, если я говорю о реальном опыте?

суммарно страниц у меня на несколько миллионов (я даже не считал, может и больше), трафик только от ботов - несколько гигов в день.

этого всего удалось достичь очень жесткой оптимизацией скриптов и базы (я сам профессиональный программер).

так что ваш коммент - ф топку.

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

так что в большинстве случаев (процентов 80-90) проблема в архитектуре ПО и его реализации.

а вопрос скорее в том, что выгоднее - переписать ПО или купить еще железяк решается по ситуации, но стратегически выгодно все же писать нормальное ПО

Насколько я понимаю, основная нагрузка идет на mysql? тогда берем сервер, вешаем на него апач, берем еще 2 сервера, делаем на них mysql репликацией (через внутреннюю сеть). Вот Вам простой кластер. Дальше при необходимости увеличием ноды. Ну естественно все это надо настраивать соответствующе.

Для начала попробуйте все же оптимизировать скрипты как уже Вам советовали. Есть определенные алгоритмы, даже есть скрипты, которые помогут с правильной конфигурацией my.cnf, если проблема в этом действительно.

ТС на дежурный вопрос сыпят, как правило, дежурными ответами. Из той информации, что Вы предоставили, что либо придумать мало реально.

У Вас типичная ошибка в понимании сути задачи

Аппаратное массштабирование возможно лишь только тогда, когда программное обеспечение это умеет. Нельзя с ходу выдать решение под "ресурсоемкий сайт", т.к. универсальных решений в природе нет. Есть вот Oracle RAC, но у в Вашем случае mysql же. Вот у первого есть мега термин grid, который очень эффектно действует на заказчика, а у второго есть пародие на кластер и на HA решение.

ps. тут вот на днях memcached в кластере + пару акселей на один проект прикрутили, так он еще тридцать раз столько же потянет... а он как был на двух серверах, так и остался... php/mysql + apache.

обычно кеширование в памяти и акселерация делается одним модулем. скажем, xcache (выглядит очень интересно), apc (бывают странные глюки). ну и классика - eaccelerator, эффекта меньше, но все же лучше чем без него. Это все касательно php.

это говорит Mysql ,

увеличение max_connection не дает никакого результата ..

пробовалось разные sort_buffer_size (до 64М ), read_buffer_size, key_buffer_size (512М)

также не помогает .... разве что вылетает з нехваткой памяти Out of memory (Needed 20965728 bytes) ...

все конекты в статусе "Sorting" или "Copying to tmp table" ....

в чем проблема :

в памяти ??? свап не используется даже когда сервере уже не отвечает ...

в CPU ??? idle даже может быть до 30%, но не всегда

gstat - не показывает сильной нагрузки на какой либо хард, только иногда ...

PS

как узнать что не было ddos атак?

Вам все верно сказали на счет оптимизации скриптов и базы данных, проанализируйте log-slow-queries, пересмотрите дизайн таблиц, там где надо используйте tinyint вместо int char-ы вместо varchars про ENUM тоже не забывайте и конечно индексы.

Кластер построить не сложно и в ваш бюджет все укладывается, разве что в сторону mcluster не стоит смотреть.