Основы dce

Системы, имеющие программы распределенной среды, соответственно, являются серверами и клиентами. Серверы связаны друг с другом логическими каналами, по которым передают друг другу файлы. Каждый сервер имеет свою группу клиентов.

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

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

Функции, выполняемые средой, записаны на языке C и включают прикладные службы:

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

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

Функционирование распределенной среды требует выполнения ряда административных задач. К ним, в первую очередь, относятся средства:

· регистрации и контроля за лицензиями пользователей на работу с прикладными программами; · унифицированных интерфейсов прикладных программ; · обеспечения безопасности данных; · инвентаризации программного и технического обеспечения абонентских систем, работающих в сети.

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

Размеры ячейки территориально не ограниченны: от нескольких машин, объединенных в локальную сеть, и до систем, находящихся на разных континентах.

В ячейках выполняются службы:

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

Как создать среду dce Планирование

Прежде чем определять размещение DCE, следует проанализировать сетевую среду и прикладные программы, чтобы ответить на вопросы: сколько приложений предполагается выполнить? Как они будут общаться между собой? Сколько пользователей окажется в каждом узле? Намерены ли пользователи одновременно работать с несколькими приложениями? Как часто пользователям придется обращаться к службе защиты? Когда они будут регистрироваться в ячейке? Как часто пользователям нужно будет вызывать приложения?

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

Одна ячейка или несколько? При решении этого вопроса необходимо добиться оптимального соотношения между стоимостью, сложностью эксплуатации и уровнями сервиса.

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

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

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

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

Рекомендуется по карте проанализировать размещение приложений и составить несколько вариантов конфигурации ячеек.

Отдельные группы пользователей, например отделы продаж, маркетинга и кадров, можно объединить в одну ячейку. Но если отдел кадров потребует ограничить доступ к своим данным сотрудников других подразделений, то для него надо будет выделить отдельную ячейку с собственной службой защиты. Тогда у сотрудника, занимающегося маркетингом, появятся все права доступа к данным своего отдела и ограниченный доступ к данным о коллегах, хранящимся в ячейке отдела кадров.

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

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

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

Даже при единственной ячейке некоторые структуры каталогов существенно усложняют процесс управления. Так, служба каталогов позволяет копировать каталоги в центры обработки информации в пределах одной ячейки. Необходимо определить только, где расположены эти центры, какой из них будет управлять данными и куда следует поместить главный экземпляр каждого каталога.

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

Если в вашей организации за управление конфигурацией отвечает не определенное подразделение, а разработчики приложений, то лучше разместить приложения в разных ячейках. Тогда каждая группа разработчиков сможет сама решать, в какое время и как переходить на новую версию. В случае когда приложения в этих ячейках обмениваются данными, необходимо синхронизовать переход на новые версии, потому что в различных версиях CDE (например, 1.0 и 1.1) реализуются разные модели обмена между ячейками.

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

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