В OVH наша первая задача как поставщика облачных услуг — предоставлять продукты с высоким качеством обслуживания (QoS). Будь то выделенные серверы, облачные серверы или размещенные веб-сайты, наши клиенты ожидают от наших решений очень высокого качества. И это именно то, что наши команды стараются предложить вам ежедневно!

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

Итак, как мы можем количественно оценить это качество обслуживания? Как мы понимаем качество, обеспечиваемое каждым продуктом каждый день, с максимальной точностью?

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

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

Чтобы быть максимально прозрачными, мы также решили объяснить и обосновать наши методы расчета. Вот почему мы решили сделать DepC открытым. Вы можете найти его на Github.

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

Что такое QoS?

Прежде всего, важно определить точный характер того, что мы хотим вычислить. QoS описывает состояние системы. Это может быть услуга (например, поддержка клиентов, время ожидания в кассе…), эксплуатация продукта (например, жизненный цикл посудомоечной машины) или сложные системы (например, инфраструктура веб-сайта).

Это состояние здоровья очень субъективно и будет различаться для каждого случая, но, как правило, оно будет основываться на вероятности того, что пользователь получит пользу от услуги в хороших условиях. В нашем случае хорошие условия означают как доступность услуги (т.е. инфраструктура работает), так и ее общее состояние (т.е. инфраструктура реагирует правильно).

QoS выражается в процентах, начиная со 100%, когда обслуживание выполняется идеально, а затем постепенно уменьшается в случае сбоя. Этот процент должен быть связан с периодом: месяц, день, время и т. Д. Таким образом, сервис может иметь 99,995% QoS в текущий день, тогда как накануне оно было 100%.

Важны и другие концепции:

• SLA (соглашение об уровне обслуживания) : не путать с QoS, это договор между заказчиком и поставщиком, указывающий на ожидаемое качество обслуживания. Этот контракт может включать штрафы, предоставленные заказчику в случае невыполнения целей.
• SLO (цель уровня обслуживания) : это относится к цели, которую поставщик услуг хочет достичь с точки зрения QoS.
• SLI (индикатор уровня обслуживания) : это мера (время отклика ping, код состояния HTTP, задержка сети ...), используемая для оценки качества обслуживания. SLI лежат в основе DepC, поскольку они позволяют нам преобразовывать необработанные данные в QoS.

Цели

DepC изначально был создан для команды WebHosting. 5 миллионов веб-сайтов, распределенных на более чем 14 000 серверов, инфраструктура, необходимая для работы веб-сайтов (описанная в этой статье ), а также постоянные изменения затрудняют расчет качества обслуживания в реальном времени для каждого из наших клиентов.. Кроме того, чтобы идентифицировать проблему в прошлом, нам также нужно было знать, как восстановить QoS, чтобы отразить состояние инфраструктуры в то время.

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

Но как мы можем измерить состояние здоровья каждого из веб-сайтов наших клиентов? Наша первая идея заключалась в том, чтобы запросить их один за другим, проанализировать HTTP-код ответа и на основе этого определить состояние веб-сайта. К сожалению, этот сценарий оказалось сложно реализовать по нескольким причинам:

• Команда WebHosting управляет миллионами веб-сайтов, поэтому масштабирование было бы очень трудным.
• Мы не единственные гаранты правильного функционирования веб-сайтов. Это также зависит от клиента, который может (намеренно или нет) генерировать ошибки, которые будут интерпретированы как ложные срабатывания.
• Даже если бы мы решили предыдущие трудности и можно было бы рассчитать QoS веб-сайтов, было бы невозможно определить первопричины в случае сбоя.

Нам нужно было найти другое решение…

График зависимостей

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

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

1. Исходный код ваших веб-сайтов размещен на серверах хранения (называемых filerz ).
2. Базы данных, используемые сайтом, также размещены на серверах баз данных .

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



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

Этот пример намеренно упрощен, поскольку зависимости наших клиентов, конечно, гораздо более многочисленны (веб-серверы, почтовые серверы, балансировщики нагрузки и т. Д.), Даже без учета всех мер безопасности, принятых для снижения этих рисков сбоя.

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

Однако создание дерева зависимостей (узлов и их отношений) не требует от нас знания Neo4j, потому что мы разработали демон, который позволяет нам преобразовывать сообщения JSON в узлы на графе. DepC предоставляет API, так что каждая команда может добавлять новые элементы в свое дерево зависимостей, не изучая Cypher.

Принцип такой:

1. Пользователи DepC отправляют сообщение JSON в потоке данных Kafka . Это сообщение указывает, какие новые узлы должны быть созданы, а также их взаимосвязь (например, узел веб-сайта, подключенный к анодному фильтру ). Все узлы и отношения содержат временную информацию, которая помогает поддерживать изменения инфраструктуры с течением времени.
2. DepC анализирует эти сообщения, а затем обновляет график зависимостей в реальном времени.

Поскольку DepC доступен на Github, документация по этой части доступна в этом руководстве.

Расчет QoS

Платформа DepC предлагает API для хранения и запроса дерева зависимостей. Это может показаться тривиальным, но постоянное наблюдение за инфраструктурой — уже сложная задача. Это настолько мощно, что некоторые команды используют только эту часть платформы, используя DepC как эквивалент своей CMDB (инвентаризация своего технического парка).

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

• Узел представляет собой элемент, контролируемый одним или несколькими датчиками.
• Целевой узел не является контролируемым элементом

Контролируемые узлы

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

Здесь мы находим концепцию SLI, которую мы видели выше: DepC анализирует необработанные данные, отправленные зондами, чтобы преобразовать их в QoS.

Принцип очень простой:

• Пользователи объявляют индикаторы в DepC, определяя запрос на получение данных из базы данных временных рядов, а также порог, который подразумевает снижение QoS для этого узла.
• DepC запускает этот запрос для всех узлов, выбранных пользователем, затем каждый результат анализируется, чтобы вычислить QoS, как только пороговое значение будет превышено. Затем мы получаем QoS данного узла. Обратите внимание, что этот процесс выполняется каждую ночь благодаря инструменту планирования задач Airflow .

Технически анализ временных рядов DepC — это просто преобразование отсортированного по времени списка значений в отсортированный по времени список логических значений.



В этом случае расчет очень прост: значение «истина» увеличит QoS, а значение «ложь» - снизит его. Например, из 100 точек, когда 95 баллов ниже порогового значения ( верно ), QoS будет 95% (DepC запускает этот расчет каждую ночь; количество точек данных на самом деле намного выше).
Обратите внимание, что для завершения этой части DepC в настоящее время поддерживает базы данных временных рядов OpenTSDB и Warp10. Скоро будут добавлены другие базы данных временных рядов (InfluxDB, Prometheus…).

Неконтролируемые узлы

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

Представьте себе, например, узел, представляющий «клиента», связанный с несколькими контролируемыми узлами типа «сервер». У нас нет данных для анализа по этому клиенту. С другой стороны, для «серверных» узлов мы можем рассчитать их QoS благодаря наблюдаемым узлам. Затем мы объединяем эти показатели QoS, чтобы получить значение «клиентского» узла.

Для этого DepC вычисляет QoS отслеживаемых узлов, получая таким образом список логических значений. Затем между этими разными списками (по зависимости) применяется логическая операция И, чтобы получить уникальный список логических значений. Этот список затем используется для расчета QoS нашего неконтролируемого узла.




Затем вычисление выполняется таким же образом, как и для контролируемых узлов, с учетом количества «истинных» случаев по отношению к общему количеству точек.

В этом примере мы использовали только логический оператор. Однако DepC предоставляет несколько типов логических операций для разных приложений:

• И : все зависимости должны работать, чтобы услуга была предоставлена.
• ИЛИ : для оказания услуги достаточно одной зависимости.
• СООТНОШЕНИЕ (N) : необходимо, чтобы N% зависимостей работали для предоставления услуги.
• ATLEAST (N) : независимо от количества зависимостей, услуга предоставляется, если функционируют как минимум N зависимостей.

Мы не будем слишком углубляться во внутреннее функционирование, которое позволяет нам рассчитывать QoS в больших масштабах. Но если вас это интересует, я приглашаю вас посмотреть конференцию, которую мы провели на FOSDEM 2019 в Python devroom. Видео и слайды доступны по этому адресу .

Вывод

DepC уже используется десятками команд в OVH. Выбранная архитектура позволяет нам предлагать визуализацию QoS через встроенный веб-интерфейс с самим DepC или депортировать дисплей в Grafana.


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



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

Наша цель — стать стандартным решением для расчета QoS в OVH. Инструмент находится в производстве несколько месяцев, и мы получаем тысячи новых узлов в день. В нашей базе данных сейчас более 10 миллионов, и это только начало.

И, конечно же, если вы хотите протестировать или развернуть DepC дома, не сомневайтесь. Это открытый исходный код, и мы всегда в вашем распоряжении, если у вас есть вопросы или идеи по улучшению!

Ссылки

• Github: https://github.com/ovh/depc
• Документация: https://ovh.github.io/depc/
• Презентация FOSDEM 2019 (EN): https://fosdem.org/2019/schedule/event/python_compute_qos_of_your_infrastructure/
• Презентация PyconFR 2018 (FR): https://pyvideo.org/pycon-fr-2018/calculer-la-qos-de-vos-infrastructures-avec-asyncio.html