Наши партнеры

UnixForum





Библиотека сайта rus-linux.net

Применение принципов оптимизации к средствам компонентного развертывания и конфигурирования систем

Глава 6 из книги "Производительность приложений с открытым исходным кодом".
Оригинал: Applying Optimization Principle Patterns to Component Deployment and Configuration Tools,
Авторы: Doug C. Schmidt, William R. Otte, and Aniruddha Gokhal
Дата публикации: 2013 г.
Перевод: Н.Ромоданов
Дата перевода: март 2014 г.

Введение

Распределенные встроенные системы реального времени (Distributed, real-time and embedded - DRE) являются важным классом приложений, которые одновременно обладают свойствами как корпоративных распределенных систем, так и встроенных систем реального времени, имеющих ограниченные ресурсы. В частности, приложения в системах DRE аналогичны корпоративным приложениям, то есть, они являются распределенными в большом домене. Более того, точно также, как и в системах реального времени и во встраиваемых системах, приложения в системах DRE часто являются критически важными и отвечают требованиям повышенной безопасности, надежности и качеством обслуживания (quality of service - QoS).

Кроме той сложности, о которой сказано выше, процесс развертывания приложения и компоненты инфраструктуры в системах DRE обладают своими собственными уникальными особенностями. Во-первых, приложения в доменах систем DRE могут иметь конкретные зависимости от целевой среды, например, от конкретного аппаратного/программного обеспечения (например, GPS, датчиков, приводов, конкретных операционных систем реального времени и т.д.). Во-вторых, инфраструктура развертывания системы DRE должна считаться с жесткими требованиями на ресурсы в средах с ограниченными ресурсами (например, мощностью процессора, размера памяти, пропускной способности сети и т.д.).

Программные инженерные решения, базирующиеся на использовании компонентов (Component-Based Software Engineering — CBSE) [1] все чаще используются в качестве парадигмы разработки приложений как в корпоративных системах [2], так и системах DRE [3]. Парадигма CBSE облегчает систематическое повторное использование программного облегчения за счет того, что поощряет разработчикам создавать компоненты вида «черный ящик», которые взаимодействуют друг с другом и окружающей их среды через хорошо определенные интерфейсы. Парадигма CBSE также упрощает развертывание очень сложных распределенных систем [4], предоставляя стандартные механизмы управления конфигурацией и жизненным циклом приложений. Эти механизмы позволяют составлять крупномасштабные сложные приложения из гораздо меньших более управляемых единиц функциональности, например, из уже готовых коммерческих компонентов и из строительных-блоков уже существующих приложений. Такие приложения можно компоновать в пакет вместе с описательными и конфигурационными метаданными, и сделать доступными для развертывания в условиях производства.

Опираясь на опыт, почерпнутый из разработки ACE ORB (TAO) [5] — реализации стандарта Common Object Request Broker Architecture (CORBA) с открытым исходным кодом, мы в течение последнего десятилетия применяли принципы CBSE для систем DRE. В результате этих усилий мы разработали высококачественную реализацию компонентной модели с открытым исходным кодом OMG CORBA Component Model (CCM), которую мы называем Component Integrated ACE ORB (CIAO) [6]. В CIAO реализована так называемая легковесная спецификация CCM [7], которая является подмножеством полного стандарта CCM, предназначенная для систем DRE с ограниченными ресурсами.

В контексте нашей работы по применению принципов CBSE к системам DRE, мы также изучали столь же сложную проблему, которая упрощает в таких доменах развертывание и настройку систем, базирующихся на использовании компонентов. Управление развертыванием и настройкой приложений, базирующихся на компонентах, является сложной задачей по следующим причинам:

  • Зависимость от компонентов и управление версиями. К отдельным компонентам могут предъявляться сложные требования и между ними могут быть взаимосвязи. Для правильной работы компоненты могут быть взаимозависимыми или могут в частности требовать определенные версии. Если эти взаимосвязи не описаны и но требуются, компонентные приложения могут не разворачиваться правильно; и, что еще хуже, могут неправильно работать в редких и в исключительных ситуациях.
  • Управление конфигурацией компонентов. Компонент может использовать специальные конфигурируемые подключения, которые меняют свое поведение, а в инфраструктуре развертывания требуется управлять и пользоваться всей необходимой конфигурационной информацией. Более того, несколько компонентов при развертывании могут иметь взаимосвязанные конфигурационные настройки, а инфраструктура развертывания должна обеспечивать, чтобы эти свойства оставались неизменными во всем приложении.
  • Распределенное подключение и управление жизненным циклом. В случае корпоративных систем, компоненты должны устанавливаться, подключаться и активироваться на удаленных хостах.

Для решения проблем, изложенных выше, мы в 2005 году начали разработку движка реализации CIAO, предназначенного для развертывания приложений. Этот инструмент, который мы называем движком развертывания и настройки Deployment and Configuration Engine (DAnCE) [8], является реализацией спецификаций OMG Deployment and Configuration (D&C) [9]. В течение большей части своей истории движок DanCE применялся, главным образом, в качестве исследовательского инструмента для аспирантов, разрабатывающих новые подходы к развертыванию и конфигурированию, что вылилось при его реализации в два важных последствия:

  • Ход разработки движка DAnCE, как исследовательского средства, в значительной степени обусловливался задачами, связанными с публикациями статей и необходимостью демонстрации спонсорам его возможностей. В итоге проверенные варианты его использования были сравнительно простыми и узконаправленными.
  • По мере того, как завершались одни научно-исследовательские проекты и начинались новые, несколько раз менялось отношение к проекту DAnCE. И, как результат, часто отсутствовало единое архитектурное видение всей инфраструктуры.

Эти два фактора несколькими способами повлияли на проект DAnCE. Например, узость и сфокусированность на практику часто при развертывании реальных приложений делало оценку общей производительности низкоприоритетной. Кроме того, отсутствие единого архитектурного видения в сочетании с жесткими ограничениями по срокам часто означало, что во имя сиюминутной целесообразности были выбраны, а позднее не были устранены слабые архитектурные решения. Эти проблемы оказались в центре внимания, когда мы начали работать с нашими коммерческими спонсорами с целью применить DAnCE к крупномасштабным развертыванием компонентов, численностью от сотен и до тысяч компонентов на десятках и сотнях аппаратных узлов. Хотя в случае меньших масштабов сфокусированность на практику позволяла иметь приемлемые сроки развертывания, такие крупные развертывания компонентов выполнялись неприемлемо долгое времени, порядка часа или более до полного завершения.

Таблица 6.1 Список принципов оптимизации и их использование в сетях [10]

НазваниеПринципИспользование в сетях
Avoiding Waste — Избегайте излишних затратИзбегайте очевидных излишних затратМетодика отказа от копирования zero-copy [11]
Shifting in Time - Сдвиг операций по времениСдвиг вычислений во времени (предварительные вычисления, ленивые вычисления, распределение затрат, дозирование действий)Копирование при записи [12] [13] , интегрированный слой обработки [13]
Relaxing Specifications — Ослабление спецификацийОслабление спецификации (временный компромисс с определенностью действий, временный компромисс по точности и сдвиг вычислений по времени) Справедливая очередь [14], фрагментация IPv6
Leveraging other Components — Балансировка межкомпонентной нагрузкиИспользование других компонентов системы (локальная обработка, затраты памяти для увеличения скорости, использование аппаратных возможностей) Алгоритм Lulea поиска IP [15], контрольная сумма TCP
Adding Hardware — Добавление аппаратных возможностейДобавление аппаратных возможностей для повышения производительности Конвейерный поиск IP [16], счетчики
Efficient Routines — Эффективные процедурыСоздание эффективных процедур Поиск UDP
Avoiding Generality — Избегайте обобщенийИзбегайте ненужных обобщений Fbufs [17]
Specification vs Implementation — Спецификация или реализацияНе смешивайте спецификации и реализациюUpcalls [18]
Passing Hints — Передача компактных сообщенийПередавайте в интерфейсах информацию в компактном виде Пакетные фильтры [19] [20] [21]
Passing Information — Передача информацииПередайте информацию в заголовках протоколов Переключение с использованием тегов [22]
Expected Use Case — Предполагаемый вариант использованияОптимизируйте предполагаемый вариант использованияПредсказание заголовков [23]
Exploiting State — Использование состоянийДобавьте и используйте состояния для увеличения скорости работыСписок активных VC
Degrees of Freedom — Степени свободыОптимизируйте степени свободы Поиск истинного IP [24]
Exploit Finite Universes — Использование конечного числа элементовИспользуйте специальные методики, предназначенные для универсумов с конечным числом элементовВременные колеса [25]
Efficient Data Structures — Эффективные структуры данныхИспользуйте эффективные структуры данных Переключение Level-4

В качестве реакции на эти проблемы, мы предприняли усилия с целью всесторонней оценки архитектуры проекта DAnCE, его структуры и его реализации, а также создали новую реализацию, которую мы называем Locality-Enabled DAnCE (LE-DAnCE) [26] [27]. В этой главе описываются принципы оптимизации, составляющие ядро LE-DAnCE, которые позволяют использовать его с системами DRE. В таблице 6.1 приведен общий список принципов оптимизации [10], многие из которых мы применили в LE-DAnCE Дополнительной целью данной статьи было дополнить этот список новыми принципами оптимизации, которые мы сформулировали при работе с нашей реализацией LE-DAnCE.

Оставшаяся часть данной главы организована следующим образом: в разделе «Обзор реализации DanCE» представлен обзор спецификации OMG D&C; в разделе «Применение принципов оптимизации к DanCE» рассказывается о наиболее значимых источниках проблем с производительностью, возникающих в DAnCE (анализ XML и получение информации о развертывании компонентов, анализ информации о развертывании компонентов времени выполнения, и последовательное выполнение отдельных шагов развертывания компонентов), и их использование в качестве средства изучения принципов оптимизации, которые (1), как правило, применяются в системах DRE и (2) которые мы применили в LE-DAnCE; и раздел «Заключение», в котором представлены заключительные замечания.


Продолжение статьи: Обзор реализации DAnCE.