Масштабирование журнала робота

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

Максимальная изоляция компонентов

В случае варианта с максимальной изоляцией компонентов Оркестратора:

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

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

3. БД с логами – два отдельных сервера, связанных асинхронной потоковой репликацией. Master-БД используется только для записи. Slave-БД – только для чтения.

Общий nginx

В случае варианта с общим nginx:

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

2. Данный вариант может совмещаться с вариантом 1.

3. Сервер БД логов можно использовать для экономии один (без разделения моделей чтения/записи).

Минимальный

В случае минимального вариант:

1. Службу приема логов RobotLogs можно хостить там же, где служба WebApi.

2. Необходимость в раздельных RabbiMQ тогда отпадает.

3. Для БД логов один сервер*

* - Крайне не рекомендуется располагать БД логов оркестратора на сервере с остальными БД оркестратора. Тем более совмещать сервер БД и сервер приложений.