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

А что такое "mcluster"?

что такое mcluster

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

Ну то что я пишу основано на практике. И написанное касается именно работы сис.а админа касательно кеширования и оптимизации на этом уровне.

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

К тому же тут вроде не шла речь про мега быстрые способы разгребания ;)

Ну практика у всех разная, вот в этой схеме вижу большое количество минусов. Способ совершенно не универсальный и массштабировать с помощью него бесконечно нельзя. Прилепленная ферма из memcached утилизирует ресурсы более эффективно. Если нужно еще и выходные запросы кэшировать, то лучше поставить еще и ферму из squid + wccp v2 настроить на маршрутизаторе.

Тут речь шла о массштабируемости, точнее о правильной массштабируемости. Массштабировать тем, что даёт увеличение производительности только в рамках одного элемента ессественно не правильно.

Исходя из этого вот собственно и использую memcached для эффективного кэширования между всеми элементами кластера. Следовательно SQUID использую на фронте, возможно перейду на nginx, когда он научится кэшировать. Каждый фронт на сквиде имеет доступ к кэшам соседей, что сами понимаете даёт хороший эффект, вот в случаях с дорогим запросом на задник это реально спасает. В случаях с WCCP v2 массштабировать можно фактически бесконечно... групками по 32 элемента. Но поверьте мне, что 5 хороших серверов держали на фронте до 45тыс активных коннектов... а еще сколько неактивных там было, можно даже не считать. Само собой это всё под фряшкой, с патчами на тему accf_http и т.д.

Чем массштабировать mysql? да ничем его не массштабируешь... его можно массштабировать только репликацией master-slave, что при грамотном подходе и специфике конкретного приложения может дать очень большой эффект. Почему я когда-то остановился на memcached? всё очень просто - его сейчас лепят к чему только можно. Имея на руках кластер из memcached можно задействовать его и под mysql... еще правда не смотрел на тему доделали они или нет, но вот вот доделают.

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

Основная иллюзия - переедем на оракл и всё будет ок, там есть оракл рак, грид и всё такое - фигня всё это. Если целостность, ограничения, исключения и прочие вещи требующие уникальности дергаются постоянно, то мы рано или поздно опять упремся в этот атомарный потолок.

Вернусь к счетчикам и биллингам. Обычно программисты делают каунтеры и в реальном времени их увеличивают. Данный метод работает до определенного уровня одновременных конектов. Опять же, важно знать не столько конектов одновременно, а их динамику во времени. Если у нас 100 конектов в секунду такой алгоритм отрабатывает, то при увеличении их количества, механизм, проверяющий целостность, внесет задержку. Если задержка эта будет существенной, то какая-то часть запросов не сможет отработать за эту секунду, а следовательно при такой интенсивности это все через какой-то момент навернется, т.к. запросы будут скапливаться.

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

Вот я на реальном примере описываю, как делать правильно.

INSERT на самом деле не принципиален, т.к. есть еще работа с таблицами на очень низком уровне. Конечно это в этот момент с ними ничего делать нельзя, но тем не менее это в разы быстрее даже при отключенных индексах. Если мы хотим реальное время, то должны от этого отказаться. Вот тут самое интересное, т.к. видеть статистику в реальном времени нужно только человеку, фактически по запросу. В момент происхождения запроса select-ом собираются необходимые записи во временную таблицу или еще куда-то, а там уже делаются все необходимые count. Простой INSERT и простой SELECT массштабируются до бесконечности. Ну само собой если в таблице никаких проверок нет, типа ключей уникальных или еще чего. И если кто не знает, то напомню - COUNT тоже блокировку возникает, но главное что бы она была в тот момент когда в базу записи не сыпятся... если мы про myisam и т.д.

Исходя из этого можно массштабировать простые задачи без всяких ораклов и прочего, только на одном mysql. Дешево и до бесконечности.

ps. а вообще всё упирается в ДНК архитектора системы и в ДНК программистов.

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

Эффективное кэширование.

Кстати, скоро NetVillage.ru уже заработает и там всё можно будет почитать. Пока сумбурно сюда что-то закину. Тем про кластеры очень близкая и с ней уже связан много лет. Многие админы полагают, что решение проблемы сводится к установке акселератора и кэширующего механизма на фронте. Я не зря упомянул про мемкашэд, т.к. в большинстве случаев он эффективен. Поясняю - особенность HTTP протокола в данном случае заключается в том, что если в запросе будет кука, то кэширование возможно в рамках конкретного клиента. Следовательно кэширующий HTTP прокси не будет давать должного эффекта, если только на нем не настроено срезание кук. Кэш кэш кэш - кричат многие начинающие админы. Фигня всё это. Если взять в руки калькулятор, а еще лучше живые тесты, то распределенное кэширование даст более больший эффект на низком уровне, чем если мы будем кэшировать итоговый результат - факт.

При наличии хорошей и массштабируемой раздавалки типа nginx статику вообще кэшировать не надо. С другой стороны, за неимением общего дискового пространства ИЛИ реплицируемого дискового пространства мы не можем пренебрегать массштабируемым элементов на фронте. Если нужно быстро и дешево решить задачу по массштабированию раздачи статики до 100-200k активных сессий, то без акселераторов мы быстро это не сделаем. Если акселераторы будут иметь распределенный сторадж на своем уровне, то это будет работать в разы эффективнее.

Ну само собой надо релоады резать и всё сопутствующее, т.к. в момент атак каких-то, в запрос добавляют всё то, что приведет к пробою запроса на задник. Если 100k пролетит до задника, то всё умрет.

Если рассматривать аспекты надежности, то такая система менее стабильна, нежели чем система с распределенным хранением статики на раздачу. Почему? При подыхании задника дохнет вся система. Если нам нужно увеличить надежность, то на фронте должна быть высокопроизводительная массштабируемая балансировка по куче задников, на которых стоят хорошие раздавалки, ну и хранение распределенное.

Если мы хотим 100k активных сессий раскидывать одним фронтом, к примеру по имени директории в URL, то нам надо забыть про сокеты вообще. Делаться все должно на уровне ядра, возможно в user space, возможно какими-то патчами на файрвол, что бы по первой строчке в пакете наш syn proxy делал NAT на нужный задник и/или группу задников.

ps. удачи и до встречи в моем блоге на NetVillage.ru

kostich, спасибо, многа букаф:)

Где взять доки по построению масштабируемых решений?

А то в ваших сообщениях я встретил кучу незнакомых терминов и вообще ничего не понял😕

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

База и скрипты с файликами на разных серверах - это самое часто встречающееся решение проблемы с большой нагрузкой.

С проблемой разобрались - некая форма DDoS-атаки

О моем сервере.

Я признал, что он мне сильно нравится. Мощи немеряно, запас по производительности - еще раз так 5. После героических оптимизаций скриптов и всего что только можно, уже почти обрабатываем через себя все запросы DDoS-щиков. :-)

А сам сайт, если кому интерестно, вот он: www.AUCTION.ua

Сороковый по посещаемости в Украине. Если б раньше вычилили проблему с DDoS, возможно был бы уже в трицатке. :-)

Вопрос свелся к следующему.

Как вычислить исполнителей и заказчиков DDoS?

Готовы хорошо заплатить.

Но это наверное в другой ветке.