Оповещение на основе сбора данных IPMI

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

Мы начали с разделения проблемы на четыре основных этапа:

• Сбор информации
• Хранилище данных
• Аналитика данных
• Визуализация / действия
• Сбор информации

Как мы собирали огромные объемы данных о работоспособности сервера ненавязчивым образом за короткие промежутки времени?


Какие данные собирать?
На современных серверах BMC (Board Management Controller) позволяет нам контролировать обновления прошивки, перезагрузки и т. Д. Этот контроллер не зависит от системы, работающей на сервере. Кроме того, BMC дает нам доступ к датчикам для всех компонентов материнской платы через шину I2C. Протокол, используемый для связи с BMC, является протоколом IPMI, доступным через LAN (RMCP).

Что такое IPMI?

• Интеллектуальный интерфейс управления платформой.
• Возможности управления и мониторинга независимо от операционной системы хоста.
• Под руководством INTEL, впервые опубликована в 1998 году.
• Поддерживается более чем 200 поставщиками компьютерных систем, такими как Cisco, DELL, HP, Intel, SuperMicro

Зачем использовать IPMI?

• Доступ к аппаратным датчикам (температура процессора, температура памяти, состояние шасси, питание и тд.)
• Нет зависимости от ОС (то есть решение без агента)
• Функции IPMI, доступные после сбоя ОС / системы
• Ограниченный доступ к функциям IPMI через пользовательские привилегии

Сбор данных из нескольких источников
Нам требовался масштабируемый и быстро реагирующий инструмент для сбора данных из нескольких источников, который собирал данные IPMI около 400 тыс. Серверов через фиксированные интервалы.


Akka Мы решили построить наш сборщик данных IPMI на платформе Akka. Akka — это инструментарий с открытым исходным кодом и среда выполнения, упрощающая создание параллельных и распределенных приложений на JVM.

Каркас Akka определяет построенную выше нить абстракцию под названием «актер». Этот субъект является объектом, который обрабатывает сообщения. Эта абстракция облегчает создание многопоточных приложений, поэтому нет необходимости бороться с тупиком. Выбрав политику диспетчера для группы участников, вы можете настроить приложение так, чтобы оно полностью реагировало и адаптировалось к нагрузке. Таким образом, мы смогли спроектировать эффективный сборщик данных, который мог бы адаптироваться к нагрузке, поскольку мы собирались собирать значения каждого датчика каждую минуту.

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

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

API REST определен для связи со сборщиком данных двумя способами:

• Чтобы отправить конфигурации
• Получить информацию о контролируемых серверах

Узел кластера работает на одной JVM, и мы можем запустить один или несколько узлов на выделенном сервере. Каждый выделенный сервер, используемый в кластере, помещается в VRAC OVH. Пул шлюза IPMI используется для доступа к BMC каждого сервера, а связь между шлюзом и сборщиком данных IPMI защищена соединениями IPSEC.



Хранилище данных
Метрики OVH Конечно, мы используем сервис метрик OVH для хранения данных! Перед сохранением данных сборщик данных IPMI объединяет метрики, квалифицируя каждый датчик. Окончательное имя метрики определяется объектом, которому принадлежит датчик, и базовой единицей значения. Это облегчит процессы последующей обработки и визуализации / сравнения данных.

Каждый коллектор IPMI центра обработки данных передает свои данные на сервер оперативного кэша Metrics с ограниченным временем хранения. Вся важная информация сохраняется на сервере OVH Metrics.


Аналитика данных
Мы храним наши метрики в warp10. Warp 10 поставляется с языком сценариев временного ряда: WarpScript, который делает аналитику мощной, чтобы легко манипулировать и обрабатывать (на стороне сервера) наши собранные данные.

Мы определили три уровня анализа для мониторинга работоспособности серверов:

• Простая пороговая метрика на сервер.
• Используя службу метрических циклов OVH, мы объединяем данные по стойке и по комнате и вычисляем среднее значение. Мы устанавливаем порог для этого среднего значения, это позволяет обнаруживать стойки или общий отказ помещения в системе охлаждения или системы электропитания.
• Служба MLS OVH выполняет обнаружение аномалий в стойках и помещениях, прогнозируя возможное развитие метрик в зависимости от прошлых значений. Если значение метрики находится за пределами этого шаблона, возникает аномалия.

Визуализация / действия
TATA Все предупреждения, генерируемые анализом данных, помещаются в TAT, который является инструментом OVH, который мы используем для обработки потока предупреждений.


Графана используется для мониторинга метрик. У нас есть информационные панели для визуализации показателей и агрегатов для каждой стойки и помещения, обнаруженных аномалий и эволюции открытых оповещений.