Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Главный недостаток Windows NT в России, или Почему я за архитектуру клиент—сервер

Д. В. Дайтер

В огромном перечне истинных и мнимых недостатков Windows NT есть один, который упоминается практически только на территории СНГ. Технические специалисты Microsoft формулируют его так: "ОС Windows NT не предназначена для СУБД, работающих по принципу совместного доступа пользователей к файлам в режиме записи". Если говорить проще, то "сетевая" бухгалтерская программа, написанная с использованием персональной СУБД (а такими изделиями буквально забит российский рынок), будет очень плохо работать под ОС Windows NT Server, если у вас больше одного бухгалтера. Правда, под NetWare они тоже работают не слишком хорошо, но в первом случае — еще хуже.

Впервые я убедился в этом на примере популярной программы "Шоп", написанной для автоматизации товарного учета. Под управлением NetWare эта программа работает "почти быстро", если не считать того, что перед формированием отчета менеджер вынужден копировать всю базу данных на локальный диск. В противном случае он заблокирует работу всего сегмента сети. Когда мы попытались запустить ее под Windows NT, результаты оказались обескураживающими. Пока с базой данных работал один пользователь, все было нормально, но стоило к ней подключиться еще кому-то, работа замедлялась в пять раз. При этом загрузка сети и всех компонентов сервера не превышала и 15%. Кроме того, еще, как минимум, десять пользователей могли подключиться к различным базам данных (каждый к своей) и работать нормально, без задержек.

На самом деле таким образом ведут себя практически все программы, написанные с использованием персональных СУБД. В последнее время мы упорно боролись с медленной работой программ "БЭСТ" и "Инфо-бухгалтер", но ничего сделать так и не удалось. Единственное, что утешает, — все эти приложения в наших подразделениях используются последний месяц. Вскоре мы переходим на программный комплекс "Галактика", где таких проблем нет, поскольку используется СУБД Btrieve.

Почему я не считаю это недостатком

Сразу оговорюсь, что я давно являюсь противником совместного использования персональных СУБД в сети. Я был им еще тогда, когда Windows NT Advanced Server еще не появился, а NetWare являлась основной сетевой ОС. Подобные СУБД создают в сети существенные проблемы независимо от того, какая ОС установлена на сервере. Попытаюсь конкретизировать это утверждение.

Проблема скорости и загрузки сети

Проблема скорости выполнения подобных приложений под управлением NetWare стоит, конечно, не так остро, как в случае с Windows NT, но тем не менее она есть. Это является следствием повышенной сетевой нагрузки, порождаемой настольной СУБД при ее использовании в локальной сети. Если принять во внимание, что за последние несколько лет объемы обрабатываемой информации и скорости вычислений выросли в сотни раз, а пропускная способность обычных сетей Ethernet осталась прежней и уже с трудом удовлетворяет требования, предъявляемые к передаче данных, то становится вполне понятным, почему персональная СУБД является наихудшим решением для совместной работы в сети. Правда, серверные СУБД, в свою очередь, изрядно загружают процессор сервера. Однако гораздо проще и дешевле поставить более мощный процессор (или процессоры), чем переводить всю сеть на Fast Ethernet. В обычной же среде Ethernet практически любая учетная программа с персональной СУБД работает с приемлемой скоростью только в том случае, если к одной подсети подключено не более десяти клиентов.

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

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

Проблема надежности

Если о скорости работы персональных СУБД еще как-то можно спорить (например, утверждать, что необходимо тщательнее оптимизировать программы), то в отношении надежности ситуация, без сомнения, гораздо хуже, чем у серверных.

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

Надежность персональной СУБД в сети, как правило, катастрофически мала, поскольку факторами риска становятся рабочие станции и кабельная система. Обрыв кабеля в момент изменения содержимого БД почти неминуемо приводит к нарушению целостности данных. Само собой разумеется, к этому же приводит и сбой в работе клиентского компьютера. Серверы, конечно, тоже "сбоят", но значительно реже, поскольку обычно являются компьютерами brand name, снабженными устройствами бесперебойного питания, и находятся в хорошо проветриваемом помещении, доступ в которое ограничен. У кабельной системы и рабочих станций таких "привилегий" нет.

В нашей сети уже несколько лет активно работают бухгалтерские приложения, использующие Btrieve. Почти все они (кроме программного комплекса "Галактика") сделаны местными программистами, что называется, на скорую руку. Но я помню не более двух-трех случаев нарушения целостности базы. При этом каждый раз ее удавалось восстановить в автоматическом режиме с помощью специальной утилиты. В то же время с программами "Шоп", "БЭСТ", "Инфо-бухгалтер" и "1С" это периодически случается независимо от того, какая ОС установлена на сервере. У нас были периоды, когда база программы "Шоп" (под управлением NetWare) разрушалась по нескольку раз в неделю. Восстановление такой базы является процессом "творческим и непредсказуемым".

Недавно произошел случай, стоивший нам всем больших нервов и едва не приведший одну из наших дочерних компаний к немалым штрафам, — разрушилась база данных программы "БЭСТ". Естественно, что произошло это (спасибо старику Мэрфи) в три часа дня, накануне сдачи отчета. У нас, конечно, была кассета с копией, сделанной предыдущей ночью, но в данном случае это никого не устраивало, поскольку пропали бы результаты работы почти за целый день. Звонить в службу технической поддержки, как вы уже поняли, было бесполезно, и мы стали пытаться решить эту проблему сами. Проанализировав ситуацию, мы обнаружили, что файл plan_sch.dbf имеет существенно меньший размер, чем его архивная копия, а файл plan_sch.cdx вообще отсутствует (хотя в архивной копии он есть). Нетрудно было догадаться, что данная пара файлов содержит план счетов. У нас отлегло от сердца: план счетов меняется нечасто и архивная копия для его восстановления вполне годится. Как и следовало ожидать, после восстановления этих двух файлов все заработало. Я лично расцениваю это как потрясающее везение. Даже страшно представить, что произошло бы, если бы был испорчен какой-то другой файл. Все эти операции с базой данных заняли у нас около часа. Излишне говорить, чего стоил этот час главному бухгалтеру.

Давайте ходить ногами!

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

Я часто слышу: если тщательнее подойти к оптимизации программы, аккуратно настроить сеть, то персональная СУБД будет работать приемлемо. Это чем-то похоже на рассуждения о том, что можно научиться хорошо и быстро ходить на руках. При известном терпении, конечно, можно, но на ногах-то все равно удобнее!

Особенности российского рынка

Аналитики из Microsoft AO одной из основных причин относительно медленного (по сравнению с другими странами) вытеснения NetWare с российского рынка считают большое число специалистов CNE (Certified Novell Engineer), подготовленных в России. Они безусловно правы. Но есть и еще одна — чисто российская — причина: наш рынок изобилует использующими персональные СУБД учетными приложениями, которые их авторы называют сетевыми, — и это на фоне очень небольшого числа систем клиент—сервер.

В доказательство своей правоты сторонники персональных СУБД часто ссылаются на зарубежные статьи, доказывается нецелесообразность внедрения систем клиент—сервер. При этом они забывают указать, что в качестве альтернативы в этих статьях рассматриваются мэйнфреймы. Использовать в таком качестве персональные СУБД никому в Европе и Америке уже давно не приходит в голову (ну разве что только Computer Associates). Это чисто российское явление, и обусловлено оно банальными историческими причинами.

Когда большинство российских производителей ПО выходили на рынок, самыми популярными в стране средствами разработки учетных программ были Clipper и Clarion. Они давали возможность в короткие сроки сделать систему, которая бы позволяла бухгалтеру, работающему на компьютере, "слегка" автоматизировать свою работу. Большего тогда и не требовалось. Подавляющее большинство нынешних учетных программ получено путем плавного развития тех, простейших. Поэтому для адаптации этих программ к новым обстоятельствам они должны быть заново переписаны под серверные СУБД, а на это нужно много времени и денег. Естественно, в условиях рынка почти никто себе этого позволить не может. Производители ПО сами загнали себя в ловушку тем, что слишком долго не пытались хотя бы немного заглянуть вперед.

Впрочем, и здесь бывают счастливые исключения. Например, фирма "Галактика" (которая, кстати, никогда и не использовала персональные СУБД) не скрывает тот факт, что базовая платформа программного комплекса "Галактика" — серверная СУБД Btrieve, в общем-то, уже устарела для крупных корпоративных решений. В ближайшее время на рынке появится новая версия "Галактики", работающая на основе сервера Oracle7. При этом пользователям будет предоставлена возможность перехода на нее с предыдущих версий. Но и здесь возникает масса проблем. Выпуск новой версии идет значительно медленнее, чем планировалось (и чем нам бы хотелось).

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

***

Но не все так плохо. В последнее время на российском рынке появляется все больше программных комплексов, использующих серверные СУБД. Хотя из-за относительной дороговизны они пока не могут составить серьезной конкуренции "персонально-сетевым", тем не менее довольно активно теснят устаревшие программы в крупных корпорациях. Кроме того, по моему мнению, число программ с новой архитектурой будет продолжать расти, а цены на эти два типа ПО в дальнейшем сравняются. Очень хочется надеяться, что в третье тысячелетие мы войдем с нормальным рынком сетевого ПО для автоматизации бизнеса.

Когда материал готовился к печати, я получил информацию о том, что в феврале будущего года должна выйти новая версия программы "Шоп", которая будет работать с MS SQL Server. Что ж, видимо, мой оптимизм вполне оправдан.





  
12 '1997
СОДЕРЖАНИЕ

колонка редактора

• Старая песня о главном

локальные сети

• Средства кластеризации серверов Windows NT

• Главный недостаток Windows NT в России, или Почему я за архитектуру клиент—сервер

• Серверы NetWare в зеркальном отражении

• ЭМС и Европейская Директива

• Оценка эффективности работы персонала

• Novell Education: кузница сетевых инженеров

корпоративные сети

• Службы LANE — мост в XXI век?

• Новейшая история транзакционных технологий

• Внезапные потери связи

• Новейшие Интернет-технологии от Novell

услуги сетей связи

• Телефонные станции для быстро растущих и крупных предприятий

• CDMA — россиянам

• О пригодности телефонных каналов для передачи данных

• Тарификационные системы для учрежденческих АТС

• Маршрутизаторы ISDN со встроенными концентраторами

интернет и интрасети

• Распределение нагрузки Web-сервера

• Естественная эволюция индустрии Интернет

• Игры в Интернет

защита данных

• Управление ИБП

новые продукты

• Network Exchange 2550 фирмы Netrix

только на сервере

• Технология Dynamic HTML: "раздвоение личности"

• Тестируем АТМ-адаптеры



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх