Upload
valentin-bazarevsky
View
141
Download
0
Embed Size (px)
Citation preview
Разработка средств управления и мониторинга распределенной мультиагентной системы
Валик Базаревский
"Как взвешивание само по себе не уменьшает вес, так и контроль качества сам по себе не улучшает качество"
Доступность
Производительность
Отказоустойчивость
Конфигурируемость
Масштабируемость
Зачем нам это понадобилось:
Тяжело отслеживать состояние всей системы
Тяжело поддерживать и обновлять распределенную систему
Надо знать что из себя представляла система в тот или иной момент времени (как правило когда произошел сбой)
Оптимизация производительности, прогнозирование нагрузок, определение оптимальной конфигурации (разные алгоритмы анализа требуют разных ресурсов)
Политические игры с отделом 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 системы «на лету» (довольно сложная схема сделать это надежно)
Мы можем себе позволить постепенно перевести вычислительные мощности из одного старого логического кластера в другой, новый.