В случае возникновения нештатной ситуации на рабочей станции пользователя администратору или сотруднику отдела технической поддержки зачастую приходится разбираться с проблемой на месте, на что тратится значительное количество драгоценного времени. С другой стороны, как показывает практика, львиная доля нештатных ситуаций скорее связана с ошибками самих пользователей, нежели с некорректной работой программного обеспечения. В ряде случаев на место происшествия оперативно прибыть вообще не представляется возможным, хотя для исправления ситуации достаточно беглого взгляда на настройки системы или воспроизведения действий пользователя, приведших к неожиданному поведению программного обеспечения. В такой ситуации возможность осуществить удалённый доступ к рабочей станции пользователя оказывается весьма полезной.
В версия SMS 1.2 режим удалённой консоли может быть установлен для операционных систем: MS-DOS, Windows 3.1x, Windows95 и Windows NT.
Рис. 62. Панель настройки удаленного доступа Windows NT
Организация удаленного доступа к компьютерам требует выполнения на них ряда предварительных операций. В частности: разрешения удаленного доступа, удаленной перезагрузки, передачи файлов на удаленный компьютер и т.п. Программное обеспечение для удаленного доступа и диагностики устанавливается как часть процесса установки клиентских компонент SMS. На рисунке 62 приведен пример настроек для компьютера под управлением Windows NT.
При поступлении на компьютер запроса на удаленное администрирование пользователь компьютера получает уведомление об этом и на своё усмотрение может разрешить или запретить доступ к своему компьютеру. Однако поскольку на станциях и серверах NT режимом удалённой консоли заведует сервис, исполняющийся на данной машине, доступ к ней может быть осуществлён без наличия пользователя на консоли и без уведомления пользователя о факте установления удаленного сеанса.
Удаленное управление может выполняться при доступе через локальные или глобальные сети по любому из поддерживаемых сетевых протоколов. В момент установления соединения подбор протокола производится автоматически.
Для компьютеров под управлением DOS/Windows/Windows95 дополнительно можно просмотреть важнейшие параметры системы, как-то: доступная память, список процессов и т.п. Внешний вид программы удаленной диагностики приведен на рисунке 63 (в Windows NT встроенная утилита диагностики позволяет просматривать системные ресурсы удаленного компьютера).
Рис. 63. Утилита удаленной диагностики рабочей станции Windows
В процессе удаленного администрирования может возникнуть необходимость в поддержании диалога между пользователем и оператором. Для осуществления этой возможности предусмотрена функция Remote Chat, позволяющая пользователю с администратором перекинуться несколькими фразами, не прерывая сеанса. На рисунке 64 приведен пример диалога администратора с пользователем станции Windows95.
Рис. 64. Режим Remote Chat между администратором и пользователем Windows95
Инвентаризация аппаратного и программного обеспечения
Инвентаризация компьютера может выполняться автоматически, как часть процесса регистрации пользователя logon-сервером, либо вручную, путем запуска соответствующего командного файла из разделяемого каталога на logon-сервере. В обоих случаях на клиентской станции исполняется программа, называемая Inventory Agent. Данная программа выполняет последовательно сканирование аппаратных и программных установок. Результатом исполнения является двоичный файл, помещаемый на разделяемый диск logon-сервера для последующей обработки. Схема сбора информации для головной площадки поясняется рисунком 6.65, для вторичной - на рисунке 66.
Установка вторичной площадки
Для установки центральной и головных площадок используют стандартную процедуру инсталляции. Установка вторичных площадок инициируется администратором первичной площадки и далее выполняется автоматически. Перед началом установки между сетями головной и вторичной площадок должен существовать канал связи, на вторичной площадке должен функционировать сервер Windows NT и администратору головной площадки должны быть известны имя и пароль пользователя, имеющего административные привилегии на этом сервере. Схема исполнения задания на установку вторичной площадки приведена на рисунке 67. На первом этапе установки конфигурирование удаленного сервера выполняет sender-сервер по инструкциям Site Hierarchy Manager. На первом этапе создается сервис Bootstrap, способный обрабатывать всего один тип входящего задания. На втором этапе сервису Bootstrap передается набор команд на создание сервиса Site Configuration Manager, который выполняет остальную часть работы по настройке site-сервера, удаляет сервис Bootstrap и возвращает наверх статус завершения.
Установка пакета
Установка приложения на рабочие станции клиентов выполняется как задание Run Command On Workstation по схеме, приведенной на рисунке 68. Следует заметить, что в случае использования одного сервера одновременно в роли site, sender и хранилища исходных файлов, для передачи пакетов, таких как инсталляторы Windows или Office, размер требуемого места на жестком диске сервера должен быть ориентировочно в три раза больше, чем исходный размер инсталлятора.
Рис. 65. Схема сбора инвентаризационной информации для головной площадки
Рис. 66. Схема сбора инвентаризационной информации для вторичной площадки
Рис. 67. Схема исполнения задания на установку вторичной площадки
Рис. 68. Схема исполнения задания на установку пакета на рабочую станцию
Интеграция с системами управления сетью
Хотя в круг задач, для решения которых разрабатывался SMS, изначально не входила поддержка протокола сетевого управления SNMP, созданного в основном для управления сетевым оборудованием и его активного мониторинга, в последнюю версию SMS ограниченная поддержка этого протокола была введена.
Реализуется эта поддержка двояко:
Прерывания, генерируемые сервисом Event to Trap Translator могут быть направлены для обработки и анализа в любой из пакетов сетевого управления, таких как HP OpenView, IBM NetView for AIX и SUN NetManager. Продукты фирм HP и IBM имеют дополнения, дающие возможность принимать и обрабатывать информацию от SMS.
Рис. 69. Inventory + Pack расширяет возможности SMS
по сбору информации о компьютерах
Продукты, расширяющие функциональность SMS
В настоящее время на рынке присутствуют продукты ряда поставщиков, значительно расширяющие базовые возможности SMS как в области инвентаризации так и в области поддерживаемых операционных систем. Все они используют возможность SMS создавать и обрабатывать объекты новой архитектуры. Остановимся подробнее на наиболее полезных продуктах:
Рис. 70. Схема управления сетями NetWare при использовании AltaVista Proxy Domain Services
"Not only has SNA Server been bug-free, but it also is one of the few products I've worked with that does exactly what it says it will do."
Sean O'Farrell, Information Services Manager, Callahan Enterprises Inc.
Вводное
Несмотря на то, что в настоящее время сети персональных компьютеров играют решающую роль в деятельности организаций, по разным оценкам до 80% процентов важнейшей информации по-прежнему продолжает храниться и обрабатываться на хост-системах, базирующихся на архитектуре Standard Network Architecture (SNA) фирмы IBM. Пользователям таких систем приходится решать задачу одновременного доступа к корпоративным данным на хост-машинах и использования популярных настольных приложений. SNA Server был создан с целью дать пользователям такую возможность с наименьшими издержками и максимальной простотой. Для достижения цели интеграции ПК и мэйнфрейма существует несколько возможностей.
Прямое соединение
На ранних этапах существования ПК традиционным способом соединения их с мэйнфреймом IBM было прямое подключение посредством специализированных SNA адаптеров по коаксиальному или твинаксиальному кабелю к контроллеру логических устройств, типа IBM 3174 или IBM 5294, для чего требовался выделенный канал доступа. Позднее появились сетевые адаптеры Token Ring, позволившие общаться с контроллером доступа уже нескольким ПК одновременно. При этом использовался протокол SNA DLC (Data Link Control). Удалённые устройства подключались к хост-машинам по выделенным линиям по протоколу SDLC (Synchronous Data Link Control).
Локальные же сети, где не требовалось доступа к мэйнфреймам, быстро развивались на основе совершенно других стандартов: на аппаратном уровне - Ethernet, на уровне протоколов - IPX/SPX и TCP/IP. Были созданы многообразные устройства объединения этих сетей, средства маршрутизации и удаленного доступа, естественно несовместимые со стандартом SNA.
Включение хост-машин в локальные сети
Нежелание организаций поддерживать две различные сетевые структуры привело к попыткам использования одной кабельной сети для передачи потоков SNA и TCP/IP или IPX/SPX. Однако на практике выяснилось, что такое сосуществование породило проблем намного больше, чем ожидалось:
Были попытки установить программы сопряжения с сетями ПК на хост-машины, но стоимость таких решений оказалась непомерно высокой и производительность головных систем зачастую значительно падала за счет затрат на поддержание дополнительных сетевых протоколов, реализация которых для мэйнфреймов не была лишена недостатков. Кроме того, большинство приложений без модификации попросту не работало с данными протоколами. Поддержание стека протоколов на мэйнфреймах во многом оказалось задачей не из легких.
Шлюзы SNA
Ещё одним возможным решением, и зачастую наиболее удачным, естественно стал шлюз между сетями SNA и LAN. Шлюз позволяет настольным компьютерам использовать преимущества работы в локальной сети и осуществлять прозрачный доступ к данным и приложениям на хост-машинах, используя один из распространенных сетевых протоколов. При этой схеме с хост-системой по протоколу SNA общается только шлюз, клиенты же общаются со шлюзом по их "родному" протоколу. В настоящее время технология шлюзования LAN/SNA стала стандартом де-факто. Одна из наиболее сильных мотиваций для использования SNA шлюзов - это поддержка единственного стека протоколов на клиенте, что увеличивает стабильность работы клиентов, уменьшает расходы по памяти и упрощает работу администратора по поддержанию сетевых компьютеров. Другая сильная мотивация - это, что наиболее важно, поддержание только "родного" SNA протокола на мэйнфрейме или AS/400. Большинство существующих шлюзов поддерживают такие возможности, как организация пулов логических устройств (LU pools), балансировка нагрузки между несколькими серверами и в той или иной мере обеспечение защиты от сбоев.
Соединения клиент/сервер
В последнее время все большее распространение получают системы, которые позволяют использовать в смешанных сетях ПК-мэйнфреймов ставшие привычными сервисы:
Таким образом с применением нового поколения шлюзов мэйнфреймы постепенно превращаются из закрытых, изолированных систем в серверы приложений и хранилища данных для сетей ПК.
Microsoft SNA Server позволяет организовать два последних типа соединений.
Рисунок 71 дает наглядное представление о том, какие сервисы предоставляет Microsoft SNA Server для доступа из сетей ПК к данным на хост-машинах.
Поддерживаются мэйнфреймы IBM и совместимые с ними, а также семейство компьютеров AS/400 и полный спектр протоколов доступа. Отметим наиболее интересные возможности версии 3.0 SNA Server:
Общее понятие об архитектуре SNA-сервера дает рисунок 6.72. Модульный принцип построения и наличие промежуточного уровня SNA Dynamic Module (DMOD) позволяет обеспечить независимость от сетевого протокола и подключение дополнительных сервисов, таких как шифрование трафика без каких бы то ни было изменений в текстах или логике работы прикладных программ. Уровень DMOD присутствует как на сервере, так и на каждом клиентском месте, приложения которого используют вызовы SNA. Следует заметить, что при данной организации всегда обеспечивается контроль прав доступа. В случае, когда клиент использует интегрированную с Windows NT модель безопасности, авторизация производится средствами сервиса SNALM автоматически. Если клиент использует для доступа "чистые" протоколы IPX, TCP/IP, AppleTalk или Vines IP, за проверку прав отвечают соответствующие сервисы SNAIPX, SNATCPIP, SNAADSP и SNABV. В этом случае от пользователя требуется ввод имени и пароля. Сервисы SNA Base и SNA Server присутствуют только на сервере. В обязанности SNA Base входит получение и передача информации о настройках группы SNA-серверов.
SNA Server может быть установлен как на доменном контроллере NT (PCD или BDC), так и на member-сервере. Сервера SNA могут объединяться в логические группы, называемые субдоменами. Старшинство серверов в субдомене похоже на схему, принятую в доменах NT. Primary SNA-сервер хранит основную базу настроек группы, backup SNA-серверы хранят реплики основной базы на случай недоступности primary, обычные сервера используют информацию с ближайшего backup или primary.
В одном субдомене SNA может существовать до 15 серверов, количество субдоменов в организации не ограничено. Сервера в субдомене могут быть настроены одновременно для выполнения автоматической балансировки нагрузки и горячего резерва. Каждый из серверов группы имеет доступ к информации о пулах логических устройств доступа (LU pools), состоянии физических соединений, группах пользователей и их активности. Объединение в группы необходимо в случае, когда нужно обеспечить балансировку нагрузки и горячее резервирование каналов доступа и/или серверов.
Назад | Содержание | Вперед
