Масштабирование журнала робота
Журнал робота – наиболее нагруженная часть Оркестратора. Журнал робота может быть масштабирован за счет вынесения на отдельные серверы ответственных за работу журнала компонентов Оркестратора.
В зависимости от нагрузки, которую могут создать роботы, предлагается несколько вариантов масштабирования.
Максимальная изоляция компонентов
В случае варианта с максимальной изоляцией компонентов Оркестратора:
- Оркестратор имеет 2 физически независимых внешних эндпоинта, один из которых предназначен специально для приема логов от роботов (поддержка будет в следующих версиях робота).
- Эндпоинт приема логов содержит свой собственный экземпляр RabbitMQ, который используется в качестве буфера для запросов файлов скринов с машин роботов.
- БД с логами – два отдельных сервера, связанных асинхронной потоковой репликацией. Master-БД используется только для записи. Slave-БД – только для чтения.
Общий nginx
В случае варианта с общим nginx:
- Оркестратор также имеет 2 физически независимых эндпоинта, один из которых (внутренний) предназначен специально для приема логов от роботов. Запросы с логами роботов проксируются во внутренний эндпоинт приема логов от одного единственного внешнего эндпоинта.
- Данный вариант может совмещаться с вариантом 1.
- Сервер БД логов можно использовать для экономии один (без разделения моделей чтения/записи).
Минимальный
В случае минимального вариант:
- Службу приема логов RobotLogs можно хостить там же, где служба WebApi.
- Необходимость в раздельных RabbiMQ тогда отпадает.
- Для БД логов один сервер*
* - Крайне не рекомендуется располагать БД логов Оркестратора на сервере с остальными БД Оркестратора. Тем более совмещать сервер БД и сервер приложений.
