Системи, що мають програми розподіленої середовища, відповідно, є серверами і клієнтами. Сервери пов'язані один з одним логічними каналами, за якими передають один одному файли. Кожен сервер має свою групу клієнтів.
Середовище має триступеневу архітектуру:
Функції, що їх середовищем, записані на мові C і включають прикладні служби:
· Каталогів, що дозволяє клієнтам знаходити потрібні їм сервери; · Інтерфейсу багатопотокової обробки; · Віддаленого виклику процедур; · Обслуговування файлів; · Безпеки даних; · Часу, синхронизирующей годинник в абонентських системах.
Програмне забезпечення середовища занурюється в мережеву операційну систему. Сервери мають свої, різні, операційні системи. У ролі сервера може також виступати мейнфрейм.
Функціонування розподіленої середовища вимагає виконання ряду адміністративних завдань. До них, в першу чергу, відносяться кошти:
· Реєстрації та контролю за ліцензіями користувачів на роботу з прикладними програмами; · Уніфікованих інтерфейсів прикладних програм; · Забезпечення безпеки даних; · Інвентаризації програмного і технічного забезпечення абонентських систем, що працюють в мережі.
З точки зору логічного управління середовище обробки даних ділиться на осередки DCE. Осередком DCE називається логічний елемент управління, де може бути від декількох одиниць до декількох тисяч комп'ютерів і виконується одна і більш додатків і служб DCE.
Розміри осередку яке територіально не обмежені: від декількох машин, об'єднаних в локальну мережу, і до систем, що знаходяться на різних континентах.
В осередках виконуються служби:
Як створити середовище dce Планування
Перш ніж визначати розміщення DCE, слід проаналізувати мережеву середу і прикладні програми, щоб відповісти на питання: скільки додатків передбачається виконати? Як вони будуть спілкуватися між собою? Скільки користувачів виявиться в кожному вузлі? Чи збираються користувачі одночасно працювати з декількома додатками? Як часто користувачам доведеться звертатися до служби захисту? Коли вони будуть реєструватися в осередку? Як часто користувачам потрібно буде викликати програми?
Відповівши на них, ви зможете визначити набір вимог до конфігурації різних осередків та узгодити поставлені перед вами завдання з наявними технічними можливостями.
Одна осередок чи кілька? При вирішенні цього питання необхідно домогтися оптимального співвідношення між вартістю, складністю експлуатації та рівнями сервісу.
У разі використання декількох осередків тиражування служб DCE підвищує продуктивність і надійність додатків, але в той же час веде до подорожчання і ускладнення управління середовищем DCE. Розподіл додатків по осередках захищає їх від збоїв в окремих осередках і дозволяє пристосувати служби DCE для потреб конкретних груп, що також збільшує витрати і складність управління.
Додатки, розміщені в різних осередках, можуть обмінюватися даними, але подібний обмін не так ефективний, як обмін всередині одного осередку, оскільки додатків доводиться звертатися до глобальної службі каталогів і координувати свою активність з двома службами захисту.
Якщо ваша компанія або її оперативна інформаційна служба територіально розбита на сегменти, то цілком природно розмістити окрему клітинку в кожному офісі. Між осередками, додатки яких спільно використовують одні і ті ж дані, потрібно встановити з'єднання. Але це можливо тільки за умови, що всі операції виконуються в межах одного географічного пункту.
Якщо ж адміністратори служби захисту працюють в Києві, а решта персоналу - в Дніпропетровську, доведеться організувати осередок, що охоплює обидва міста, в команді якої всі необхідні функції.
Рекомендується по карті проаналізувати розміщення додатків і скласти кілька варіантів конфігурації осередків.
Окремі групи користувачів, наприклад відділи продажів, маркетингу і кадрів, можна об'єднати в одну клітинку. Але якщо відділ кадрів вимагатиме обмежити доступ до своїх даних співробітників інших підрозділів, то для нього треба буде виділити окрему клітинку з власною службою захисту. Тоді у співробітника, що займається маркетингом, з'являться всі права доступу до даних свого відділу і обмежений доступ до даних про колег, що зберігаються в осередку відділу кадрів.
При використанні декількох осередків можна обмежити доступ до додатків, наприклад дозволити всім клієнтам доступ в перший осередок, а для доступу до додатка в другій ввести спеціальний пароль. Така схема практично еквівалентна застосуванню брандмауерів.
При меншій кількості осередків DCE знижуються витрати на покупку ліцензій і спрощується управління осередками. Але якщо ви вирішили обмежитися одним осередком, врахуйте, що збій в ній здатний паралізувати роботу компанії на тривалий час.
При визначенні числа осередків слід взяти до уваги і рівень підготовки обслуговуючого персоналу вашої фірми. Скарги на складність управління середовищем DCE вже стали притчею во язицех. При великому числі осередків персоналу доведеться мати справу зі значним обсягом інформації про характер обміну даними між осередками. Якщо для доступу до кожної клітинки встановити свій пароль, то оператори, часто допомагаючи користувачам відновлювати забутий пароль, будуть витрачати на це багато часу.
Навіть при єдиною осередку деякі структури каталогів суттєво ускладнюють процес управління. Так, служба каталогів дозволяє копіювати каталоги в центри обробки інформації в межах одного осередку. Необхідно визначити тільки, де розташовані ці центри, який з них буде керувати даними і куди слід помістити головний екземпляр кожного каталогу.
У міру збільшення числа додатків DCE виникає проблема відстеження версій. Наприклад, багато користувачів хочуть застосувати нові засоби захисту даних і управління зі складу DCE 1.2. Зазвичай перехід на наступну версію не викликає ускладнень, проте деякі утиліти, що використовують DCE, наприклад менеджер транзакцій, не працюють під управлінням DCE 1.2 або підтримують тільки частина її можливостей. Тому в ряді випадків перехід на нову версію доводиться відкладати до появи удосконалених варіантів утиліт.
Якщо у вашій організації за управління конфігурацією відповідає не визначене підрозділ, а розробники додатків, то краще розмістити додатки в різних осередках. Тоді кожна група розробників зможе сама вирішувати, в який час і як переходити на нову версію. У разі коли додатки в цих осередках обмінюються даними, необхідно синхронізувати перехід на нові версії, тому що в різних версіях CDE (наприклад, 1.0 і 1.1) реалізуються різні моделі обміну між осередками.
Контроль за зміною спільно використовуваних ресурсів - баз даних, системного і мережевого ПО - повинен здійснюватися централізовано. Конфігурація осередку може впливати на результати тестування додатків. Очевидно, що таке тестування краще проводити в середовищі, максимально наближеному до реального. Тому програму, яка буде виконуватися в декількох осередках, треба тестувати при різних конфігураціях, що потребують додаткових витрат.
Складнощі при тестуванні можуть виникнути і в разі невеликого числа осередків. Якщо додаток працює тільки в одній комірці, де виконується безліч інших програм, то слід провести тестування сумісність, що особливо важливо при використанні декількома додатками одного процесора або бази даних.