4.8. Поддержка режима удалённой консоли

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

Рис. 61. Network Monitor позволяет получать статистику о состоянии сети, перехватывать и анализировать сетевые пакеты

В версия 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

4.9. Схемы исполнения заданий

Инвентаризация аппаратного и программного обеспечения

Инвентаризация компьютера может выполняться автоматически, как часть процесса регистрации пользователя 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. Схема исполнения задания на установку пакета на рабочую станцию

4.10. Интеграция с системами управления сетями. Обзор продуктов, расширяющих функциональность SMS

Интеграция с системами управления сетью

Хотя в круг задач, для решения которых разрабатывался SMS, изначально не входила поддержка протокола сетевого управления SNMP, созданного в основном для управления сетевым оборудованием и его активного мониторинга, в последнюю версию SMS ограниченная поддержка этого протокола была введена.

Реализуется эта поддержка двояко:

• на серверах и рабочих станциях Windows NT как составляющая клиентской части SMS может исполняться сервис Event to Trap Translator, преобразующий события Windows NT, помещаемые в системный журнал, в прерывания SMNP. С помощью файлов настройки можно передавать дополнительную информацию о станции, посылающей конкретное прерывание программе наблюдения за сетью;
• на site-сервере может быть установлен сервис, называемый SMNP Trap Receiver, принимающий прерывания от сетевых устройств. Это могут быть как станции и сервера SMS исполняющие Event to Trap Translator, так и любые прочие устройства, включая мосты, коммутаторы и маршрутизаторы. Входящие прерывания SMNP могут фильтроваться по ряду параметров, как-то: IP-адресу источника, типу, индексу и т.п. Отфильтрованные прерывания сохраняются в базе данных SMS и по этой информации в дальнейшем можно выполнять выборки и, следовательно, ассоциировать с результатами запроса предупреждение SMS.

Прерывания, генерируемые сервисом Event to Trap Translator могут быть направлены для обработки и анализа в любой из пакетов сетевого управления, таких как HP OpenView, IBM NetView for AIX и SUN NetManager. Продукты фирм HP и IBM имеют дополнения, дающие возможность принимать и обрабатывать информацию от SMS.

Рис. 69. Inventory + Pack расширяет возможности SMS
по сбору информации о компьютерах

Продукты, расширяющие функциональность SMS

В настоящее время на рынке присутствуют продукты ряда поставщиков, значительно расширяющие базовые возможности SMS как в области инвентаризации так и в области поддерживаемых операционных систем. Все они используют возможность SMS создавать и обрабатывать объекты новой архитектуры. Остановимся подробнее на наиболее полезных продуктах:

• Inventory +Pack фирмы Computing Edge расширяет возможности сбора информации о клиентах и настройках операционных систем. Такие параметры как настройка ODBC драйверов, Internet Information Server, настройка принтеров и т.п. инспектируются автоматически и заносятся в базу данных. Для предопределенных типов информации в свойствах рабочей станции на административной консоли отображаются соответствующие иконки. Модифицированная версия агента на клиенте поддерживает возможности исполнения инвентаризационных сценариев из которых можно читать содержимое registry и *.INI файлов. Установка данного пакета выполняется как обычное задание SMS.

Рис. 70. Схема управления сетями NetWare при использовании AltaVista Proxy Domain Services

• AltaVista Proxy Domain Services фирмы Digital расширяет возможности SMS по управлению сетями NetWare, особенно в сетях с большим количеством WAN-соединений. Сервис, исполняющийся на Windows NT Workstation или Server, позволяет управлять произвольным количеством сетей NetWare через локальные и глобальные сети, не требуя при этом установки выделенного сервера NT на месте. Административная консоль AltaVista Proxy позволяет устанавливать необходимое программное обеспечение на серверы NetWare по принципу установки вспомогательных площадок SMS. Рисунок 6.70 поясняет принципы использования Proxy Domain Services.
• AssetWORKS v.3.0 фирмы CA расширяет поддержку инвентаризации и установку программного обеспечения на серверы и рабочие станции UNIX. Поддерживаются все наиболее популярные UNIX платформы: Solaris, SunOS, HP UX, DEC UNIX и OpenVMS, IBM AIX.

5. Шлюз SNA Server

"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.

5.1. Архитектура, обзор возможностей

Вводное

Несмотря на то, что в настоящее время сети персональных компьютеров играют решающую роль в деятельности организаций, по разным оценкам до 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. Однако на практике выяснилось, что такое сосуществование породило проблем намного больше, чем ожидалось:

• поддержка двух протокольных стеков приводила к крайней нестабильности в работе ПК и недостатку доступной оперативной памяти для выполнения прикладных программ;
• постоянный опрос состояния рабочих станций контроллерами хост-машин приводил к перегрузке сетей;
• WAN соединения ПК - хост, в связи с рядом особенностей протокола DLC, были крайне неустойчивы из-за ограничений на допустимое время отклика;
• управление сетями на основе SNA и не-SNA протоколов потребовало весьма сложных средств администрирования.

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

Шлюзы 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:

• возможность вывода заданий печати с мэйнфреймов на принтеры, подключенные к серверам печати в локальных сетях, в том числе к серверам Novell NetWare;
• унифицированная процедура регистрации, возможность синхронизации учетных записей пользователей между доменами NT и хост-машинами;
• представление разделяемых папок AS/400 как локальных ресурсов SNA шлюза с соблюдением прав доступа и возможностью накладывать дополнительные ограничения как на разделяемые тома NTFS;
• наличие драйвера ODBC/DRDA для доступа к базам данных мэйнфреймов и репликации данных из SQL Server;
• наличие шлюза FTP-AFTP для передачи файлов с ftp-клиентов на хост-компьютеры с поддержкой AFTP;
• возможность шифрования трафика между клиентом и сервером и между серверами;
• расширенная масштабируемость, поддержка до 5000 пользователей и 15 000 сессий, до 250 физических соединений и до 250 соединений с PU-устройствами, поддержка установления соединений с хост-машиной по запросу;
• средства обеспечения надёжности и доступности данных, автоматическая балансировка нагрузки, поддержка горячего резервирования на уровне хост-соединений и SNA-серверов; для обеспечения максимальной надёжности в группу горячего резервирования может быть включено одновременно до 15 серверов.

Общее понятие об архитектуре 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), состоянии физических соединений, группах пользователей и их активности. Объединение в группы необходимо в случае, когда нужно обеспечить балансировку нагрузки и горячее резервирование каналов доступа и/или серверов.

Назад | Содержание | Вперед