При работе в кластерном режиме необходимо поковырять механизмы репликации БД в CMS. Кластеризация web-серверов, серверов кеширования и т.д. настраивается с меньшей оглядкой на сам bitrix, поэтому тут достаточно общеизвестных подходов.
Так же есть большая вероятность того, что, при ручной настройке окружения, часть функционала по управлению масштабированием в админ.панели может быть недоступна.
Сам bitrix на debian вполне работает, его можно развернуть даже на alpine в docker — если настроить окружение самостоятельно. Правда разбор нюансов настройки такого окружения займет достаточно времени, особенно если необходим кластерный режим работы приложения.
Мы мигрировали с RHEL на CentOS, проблем не было. Собственно web-сайту без разницы какая OS стоит, он работает, в основном, с LAMP. Проблемы скорее возникнут если в проекте используете какой-нибудь софт, которого нет, или его не так просто установить, на CentOS.
Не понятно, что должно упростить добавление нового виртуального сервера в инфраструктуру? Сейчас многопоточная работа с очередями вполне успешно решает проблему фоновых работ, без добавления новых узлов кластера.
Новый виртуальный сервер может решить проблему недостаточного кол-ва выч. ресурсов, но никак не упростить поддержку проекта.
Асинхронно работаем со внешними web-сервисами. Т.к. работа идёт довольно активная и в обе стороны, bitrix-агенты не вытягивали, то реализовали это через кролика.
ErnestMiller, bitrix, как и его окружение, это в первую очередь инструмент. Любой инструмент создаётся под определённый круг задач, для остальных задач он может не подходить полностью или частично. Описанный Вами проект достаточно специфичен, bitrix мог быть не самым удачным выбором в этом случае, это же коробочное решение — оно хорошо решает часто встречающиеся проблемы.
Существуют и другие проекты, которые довольно неплохо вписываются в рамки Bitrix. Например интернет-магазин с небольшим количеством товаров, но с большой посещаемостью и оборотом заказов. Проблема с фасетными индексами пропадёт, проблема с кэшированием решается использованием композитного и тегированного кэша. Плюс имеем много готового функционала, т.к. это тиражируемое коробочное решение, что позволяет запустить продукт быстрее.
Аналогично и с окружением. Можно, конечно, сделать полностью своё окружение, кластеры, контейнеризацию и т.д., но в некоторых случаях это может быть излишним или не в срок.
Насколько я понял, периодически синкаются папки сайтов (/home/bitrix/www/ и /home/bitrix/ext_www/*) при помощи утилиты csync2. Опытным путём установлено что в среднем период составляет 2-3 минуты.
Так же есть большая вероятность того, что, при ручной настройке окружения, часть функционала по управлению масштабированием в админ.панели может быть недоступна.
Сам bitrix на debian вполне работает, его можно развернуть даже на alpine в docker — если настроить окружение самостоятельно. Правда разбор нюансов настройки такого окружения займет достаточно времени, особенно если необходим кластерный режим работы приложения.
Новый виртуальный сервер может решить проблему недостаточного кол-ва выч. ресурсов, но никак не упростить поддержку проекта.
Существуют и другие проекты, которые довольно неплохо вписываются в рамки Bitrix. Например интернет-магазин с небольшим количеством товаров, но с большой посещаемостью и оборотом заказов. Проблема с фасетными индексами пропадёт, проблема с кэшированием решается использованием композитного и тегированного кэша. Плюс имеем много готового функционала, т.к. это тиражируемое коробочное решение, что позволяет запустить продукт быстрее.
Аналогично и с окружением. Можно, конечно, сделать полностью своё окружение, кластеры, контейнеризацию и т.д., но в некоторых случаях это может быть излишним или не в срок.