используется клиентами для изменения
пароля AIX Connections.
Сервера AIX Connections
AIX Connections может выполнять роль трех
различных серверов для различных клиентов:
LSserver
NWserver
MACserver
Установка и конфигурация различных
серверов выполняется через SMIT. Пакеты,
включенные в AIX CONNECTIONS перечислены ниже:
connect.client AIX Connections
connect.info.en_US AIX Connections
connect.msg.en_US AIX Connections
connect.protocols Protocol stacks
connect.server.com Common Server Files
connect.server.lsserve LS_Server
connect.server.macserve MAC_Server
connect.server.nwserve NW_Server
netbios.api Netbios
netbios.rte Netbios
На одном и том же сервере AIX могут быть
активными один или большее количество
серверов. AIX Connections включает в себя
несколько файлов, которые разделяются
среди всех трех серверов. Цель этих файлов
состоит в том чтобы координировать услуги
между LSserver, NWserver и MACserver.
Установка AIX Connections выполняется в
директорию /usr/tn. В этой же директории
устанавливаются разделяемые между всеми
тремя серверами файлы. Разделяемые файлы
выполняют следующие функции:
Проверка базы данных контуров;
Проверка блокировки файла;
Регистрация выполняемых действий;
Административные программы.
База данных контуров
Контур - надежное соединение между двумя
узлами сети. Для каждого активного
соединения пользователя, файл определения
контура записывается в базу данных
контуров. Эта база данных ведет записи о том,
какие клиенты обращаются к серверам и какие
ресурсы они используют.
Файл блокировки
Файл блокировки, lock.smb, используется для
контроля над параллельным доступом к
файлам на сервере. Когда пользователь
открывает файл, прикладная программа
определяет, какой параллельный доступ
нужно разрешить другим клиентам.
Административные программы
Для управления базой данных контуров
используется набор административных
инструментальных средств. tnwho
показывает список текущих клиентов. tninfo
производит поиск информации о текущих
клиентах. tnck проверяет и дополнительно
корректирует базу данных контуров. Эти
функции могут также быть выполнены через SMIT.
Регистрация выполняемых действий
Если это определено в файле конфигурации,
серверы могут поддерживать накопляемый
файл регистрации соединений. Файл
разделяется между серверами и содержит
следующую информацию:
Имя пользователя AIX;
Имя машины клиента;
Сетевой адрес клиента;
Сетевое имя сервера;
Общее количество прочитанных килобайтов;
Общее количество записанных килобайтов;
Общее количество напечатанных килобайтов;
Общее количество обслуженных запросов;
Общее время соединения;
Тип сервера - LSserver, NWserver или MACserver.
Novell Network Services (NNS) 4.1 on AIX
Включенный в bonus-pack, поставляемый со
стандартной ОС AIX, программный продукт Novell
Network Services 4.1 (NNS) on AIX привносит мощные сетевые
услуги Novell NetWare 4 в систему RS/6000. NNS on AIX
обеспечивает полнофункциональную
совместимую реализацию Novell Directory Services (NDS) на
неограниченное количество пользователей,
распределенные сервисы файл и принт-сервера
Novell (в bonus-pack на 2-х пользователей), сетевую
защиту и административные сервисы для
всего семейства систем RS/6000.
Это дает возможность RS/6000 действовать как
сервер Internet и как сервер прикладных
программ пользователя ПК, использующих
операционные системы DOS 5.0, OS/2 2.1, Windows 3.11, Windows
95 и Windows NT 3.51 или их более поздние версии. NNS on
AIX обеспечивает одно, глобальное
представление всех сетевых ресурсов с
помощью NDS.
Основные свойства NNS on AIX:
Обеспечение мощной, масштабируемой и
надежной службы каталогов Novell Directory Services (NDS)
для клиентов PC.
Расширение NDS поддержкой сервиса каталога
LDAP для Internet/intranet.
Обеспечение сетевой защиты.
Обеспечение распределенных файл и принт
сервисов Novell для ПК клиентов.
Поддержка способности RS/6000 к сетевому
взаимодействию с системами с сетевой
операционной системой Netware и NDS серверами.
Доступно для AIX Версий 4.2. и 4.3
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Кластеризация
High Availability Cluster Multi-Processing (HACMP)
Традиционно, системы основанные на
менфреймах IBM всегда обеспечивали очень
высокие уровни доступности системы и её
сервисов. Однако в мире UNIX эти функции не
всегда представлены. Корпорация IBM уже
провела и проводит большую работу для
обеспечения функций высокой доступности
для UNIX.
Архитектура IBM HACMP дает возможность
соединить в кластер восемь одно- или
многопроцессорных систем RS/6000 (до 16
компьютеров IBM RS/6000 SP). Программный пакет HACMP
включает в себя графические инструменты
администратора, которые помогают
установить, сконфигурировать и управлять
вашими кластерами высокопроизводительным
способом.
High Availability Geographic Cluster (HAGEO)
Программный пакет High Availability Geographic Cluster (HAGEO)
помогает построить ещё более
отказоустойчивую систему за счёт
географического удаления компонентов
кластерной системы.
Кластер HAGEO состоит из двух географически
удаленных узлов, каждый из которых способен
поддерживать до четырех узлов
высокодоступных кластерных систем.
Имеются три режима защиты и один режим
восстановления: удаленная горячая копия,
удаленный взаимный переворот, параллельный
доступ и удаленное восстановление системы.
Требования HAGEO к программному
обеспечению
Каждая система в кластере HAGEO требует
наличия HACMP версии 4.1.1, установленный в
обеих узлах и AIX 4.1.4 for Servers. Для организации
режима защиты "параллельный доступ"
необходимо наличие AIX CLVM и Oracle Parallel Edition.
Коммуникационные линии
Могут быть использованы линии типа "точка-точка"
или сеть на основе коммутации пакетов,
поддерживаемые набором AIX TCP/IP.
Рекомендуется использовать как минимум две
линии, расположенных физически отдельно
друг на друга, чтобы не превратить связь в
ещё одну точку отказа. Производительность
HAGEO зависит от скорости линии связи и типов
сетевых услуг.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Распределенная среда обработки данных DCE
Distributed Computing Environment (DCE) - технология
распределенной обработки данных,
предложенная фондом открытого
программного обеспечения (OSF). Многие
считают ее единственным реально
существующим стандартом для связующего
программного обеспечения.
Среда DCE, разработанная в 1990 г.,
представляет собой набор сетевых служб,
предназначенный для выполнения прикладных
процессов, рассредоточенных по группе
абонентских систем гетерогенной сети.
Наряду с файловой службой, реализованной в
виде распределенной файловой системы (DFS), DCE
специфицирует следующий базовый набор
распределенных служб и технологий:
| Служба | Выполняемые функции |
| Имена | База Данных (БД) имен пользователей и средств, предназначенных для доступа пользователей к сетевым службам. |
| Удаленный доступ | Технология, обеспечивающая взаимодействие двух прикладных программ, расположенных в различных абонентских системах. |
| Защита данных | Программное Обеспечение (ПО) разрешения на доступ к ресурсам системы или сети, включающее схему Kerberos на базе RPC |
| Многопоточность | ONT>OCT Программы, обеспечивающие одновременное выполнение нескольких задач. Позволяет одновременно выполнять множество вызовов RPC в асинхронном режиме |
Достоинства DCE
Таким образом, среда DCE предлагает
множество стандартизованных и очень
полезных услуг, однако это почему-то не
принимается во внимание теми, кто
предвещает ее скорый закат. А пользователям
крупных гетерогенных сетей так необходимы
единая процедура входа в систему, единая
система справочников и информационной
безопасности для управления доступом к
данным, распределенным по всему
предприятию.
Интегрированные службы безопасности,
справочников и единого времени означают,
что соответствующим спецификации DCE
прикладным программам не надо самим
создавать эти службы или средства работы с
несколькими нестандартными (фирменными)
системами различных производителей (скажем,
службой справочника NetWare (NDS) или службой Banyan
StreetTalk).
Довольно часто связующее ПО само
реализует подобные службы или (что гораздо
хуже) реализует их лишь частично,
следствием чего являются необходимость
параллельного администрирования множества
систем и недостаточная защищенность
корпоративной информации.
Механизмом межпроцессного
взаимодействия в DCE являются вызовы
удаленных процедур. Это хорошо.
Использование RPC значительно облегчает
труд программистов. Кроме того, RPC -
достаточно гибкое средство для построения
приложений по трехуровневой архитектуре.
Основное преимущество
стандартизованного в DCE механизма RPC перед
нестандартизованными разработками
различных производителей - его интеграция с
другими службами.
Недостатки DCE
Механизм RPC является единственным
механизмом межпроцессного взаимодействия.
И это плохо. Такой механизм требует
установления соединения между клиентом и
сервером.
Кроме того, вызовы RPC являются синхронными
и блокирующими. Это означает, что
приложению приходится ждать завершения
каждого вызова.
Все это приводит к тому, что вызовы RPC, как
только они сталкиваются со столь обычными
для сетей "странностями" или с
небольшой пропускной способностью каналов
между клиентами, работают
неудовлетворительно.
По мере того как программы становятся в
большей степени событийно-ориентированными,
для обеспечения одновременного выполнения
многочисленных вызовов, реализации
асинхронных и неблокирующих RPC в DCE
предусмотрен механизм многопоточности.
Но проблема в том, что для многих
разработчиков создание многопоточных
программ оказалось значительно более
сложным делом, чем они рассчитывали.
Ахиллесова пята DCE - сам механизм RPC. Эта
устаревшая технология просто не поспевает
за новейшими технологиями межпроцессного
взаимодействия. Поэтому совершенно
естественно, что при разработках многих
продуктов связующего ПО применялся совсем
иной подход.
Механизм RPC не стал универсальным
средством для создания распределенных
прикладных систем.
В DCE нет функциональных возможностей,
связанных с организацией очередей, и столь
обычных в ориентированном на передачу
сообщений связующем ПО. Несмотря на
отсутствие стандартов на рынке такого ПО,
существует по крайней мере один продукт с
организацией очередей сообщений - Encina
Recoverable Queuing System фирмы Transarc, совместимый со
средой DCE.
Корпорация IBM сейчас ведет себя крайне
агрессивно и на рынке серверов, и на рынке
настольных систем, и на рынке сетевых
операционных систем. Вскоре она собирается
добавить поддержку DCE во все свои основные
платформы, включая LAN Server.
Может изменить ситуацию компания Microsoft,
если она решит более полно поддерживать
стандарты DCE в своих продуктах. Но она этого
не делает. И Windows NT, и Windows 95 включают в себя
реализацию механизма RPC в соответствии со
спецификацией DCE, однако другие службы DCE
этими системами не поддерживаются.
Network OLE, новая технология Microsoft,
разработанная в соответствии со стратегией
Common Object Model для распределенных приложений,
также поддерживает согласуемый с DCE
механизм RPC, но совершенно неясно, будут ли
здесь реализованы базовые службы
безопасности DCE.
Таким образом, подход Microsoft не полностью
согласуется с DCE. Microsoft поддерживает только
ту часть DCE, которая связана с RPC и является
далеко не лучшей. Непонятно, преодолеет ли
Microsoft свое нежелание использовать не ею
разработанные технологии и реализует ли
службы безопасности DCE. Microsoft может помочь
делу разработкой в рамках архитектуры WOSA
интерфейсов API для служб справочников,
единого времени и безопасности - служб,
которые могут быть обеспечены с помощью DCE
конкурентами этой фирмы.
Так же как интерфейс ODBC позволил
стандартизировать доступ к базам данных SQL
разных производителей, разработка Microsoft
могла бы сильно облегчить труд создателей
приложений, позволив им использовать
готовые службы, а не создавать свои
собственные.
Основы DCE
Системы, имеющие программы
распределенной среды, соответственно,
являются серверами и клиентами. Серверы
связаны друг с другом логическими каналами,
по которым передают друг другу файлы.
Каждый сервер имеет свою группу клиентов.
Логическая структура среды CDE
представлена на рисунке:
<!--[if gte vml 1]>
path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">
Среда имеет трехступенчатую архитектуру:
прикладная_программа-база_данных-клиент.
Функции, выполняемые средой, записаны на
языке C и включают прикладные службы:
каталогов, позволяющую клиентам
находить нужные им серверы;
интерфейса многопоточной обработки;
удаленного вызова процедур;
обслуживания файлов;
безопасности данных;
времени, синхронизирующей часы в
абонентских системах.
Программное обеспечение среды
погружается в сетевую операционную систему.
Серверы имеют свои, различные, операционные
системы. В роли сервера может также
выступать мейнфрейм.
Функционирование распределенной среды
требует выполнения ряда административных
задач. К ним, в первую очередь, относятся
средства:
регистрации и контроля за лицензиями
пользователей на работу с прикладными
программами;
унифицированных интерфейсов прикладных
программ;
обеспечения безопасности данных;
инвентаризации программного и
технического обеспечения абонентских
систем, работающих в сети.
С точки зрения логического управления
среда обработки данных делится на ячейки DCE.
Ячейкой DCE называется логический
элемент управления, где может быть от
нескольких единиц до нескольких тысяч
компьютеров и выполняется одно и более
приложений и служб DCE.
Размеры ячейки территориально не
ограниченны: от нескольких машин,
объединенных в локальную сеть, и до систем,
находящихся на разных континентах.
В ячейках выполняются службы:
контроля права работы с прикладными
программами и базами данных;
каталогов, назначающих адреса объектов;
времени, синхронизирующая часы систем;
лицензии, отслеживающей использование
видов сервиса.
Как создать среду DCE
Планирование
Прежде чем определять размещение DCE,
следует проанализировать сетевую среду и
прикладные программы, чтобы ответить на
вопросы: сколько приложений предполагается
выполнить? Как они будут общаться между
собой? Сколько пользователей окажется в
каждом узле? Намерены ли пользователи
одновременно работать с несколькими
приложениями? Как часто пользователям
придется обращаться к службе защиты? Когда
они будут регистрироваться в ячейке? Как
часто пользователям нужно будет вызывать
приложения?
Ответив на них, вы сможете определить
набор требований к конфигурации разных
ячеек и согласовать поставленные перед
вами задачи с имеющимися техническими
возможностями.
Одна ячейка или несколько? При решении
этого вопроса необходимо добиться
оптимального соотношения между стоимостью,
сложностью эксплуатации и уровнями сервиса.
В случае использования нескольких ячеек
тиражирование служб DCE повышает
производительность и надежность
приложений, но в то же время ведет к
удорожанию и усложнению управления средой
DCE. Распределение приложений по ячейкам
защищает их от сбоев в отдельных ячейках и
позволяет приспособить службы DCE для нужд
конкретных групп, что также увеличивает
затраты и сложность управления.
Приложения, размещенные в разных ячейках,
могут обмениваться данными, но подобный
обмен не так эффективен, как обмен внутри
одной ячейки, поскольку приложениям
приходится обращаться к глобальной службе
каталогов и координировать свою активность
с двумя службами защиты.
Если ваша компания или ее оперативная
информационная служба территориально
разбита на сегменты, то вполне естественно
разместить отдельную ячейку в каждом офисе.
Между ячейками, приложения которых
совместно используют одни и те же данные,
нужно установить соединение. Но это
возможно только при условии, что все
операции выполняются в пределах одного
географического пункта.
Если же администраторы службы защиты
работают в Киеве, а остальной персонал - в
Днепропетровске, придется организовать
ячейку, охватывающую оба города и
объединяющую все требуемые функции.
Рекомендуется по карте проанализировать
размещение приложений и составить
несколько вариантов конфигурации ячеек.
Отдельные группы пользователей, например
отделы продаж, маркетинга и кадров, можно
объединить в одну ячейку. Но если отдел
кадров потребует ограничить доступ к своим
данным сотрудников других подразделений,
то для него надо будет выделить отдельную
ячейку с собственной службой защиты. Тогда
у сотрудника, занимающегося маркетингом,
появятся все права доступа к данным своего
отдела и ограниченный доступ к данным о
коллегах, хранящимся в ячейке отдела кадров.
При использовании нескольких ячеек можно
ограничить доступ к приложениям, например
разрешить всем клиентам доступ в первую
ячейку, а для доступа к приложению во второй
ввести специальный пароль. Такая схема
практически эквивалентна применению
брандмауэров.
При меньшем числе ячеек DCE снижаются
расходы на покупку лицензий и упрощается
управление ячейками. Но если вы решили
ограничиться одной ячейкой, учтите, что
сбой в ней способен парализовать работу
компании на продолжительное время.
При определении числа ячеек следует
принять во внимание и уровень подготовки
обслуживающего персонала вашей фирмы.
Жалобы на сложность управления средой DCE
уже стали притчей во языцех. При большом
числе ячеек персоналу придется иметь дело
со значительным объемом информации о
характере обмена данными между ячейками.
Если для доступа к каждой ячейке установить
свой пароль, то операторы, часто помогая
пользователям восстанавливать забытый
пароль, будут тратить на это много времени.
Даже при единственной ячейке некоторые
структуры каталогов существенно усложняют
процесс управления. Так, служба каталогов
позволяет копировать каталоги в центры
обработки информации в пределах одной
ячейки. Необходимо определить только, где
расположены эти центры, какой из них будет
управлять данными и куда следует поместить
главный экземпляр каждого каталога.
По мере увеличения числа приложений DCE
возникает проблема отслеживания версий. К
примеру, многие пользователи хотят
применить новые средства защиты данных и
управления из состава DCE 1.2. Обычно переход
на следующую версию не вызывает осложнений,
однако некоторые утилиты, использующие DCE,
например менеджер транзакций, не работают
под управлением DCE 1.2 либо поддерживают
только часть ее возможностей. Поэтому в
ряде случаев переход на новую версию
приходится откладывать до появления
усовершенствованных вариантов утилит.
Если в вашей организации за управление
конфигурацией отвечает не определенное
подразделение, а разработчики приложений,
то лучше разместить приложения в разных
ячейках. Тогда каждая группа разработчиков
сможет сама решать, в какое время и как
переходить на новую версию. В случае когда
приложения в этих ячейках обмениваются
данными, необходимо синхронизовать переход
на новые версии, потому что в различных
версиях CDE (например, 1.0 и 1.1) реализуются
разные модели обмена между ячейками.
Контроль за конфигурацией совместно
используемых ресурсов - баз данных,
системного и сетевого ПО - должен
осуществляться централизованно.
Конфигурация ячейки может влиять на
результаты тестирования приложений.
Очевидно, что такое тестирование лучше
проводить в среде, максимально
приближенной к реальной. Поэтому программу,
которая будет выполняться в нескольких
ячейках, надо тестировать при разных
конфигурациях, что потребует
дополнительных затрат.
Сложности при тестировании могут
возникнуть и в случае небольшого числа
ячеек. Если приложение работает только в
одной ячейке, где выполняется множество
других программ, то следует протестировать
их совместимость, что особенно важно при
использовании несколькими приложениями
одного процессора или базы данных.
Оптимизация ячейки
После того как определено число ячеек,
каждую из них нужно оптимизировать для
получения наилучшей производительности,
доступности и масштабируемости.
Производительность приложений DCE падает до
самого низкого уровня при начальном
запуске, когда формируются запросы к
службам каталогов и защиты, а клиенты
устанавливают связи с сервером.
Впоследствии приложения обращаются к этим
службам гораздо реже.
Размещение указанных служб поблизости от
станций пользователей поможет уменьшить
падение производительности в ячейке во
время запуска. Для устранения конкуренции в
доступе к службам и приложениям DCE
рекомендуется создать достаточное
количество их копий.
Например, если в среде возникает 11
запросов на 10 серверов, попробуйте
установить один, два и даже больше
дополнительных серверов, пока в реальных
условиях не будет достигнута приемлемая
производительность.
Еще одна причина снижения
производительности в крупных сетях -
обновление информации службы защиты DCE.
Программа регистрации периодически
записывает на диск данные этой службы.
Исследование, проведенное Центром
информационных технологий Мичиганского
университета, показало, что хотя среднее
время регистрации составляет всего 2 с даже
при работе с 50200 бюджетами, иногда оно
достигает трех минут и более.
Учитывая то обстоятельство, что
первоначальные реализации DCE поддерживают
сотни, а не десятки тысяч пользователей,
нетрудно предположить, что большинство
компаний не ощутят снижения
производительности из-за процедуры
регистрации.
В версии DCE 1.2 эта проблема полностью
устранена. Повысить доступность ресурсов
поможет создание копий приложений и служб в
нескольких узлах ячейки. Такая мера
позволит в случае сбоя приложения или
службы перейти на работу с их копиями, а
также улучшит масштабируемость системы.
Для того чтобы в результате отказа
сетевого узла часть пользователей не
оказалась отрезанной от приложений и служб
DCE, попытайтесь для каждого сетевого
сегмента организовать отдельную ячейку и
скопировать в нее приложения.
Другой способ защиты от отказов узлов -
создание ячейки, где бы хранились копии
всех приложений и служб DCE. Однако он
неприменим при длительных простоях сети,
поскольку в среде DCE предусмотрен один-единственный
экземпляр информации о защите и каталогах.
Часть процессов DCE работает в каждом узле,
например программа-демон dced, которая в
версии 1.1 связывает клиента с сервером и
обслуживает каталоги. При этом в отдельном
узле может выполняться только одна копия
процесса. Хорошо что сбой процесса влечет
за собой отказ не всей ячейки, а лишь того
узла, на котором он работал.
Для восстановления нужно с помощью
сетевого или системного ПО определить
состояние этого процесса и запустить его
снова.
Размещение серверов защиты
Чтобы оптимально разместить серверы
защиты, которые отвечают за копии
регистрационных данных, вы должны
разобраться в том, как DCE использует и
обновляет регистрационную информацию.
В ячейке DCE, как правило, находится один
главный экземпляр данных службы защиты и
неограниченное число его полных копий,
предназначенных только для чтения. Запрос
на чтение может прийти на любой сервер
защиты, поскольку способ передачи его на
ближайший сервер отсутствует.
Даже если в вашей ЛС имеется копия данных
службы защиты, не исключено, что запрос на
их чтение обслужит сервер, расположенный на
другом конце сети. Поэтому старайтесь
размещать серверы защиты ближе к
логическому центру сети в ячейке DCE.
Например, если ячейка объединяет сети в
Киеве, Днепропетровске и Кривом Роге и все
коммуникации проходят через
Днепропетровск, то этот город и будет
логическим центром сети и именно там
следует разместить по крайней мере один
сервер защиты.
Прежде чем выбрать такой вариант,
необходимо убедиться, что сбой данного
сегмента не вызовет отказа всей сети.
Если в большинстве случаев пользователи
работают с приложениями только из
собственной ЛС и в сети нет обходных
маршрутов, имеет смысл поместить сервер
защиты в каждой локальной сети.
Что касается запроса на обновление данных
службы защиты, то он всегда поступает на
сервер, где хранится их главный экземпляр.
Для этих целей лучше всего использовать
сервер, расположенный ближе к логическому
ядру сети ячейки.
Хотя среда DCE обеспечивает защиту обмена