`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Что для вас является метрикой простоя серверной инфраструктуры?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Мониторинг инфраструктуры – задача для выделенного сервера

+55
голосов

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

Системы мониторинга (Zabbix или MS SCOM), ввиду их специфических функций, размещают рядом с основной инфраструктурой. Требования к производительности серверов мониторинга следуют из выполняемых ими разнородных задач.

Мониторинг инфраструктуры – задача для выделенного сервера

Три источника нагрузки и три составных части требований к производительности мониторинга
 
Основная задача —  получать, обрабатывать и записывать поступающие из внешних источников данные, с минимальными задержками по каждой операции. Здесь важен каждый из элементов:
 
Сеть. Нужен интерфейс с минимальной латентностью на уровне оборудования. Уместно вспомнить  сравнение двух стандартов 10 Gigabit Ethernet - 10Base-T и SFP+: аппаратные задержки по витой паре почти в 9 раз выше (2.6 μs per hop против 0.3 μs).
 
CPU. Важна тактовая частота работы процессора - для минимизации задержек, и, как следствие, высокой скорости работы с оперативной памятью.
 
RAM. Объема должно хватать для предварительного кэширования и оперативной обработки потока данных перед формированием пакета записи.
 
Дисковая подсистема. Высокая потоковая скорость записи на диски важна при сбросе данных из кэша системы мониторинга и кэша базы данных SQL.
 
Надо минимизировать задержки на каждом этапе/устройстве – ведь они суммируются и с ростом системы будут только нарастать, причем нелинейно.
 
Вторая по важности задача — обеспечить быстрый доступ к большим массивам ранее собранных исторических данных. По ним генерируются отчеты и графики, на них основываются агрегированные проверки и триггеры.
 
Здесь основное внимание уделяют дисковой подсистеме: для отчетов и агрегированных проверок требуется быстрое потоковое чтение, а для отработки тригеров - быстрая работа со случайной выборкой данных. Традиционно, предпочтительна высокая частота CPU.  
 
Третья задача —  очистка устаревших исторических данных. Ценность данных со временем меняется. Если первое время нужны детальные данные, то в ретроспективе месяцев и лет достаточно интегральных показателей. Самому по себе прореживанию данных особая скорость не нужна. 

Но все дело в том, что его приходится выполнять одновременно с непрерывной записью данных. 

И, в итоге, это получается довольно сложная задача для любой SQL СУБД, генерирующая существенные нагрузки на дисковую подсистему.
Средняя система мониторинга может удалять устаревшие исторические данные пакетами по несколько тысяч записей в час. Но в своем большинстве СУБД не оптимизированы под операции удаления данных. Более того,  процесс автоматически вызывает процедуру обновления индексов для таблиц, из которых проводилось удаление (что по времени может быть длительнее, чем сама операция удаления), и обновление статистики использования данных (для оптимизации планировщиков запросов).
 
В результате дисковая подсистема должна:
 - быстро отрабатывать операциях записи со случайной выборкой;
 - иметь встроенные алгоритмы “сбора мусора” по результатам удаления данных и их естественной фрагментации;
 - удерживать производительность потоковой записи поступающих данных при проведении операций удаления.
 
Накопители NVMe подходят идеально.

Мониторинг инфраструктуры – задача для выделенного сервера

Коммунальный ад 

Абсолютно очевидно, что размещать систему мониторинга на общих c другими приложениями ресурсах хранения данных (сервера или кластера серверов) – не лучший выбор. Нагрузка мониторинга и так разношерстна – чтобы усугублять ею общий трафик. Наложение повредит вообще всем:
  • Система мониторинга генерирует пиковые нагрузки на процессор и дисковую подсистему. Просядет производительность всего хранилища – упадет качество всех сервисов (сервера или кластера). И наоборот, пиковые нагрузки сторонних приложений подавят работу системы мониторинга.
  • Система мониторинга следит за жизнеспособностью инфраструктуры. Поместив ее внутрь инфраструктуры, рискуем замаскировать для оператора развитие проблемы при отказе сервера. Недоступность мониторинга перекрывает канал важной информации и делает невозможной своевременную реакцию на сбой.
  • В любой виртуализированной среде критично время обработки запроса к конкретным устройствам ввода/вывода, не просто общие задержки. Особенно это касается дисковой подсистемы.  Она, при сохранении интегральных показателей может демонстрировать замедление отклика до 40%. Потери на обработку запросов сетевыми интерфейсами в виртуальной среде могут вырасти на 15-25%.

Что делать? 

Задача мониторинга инфраструктуры - еще один хороший пример “сервера одной функции”, где применение выделенного аппаратного устройства является более оправданным решением, чем размещение её внутри виртуализированной среды.
 
Разделяй и властвуй.
 

Вы можете подписаться на наш Telegram-канал для получения наиболее интересной информации

+55
голосов

Напечатать Отправить другу

Читайте также

 
 
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT