1. Разработка средств управления и
мониторинга распределенной
мультиагентной системы
Валик Базаревский

3. "Как взвешивание само по себе не уменьшает
вес, так и контроль качества сам по себе не
улучшает качество"

Доступность

Производительность

Отказоустойчивость

Конфигурируемость

Масштабируемость

4. Зачем нам это понадобилось:

Тяжело отслеживать состояние всей системы

Тяжело поддерживать и обновлять распределенную систему

Надо знать что из себя представляла система в тот или иной
момент времени (как правило когда произошел сбой)

Оптимизация производительности, прогнозирование нагрузок,
определение оптимальной конфигурации (разные алгоритмы
анализа требуют разных ресурсов)

Политические игры с отделом IT заказчика, в значительной мере
усложняющие поиск и раннее выявление проблем на
production

5. Краткое описание системы:
Система анализа качества
переводов.
Есть порядка 10 различных
алгоритмов, которые постоянно
обновляются.
Task Processor
Task Controller
Tasks Queue
Web Service
Message queue
Windows Service
Tasks Storage
Сложность (длительность
выполнения) алгоритма
довольно сложно
прогнозируема (по крайней
мере нас так заверили).
SQL Database
Task Processor
Windows Service
File Storage
Network Share
Task Controller
Web Service
Task Processor
Windows Service

6. Слой данных:

MS SQL

Network Share

Message Queue (Rabbit MQ / Azure Service Bus)

7. Что мы сделали/делаем:





Единая страничка, проверяющая работоспособность всех
элементов системы (как правило такая страничка есть у каждого
приложения)
«Центральная" конфигурация (при старте каждый агент скачивает
себе все настройки, включая connection string)
Поддержка обновлений (при появлении новых алгоритмов, новых
словарей, все агенты получают сообщение, что необходимо
обновиться).
Возможность опросить всех агентов об их состоянии (версию
алгоритмов, словарей, работает/остановлен и т.д.)
Performance counters для каждого из агентов (ram, io, network, cpu,
i.e.), таким образом, мы сможем посмотреть что происходило во
время исполнения каждой из задач, если задача выполнялась
несколько раз, возможность сравнить показатели)

8. Как это выглядит:

9. Или так:

10. «Центральная» конфигурация

Скачать последнюю версию алгоритмов, словарей, актуальные
connection strings

Скачивание происходит только на старте нового TaskProcessor-а,
в дальнейшем он не зависит от источника конфигурации

Провайдером конфигураций может быть любой из
TaskController-ов

11. Сервисная шина

Так, как у нас в системе уже были очереди, логично было их
просто немного расширить. Внедрять дополнительный
компонент только для heartbeat-ов – вопрос очень спорный.

Теоретически можно использовать любой из RPC для опроса
агентов, но асинхронная модель предпочтительней.

12. Queues

It should be persistent (i.e. in case of shutdown, queue should not lose not yet
processed tasks).

It should provide confirmations after successful task processing, in case of failure it
should put task back in queue for processing.

It should guarantee, that each task in queue would be processed by only one
consumer.

It should provide priority mechanism.

It should guarantee, that tasks will get back to the queue even in case of
unexpected hardware failure of Task Processor node.

It would be nice option to see real-time performance statistics.

Technology stack for the solution should have commercial support.

Message queue technology should be mature enough and have good references in
production environment.

Queue server and consumers should have easy setup and support.

13. Queues / Service Bus Providers

MSMQ

Custom implementation

NServiceBus

Azure Queues

Rabbit MQ

Active MQ

Azure Service Bus

BizTalk ESB

14. Rabbit MQ

Постановка задач в очередь / Обработка задач

Нотификация о необходимости обновления словарей

Нотификация о необходимости обновления алгоритмов

Текущий статус каждого агента

15. Сценарии использования
очередей

Queues

Publish/Subscribe

Routing

Topics

RPC

16. Queues

Message acknowledgment

Message durability

Fair dispatch

17. Publish/Subscribe

Exchange

18. Routing

19. Topics

20. RPC

21. Performance counters

22. Чего мы не делали
(решив, что нам этого пока что не нужно)

Обновление connection strings системы «на лету» (довольно
сложная схема сделать это надежно)
Мы можем себе позволить постепенно перевести вычислительные
мощности из одного старого логического кластера в другой,
новый.

23. Вопросы. Предложения.
E-mail: baz-val@yandex.ru
FB: https://www.facebook.com/valentin.bazarevsky