Производители сыплют пресс-релизами и создают ажиотаж вокруг продуктов "управления в соответствии с заданными правилами". Но что они собой представляют в действительности?
Суматоха просто поражает. Ведущие игроки сетевой отрасли и различные прилипалы с венчурным капиталом стремятся найти себе союзников, создают стратегические альянсы и связывают свое имя со стандартами, пытаясь застолбить участок на территории так называемого "управления в соответствии с заданными правилами" (policy-based management).
Однако в сетевом бизнесе производители раскручивают рекламную машину, только если потенциальный рынок действительно того стоит. Так что же это за управление с помощью правил и что оно может сделать для вас?
Концептуально управление в соответствии с заданными правилами относится к набору задаваемых пользователем инструкций, определяющих, как выполняются различные сетевые функции. Конечно, многие администраторы сетей уже ввели различные правила в области ИТ в своей компании, но большая часть этих правил реализована вручную и/или отдельно для каждого вида устройств или правил.
Если быть более точным, управление с помощью правил означает некоторую степень автоматизации при реализации правил и, кроме того, общие механизмы задания и распространения всех типов правил.
Это что касается определения, на практике же, говоря об управлении с помощью правил, производители прежде всего имеют в виду приоритетное распределение пропускной способности и, иногда, защиту информации. Судя по презентациям, на самом деле, они продают решения по обеспечению дифференцированного обслуживания для сетей, где используется множество разнообразных приложений, выполнение части которых можно приостановить, когда пропускной способности оказывается недостаточно.
Так что, по крайней мере в своей первой инкарнации управление на базе правил представляет собой способ автоматизации административных задач по обеспечению качества обслуживания в сети. Конечно, оно вряд ли будет иметь хоть какую-либо привлекательность для тех администраторов сетей, у которых нет никаких средств обеспечения качества обслуживания и у кого они вряд ли появятся в ближайшем будущем. Но для тех, у кого они есть или кто собирается внедрить управление QoS в ближайшем будущем, возможность вводить правила обеспечения QoS в масштабе всего предприятия выглядит весьма привлекательно.
ВВЕДЕНИЕ СЕТЕВОГО КАТАЛОГА
Действительно ли администрирование QoS настолько сложно, что требует внедрения совершенно нового инструментария управления? Возможно. Прежде всего, число сетевых устройств в любой достаточно крупной компании, где вопросы дифференцированного QoS имеют смысл, скорее всего, велико. Это повышает важность автоматической реконфигурации большего числа устройств для соблюдения заданных правилами параметров. "Администраторы хотят иметь возможность определять правила на высокоуровневом языке и затем с помощью некоторого механизма автоматически преобразовывать их в различные низкоуровневые команды, понимаемые разнотипными устройствами", - объясняет Марк Говард, исполнительный директор Infonetics Research.
Не менее важно сетевым администраторам иметь возможность просто указать, что Приложение А имеет приоритет над Приложением Б, или что конкретные пользователи, в частности руководство компании, имеют привилегированный доступ для всех приложений, или что конкретное подмножество пользователей имеет преимущество при работе с указанными приложениями в такие-то и такие-то дни (например, что бухгалтерия получает всю необходимую ей пропускную способность для составления финансового отчета в последние дни каждого квартала).
 | 1. Администратор сети задает правила с помощью приложения управления правилами.
2. Информация о правилах вводится в LDAP-совместимый каталог. 3. Пользователь подает запрос о предоставлении услуги. 4. Сетевое устройство получает просьбу и запрашивает у сервера правило о том, что ему делать. 5. Сервер правил извлекает статическую информацию, условия и соответствующую информацию о пользователе, хранимую в каталоге LDAP, и формирует однократную лицензию с правилами. 6. Затем сервер правил возвращает лицензию устройству в качестве ответа с помощью протокола преобразования правил, такого, как общий открытый сервис правил (Common Open Policy Service, COPS). 7. Устройство реализует сервис с требуемым QoS, шифрованием и т. п., как описано в лицензии. |
Для обеспечения такого контроля механизмы задания правил должны быть связаны с имеющимся хранилищем информации о пользователях и ресурсах, т. е. с каталогом (см. Рисунок). Данная связь также необходима на случай, если управление в соответствии с правилами когда-нибудь будет простираться на такие области, как защита или конфигурация виртуальных локальных сетей, так как каталоги - это место, где администраторы хранят сведения о правах и ограничениях доступа.
В этой связи мы должны упомянуть инициативу "Сети с каталогами" (Directory-Enabled Networks, DEN). Она была объявлена в сентябре 1997 года компаниями Cisco Systems и Microsoft и получила с тех пор поддержку многих других производителей. Через год спецификация DEN была представлена в рабочую группу по управлению настольными системами (Desktop Management Task Force, DMTF) на рассмотрение в качестве стандарта. Идея состояла в том, чтобы сделать DEN расширением общей информационной модели (Common Information Model, CIM), где бы DEN отводилась функция предоставления данных о том, как профили пользователей, приложения и сетевые услуги связаны между собой.
Как гласит официальное заявление, DEN "определяет проблемные области, информационную модель, принципы использования и подробную схему каталога для внедрения каталога в сеть". Это означает, что инструментарий управления может не только брать информацию из каталога для определения правил и местонахождения ресурсов, необходимых для введения данных правил в силу, но и публиковать информацию о самом себе в каталоге. Каталог становится, таким образом, главной точкой управления в сети, при этом инструментарий управления правилами выступает в качестве консоли(-ей) для введения определений правил и преобразования их в объекты DEN, публикуемые в каталоге.
DEN заимствует многие из определений CIM, включая классы Managed System Element, Configuration и Setting, а также Service, Location и Application. Эти определения весьма сложны и специфичны. Например, Сервис определяется как "Логический Элемент, содержащий информацию, необходимую для представления и управления функциональными возможностями, предоставляемыми Устройством и/или Программной Функцией. Сервис - объект общего назначения, предназначенный для конфигурации и управления реализациями функциональных возможностей. Сервис - не функциональная возможность сама по себе". Услуга отличается от Точки Доступа к Сервису, т. е. возможности задействовать или вызвать сервис. Такие подробные определения характерны для всей процедуры разработки стандартов, но они также являются следствием стремления DMTF сделать функцию DEN расширением CIM.
Кроме того, DEN немало заимствует из стандарта X.500. Она использует определения объектов X.500: Person, Group, Organization, Application и Alias. Не будучи новым стандартом на каталог, DEN не расширяет определения для таких объектов, как Alias. Тем не менее определения Person, Application и другие были расширены с целью обеспечения требуемой дополнительной функциональности и/или для согласования с существующей схемой CIM.
Как в объектно-ориентированной модели, взаимоотношения между объектами в DEN выражаются через включения или ссылки (иначе называемые объединениями и ассоциациями, соответственно). Включение означает, что один объект является частью другого, как платы, устанавливаемые в слоты маршрутизатора, а ссылка - что один объект подключается к другому, как данная сетевая плата к конкретному сегменту Ethernet.
В результате мы получаем весьма сложный язык, теоретически обеспечивающий возможность моделировать всякий объект и отношение в корпоративной среде, которые может потребоваться контролировать.
Все это, конечно, предполагает, что у вас имеется корпоративный каталог. Если доступность приложения зависит от корреляции между этим приложением и некоторой записью в пользовательских профилях каталога, то мы советовали бы вам сменить службу каталогов. Поэтому преимущества от использования DEN получат в первую очередь пользователи NDS (или даже X.500), несмотря на то что DEN является детищем Microsoft.
Возможности DEN выходят за рамки QoS. Абстрактная природа DEN позволяет отделам ИТ интегрировать все сетевые инфраструктурные сервисы, включая QoS, доступ к ресурсам, администрирование IP-адресов и т. д., в свои корпоративные каталоги, исключая ненужные задачи по ведению учета и обеспечению согласованности информации между всеми отделами и офисами.
"Снимая с оператора ту или иную повторяющуюся задачу, тем самым вы устраняете множество потенциальных ошибок, которые они могут допустить либо по небрежению, либо из-за незнания соответствующих правил", - считает Говард из Infonetics.
Серьезным испытанием для DEN станет готовность других производителей ее поддержать. Пугалом для стандартов, как можно видеть на примере SNMP, является склонность производителей создавать собственные расширения любого стандарта для того, чтобы добиться конкурентных преимуществ или просто предоставить функции, не предлагаемые стандартом. Для примера, какую часть информации коммутатора Stratacom компании Cisco Systems можно извлечь посредством простого опроса по SNMP?
"Мы должны быть очень осторожны, когда дело касается нестандартных расширений стандарта, - замечает Дж. Кевин МакЛиз, вице-президент группы по стратегическим технологиям в Bank-America. - Даже ориентируясь на одного поставщика, мы вынуждены всегда помнить о том, что приобретаемые нами организации вовсе не обязательно используют ту же комбинацию технологий".
Таким образом, хотя очевидно, что DEN помогает определить, как каталоги следует использовать для хранения информации о правилах, пока неясно, насколько широкое применение она найдет в качестве общепринятого механизма контроля за гетерогенной инфраструктурой в масштабах предприятия, в частности в организациях, где используется несколько каталогов (дополнительную информацию о DEN см. во врезке "Ресурсы Internet").
РОЛЬ LDAP
Ждать, пока DEN предоставит необходимые связи с каталогами для реализации управления с помощью правил на базе каталогов, может и не понадобиться.
3Com, например, заявляет, что ее оборудование будет поддерживать упрощенный протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP), благодаря чему оно может считывать информацию о правилах из популярных каталогов. В так называемых сетях с введением правил (Policy-Powered Network, PPN - термин 3Com) администраторы сетей могут использовать возможности LDAP совместно с программным обеспечением TranscendWare для определения и введения правил в отношении приоритетов, доступа к портам и т. п. "LDAP-совместимое устройство способно обмениваться информацией с любым каталогом, будь то NDS, Active Directory или что-либо еще, - говорит Майк Кукиш, менеджер линии продуктов в отделе управления сетями 3Com. - Это совсем иное дело, нежели обращение системы управления на базе правил типа TranscendWare напрямую к каталогу для получения необходимой информации".
Аналогично, Lucent Technologies объявила, что она собирается интегрировать и поставлять NDS в пакете с программным обеспечением управления для своего коммутирующего оборудования Cajun начиная ориентировочно с первой половины 1999 года. Как и 3Com, Lucent собирается обращаться к информации каталога со своих устройств с помощью клиента LDAP.
3Com, Lucent, Novell и другие компании, исповедующие сходный подход, одновременно заявляют о своей поддержке DEN, но, очевидно, они не собираются ждать, пока DMTF завершит свою работу, чтобы представить сетевое оборудование с управлением с помощью правил. На самом деле, если эти поставщики способны удовлетворить основные требования к созданию правил посредством LDAP-совместимого оборудования, то они могут насытить рыночный спрос на технологию типа DEN уже сейчас.
Так зачем же кому-либо заботиться о наличии стандартов для связи каталогов и правил? Зачем вообще нужен отдельный механизм введения правил?
Тому есть несколько причин. Во-первых, большая часть корпоративных сетей состоит из сетевого оборудования от множества производителей, поэтому различные устройства в сети должны уметь читать одну и ту же информацию. LDAP предоставляет общие средства доступа к данным в каталогах, но он не обеспечивает общей схемы этих данных. Другими словами, даже если бы китайцы и израильтяне согласились писать слева направо, как европейцы и американцы, то от этого их языки не стали бы более понятны. Благодаря предлагаемым DEN определениям данных устройства будут знать, как читать данные из каталогов, а также как выглядит находящийся в каталоге параметр QoS.
"Правила должны распространяться на все - от магистрального коммутатора до сетевой платы", - провозглашает Алан Моксли, администратор сети из Ciba Specialty Chemicals.
Во-вторых, рынок серверов управления с помощью правил будет скорее всего неоднородным. У вас может быть сетевое оборудование от Northern Telecom и 3Com, а платформа защиты от Axent Technologies или Platinum Technology. Таким образом, если вы определяете множество правил защиты, охватывающих доступ, идентификацию и шифрование, с одной консоли задания правил, то она должна говорить на том же самом языке, что и консоль задания приоритетов в распределении пропускной способности. Кроме того, все соответствующие элементы в инфраструктуре должны понимать, что консоль им сообщает.
"Мы стараемся даже использовать термин "управление в соответствии с правилами" как можно реже, потому что считаем это неотъемлемым принципом функционирования сети, - говорит Джо Хилшер, директор по маркетингу сетевых технологий с применением правил в Cisco Systems. - Это означает не только то, что вы должны иметь системы управления с возможностью определения правил, но и что ваша инфраструктура должна обладать достаточным интеллектуальным потенциалом для поддержки принятых решений".
ВСЕ ПЕРЕГОВОРЫ ЧЕРЕЗ COPS
Если LDAP обеспечивает для сетевых ресурсов прямой доступ к информации о правилах в каталогах, а DEN - представление этих данных на языке, понятном всем сетевым устройствам, то IETF готовит спецификацию на транспортную службу для передачи правил по сетям IP.
Общая открытая служба правил (Common Open Policy Service, COPS) описывает клиент-серверную модель запросов и ответов о правилах. Протокол абстрагируется от внутренних принципов работы сервера правил и, хотя он писался под QoS, теоретически расширяем на другие виды правил.
Модель COPS описывает коммуникации между сервером правил (в данном случае он называется точкой принятия решений - Policy Decision Point, PDP) и клиентом (точкой выполнения решений - Policy Enforcement Point, PEP). В соответствии с COPS клиент посылает запросы, обновления и удаления серверу. В ответ PDP возвращает PEP решения. COPS использует IPSec для идентификации сторон и защиты каналов между PEP и PDP - важный момент, учитывая тот факт, что серверы правил могут представлять собой мощное средство вмешательства в функционирование сети для злоумышленников.
Более важно, что протокол COPS учитывает контекст (иными словами, он составлен так, что информация об атрибутах ресурсов интерпретируется как текущее состояние этих ресурсов, пока не будет получено сообщение об обратном). Данное обстоятельство чрезвычайно важно, потому что запросы об услуге со стороны клиента PEP должны сохраняться на PDP, пока они не будут явным образом удалены. Без учета контекста правила не могут реагировать на текущие условия в сети (например, на превышение порога), а это означает, что правила не будут реагировать на переменные среды. В данном отношении COPS отличается от таких протоколов, как SNMP, сообщающих системе управления о своем текущем состоянии в данный момент, но не обязанных уведомлять об изменении этого состояния. COPS позволяет PDP принудительно изменять конфигурационную информацию на клиенте и затем удалять ее, когда она перестает соответствовать ситуации.
Кроме того, COPS предусматривает локальные точки принятия решений (Local Decision Point, LDP), с помощью которых нагрузка по хранению данных и обработке запросов о правилах может быть возложена на подчиненные серверы правил ближе к клиентам PEP, которыми они управляют. Однако LDP обязаны сообщать о принятых решениях PDP, причем последние могут отменить их в любой момент.
Сообщение COPS состоит из заголовка, за которым следуют относящиеся к правилам объекты. Заголовок идентифицирует версию COPS (в настоящее время это первая версия), Request, Decision, Report State, Delete Request State, Synchronize State Request, Client Open, Client Accept, Keep-Alive, Client-Close, Synchronize Complete и Client-Type. Имена этих полей показывают, как COPS использует состояния для того, чтобы решения в соответствии с правилами соотносились с состоянием ресурсов и среды в целом.
Объекты COPS - это Handle, идентифицирующий установленное состояние; Context, указывающий тип события(-ий), инициированных запросом; Reason, описывающий причину, почему данное состояние было удалено. Очевидно, что эти объекты дают разработчикам механизмов задания правил чрезвычайно детальный контроль за тем, как ресурсы запрашивают решения, как серверы правил определяют, что отвечать на эти запросы и как ресурсы могут выполнить ответы, которые они получают.
КАКИЕ ВАРИАНТЫ?
При всей масштабности замысла COPS некоторые вопросы относительно его практической реализации все же имеет смысл задать. Действительно ли все эти сложные запросы и ответы, передаваемые по сети, так необходимы? Захотят ли администраторы сетей, и без того приходящие в отчаяние от сложности инструментария управления корпоративными сетями, осваивать еще и новые средства управления в соответствии с правилами на базе DEN и/или COPS. Готов ли персонал управления сетью устанавливать сложные зависимости, характерные для сервисов в распределенной среде? Лишь немногие группы ИТ занимаются мониторингом своих сетей с точки зрения функционирования приложений из конца в конец. Как же тогда они могут заставить работать ориентированное на правила управление? Возможно, что и не могут, поэтому весьма вероятно производители предложат другое решение задач, которые призвано решить управление в соответствии с правилами.
Один любопытный подход был предложен ведущим поставщиком интегрированного инструментария управления корпоративными сетями Computer Associates. Недавно CA сняла завесу секретности со своей технологии нейронных агентов Neugents. Neugents - это интеллектуальные эвристические агенты, способные самостоятельно собирать информацию о состоянии и проблемах сети с течением времени. Они отслеживают сотни или даже тысячи дискретных параметров среды, хранимых в базе данных о предыстории. С ухудшением функционирования или выходом системы из строя Neugents могут проанализировать предшествующие возникшей ситуации условия. Это, конечно, не означает, что они понимают следствия и причины точно так же, как опытный специалист, но во всяком случае они способны выполнять весьма детальный анализ условий, приведших к возникновению проблемы. Таким образом, технология нейронных агентов весьма хороша для прогнозирования проблемных ситуаций с известной степенью определенности, т. е. она может помочь предотвратить отказ службы, а не просто сообщить, когда он произойдет.
Какое все это имеет отношение к управлению с помощью правил? Если цель введения управления на базе правил состоит в предотвращении "удушения" загрузкой из Web трафика SAP R/3, то все, что вам необходимо, - это агент SAP R/3 Neugent. Агент Neugent достаточно быстро определит, что одной из причин ухудшения работы R/3 является рост трафика HTTP. При достижении этим трафиком определенного уровня Neugent проинформирует администратора сети, что он зафиксировал наступление опасного состояния и, при наделении его соответствующими полномочиями, может даже перекрыть потоки HTTP.
Естественно, Neugent необходимы средства для получения информации от сетевой инфраструктуры (возможно, по протоколу COPS), и, кроме того, в него должны быть введены некоторые функциональные параметры. Тем не менее эвристичность остается наиболее привлекательной чертой технологии нейронных агентов; иными словами, администратору не требуется проделывать огромную подготовительную работу по программированию и конфигурированию, прежде чем он сможет извлечь хоть какие-нибудь преимущества из своей работы. Теоретически, правила можно вводить поэтапно, когда основные правила реализуются быстро и в первую очередь, а уточнения вносятся по мере необходимости. Однако важнее всего то, что определение и реализация правил не будут отвлекать значительные человеческие ресурсы на длительное время.
"Правила нельзя задать раз и навсегда. Администратор должен постоянно следить за тем, что происходит в сети, и изменять правила соответствующим образом, - замечает Дж. П. Корбо, старший вице-президент по исследованиям и разработкам в Computer Associates. - Именно здесь способность агентов Neugents к самонастройке с течением времени может оказаться особенно ценной для администраторов сетей".
Еще более серьезный вопрос состоит в том, в какой мере правила действительно необходимы для того, чтобы справиться с многообразием сервисов, которые они призваны поддерживать, и с растущей пропускной способностью, которая этим сервисам требуется.
"Все сводится к старому аргументу, что вы можете купить столько пропускной способности, сколько требуется, так зачем беспокоиться о чем-то еще? - говорит МакЛиз из BankAmerica. - Это подобно тому, что произошло с процессорами: наши компьютеры стали намного мощнее, но они используют возросшую мощь для того, чтобы делать множество ненужных вещей. Так что, в любом случае, если вы хотите сделать больше полезного с помощью своей сети, управление ресурсами вам неизбежно понадобится".
Не будучи панацеей, перестройка сети помогает решить многие вопросы поддержки множества сервисов, так как проблемные точки в данном случае весьма специфичны. Например, в случае коммутируемого Ethernet на 100 Мбит/с на уровне рабочих групп и ATM на магистрали проблемы с пропускной способностью у корпоративной сети могут возникнуть только вне границ коммутирующего ядра. Таким образом, вместо внедрения сквозных механизмов реализации правил в такой сети наделение устройств доступа необходимым уровнем интеллекта может решить проблему.
Аналогично, информационная система с достаточной пропускной способностью территориальной сети, но узкими каналами глобальной сети для телеконференций может извлечь больше преимуществ из коммутируемых виртуальных каналов frame relay по запросу, чем из сложной системы управления с помощью правил.
При рассмотрении с точки зрения исключительно пропускной способности управление с помощью правил может, таким образом, оказаться наиболее привлекательным для провайдеров услуг, так как им приходится "жонглировать" различными видами трафика от множества клиентов в соответствии с разнотипными соглашениями об уровне сервиса. Таким провайдерам правила могут помочь найти нужный баланс между ресурсами и требованиями заказчиков для извлечения максимума возможного из инфраструктуры и сведения к минимуму случаев нарушения, чреватых обычно теми или иными штрафами.
Однако если производителям систем управления с помощью правил удастся разработать реальные стандарты, дающие возможность осуществить эффективную автоматизацию управления пропускной способностью, защитой и конфигурацией устройств различных производителей, то правила найдут свою нишу в корпоративных сетях, в частности, вследствие все возрастающей нехватки опытных специалистов. Активно внедряющие технологии компании постоянно что-то пробуют и изменяют в своих сетях, и если управление в соответствии с правилами поможет им внедрить больше сервисов более эффективно на базе обычной инфраструктуры IP без увеличения персонала ИТ, то это будет действительно привлекательным решением.
"Возможность управлять сетью посредством задания правил позволила мне держать одну вакансию незанятой больше года, - утверждает Гэри Хаберман, директор по техническим ресурсам в Университете Виденера. - Таким образом, мне удалось сэкономить 135 000 долларов".
Ленни Либманн - консультант и автор, специализирующийся на применении сетевых технологий в коммерческих целях. С ним можно связаться по адресу: ll@exit109.com.
Ресурсы Internet
Проект спецификации "Сети с каталогами" (Directory-Enabled Networks, DEN) можно найти на http://murchiso.com/den/#denspec/.
Проект протокола общего открытого сервиса правил (Common Open Policy Service, COPS) можно прочитать на http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-03.txt/.