Дано:

1. Есть кластер. В кластере живёт несколько узлов. В узле живёт несколько веб-серверов. В веб-сервере живёт несколько аккаунтов. В аккаунте живёт несколько сайтов.
2. Для каждого сайта известна текущая нагрузка. Соответственно, известна нагрузка для каждого из аккаунтов.
3. Известно количество сайтов в каждом из аккаунтов.
4. Для каждого аккаунта сказано, на скольких минимум узлах (не веб-серверах) он должен присутствовать. Пусть это будет μ.
5. Для каждого аккаунта известно, какие веб-серверы обрабатывают его в данный момент.

Задача состоит в том, чтобы перераспределить аккаунты по веб-серверам так, чтобы

1. Аккаунты с максимальной нагрузкой присутствовали на максимальном числе узлов. Ну и соразмерно все остальные.
2. Каждый аккаунт представлен минимум на μ узлах.
3. В пределах одного узла каждый аккаунт представлен лишь один раз.
4. Текущая нагрузка наиболее равномерно распределена между всеми узлами (или с каким-то коэффициентом — не суть).
5. Сайты максимально равномерно распределены между всеми веб-серверами, чтобы минимизировать объём памяти каждого из процессов веб-серверов.
6. Сделать это всё так, чтобы изменения коснулись по возможности минимального количества веб-серверов, чтобы затем минимум их пришлось заставить перечитывать конфиг.
7. Делать это каким-то хитрым алгоритмом т.к. простой перебор на потенциальные десятки тысяч сайтов может отожрать немало проца и памяти…

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

1. Показать всякую текущую статистику (устаревшее show_workers, show_nodes и т.д.)
2. Управлять списками наблюдения.

Второй пункт интереснее. Немного предыстории. Часто бывает, что у клиентов на shared-хостинге случился перерасход ресурсов и они хотят знать, откуда эта нагрузка растёт. Резонное желание. Но беда в том, что ни я, “заведующий всем” © на хостинге, ни тем более техподдержка не может точно ответить на такой вопрос. Просто неоткуда брать данные. Чтобы разрешить эту проблему и были созданы списки наблюдения. Допустим, по MySQL-пользователю evlampiy случилось превышение нагрузки на MySQL. Пишем:

start save time, sent, query from mysql where user = “evlampiy” into file “/home/evlampiy/mysql_load.txt”

Всё, с этого момента прокся начнёт сохранять в указанный файлик все запросы к MySQL, пришедшие от пользователя evlampiy. Будет записано время выполнения запроса, количество посланных клиенту байт и сам запрос. Как только выяснили происхождение нагрузок, пишем:

stop save time, sent, query from mysql where user = “evlampiy” into file “/home/evlampiy/mysql_load.txt”

Запись прекратилась. Можно и понавороченней:

start save current_time, time/60, sent/1024/1024, host, uri from http where host = “john.5070.info” and ((uri = “/” and time < 0.5) or (uri = “/news/” and time > 0.01)) into file “/tmp/crazy_requests.txt”; stop save host from http into file “/tmp/all_http.txt”

Разумеется, можно посмотреть текущий список наблюдения:

show queries

На моей машине оверхед на один запрос со списком наблюдения длиной 5 получился 70 микросекунд, что примерно соответствует 2.3% на одно наблюдение при отдаче напрямую и 1.7% при проксировании.

Самой большой моей ошибкой в проектировании была идея использовать POSIX треды. Всё замечательно, но только до тех пор, пока активных соединений не становится больше сотни. Дело в том, что такие треды, по сути, являются почти что отдельными процессами: у них свой стек, их обрабатывает шедулер ядра и т.д. Единственное отличие — у них в пределах одного процесса единое адресное пространство. Так вот, всё это вызывало такие проблемы, как переполнение стека, нелинейность масштабирования и пр. В качестве альтернатиы рассматривалось два варианта:

1. Библиотека Equeue. Знаменита тем, что предоставляет низкий уровень к управлению очередями обработки дескрипторов. Это и минус — работать с ней не слишком комфортно: “есть только очередь и события, всё остальное на ваше усмотрение”.
2. Библиотека Lwt. По сути, то же самое, но выполнено совсем, совсем с другого бока. В интерфейсе предоставляется модель монад и псевдопотоков (отсюда название: LightWeight Threads). Быдлокодеру, навроде меня, достаточно лишь описать зависимости между состояниями: что делать, когда я получу данные из вон того сокета, и куда их записать потом.

Выбор пал на Lwt. А вот тут следует сказать несколько восторженных слов о типизации Хиндли — Милнера, используемой, в том числе, в Ocaml. Как я уже сказал, потоки POSIX при разработке выглядят практически как отдельные процессы. Создал поток, и забыл о нём, а он варится сам по себе. В Lwt же надо отдельно позаботиться о последствиях каждой операции IO. Прежде всего, я заменил все вызовы Unix.socket (создание сокета) — благо в коде почти все они были в моей обёртке и реально вызов встречался только в 2-3 местах — на Lwt_unix.socket. И понеслось. Типовычислялка компилятора сразу указала мне, где я, дурень, пытаюсь подсунуть в нормальную сокетную функцию параметр с каким-то странным типом Lwt_unix.file_descr. Следующая неделя прошла за чрезвычайно интеллектуальной работой. Компилятор говорил мне, что нужно сделать чтобы впасть в нирвану, а я всячески пытался её достичь. Таким образом, буквально через несколько дней негритянской работы, передо мной предстал код, который мало того, что не содержал ни одного вызова к стандартным функциям IO, так ещё и компилился.

Каково же было моё удивление, когда с первым запуском оно ещё и заработало! После недели тупой работы, перехода с философии “одно соединение == один самостоятельный псевдопроцесс” на “одно соединение == один конечный автомат”, после исправления тучи кода исключительно по указаниям компилятора! Кривенько, но заработало, результат я увидел. Последующая неделя ушла на исправление совсем новых багов, багов ещё со старой версии и дописывания новых приятных мелочей.

Итого, имеем. Кластер с определённым количеством клиентов (пока меньше, чем на одной машине в среднем, но уже существенно). Прокся заведует как балансировкой нагрузки между HTTP-узлами, так и между MySQL. Т.е. гоняются вполне реальные данные настоящих сайтов. На одно соединение (не запрос) HTTP в среднем уходит чуть меньше миллисекунды CPU (это и проксирование динамики, и отдача статики с помощью системного sendfile). На соединение MySQL уходит несколько больше — около 5 миллисекунд, хотя алгоритм там наоборот в целом проще. Связываю это с

• sendfile() там не применишь, все проксируемые данные копируются в userspace
• Имею богатый опыт разглядывания скриптов клиентов. А это совсем другая, удивительная, не поддающаяся научному изучению культура. У них принято сказать SELECT * на большую табличку, затем сложным алгоритмом с циклами тройной вложенности вычленить из многомегабайтного результата 2 строки, затем их отправить обратно в мускуль с целью join’а в непристойной позе с другой табличкой.

Памяти жрёт в рабочем режиме при текущих нагрузках стабильно 12-15MB (один мастер, 4 рабочих).

Планы (или мечты?) на будущее:

• Пропатчить Lwt на предмет использования epoll() вместо select(). Чтобы в будущем не было мучительно больно обрабатывать 10000 одновременных соединений. Если, конечно, до этого дойдёт.
• Написать некую глюкалу, которая сильно поможет в поиске причин высоких нагрузок как на сайтах, так и в БД. Пока мне это видится чем-то вроде: oproxyreport “select response_time-start_time, uri from http where host=’ispsystem.com’ and uri begins with ‘/ru/’ save to ‘/tmp/load.log’”. Если будет реализовано — сразу можно будет написать интерфейсик в ISPmanager, чтобы клиенты могли сами это делать.

Я всё сказал.

p.s. Нет, не всё :) С переходом на Lwt, обнаружилась ещё одна приятная особенность: портабельность. Например, во FreeBSD 7.1. поломали те самые POSIX треды, из-за чего мне пришлось отказаться от альфа-тестирования прокси на ней в своё время. Lwt же ни от чего не зависит. Select() есть везде, а не блокирующие сокеты криво реализованы разве что в винде.

Из нового:

• Балансировка нагрузки. Универсальный модуль для любых видов соединений. Написано кривовато, но работает. Заведует всеми узлами мастер-процесс. Это несколько замедляет процесс (рабочим приходится больше общаться с мастером), зато позволяет контролировать балансировку в одном месте.
• Файлик: список сайтов. Пока каждый сайт можно только включить/выключить и прописать алиасы. Кроме того, на будущее есть поле “домашняя директория сайта”. В ближайшее время есть планы проксёй отдавать статичные файлы. Не понятно, что делать с .htaccess. Не хочется забивать, как это нынче делается в Nginx.
• Файлик: список узлов. Представляет из себя IP, мастер-пароль, список ролей.
• Роли. Что каждая машина умеет/должна делать. От этого зависит поведение балансировщика и некоторых скриптов. Предопределённые роли: worker_http (узел умеет обрабатывать HTTP-запросы), master (узел будет точкой входа, где висит балансировщик) и другие. Всё рассказывать раньше времени не буду :)
• Мониторинг. Наконец нашёл, где заюзать функционалы. На основе этого функционала (functional) написан мониторинг файлов. Как результат, прокся умеет автоматически подгружать изменённый список сайтов или узлов.
• Новый параметр у oproxyctl: show_nodes. Показывает известные узлы. Кто в дауне, сколько у каждого активных запросов, сколько всего обработано. Может оказаться полезным для выяснения проблемных узлов.
• Поддерживаем новый протокол, который я сам выдумал :) Служит для различных сервисных запросов к узлу. Поскольку позволяет совершать совершенно небезопасные вещи, авторизация происходит без передачи открытого пароля по сети.
• Новая утилита: clusterctl. Умеет 1) запустить на узлах с указанной ролью (или на всех, или на определённом IP) определённую команду и вернуть в STDOUT/STDERR что в итоге получилось 2) рассказывать список ролей текущей ноды 3) рассказывать список узлов, поддерживающих указанную роль. Служит для сервисных скриптов.
• Прокся умеет выставлять X-Forwarded-For, чтобы в конечном итоге в логи попадал нужный IP.
• Сервисные скрипты: apachectl (рестарт Апача на всех узлах), repquota и другие.
• Оптимизация, стабильность.

Допил коньяк. Опять потянуло на философию…

Заменил рекурсивный вызов на цикл, и уже двое суток работаем ровно и без падений; обработано около 2000000 реальных соединений к MySQL.

Кстати…

Уже можно подвести итог, насколько в условиях хостинга с абстрактным набором сайтов (как правило, кривых :), нагружен мускуль. Статистика за сутки. Машина средней мощи, набито правильное количество клиентов.

Активных пользователей в MySQL: 453

Из них, имеющих соединие каждые 5 минут за сутки (т.е. работающих круглосуточно): 46

Принято данных от пользователя (байты голого протокола):  9015309900

Передано байт:  121983229037

В сумме потрачено времени внутри MySQL: 138884 секунды (не забываем, что мускуль умеет жрать несколько процессоров)

Обработано запросов (в т.ч. авторизация и протокольная команда QUIT считаются запросами):  61044220

Это данные за сутки назад, включая бэкапный трафик (прибавляет ~15% ко всем циферкам).