Возвращаясь к проблемам удаленного мониторинга

Питер Морриси

Обратимся к сетевому управлению, которое, будучи непростым и сегодня, со временем все более усложняется. В такой ситуации на помощь приходят стандарты RMON (удаленного мониторинга), основанные на протоколе SNMP. RMON находит повсеместное применение и принимает самые разнообразные формы. Его можно назвать двигателем развития высококлассного ПО и оборудования. Но то, что RMON действует, не значит, что он является панацеей. Давайте с практической точки зрения взглянем на его недостатки и конкретные шаги, предпринимаемые производителями по их преодолению. Рабочая группа IETF тоже прикладывает значительные усилия по решению этих задач.

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

Чтобы избежать этого, производители снабдили некоторыми функциями RMON каждый порт коммутатора. Сейчас большинство этих устройств имеют группы статистики и истории RMON на каждом порте, а некоторые из них — группы событий и аварийных сообщений, извещающих станцию сетевого управления только тогда, когда статистика достигает пороговой величины. Это более масштабируемая система, чем система постоянного опроса всех портов коммутатора. Группа статистики запускает счетчики базовой загрузки и статистики ошибок на каждом порте, а группа истории позволяет хранить выборки указанных данных, которые могут понадобиться для оценки тенденций. Теоретически это выглядит хорошо, так как с помощью производимых в настоящее время улучшенных наборов специализированных микросхем (Application Specific Integrated Circuits — ASIC) удаленного мониторинга можно осуществить все перечисленное без серьезных дополнительных затрат, но в действительности это связано с определенным риском.

Первая проблема — упрощение идентификации портов и установление их соответствия реальным физическим соединениям. RMON осуществляет это с помощью более старой базы управляющей информации — MIB2 (RFC 1213), разработанной первоначально для маршрутизаторов. Она включает в себя элемент, в котором есть так называемая ifIndex — таблица для каждого интерфейса на устройстве. Их нумерация в таблице производится последовательно, начиная с 1 или 0. Однако эти числа не вполне соответствуют физическим номерам портов на коммутаторе, делая проблематичной интерпретацию данных RMON. Модульный коммутатор еще больше усложняет дело: добавление платы может изменить последовательность номеров. Каждый интерфейс в ifIndex способен включать свое описание, позволяя поставщикам для облегчения проблемы помещать в указанное поле данные — такие, как скорости портов и описания сред передачи.

ПО Nethealth фирмы Concord Communications создает запись в базе данных для каждого порта, из которого собирает данные. А определяемое пользователем поле позволяет дать порту более осмысленное описание, например физический номер порта. Поступление и обновление подобной информации нелегко масштабировать, поэтому стоит ограничиться ключевыми соединениями, подобными тем, что находятся на магистралях.

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

***