Page 1

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


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

Доступность

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

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

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

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


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

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

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

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

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

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


Краткое описание системы: Система анализа качества переводов. Есть порядка 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


Слой данных: 

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

Доклад разработка средств управления и мониторинга распределенной мультиагентной системы 2  
Read more
Read more
Similar to
Popular now
Just for you