Обращали ли вы когда-либо внимание, что, как только какая-нибудь тема становится «горячей», ничего полезного по данному предмету уже не удается услышать? Если тема привлекает внимание прессы, то все, кому не лень, стараются высказаться на сей счет из желания обратить на себя внимание — и при этом совершенно неважно, насколько этот предмет им знаком. В результате реальные факты часто просто теряются среди пустопорожних комментариев. Этот принцип хорошо иллюстрирует ажиотаж вокруг ориентированных на каталог сетей (Directory Enabled Network, DEN).

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

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

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

Что же может DEN? Это зависит от ряда факторов.

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

Затем это вопрос о наличии единого стандарта для обеспечения совместимости. Как скажет вам любой специалист, два стандарта — это все равно что ни одного. Сегодня же мы имеем по крайней мере два конкурирующих подхода к централизованным каталогам — NDS компании Novell и Active Directory компании Microsoft. Некоторые разработчики, во всяком случае пока, примыкают только к одному какому-нибудь лагерю, а это означает, что если все ваши поставщики аппаратного и программного обеспечения не придерживаются одинаковой стратегии в области каталогов, то от DEN будет намного меньше пользы.

Еще один вопрос — насколько действительно полезно расширение прикладных сервисов каталога. В наши дни, когда стоимость коммутатора в расчете на порт составляет порядка 80 долларов, пропускная способность локальной сети стоит дешевле, чем управление пропускной способностью локальной сети, так что оно может оказаться сложным решением простой проблемы. Кроме того, многие организации вполне довольны имеющимися системами управления ресурсами. И вовсе не обязательно, что они получат какую-нибудь пользу от применения методов управления на базе DEN.

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

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

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