Pull to refresh

Comments 25

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

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

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

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

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

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

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