ГЕТЕРОГЕННАЯ СРЕДА И СЕТЕВЫЕ ОС

Статья Константина Пьянзина "Сетевые ОС в гетерогенной среде" (LAN Magazine/Русское издание, ноябрь, стр. 61) далеко не бесспорна. Хотелось бы остановиться на конкретном сравнении сетевых ОС. С точки зрения администратора, я хочу подчеркнуть, что сравниваемые автором ОС - это ОС для локальных сетей. А в локальных сетях, как показывает здравый смысл, гетерогенность - это зло. Куда спокойнее, когда у тебя система сервера и клиента совпадают (или одного производителя). И общаться надо с одним поставщиком (интегратором), и общая производительность однородной сети выше, чем у гетерогенной, и затраты на обучение снижаются. Поэтому надо делать выбор между парами (и сравнивать соответственно Novell NetWare и Novell DOS, Windows NT Server и Windows NT Workstation, IBM OS/2 Warp Server и IBM OS/2 Warp Connect, Unix и ...Unix).

Конечно, однородная (не одноранговая!) сеть не лишит администратора головной боли, но степень ее уменьшит на порядок.

Что касается многопользовательских ОС, то замечу, что работать на одном компьютере нескольким пользователям (десяткам, сотням и т.д.) - это все равно, что жить в коммунальной квартире, даже с хорошими соседями и добрым управдомом (читай - системным программистом). И если останавливаться на многопользовательских системах, то Unix, на мой взгляд, не лучший выбор (я, надо сказать, в прошлом системный программист на компьютерах серии СМ - помните такие?). Впрочем, когда есть деньги, ездить на "Порше" или "Ягуаре" - это дело вкуса (извините за сравнение).

Теперь пару слов о гетерогенности. Гетерогенность возникает при создании межсетевого взаимодействия (связи между отдельными локальными сетями) и при построении Корпоративных (с большой буквы) сетей. Методы проектирования таких связей абсолютно другие. На выбор конкретной сетевой-клиентской ОС они, как правило, не влияют. И затраты (!!!) на построение подобных систем обычно позволяют употреблять (не злоупотреблять) разные сетевые ОС на уровне клиентских подсистем. Причем заслуги сетевых ОС в этом практически нет. Это я к тому, что нет смысла определять, какую сетевую ОС выбрать для гетерогенной сети - в таком случае сеть теряет гетерогенность. Но как же прикладные сервисы - серверы баз данных, электронной почты, groupware, - спросите вы.

Здесь-то я и хочу сказать, что во главу угла надо ставить выбор ПО серверов приложений. Как правило, технология клиент-сервер в прикладных системах подразумевает замену некоторых функций сетевой ОС своими аналогичными функциями. Это касается и защиты информации (пароли, резервное копирование/восстановление), и межсетевого взаимодействия (удаленный доступ и тиражирование), и даже файловой системы (серверы БД). Если отказаться от концепции сетевых ОС, как ОС для хранения файлов и обслуживания печати, то проблема выбора лучшей сетевой ОС сводится к ответу на вопрос: на какой паре ОС "сервер-клиент" наилучшее соотношение стоимость/производительность у конкретного ПО "клиент-сервер"? Ну, может быть, встанет и второй вопрос - что удобнее пользователю? Ведь сети и компьютерные системы создаются для пользователей, а не для системных администраторов.

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

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

Виктор Матвеев,

Администратор локальной сети Законодательного

Собрания Республики Карелия,

root@parl.karelia.su

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

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

Вы пишете, что сравниваемые мною сетевые ОС (NetWare, Windows NT и Unix) являются ОС для локальных сетей. В таком случае, какие сетевые ОС существуют для корпоративных сетей? По большому счету, в качестве основы (и только основы) для корпоративной сети в настоящее время хорошо подходят только две ОС (вернее, их службы каталогов): Banyan VINES (StreetTalk) и Novell NetWare 4.x (NDS). В скором времени аналогичная служба появится и для Windows NT. Можно строить корпоративную сеть на основе других СОС, но это значительно усложняет проблемы создания единой инфраструктуры.

Вы, конечно, правы, что гетерогенная среда гораздо хуже (в смысле управляемости и удобства), чем однородная. Но жизнь - сложная штука, и если в Вашей сети (не важно - локальной или корпоративной) существуют неоднородные и разноплатформенные машины (такие как ПК, Unix, AS/400, VMS, мэйнфреймы и т.п.), то, фактически, у организации выбор очень ограничен, остается создавать гетерогенную среду. Именно этому была посвящена статья в LAN.

Что же касается предложенных Вами вариантов сравнения по парам (Novell NetWare и Novell DOS, Windows NT Server и Windows NT Workstation, Unix и Unix), то, боюсь, это очень оригинальный подход. И, по-моему, несколько не правомерный. Задача сетевой ОС как раз и состоит в поддержке максимального количества ОС-клиентов. Иначе грош ей цена. Чего стоила бы NetWare (а она установлена в 60% всех локальных сетей мира и 90% сетей России), если был бы реализован такой подход? А куда отнести Banyan VINES? А где место Macintosh, как клиентской платформы (а ведь это 10% всех компьютеров мира)?

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

Что касается замечаний по поводу поддержки многопользовательского режима, то на этот счет существуют самые различные мнения. Кстати, один из откликов был посвящен тому, что я уделил в своей статье слишком мало внимания данной теме. Просто все зависит от решаемых задач. Кому-то многопользовательский режим крайне необходим, а кому-то нет. А что касается сравнения многопользовательского режима с коммунальной квартирой, то я мог бы привести совсем другие аналогии. Но как говорили древние, всякая аналогия хромает. Не в этом суть. В Unix вы можете применять многопользовательский интерфейс, а можете и не применять. Есть возможность выбора. В Windows NT у Вас, фактически, нет выбора (без дополнительных продуктов сторонних фирм). Кстати, сама операционная система Windows NT работает в многопользовательском режиме, однако у нее отсутствует встроенный многопользовательский интерфейс (что говорит о нелогичности подхода Microsoft). В этом беда. Могу только сказать, что мне, как администратору сети, очень недостает многопользовательского интерфейса Windows NT. Например, я нахожусь в другом здании у клиента и вижу, что на сервере Windows NT надо внести какие-либо исправления. Для этого я должен идти к серверу (или звонить кому-то по телефону и объяснять, что надо сделать), а потом идти обратно к клиенту. Согласитесь, что это не лучший подход. Можно в качестве примера привести и множество других, гораздо более весомых, доводов.

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

Только не считайте меня убежденным сторонником какой-либо одной ОС (и сетевой ОС в частности). У каждой из них есть свои плюсы и минусы. Именно на этом надо акцентировать внимание в журнальных публикациях, а не только превозносить достоинства одной ОС и поливать грязью остальные. Сам же я постоянно работаю в Windows, DOS, Windows NT, Unix (именно в таком приоритетном порядке).

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

Что же касается серверов приложений, то почему выбор конкретной платформы и приложения должен в приоритетном порядке влиять на выбор сетевой ОС? Ничто не мешает в сети Windows NT Server использовать в качестве сервера приложений Unix-машину или мэйнфрейм, или в сети NetWare задействовать сервер БД на основе Windows NT.

При выборе (в частности, сервера приложений) многие ориентируются только на соотношение цена/производительность (ну еще Вы упомянули про удобство пользователя). Думаю, это справедливо далеко не всегда. А косвенные расходы? Приведу конкретный пример.

У нас раньше стояли машины ЕС-1061 и ЕС-1066. В 1994 г. была поставлена задача перехода на более надежную технику. Рассматривались различные варианты: установка RISC-сервера, мэйнфрейма, AS/400, серверов на основе PC и т.п. Но руководством был выбран мэйнфрейм IBM ES/9000. Дело в том, что если переходить на другую технику, то пройдут многие месяцы, прежде чем ее можно будет задействовать (перенос программ, переобучение персонала и пользователей, эксплуатационные расходы и т.д. и т.п.). Однако работу завода нельзя остановить ни на день. Поэтому посчитали, что вариант с мэйнфреймом с учетом косвенных затрат намного дешевле остальных. И действительно, когда поставили мэйнфрейм, уже через день все старые программы работали в обычном режиме, и пользователи даже не заметили перехода. Возможно, там, где нет тяжелого наследия старых приложений, другой вариант был бы более предпочтителен.

Если ориентироваться только на показатель "цена/производительность", то можно попасть впросак и по другим причинам. Ведь кроме данного показателя, должны учитываться и функциональные параметры. Ну что толку в отличном показателе "цена/производительность" для Microsoft SQL Server, если данный сервер просто не потянет работу всех Ваших пользователей или если применяется огромная (в несколько тысяч гигабайт) база.

Надеюсь, что в некоторой степени Вас удовлетворили мои объяснения.

-Константин Пьянзин


ПИШИТЕ НАМ!

Редакция журнала "LAN Magazine/Русское издание" ждет Ваших откликов на публикуемые материалы. Нам будет интересно узнать Ваше мнение о статьях, которые вызвали у Вас наибольший интерес или, наоборот, несогласие. Мы учтем пожелания наших читателей по тематике материалов, которые появятся в следующих номерах журнала.

Присылайте ваши отклики по электронной почте: lan@osp.ru или по факсу (095) 135-4220.