snmptrapd performance

Сколько может snmptrapd трапов обработать в единицу времени?

От несколько тысяч до нескольких десятков тысяч в секунду.

Есть ли какие-то ограничения на это количество?

Да, это сама архитектура snmptrapd. Если нужно передать трап куда-либо еще, скажем, записать в файл/сокет/pmq, то snmptrapd на каждый трап (по фильтру или без) дернет один раз нужную команду/скрипт. В момент исполнения данной команды обработка трапов просто приостанавливается. В мане ты можешь почитать состояние дел на текущую версию. Судя по моим данным они так и не исправили эту ситуацию (хотя бы вывести в отдельный пул потоков). Можешь поискать патчи в сети, если для тебя это критически важно.

И доп. вопрос: если snmp-агент, отсылающий трапы демону, находится за NAT, то будет ли ему приходить подтверждение того, что трап был получен и обработан менеджером?

Трапы можно слать двумя способами по UDP и TCP: в первом случае гарантии доставки нет (вообще, by design), во втором - можно контролировать на уровне соединения/отсутствия ошибок (вроде EPIPE) в момент передачи сообщения.

Отличное сообщение, спасибо!

Да, это сама архитектура snmptrapd. Если нужно передать трап куда-либо еще, скажем, записать в файл/сокет/pmq, то snmptrapd на каждый трап (по фильтру или без) дернет один раз нужную команду/скрипт. В момент исполнения данной команды обработка трапов просто приостанавливается. В мане ты можешь почитать состояние дел на текущую версию. Судя по моим данным они так и не исправили эту ситуацию (хотя бы вывести в отдельный пул потоков). Можешь поискать патчи в сети, если для тебя это критически важно.

Что касается ахитектуры snmptrapd, то т.к. мне нужна достаточно сложная обработка данных, включающая обращение к СУБД, узким местом будет блокировка обработки остальных трапов на время выполнения текущего.

Трапы можно слать двумя способами по UDP и TCP: в первом случае гарантии доставки нет (вообще, by design), во втором - можно контролировать на уровне соединения/отсутствия ошибок (вроде EPIPE) в момент передачи сообщения.

Что касается UDP/TCP, то с TCP всё ясно, а вот с UDP вроде бы в документации на протокол SNMP видел что-то связанное возможностью подтверждения получения и обработки трапа от менеджера агенту.

Ещё раз спасибо, думаю что SNMP для моей задачи не подходит.

Ещё раз спасибо, думаю что SNMP для моей задачи не подходит.

Если у тебя железки покруче сетевого оборудования, то смотри в сторону различных очередей сообщений: RabbitMQ, ActiveMQ, ZeroMQ и прочих.

У меня железки простые, но есть задача их мониторить и периодически управлять так, чтобы иметь возможность выполнять удалённо команды с расширяемой логикой. Архитектура - 1:N, один сервер и множество клиентов (до 1000), которые периодически сообщают своё состояние и запрашивают команды из центра.

zeromq

Да, наверное хороший выбор.

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

Занимался не так давно подобным. Могу сказать, что 2 сервера (управление + БД) более чем достаточно на 1000 железок. Они могут слать хоть вообще все подряд на snmptrapd, но как из опыта известно кол-во сообщений в обычной сети довольно мизерно.

которые периодически сообщают своё состояние и запрашивают команды из центра

Переконфигурация налету?

ИМХО, в твоей задаче кроме snmp трапов и поллинга (для надежности) более ничего не нужно.

Могу сказать, что 2 сервера (управление + БД) более чем достаточно на 1000 железок.

Это интересно. Там было 2 сервера с балансировкой нагрузки или я не так понял? Мы планируем делать схемку с фронтенд-сервером, БД и гуём управления, цепляющимся и работающим с БД. Здесь достаточно легко можно будет сделать резервирование, т.к. база реплицируется на раз-два...

Переконфигурация налету?

Не только. Например, поднятие обратного туннеля через SSH, чтобы можно было открыть WEB-интерфейс с центра на любом узле.

ИМХО, в твоей задаче кроме snmp трапов и поллинга (для надежности) более ничего не нужно.

Про трапы понятно - это сигнализация смены состояний от агента менеджеру (центру). Но нам нужно ещё в обратную сторону периодически что-то гонять (команды, данные). Сложность в том, что агенты могут быть за NAT'ом и, соответственно, прямой доступ к ним со стороны центра отпадает. Что остаётся? Именно поллинг, но соединение будет устанавливать агент: отправлять состояние и запрашивать команды.

А ты имел в виду под поллингом периодический опрос клиентов из центра, так?

Там было 2 сервера с балансировкой нагрузки или я не так понял?

Система мониторинга + автоконфигурация и все в таком духе. Платная штука. Разворачивается хоть на одном сервере, хоть на сколько скажешь.

Здесь достаточно легко можно будет сделать резервирование, т.к. база реплицируется на раз-два...

БД это всего лишь сторадж. Но если вы вынесете логику в БД... в общем максимальная нагрузка в лучшем случае будет составлять несколько десятков тыс. «событий».

Сложность в том, что агенты могут быть за NAT'ом и, соответственно, прямой доступ к ним со стороны центра отпадает.

То у вас обратные тунели поднимаются, то сложности какие-то :) Пишешь прокси сервер, который будет гонять через себя трафик из/в центр. С автореконнектом, ну и звонок на мобильный в случае недоступности свыше 10 минут (или сколько у вас критикал). Соединение можно даже зашифровать, если нужно. Вобщем, я никаких сложностей не вижу.

Основная сложность для SNMP это UDP, со всеми вытекающими: потери, низкий приоритет. Даже если замените SNMP на что-то другое (или используете TCP для SNMP), то насколько мне известно никакие протоколы не заботятся о доставке событий. Например, «линк упал, сообщение не дошло, линк поднялся, сообщение не дошло, потом все наладилось» — цепь событий будет утеряна при любом раскладе, только если по логам выяснять. Конечно, касается лишь обычных коммутаторов/маршутизаторов. А для всего остального, ну к прокси выше можно дописать модуль (или вообще сделать как отдельное приложение), который будет копить события, а когда все нормализуется с коннектом в центр - передаст.

На самом деле потеря событий от железок не является критически важной частью системы мониторинга или предоставления сервиса. Фишка в том, что за надежность отвечает BGP/OSPF + люди, которые строили сеть. Сеть должна быть достаточно надежной со всех сторон: несколько физических каналов, BGP, как я говорил, и качественное оборудование. Если всего этого нет, то какую систему не строй (программно), то ничего не выйдет. Один физический линк может накрыться на день-два, накопится 100500 событий. Система мониторинга должна просто проигнорировать их все, т.к. время вышло. Что системе нужно знать в текущий момент, так это только то, что железка поднялась; далее производится проверка uptime, настройки, мак-адреса и т.д. А все потеренные события... ну, клево для журнала, в то время как над исправлением ситуации будут заниматься либо вы, либо кто-то еще и знать все детали.

А ты имел в виду под поллингом периодический опрос клиентов из центра, так?

Да. Я просто не знаю, что конкретно вы строите, но поллинг это активный мониторинг, трапы по snmp это пассивный. Оба друг друга дополняют.

БД это всего лишь сторадж. Но если вы вынесете логику в БД... в общем максимальная нагрузка в лучшем случае будет составлять несколько десятков тыс. «событий».

Поясни пожалуйста, что именно ты имеешь в виду? На сколько я представляю сейчас возможную архитектуру нашу серверной части, то БД будет содержать, например, таблицу команд для Клиентов для того, чтобы при подключении любого из них дать ему знать что нужно сделать. Это по твоей терминологии сторадж, т.е. хранилище. Так? Логику при этом будет содержать фронтенд с одной стороны и консоль управления, с другой.

То у вас обратные тунели поднимаются, то сложности какие-то :) Пишешь прокси сервер, который будет гонять через себя трафик из/в центр. С автореконнектом, ну и звонок на мобильный в случае недоступности свыше 10 минут (или сколько у вас критикал). Соединение можно даже зашифровать, если нужно. Вобщем, я никаких сложностей не вижу.

Если правильно понимаю, то прокси на стороне сервера с подключением к нему Клиентов? Тогда придётся реализовывать маршрутизацию обращений через прокси к Клиентам. В предположении, что на проксе будет висеть 1000 клиентов, а обращаться за данными нужно к конкретному. Не совсем понятно, чем это проще, нежели при необходимости поднимать обратный туннель по команде.

Основная сложность для SNMP это UDP, со всеми вытекающими: потери, низкий приоритет. Даже если замените SNMP на что-то другое (или используете TCP для SNMP), то насколько мне известно никакие протоколы не заботятся о доставке событий. Например, «линк упал, сообщение не дошло, линк поднялся, сообщение не дошло, потом все наладилось» — цепь событий будет утеряна при любом раскладе, только если по логам выяснять. Конечно, касается лишь обычных коммутаторов/маршутизаторов. А для всего остального, ну к прокси выше можно дописать модуль (или вообще сделать как отдельное приложение), который будет копить события, а когда все нормализуется с коннектом в центр - передаст.

На самом деле потеря событий от железок не является критически важной частью системы мониторинга или предоставления сервиса. Фишка в том, что за надежность отвечает BGP/OSPF + люди, которые строили сеть. Сеть должна быть достаточно надежной со всех сторон: несколько физических каналов, BGP, как я говорил, и качественное оборудование. Если всего этого нет, то какую систему не строй (программно), то ничего не выйдет. Один физический линк может накрыться на день-два, накопится 100500 событий. Система мониторинга должна просто проигнорировать их все, т.к. время вышло. Что системе нужно знать в текущий момент, так это только то, что железка поднялась; далее производится проверка uptime, настройки, мак-адреса и т.д. А все потеренные события... ну, клево для журнала, в то время как над исправлением ситуации будут заниматься либо вы, либо кто-то еще и знать все детали.

Обдумаю, спасибо.

Поясни пожалуйста, что именно ты имеешь в виду?

У нас был опыт: систему изначально строили для 1000, максимум 2000 железок. Большая часть логики системы, в данном случае назовем это реагированием на события была сделана в БД. А понимается под этим следующее: в любой момент времени событие от железки должно обработатся БД для формирования определенного действия (хранимые процедуры), например, оповещение по смс или реконфигурация по telnet/ssh/неважно. В итоге, сейчас система должна обслуживать сотни тысяч (момент миллиона я уже не застану) железок. И как оказалось, БД с навороченной логикой внутри себя просто не готова к такому извращению. БД используется самая известная в мире, т.е. с плюшками масштабируемости и все такое. И оказалось, что содержание БД на кластерах очень-очень затратное и крайне неэффективное занятие.
Как бы там ни было, за все платит клиент и он же диктует правила. В нашем случае правила были таковы, чтобы заставить систему безболезненно масштабироваться в рамках безудержного роста железок. И тут оказалось, что это сделать на стороне БД очень сложно. Выход был найден и тривиален (переписать все), но было уже поздно. Поэтому мой совет: проектируйте систему под 10 млн. железок сразу. Логику лучше выносить в собственное ПО, а БД пусть является центральным хранилищем. Столкнутся придется с проблемами другого характера, но во всяком случае они будут решаемы. К слову сказать однажды решив проблему с сетевой нагрузкой (а ее будет достаточно) можно будет говорить о точных цифрах для единицы системы.
Недостаток БД в качестве логики кроется еще в одном ньюансе. БД рано или поздно необходимо обновлять. В развивающейся системе, где кроме мониторинга и автоконфигурации требуются плюшки в виде документного оборота, инвентаризации и прочего, БД придется обновлять. Скорей всего во время обновления систему придется приостанавливать, могут возникать непредвиденные сбои, и в нашем случае весь мониторинг останавливался. В хорошей системе этого не должно случаться никогда. Поэтому я называю БД всего лишь хранилищем данных. Далее эти данные загружаются модулями системами в свои локальные хранилища и на основе этих данных производятся необходимые действия.

Логику при этом будет содержать фронтенд с одной стороны и консоль управления, с другой.

Ваша терминология мне не ясна без указания деталей. Суть я передал выше.

Если правильно понимаю, то прокси на стороне сервера с подключением к нему Клиентов? Тогда придётся реализовывать маршрутизацию обращений через прокси к Клиентам. В предположении, что на проксе будет висеть 1000 клиентов, а обращаться за данными нужно к конкретному. Не совсем понятно, чем это проще, нежели при необходимости поднимать обратный туннель по команде.

Я просто предложил один из вариантов решения. Как я сказал выше, система мониторинга/управления должна быть автономной и не зависеть жестко от БД. Поэтому мы делали иначе. Концепция была в следующем. Было три типа единиц системы: серверная часть/мониторинг, БД и клиенты системы. Серверная часть состояла из множества различных демонов, которые занимались обработкой данных с железок и их управлением. Такую единицу системы можно запустить в сети, где клменты находятся за NAT. И тогда все демоны могут непосредственно обращаться в БД. Конечно, держать БД открытой на весь мир не самый лучший вариант. Но в моем случае не было жесткой необходимости как-то извращаться ради NAT. У вас, как я понимаю, что-то публичное. И тут вариант с прокси решает глобальные проблемы: а) обеспечивает защиту данных; б) скрывает «беззащитную» БД от посторонних. Можно сколько угодно говорить насколько в вашей БД хорошо реализованы методы защиты авторизации, но я уверен, что все их относительно легко обойти.