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

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

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

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

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


Rambler's Top100

  

В поисках решения удаленного управления

Джонатан Фельдман

Поиск наилучшего решения удаленного управления приложением — труд не из легких, но он наверняка будет вознагражден. В последнее время появилось большое число методов удаленной работы с приложениями, включая удаленное управление, развертывание приложений через интрасеть и использование многопользовательской среды Windows, ориентированной на тонкий клиент; причем у каждого из методов есть как свои достоинства, так и недостатки.

Традиционные решения удаленного доступа предполагают использование двух ПК: по одному для удаленного пользователя и управляемого хоста. По этой причине удаленное управление не может похвастаться хорошей масштабируемостью. Кроме того, оно легко может превратиться в «удаленную неуправляемость» с появлением в сети новых коммутируемых линий и ненадежных рабочих станций.

Казалось бы, распространение приложений средствами Java через интрасеть уже решило все проблемы, но на деле такой подход еще недостаточно проработан и применим далеко не во всех практических сферах деятельности. Многопользовательская среда Windows, основанная на технологии WinFrame фирмы Citrix, поможет вам преодолеть боўльшую часть пути в этом направлении, особенно если дело касается управляемости и масштабируемости.

Наш отдел отвечает за поддержку примерно 1200 местных федеральных узлов, осуществляющих связь по самым разнообразным каналам — от X.25 до FDDI. С ростом потребности в удаленном управлении приложениями как по выделенным, так и по коммутируемым каналам мы все острее ощущаем отсутствие продукта, который бы поднял на новый уровень инфраструктуру нашей сети. В прошлом мы с успехом пользовались оборудованием и ПО фирмы Cubix для обеспечения хорошо управляемого и централизованного удаленного контроля, поэтому и в данном случае было бы разумно обратиться к ее продукции.

В течение двух месяцев мы проверяли совместную работу сервера Cubix Remote Serv/IS 5000 и ПО WinFrame фирмы Citrix. Этот сервер поставляется вместе с отказоустойчивым управляемым шасси, на котором установлены две двухпроцессорные подсистемы Pentium со 128 Мбайт оперативной памяти в каждой, оснащенные ПО WorldDesk — весьма ценным дополнением к системе, так как оно позволяет многопользовательской среде Windows регулировать нагрузку в кластере серверов. Протестированный нами сервер Remote Serv/IS поставляется в виде кластера из двух машин, каждая из которых размещается в отдельном шасси для обеспечения возможности горячей замены.

Частное решение

Для большинства наших приложений комбинация продуктов Cubix и Citrix показала себя очень хорошо. Доступ при помощи WinFrame оказался быстрым даже на медленных линиях, распространение клиентской части WinFrame также не вызвало затруднений. Здесь реализованы клиенты как для машин DOS, так и для Windows 95. Кроме того, на рынке имеются клиенты для Macintosh и Unix, например производства компаний Insignia Solutions и Tektronix, правда их мы не тестировали. Фирмы Insignia и Tektronix применяют WinFrame в своих продуктах NTrigue и WinDD соответственно.

Принимать решение об установке многопользовательской среды Windows нужно осмотрительно, даже в нашем отделе ею могли пользоваться лишь некоторые сотрудники. Она бесполезна для тех, кто работает с современными 32-разрядными модулями, такими, как Windows MAPI32 (Messaging Application Programming Interface). WinFrame, созданный на базе Windows NT 3.51, может работать далеко не со всеми приложениями Windows 95/NT. Кроме того, приложения WinFrame не будут работать под управлением обычной Windows NT 3.51: для них необходима модифицированная версия этой ОС, а значит, для такой версии не подойдут и обычные пакеты Service Pack фирмы Microsoft.

Рис. 1. Наша тестовая установка

Рис. 1. Наша тестовая установка

Мы решили исследовать средства удаленного управления приложениями, преследуя несколько целей. Во-первых, нам требовалась приемлемая производительность для управления большими приложениями по медленным коммутируемым или выделенным линиям при известных ограничениях используемого оборудования на удаленном конце. Во-вторых, мы были заинтересованы в усилении нашей концепции тонкого клиента, которая обладает двумя существенными достоинствами: централизованным управлением и быстрой заменой клиентских терминальных устройств. И в-третьих, нам была необходима интеграция нового продукта с нашими текущими и унаследованными приложениями и инструментарием. Мы хотели сохранить средства, вложенные, например, в терминальные серверы и модемные пулы, вместо того чтобы приобретать новые многопортовые модемные платы, рассчитанные специально для сервера Windows NT.

Управление в «зоопарке»

Некоторые из наших клиентов, работающих по коммутируемым каналам, а также удаленные филиалы до сих пор используют старые 386-е и 486-е ПК, работающие под управлением DOS. Поскольку в тестовой конфигурации у сервера удаленных приложений не было непосредственной связи с клиентами по асинхронному каналу, подключаться к нему приходилось через терминальный сервер по протоколу IP (рис. 1). Нам пришлось сконфигурировать клиент WinFrame для DOS таким образом, чтобы он использовал уже существующие стеки TCP/IP.

WinFrame изначально поддерживает сетевые стеки для DOS производства Microsoft, Novell и FTP Software. Поскольку приложения DOS не имеют возможности пользоваться интерфейсом WinSock, то WinFrame предоставляет для этих целей библиотеку Virtual Socket Library, которая работает как промежуточный слой, поддерживающий множество различных стеков. После редактирования небольшого INI-файла и сценария подключения наши DOS-клиенты были готовы к работе. Но, что более важно, нам не пришлось арендовать выделенные асинхронные каналы для поддержки пользователей DOS: они могли продолжать работать по тем же коммутируемым соединениям, что и пользователи Windows 95.

В одном из обслуживаемых нами отделов используется продукт удаленного управления для распространения приложений на «слабенькие» машины, работающие под управлением DOS и Windows 3.1 в удаленных подразделениях отдела. Но отдел растет, и мощностей процессоров, занятых удаленным управлением, вскоре перестанет хватать. Поскольку сюда все равно придется ставить новое шасси, мы задумались над тем, чтобы увеличить производительность сервера удаленных приложений за счет использования WinFrame вместо дальнейшего наращивания старой системы удаленного управления.

Пытаясь заранее предусмотреть возникновение проблем и оценить, как многопользовательская Windows может повлиять на довольно ограниченную пропускную способность сетевых каналов отдела, мы воспользовались продуктом Sniffer компании Network General для измерения сетевой нагрузки при обычном сеансе удаленного управления приложениями. Затем мы сравнили полученные данные с аналогичными измерениями для WinFrame. Результаты были впечатляющими. Наше тестирование показало, что при работе в распределенной сети WinFrame использует всего треть от того объема полосы пропускания, который требуется для работы прежнего продукта удаленного управления.

Полоса черная, полоса белая

К сожалению, наши надежды на то, что, сконфигурировав приложение однажды, в дальнейшем его можно многократно использовать, рассчитанные на механизм профилей Windows 95, не оправдались. Как оказалось, профили Microsoft не могут быть автоматически перенесены между WinFrame и Windows 95. Они представляют собой сетевое хранилище настроек реестра пользователей Windows и ссылок на приложения (shortcut), которые восстанавливаются при каждом входе пользователя в сеть. При развертывании Windows 95 в среде WinFrame необходимо было тщательно проследить доступность всех профилей, с тем чтобы пользователи, работая на различных машинах, всегда имели возможность загрузить настройки собственного «рабочего стола». В идеале нам хотелось добиться, чтобы и вне офиса удаленные пользователи могли задействовать те же профили, что и на рабочем месте.

Как уже упоминалось, поскольку пакет WinFrame был реализован для ОС Windows NT 3.51, он не поддерживает профили в стиле Windows 95. Например, мы не могли буксировать мышью пиктограммы между двумя профилями различных типов: профили Windows NT 3.51 хранятся в «плоской» базе данных, а не в каталоговой структуре. В пакете WinFrame ничего не стоит создать рабочий стол, полностью соответствующий рабочему столу в Windows 95, и размножить его для нескольких пользователей, однако гораздо труднее добиться, чтобы каждый работал с привычной ему настройкой графического интерфейса.

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

Рис. 2. Обеспечение безопасности

Рис. 2. Обеспечение безопасности

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

Однако при тестировании клиента системы обмена сообщениями GroupWise 5 компании Novell мы столкнулись с неожиданными препятствиями. Несмотря на все наши усилия, мы так и не смогли заставить 32-разрядную версию GroupWise работать под управлением WinFrame. Пакету GroupWise для работы требуется библиотека MAPI32, которая имеется только в Windows 95 и NT 4.0. Так как этот модуль DLL поставляется фирмой Microsoft, то Novell ничем не могла нам помочь. Кроме того, мы обнаружили, что реестры Windows NT версий 3.51 и 4.0 существенно различаются, что порождало дополнительные проблемы с приложениями. Как и ожидалось, 16-разрядная версия работала, но не обладала всеми возможностями, которые нам были нужны. Из-за перечисленных недостатков концепция удаленной рабочей станции в WinFrame была реализована не полностью.

Мы провели тестирование продукта на наших сетевых компьютерах @workStations фирмы NeoWare Systems. Для установки конфигурации на сервере потребовалось всего полчаса, после чего все наши терминалы были извлечены из коробок и уже через несколько минут готовы к соединению с сервером WinFrame.

Помимо прочего, WinFrame проявил одно очень интересное свойство: если после разрыва соединения вы обратитесь к серверу с запросом на аутентификацию под прежним именем, то WinFrame возобновляет сеанс с той точки выполнения задания, на которой оно было прервано. Это весьма полезно для предотвращения фатальных сбоев в приложениях при неожиданном разрыве соединения.

Обслуживание внешних клиентов

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

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

В полной безопасности

Реализованная в WinFrame модель обеспечения безопасности позволяет различным сегментам сети иметь разный уровень полномочий, при этом пользователям определенных сегментов можно навязать автоматическую регистрацию с ограниченными правами доступа (рис. 2). При такой модели в сервере должно быть установлено несколько сетевых интерфейсных плат — по одной на защищенный и незащищенный сегменты. Внутренние пользователи сегмента A устанавливают соединение с WinFrame обычным способом, т. е. при входе в систему сообщают свое имя и пароль. Пользователи же из сегмента Б будут регистрироваться автоматически с последующим подключением к определенному общедоступному приложению. Владея такими средствами обеспечения безопасности, мы могли бы предоставлять доступ к соответствующим данным и пользователям Интернет, и нашим внешним клиентам.

Мы затратили много времени на тестирование средств безопасности. К счастью, вы всегда сможете снять блокировку со своей программы, если вы вдруг заблокировали сами себя (консоль системы нельзя заблокировать в принципе).

Фирмы Microsoft и Citrix объединили свои усилия для разработки технологии многопользовательской Windows. Можно даже предположить, что средства многопользовательского доступа станут ядром технологии ОС Windows NT. Мы намерены внимательно изучить эту службу, получившую кодовое название Hydra, как только она появится на свет. Ожидается, что в ней будут устранены некоторые из тех проблем, которые возникли у нас с профилями пользователей, а также появятся обновленная 32-разрядная библиотека и средства для работы с реестром.





  
3 '1998
СОДЕРЖАНИЕ

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

• В борьбе GSM и CDMA победила дружба

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

• Кабельные системы для офисных зданий. Часть I. История, приложения, стандарты

• Быстрые устройства для быстрых сетей

• Когда сервер NetWare работает медленно

• В поисках решения удаленного управления

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

• Коммутаторы ATM на магистрали корпоративной сети

• Формализованное представление работы предприятия

• Четыре монитора транзакций для корпоративных приложений

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

• Системы WLL на российском рынке

• Технологии ХХI века и российские университеты

• Европейская конференция по АТМ

• Передача голоса по сетям ATM (часть II)

• Передача данных по каналам телевещания

• Телевидение: от кабельного к эфирному и далее...

системы учрежденческой связи

• Конкурентоспособны ли отечественные УАТС?

• Такие разные автоинформаторы

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

• За подрядами - в Интернет!

• Оправдает ли ожидания WinSock 2?

• Электронная коммерция в России

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

• Секреты виртуальных частных сетей

бизнес

• 3Com-OCS: связь напрямую

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

• 101-й "козырь" фирмы RAD, Allied Telesyn выходит на рынок средств удаленного доступа

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

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



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