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

Валик Базаревский

"Как взвешивание само по себе не уменьшает вес, так и контроль качества сам по себе не улучшает качество"

Доступность

Производительность

Отказоустойчивость

Конфигурируемость

Масштабируемость

Зачем нам это понадобилось:

Тяжело отслеживать состояние всей системы

Тяжело поддерживать и обновлять распределенную систему

Надо знать что из себя представляла система в тот или иной момент времени (как правило когда произошел сбой)

Оптимизация производительности, прогнозирование нагрузок, определение оптимальной конфигурации (разные алгоритмы анализа требуют разных ресурсов)

Политические игры с отделом IT заказчика, в значительной мере усложняющие поиск и раннее выявление проблем на production

Краткое описание системы:

Система анализа качества переводов. 

Есть порядка 10 различных алгоритмов, которые постоянно обновляются.

Сложность (длительность выполнения) алгоритма довольно сложно прогнозируема (по крайней мере нас так заверили).

Task ControllerWeb Service

Task ControllerWeb Service

Task ProcessorWindows Service

Task ProcessorWindows Service

Task ProcessorWindows Service

File StorageNetwork Share

Tasks StorageSQL Database

Tasks QueueMessage queue

Слой данных:

MS SQL

Network Share

Message Queue (Rabbit MQ / Azure Service Bus)

Что мы сделали/делаем:

Единая страничка, проверяющая работоспособность всех элементов системы (как правило такая страничка есть у каждого приложения)

«Центральная" конфигурация (при старте каждый агент скачивает себе все настройки, включая connection string)

Поддержка обновлений (при появлении новых алгоритмов, новых словарей, все агенты получают сообщение, что необходимо обновиться).

Возможность опросить всех агентов об их состоянии (версию алгоритмов, словарей, работает/остановлен и т.д.)

Performance counters для каждого из агентов (ram, io, network, cpu, i.e.), таким образом, мы сможем посмотреть что происходило во время исполнения каждой из задач, если задача выполнялась несколько раз, возможность сравнить показатели)

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

Или так:

«Центральная» конфигурация

Скачать последнюю версию алгоритмов, словарей, актуальные connection strings

Скачивание происходит только на старте нового TaskProcessor-а, в дальнейшем он не зависит от источника конфигурации

Провайдером конфигураций может быть любой из TaskController-ов

Сервисная шина

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

Теоретически можно использовать любой из RPC для опроса агентов, но асинхронная модель предпочтительней.

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.

Queues / Service Bus Providers

MSMQ

Custom implementation

NServiceBus

Azure Queues

Rabbit MQ

Active MQ

Azure Service Bus

BizTalk ESB

Rabbit MQ

Постановка задач в очередь / Обработка задач

Нотификация о необходимости обновления словарей

Нотификация о необходимости обновления алгоритмов

Текущий статус каждого агента

Сценарии использования очередей

Queues

Publish/Subscribe

Routing

Topics

RPC

Queues Message acknowledgment

Message durability

Fair dispatch

Publish/Subscribe

Exchange

Routing

Topics

RPC

Performance counters

Чего мы не делали (решив, что нам этого пока что не нужно)

Обновление connection strings системы «на лету» (довольно сложная схема сделать это надежно)

Мы можем себе позволить постепенно перевести вычислительные мощности из одного старого логического кластера в другой, новый.

Вопросы. Предложения.

E-mail: baz-val@yandex.ru

FB: https://www.facebook.com/valentin.bazarevsky