Установка 1С-Битрикс веб кластер. Часть 2

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

Битрикс веб кластер «почему все так плохо»

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

Будем считать что сам кластер уже установлен.

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

Что произойдет на самом деле?

Вы синхронизируете кластер и он заработает! Вы реально множите размещать файл на любом сервере изменять их и все с виду будет работать, но!

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

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

	 */5 * * * * root /opt/webdir/bin/csync2_full_push site

И сам конфиг

	 /etc/csync2/csync2_вашсайт.cfg

тоже выглядит вполне пристойно

host вашсайт

include /home/bitrix/ext_www/вашсайт.ru;

exclude /home/bitrix/ext_www/вашсайт.ru/bitrix/cache;

exclude /home/bitrix/ext_www/вашсайт.ru/bitrix/managed_cache;

exclude /home/bitrix/ext_www/вашсайт.ru/bitrix/stack_cache;

exclude /home/bitrix/ext_www/вашсайт.ru/upload/resize_cache;

exclude /home/bitrix/ext_www/вашсайт.ru/bitrix/modules/xmppd.log;

exclude /home/bitrix/ext_www/вашсайт.ru/bitrix/modules/smtpd.log;

В свою очередь демон отвечающий за синхронизацию сайтов сейчас занят одним делом, собирает гигантский список файлов со скоростью 10–20 файлов в минуту! В свою бд. После чего начнет каждый файл по отдельной сессии перекидывать на новый сервер (со скоростю копирования файлов фактически ниже чем по ftp в несколько раз) учитывая неторопливость составления самой бд и при том очень большую прожорливость к I-O время когда обычный стоковый сайт битрикса появится на второй ноде около 21 часа! Все это время csync2 будет активно работать просаживая I-O системы на 98%. Не делая фактически ничего!

Прямое копирование файлов на вторую ноду приведет к еще более печальным последствиям — кластер встанет, поскольку теперь с обоих сторон будет иметься новый файл! И csync скажет что он запутался. Да и попросту встанет колом.

В результате для нормальной синхронизации первый раз, вам придется отключить синхронизацию по крону, зайти в ман по csync2 и сделать первую синхронизацию руками, это займет в сотни, а то и тысячи раз меньше времени, чем просто ждать. Это единственный способ!

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

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

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

Но на этом веселье не заканчивается.

Мы добавляем второй сайт скажем test.kz и тут у нас начинается совсем смешные штуки.

Для начала синхронизировав ручками первый раз сайт мы проверяем все ли работает, и да мы запустили задачи по крону все стало работать, вот правда отвалился первый сайт!

Лезем в /etc/ansible для разбора полетов

Находим вот такую замечательную штуку {{ item. SiteCsync2 }} = ваш домен до точки!

А у меня два домена test1.ru test1.kz

Следовательно проверяем догадку смотря в конфиги

/etc/ansible/roles/web/task/balancer.yml

{{ csync_configdir }}/csync2_{{ item. SiteCsync2 }}.cfg"

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

На мой вопрос в службу поддержки о невозможности использовать домен с разницей на 1 уровне был дан любезный ответ, «спасибо за обращение функция мультисайтовости с кластера будет скоро удалена»

WTF?!?!?!?!

Так что для региональных зеркал битрикс в будущем вам порекомендует отдельные серверные стойки!

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

Вот небольшой перечень проблем которые возникли у меня при создание кластера:

1. Стандартная сборка кластера — синхронизация 879 Mb заняла 21 час, с отсутствием любого статуса в панели или на сайте.
2. После синхронизации папка bitrix была удалена поскоку по дате создания была более новая версия папки на слейв ноде (в ней лежит только dbcon.php созданный битрикс кластером. Да-да тот который создаетя с ошибкой в префиксе бд если сайты одинаковые по домену 2 уровня.
3. Удаление данного каталога как и index.php на слейв ноде до синхронизации привело к такому же результату csync2 просто убил эти файлы и каталоги на мастер хосте. Как и говорил до этого первую синхронизацию нужно проводить ручками, стандартный метод просто неработоспособен.
4. Убились все конфиги для одинаковых доменов 2 уровня.
5. Упала производительность сайта примерно в 200 раз связано это с конфигурацией мастер слейва для статического контента, в купе с динамическим.
6. Кластер не умеет работать с кешем, уже писал выше.
7. Кластер не может работать с CDN практически по той-же причине.
8. Кластер не может работать с композитом.
9. Кластер не может работать с html кешем.
10. Кластер из коробки вообще невозможно сконфигурировать, там попросту нет ни одного меню для этого, его базовая конфигурация наихудший вариант из всех возможных.
11. Кластер без глубоких знаний linux поднять попросту невозможно.
12. Кластер работает только на 1с-битрикс виртуальной машине, любой другой способ его установки настолько затруднителен что в 10 раз проще собрать свой кластер без использования 1с-битрикс, в принципе это справедливо и даже с использованием виртуальной машины.
13. Очень сырой продукт в целом, мало того еще и практически не документирован.
14. Заявление на презентации битрикс 14 о включение «кластера» с 2 серверами во все базовые решения полное и откровенное вранье, кластер как был отдельной «старшей» редакцией так ей и остался.
15. В балансере нет четких правил по переключению мастер слейв ноды.

Но обо всем по порядку.

Допустим мы все победили и бд и файлы у нас синхронизированы все работает, но почему так все адски медленно? Производительность в 1с-битрикс упала до 0.2 со 170!

тут причина в конфигурации кластера по умолчанию.

Все что вы читали по поводу мастер-слейв мастер—мастер и т. д. вы множите выкину в мусорку, 1с-битрикс НЕ УМЕЕТ переключать конфигурации. Это попросту вранье, в нем нет ни единой строчки кода отвечающих за это. Как и нет ни единой строчки кода указывающей на вид текущей конфигурации, ровно как и документации по этому поводу. Даже в обучении битрикс виртуальной машине вы не найдете базовое расположение базового собранного кластера.

А выглядит он примерно вот так!

Какой умный и безусловно злобный гений предложил так собрать кластер я не знаю, но с точки зрения менеджмента это однозначно провал!

Вот как изменилась производительность:

Было:

Стало:

Я честно не верю что среднестатистический php программист которому начальник даст задачу собрать 1с-битрикс кластер. Качественно разбирается в балансировке nginx отлично админит линукс, знает csync2 и ansible отлично разбирается в apache-nginx конфигурации.

На очень пристойном уровне умеет читать bash скрипты и т. д.

Скорее всего он просто с горем попала подняв кластер увидит производительность этого мероприятия и бросит все на этом! Поскольку документации вообще никакой нет и где ему рыть не совсем понятно.

По мне так это полный провал самой идеи!

Для тех, кто не понял ошибочности конфигурации серверов, я опишу более детально.

И так, допустим у нас расстояние между серверами 40ms поскольку мы используем разные дата центры.

Следовательно, запрос у нас идет вначале на сервер 1, потом на 2, потом на 1, притом последние запросы sql, и каждый из них будет добавлять 40ms. Причина по которой кластер при первом старте так выглядит мне не известна, но не хотелось бы верить в то, что попросту в nginx балансере человеку писавшему скрипт обломило дописать 1 строчку кода.

Фактически добавлена вторая машина идет как последняя объявленая, а следовательно все запросы по умолчанию (ибо не было указано никаких приоритетов) будут идти на нее.

Просто поменяв машины местами в

/etc/nginx/bx/site_available/upstream.conf

и перезапустив nginx,

мы можем получить изначальную схему работы сервера, с дополнением в виде отказоустойчивости, но надо понимать что второй сервер по прежнему будет в dbcon.php иметь директиву host: server1.ru, а следовательно при падении бд на нем все равно будет не жизнеспособен.

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

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

В такой конфигурации на мой взгляд я бы и продавал кластер.

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

Ведь бизнес модель «кластер из коробки» и подразумевает мелкий и средний бизнес hh.ru и без всяких... себе поднимет кластер. А следовательно, мелкому сегменту он нужен только в двух случаях.

1. Сайт максимальное время доступен, имеет инкрементную копию, пусть даже с переназначением слейв базы в мастер после восстановления мастер нод.
2. Указать более детально причину получения данных с слейв ноды, но ее в админке нигде нет, по сему «сервер из коробки» должен уж если не давать настроить эти параметры при старте, то как минимум не проседать по производительности.

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

Единственное, что я хотел бы еще добавить так это как бы я действительно хотело видеть это решение:

1. Естественно, битрикс кластер запускается исключительно с битрикс машиной, это промо ход и он удачен.
2. Отладить все баги, а их море поскольку нет выбора способа конфигурации создать 1 единственную мастер +слейв и балансер забрать в облако битрикс. В таком случаи кластер был бы действительно отказоустойчивым и при выходе из строя полностью машины мастер ноды мог все еще продолжать работать. Да и очень важным плюсом стало бы невозможность съехать с битрикса в дальнейшем, поскольку балансер кому-то нужно держать.
3. Также решилась бы проблема с проверкой битрикс сайта на лицензию кластера, существующая проверка настолько легко ломается что я попросту не могу ее привести в статье, будучи золотым партнером битрикс.
4. Самое важное кластер должен быть подъемен обычным юзерам, отладить 1 единственную схему с четким действием намного легче чем хвататься за все подряд.
5. Никто не запрещает заставить пользователя давать одинаковые мастер слейв ноды, домены 3 уровня от основного сайта и т. д., четкая последовательность действий хоть и не подойдет всем, но даст «готовое решение», а не то, что есть сейчас. Пусть оно будет не всем подходить, но будет работать!

ИТОГ с точки зрения linux администратора:

Битрикс виртуальная машина сильно скакнула по производительности на 1 сайт, сделали очень много полезного, добавили наконец возможность удалить ноду (в прошлой версии даже этого не было). Вообще тенденция есть хорошая, но если говорить о сырости, то продукт с точки зрения хостинга для нескольких сайтов вполне себе рабочий, не считая убогой идеи класть сайт в папку default. За которую я бы просто оборвал бы руки.

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

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

Решение кластер настолько сыро и настолько медленно, что использовать его из коробки попросту невозможно.

Сборка битрикс веб кластера даже у хорошего админа займет больше времени, чем собрать руками.

ИТОГ с точки зрения программиста php:

Тут все просто битрикс кластер трогает программиста только 1 строчкой возвращая с ядра ответ true проверяя наличие модуля кластер. Если же говорить с точки зрения применения, то обычный программист не может применить решение «1с-битрикс веб кластер».

ИТОГ с точки зрения менеджера

Тут все просто, решения 1С-битрикс кластер не существует!

Можно вдаваться в дальнейшую полемику, но факт остается фактом, существующее решение «продать» нельзя!

P.S отдельное спасибо коллегам с vps-server.ru которые предоставили мне на общественных началах vps серверы для первоначальных тестов, да в конечном итоге я уже работал на didicate серверах, но в любом случае они мне хорошо помогли, сэкономив кучу времени.

Сегодня 15.06.2015 мне пришло сообщение от битрикс о фиксировании бага связанного с коротким доменом, возможно часть багов будут в ближайшее время так же исправлены!