NETWARE И UNIX - ВМЕСТЕ

НА НЕКОГДА БЕСПЛОДНОЙ ПОГРАНИЧНОЙ ПОЛОСЕ МЕЖДУ NETWARE И UNIX НЫНЕ ВОЗДЕЛЫВАЮТСЯ НОВЫЕ СРЕДСТВА СОЕДИНЕНИЯ, ДОКАЗЫВАЮЩИЕ, ЧТО ВЫ СМОЖЕТЕ ДОБРАТЬСЯ ОТТУДА СЮДА.

У Wells Fargo богатая история. Многие, услышав это название, наверняка вспомнят один из первых финансовых институтов, оставивших свой опознавательный знак на границе американского Дикого Запада.

Сие учреждение Сан-Франциско недавно открыло новую главу в своем первопроходчестве, однако на этот раз с технологическим уклоном. Wells Fargo Bank, стремясь уменьшить время обслуживания клиентов, перенес все накопленные за долгие годы данные с мэйнфрейма IBM 3090 в базу данных Oracle (Redwood Shores, CA), на Unix-сервере компании Sun Microsystems (Mountain View, CA). Сотрудники фирмы, непосредственно занятые обслуживанием клиентов, используют ПК, соединенные локальными сетями NetWare. Для Oracle необходим клиентский компонент, SQL*Net, который может выполняться как над стеком протоколов IPX компании Novell, так и над стеком протоколов TCP/IP.

Использование SQL*Net for IPX требует, чтобы серверы Sun имели стеки IPX (поставляемые Sun), взаимодействующие со стеками NetWare IPX на ПК. Но Wells Fargo Bank выбрал SQL*Net for TCP/IP. Таким образом, серверы Sun продолжают взаимодействовать посредством привычного TCP/IP, в то время как ПК учатся общаться не только с помощью IPX, но и TCP/IP.

Решение использовать TCP/IP позволило убить сразу двух зайцев. Во-первых, большинство соединенных с локальной сетью компьютеров, например, IBM 3090, поддерживают TCP/IP. Во-вторых, - как отмечает руководитель разработки прикладных систем для обслуживания клиентов Боб Оуэнс, "стратегическое направление банка - это TCP/IP, а не используемый на мэйнфреймах SNA".

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

Администраторы корпоративных сетей должны обеспечить клиентам NetWare доступ к Unix-серверам, часто посредством TCP/IP, и при этом сохранив управляемость глобальной сети и сети масштаба предприятия. Проделать это надо с минимальными затратами, не нарушая нормальной работы.

В этой статье мы рассмотрим доводы "за" и "против" трех методов доступа к Unix-системам из NetWare.

СПИСОК ПОЖЕЛАНИЙ

Сравнивая средства связи NetWare с Unix, руководствуйтесь следующим "списком пожеланий":

Помня об этих критериях, исследуем три основных пути, которые ведут из NetWare в Unix.

ЦЕЛЬ - UNIX

Чтобы добраться из NetWare в Unix, вам потребуются две вещи: протокол, общий для обоих типов систем, и некая прикладная программа, работающая с этим протоколом. Ею может быть база данных, например Oracle с клиентом на базе ПК и сервером на базе Unix, эмулятор терминала, такой как telnet, или система передачи файлов, скажем, ftp, или программа просмотра для доступа к Internet.

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

Первый - выполнение стека TCP/IP на каждом клиенте NetWare в параллель с IPX. Связанные с Unix приложения на ПК выполняются над TCP/IP. Примеры стеков TCP/IP для рабочих станций включают LAN WorkPlace и LAN WorkGroup компании Novell, PC/TCP OnNet компании FTP Software (North Andover, CA) и Chameleon компании NetManage (Cupertino, CA).

Второй способ реализации протоколов - шлюз или разделяемый стек TCP/IP, обычно выполняющийся маршрутизатором или сервером NetWare. В этой конфигурации ПК-клиенты выполняют только IPX. Интересующий нас трафик между клиентом и разделяемым стеком TCP/IP опирается на IPX, а между разделяемым стеком TCP/IP и сервером Unix - на IP. Примером может служить Nov*IX компании FireFox (San Jose, CA).

В третьем варианте стек IPX устанавливается на сервере Unix, а клиенты выполняют только IPX. Связанные с Unix приложения для взаимодействия между клиентами и сервером Unix используют IPX. Пример - PC Protocol Services for Solaris компании SunSoft (Chelmsford, MA). Стек SunSoft IPX позволяет пользователям NetWare выполнять приложения Solaris. Другой продукт SunSoft, PC Server Services, предоставляет клиентам NetWare доступ к сервисам файлов и печати ОС Solaris.

Выбрав один из трех вариантов реализации протоколов, вам также необходимо выбрать, где выполнять такие сервисы NetWare, как сервисы файлов и печати. Обычно они предоставляются выделенным сервером NetWare, но возможно, и Unix-компьютером.

"NetWare-на-Unix" часто реализуют вместе со стеком IPX на сервере Unix. Первым примером такой реализации была система Portable NetWare. Среди современных продуктов этого типа - NetWare for SCO Unix компании Acer America (San Jose), NWserver компании Syntax (Federal Way, WA), NetWare for UnixWare компании Novell. (UnixWare - это ОС Unix по версии Novell.)

Есть еще две перспективных стратегии интеграции NetWare и Unix. Для некоторых организаций и приложений фундаментом для интеграции может служить Распределенная Вычислительная Среда (DCE, Distributed Computing Environment). Например, компания Gradient Technologies (Marlboro, MA) предлагает продукт PC-DCE, который преобразует любую машину под Windows, а также клиентов NetWare в клиентов DCE, обеспечивая доступ из NetWare к любому хосту DCE.

Наконец, надо упомянуть еще один вариант, связанный с протоколом: NetWare/IP. Хотя этот вариант сам по себе и не обеспечивает доступ к системам Unix, он позволяет выполнять NetWare на IP, исключая IPX. NetWare/IP поддерживает также интерфейсы Winsock и LAN WorkPlace API, которые, вместе с совместимыми с ними продуктами, могут обеспечить доступ к Unix.

ПОГРАНИЧНЫЙ МЕНТАЛИТЕТ

Главное преимущество - и недостаток - продукта, реализующего TCP/IP на клиенте, такого как LAN WorkPlace компании Novell, можно выразить одним словом: независимость. TCP/IP позволяет всем клиентам работать независимо друг от друга и от сервера NetWare, когда он работает с TCP/IP.

Преимущество в том, что при оптимизации производительности вам не придется иметь дело со шлюзом, который может оказаться узким местом. Каждая рабочая станция взаимодействует непосредственно с другими устройствами TCP/IP. Конечно, узкие места могут возникать и за пределами шлюза. При использовании медленного сервера Unix оба решения - и шлюз, и TCP/IP на клиенте - скорее всего обеспечат одинаково низкий уровень производительности.

TCP/IP на клиенте является также отказоустойчивым решением. Каждый клиент - это самодостаточный сетевой узел; сбой одного клиента не влияет на других.

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

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

Часть продуктов, реализующих TCP/IP на клиенте, поддерживает централизованное управление и хранение файлов. Например, программное обеспечение Novell LAN WorkGroup инсталлируется и конфигурируется на сервере и загружается на клиенты по их требованию. Для решения некоторых проблем определенных ситуациях может понадобиться обратиться к рабочей станции, но обычные операции конфигурирования и управления, впрочем как и часть работы по устранению неисправностей, могут выполняться централизованно всяким, кто наделен соответствующими привилегиями.

Однако, пользователям, не имеющим таких прав, нельзя изменять свою конфигурацию, - Netware и LAN WorkGroup могут запретить загрузку TCP/IP с сервера для незарегистрированных пользователей.

Таким образом, централизованное управление обладает преимуществами безопасности и контроля.

Оно предоставляет также новые возможности управления IP-адресами. В случае "чистой" реализации TCP/IP на клиенте (без центрального управления), у каждой рабочей станции должен быть свой собственный IP-адрес, присваиваемый и изменяемый на самой этой станции. Централизованное управление позволяет администратору сети присваивать и изменять IP-адреса с одной консоли управления.

Кроме того, адреса могут быть организованы в пулы. По этой схеме каждая рабочая станция имеет свой собственный IP-адрес, пока использует IP-сеть. Когда же она прекращает ее использовать, IP-адрес может быть передан другой станции. В случае LAN WorkPlace, напротив, каждая рабочая станция имеет собственный постоянный IP-адрес.

Заметим, что централизованное хранение файлов имеет и ряд недостатков. Например, если файловый сервер перестает работать, рабочие станции не смогут загрузить TCP/IP, хотя существующие соединения TCP/IP не разрываются. В LAN WorkPlace сервер ведет себя с полным безразличием по отношению к соединениям TCP/IP.

ЛУЧШЕ ЛИ ЭТА ДОРОГА?

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

Шлюзы обычно обеспечивают более гибкое управление IP-адресами, чем стеки TCP/IP на клиенте. Например, хотя TCP/IP на клиенте и допускает организацию адресов в пулы, обычно нескольким рабочим станциям не разрешается разделять один адрес. При использовании шлюза типа Nov*IX для всех рабочих станций в локальной сети может использоваться единый адрес. Шлюз действует как мультиплексор адресов, он разделяет IP-трафик для различных рабочих станций, опираясь на информацию о номере порта (каждая рабочая станция имеет свой собственный номер порта).

Совсем не обязательно, что шлюз будет ограничиваться разделением единого адреса. Кстати сказать, упомянутый выше Nov*IX может обеспечить организацию пулов адресов и мультиплексирование адресов в любой комбинации. Например, такие приложения, как X Window, возможно, будут время от времени помещать в пулы IP-адреса для пользователей, нуждающихся в индивидуальных адресах. Два различных подразделения, например, отдел продаж и исследовательский отдел, могут одновременно пользоваться двумя адресами. Другие IP-адреса могут быть соотнесены с идентификаторами пользователей или групп пользователей NetWare.

Наконец, некоторые IP-адреса могут быть постоянно связаны с аппаратными адресами локальной сети. Вероятно, этот вариант подходит для ftp-сервера, который всегда выполняется на одной и той же машине и должен иметь стабильный адрес, так чтобы приложения могли найти его с помощью DNS (Domain Name Service). DNS - наиболее общий механизм доступа по запросам к ресурсам в Unix-сетях.

Пользователи обычно запрашивают ресурс, например, сервер X Window или ftp-сервер, по имени. DNS определяет по этому имени IP-адрес, используемый приложением для обнаружения и связи с сервером. Независимо от того, как распределены IP-адреса, информация о конфигурации (например, подразумеваемый шлюз и DNS-сервер) связывается с IP-адресом.

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

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

ПЕРВОПРОХОДЦАМ INTERNET

Организации, которые хотят сделать свои сети частью Internet, могут сильно упростить себе жизнь, ограничив число необходимых им адресов хостов (см. врезку "Все дело в размерах").

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

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

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

КАК ПОСТРОИТЬ СТЕК IPX

Большинство поставщиков Unix предоставляют теперь и стеки IPX. Это, в частности, делает возможным использование IPX для доступа к серверам баз данных на Unix. Основное преимущество подхода IPX-на-Unix состоит в том, что в локальной сети ничего не надо изменять. Ни клиенты, ни файловые серверы NetWare не затрагиваются.

Администратору Unix теперь придется исправлять неисправности и оптимизировать производительность стека протоколов IPX. Кроме того, маршрутизаторы между локальной сетью и сервером Unix должны будут выполнять функции маршрутизатора (или моста) для IP, усложняя тем самым управление глобальной сетью.

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

На фундаменте IPX поставщик Unix может также реализовать доступ к сервисам файлов и печати в Unix, так чтобы Unix-сервер обеспечивал те же самые базовые функции, что и сервер NetWare. Если двигаться в этом направлении дальше, можно предоставить пользователям возможность выполнять саму NetWare на Unix. NetWare-на-UnixWare - последнее предложение Novell на данном сегменте рынка.

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

В организациях с большим опытом использования Unix ловкие специалисты смогут управлять сервером NetWare-на-UnixWare с помощью инструментов и процедур управления Unix. В то же время, загрузку повседневно выполняемых раздробленных операций управления NetWare, например, связанных с управлением доступа к файлам и с регистрацией пользователей, можно выполнять на ПК с помощью стандартных утилит NetWare. В большинстве случаев для выполнения любой такой функции управления есть выбор между утилитами управления NetWare и Unix. "Девяносто восемь процентов всех ваших знаний по администрированию NetWare полностью переносятся в NetWare-на-UnixWare", - считает Кейт Браун, менеджер по маркетингу Novell Unix Systems Group (USG, San Jose, CA).

Два основных недостатка - это, вероятно, производительность и отсутствие поддержки загружаемых модулей NetWare. Браун говорит, что производительность NetWare-на-UnixWare часто будет "очень сравнима" с производительностью настоящей NetWare на той же самой платформе. Однако так уж повелось, что настоящая ОС NetWare обычно превосходила по производительности NetWare, выполняющуюся в среде Unix. "Даже если производительность по-прежнему будет отставать, расхождение может стать менее существенным по мере того, как аппаратные платформы будут становиться более мощными, а в NetWare и UnixWare появятся возможности многопроцессорной обработки", - считает Майкл Гаулд, аналитик Patricia Seybold Group, консультационной фирмы из Бостона.

"Когда NetWare выполнялась на машине с процессором Intel 286, скорость NetWare была очень важна", - говорит Гаулд. - "Сегодня, когда доступны очень быстрые и очень недорогие машины, оптимизация программного обеспечения теряет свое значение по сравнению с такими проблемами, как масштабируемость, управляемость и надежность. А Unix, включая UnixWare, - это вообще более масштабируемая, управляемая и надежная платформа для сервера приложений, чем обычная NetWare", - замечает Гаулд. - "Следовательно", - говорит он, - "по мере того, как центр внимания корпоративных пользователей будет сдвигаться к сервисам приложений масштаба предприятия, такие продукты, как UnixWare, NetWare-на-UnixWare и, наконец, SuperNOS, будут играть все более важную роль в стратегии Novell по обеспечению сервисов приложений".

Первоначально, в NetWare-на-UnixWare не будут выполняться модули NLM; разработчикам программного обеспечения придется создавать Unix-приложения. "Поддержка NLM под NetWare-на-UnixWare может появиться через несколько лет", - обещает Браун. Выполнение NLM может заинтересовать пользователей, поскольку это означает, что не придется отбрасывать имеющееся NLM только для того, чтобы использовать NetWare-на-UnixWare. Для тех, кто покупает новые программы, следует отметить, что NLM, как правило, стоят гораздо меньше эквивалентных Unix-приложений.

С другой стороны, еще не ясно, какие недостатки, например, снижение производительности или надежности, могут проявиться при выполнении NLM в среде NetWare-на-UnixWare. n

SUPERNOS - МАЛЕНЬКАЯ ПЕРЕДЫШКА НА ПУТИ ОТ NETWARE К UNIX

КАК ЭТО ДОЛЖНО БЫТЬ

Операционная система SuperNOS компании Novell, объединяющая NetWare и UnixWare, станет доступна в ближайшие несколько лет. Общие для обеих ОС функции реализует микроядро, над которым в качестве приложений будут выполняться NetWare и UnixWare. Майкл Гаулд, аналитик Patricia Seybold Group, консультационной фирмы из Бостона, считает, что SuperNOS будет делать то же самое, что и NetWare-на-UnixWare, обладая при этом намного более совершенной архитектурой.

SuperNOS призвана обеспечить наилучшую архитектуру: выполнение загружаемых модулей в среде NetWare и Unix-приложений в среде Unix. SuperNOS будет выполнять NetWare непосредственно над микроядром, а не как приложение Unix.

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

ВЫБОР АДРЕСА НАЧИНАЕТСЯ С ОПРЕДЕЛЕНИЯ КЛАССА

Все дело в размерах

Ограничение числа адресов хостов, используемых вашей организацией, может значительно сократить трудности, с которыми вы сталкиваетесь при работе со шлюзом Internet. Чтобы сделать это, вам надо правильно выбрать класс IP-адреса - A, B или C.

В адресах класса A 1 бит выделяется идентификатору класса, 7 бит - номеру сети и 24 бита - номеру хоста. Это означает, что может существовать всего 128 сетей класса A, но в каждой из них может быть несколько миллионов хостов. Поэтому сетевые номера класса A резервируются для очень крупных организаций.

В адресах класса B 2 бита выделяются идентификатору класса, 14 бит - номеру сети и 16 бит - номеру хоста. Это означает, что может существовать 16394 сети класса B и в каждой из них - до 65536 устройств. Сетевые номера класса B подходят для достаточно больших организаций.

Наконец, в адресах класса C 2 бита выделяются идентификатору класса, 22 бита - номеру сети и 8 бит - номеру хоста. То есть может существовать более четырех миллионов сетей класса С, но каждая может содержать не более 254 устройств (с помощью восьми бит можно задать 256 адресов, но два из них зарезервированы).

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

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