Технологии кластеризации 1С-Битрикс - распределение файлов веб-проекта и балансировка

Добрый день, коллеги!


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


Из чего состоит веб-проект на платформе 1С-Битрикс?

Прежде всего, вспомним, из чего состоят наши веб-проекты? Из информации в базе данных, эффективную работу с которой в контексте кластеризации мы подробно разобрали, и информации в файлах.

В файлах хранится информация следующих типов:


1) "Узлы и агрегаты платформы 1С-Битрикс"

Библиотеки, скрипты, вспомогательные файлы: меню, права доступа, свойства разделов и страниц, шаблоны сайтов, файлы конфигурации. Часть файлов находится условно "под капотом", менять их нельзя, они обновляются по технологии SiteUpdate - благодаря чему ядро системы постоянно улучшается, в нем появляется новый функционал.

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


2) Загружаемый контент

Загружаемые в объекты модулей системы (например, "Медиабиблиотеку" ) файлы, документы и изображения хранятся в подпапках системной папки "/upload". Почему файлы и документы хранятся в файловой системе, а не в базе данных? Это общепринятая архитектурная практика, доказавшая свою эффективность: в базе данных хранится справочная мета-информация, которая оптимально проиндексирована для поиска, а сами большие объекты хранятся отдельно (в файловой системе или "облачном" хранилище) и отдаются клиентам напрямую специализированными инструментами, например через nginx.


3) Страницы веб-сайта

Страницы веб-сайта редактируются через административный интерфейс и хранятся в виде файлов. Разделы это папки, страницы - файлы. Размещенные на страницах изображения также можно хранить в виде файлов, например в папке "/images".





Повышение эффективности работы с файлами - на одной ноде кластера

Чтобы максимально разгрузить сервер приложений (его роль часто выполняет Apache, популярность набирает технология php fpm), выполняющий код нашего веб-проекта, работу со статическими файлами переводят на обратный прокси-сервер, например nginx.

Обратный прокси очень эффективно напрямую работает со статическими файлами, в том числе из системной папки "/upload" - изображениями, документами, архивами и т.п., позволяя серверу приложений сосредоточиться на выполнении кода.

Чтобы снизить нагрузку на дисковую подсистему сервера, на linux, например, стараются освободить как можно больше оперативной памяти. В этом случае файлы закэшируются в оперативной памяти и будут отдаваться оттуда значительно быстрее. Особенно это эффективно при интенсивном скачивании клиентами файлов веб-проекта (документы, видео). Поэтому, если известно, что контента ожидается на 10G - устанавливайте соответственно большее количество оперативной памяти.



На графике видим, что на сервере 7.5GB памяти, при этом приложения используют 300МB (nginx+apache), а для кэша и буфферов файловой системы задействовано более 5GB. Этот объем будет отдаваться клиентам значительно быстрее, чем если бы он отдавался напрямую с диска.

Сервер "статики"

Если веб-проекту требуется отдавать значительно большие объемы контента, то можно делегировать задачу отдачи контента серверу "статики". При этом тяжелая "статика" будет отдаваться с отдельного домена/сервера, например images.mysite.ru - что позволит браузерам загружать веб-страницы в параллельном режиме (обходя ограничения браузера на число подключений к одному серверу). Также, на данном домене для "статики" можно сократить до минимума число cookies - сократив трафик и нагрузку на канал.

Для сервера "статики" обычно формируют быструю дисковую подсистему - например рейд10 (или рейд0 - если данные можно перезалить).

Чтобы сохранять "тяжелые" файлы для скачивания на сервере статики, можно организовать для этого отдельный бизнес-процесс: контенщик по ftp сохраняет там файл и вставляет ссылку на него в контент страницы. Можно вместо ftp подмонтировать папку с файлами с сервера "статики" к ноде кластера и тогда нужно будет просто класть файлы в эту папку - главное сформировать правильную ссылку.


Кэширование на обратном прокси-сервере

Популярный nginx поддерживает кэширование статических файлов (или их "перетаскивание"). В этом случае можно не загружать на сервер "статики" файлы по ftp/cifs/nfs - а сделать закачку "автоматической".


Когда нужен CDN

Если ваша задача раздавать тяжелое видео и ожидается большое число одновременных скачиваний - наверно лучшим решением будет CDN, в том числе облачный.



Промежуточный итог - "тяжелые" скачиваемые файлы желательно хранить отдельно и отдавать оттуда же

На летней партнерской конференции 2011 мы расскажем, какие новейшие технологии в данной области мы включим в платформу 1С-Битрикс. Приходите, не пожалеете!  


Итак, с организацией эффективной раздачи файлов все понятно и просто. Теперь подумаем, как синхронизировать оставшиеся файлы веб-проекта между нодами веб-кластера?


NFS/CIFS

Казалось бы все просто. Экспортируем папку с файлами проекта на другие ноды веб-кластера по NFS/CIFS. Проблема один - производительность. К сожалению, при высоких нагрузках веб-проект будет работать значительно медленнее на нодах, подсоединяющихся к реальному диску "через сеть". Проблема два - при выходе из строя ноды1, остальные ноды ... потеряют данные и не смогут работать.


OCFS2(GFS2)

Эти и другие кластерные системы предназначены для работы с разделяемыми дисками. Например диск C должен быть примонтирован как на ноду1, так и ноду2. Это конечно эффективно, но требуются дополнительные затраты на оборудование. Передовые облачные хостинги, такие как Amazon или Оверсан-Скалакси, пока не предоставляют такую услугу.


OCFS2(GFS2)  over DRBD

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


Csync2

В случае, когда файлов на вашем веб-кластере не миллионы, данная утилита работает отлично. Пройдем по ее основным режимам работы, т.к. в официальной документации они описаны не очень понятно.


Конфигурация

В системе может быть сколько угодно файлов конфигурации csync2. В этом случае создается такое-же количество баз данных SQLite, используемых для хранения информации о файлах. Это пригодится, когда файлов много и хранение их в одной базе отрицательно сказывается на производительности.
Сервер утилиты при этом работает на одном порту и разбирает с какими конфигами работать в зависимости от режима работы клиента.


Начальный импорт данных

Если вы не можете остановить основной сервер с файлами при настройке синхронизации файлов на вторую ноду веб-кластера, то
можно поступить так:

1) Выполнить индексацию файлов на ноде1: csync2 -cIr /
2) Запустить архивацию файлов на ноде1. Да, мы понимаем, что архив может оказаться нецелостным, но мы сделали "снимок" в п.1
3) Распаковать архив на ноде2.
4) Выполнить индексацию файлов на ноде2: csync2 -cIr /
5) Выполнить первоначальную синхронизацию в обе стороны. На ноде1, затем на ноде2: csync2 -cr /, csync2 -u


Логика работы

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

Собираем изменения: csync2 -cr /

Проверяем, что локально что-то поменялось: csync2 -M - выводятся данные, которые будут возможно переданы на другие ноды веб-кластера.

Отправляем изменения на другие ноды веб-кластера: csync2 -u. Предварительно можно добавить ключик "холостого" запуска - d.

Проверяем, что изменения ушли из списка модификаций: csync2 -M - он должен быть пустым.


Режим отладки

Если утилита сообщает об ошибке, подробности процесса можно посмотреть, добавив ключики -v или  -vv. Как правило причина ошибки становится понятной.


Производительность

На относительно небольшом количестве файлов (до 100к) утилита стабильно работает с частотой синхронизации 1 раз в минуту.
Для большего количества файлов можно ее запускать реже, если это позволяет бизнес-процесс.



Балансировщик

В nginx, например, можно настроить балансировку используя модуль upstream как в режиме round-robin, так и путем хэширования ip-адреса клиента.


Для "быстрого" достижения эффекта он-лайн синхронизации файлов между нодами веб-кластера поможет использование режима ip_hash - каждый клиент будет ходить на "свой" сервер и сразу видеть загруженные им файлы. Правда это уже будет не балансировка, а скорее дистрибуция, но конфигурация будет устойчивой - при выходе из строя одной из нод, запросы автоматически будут обслуживаться другой нодой веб-кластера.

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

Однако, если для вас критично, чтобы любые изменения на одной из нод веб-кластера "мгновенно" появлялись на всех других нодах, смотрите на кластерные файловые системы типа OCFS2/GFS2.

SSL-termination



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


Передача IP-адреса через балансировщик на ноды кластера

При использовании балансировщика не забывайте передавать реальный адрес клиента в ноды веб-кластера. Это можно сделать различными способами, которые хорошо известны и описаны - например путем установки заголовка на nginx.

ИТОГИ

Мы предметно поговорили о стратегиях организации работы с файламивеб-кластера на платформе 1С-Битрикс, научились выбирать балансировщик и режимы его работы для использования в кластере, изучили типы размещения "больших" файлов, CDN, кэширование.