Переезд на кластер под управлением «1С-Битрикс: Веб-окружение»

  • Tutorial
В определённый момент появилась задача — перевести, существующий и активно работающий в production, проект на работу в кластере серверов. Т.к. проект разработан на базе 1C-Bitrix, было принято решение построить кластер с использованием «1С-Битрикс»: Веб-окружение». Цель данного мероприятия — получить возможность выдерживать большие нагрузки при наплывах посетителей сайта, а также возможность в дальнейшем быстрее масштабироваться горизонтально.

Собственно, если мы обратимся на сайт вендора, то там увидим что:

«1С-Битрикс»: Веб-окружение» — Linux служит для быстрой и простой установки всего ПО, необходимого для работы продуктов и решений «1С-Битрикс» на Linux-платформах CentOS 6 (i386, x86_64) и CentOS 7 (x86_64). Устанавливать необходимо на «чистый» CentOS, без уже установленного веб-сервера.

В состав «1С-Битрикс: Веб-окружение» — Linux входят: mysql-server, httpd, php, nginx, nodejs push-server, memcached, stunnel, catdoc, xpdf, munin, nagios, sphinx.


По сути, данный комплекс ПО содержит в себе настроенный LAMP, консольную панель управления сервером, плюс дополнительные, необходимые для работы некоторых модулей 1C-Bitrix, пакеты. Весь софт настроен с учётом особенностей 1C-Bitrix, а именно:

  • установлены необходимые расширения (gd, zip, socket, mbstring)
  • включена поддержка short-тегов
  • заданы необходимые значения для параметров memory_limit, max_input_vars, safe mode, opcache.validate_timestamps, opcache.revalidate_freq, mbstring.func_overload, default_charset, display_errors и др.
  • установлен одинаковой часовой пояс для БД, php и на самом сервере
  • и др.

Это позволяет в большинстве случаев не заниматься настройкой сервера и его тюнингом.

Итак, у нас было 2 app сервера (назовём их app01 и app01), 2 db сервера (db01, db02), 1 сервер под кэширование (cache01, ну вы поняли), точнее была идея реализовать структуру кластера подобным образом. Под этот план были получены 5 серверов, с установленными на них последними версиями centos7 (к сожалению, debian, ubuntu, fedora, rhel и др. не подходят), кроме os на серверы больше ничего не устанавливалось.


Т.к. мы собираем кластер, то необходимо определить, какой из серверов будет основным. Из-за особенностей балансировки запросов к приложению, один из серверов, где будет работать httpd, будет также содержать nginx. Все входящие запросы будет принимать также он, и после этого перенаправлять запрос на одну из доступных web-нод. Мы выбрали основным сервер app01.


В дальнейшем работа пошла по следующему плану:

1. Установить bitrixenv


Установка не подразумевает сверхъестественных знаний linux или администрирования. Заходим на каждый сервер через ssh и выполняем такие команды:

cd ~
wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh
chmod +x bitrix-env.sh
./bitrix-env.sh

Ставить bitrixenv необходимо на все серверы, которые планируется использовать в кластере. Даже если сервер будет работать только как инстанс memcached, bitrixenv необходим, т.к. позволяет управлять всем кластером из основного сервера.

2. Настроить bitrixenv


Т.к. использовать весь этот зоопарк мы будем как кластер, то производить настройку серверов можно через меню окружения на app01. Для этого заходим на сервер через ssh, и запускаем файл /root/menu.sh. При первом запуске необходимо задать пароль для пользователя bitrix (аналогичную операцию необходимо провести на всех серверах, где планируется запуск сайта):



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



Тут нам необходимо выбрать первый пункт меню. В процессе создания окружение запросит имя текущего сервера, тут то мы и указываем app01:



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



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

Теперь нам необходимо добавить в созданный пул все доступные серверы. Для этого воспользуемся первым пунктом меню и увидим такие варианты:



Опять выбираем первый пункт меню, и указываем ip нового сервера, его имя в кластере (те самые app02, db01, db02, cache01) и root-пароль от подключаемого сервера. Таким образом, поочерёдно добавляем каждый имеющийся сервер. После того, как все серверы зарегистрированы в кластере, мы должны получить примерно такой список на главном экране окружения:



Настройку ролей серверов пока отложим на следующий шаг.


3. Перенос проекта


Т.к. наше приложение изначально работает на одном сервере, то модуль масштабирования и управления кластером отключены, база не реплицирована. Сам перенос ничего сверхъестественного из себя не представляет — упаковали папки bitrix и upload, сняли дамп БД.

После того, как архивы и дампы готовы, заходим на app01, и тянем через git код проекта в дефолтную папку сайта в bitrixenv — /home/bitrix/www, скачиваем wget-ом или curl-ом архивы и дамп БД, распаковываем архивы и заливаем дамп в БД на app01, переносим записи cron.

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

Есть небольшой, но важный, нюанс. При переносе сайта в кластер, необходимо чтобы на сайте были отключены модули scale и cluster, а в окружении кластера, в которое планируется перенос, серверы пулла были не задействованы. Включать в работу серверы кластера необходимо только после того, как сайт будет перенесён и развёрнут на основном сервере. В противном случае сайт не сможет корректно определять серверы кластера.


4. Включение кластерного режима работы


После того, как приложение было перенесено на app01, и мы проверили корректность его работы, пришла пора заняться самым интересным — масштабированием. Для начала необходимо установить модули scale и cluster в админ-панели 1C-Bitrix. Во время установки ничего особо делать не нужно, вся работа происходит далее.

Как только модули установлены, переходим в ssh-соединение с основным сервером, а это app01, и открываем меню bitrixenv (лежит тут /root/menu.sh). Прежде чем приступить к дальнейшей настройке, необходимо выяснить один важный момент — bitrixenv оперирует понятием “роль сервера”. Не имеет особого значения, как называется сервер в пуле, т.к. каждый сервер содержит весь софт, который входит в пакет bitrixenv, мы всегда можем назначить ему одну или несколько ролей, а можем снять их с него или поменять на другие. Основные роли это — mgmt (балансировщик, т.е. nginx), web (т.е. httpd/apache), mysql_master и mysql_slave (инстанс БД, slave появляется уже когда начинаем делать репликацию), memcached (сервер с memcached). Общая картина теперь понятна, и мы решили начать с memcached-сервера. Для этого заходим в пункт

4. Configure memcahed servers > 1. Configure memcached service

и видим запрос имени сервера, который будет выполнять роль memcached-сервера. У нас уже есть заготовленный для этого сервер cache01, поэтому смотрим в список доступных серверов. Если cache01 есть в списке, значит никаких проблем с установкой нет, и мы можем дать серверу выбранную роль.



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



Пришло время добавить второй app-сервер. Для этого переходим по пути
8.  Manage web nodes in the pool > 1. Create web role on server,



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



Обратим внимание на то, что в колонке Roles напротив сервера app02 указана роль web.
Осталось разобраться с БД, её настройка занимает больше всего времени. Для начала вкратце объясню, как раздаются роли mysql в контексте bitrixenv. По-умолчанию на основном сервере кластера стоит master версия БД. В нашем случае необходимо было вынести БД на отдельный сервер и добавить ещё один сервер с slave-версией БД. В bitrixenv нельзя просто так взять и перенести master с одного сервера на другой)



Последовательность такая:

  1. Даём роль mysql_slave серверу, на который мы планируем перенести БД
  2. На целевом сервере меняем роль mysql_slave на роль mysql_master (автоматом старый mysql_master переходит в режим mysql_slave)
  3. Удаляем роль mysql_slave на исходном сервере, бывшем master
  4. PROFIT!!!

Мы последовали этой логике таким образом:

Перешли в

3.  Configure MySQL servers > 4. Create MySQL slave



Указали сервер, которому хотим дать роль mysql_slave — db01. Дожидаемся окончания фоновых работ и видим такой результат:



Отлично, теперь переходим в

3.  Configure MySQL servers > 5. Change MySQL master



Указываем app01 и ждём. В итоге должны увидеть примерно такой результат:



Медленно и неотвратимо мы подошли к установке последней роли — mysql_slave. Для этого необходимо повторить действия, которыми мы устанавливали такую роль для db01, но указать уже db02.

Наконец, все серверы подключены и настроены.

5. Тюнинг производительности


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

  • Прокачиваем работу с сессиями. Подробно описано здесь. Вкратце — переключаем хранение сессий в memcached.
  • Удаляем файлы /bitrix/php_interface/after_connect_d7.php и /bitrix/php_interface/after_connect.php, т.к. команды из них обрывают конвейер кластера (если не используется bitrixenv, то их лучше оставить).
  • Увеличиваем количество памяти, выделяемое memcached, и устанавливаем процент использования серверов с ролью memcached до 100%.
  • Отключаем модули php: apcu, ldap
  • Отключить модули БУС «Компрессия», и “Веб-аналитика” (по возможности).
  • Рассмотреть вариант использования локального кэша. Подробнее описано тут. В нашем случае прироста не было, но идея интересная. Решение имеет пару особенностей:

    • Количество инстансов memcached должно равняться количеству web-нод.
    • Для отдачи композитного кэша nginx-ом напрямую из локального memcached придётся поковырять конфиг nginx, из коробки не работает.

  • Перенести выполнение всех агентов на cron.


Выводы


В рамках данной статьи мы разобрали последовательность действий, необходимых для настройки кластера серверов на базе bitrixenv, а также некоторых возможных подводных камней. По итогам работы с bitrixenv, и кластером на нём, можем выделить плюсы и минусы данного подхода:

Плюсы bitrixenv


  • Время установки
    Установка и базовая настройка занимает менее 30 минут. Нет необходимости настраивать элементы LAMP (как интеграцию этих служб друг с другом, так и для корректной работы проектов на 1C-Bitrix).
  • Службы для ускорения работы сайта
    Установленные и настроенные службы, которые позволяют организовать более быстрое кэширование через memcached, а не файлы, поиск с использованием движка sphinx и функционал видеозвонков и чатов на корп.портале (модуль nginx push&pull). Кроме того, nginx в окружении настроен таким образом, что при включении соответствующих опций на сайте и в меню bitrixenv, кэш отдаётся при помощи nginx сразу из memcached (в обход httpd и php)
  • Кластеризация
    Возможность включить репликацию БД, без ковыряния настроек MySQL. Подключение произвольного количества web-нод, которые будут автоматически синхронизироваться друг с другом, и memcached-нод. Управление распределением нагрузки на web- и memcached-ноды как из меню bitrixenv, так и через админ-панель проекта на 1C-Bitrix. Плюс к этому, добавление новых серверов и ролей к ним не вызывает простой проекта (кроме разве что ролей серверов БД)

Минусы bitrixenv


  • Балансировщик всегда вместе с основной web-нодой
    Т.к. у нас уже был свой балансировщик, мы столкнулись с тем, что невозможно отказаться от встроенного в bitrixenv балансировщика. Нельзя в т.ч. разместить его отдельно от основной web-ноды.
  • Много лишнего софта для некоторых ролей
    Т.к. каждый сервер в пулле содержит полную версию окружения, то получается что на db-нодах стоят httpd, memcached, sphinx, пусть они и не используются. Аналогично можно встретить MySQL на сервере, который занимается только кэшированием, но в этом случае MySQL можно остановить в меню окружения или админ.панели сайта.
  • Php работает в режиме apache2handler
    Нет возможности безболезненно включить php в работу в режиме fcgi, не говоря уже о режиме nginx+php-fpm. Так же не получится поменять версию php, без танцев с бубном.


Источники:


www.1c-bitrix.ru/products/env
dev.1c-bitrix.ru/community/blogs/rns/hidden-features-of-work-with-sessions.php
dev.1c-bitrix.ru/community/blogs/rns/the-use-of-local-caches-in-the-cluster.php
dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&INDEX=Y
dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=37&INDEX=Y

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

Используете ли Вы в своих Bitrix-проектах окружение bitrixenv?

  • 23,5%Да8
  • 14,7%Нет5
  • 61,8%Bitrix — зло21
Агентство AGIMA
Компания

Комментарии 26

    0
    каким образом файлы приложения синхронизируются при изменении на одном из членов кластера приложения?
      0
      Насколько я понял, периодически синкаются папки сайтов (/home/bitrix/www/ и /home/bitrix/ext_www/*) при помощи утилиты csync2. Опытным путём установлено что в среднем период составляет 2-3 минуты.
        0
        Когда работал в прошлой конторе от csync2 ушли.
        Из минусов:
        Инфа по отслеживаемым файлам хранились в sqlite, на больших кол-вах файлов тормозило жесть как…
        Пришли к альтернативе: lsyncd
        Использовать в принципе можно. При старте, на отслеживаемом каталоге навешивает так называемые inotify. Если слишком много файлов в отслеживаемом каталоге, старт утилиты может занять некоторое время. :-)
        Важно! По lsyncd настоятельно рекомендую покурить конфиги, изучить опции по умолчанию и их значения. :-)

          0
          Спасибо, буду курить)
          0
          Когда последний раз тестировал развёртывание кластера, то поставился именно lsyncd.
          Автор lsyncd пишет на гитхабе, что master-master репликация не очень хорошо работает в lsyncd и лучше что-то другое использовать, например glusterfs.

          Лучше использовать свой playbook для развёртывания кластера вместо bitix-env. Можно и балансировщиков несколько сделать и vrrp добавить и glusterfs и Percona XtraDB Cluster (master-master) с proxysql и php-fpm и всё остальное, что потребуется
            0
            Интересно. Надо будет в следующий раз обязательно ознакомиться, если опять нарвусь на битрегз в своей судьбе.
        +2
        Благодаря таким статьям лишний раз убеждаешься в скорой смерти битрикса и забивании Рыжиковым на развитие продукта из-за смещения его приоритетов в сторону CRM Битркис24.
        Практика показывает, что масштабировать битрикс его инструментами — это масштабировать проблемы. А с использованием всего этого ретро-барахла эти проблемы только будут множиться. Какой нафиг memcached, если есть Redis/Tarantool? Кешировать надо не страницу, а структуры данных — битрикс без костылей этого не умеет. Какой нафиг Sphinx, если есть Elasticsearch, более понятный и быстрый? php-fpm не поставить — с этого можно было начать статью и этим же закончить.
          0
          Чем в данном случае redis/tarantool лучше?
          Горизонтальное маштабирование уже реализовано в продукте, по этому использовать memcached оправданно. Да было бы хорошо иметь возможность альтернативно, но в данном контексте не критично.
          По поводу Sphinx и ES. В эксплуатации Sphinx проще, а профита перед теми задачами которые он решает в битриксе хватает, но согласен поддержка ES нужна.
            0
            Redis позволяет кешировать структуры: ряды, списки, хэш-таблицы, оперировать с ними (пересечения, перемножения, выборки, поиск и т.д.). А это уже позволяет кешировать не просто кусок сгенерированного HTML, а массивы данных, последовательности ID товаров и много чего еще. Простой пример, вот есть у вас страница товара — элемент инфоблока, данные по цене и наличию из модуля catalog. Допустим, у товара изменилась цена, что сделает битрикс? Он сбросит кеш всего компонента, т.е. всей страницы — это нагрузка. А по-нормальному, на странице надо сбрасывать кеш не всей страницы, а только блока с ценой, ведь название товара, описание, фотки и характеристики не изменились. Или вот фасетный фильтр — это просто дичь. Когда у вас в БД сотня тысяч товаров, у каждого товара десятки характеристик, то фильтр просто не работает. При изменении товаров его надо каждый раз переиндексировать. А тот же Redis предлагает простой решение — числовые ряды, которые можно перемножать и искать пересечения. Это просто частные примеры, их там очень много. Я на одном проекте внедрил всё это дело, теперь фильтр по каталогу ищет за несколько тысячных секунды, вывод товаров без битриксовского кеширования в любом порядке — одна сотая секунды, нагрузка на сервере снизилась с 50-70% до 10-15% при той же посещаемости.
              –1
              ErnestMiller, bitrix, как и его окружение, это в первую очередь инструмент. Любой инструмент создаётся под определённый круг задач, для остальных задач он может не подходить полностью или частично. Описанный Вами проект достаточно специфичен, bitrix мог быть не самым удачным выбором в этом случае, это же коробочное решение — оно хорошо решает часто встречающиеся проблемы.
              Существуют и другие проекты, которые довольно неплохо вписываются в рамки Bitrix. Например интернет-магазин с небольшим количеством товаров, но с большой посещаемостью и оборотом заказов. Проблема с фасетными индексами пропадёт, проблема с кэшированием решается использованием композитного и тегированного кэша. Плюс имеем много готового функционала, т.к. это тиражируемое коробочное решение, что позволяет запустить продукт быстрее.
              Аналогично и с окружением. Можно, конечно, сделать полностью своё окружение, кластеры, контейнеризацию и т.д., но в некоторых случаях это может быть излишним или не в срок.
                0
                Описанный мной проект — обычный интернет-магазин одежды. Как раз для таких проектов битрикс и предлагается. Тегированный кеш я как раз и описывал, сбрасывается при изменении цены.
          0

          Для каких задач, если не секрет, используете на проекте RabbitMQ?

            0
            Асинхронно работаем со внешними web-сервисами. Т.к. работа идёт довольно активная и в обе стороны, bitrix-агенты не вытягивали, то реализовали это через кролика.
              0
              Спасибо, а для интеграции с 1С не приходилось его использовать?
              0
              Эта задача решилась бы сильно проще, если бы вы использовали, например, Proxmox. Выделить все фоновые задачи в отдельный контейнер без лишних костылей и всё.
                0
                Не понятно, что должно упростить добавление нового виртуального сервера в инфраструктуру? Сейчас многопоточная работа с очередями вполне успешно решает проблему фоновых работ, без добавления новых узлов кластера.
                Новый виртуальный сервер может решить проблему недостаточного кол-ва выч. ресурсов, но никак не упростить поддержку проекта.
            0
            Это хорошо, когда всё рабочее окружение можно развернуть так быстро. А если проект работал раньше Ubuntu, переход не вызывает проблем?
              0
              Мы мигрировали с RHEL на CentOS, проблем не было. Собственно web-сайту без разницы какая OS стоит, он работает, в основном, с LAMP. Проблемы скорее возникнут если в проекте используете какой-нибудь софт, которого нет, или его не так просто установить, на CentOS.
              0
              Добрый день, а по какой причине debian не подходит?
                0
                Bitrixenv поддерживает только CentOS, на других дистрибутивах оно не устанавливается.
                  0
                  Если все ПО ставить напрямую и все самостоятельно настраивать, не пробовали? Какие-то сложности могут возникнут кроме конечно настройки всего самостоятельно
                    0

                    Сам bitrix на debian вполне работает, его можно развернуть даже на alpine в docker — если настроить окружение самостоятельно. Правда разбор нюансов настройки такого окружения займет достаточно времени, особенно если необходим кластерный режим работы приложения.

                      0
                      Работа в обычном режиме это понятно, интересовали нюансы для кластерного режима у Битрикс).
                        0
                        При работе в кластерном режиме необходимо поковырять механизмы репликации БД в CMS. Кластеризация web-серверов, серверов кеширования и т.д. настраивается с меньшей оглядкой на сам bitrix, поэтому тут достаточно общеизвестных подходов.
                        Так же есть большая вероятность того, что, при ручной настройке окружения, часть функционала по управлению масштабированием в админ.панели может быть недоступна.

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

              Самое читаемое