что не имелось достаточной мощности процессора, чтобы выполнить много работ интерактивно. ќто изменилось на более современных системах.

‘егоднЯ, наиболее общее использование этих функций должно выполнить регулЯрно планируемые промышленные работы. ‚ы не можете хотеть ваших нормальных пользователей, представлЯющих любой cron или при работах.

€меютсЯ два способа управлЯть использованием этих функций. ‚ы можете запрещать определенным пользователЯм из использованиЯ этих функций, или ‚ы можете ограничивать использование списком определенных пользователей. ќто включает четыре файла:

/var/adm/cron/cron.allow
/var/adm/cron/cron.deny
/var/adm/cron/at.allow
/var/adm/cron/at.deny

„ва отвергающих файла "deny" существуют, но пусты.

„ва позволЯющих файла "allow", не существуют в распределенной системе. …сли они созданы, то отвергающие файлы игнорируютсЯ.

Џри этом использование функций cron разрешаетсЯ только тем пользователЯм, чьи userid перечислены в позволЯющем файле. ќто правило применЯетсЯ даже длЯ пользователЯ root, который должен Явным способом указан в позволЯющем файле.

Ћсобенно длЯ больших серверов, рекомендуетсЯ создание файлов /var/adm/cron/cron.allow и /var/adm/cron/at.allow, содержащие имена root и имена тех пользователей, которым разрешаетсЯ запускать планируемые промышленные работы.

Љоманда cronadm полезна длЯ проверки текущего состоЯниЯ cron:

cronadm cron -l (list all cron files)
cronadm cron -l joe (list joe's cron files)
cronadm cron -v (list job submission status)
cronadm at -l (list existing at jobs)
cronadm at -l joe (list joe's at jobs)
cronadm at -v (list submission status)

Љоманда может также использоватьсЯ, чтобы удалить работы из этих очередей. …сли cron работа не существует длЯ определенного пользователЯ, ‚ы получите сообщение AIX относительно "файл или директориЯ, не найдены".

Љ содержанию ‚перед Ќазад

Џодключение ЏЉ к серверу AIX

Љ содержанию ‚перед Ќазад

Џодключение ЏЉ к серверу AIX

AIX Connections

Ћтдельно заказываемый программный продукт AIX Connections обеспечивает решение проблемы подключениЯ ЏЉ с популЯрными операционными системами, включаЯ OS/2, Windows, Windows 95, Windows NT Workstation и MacOS к серверу с AIX.

ќтот продукт дает возможность клиентам на ЏЉ работать с прикладными программами AIX, такими как базы данных, маршрутизатизациЯ и сетевыми файловыми системами. AIX Connections также обеспечивает инфраструктуру длЯ совместного использованиЯ файлов и принтеров между серверами AIX и ЏЉ.

Љраткое описание AIX Connections

AIX Connections Version 1.1 длЯ AIX, основана на технологии TotalNet Advanced Server компании Syntax и позволЯет использовать систему с AIX как файл- и принт-сервер в сетЯх Ethernet или Token-Ring. ќтот пакет поддерживает клиентов с почти со всеми основными операционными системами:

ћ DOS 5.0 и выше;
ћ IBM OS/2 2.1 и IBM LAN Server 3.0 и выше;
ћ MacOS 6.03 или выше;
ћ Novell Netware 3.1;
ћ Microsoft LANMAN 2.0 и выше;
ћ Windows длЯ Workgroups, Windows 95/98 и Windows NT 3.51 или выше.

’ак как AIX - истинно многозадачнаЯ и многопользовательскаЯ система, то намного проще выполнЯть диагностические функции без воздействиЯ на сетевых клиентов. Џоскольку AIX также и динамическаЯ операционнаЯ система, то много изменений могут быть сделаны без прерываниЯ обслуживаниЯ пользователей. „лЯ управлениЯ большими распределенными сетЯми и системами применЯютсЯ системы на основе открытого глобального каталога и стратегиЯ безопасности DCE. AIX Connections обеспечивает естественную интеграцию в этот каталог и структуру защиты.

Ќабор функций AIX Connections:

ћ Џоддержка графических рабочих станций.
ћ ”айловый сервер и сервер печати.
ћ ‘ерверы данных Network File System (NFS)/Distributed File System (DFS).
ћ Џоддержка асинхронного Point-to-Point Protocol (PPP).
ћ Џоддержка DHCP.
ћ Џоддержка программ клиент/сервер, таких как OLTP и прикладных программ баз данных.
ћ ‘ерверы имен.
ћ ЊаршрутизациЯ.
ћ Џоддержка HACMP (кластеризации).
ћ Џоддержка Windows Internet Naming Service (WINS).

Ћсновные преимущества

ћ ‘овместимость с функциЯми файлового сервера и сервера печати - IBM Version LAN Server 4, Microsoft LAN Manager, Novell Netware и Apple.
ћ Џоддержка всех функций AIX длЯ работы с файлами, в том числе и функций защиты.
ћ Џоддержка SMIT - обеспечено интегрированное администрирование системы.
ћ Џоддержка кластеров HACMP позволЯет обеспечить файловых сервис и сервис печати высокой степенью доступности.
ћ ‚строенные функции маршрутизации позволЯют пользователЯм присоединитьсЯ к большинству внешних сетей без необходимости изменениЯ программного обеспечениЯ со стороны клиента или покупки дополнительного программного обеспечениЯ.
ћ €сключена необходимость в использовании отдельного сервера с Windows NT длЯ поддержки WINS.

‚се файлы и прикладные программы, помещаемые в RS/6000 пользователЯми и администраторами AIX Connections сохранЯютсЯ как файлы AIX. ќто означает, что эти файлы будут обрабатыватьсЯ как часть файловой системы AIX. Џреимущества Journal File System и Logical Volume Manager, типа зеркального отражениЯ дисков, больших размеров файлов и расширЯемых логических томов, теперь относЯтсЯ и к этим файлам.

‚есь диапазон средств системного управлениЯ AIX может теперь использоватьсЯ, чтобы обеспечить надежность и доступность длЯ пользователей AIX Connections. ‘ервер может также сохранЯть эти файлы на других серверах UNIX через Network File System или Distributed File System.

„оступ к файлам и защита

’ак как все файлы сохранены в файловой системе AIX, доступ к ним управлЯетсЯ AIX. Љаждому подсоединенному пользователю ЏЉ будут предоставлены разрешениЯ, основанные на userid AIX этого пользователЯ. ‚ то же времЯ сетевым клиентам не требуютсЯ регистрациЯ в AIX, чтобы обращатьсЯ к ресурсам, доступным AIX Connections. „оступ длЯ этих пользователей управлЯетсЯ AIX Connections. Џроцедура входа в любой сервер AIX Connections сравнима с процедурой входа на эмулируемом сервере. ‚ход в систему пользователЯ может иметь силу длЯ любого или всех серверов. “тилита tnpasswd используетсЯ клиентами длЯ изменениЯ паролЯ 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

Љ содержанию ‚перед Ќазад

ЉластеризациЯ

Љ содержанию ‚перед Ќазад

ЉластеризациЯ

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 зависит от скорости линии свЯзи и типов сетевых услуг.

Љ содержанию ‚перед Ќазад

ђаспределеннаЯ среда обработки данных DCE

Љ содержанию ‚перед Ќазад

ђаспределеннаЯ среда обработки данных 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 представлена на рисунке:

‘реда имеет трехступенчатую архитектуру:

прикладнаЯ_программа-база_данных-клиент.

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

Џри повышенных требованиЯх к конфиденциальности серверы защиты DCE рекомендуетсЯ размещать в охранЯемых помещениЯх информационного центра.

ђазмещение серверов каталогов

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

‚ отличие от регистрационной информации в этих копиЯх находитсЯ лишь часть информации о каталогах и их содержимом, поэтому не исключена ситуациЯ, когда ни в одном центре обработки информации не окажетсЯ полных данных о каталоге.

Љопирование каталогов в несколько центров обработки информации усложнЯет работу. Џри сбое центра, где хранитсЯ главный экземплЯр каталогов, администратору придетсЯ выЯснЯть, какие каталоги в нем размещались, и назначать длЯ них новый центр обработки информации.

„лЯ упрощениЯ восстановлениЯ служебных данных после сбоев и повышениЯ доступности целиком скопируйте структуру каталогов во все центры обработки информации и сделайте один из них главным (хранЯщим главный экземплЯр). …сли длЯ этого у вас нет возможностей, то создание и удаление каталогов отмечайте в специальном журнале.

Џри определении места размещениЯ копий каталогов следуйте тем же рекомендациЯм, что и при размещении копий регистрационных данных. Ћднако оптимизациЯ местонахождениЯ этих копий практически не влечет за собой повышениЯ производительности в случае, когда приложениЯ и службы DCE сохранЯют свою локализацию и выполнЯютсЯ длительное времЯ.

Џрограмма cdsclerks, сообщающаЯ станциЯм-клиентам имена серверов, хранит в кэш-памЯти информацию о каталогах, включаЯ сетевые адреса центров обработки информации и серверов. ‚ ситуации со стабильно работающими приложениЯми и службами cdsclerks обычно находит информацию о свЯзЯх между серверами приложений в кэш-памЯти. ќта программа обращаетсЯ в центр обработки информации тогда, когда требуемаЯ информациЯ в кэш- памЯти отсутствует, или при внесении изменений в каталог.

‘инхронизациЯ часов

Ћ значении службы времени и соответствующих рекомендациЯх OSF можно прочитать в руководстве "OSF DCE Administration Guide, Core Components", которое входит в комплект поставки DCE. ‚ нем подробно описано, какие службы времени нужны длЯ Ячеек при той или иной конфигурации сети. Џоскольку небольшаЯ ошибка в системных часах может нарушить совместимость защищенных приложений DCE, лучше всего обратитьсЯ в службу точного времени.

‘ерверы лицензий

Ќекоторые реализации DCE применЯют серверы лицензий длЯ контролЯ за модернизацией среды DCE и использованием ее служб. ‚ этих случаЯх серверы лицензий так же важны, как и серверы других служб. Џри их отказе нельзЯ запустить службы DCE, поскольку получение или обновление данных о лицензиЯх становитсЯ невозможным. Џоэтому надо предусмотреть защиту серверов лицензий, разместив их в том же охранЯемом помещении, что и серверы защиты.

‹ицензии длЯ серверов лицензий выдаютсЯ на определенной машине и не могут использоватьсЯ серверами с других машин. Џоэтому при сбое этого сервера вы терЯете доступ ко всем его лицензиЯм до устранениЯ неисправности.

Џостарайтесь, чтобы с вашим поставщиком ЏЋ среды DCE можно было быстро свЯзатьсЯ длЯ восстановлениЯ сервера лицензий или получениЯ новых лицензий на короткий срок.

„лЯ особо ответственных приложений рекомендуетсЯ купить дополнительное число лицензий.

Џодготовка персонала

Ћт вас потребуетсЯ составить план и выделить средства длЯ найма и обучениЯ обслуживающего персонала. ЏредлагаетсЯ следовать рекомендациЯм, принЯтым длЯ NetWare и длЯ других распределенных сред: на каждые 100 пользователей и серверов приложений должен приходитьсЯ один администратор.

„лЯ лучшего обеспечениЯ главных видов сервиса рассмотрите возможность обучениЯ всего персонала решению основных задач, свЯзанных со службами каталогов и защиты. Џусть одна часть сотрудников пройдет специализированную подготовку по службе защиты, другаЯ - по мониторингу транзакций, а третьЯ сосредоточитсЯ на поддержке системного и сетевого ЏЋ.

ђазработайте основные стратегии и процедуры, такие как стандарты имен интерфейсов, каталогов и их элементов, серверов приложений и других ресурсов, а также рекомендации по работе со службой защиты и копированием данных служб защиты и каталогов.

Љ содержанию ‚перед Ќазад

Ћбзор лицензированиЯ

Љ содержанию ‚перед Ќазад

Ћбзор лицензированиЯ

ЋбщаЯ концепциЯ

‹ицензирование программного обеспечениЯ применЯетсЯ длЯ контролЯ числа пользователей его использующих и помогает организации осуществлЯть контроль над выполнением лицензионных соглашений с производителЯми программного обеспечениЯ. Џри этом необходимо обеспечить удобство работы пользователей и предоставление им прав на запуск нужных им программ в распределенной среде с более чем одним сервером.

„лЯ лицензированиЯ в AIX применЯетсЯ программный продукт iFOR/LS (Information For Operation and Retrieval License System). ќто программное обеспечение управлениЯ лицензиЯми использует стандартную промышленную распределенную технологию Network Computing System (NCS) длЯ вызова удаленных процедур в модели клиент/сервер.

–ена на LPP длЯ AIX и их поставка осуществлЯетсЯ используЯ две модели лицензированиЯ: лицензиЯ на пользователЯ лицензиЯ на сервер/неограниченное количество пользователей

€спользуЯ зашифрованные ключи iFOR/LS осуществлЯет мониторинг типов и количества лицензий используемых в системе.

iFOR/LS

Џакет iFOR/LS ЯвлЯетсЯ расширением системы NetLS и его команды на 100% совместимы с системой команд NetLS. ЉомпаниЯ Hewlett-Packard приобрела права на NetLS вместе с приобретением компании Apollo Computers. ‚ 1987 году компаниЯ Gradient Technologies согласно соглашению с HP перенесла этот продукт на AIX под новой тор-говой маркой iFOR/LS.

Љомпонентами iFOR/LS ЯвлЯютсЯ:

ћ NCS 1.5.1.
ћ ARK
ћ ADK iFOR/LS требует применениЯ NCS 1.5.1.

NCS ЯвлЯетсЯ отдельно устанавливаемым пакетом bos.net.ncs.obj, содержащим комплект инструментов длЯ распределенных вычислений.

iFOR/LS поставлЯетсЯ разделенным на две части: ориентированной на поддержку разработчиков программ и ориентированной на поддержку ад