Во-первых, следует указать на существенную социальную интегрированность и открытость научно-образовательного сообщества. В отличие от сетей большинства других корпоративных сообществ (например, силовых ведомств, промышленных предприятий), где во главу угла ставятся задачи узкокорпоративного характера и не предполагается выделение сколько-нибудь заметных ресурсов для обеспечения иных задач (разве что во время чрезвычайных ситуаций), в научно-образовательных сообществах всегда отмечалась тенденция не замыкаться в ведомственных рамках, а искать все новые и новые приложения для разработанных идей, подходов, не ограничивая чрезмерно совместного использования ресурсов.
Именно поэтому научно-образовательные сети России, создававшиеся в существенно ограниченных условиях (например, FreeNet в ИОХ им. Зелинского, Radio-MSU в Институте ядерной физики им. Скобельцина), неизбежно эволюционировали в сторону мультидисциплинарного развития, размывая тем самым изначальную узкопрофессиональную ориентацию. Более того, в сферу такого развития неизбежно оказывались вовлеченными не только научно-ориентированные сообщества, но и структуры образования, культуры и здравоохранения различной ведомственной принадлежности.
Во-вторых, упомянутая мудьтидисциплинарность, в совокупности с исследовательским характером решаемых задач, с неизбежностью приводит к расширению спектра проблемной ориентации пользователей. В таких сетях могут спонтанно возникать новые потребности, которые должны по возможности удовлетворяться наряду с потребностями традиционными и заявленными заранее. При этом специалисты, ответственные за сектор, например, вирусологических исследований, проводимых с использованием сети, не могут даже и предполагать о содержании задач, которые будут предложены уже завтра для решения в этой же сети археологами или геофизиками. Новые задачи и направления исследований возникают непрерывно, постоянно меняются их относительные приоритеты, состав приложений, участников и используемых ресурсов. Такая ситуация нехарактерна для типичной корпоративной сети неакадемического происхождения, где развитие идет существенно более плавными темпами, без резких скачков и поворотов.
Наконец, имеет место особое отношение исследовательских, в первую очередь, академических сообществ, к проблемам подготовки кадров -- как для ``собственного потребления'', так и для нужд общества в самом широком смысле -- на уровне города, региона, государства и даже цивилизации в целом.
Для эффективного управления информационно-телекоммуникационной системой такого масштаба, как Сеть передачи данных СО РАН в ее современном виде, требуется непрерывное поступление достоверных технологических данных о состоянии различных ее узлов и подсистем. Однако, наличия лишь низкоуровневых технологических данных для понимания и прогнозирования работы современной сети безусловно недостаточно. Так, мы располагаем, например, информацией о том, что с 14:10 сего дня резко подскочила загрузка сетевого подключения, обслуживающего организацию N. Является ли эта аномалия проявлением нового научного подхода в сообществе N, что потребовало организовать массовую перекачку данных из точки А в точку Б? Или это -- результат вирусной инфекции в локальной сети организации? Или это -- проявление внешней атаки на информационные ресурсы наших абонентов? От ответа на эти и подобные вопросы, от классификации наблюдаемых аномалий зависит реакция администраторов сети, основанная на оперативном анализе ситуации, выполненном на более высоком семантическом уровне.
Если в отношении технологического мониторинга ситуация более или менее ясна, и для реализации этого мониторинга доступны вполне адекватные технические и программные средства, обеспечивающие сбор и визуализацию данных о сиюминутном состоянии различных компонент сети, то в отношении средств сбора данных по динамике и высокоуровневому анализу состояния сети ситуация далеко не так проста.
Предваряя изложение подходов к решению решаемых этими службами задач, рассмотрим возможную их классификацию. На наш взгляд, могут быть выделены следующие категории:
Мы сознательно ограничиваем предметную область и не рассматриваем оперативный контроль за состоянием множества сетевых приложений и сервисов, таких, как DNS, работоспособность почтовых служб и заполненность пулов почтовых очередей, согласованность и непротиворечивость маршрутизации. Важность этих вопросов для управления реальной сетью не вызывает сомнений, и большинство задач этих категорий решаются с помощью широко известных сетевому сообществу приложений высокоуровневого сетевого мониторинга. В настоящее время хорошо известны программные продукты с открытым кодом, например, Nagios, с помощью которых могут эффективно решаться как упомянутые выше, так и подобные им задачи.
Перечислим широко использующиеся подходы:
- SNMP-мониторинг. Информационная ценность его результатов в известной степени ограничена, поскольку практически вся доступная информация сильно интегрирована и/или анонимизирована. Несмотря на то, что многие естественные вопросы в рамках стандарта SNMP остаются без ответов (например, определить текущую загрузку в битах в секунду на определенном интерфейсе можно только при использовании реализованных на конкрентной платформе расширений стандарта, или путем самостоятельного вычисления инкрементов счетчиков на интерфейсе и деления полученных значений на длительность интервала наблюдения), SNMP-мониторинг активно используется для решения задач категорий А и Б. Его функциональность реализована достаточно единообразно на большинстве используемых платформ, хотя и существует определенная специфика. Практически нет альтернатив, позволяющих работать с различными платформами (не учитывая разве что терминальный доступ). Для задач категории Б технологии SNMP-мониторинга вполне адекватны, но проблемы могут возникать при использовании небрежно реализованных front-end систем или применения плохо масштабируемых решений (например, при регулярном опросе значительного количества переменных загрузка мониторирующего процессора может стать значительной).
Для решения задач категории В применяется уже множество подходов:
- Непосредственное наблюдение за состоянием передающей среды на 2-ом уровне ВОС. В принципе это -- самый мощный метод, поскольку позволяет фиксировать всю необходимую информацию о трафике, однако применимость его с переходом сетей на современные технологии передачи данных существенно ограничилась.
Использование для этой цели современных коммутаторов и маршрутизаторов с применением технологий мониторирующих портов (monitoring port, spanning port) все же возможны, но ограничиваются в основном сетями с относительно невысокой загрузкой, не превышающей половины пропускной способности передающей среды: в случае мониторинга порта c текущей загрузкой 40 Мбит/сек в обе стороны на мониторирующий порт будет приходить поток 40+40=80 Мбит/сек; для текущей загрузки 80 Мбит в обе стороны мощность потока на мониторирующий порт составит уже 160 Мбит/сек, что может превысить возможности мониторирующего порта (мы исходим из предположения, что мониторируемая инфраструктура построена на широко распространенной технологии Fast Ethernet) . В этом случае будет необходимо использование или гигабитного порта (а их количество на коммутаторе и, тем более, на маршрутизаторе, как правило, ограничено, и они используются в основном для организации так называемых восходящих линков (up-links)), или применением механизма агрегирования группы Ethernet-портов. Однако, в последнем случае также существуют проблемы на популярных платформах, связанные, например, с невозможностью назначения порта и/или интерфейса (в частности, агрегированного порта) в качестве мониторирующего порта.
При таком подходе анализируется непосредственно передающая среда, и здесь возможна определенная независимость от аппаратной платформы. Для полноценного использования возможностей такого метода могут потребоваться специальные технические средства сетевого мониторинга (Network Taps, technological access points).
- Технологии типа IP-accounting. По сути, это -- наблюдение за трафиком интерфейса или группы интерфейсов средствами, интегрированными в состав активного сетевого устройства. В настоящее время эти технологии также имеют ограниченное применение, хотя по своей эффективности могли бы быть сопоставлены с перечисленными в предыдущем пункте. Технологии этого типа реализованы на немногих аппаратных платформах. Конечно, они могут быть реализованы в автономных модулях-сенсорах, способных непосредственно наблюдать за средой (см. выше), либо в качестве встроенных компонент сетевой инфраструктуры, пропускающих через себя весь трафик определенных фрагментов сети.
В подобных реализациях сенсоры могут предоставлять дополнительную функциональность межсетевых экранов (firewalls), либо систем обнаружения атак (традиционно такие системы обнаружения называются IDS, Intrusion Detection System, что не вполне соответствует их функциональности): например, сетевые экраны PIX, FW-1, экраны, построенные на распространенных пользовательских платформах (Linux, BSD, Solaris)/ Как правило, предоставляемая в части сбора статистики функциональность y распространенных сетевых платформ существенно ограничена из-за чрезмерного агрегирования и интегрирования статистических характеристик трафика. В то же время, при реализации на автономных модулях-сенсорах она может быть столь существенно расширена, что возникают основания говорить о новой категории сетевых устройств.
- Методы, базирующиеся на технологиях, следующих моделям RFC1272, RFC3917 (Netflow и им подобные). Эти методы наиболее широко применяются в современных сетях, наряду с мониторингом SNMP. Технологии Netflow разрабатывались для оптимизации процедур маршрутизации и коммутации, так что задачи сбора статистики трафика не являлись приоритетными. В результате ценность данных Netflow для задач категорий В и Г заметно ограничивается. Критика технологии Netflow и направления ее развития достаточно широко известны.
Для задач сбора статистики и оперативной диагностики, когда требуется информация неинтегрированная (fine-grained), преимущественно используются методы, базирующиеся на технологиях Netflow, что объясняется не преимуществами этих технологий, а отсутствием альтернативных решений. Например, определенные характеристики TCP-трафика (например, кем из двух участвовавших в диалоге хостов было инициировано данное TCP-соединение или данная UDP-транзакция) практически несущественны для задач сбора статистики, но для задач расследования инцидентов они чрезвычайно важны.
На наш взгляд, определенные перспективы имеют два взаимодополняющих метода мониторинга: непосредственный мониторинг потока данных передающей среды на нижнем уровне посредством автономного модуля-сенсора, и сбор оперативной статистики трафика на базе этого мониторинга типа Netflow, но с иной, более продуктивной для сформулированных задач семантикой.
Сложности применения этих подходов состоят, прежде всего, в том, что непосредственный мониторинг канала в условиях корпоративной СПД СО РАН возможен только в точках подключения на периферии сети, на уровне отдельной организации либо некоторой группы организаций, типа сети регионального НЦ (где загрузка канала не превосходит 50% от потенциальной емкости канала), но не подходит для опорной сети или для внешних каналов. Для организации такого мониторинга на загруженных каналах емкостью 100 Мбит/с и более требуется специальное оборудование, обеспечивающее невозмущающий мониторинг канала.
Следует указать также и на то, что включение в состав сети сложных компонент с активно эволюционирующим программным обеспечением может отрицательно сказаться на надежности системы в целом. Это делает предпочтительным выделение модулей-сенсоров в такие автономные блоки, которые не будут блокировать целый сегмент сети в случае неизбежных ошибок/сбоев.
И, наконец, дополнительную сложность создает необходимость обеспечения масштабируемости системы с тем, чтобы обеспечить ее работоспособность как на современных уровнях загрузки каналов, так и в случае ее увеличения в несколько раз (как минимум до емкости 1 Гбит/сек).