Аналіз роботи системи

Якщо ви наймаєте адміністратора мережі, то намагайтеся найняти його на самому початку планування мережі — ще до того, як оберете мережу, яку будете встановлювати. Притягнення адміністратора на етапі початкового планування допоможе в процесі установки і прискорить конфігурацію системи. Знання, отримані під час планування, збагатять починаючого адміністратора великою кількістю корисної інформації, яка знадобиться йому в подальшій роботі, а досвідченому — ознайомитися з непередбаченими проблемами, що завжди неминуче виникають.

Крім того, такий підхід вирішить багато етичних проблем, що будуть виникати в процесі роботи між вами й адміністратором.

Якщо ви збираєтеся найняти нового адміністратора для вже існуючої мережі, то приготуйтеся до того, що йому знадобиться значний час для ознайомлення з вашою системою. Не плекайте надію, що коли в адміністратора вже є досвід роботи з подібною системою, то він включиться в справу без ускладнень. У кожної мережі є індивідуальні особливості і свій колектив користувачів. Для розуміння системи адміністратору знадобляться дві речі: знання технічних особливостей мережі (це досягається досвідом) і знання її реальних робочих характеристик (це приходить тільки з щоденною практикою). Інакше кажучи, чим довше адміністратор працює з вашою системою, тим цінніше він стає.

Одна з найскладніших задач керування мережею — установка програмного додатка таким чином, щоб він працював з максимальною ефективністю. У багатьох випадках, адміністратор захоче помістити копію додатка на жорсткий диск кожної робочої станції, з якої цей додаток буде запускатися. Це не єдиний раціональний метод збереження, але кожна робоча станція зможе запускати додаток локально. Це зменшить мережевий трафік і збільшить продуктивність. Можливо, так варто зробити з традиційними автономними додатками, такими як текстовий процесор і електронні таблиці. У цих випадках частий доступ до файлів програмного додатка буде зменшувати загальну продуктивність мережі. Припустимо, що окремий додаток у кожний момент часу буде використовуватися тільки одним користувачем або, що загальне число файлів додатка занадто велике для жорсткого диску робочої станції або, що цей додаток можна цілком завантажити в пам'ять робочої станції і користуватися ним звідти увесь день (як це відбувається у випадку з деякими найпростішими електронними таблицями). У цих випадках адміністратор може віддати перевагу розміщенню таких додатків на сервері; користувачі ж — запускатимуть їх через мережу.

Адміністратор може прийти до висновку, що збереження на сервері деяких додатків, орієнтованих на роботу в мережі, є більш ефективним. Це може стосуватися таких додатків, як програмне забезпечення серверу (SQL, Informix або ін.), який працює безпосередньо з базами даних, що розподіляються, які зберігаються на сервері, і передає результати їх обробки на робочу станцію. Локальний запуск програмного забезпечення такого типу не покращить продуктивність. Потужні СКБД (додатки, що відповідають на SQL-запити) можуть працювати неефективно на локальних жорстких дисках (або навіть не працювати зовсім через недостатність ресурсів). У цих випадках адміністратор, ймовірно, просто протестує різноманітні конфігурації, щоб вирішити, як їх краще запустити в даній системі.

Базуючись на приведених вище прикладах, можна вивести загальне правило використання мережевого програмного забезпечення: автономні додатки краще працюють локально, а додатки, призначені для роботи в мережі, — на сервері. Але є багато винятків, які виявляються під час роботи чи настроювання.

Що стосується файлів даних, то це питання значно складніше. Залежно від преваг і стилю роботи кожного окремого користувача ці файли будуть зберігатися або в мережі, або на локальному диску. Правило вивести важко, але ви можете ґрунтуватися на твердженні: “намагайтеся зберігати файли даних на сервері; це підвищить ефективність і надійність резервного копіювання”. Проте заохочуйте користувачів створювати окремі резервні копії своїх файлів.

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