Контроль потребления и мониторинг облачных служб

Завершено

Поставщики облачных служб выставляют клиентам счета за использование своих служб. Для этого поставщики должны тщательно отслеживать использование своих служб и включать затраты на выполнение этих служб в своей инфраструктуре. Это является критически важным для поставщиков облачных служб и их клиентов.

Регулярное поступление доходов поставщика облачных служб зависит от правильности контроля потребления и отслеживания ресурсов. Потеря данных об использовании ресурсов за пару часов может стоить поставщику облачных служб миллионы долларов. С другой стороны, взимание с клиентов платы за пару лишних часов может сильно подорвать репутацию организации.

С точки зрения клиентов стоимость облачных ресурсов является важной частью их расходов. Чтобы облачные клиенты могли составлять бюджетные планы, они должны получать согласованные счета каждый месяц. Это ставит перед поставщиками облачных служб важные задачи по контролю потребления и мониторингу.

Проблемы с контролем потребления и мониторингом

В состав облачных ресурсов включены различные расходы. Фиксированные затраты, такие как помещение, сотрудники и серверы, легко вычислить. Однако для переменных затрат требуется обеспечить постоянный контроль потребления и мониторинг. Преимущества обращения к поставщику облачных служб заключаются в том, чтобы оплачивать только используемые ресурсы. Например, подготовка экземпляра виртуальной машины включает в себя стоимость использования экземпляра в час, места для хранения (ГБ в месяц) для каждого типа хранилища, а также передачи данных (ГБ в месяц). Даже для одного такого ресурса поставщик облачных служб должен отслеживать эти метрики для каждого экземпляра и подключенного тома. На рис. 3 приведена возможная декомпозиция различных затрат на службы. Если мы представим, что это требуется осуществлять у более чем 1 000 000 облачных клиентов для десятков разных типов служб, потребуется ежесекундно анализировать гигабайты журналов для контроля потребления и мониторинга и соответствующим образом взимать плату с клиентов. Самая популярная модель, используемая для определения таких метрик, называется моделью взимания средств за использование.

Metering in different types of cloud services.

Рис. 3. Контроль потребления в облачных службах разных типов

Модель взимания средств за использование

Модель взимания средств за использование определяет способность ИТ-организации измерять использование ресурсов и взимать с клиентов соответствующую плату. Традиционно такая модель проста в реализации, так как ИТ-отдел может легко разделить свой бюджет для каждого обслуживаемого им подразделения (лицензии на программное обеспечение, автономные серверы и т. п.). Однако ее сложно реализовать для облачных вычислений, так как поставщику облачных служб необходимо учитывать скорость и время потребления.

Проверка для контроля потребления и мониторинга

С точки зрения клиента проверяемый контроль потребления является важной проблемой. Существует ряд затрат, которые легко измерить, например использование виртуальной машины (почасовое использование * стоимость за час), но клиентам трудно измерять другие ресурсы, такие как переходы по данным или запросы ввода-вывода. Чтобы проверить контроль потребления и мониторинг, пользователи могут работать с сертифицированными поставщиками облачных служб. Например, программа Resilient Cloud Validation компании IBM позволяет организациям, которые сотрудничают с IBM, использовать единообразную программу тестирования производительности и проверки облачных служб.

Пример использования: Ceilometer

Хотя корпоративные поставщики облачных служб скрывают базовую архитектуру контроля потребления и измерения, решение Ceilometer предназначено для контроля потребления, выставления счетов и оценки в OpenStack. Высокоуровневую архитектуру OpenStack Ceilometer можно обобщить следующим образом (рис. 4).

Ceilometer architecture.

Рис. 4. Архитектура Ceilometer

Агент опросов. Управляющая программа, которая опрашивает службы OpenStack для контроля потребления.

Агент уведомлений. Управляющая программа, которая прослушивает уведомления в очереди сообщений и преобразует их в примеры и события.

Сборщик. Управляющая программа, предназначенная для сбора данных метрик, создаваемых агентами уведомлений и опросов.

API. Служба для запроса данных, зарегистрированных сборщиком.

Предупреждения. Управляющие программы для оценки и активации уведомлений на основе предопределенных правил.

Каждая из этих служб предназначена для горизонтального масштабирования. В соответствии с ожидаемой нагрузкой можно добавить дополнительные рабочие роли и узлы.

Проверьте свои знания

1.

Какие из следующих аспектов службе Azure не требуется отслеживать, чтобы иметь возможность точно выставлять счета пользователям?