Проблемы взаимодействия операционных систем в гетерогенных сетях
Понятия "internetworking" и "interoperability"
До недавнего времени проблемы межсетевого взаимодействия не очень волновали отечественных пользователей и системных администраторов. Они уютно себя чувствовали в замкнутом мире IBM PC совместимых компьютеров, сетей Novell и сетевых адаптеров Ethernet, хотя в "большом" мире многие фирмы, в том числе и Novell, успешно продавали различные средства межсетевой связи. Однако пора монокультурного развития отечественных сетей заканчивается, организации приобретают различную технику, например, бизнес-серверы Hewlett-Packard, графические станции Sun или Silicon Graphics, мини-компьютеры AS-400 фирмы IBM и другую не менее достойную аппаратуру с разнообразными операционными системами, поэтому проблемы, характерные для западных корпоративных сетей, постепенно становятся актуальными и для нас.
Прежде, чем приступить к рассмотрению межсетевого взаимодействия, уточним, что понимается под термином "сеть". Этот термин может употребляться в широком смысле (сеть - это совокупность связанных между собой компьютеров) и в узком смысле (сеть - это совокупность компьютеров, соединенных между собой в соответствии с одной из стандартных типовых топологий - шина, звезда, кольцо, и использующих для передачи пакетов один из протоколов канального уровня, определенный для этой топологии).
Каждая сеть имеет свой номер, который используется на сетевом уровне при выполнении маршрутизации. Когда две или более сетей организуют совместную транспортную службу, то такой режим взаимодействия обычно называют межсетевым взаимодействием (internetworking). Для обозначения составной сети в англоязычной литературе часто также используются термины интерсеть(internetwork или internet). Интерсеть обеспечивает только передачу пакетов, не занимаясь их содержанием.
Так как понятие "номер сети" определяется на сетевом уровне, то оно является относительным, то есть, если в одном компьютере установлено программное обеспечение, поддерживающее несколько протоколов сетевого уровня (например, TCP и SPX), то данный компьютер может принадлежать нескольким сетям.
При рассмотрении вопросов межсетевого взаимодействия часто используется еще один англоязычный термин - interoperability. В то время как термин internetworking обозначает взаимодействие сетей на нижних уровнях, непосредственно связанных с транспортировкой пакетов, в понятие interoperability входит обеспечение согласования верхних уровней стека коммуникационных протоколов, реализуемых серверами и редиректорами операционных систем и некоторыми сетевыми приложениями.
Гетерогенность
Только небольшое количество сетей обладает однородностью (гомогенностью) программного и аппаратного обеспечения. Однородными чаще являются сети, которые состоят из небольшого количества компонентов от одного производителя.
Немногие организации имеют сети, составленные из оборудования, например, только IBM или DEC. Дни сетей от одного производителя миновали. Нормой сегодняшнего дня являются сети неоднородные (гетерогенные), которые состоят из различных рабочих станций, операционных систем и приложений, а для реализации взаимодействия между компьютерами используют различные протоколы. Разнообразие всех компонентов, из которых строится сеть, порождает еще большее разнообразие структур сетей, получающихся из этих компонентов. А если продолжить далее, и рассмотреть более сложные образования, получающиеся в результате объединения отдельных сетей в единую большую сеть, то становится понятным то множество проблем, связанных с проектированием, администрированием и управлением такой гетерогенной интерсетью. В идеале это объединение неоднородных сетей должно быть прозрачным для пользователя.
Так как сети создавались большей частью случайным образом, то приобретенные компьютеры и ОС отвечают, как правило, индивидуальным потребностям группы пользователей. Сети отдела строились для решения конкретных задач групп сотрудников. Например, инженерный отдел мог выбрать рабочие станции SPARC фирмы Sun Microsystems, соединенные сетью Ethernet, потому что им нужны были приложения, работающие только в среде UNIX. Разделение файлов при этом реализовывалось с помощью TCP/IP и NFS. В отделе продаж той же самой организации уже могли быть куплены компьютеры PS/2, установлена сеть Token Ring и операционная система NetWare для решения их собственных задач: ведения базы данных о клиентах, подготовки писем, разработки коммерческих предложений. Затем в рекламном отделе были выбраны компьютеры Macintosh, поскольку они наилучшим образом подходят для создания презентационных материалов. Macintosh'и соединены посредством LocalTalk, а файлы и принтеры разделяются с использованием AppleTalk. Отдел, отвечающий за автоматизацию предприятия, должен интегрировать все эти плохо совместимые системы в единый прозрачный организм.
Добавление в вычислительную сеть новых, чужеродных элементов может происходить и при всякой значительной реорганизации предприятия, например, при смене владельца, что для нашей страны сейчас тоже становится весьма обычным делом. В этом случае вновь приобретенное предприятие и его вычислительное оборудование также должно быть интегрировано в общую структуру предприятия нового владельца.
Основные подходы к реализации взаимодействия сетей
Основные проблемы при организации взаимодействия различных сетей связаны с тем, что эти сети используют различные стеки коммуникационных протоколов. В каждом конкретном стеке протоколов, будь то стек DoD или Novell NetWare, средства, реализующие какой-либо уровень, обеспечивают интерфейс для вышележащего уровня своей системы и пользуются услугами интерфейсных функций нижележащего уровня. Например, средства реализации протокола Novell IPX в сервере предоставляют интерфейсные услуги протоколу NCP для приема запросов от рабочих станций и пересылки им ответов. В свою очередь протокол IPX пользуется интерфейсными функциями драйвера сетевого адаптера Ethernet, чтобы передать пакет для отправки в сеть.
Если бы в компьютерном мире существовал только один стек протоколов, то у независимых разработчиков сетевого и программного обеспечения не было бы никаких проблем: сетевые адаптеры вместе со своими драйверами подходили бы к любой сетевой ОС за счет единого интерфейса между канальным и сетевым уровнями, разработчики транспортных средств новых ОС могли бы использовать существующие реализации протокола сетевого уровня, а разработчики сетевых приложений использовали бы единый API для обращения к сервисным услугам прикладного уровня ОС.
К сожалению, в реальном мире компьютерных сетей существует несколько стеков протоколов, уже завоевавших свое место под солнцем и не собирающихся его уступать. Например, если на предприятии используются мейнфреймы IBM, то они скорее всего используют протоколы сетевой архитектуры SNA и аппаратуру Token Ring. Использование компьютеров DEC с операционной системой VAX означает, что используются протоколы DECnet и Ethernet. Сети локальных компьютеров используют чаще всего протоколы Novell NetWare, Banyan VINES, IBM LAN Server или Microsoft LAN Manager с аппаратурой Ethernet, Token Ring или ARCnet.
Существование многих стеков протоколов не вносит никаких проблем до тех пор, пока не появляется потребность в их взаимодействии, то есть потребность в доступе пользователей сети NetWare к мейнфрейму IBM или пользователей графических рабочих станций UNIX к компьютеру VAX. В этих случаях проявляется несовместимость близких по назначению, но различных по форматам данных и алгоритмам протоколов.
Общность различных стеков протоколов проявляется только на нижних уровнях - физическом и канальном. Здесь в настоящее время почти нет проблем для взаимодействия, так как большинство стеков могут использовать общие протоколы Ethernet, Token Ring, FDDI. Исключение составляют только мейнфреймы IBM, которые на нижнем уровне в основном используют протоколы типа ведущий-ведомый с синхронной передачей данных, ориентированные на иерархическую соподчиненную структуру мейнфрейм - групповой контроллер - терминалы. Да и соединение двух компьютеров, использующих на нижнем уровне различные протоколы, а на верхних - одинаковые не составляет проблемы - эта задача решается аппаратно с помощью транслирующего моста или маршрутизатора.
Сложнее обстоит дело с сопряжением сетей, использующие различные протоколы верхних уровней, начиная с сетевого. Задачи согласования протоколов верхних уровней решить труднее из-за большей сложности этих протоколов и их разнообразия - чем большим интеллектом обладает протокол, тем больше у него аспектов и граней, по которым он может отличаться от своего собрата по функциональному назначению. Сложно осуществить трансляцию транспортных протоколов (таких, как IP и IPX), но гораздо сложнее совместить протоколы верхнего, прикладного уровня, с помощью которых клиенты получают сервис у серверов.
Если рассмотреть наиболее часто используемый в сетях сервис, а именно, файловый сервис, то различия в протоколах файлового сервиса в первую очередь связаны с различиями структур файловых систем. Например, пользователю MS-DOS непривычны приемы монтирования файловой системы UNIX в одно дерево, он хочет работать с разрозненными файловыми системами отдельных носителей, отображенными на буквы английского алфавита. Команды, используемые при работе с различными файловыми системами, также различны как по названию, так и по содержанию. Кроме того, даже для одной файловой системы в различных операционных системах предусмотрены различные удаленные сервисы. В ОС UNIX можно работать с удаленной файловой системой с помощью символьных команд протокола прикладного уровня FTP, переписывая файлы с удаленной машины на локальную по одному, а можно работать с протоколом NFS, который обеспечивает монтирование удаленной системы в локальную и требует других команд и приемов. Поэтому проблемы, возникающие на верхних уровнях, гораздо сложнее, чем проблемы замены заголовка пакета на канальном уровне.
Рис. 3.13. Два основных варианта согласования протоколов
а - трансляция протоколов; б - мультиплексирование стеков протоколов
Для организации взаимодействия различных сетей в настоящее время используется два подхода.
Первый подход связан с использованием так называемых шлюзов, которые обеспечивают согласование двух стеков протоколов путем преобразования (трансляции) протоколов (рисунок 3.13,а). Шлюз размещается между взаимодействующими сетями и служит посредником, переводящим сообщения, поступающие от одной сети, в формат другой сети.
Второй подход заключается в том, что в операционные системы серверов и рабочих станций встраиваются несколько мирно сосуществующих наиболее популярных стеков протоколов. Такая технология получила название мультиплексирования стеков протоколов. За счет ее использования либо клиентские запросы используют стек протоколов той сети, к которой относятся нужные серверы, либо серверы подключают стек протоколов, соответствующий поступившему клиентскому запросу (рисунок 3.13,б).
Взаимодействие компьютеров, принадлежащих разным сетям, напоминает общение людей, говорящих на разных языках. Для достижения взаимопонимания они также могут использовать два подхода: пригласить переводчика (аналог шлюза), или перейти на язык собеседника, если они им владеют (аналог мультиплексирования стеков протоколов).
Каждый из подходов имеет свои преимущества и недостатки, на которых мы остановимся позже.
Шлюзы
Итак, шлюз согласует коммуникационные протоколы одного стека с коммуникационными протоколами другого стека. Программные средства, реализующие шлюз, нет смысла устанавливать ни на одном из двух взаимодействующих компьютеров с разными стеками протоколов, гораздо рациональнее разместить их на некотором компьютере-посреднике. Прежде, чем обосновать это утверждение, рассмотрим принцип работы шлюза.
Рисунок 3.14 иллюстрирует принцип функционирования шлюза. В показанном примере шлюз, размещенный на компьютере 2, согласовывает протоколы клиентского компьютера 1 сети А с протоколами серверного компьютера 3 сети В. Допустим, что две сети используют полностью отличающиеся стеки протоколов. Как видно из рисунка, в шлюзе реализованы оба стека протоколов.
Рис. 3.14. Принципы функционирования шлюза
Запрос от прикладного процесса клиентского компьютера сети А поступает на прикладной уровень его стека протоколов. В соответствии с этим протоколом на прикладном уровне формируются соответствующий пакет (или несколько пакетов), в которых передается запрос на выполнение сервиса некоторому серверу сети В. Пакет прикладного уровня передается вниз по стеку компьютера сети А, а затем в соответствии с протоколами канального и физического уровней сети А поступает в компьютер 2, то есть в шлюз.
Здесь он передается от самого нижнего к самому верхнему уровню стека протоколов сети А. Затем пакет прикладного уровня стека сети А преобразуется (транслируется) в пакет прикладного уровня серверного стека сети В. Алгоритм преобразования пакетов зависит от конкретных протоколов и, как уже было сказано, может быть достаточно сложным. В качестве общей информации, позволяющей корректно провести трансляцию, может использоваться, например, информация о символьном имени сервера и символьном имени запрашиваемого ресурса сервера (в частности, это может быть имя каталога файловой системы). Преобразованный пакет от верхнего уровня стека сети В передается к нижним уровням в соответствии с правилами этого стека, а затем по физическим линиям связи в соответствии с протоколами физического и канального уровней сети В поступает в другую сеть к нужному серверу. Ответ сервера преобразуется шлюзом аналогично.
Мультиплексирование стеков протоколов
Вторым использующимся в настоящее время на практике подходом является использование в рабочих станциях технологии мультиплексирования различных стеков протоколов.
Рис. 3.15. Мультиплексирование стеков
При мультиплексировании стеков протоколов на один из двух взаимодействующих компьютеров с различными стеками протоколов помещается коммуникационный стек другого компьютера. На рисунке 3.15 приведен пример взаимодействия клиентского компьютера сети 1 с сервером своей сети и сервером сети 2, работающей со стеком протоколов, полностью отличающимся от стека сети 1. В клиентском компьютере реализованы оба стека. Для того, чтобы запрос от прикладного процесса был правильно обработан и направлен через соответствующий стек, в компьютер необходимо добавить специальный программный элемент - мультиплексор протоколов. Мультиплексор должен уметь определять, к какой сети направляется запрос клиента. Для этого может использоваться служба имен сети, в которой отмечается принадлежность того или иного ресурса определенной сети с соответствующим стеком протоколов.
При использовании технологии мультиплексирования структура коммуникационных средств операционной системы может быть и более сложной. В общем случае на каждом уровне вместо одного протокола появляется целый набор протоколов, а мультиплексоров может быть несколько, выполняющих коммутацию между протоколами разных уровней (рисунок 3.16). Например, рабочая станция может получить доступ к сетям с протоколами NetBIOS, IP, IPX через один сетевой адаптер. Аналогично, сервер, поддерживающий прикладные протоколы NCP, SMB и NFS может без проблем выполнять запросы рабочих станций сетей NetWare, Windows NT и Sun одновременно.
Рис. 3.16. Мультиплексирование протоколов
Предпосылкой для развития технологии мультиплексирования стеков протоколов стало строгое определения протоколов и интерфейсов различных уровней и их открытое описание, так, чтобы фирма при реализации "чужого" протокола или интерфейса могла быть уверена, что ее продукт будет правильно взаимодействовать с продуктами других фирм по данному протоколу.
Использование магистрального протокола
Хорошим решением был бы переход на единый стек протоколов, но вряд ли эта перспектива осуществится в ближайшем будущем. Попытка введения единого стека коммуникационных протоколов сделана в 1990 году правительством США, которое обнародовало программу GOSIP - Government OSI Profile, в соответствии с которой стек протоколов OSI должен стать общим знаменателем для всех сетей, устанавливаемых в правительственных организациях США. Но, понимая бесполезность силовых мер, программа GOSIP не ставит задачу немедленного перехода на стек OSI, а принуждает пока к использованию этого стека в качестве "второго языка" правительственных сетей, наряду с родным, первым.
Вопросы реализации
При объединении сетей различных типов в общем случае необходимо обеспечить двухстороннее взаимодействие сетей, то есть решить две задачи (рисунок 3.17):
1. Обеспечение доступа клиентам сети A к ресурсам и сервисам серверов сети B.
2. Обеспечение доступа клиентам сети B к ресурсам и сервисам сети A.
Рис. 3.17. Варианты сетевого взаимодействия
Эти задачи независимы и их можно решать отдельно. Прежде всего нужно понять, необходимо ли полное решение или достаточно и частичного, то есть нужно ли, чтобы пользователи, например, UNIX-машин имели доступ к ресурсам серверов сети NetWare, а пользователи персональных машин имели доступ к ресурсам UNIX-хостов, или же достаточно обеспечить доступ к ресурсам другой сети только одному виду пользователей.
Кроме того, каждую из этих задач можно в свою очередь разделить на части. В сети обычно имеются различные виды разделяемых ресурсов, и с каждым типом ресурсов могут предоставляться различные виды сервиса. Например, в UNIX-сетях файлы являются разделяемым ресурсом, и с ними связаны два вида сервиса - перемещение файлов между машинами по протоколу FTP и монтирование удаленной файловой системы по протоколу NFS. Поэтому при объединении сетей можно предложить пользователям набор средств, каждое из которых позволяет воспользоваться одним каким-либо сервисом чужой сети. Естественно, возможно объединение всех функций в рамках одного продукта.
При объединении сетей достаточно иметь средства взаимодействия сетей только в одной из сетей. Например, фирма Novell разработала ряд программных продуктов для связи с UNIX-сетями, которые достаточно включить в программное обеспечение сети NetWare, чтобы решить обе указанные задачи взаимодействия сетей. При этом серверной части UNIX клиент NetWare представляется UNIX-клиентом, а клиент UNIX обращается с файлами и принтерами, управляемыми сервером NetWare, как с UNIX-файлами и UNIX-принтерами. Возможен перенос средств взаимодействия сетей и на сторону UNIX-сети. Тогда аналогичные функции будут выполнять программные средства на UNIX-машине.
В то время, как расположение программных средств, реализующих шлюз, уже было определено - они должны располагаться на компьютере, занимающем промежуточное положение между двумя взаимодействующими машинами, вопрос о размещении дополнительных стеков протоколов остался открытым. Заметим также, что шлюз реализует взаимодействие "многие-ко-многим" (все клиенты могут обращаться ко всем серверам).
Рассмотрим все возможные варианты размещения программных средств, реализующих взаимодействие двух сетей, которые основаны на мультиплексировании протоколов. Введем некоторые обозначения: С - сервер, К - клиент, ( - дополнительный протокол или стек протоколов.
На рисунке 3.18 показаны оба возможных варианта однонаправленного взаимодействия А®В: а) путем добавления нового стека к клиентам сети А, либо б) путем присоединения "добавки" к серверам сети В.
В первом случае, когда средства мультиплексирования располагаются на клиентских частях, только клиенты, снабженные средствами мультиплексирования протоколов, могут обращаться к серверам сети В, при этом они могут обращаться ко всем серверам сети В. Во втором случае, когда набор стеков расположен на каком-либо сервере сети В, данный сервер может обслуживать всех клиентов сети А. Очевидно, что серверы сети В без средств мультиплексирования не могут быть использованы клиентами сети А.
Рис. 3.18. Варианты размещения программных средств
(С - cервер, К - клиент, ( - средства сетевого взаимодействия)
Примером "добавки", модифицирующей клиентскую часть, может служить популярное программное средство фирмы Novell LAN Workplace, которое превращает клиента NetWare в клиента UNIX. Аналогичным примером для модификации сервера могут служить другие продукты фирмы Novell: NetWare for UNIX, который делает возможным использование услуг сервера UNIX клиентами NetWare, или Novell NetWare for VMS, который служит для тех же целей в сети VMS.
Взаимодействие А ( В реализуется симметрично.
Если же требуется реализовать взаимодействие в обе стороны одновременно, то для этого существует четыре возможных варианта, показанных на рисунке 3.19. Каждый вариант имеет свои особенности с точки зрения возможностей связи клиентов с серверами:
Средства обеспечения взаимодействия расположены только на клиентских частях обеих сетей. Для тех и только тех клиентов обеих сетей, которые оснащены "добавками", гарантируется возможность связи со всеми серверами из "чужой" сети.
Все средства обеспечения взаимодействия расположены на стороне сети А. Все клиенты сети В могут обращаться к серверам сети А (не ко всем, а только к тем, которые имеют сетевую "добавку").Часть клиентов сети А, которые обозначены как К+(, могут обращаться ко всем серверам сети В.
Средства межсетевого взаимодействия расположены только на серверных частях обеих сетей. Всемклиентам обеих сетей гарантируется возможность работы с серверами "чужих" сетей, но не со всеми, а только с серверами, обладающими сетевыми средствами мультиплексирования протоколов.
Все средства межсетевого взаимодействия расположены на стороне В. Двусторонний характер взаимодействия обеспечивается модификацией и клиентских, и серверных частей сети В. Все клиенты сети А могут обращаться за сервисом к серверам сети В, обозначенным как С+(, а все серверы сети А могут обслуживать клиентов сети В, обозначенных как К+(.
Рис. 3.19. Варианты размещения программных средств при двустороннем взаимодействии
(С - cервер, К - клиент, ( - средства сетевого взаимодействия)
Очевидно, что наличие программных продуктов для каждого из рассмотренных вариантов сильно зависит от конкретной пары операционных систем. Для некоторых пар может вовсе не найтись продуктов межсетевого взаимодействия, а для некоторых можно выбирать из нескольких вариантов. Рассмотрим в качестве примера набор программных продуктов, реализующих взаимодействие Windows NT и NetWare. В ОС Windows NT и в серверной части (Windows NT Server), и в клиентских частях (Windows NT Workstation) предусмотрены встроенные средства мультиплексирования нескольких протоколов, в том числе и стека IPX/SPX. Следовательно эта операционная система может поддерживать двустороннее взаимодействие (по варианту 2) с NetWare без каких-либо дополнительных программных средств. Аналогичным образом реализуется взаимодействие сетей Windows NT с UNIX-сетями.
Сравнение вариантов организации взаимодействия сетей
Возвращаясь к принципам организации взаимодействия сетей, сравним два основных подхода - мультиплексирование протоколов и трансляцию протоколов (шлюзы).
Встроенные в сетевую ОС средства мультиплексирования протоколов дают все те преимущества, которые присущи встроенным средствам:
Эти средства не нужно отдельно приобретать;
Нет проблем их совместимости с другими продуктами.
Основным недостатком этого подхода является избыточность. Хотя средства мультиплексирования обычно позволяют загружать и выгружать по желанию пользователя различные стеки протоколов, но если нужно одновременно работать с тремя различными сетями, то в каждую рабочую станцию необходимо загрузить все три стека одновременно.
Шлюз по своей природе является выделенным сервисом, разделяемым всеми источниками запросов к серверам другой сети. Использование шлюзов обеспечивает следующие преимущества:
Позволяет сосредоточить все функции согласования протоколов в одном месте и разгрузить рабочие станции от дополнительного программного обеспечения, а их пользователей - от необходимости его генерации. Шлюз сохраняет в локальной сети ее родную среду протоколов, что повышает производительность, так как стек протоколов был специально спроектирован для данной операционной среды и наилучшим образом учитывает ее особенности.
Возникающие проблемы легко локализуются.
Обслуживающий персонал работает в привычной среде, где можно использовать имеющийся опыт по поддержанию сети. Шлюзы сохраняют различные, несовместимые сети в их первозданном виде. Если имеется несколько различных сетей, то для их совместной работы может понадобиться значительное количество шлюзов. Для доступа пользователей сети UNIX к мейнфрейму понадобится шлюз UNIX-SNA, для подключения пользователей NetWare к компьютерам UNIX и мейнфрейму нужно два шлюза - NetWare-UNIX и NetWare-SNA.
Недостатки использования шлюзов:
Шлюзы работают, как правило, медленно; пользователи замечают уменьшение производительности при обращении к другой сети через шлюз.
Шлюз как централизованное средство понижает надежность сети.
Службы именования ресурсов и проблемы прозрачности доступа
Подобно большой организации, большая корпоративная сеть нуждается в централизованном хранении как можно более полной справочной информации о самой себе (начиная с данных о пользователях, серверах, рабочих станциях и кончая данными о кабельной системе). Естественно организовать эту информацию в виде базы данных, ведение которой поручить сетевой операционной системе. Данные из этой базы могут быть востребованы многими сетевыми системными приложениями, в первую очередь системами управления и администрирования. Кроме этого, такая база полезна при организации электронной почты, систем коллективной работы, службы безопасности, службы инвентаризации программного и аппаратного обеспечения сети, да и для практически любого крупного бизнес-приложения.
Хотя полезных применений единой справочной службы много, она нужна по крайней мере для эффективного решения задачи администрирования, то есть ведения учетной информации на пользователей сети и определения прав доступа этих пользователей к разделяемым ресурсам сети. Эта задача всегда решалась каким-либо способом во всех многопользовательских операционных системах, не обязательно сетевых. В локальных версиях UNIX имеются файлы с предопределенными именами, хранящие эту информацию - например, файл /etc/passwd хранит информацию о пользователях и их паролях, а также о группах пользователей.
В идеале сетевая справочная информация должна быть реализована в виде единой базы данных, а не представлять собой набор баз данных, специализирующихся на хранении информации того или иного вида, как это часто бывает в реальных операционных системах. Например, в Windows NT имеется по крайней мере пять различных типов справочных баз данных. Главный справочник домена (NT Domain Directory Service) хранит информацию о пользователях, которая используется при организации их логического входа в сеть. Данные о тех же пользователях могут содержаться и в другом справочнике, используемом электронной почтой Microsoft Mail. Еще три базы данных поддерживают разрешение низкоуровневых адресов: WINS - устанавливает соответствие Netbios-имен IP-адресам, справочник DNS - сервер имен домена - оказывается полезным при подключении NT-сети к Internet, и наконец, справочник протокола DHCP используется для автоматического назначения IP-адресов компьютерам сети. Ближе к идеалу находятся справочные службы, поставляемые фирмой Banyan (продукт Streettalk III) и фирмой Novell (NetWare Directory Services), предлагающие единый справочник для всех сетевых приложений.
Единая база данных, хранящая справочную информацию, предоставляет все то же многообразие возможностей и порождает все то же множество проблем, что и любая другая крупная база данных. Она позволяет осуществлять различные операции поиска, сортировки, модификации и т.п., что очень сильно облегчает жизнь как администраторам, так и пользователям. Набор разрозненных баз данных не предоставляет такого прозрачного доступа к ресурсам сети, как это имеет место в случае использования ОС NetWare 3.x с ее базой bindery, локальной для каждого сервера. В последнем случае пользователь должен заранее знать, на каком сервере находится нужный ему ресурс и производить логическое подключение к этому серверу для получения доступа к этому ресурсу. Для того, чтобы получить доступ к ресурсам какого-нибудь сервера, пользователь должен иметь там свою учетную информацию, которая дублируется таким образом на всех серверах сети. В единой базе данных о каждом пользователе существует только одна запись.
Но за удобства приходится расплачиваться решением проблем распределенности, репликации и синхронизации, которые возникают при построении крупномасштабной базы данных для большой сети.
Реализация справочной службы над полностью централизованной базой данных, хранящейся только в виде одной копии на одном из серверов сети, не подходит для большой системы по нескольким причинам, и в первую очередь из-за низкой производительности и низкой надежности такого решения. Производительность будет низкой из-за того, что запросы на логический вход всех пользователей будут поступать в единственный сервер, который при большом количестве пользователей обязательно перестанет справляться с их обработкой, то есть такое решение плохо масштабируется в отношении количества пользователей и разделяемых ресурсов. Надежность также не может быть высокой в системе с единственной копией данных. Кроме снятия ограничений по производительности и надежности, желательно, чтобы структура базы данных позволяла производить логическое группирование ресурсов и пользователей по структурным подразделениям предприятия и назначать для каждой такой группы своего администратора.
Проблемы сохранения производительности и надежности при увеличении масштаба сети решаются за счет использования распределенных баз данных справочной информации. Разделение данных между несколькими серверами снижает нагрузку на каждый сервер, а надежность при этом достигается за счет наличия нескольких копий (называемых часто репликами) каждой части базы данных. Для каждой части базы данных можно назначить своего администратора, который обладает правами доступа только к объектам своей порции информации о всей системе. Для пользователя же (и для сетевых приложений) такая распределенная база данных представляется единой базой данных, которая обеспечивает доступ ко всем ресурсам сети вне зависимости от того, с какой рабочей станции осуществил свой вход в сеть пользователь.
Существует два подхода к организации справочной службы сети: доменный и глобальный. Рассмотрим эти подходы на конкретных примерах - доменной справочной службе ОС Windows NT и глобальной справочной службе NDS ОС NetWare. Естественно, это не единственные операционные системы, где такие службы имеются - доменная служба реализована в Microsoft LAN Manager и IBM LAN Server, а глобальная справочная служба - в ОС Banyan VINES (служба Streettalk III). Более того, существует стандарт X.500, разработанный МККТТ для глобальной справочной службы почтовых систем, который с успехом может применяться и применяется для хранения любой справочной информации.
Доменный подход
Домен - это основная единица администрирования и обеспечения безопасности в Windows NT. Для домена существует общая база данных учетной информации пользователей (user accounts), так что при входе в домен пользователь получает доступ сразу ко всем разрешенным ресурсам всех серверов домена.
Доверительные отношения (trust relationships) обеспечивают транзитную аутентификацию, при которой пользователь имеет только одну учетную запись в одном домене, но может получить доступ к ресурсам всех доменов сети.
Рис. 3.20. Доверительные отношения между доменами
Пользователи могут входить в сеть не только из рабочих станций того домена, где хранится их учетная информация, но и из рабочих станций доменов, которые доверяют этому домену. Домен, хранящий учетную информацию, часто называют учетным, а доверяющий домен - ресурсным.
Доверительные отношения не являются транзитивными. Например, если домен А доверяет домену В, а В доверяет С, то это не значит, что А автоматически доверяет С.
Основной и резервные контроллеры домена
В домене должен находится сервер, выполняющий роль основного контроллера домена (primary domain controller). Этот контроллер хранит первичную копию базы данных учетной информации пользователей домена. Все изменения, производимые в учетной информации, сначала производятся именно в этой копии. Основной контроллер домена всегда существует в единственном экземпляре. Пользователь, который администрирует домен, не должен явно задавать имя компьютера, который выполняет роль основного контроллера, утилита, в помощью которой осуществляется администрирование (в Windows NT это User Manager for Domains), должна по имени домена самостоятельно, в соответствии с заранее разработанным протоколом провести диалог с основным контроллером домена и сделать нужные изменения в его базе данных.
Кроме основного контроллера в домене могут существовать несколько резервных контроллеров (backup domain controllers). Эти контроллеры хранят реплики базы учетных данных. Все резервные контроллеры в дополнение к основному могут обрабатывать запросы пользователей на логический вход в домен.
Резервный контроллер домена решает две задачи:
Он становится основным контроллером при отказе основного.
Уменьшает нагрузку на основной контроллер по обработке логических входов пользователей.
Если сеть состоит из нескольких сетей, соединенных глобальными связями, то в каждой сети должен быть по крайней мере один резервный контроллер домена.
Обычный сервер (не основной или резервный контроллер домена) может быть членом домена, а может и не быть. Если он принимает участие в домене, то он пользуется учетной информацией, хранящейся на контроллере домена. Если же нет - то доступ ко всем его ресурсам имеют только пользователи, которые заведены в базе учетной информации этого сервера.
Четыре модели организации связи доменов
Механизм доменов можно использовать на предприятии различными способами. В зависимости от специфики предприятия можно объединить ресурсы и пользователей в различное количество доменов, а также по-разному установить между ними доверительные отношения.
Microsoft предлагает использовать четыре типовые модели использования доменов на предприятии:
Модель с одним доменом;
Модель с главным доменом;
Модель с несколькими главными доменами;
Модель с полными доверительными отношениями.
Модель с одним доменом
Эта модель подходит для организации, в которой имеется не очень много пользователей, и нет необходимости разделять ресурсы сети по организационным подразделениям. Главный ограничитель для этой модели - производительность, которая падает, когда пользователи просматривают домен, включающий много серверов.
Использование только одного домена также означает, что сетевой администратор всегда должен администрировать все серверы. Разделение сети на несколько доменов позволяет назначать администраторов, которые могут администрировать только отдельные серверы, а не всю сеть.
Таблица 3.1.
Преимущества и недостатки модели с одним доменом
Преимущества
|
Недостатки
|
Наилучшая модель для предприятий с небольшим
числом пользователей и ресурсов
Централизованное управление пользовательской
учетной информацией
Нет нужды в управлении доверительными отношениями
Локальные группы нужно определять только однажды
|
Низкая производительность, если
домен имеет слишком много
пользователей и/или серверов
Невозможность группирования
ресурсов
|
|
