Измерения в OpenStack с использованием Ceilometer

    Автор: Руслан Киянчук

    Цель проекта 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 реализована следующая архитектура:

    image

    Сервер 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]:
    image

    Большинство работ по интеграции и реализации дополнительных функций запланированы на релиз OpenStack Havana. В основной план реализации входит покрытие большинства функциональностей измерения и мониторинга, а также предоставление возможности построения других услуг (интерфейс командной строки, графический интерфейс, визуализация, исполнение функции будильника и т.п.) вокруг API Ceilometer.

    image

    Измерения в 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
    58,00
    Компания
    Поделиться публикацией

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое