Автор: Руслан Киянчук
Цель проекта OpenStack – создать платформу облачных вычислений с открытым кодом, которая будет соответствовать запросам публичных и частных облаков засчет простого развертывания и возможностей масштабирования. Так как OpenStack предоставляет инфраструктуру как услугу (IaaS) конечным клиентам, важно иметь возможность измерить её производительность и использование в целях биллинга, оценки эффективности, масштабируемости и получения статистики.
Для измерения инфраструктуры OpenStack доступны несколько проектов:
• Zabbix – это корпоративное распределенное решение с открытым кодом для мониторинга сети и приложений, которое может быть настроено для использования с OpenStack.
• Synaps– это система мониторинга облака, совместимая с AWS CloudWatch, предназначенная для сбора метрик, предоставления статистики, отслеживания и уведомления о тревожных событиях в системе.
• Healthmon от HP стремится предоставить “Монитор ресурсов облака” — расширяемый сервис мониторинга для инфраструктуры OpenStack.
• StackTach– это утилита для отладки и мониторинга в OpenStack, которая может работать с несколькими ЦОД, в том числе при многоячеечном (multi-cell) развертывании.
• Проект Ceilometer – это инфраструктура для сбора метрик в облаке OpenStack, созданная для избежания разработки многочисленных решений с одинаковыми функциями. Основной целью проекта является мониторинг и измерения, но возможности фреймворка могут быть расширены и для других нужд.
Среди этих проектов наиболее многообещающим и активно развивающимся является Ceilometer, который хорошо подходит для измерений OpenStack инфраструктуры. Проект вышел из стадии инкубации и стал частью OpenStack. В метеорологии облакомер (по-английски — ceilometer) – это устройство, использующее лазер или другой источник света для определения высоты нижней границы облаков. Таким образом, проект Ceilometer — это основа для мониторинга и измерения облака OpenStack. Также проект может быть расширен и для других нужд.
Архитектура проекта OpenStack Ceilometer
Основными целевыми назначениями проекта Ceilometer являются следующие [1]:
•Эффективный сбор метрик с оптимальным расходованием процессорных и сетевых ресурсов.
•Сбор данных путем отслеживания уведомлений от служб или путем опроса инфраструктуры.
•Настройка типа собираемых данных для соответствия различным эксплуатационным требованиям.
•Получение доступа к данным измерений и их добавление с помощью REST API.
•Расширение инфраструктуры для сбора пользовательских метрик с помощью дополнительных плагинов.
•Получение подписанных и неопровержимыхсообщений с результатами измерений.
Для выполнения этих требований в релизе Grizzly реализована следующая архитектура:
Сервер API предоставляет доступ к метрикам в базе данных посредством интерфейса REST API.
Центральный агент (central agent) опрашивает данные по утилизации ресурсов, которые не связаны с виртуальными машинами или вычислительными узлами (compute nodes). В инфраструктуре может быть запущен только один экземпляр центрального агента.
Вычислительный агент (compute agent) опрашивает данные измерений и статистику с вычислительных узлов (в основном, гипервизора). Вычислительные агенты должны быть запущены на каждом вычислительном узле, который необходимо отслеживать.
Коллектор отслеживает очереди сообщений (на предмет уведомлений, которые присылает инфраструктура, и на предмет результатов измерений от агентов). Уведомления обрабатываются, преобразовываются в измерительные данные, затем подписываются и возвращаются на шину передачи сообщений в соответствующую тему. Коллектор может работать на одном или нескольких серверах управления.
Хранилище данных (data store) – это база данных, которая может обрабатывать одновременные запись (с одного или нескольких коллекторов) и чтение данных (с API-сервера). Коллектор, центральный агент и API могут работать на любом узле.
Эти службы сообщаются с помощью стандартной шины передачи сообщений OpenStack. Только коллектор и API-сервер имеют доступ к хранилищу данных. Поддерживаются SQL базы данных совместимые с SQLAlchemy, а также MongoDB и HBase; тем не менее, разработчики Ceilometer рекомендуют MongoDB в связи с эффективной обработкой одновременных операций чтения/записи данных. Кроме того, только конфигурация Ceilometer с MongoDB прошла тщательное тестирование и развертывание в коммерческих средах. Для базы данных Ceilometer рекомендуется использовать выделенный узел, так как инфраструктура может создавать большое количество записей в базу данных [2]. Согласно оценкам разработчиков, измерение инфраструктуры на коммерческом уровне предполагает до 386 записей в секунду и 33 360 480 событий в день, что потребует до 239 Гб для хранения статистики за месяц.
Интеграция связанных проектов в Ceilometer
С развитием проекта OpenStack до коммерческого уровня возникает потребность в новой функциональности для его успешного использования в качестве провайдера облака: биллинговая система, статистика использования, автоматическое масштабирование, оценка эффективности (benchmarking), средства для диагностики и исправления ошибок.После запуска нескольких проектов для удовлетворения данных требований стало очевидно, что большая часть их реализаций имеет общую функциональность мониторинга и измерения инфраструктуры.
Для исключения фрагментации и дублирования функциональности планируется интеграция связанных проектов с целью предоставления другим службам единого интерфейса мониторинга и измерений.
Проект Healthmon было решено интегрировать в Ceilometer по причине одинакового предназначения (измерение инфраструктуры), хотя модель данных и механизмы измерения различались. [4]. Для релиза OpenStack Havana был создан и утвержден проект интеграции Healthmon и Ceilometer. Также, проекты Synaps и StackTach имеют уникальную функциональность, которая интегрируется в Ceilometer в качестве дополнительных функций. Основная причина сохранения проекта Ceilometer и интеграции в него других решений заключается не столько в большом списке возможностей, сколько в модульности и четком определении функциональной задачи. Большинство других аналогичных проектов реализовали ограниченную функциональность измерения и некоторые дополнительные узконаправленные функции. В свою очередь Ceilometer предоставляет полнофункциональную услугу измерения и API-интерфейс для доступа к полученным данным, на основе которых можно построить любую другую функциональность, будь это биллинг, автомасштабирование или мониторинг производительности.
Проект управления облачными приложениями, OpenStack Heat, также планирует модифицировать свою серверверную часть (back-end) обработки измерений и уведомлений для работы с API Ceilometer, что позволит реализовать автомасштабирование [3]. Процесс интеграции включает разработку API для уведомлений и возможность отсылать образцы измерений посредством REST-запросов к Ceilometer, а также переработку Heat для возможности модульного подключения логики измерений.
Интеграция расширит интерфейс Ceilometer дополнительными функциями и плагинами, что приведет к следующим изменениям в архитектуре [5]:
Большинство работ по интеграции и реализации дополнительных функций запланированы на релиз OpenStack Havana. В основной план реализации входит покрытие большинства функциональностей измерения и мониторинга, а также предоставление возможности построения других услуг (интерфейс командной строки, графический интерфейс, визуализация, исполнение функции будильника и т.п.) вокруг API Ceilometer.
Измерения в Ceilometer
В проекте Ceilometer реализованы три типа измерений:
•Cumulative (кумулятивные): увеличение со временем (например, время существования виртуальной машины)
•Gauge (индикатор): дискретные события (например, плавающие IP-адреса или загрузки образов) и изменяющиеся значения (как например ввод-вывод диска)
•Delta (дельта): изменение со временем (например, пропускная способность сети)
Каждый измеритель собирает данные с одного или нескольких образцов (собираемых из очереди сообщений или агентами), которые представлены счетчиками. Каждый счетчик имеет следующие поля:
– counter_name
Строка идентификатора счетчика. По принятому соглашению разделитель ‘.’ используется для перехода от наименее конкретного слова к наиболее конкретному (например, disk.ephemeral.size).
– counter_type
Один из типов счетчиков, описанных выше (кумулятивный, индикатор, дельта).
– counter_volume
Количество измеряемых данных (такты ЦП, число байт, переданных по сети, время развертывания виртуальной машины и т.п.). Это поле несущественно для счетчиков типа индикатор; в этом случае ему должно быть присвоено значение по умолчанию (обычно: 1).
– counter_unit
Описание единицы измерения счетчика. Для обозначения используются единицы измерения системы СИ и их утвержденные сокращения. Количество информации должно выражаться в битах (‘б’) или байтах (‘Б’). Когда измерение представляет собой не количество данных, описание всегда должно содержать точную информацию, что измеряется (виртуальные машины, образы, плавающие IP-адреса и т.п.).
– resource_id
Идентификатор измеряемого ресурса (UUID виртуальной машины, сеть, образ и т.п.).
– project_id
Идентификатор проекта, которому принадлежит ресурс.
– user_id
Идентификатор пользователя, которому принадлежит ресурс.
– resource_metadata
Некоторые дополнительные метаданные из информационного наполнения сообщения об измерении.
Полный список предоставляемых на данный момент измерений можно найти в документации OpenStack Ceilometer [6].
Функциональность Ceilometer
В связи с активным развитием Ceilometer и его интеграцией с другими проектами для релиза OpenStack Havana запланировано много дополнительных функций. Функциональность Ceilometer (реализованная или запланированная на ближайший релиз) описана ниже [7].
Отправка образцов измерений с помощью REST API
Реализация этой функции позволяет отправлять данные измерений с помощью интерфейса Ceilometer REST API v2. Список отсылаемых счетчиков должен быть определен в формате JSON и отправлен в виде POST-запроса на url-адрес http://<metering_host>:8777/v2/meters/<meter_id> (название счетчика соотносится с идентификатором измерителя). Например:
[
{
«counter_name»: «instance»,
«counter_type»: «gauge»,
«counter_unit»: «instance»,
«counter_volume»: «1»,
«resource_id»: «bd9431c1-8d69-4ad3-803a-8d4a6b89fd36»,
«project_id»: «35b17138-b364-4e6a-a131-8f3099c5be68»,
«user_id»: «efd87807-12d2-4b38-9c70-5f5c2ac427ff»,
«resource_metadata»: {
«name1»: «value1»,
«name2»: «value2»
}
}
]
Это позволяет сторонним программам с легкостью отправлять данные измерений в Ceilometer.
Интерфейс уведомлений в Ceilometer
Уведомления позволяют отслеживать состояние счетчика и сообщать после достижения им порогового значения. Эта функциональность позволит построить множество возможностей на основе Ceilometer, таких как автомасштабирование, диагностика и исправление ошибок и многих других действий в инфраструктуре. Соответствующий план реализации интерфейса уведомлений одобрен с высоким приоритетом и запланирован на релиз Havana.
Расширение интерфейса Ceilometer
Интерфейс Ceilometer API будет дополнен для предоставления дополнительной функциональности, которая необходима для биллинговых движков, например:
•Максимальное использование ресурса длительностью более 1 часа;
•Статистика использования ресурса в течение времени;
•Предоставление дополнительной статистики (стандартное отклонение, медиана, дисперсия, распределение и т.п.).
Соответствующий план утвержден и запланирован на релиз Havana-2.
Измерение пропускной способности в Quantum
Проект Ceilometer будет дополнен вычислением пропускной способности сети с помощью Quantum. План измерения пропускной способности Quantumутвержден со средним приоритетом на релиз Havana-3.
Мониторинг физических устройств
Ceilometer будет отслеживать физические устройства в инфраструктуре OpenStack, в том числе физические сервера, на которых запущены Glance, Cinder, Quantum, Swift, вычислительные узлы и контроллеры Nova, а также сетевые устройства, использующиеся в среде OpenStack (коммутаторы, сетевые экраны). План мониторинга физических устройств утвержден на релиз Havana-2 и его реализация уже находится на стадии верификации кода.
Расширение функций Ceilometer
Проект Ceilometer предполагает простое расширение и настройку с индивидуальной подгонкой для каждой инсталляции. Система плагинов на основе точек входа в инструменты настройки предоставляет возможность добавлять новые мониторы в коллектор или субагенты для опроса. Система плагинов, основанная на точках входа setuptools, предоставляет возможность добавлять новые мониторы в коллектор или агенты опроса.
Предусмотрено два типа плагинов: опросники (pollesters) и слушатели (listeners). Слушатели обрабатывают уведомления, созданные и помещенные в очередь сообщений компонентами OpenStack, для создания соответствующих объектов-счетчиков. Опросники используются для выборочного опроса инфраструктуры по метрикам, уведомления для которых не помещаются в очередь сообщений компонентами OpenStack. Все плагины настраиваются в файле setup.cfg в секции [entry_points]. Например, для включения пользовательских плагинов, размещенных в директории ceilometer/plugins и определенных как классы MyCustomListener и MyCustomPollster, необходимо настроить файл setup.cfg следующим образом:
[entry_points]
ceilometer.collector =
custom_listener = ceilometer.plugins:MyCustomListener
…
ceilometer.poll.central =
custom_pollster = ceilometer.plugins:MyCustomPollster
…
Цель плагинов-опросников — получать необходимые результаты измерений от инфраструктуры облака и создавать из них объекты-счетчики. Плагины для центрального агента определяются в пространстве имен ceilometer.poll.central точек входа setup.cfg, а для вычислительных агентов — в пространстве имен ceilometer.poll.compute. Плагины-слушатели загружаются из секции ceilometer.collector.
Сердцем системы является коллектор, который отслеживает шину передачи сообщений на предмет данных, предоставленных опросниками, а также уведомлений от других компонентов OpenStack, таких как Nova, Glance, Quantum и Swift.
Класс типичного плагина-слушателя должен иметь несколько методов приема определенных уведомлений из очереди сообщений и создания из них счетчиков. Метод get_event_types() должна возвращать список строк, содержащих типы событий, в которых заинтересован плагин. Эти события передаются плагину каждый раз при получении соответствующего уведомления. Метод notification_to_metadata() отвечает за обработку уведомлений и создание метаданных, которые будут включены в измерительные сообщения, доступ к которым будет предоставлен через Ceilometer API. Метод process_notification() определяет логику создания счетчика на основе данных из полученных уведомлений. Этот метод может также вернуть пустой список, если в текущем уведомлении не было найдено подходящих данных измерений. Счетчики создаются конструктором ceilometer.counter.Counter(), который принимает значения обязательных полей счетчика (см. Измерения в Ceilometer). Измерители предоставляемые Ceilometer по умолчанию также реализованы как плагины и могут использоваться в качестве вспомогательной информации для создания дополнительных плагинов.
Заключение
Ceilometer – это многообещающий проект, разработанный для предоставления обширных возможностей измерения и мониторинга облачной инфраструктуры, реализующий функциональность, которая необходима для коммерческого использования OpenStack. Хотя уже есть случаи коммерческого применения Ceilometer (CloudWatch, AT&T, Dreamhost[5]), к октябрю 2013 года в проект добавится много изменений и дополнительных функций. Таким образом проект Ceilometer должен стать гораздо более приспособленным к коммерческому использованию с релизом Havana, на который запланирована реализация основных изменений и нового функционала.
Оригинал статьи на английском языке
Автор: Mirantis_OpenStack
