Дозоры.RU / кластерная архитектура

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

Бизнес-логика, наложенная на топологию сети *.dozory.ru:


http://game.dozory.ru/*, то есть все игровые запросы. Все запросы попадают на LVS-Director (Linux Virtual Server) — служба балансировки нагрузки для Linux High Availability Cluster. Состоит из следующих частей:
+ Модуль в ядре, который в соответствии с таблицей LVS бэкендов и хэшем соединений, создает и прокидывает входящие клиентские соединения;
+ Демон ipvs_sync, который синхронизирует таблицу LVS бэкендов и хеш соединений между узлами;
+ Утилита ipvsadm, которая позволяет управлять таблицей LVS бэкендов, хешем соединений и работой демона ipvs_sync;
+ Перловый демон ldirectord, который, в соответствии с конфигурацией, проверяет работоспособность бэкендов и изменяет таблицу LVS бэкендов.

Своими словами — внешне все, что стоит за L-Director выглядит как один IP-адрес. Запрос приходит на него и перенаправляется на один из бекендов (в нашем случае). Обратно запрос идет в сеть напрямую уже с бекенда не проходя через L-Director (схема похожая на Carp, но работающая на Linux).

На бекендах (их в Дозорах восемь) работают тяжелые mod_perl'ы. Машины постоянно не загружены, но их должно быть много. Почему? Ответ кроется в том, что большую часть времени mod_perl'ы ждут ответов от различных демонов — критичные по производительности участки вынесены в отдельные демоны.

Демоны работают на трех машинах, слушают чертову тучу портов: игровой демон, демон боев, демон ботов, демон чата, демон энергии, демон баннерной сети, демон сохранения персонажей в БД. На этих же машинах работают memcached'ы (их 20 штук). Зачем именно 20 — по всей видимости для гибкости, в каждом из них хранится свой вид информации.

Вернемся к LVS-Director, он работает на двух машинах, которые по идеи должны представлять из себя High Availability Cluster. Узлы кластера в данной системе общаются между собой, и при утрате работоспособности одного из узлов, другой подхватывает функции упавшего. Ресурсы привязаны к одному конкретному узлу, который является для них первичным. При восстановлении работы узла, все его ресурсы, временно поддерживаемые вторым узлом, возвращаются к нему. При этом, некоторые из ресурсов, при обратном переключении не освобождаются на резервном узле, а переключаются в резервный режим. Например, LVS Sync Daemon, при возвращении с резервного сервера на первичный, перезапускается на резервном сервере в резервном режиме, также это делает драйвер DRBD.

В данном проекте используется в двух местах — основной кластер (собственно game.dozory.ru: машины front и content) и кластер административной базы данных.

Программный код игры между двумя машинами основного кластера шарятся с помощью технологии DRBD. DRBD — Distributed Replicated Block Device. DRBD можно рассматривать как сетевой RAID-1. Устройство DRBD обслуживается драйвером ядра. DRBD принимает данные, записывает их на локальный диск и пересылает по сети на другой хост, с другой стороны данные так же записывются на диск.

Каждое из устройств DRBD может находится в состоянии primary либо secondary. На узле с primary устройством приложения обращаются к устройству /dev/drbdX. При системном вызове write присходит запись данных на локальное устройство нижнего уровня, после чего данные передаются на узел, находящийся в состоянии secondary. Устройство secondary записывает принятые данные на локальное устройство нижнего уровня (например диск), чтение с устройства DRBD всегда происходит локально.

Если primary устройство выходит из строя то heartbeat переключает secondary устройство в состояние primary и запускает приложение на нём. если используется нежурналируемая файловая система то предварительно запускается fsck. Если отказавший узел снова вступает в работу, то он получает статус secondary и его данные синхронизируются с текущим primary устройством.



Есть еще парочка сетевых файловых систем, используемых в Дозорах. В частности интересно устроена система выкатки. К устройству DRBD подмонтированы по NFS все бекенды, апачи которых читают данные с подмонтированных ресурсов. Основной NFS демон шарит ресурсы, расположенные на диске DRBD (исходники, конфиги, шаблоны и т.д.), которые монтируются бэкендами, машинами с игровыми демонами. Используется в качестве аналога системе выкатки. В нормальном режиме сервер запускается на front, в случае сбоя на content.

Третья сетевая ФС — SSHFS. Шифрованная сетевая файловая система используется для доступа к приватным данным на frontend кластере. Совершенно непонятно зачем это сделано (шарятся аватары и сохраненные логи боев).

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

В следующих сериях — о базе данных проекта Дозоры.RU, веерных отключениях бекендов; о том, как один медленный разделяемый ресурс способен убить всю систему. Предугадывая вопрос — то, что нарисовано и опубликовано — далеко не все, что мы успели изучить ;-)