При построении сетей, объединяющих мэйнфреймы с локальными и глобальными сетями могут применяться различные схемы доступа. Рассмотрим основные из них.
SNA Server в региональных отделениях (рисунок 73)
Подходит для организаций, где уже были созданы глобальные сети на базе X.25 и/или выделенных линий и изменение инфраструктуры нежелательно. Требует установки SNA Server в каждом отделении организации.
SNA Server в центральном офисе (рисунок 74)
Ускоряет процесс внедрения SNA Server, упрощает администрирование соединений с хост-машиной, уменьшает количество настроек выполняемых в каждом удаленном офисе и количество административного персонала, требуемого для поддержания системы.
Распределенная модель доступа (рисунок 75)
Преимущества над первой схемой состоят в уменьшении вероятности состояний time-out на клиентах и общем снижении трафика поверх удаленных соединений.
Преимущества над второй схемой состоят в уменьшении времени отклика на клиентах в удаленном офисе и упрощении балансировки нагрузки на шлюзы в центральном офисе. Кроме того, в случае недоступности WAN-соединения, серверы в удаленных офисах могут быть настроены на автоматическое установление соединений по SDLC и/или X.25.
Сервис RAS поверх SNA (рисунок 76)
Позволяет использовать существующие соединений SNA для объединения сетей Windows NT. Сервисы RAS при этом используют SNA соединения как протокол нижнего уровня и позволяют предавать трафик IPX,TCP/IP и/или NetBEUI между сетями. Кроме того служба SNA RAS может быть использована другими продуктами семейства BackOffice, такими как Exchange RAS Connector и SMS Sender.
Организация толерантных систем (рисунок 77)
Как уже было отмечено, организации горячего резервирования и балансировки нагрузки сервера объединяются в группы, в группе должно быть по крайней мере два (до 15) серверов.
В приведенном на рисунке примере организуется горячее резервирование каналов доступа к мэйнфрейму для двух групп пользователей PRODUCTS и SALES. Множество логических устройств (LU001-LU200) доступных на хост-компьютере делится поровну между двумя SNA-серверами (SNASERV1 и SNASERV2), затем создаются два пула POOL@PRD, с правами доступа для группы PRODUCTS, и POOL@SAL , с правами для SALES. Каждый пул содержит логические устройства, обслуживаемые каждым из серверов.
В случае недоступности SNASERV1, после поступления запроса на установления соединения с хост-машиной из пула будут выбраны логические соединения, обслуживаемые SNASERV2.
Поскольку SNA Server может функционировать только на платформе Windows NT, он использует для проверки полномочий механизм защиты операционной системы. На все ресурсы сервера SNA, включая выделенные каналы доступа, пулы логических устройств, очереди печати и разделяемые папки, можно назначить права пользователям и группам доменов NT.
Для клиентских станций, поддерживающих процедуру регистрации в домене, авторизация на уровне SNA Server происходит автоматически на основе текущего секретного идентификатора пользователя, для пользователей же других операционных систем, таких как "чистые" клиенты NetWare и пользователи Unix-машин требуется непосредственный ввод имени, пароля и домена пользователя. Введенная информация верифицируется контроллером домена в котором расположен SNA Server, после чего клиенту предоставляется доступ к ресурсам согласно его полномочий.
SNA Server также поддерживает установку административных привилегий на объекты управления, что позволяет делить функции между администраторами определенных ресурсов без предоставления им полного контроля над сервером.
Формат многих протоколов SNA, в особенности протоколов эмуляции 3270/5250, не предусматривает средств шифрования, так при терминальном сеансе имена и пароли передаются в открытом виде, При прохождении такой информации через сети публичного доступа возникает серьёзная угроза перехвата конфиденциальных данных, угроза несанкционированного доступа и модификации данных. SNA Server позволяет этому воспрепятствовать.
Благодаря модульной архитектуре и наличию прикладного уровня DMOD, весь трафик между клиентом и сервером может быть зашифрован, при этом могут вводиться дополнительные уровни, реализующие альтернативные алгоритмы защиты.
Для клиентов, поддерживающих регистрацию в домене NT, возможность шифрования трафика обеспечивается автоматически, при этом имена и пароли всегда передаются в зашифрованном виде. Весь обмен информацией между серверами также может быть шифрован, что особенно актуально при передаче трафика через сети коллективного доступа, например Internet. Признак шифрования устанавливается на сервере и может назначаться поименно для каждого пользователя. Алгоритм, применяющийся при шифровке - RC4 stream cipher - разработан RSA Data Security и имеет длину ключа 40 бит. Этот же алгоритм используется Windows NT для защиты удаленных вызовов процедур.
Как и другие продукты BackOffice, SNA Server использует интегрированную консоль - SNA Server Manager, для управления группами серверов организации и мониторинга их состояния. Административная консоль может функционировать на сервере или рабочей станции Windows NT. На рисунке 78 приведен пример, того как эта консоль выглядит. Левая панель представляет иерархическое дерево объектов управления в группе SNA-серверов. Правая панель отображает множество свойств и включенных объектов выбранного объекта. Дополнительные окна отражают информацию о конкретных объектах администрирования. Щелчком правой кнопки мыши на экран выводится контекстно-зависимое меню операций, ассоциированных с данным объектом управления. Стоит отметить, что многие административные операции могут выполняться методом "перетащи и оставь", например, назначение групп пользователей или рабочих станций с пулами устройств, назначение очередей печати терминальным устройствам, помещение логических устройств в пул и т.д. Наличие мастеров конфигурации автоматизирует наиболее часто выполняемые операции. Административные операции могут выполняться над SNA-серверами доступными через локальную или удаленную сети или через RAS-соединения.
Кроме графической утилиты управления в состав SNA-сервера входит утилита командной строки, позволяющая модифицировать конфигурацию серверов и выполнять часто повторяющиеся операции в пакетном режиме.
Для наблюдения за производительностью и получением статистики SNA Server устанавливает на сервер NT набор объектов для Performance Monitor и несколько шаблонов окон наблюдения.
Для облегчения задачи поиска неисправностей и контроля состояния системы в состав SNA Server входит графическая утилита мониторинга SNA Trace, с ее помощью администраторы могут собирать интересующую их информацию и статистику вплоть до вызовов API.
Кроме того, SNA Server содержит средства интеграции с системой управления IBM NetView, информация о событиях и ошибках может быть направлена на управляющую консоль IBM. NetView в свою очередь может вызывать удаленное выполнение заданий на серверах SNA через сервис NVRunCmd.
Для определения требуемой конфигурации SNA Server предлагается следующая схема (к сожалению, для версии 2.11):
Для любой конфигурации справедливо, что наличие нескольких сетевых протоколов, совмещение функций сервера файлов и печати, выполнение функций первичного или вторичного контроллера домена, шифрование SNA-трафика могут значительно влиять на производительность при большом числе пользователей и их высокой активности. Сервера с большим числом пользователей рекомендуется устанавливать на member-серверы домена, не использовать в качестве серверов файлов и печати, избегать установки протоколов сверх необходимости и использовать шифрование трафика только для критичных соединений.
| Предполагаемое число пользователей | Аппаратная конфигурация |
| от 1500 до 2000 пользователей до 10 000 сессий на сервере |
двухпроцессорный PentiumPro или Digital Alpha/299 компьютер, 128 Мб оперативной памяти, два или более серверов для обеспечения режима горячего резерва; несколько LAN адаптеров; адаптер Token Ring или канальный адаптер; несколько SNA адаптеров для доступа к хост-машине |
| до 600 активных пользователей или до 1500 с нерегулярным доступом | Pentium P90, Alpha AXP или PowerPC компьютер, 64-128 Мб RAM, два или более серверов для обеспечения режима горячего резерва; несколько LAN адаптеров; адаптер Token Ring или канальный адаптер; несколько SNA адаптеров для доступа к хост-машине |
| до 200 активных пользователей или до 500 с нерегулярным доступом | Pentium P60, 32 Мб RAM, два или более серверов для обеспечения режима горячего резерва; канал доступа 56 К/с, установка нескольких адаптеров SNA или выполнение операций сервера файлов и/или печати может потребовать увеличения объема оперативной памяти |
| от 1 до 25 пользователей | 486/66, 24 Мб RAM; относительно медленные каналы SDLC (9600 бит/с) |
Для обеспечения доступа к базам данных на мэйнфреймах в состав SNA Server включен драйвер, обеспечивающий доступ к DRDA-совместимым базам хост-компьютеров из приложений, использующих стандарт ODBC, в частности для репликации данных из SQL Server 6.5. Драйвер поддерживает следующие базы данных:
К сожалению, драйвер имеет только однопользовательскую лицензию, так как разработан сторонней фирмой.
Для репликации больших объемов данных существует ряд продуктов совместимых с SNA Server:
SNA Server поддерживает следующие схемы интеграции хост-компьютеров с Internet.
Транслятор 3270/5250-to-HTML (рисунок 79)
Недостатком такой схемы является невозможность поддержания непрерывной сессии браузера с хост-машиной по причине отсутствия в HTLM понятия "непрерывное соединение". Ввиду этого выполнение программ, требующих наличия устойчивой сессии с эмулятором терминала, не поддерживается. Существует ряд продуктов поддерживающих данный тип доступа, например Attachmate Emissary Host Publishing System, Teubner & Associates Corridor и Wall Data ARPEGGIO Live!.
Схема Web-to-Host, эмуляторы Java и ActiveX (рисунок 80)
В данном случае эмулятор первично загружается на рабочую станцию с Web-сервера. Дальнейшее общение клиентской станции идет уже со SNA-сервером и вызовы прикладных программ упаковываются в пакеты TCP/IP. Недостатком данной схемы является необходимость непосредственного доступа к SNA-серверу, что зачастую неприемлемо. Данная схема доступа поддерживается продуктом OC://WebConnect фирмы OpenConnect.
Репликация Host-to-Web (рисунок 81)
Данные с мэйнфрейма через средства передачи файлов AFTP, APPC или FTP-AFTP шлюз помещаются на локальные диски SNA Server в каталоги доступные Internet серверу. При желании может быть реализована двунаправленная репликация.
Публикации Host-to-Web (рисунок 82)
При такой схеме данные с мэйнфрейма через SNA Server и ODBC/DRDA драйвер запрашиваются непосредственно с Internet-сервера из интерфейсов IDC, CGI или программ реализующих ISAPI. Результаты запроса преобразуются в формат HTML и отображаются в Web-браузера. Данная схема требует зачастую большого объема кодирования. Однако существует ряд продуктов, облегчающих реализацию данного типа доступа, таких как:
Рис. 71. SNA Server обеспечивает доступ к корпоративным данным любым настольным системам с использованием большинства популярных LAN и WAN протоколов
Рис. 72. Наличие уровня DMOD позволяет интегрировать SNA в архитектуру клиент/сервер и обеспечить полную независимость от протоколов нижних уровней и неограниченную расширяемость
Рис. 73. Схема внедрения шлюзов SNA в удаленных офисах с доступом по SDLC поверх выделенных линий и каналов X.25
Рис. 74. Схема доступа к центральному офису с использованием WAN протоколов
Рис. 75. Распределенная схема доступа к центральному офису
Рис. 76. Использование сервиса RAS поверх SNA
Рис. 77. Организация пулов логических устройств для обеспечения горячего резервирования SNA соединений
Рис. 78. Административная консоль SNA Server
Рис. 79. Схема функционирования транслятора 3270/5250-to-HTML
Рис. 80. Схема функционирования терминального эмулятора Java или ActiveX
Рис. 81. Схема файловой репликации Host-to-Web
Рис. 82. Схема публикации Host-to-Web на основе IDC или ISAPI
Вводное
Ни для кого не секрет, что в последнее время в мире происходит нечто, схожее с "золотой лихорадкой". Массовое увлечение Internet и доступом к информации на основе протокола HTTP привело к возникновению массы новых продуктов, дающих возможность организовать такой доступ. Более того, эти продукты все чаще включаются в стандартные комплекты поставки операционных систем, наряду с сервисами файлового доступа и печати.
Так, вместе с каждым сервером Windows NT 4.0 поставляется Internet Information Server 2.0, с каждой станцией Windows NT - его полный функциональный аналог, Peer Web Server.
За счет поддержки наиболее популярных протоколов Internet, IIS позволяет организовать доступ к информации вне зависимости от установленной на клиенте операционной системы. Место хранения информации может быть тоже достаточно произвольным, от файловой системы до баз данных на мэйнфреймах. Подключение новых методов доступа к данным, так называемых коннекторов, обеспечивается наличием в IIS интерфейса прикладного программирования ISAPI.
В комбинации с MS Proxy Server, реализующим технологию Remote WinSock для любого поддерживаемого Window NT протокола, IIS позволяет воспользоваться услугами служб Internet клиентам, не имеющим стека TCP/IP, что позволяет с одной стороны уменьшить число необходимых IP-адресов и сэкономить время и усилия на установку стека TCP/IP, а с другой - уменьшить риск атаки внутренних сетей злоумышленниками.
IIS поддерживает создание виртуальных директорий, когда ресурсы, расположенные физически в других каталогах или на других компьютерах, с точки зрения клиента выглядят принадлежащими одному серверу. Кроме того, при наличии нескольких IP-адресов на компьютере, IIS позволяет создавать на одной машине несколько виртуальных Internet-серверов, каждый из которых может использовать свою структуру каталогов и свои правила предоставления информации.
Для контроля доступа к ресурсам могут использоваться как анонимный режим и базовые средства контроля, требующие от пользователя ввода имени и пароля, так и подтверждение полномочий средствами Windows NT через протокол Secure RPC (в оригинале этот метод называется NT challenge/response).
Для каждого сервиса можно задать таблицу фильтрации допустимых соединений по именам клиентских машин и/или их IP-адресам.
Для шифрования трафика между клиентом и сервером может применяться протокол SSL версии 3.0.
Архитектура
Как и большинство серверов для Windows NT, IIS реализован как набор сервисов:
Сервер реализован как единый процесс - Inetinfo, и весьма компактен - занимает в памяти всего около 400 Кб. Процесс всегда исполняется под пользователем IUSR_computername, создаваемом в процессе установки на локальной машине или домене, в зависимости от роли сервера.
Кроме означенных сервисов в IIS входят коннекторы:
Для управления сервером IIS в комплект поставки входит также графическая административная утилита Internet Service Manager, позволяющая управлять любым количеством серверов с одного рабочего места. Утилита использует протокол RPC.
Рис. 83. Консоль управления IIS
Кроме того в составе IIS есть встроенные средства для выполнения большинства административных действий через любой браузер, поддерживающий стандарт HTML 2.0 и выше. Однако в обеих случаях для управления сервером, необходимо иметь на нем привилегии администратора.
Для контроля обращений, выполняемых пользователями действий, и сбора статистики IIS поддерживает ведение журнала. Данные могут записываться в трёх форматах:
Для наблюдения за сервером и отдельными сервисами в реальном времени можно использовать Performance Monitor или любое средство мониторинга на основе SNMP.
Протокол HTTP
Сервис WWW использует для общения с клиентом Hypertext Transport Protocol (HTTP) версии 1.0. HTTP поддерживает встроенные средства универсальной адресации ресурсов (URL), переадресации запросов, средства типизации данных и согласования способов их представления, он не требует наличия постоянного соединения клиента с сервером и не привязан к особенностям какой-либо операционной системы. Протокол HTML (Hypertext Markup Language), благодаря которому возникло и с которым ассоциируется понятие World Wide Web, является одним из поддерживаемых HTTP протоколов. Общение клиента с сервером можно упрощенно представить в виде серии запросов клиента (request) и ответов (response) сервера (рисунок 84). Соединение между компьютерами существует только в промежутке между посылкой запроса и ответом сервера. Сразу после отправки ответа, сервер закрывает соединение, что с одной стороны дает ему возможность продолжить обработку ждущих запросов от других клиентов, но с другой, не позволяет эффективно организовать пересылку информации, изменяющейся во времени.
Рис. 84. Типичная схема взаимодействия клиента и сервера по протоколу HTML
Universal Resource Locator (URL) - общепринятая схема указания местонахождения ресурсов в Internet вне зависимости от протокола доступа и операционной системы сервера. URL состоит из трех частей:
Например для HTTP формат записи URL таков:
http://host[:port]obj_path
где
Протокол FTP
Несмотря на то, что большинство функций FTP перекрывается протоколом HTTP, FTP остаётся пока единственным стандартным способом загрузки файлов с клиента на сервер. Кроме того, FTP основывается на постоянном соединении между сервером и клиентом, что позволяет гарантировать доставку информации и восстановление при ошибках передачи.
FTP сервер в составе IIS позволяет ограничивать количество одновременно подключенных к нему пользователей, модифицировать сообщения при установлении и закрытии соединения, а также выполнять аннотацию директорий. Так, при наличии соответствующего ключа в Registry и файла с именем ~ftpsvc~.ckm в текущей директории, его содержимое будет отображаться на экране пользователя при попадании в данную директорию. Однако FTP сервер IIS не поддерживает режим reget, несмотря на то, что в последнее время в Internet он достаточно распространен. Это, видимо, объясняется отсутствием данного метода в RFC на протокол.
Протокол Gopher
Протокол Gopher был изначально ориентирован на использование упрощенного пользовательского интерфейса алфавитно-цифровых терминалов. Он имеет ряд преимуществ по сравнению с FPT, так как позволяет не только загружать файлы, но и создавать ссылки на ресурсы, находящиеся в других директориях и на других компьютерах, производить аннотацию ресурсов и создавать систему вложенных меню. В Gopher есть средства интеграции с системой поиска WAIS. Полезен в организациях, где созданы значительные информационно-поисковые системы на его базе. Системы, создаваемые в последнее время, используют стандарт HTML.
Для каждого из протоколов, HTTP, FTP и Gopher, IIS позволяет менять номера портов, используемых по умолчанию. Для FTP и Gopher это может выполняться как посредством модификации файла Services, расположенном, как правило, в директории %SystemRoot%\System32\Drivers\Etc, так и путем изменения установок Registry, однако настройки, заданные в файле сервисов, имеют больший приоритет. Сервис HTTP настраивается только через Registry.
Назад | Содержание | Вперед