Доступность IaaS-сервисов: практика OnCloud.ru

Логотип компании
Доступность IaaS-сервисов: практика OnCloud.ru
Доверие заказчика к облачным услугам в первую очередь зависит от стабильности их качества. Один из основных параметров качества – доступность облачных сервисов – определяется, как период времени, когда вычислительные ресурсы работают, производительность этих ресурсов соответствует заявленным параметрам и пользователи имеют доступ к приложениям, размещенным на этих ресурсах.

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

Впервые мы начали работать над задачей измерения доступности сервиса IaaS в 2010-м году, в процессе запуска облака OnCloud.ru. В первой его версии было решено использовать наиболее простой подход – мониторинг доступности гостевых операционных систем (Windows, Uniх и т.п.), которые устанавливались на выделенные заказчикам виртуальные мощности. Виртуальная машина считалась доступной, если была доступна ОС, и эти данные служили основой для ежемесячных отчетов заказчикам.

Недостатки такого метода проявились довольно быстро: сервис IaaS не всегда подразумевает администрирование операционных систем нашими силами – чаще это делается заказчиком и периоды, когда заказчик выключал или перезагружал свою виртуальную машину, попадали в отчет, как время недоступности сервиса. Иногда приходилось даже проводить дополнительные «расследования», анализировать логи, чтобы понять – где наша вина, а где машины останавливались по инициативе заказчика. Заказчика такая ситуация устраивала, так как, если не удается доказать, что причиной простоя машины стала именно его деятельность, то, в соответствии с договором и SLA, штрафы платили мы – поставщик услуги.

Через какое-то время мы пришли к выводу, что надо менять метод измерения доступности IaaS-сервиса. Проведенный анализ рыночной ситуации показал, что практически все облачные провайдеры (как наши, так и зарубежные) оценивают доступность сервиса по доступности гипервизора – среды виртуализации, которая обеспечивает одновременную работу всех виртуальных машин. Этот подход проще и удобнее в реализации: если гипервизор доступен, то доступны все виртуальные машины. Поскольку при использовании серьезных «промышленных» решений сбои в среде виртуализации достаточно редки, доступность в этом случае приближается к 100%.

В результате этот метод, которым и сейчас пользуются многие провайдеры облачных услуг, был внесен нами в SLA. Так как время регламентных работ исключается из отчетов, и за всё время работы был всего один сбой гипервизора, то показатели доступности практически всегда составляли 100%.

Но теперь мы столкнулись с недовольством заказчиков. Если, к примеру, в течение отчетного месяца пропадал интернет-канал или при «перемещении» виртуальной машины с одной СХД на другую имела место «деградация» сервиса по дисковой подсистеме, то заказчик ожидает увидеть эти сбои в отчете в конце месяца. Но в отчете указана доступность гипервизора - 100%, и у заказчика нет формальных оснований для претензий, так как он подписал SLA.

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

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

1. Доступность сети (с учетом провайдера, сетевых карт серверов, маршрутизаторов, коммутаторов, SAN-переключателей и т.д.),

2. Доступность гипервизора, определяющая доступность процессоров и памяти виртуальных машин

3. Доступность СХД (сложный для мониторинга параметр).

Произведение этих трех параметров (доступность сети, гипервизора, СХД) дает нам «интегральный показатель доступности». Его величина всегда ниже, чем доступность каждого элемента, если только каждый из них не равен 100%.

Методика был принята и согласована, и мы перешли к довольно длительной и трудоемкой фазе технической реализации - настройке системы мониторинга так, чтобы она могла измерять доступность трех указанных компонент по всем виртуальным машинам и формировала отчет по каждому заказчику.

Были проведены испытания нескольких вариантов измерения необходимых параметров.

На первом этапе опробовали установку «агентов» в каждую виртуальную машину заказчика. Но в этом варианте много минусов – такую установку надо согласовывать с заказчиком (а это не всегда возможно), заказчик может случайно удалить «агента», также возникают проблемы совместимости с ПО и т.д.

Затем был опробован вариант фиксации сбоя по каждому элементу – например, отсутствие сети в течение какого-то времени. Но и этот вариант не прошел. Сбои отдельных элементов по-разному отражались на разных виртуальных машинах.

После довольно длительного периода экспериментов пришли к решению: вместо контроля доступности виртуальных машин заказчика, можно контролировать доступность виртуальных машин, которыми управляют наши инженеры. В результате в облаке был создан пул управляемых нами «эталонных» виртуальных машин. Они соответствуют основным конфигурациям виртуальных машин заказчиков по операционным системам, настройкам, размерам. Количество этих виртуальных машин может меняться в зависимости от появления новых ВМ заказчиков. В эталонные виртуальные машины устанавливаются «агенты» системы мониторинга, которые ведут сбор статистики по всем показателям доступности, в том числе и по трем основным: сети, гипервизора, СХД.

При сбое в облаке система мониторинга фиксирует недоступность какой-то из эталонных виртуальных машин, и это соответствует недоступности части ВМ заказчика, входящих в пул с эталонной. Исходя из этой статистики и рассчитывается «интегральный показатель доступности», который затем попадает в отчеты заказчику.

Читайте также
Уже в 2023 году около 46% строительных компаний считали цифровизацию приоритетным направлением развития. С 1 июля 2024 года государство обязало девелоперов использовать BIM-модели для проектирования и строительства жилых объектов, а значит таких компаний станет еще больше. У ставших на путь цифровизации компаний есть два основных варианта: разработать собственное IT-решение или воспользоваться готовым продуктом. О плюсах и минусах каждого подхода рассказывает сооснователь цифровой платформы для управления строительством Pragmacore Кирилл Поляков.

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

Хотелось бы отметить, что предлагаемый подход позволяет облачному провайдеру (и – что немаловажно – мотивирует его) обеспечить более высокое качество услуг IaaS, что положительно сказывается на доверии заказчиков к облакам и динамике развития этого сектора рынка услуг ИТ.

Значение доступности сервиса IaaS, которое сегодня используется в типовом SLA, составляет 99,5%. Чтобы заказчик имел возможность сравнить показатели OnCloud.ru с другими сервисами, в описаниях наших услуг также приводятся и показатели доступности по гипервизору («маркетинговая доступность»).

И хотя 99,5% в маркетинговых материалах может выглядеть не очень выразительно, качество реально получаемого заказчиком сервиса выше, чем при 99,9% в случае измерения по доступности гипервизора. 

Опубликовано 16.04.2015

Похожие статьи