Механика управления с помощью правил

Чем управление с помощью правил может помочь в оптимизации вашей сети? Эта статья представляет собой попытку ответа на данный вопрос.

Однако со временем вам может потребоваться кардинальный ремонт. В этом случае весьма полезным инструментом может оказаться управление с помощью правил.

Вряд ли управление с помощью правил появится в вашей сети в ближайшее время, тем не менее его полезно рассмотреть с точки зрения того, что эта технология способна предложить в перспективе. Наш журнал уже обращался к данной теме (см. статью Л. Либмана «На пути к управлению в соответствии с заданными правилами» в мартовском номере LAN за прошлый год), но за истекший год многое изменилось.

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

ЦЕЛИ И ЗАДАЧИ

Как говорилось выше, один из способов решить проблему увеличения числа пользователей и приложений в сети — это выделить дополнительную пропускную способность. Однако в какой-то момент такой подход перестает давать результат.

«С увеличением сложности сетей и приложений возникающие проблемы невозможно решить одним увеличением пропускной способности», — говорит Рон Уэстфол, ведущий эксперт в занимающейся исследованиями рынка компании Current Analysis. По мнению Уэстфола, управление с помощью правил будет приобретать все большее значение для оптимизации работы таких сетей. (О том, как повысить эффективность использования пропускной способности, смотри статью С. Штайнке «Оптимизация распределения пропускной способности» в февральском номере LAN за 1999 год.)

Однако, как и в случае большинства других перспективных технологий, важно помнить, что все дело — в деталях. Истинное управление с помощью правил предполагает учет сложной совокупности переменных, причем все они должны быть тщательно «оркестрованы» для достижения требуемых результатов. Иными словами, прежде чем браться за развертывание такой системы управления, вы должны выявить и взвесить все эти переменные — какие именно, вы узнаете, прочтя статью.

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

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

В настоящее время управление с помощью правил нацелено главным образом на обеспечение QoS и защиты.

При реализации системы управления с помощью правил для обеспечения QoS вам необходимо задать метод назначения приоритета потокам данных. Для IP-трафика IETF разработала ряд стандартов. В случае Differential Services (DiffServ) IP-пакеты различаются по биту типа сервиса (Type of Service, ToS) в заголовке. Поддерживающие DiffServ устройства, такие, как коммутаторы и маршрутизаторы, узнают таким образом, как классифицировать пакеты в соответствии с заранее заданными правилами. Сильной стороной DiffServ является сокращение различных этапов обработки, благодаря чему этот стандарт оказывается сравнительно хорошо масштабируем.

Разработанный для использования с DiffServ протокол RSVP+ распределяет приложения по приоритетам по отношению друг к другу. Это достигается благодаря предоставлению приложениям возможности идентифицировать себя в сети, чтобы наиболее важные или чувствительные к задержке приложения могли получить приоритет над менее важными или менее чувствительными к задержке.

Оптимально система управления с помощью правил должна позволять администратору сети задавать правила распределения трафика по приоритетам и затем, на основании этой информации, конфигурировать устройства для реализации приоритетов в соответствии с правилами.

Что касается защиты, управление с помощью правил способно выполнять множество функций. В идеале оно должно позволять делать такие вещи, как консолидация информации о правилах, в том числе списков контроля доступа, и применение данной информации к устройствам внутри сети. Это упрощает задачу назначения разным пользователям различных уровней привилегий доступа. Кроме того, служащие в качестве хранилищ правил каталоги и базы данных могут хранить такие компоненты защиты, как сертификаты PKI.

Хотя QoS и защита являются в данный момент основными областями приложения сил, системы на базе правил для управления хранением и приложениями также выходят на повестку дня. Без сомнения, функциональность управления с помощью правил будет продолжать расширяться.

АНАТОМИЯ ПРАВИЛ

Рисунок 1. Эта архитектура системы управления с помощью правил опирается на модель, предложенную DMTF и IETF. Точки принятия решений получают информацию от хранилищ правил и принимают решения на основании имеющихся правил. Точки выполнения решений — т. е. такие устройства, как коммутаторы, маршрутизаторы, шлюзы и брандмауэры, реализуют решения, передаваемые им PDP.

Системы управления с помощью правил могут значительно разниться по своей структуре и составу, тем не менее они имеют ряд общих элементов (см. Рисунок 1). В соответствии с моделью Рабочей группы по распределенному управлению (Distributed Management Task Force, DMTF, ранее Desktop Management Task Force) и IETF, система управления с помощью правил включает сервер правил, консоль правил (или консоль управления), точки принятия решений (Policy Decision Point, PDP) и точки выполнения решений (Policy Enforcement Point, PEP), а также управляющие протоколы. Большинство схем предусматривает также каталог или базу данных, служащую в качестве централизованного хранилища правил (см. врезку «Разногласия по поводу каталогов»).

Политика — это совокупность правил, при этом каждое правило состоит из ряда условий и действий. Условия определяют параметры, при которых правило применяется. Применение правила состоит в выполнении заданных действий. Действия описывают, что делать, когда удовлетворяются требования условия. Политика определяет, как устройство или интерфейс реализует действие при выполнении конкретного условия.

Сервер правил собирает информацию, принимает решение на основании полученной информации и передает решение сети с помощью протокола транзакции правил (некоторые из этих протоколов мы опишем ниже).

Консоль правил — это интерфейс, который администратор сети использует для таких задач, как создание и редактирование правил. Она также следит за отсутствием конфликтов между разными правилами.

Хранилище правил — это место, где хранится информация о правилах; им может быть, например, LDAP-совместимый сервер каталога. Хранилище позволяет элементам среды управления с помощью правил повторно использовать данные. Кроме того, централизованное хранилище позволяет добиться согласованности данных в масштабах всей среды управления с помощью правил.

PDP получает схемы правил из хранилища и принимает решения на основании этих правил. (Схема — это механизм представления и определения объектов.) Решения могут учитывать и другие факторы, такие, как запросы к сети от устройств или приложений, а также изменения в картине сетевого трафика.

PEP — это устройства, реализующие решения, переданные PDP. Ими могут быть коммутаторы, маршрутизаторы, брандмауэры и шлюзы.

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

В общем, процесс управления с помощью правил работает следующим образом: администратор сети определяет политику (или видоизменяет принятую политику) и связывает ее с PEP. Как правила, так и информация, относящаяся к PEP, находятся в хранилище. PDP извещаются о введении новой политики. Они получают правила и уведомляют администратора об их успешном (или безуспешном) введении.

Даже при наличии всех компонентов администратор должен убедиться, что они функционируют как надо. Это обычно достигается с помощью таких мер, как измерение (или аудит). Эта выполняемая PEP процедура позволяет проверить, что PDP реализуют политику правильно.

ПРОКОЛЫ И ПРОТОКОЛЫ

При большом числе взаимодействующих компонентов реализация политики может столкнуться с рядом трудностей. Одна из потенциальных проблем — конфликты правил. Конфликт правил — это режим, в котором политика оказывается недостижима, потому что действия одного или более правил не могут быть выполнены. Конфликт правил может возникнуть между несколькими правилами или между действиями в одном и том же правиле. (Под действием подразумевается процесс изменения конфигурации сетевых элементов для реализации определенного режима политики.)

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

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

Как упоминалось ранее, протоколы необходимы для передачи запросов и ответов о правилах между серверами правил и PEP. На эту роль претендует несколько соискателей.

Помимо традиционных участников, таких, как SNMP и RSVP, за право выполнения этой функции соперничают несколько других кандидатов. Одним из предложенных методов передачи информации является Common Open Policy Service Protocol (COPS) от IETF. Это протокол по типу «запрос-ответ» на базе TCP позволяет клиентам и серверам правил обмениваться информацией для проверки действенности решений.

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

Важно помнить, что, даже когда стандартный протокол пользуется широкой поддержкой, реализации разных производителей могут оказаться несовместимыми друг с другом. Таким образом, даже стандартный протокол — не панацея для обеспечения согласованного обмена информацией о правилах между серверами правил и PEP.

ВОПРОСЫ РЕАЛИЗАЦИИ

Для поверхностного взгляда управление с помощью правил может представляться относительно простой процедурой, но его реализация таит множество опасностей. Вообще же, правильная реализация чрезвычайно важна для успеха любой схемы управления с помощью правил. Неправильная конфигурация компонентов правил может не только не позволить достичь поставленных при создании системы целей, но и привести к полной неработоспособности сети.

Как говорит Дэвид Пассмор, директор по исследованиям в The Burton Group, относительно высокий, необходимый даже для типичной реализации управления с помощью правил уровень знаний, а также сложность системы правил и связанных с ней элементов, таких, как каталоги, заставляет многие компании обращаться к консультантам за помощью в развертывании системы. Обращение к сторонним услугам в такого рода проектах может оказаться весьма дорогим удовольствием. Динамическая же природа правил означает, что в них придется вносить изменения и в будущем, по завершении фазы внедрения. «Это не то, что можно один раз установить и забыть, — объясняет Пассмор, — потому что политика меняется».

По мнению Уэстфола из Current Analysis, дальнейшему распространению управления с помощью правил мешают препятствия в таких областях, как совместимость и масштабируемость. «Пользователи должны быть уверены, что система управления с помощью правил будет не только работать в гетерогенной среде, но и масштабироваться, как обещано». В особенности в случае таких приложений, как голос по IP (Voice over IP, VoIP), рассматривающие данный подход организации вряд ли рискнут делать ставку на столь незрелую технологию.

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

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

Другой вопрос — целостность транзакций. Хранилище должно быть способно выполнять совокупность связанных операций как одно целое. Без надлежащей целостности транзакций данные в хранилище могут оказаться испорченными.

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

Развиваемая DMTF инициатива Directory-Enabled Network (DEN) должна оказать значительное влияние на совместимость. Инициированная Microsoft и Cisco Systems в 1997 году, DEN была впоследствии передана DMTF. DEN должна быть включена в стандарт на общую информационную модель (Common Information Model, CIM). CIM составляет более общую схему, конечной целью которой является унифицированное управление элементами в рамках предприятия. (Схема каталога определяет объекты и атрибуты объектов.)

Одна из основных целей DEN — создать базовую схему каталога для предоставления совместимых услуг каталога. Она предусматривает не только обеспечение конфигурационного управления устройствами, но также управление QoS и управление с помощью правил.

Рисунок 2. Эта диаграмма иллюстрирует одно из преимуществ централизованного хранилища правил. Сервер правил А и сервер правил Б управляют своим собственным подмножеством устройств, таких, как коммутаторы и маршрутизаторы, но могут обмениваться информацией о правилах между собой. Подобная схема может пригодиться при управлении устройствами разных производителей. Таким образом, она позволяет преодолеть отсутствие совместимости, могущее представлять проблему в реализациях управления с помощью правил.

Несмотря на некоторые свои недостатки, в настоящее время LDAP является основным стандартом на доступ к каталогу при управлении с помощью правил. DMTF и IETF работают над отображением LDAP на информационную модель DEN, определяющую схемы и взаимоотношения между объектами для управления с помощью правил. Первая часть этого проекта состоит в логическом и физическом описании сетевых устройств и сервисов. На следующий шаг — описание правил и междоменных услуг — времени потребуется гораздо больше.

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

На Рисунке 2 приведена гипотетическая конфигурация системы управления с помощью правил, централизованное хранилище которой предоставляет механизм обеспечения совместимости.

НОВЫЕ ИЗМЕРЕНИЯ

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

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

Другой влияющий на масштабируемость фактор — нагрузка на сервер правил. Если число обслуживаемых устройств оказывается велико для одного сервера правил, то одним из вариантов решения может быть установка второго сервера. Устраняя одну проблему, такое решение увеличивает накладные расходы на администрирование и общие затраты. Другая проблема с несколькими серверами правил, как указывает Пассмор из The Burton Group, состоит в отсутствии стандартного протокола межсерверных коммуникаций. Кроме того, как он отмечает, распределение некоторых аспектов политики между несколькими серверами может привести к проблемам синхронизации правил.

Масштабируемость может быть улучшена за счет включения серверов правил в коммутаторы и маршрутизаторы, но такое решение входит в противоречие с централизованной системой управления с помощью правил. Кроме того, как отвечает Дэвид Косьер, эксперт из The Burton Group, необходимая со стороны коммутаторов и маршрутизаторов дополнительная вычислительная мощность может привести к значительному удорожанию таких устройств.

Разработчики выпускают продукты на базе целого ряда архитектур, вам же важно выбрать такой подход, чтобы он наилучшим образом отвечал требованиям вашей сети. (Некоторые общие сведения о реализациях разных разработчиков можно найти в статье Э. Кларк «Настройка барометра пропускной способности» в январском номере LAN за этот год.)

Стоимость — еще один требующий рассмотрения вопрос при планировании процесса реализации. В частности, обеспечивающие QoS устройства, такие, как коммутаторы и маршрутизаторы, обычно обходятся дороже, чем их менее «интеллектуальные» собратья. Устройства со встроенными серверами правил могут иметь еще большую цену.

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

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

Элизабет Кларк — исполнительный редактор. С ней можно связаться по адресу: eclark@mfi.com.

Разногласия по поводу каталогов

Ресурсы Internet