Далее под распределенной вычислительной средой понимается кластер HTC (система грид-вычислений) на базе ОС Linux/UNIX, позволяющая запускать параллельно сотни, тысячи и деcятки тысяч вычислительных процессов, пользующихся общим хранилищем для файлов.
Такая система не является территориально-распределенной, она располагается компактно, располагая при этом высокоскоростной сетью, соединяющей вычислительные узлы между собой и с высокопроизводительным хранилищем данных большой ёмкости.
Среды такого типа наиболее подходят для выполнения в них средств автоматизированного проектирования, верификации, моделирования. Возможны также запуски научных расчетов (и других программ, построенных на базе библиотек обмена сообщениями), хотя для их функционирования более подходят системы несколько отличающейся архитектуры (в части организации системы хранения и сети). Для хранения и обработки BigData, а также использования в качестве облачной инфраструктуры такие системы не предназначены
Широко применяемые сегодня системы мониторинга вроде Cacti, Zabbix, Prometeus или ELK способны собирать статистику с тысяч хостов, и могут использоваться для работы в средах данного типа, однако использование результатов их работы для расследования случаев экстремальной нагрузки и отладки, а не изучения долговременных трендов.
Проблема -
1) низкая скорость опроса
2) использование усредненных значений при построении графиков
3) невозможность соотнести детальный отчет о состоянии машины с характером графиков
расследование инциденда возможно только если он продолжается
иногда это невозможно по причинам производительности (инцидент делает невозможным подключение к пострадавшей машине)
4) низкая скорость построения графиков (Кибана/графана)
стратегия Pull (кроме Premeteus, у которого есть модуль для push-уведомлений от коротких процессов, зато он не может держать длительную историю - рекомендуется выгрузка в другие хранилища)
низкая скорость опроса / невозможность снимать данные с высокой регулярность - фатальный недостаток
в системах, собирающих данные с помощью специализированного агента, собирающего информацию по запросу, низкая скорость опроса усугубляется "некогерентностью" данных, т.е. данные
о различных параметрах могут собираться с интервалом в несколько секунд, но сохраняться в базе данных так, будто относятся с к одному моменту времени
обойти этот недостаток принципиально невозможно, т.к. в условиях высокой нагрузки на систему она не может обеспечить запуск агента/опрос с требуемой скоростью (особенно в случае, если парамет снимается не со штатных счетчиков ОС, а с помощью запускаемой сторонней утилиты, вывод которой возможно должен быть пропущен через фильтр типа grep)
у систем с SNMP-агентами лучше обстоит дело с "когерентностью" данных, но хуже с получением произвольной информации, не поддерживающейся SNMP-агентом
Что понимается под НИЗКОЙ скоростью опроса:
в системах с большим количеством контролируемых узлов опрос происходит раз в минуту
Средства мониторинга позволяют снизить интервал до 10 секунд, но требуют при этом увеличения мощности машины, производящей опрос и обработку данных, а также уменьшения количества контролируемых узлов или параметров.
Некоторое сетевое оборудование способно выдавать значения скоростей на интерфейсах раз в 5 секунд.
Для сравненния - утилиты ОС типа top vmstat iostat netstat nfsstat iftop ifconfig обеспечивают считавание счетчиков раз в секунду.
При опросе происходит усреднение показателей за интервал съема данных, что скрывает пиковые значения показателей, а ведь нештатные ситуации (потери пакетов, превышения таймаутов, заметные лаги в интерактивной работе, аварийные завершения из-за нехватки ресурсов) происходят как раз при пиковых значениях показателей.
Особенно наглядной иллюстрацией является проблема потери кадров в сетях Ethernet при одновременной передаче с нескольких узлов на один (например запись 100 файлов 100 клиентами на один файловый сервер):
На первый взгляд потери пакетов на соединении между коммутатором и сетевой картой файл-сервера выглядят довольно странно, если пропускная способность этого соединения - 1 гигабит в секунду, а наблюдаемый трафик - 150 мегабит в секунду, т.е. всего 15%.
Однако как только мы поймём, что значение 150мб/с является УСРЕДНЕННЫМ ЗНАЧЕНИЕМ НА ИНТЕРВАЛЕ в 1 секунду, а длительность передачи одного кадра составляет около 12 микросекунд, то станет очевидно, что 10 пакетов, одновременно пришедших от 10 машин в адрес сервера - соответствют пропускной способности 10 гигабит в секунду если расчитывать скорость без усреднения (т.е. использовать интервал усреднения в 12 микросекунд) и справиться с таким трафиком поможет только буферизация на портах коммутатора.
Т.е. графики трафика даже с усреднением в 1 сек "слепы", т.к. для проблемы потери кадров нужно изучать процессы длительностью в 10000-50000 раз меньше (при скоростях 10 гигабит и выше картина становится ещё более печальной)
Какие же процессы, происходящие в ОС интересуют нас для целей мониторинга и отладки высокопроизводительной вычислительной системы?
Какая скорость снятия данных достаточна для получения информации?
Интересны моменты массового запуска и завершения задач
Интересно выявление различных этапов работы алгоритмов, характеризующиеся специфическими паттернами нагрузки на компоненты информационной системы (зачитывание исходных даннных, моделирование в один или несколько потоков, порождение подзадач в том числе и на других узлах).
Интересно взаимодействие с подсистемой памяти, например захват приложением свободной памяти, давление на страничный кеш с целью его уменьшения, связанные с этим потери в производительности, возвращение ненужной памяти при проходжениие этапов алгоритма (или утечка памяти, впоследствии приводящая к краху приложения или активации оом-киллера).
Интересна работа буферов протоколов сетевого взаимодействия.
При анализе данных пользователь системы мониторинга крайне редко оперирует точными мгновенными значениями из базы данных - в подавляющем большинстве случаев речь идёт об анализе графиков, и здесь проблема слишком длительного цикла опроса умножается на проблему использования для построения графиков усреднённых значений за интервал, соответствующий по длительности одному пикселу картинки.
Цепочка расследования
графики с необычной нагрузкой на процессор
список процессов на машине - кто в топе
какая нагрузка на хоум/Сим (иостат)
что на файлере по нфс иопс, по дискам по процессору
одни графики не позволяют понять, чья конкретно нагрузка на клиентах. нужны ещё топ и иостат
с одним топом без иостат нельзя понять направление данных
С файлера нельзя понять чья
Цепочка мониторинга:
1) штатные стредства ОС, формирующие текстовый вывод. Желетельно ежесекундно, желательно с включением времени отправки
2) nc отправляющий со входа по TCP на сервер
3) statmon - слушает на TCP-порту и сохраняет присланные данные (от маркера начала до макрера начала) в директкорию по IP-адресу отправителя в файл, поименованный по таймкоду
4) statparser -
по списку "своих" серверов по всем наборам правил создать в память деревья уровней детализации для каждого параметра
каждый RescanTimeOut повторять:
по списку "своих" серверов выбирать файлы из папки "входяящие"
по наборам правил разбирать их на значения параметров.
для текущего момента вычислить тайл и положение в нём
зачитать или создать соответствующий тайл
добавить в него значение параметра
сохранить тайл
если был записан последний элемент тайла, (неудачная логика - нужно более универсальное)
то выгрузить его из памяти
переложить исходные файлы данных в дерево детализации
если не получается - просто стереть во избежание переполнения папки "входящие", которая может быть в памяти
5) statkeeper
по списку "своих" серверов по всем наборам правил создать в память деревья уровней детализации для каждого параметра
каждый RescanTimeOut повторять:
по списку "своих" серверов
по каждоу уровню дерева детализации
повторять поиск и удаление с диска самого старого тайла и соответствующей RAW-директроии
пока не останется сколько задано в параметрах дерева