ВСТУП

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

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

Замкнуте коло

Строго говорячи, історія системного адміністрування нараховує декілька десятиліть, оскільки задача керування обчислюванними комплексами виникнули відразу після появи самих цих комплексів. Доминуюча до кінця 80-х років централізована обчислювальна модель типу “мейнфрейм - термінали” один до одному проектувалася на архітектуру засобів адміністрування. Строго централізована організація адміністративного ПО сьогодні багатьма сприймається в якості надбання історії. Проте усе пізнається в порівнянні, і оцінюючи із сучасних позицій можливості ніколи популярних керуючих пакетів типу RACF і додатків VTAM для платформ S/360 і S/370, припадає визнати, що по зручності і надійності ці системи можуть служити своєрідним еталоном для оцінки всіх інших засобів адміністрування.

Як відомо, на початку 90-х років ері безроздільного панування хост-комп'ютерів прийшов кінець. Бурхливе поширення розподілених архітектур клієнт/сервер викликало кардинальні перерви й у сфері керування інформаційними системами. Основна проблема полягала в тому, що замість однорідного середовища адміністраторам (і наявним в їхньому розпорядженні інструментальним засобам) прийшлося мати справу з небаченим раніше різноманіттям ресурсів, чи йшла промова про комп'ютерні платформи, активному мережному устаткуванні або програмному забезпеченні (де виникнула множина операційних систем, варіантів сполучного ПО, СУБД, офісних додатків і т.д.). Ця гетерогенність зажадала рішення цілком нових адміністративних задач - урахування розподілених ресурсів, електронного поширення ПО і контролю ліцензій, аналізу трафіка і керування пропускною спроможністю мережі, перерозподіли серверного навантаження, відслідковування стану окремих настільних систем і т.д., що попросту були відсутні! али в класичній централізованій моделі. Справа ускладнювалася ще і тим, що в нове середовище неможливо було перенести додатка адміністрування, що функціонували на мейнфреймах, так що виробникам довелося створювати керуюче ПО практично з нуля.

Трудомісткість процесів адміністрування розподіленого обчислювального середовища, що лягли важким тягарем на бюджети корпоративних замовників, явилася одним із стимулів до появи скорочених розподілених обчислюваних моделей. Восени 1996 р. компанії Oracle і Sun Microsystems виступили з ініціативою створення мережних комп'ютерів, а через півроку у надрах Intel і Microsoft зародилася концепція мережних персональних комп'ютерів (Net PC). Незважаючи на істотні відмінності цих двох архітектур (хоча один час експерти щиро протиставляли їх одну до одної), обидві вони ознаменували собою часткове повернення до централізованої обчислювальної моделі і до відповідної організації всіх процесів адміністрування. (Справедливості заради зауважимо, що якщо поява архітектури Net PC і технологій типу, що примикають, Wired for Management і Wake-on-LAN щиро мало на меті скорочення експлуатаційних витрат, то адептів мережних комп'ютерів не в останню чергу надихали! можливості нових технологій, що вперше одержали прописку в Internet.)

У прагненні до всеїдності

Еволюція концепцій адміністрування відбувалася не тільки уздовж архітектурної осі, але й у просторі тих об'єктів, що поступово утягувалися в “сферу компетенції” керуючих засобів.

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

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

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

У цьому зв'язку цікаво проаналізувати еволюцію співвідношення між мережним і системним адмініструванням. Нові проблеми, що виникли в розподілених середовищах, призвели до того, що на якийсь час мережне управління стало розглядатися в якості головної турботи адміністраторів інформаційних систем. З погляду ситуації на ринку це висловилося в різкому збільшенні попиту на платформи мережного управління (HP OpenView, IBM NetView, SunNet Manager, Cabletron SPECTRUM), що служили базою для запуску керуючих додатків. Системне ж адміністрування при цьому як би відійшло на другий план, а відповідний інструментарій фігурував у якості автономних служб, зовнішніх стосовно платформ і додатків мережного управління. Ця інверсія, що не цілком відповідає логікі функціонування корпоративних інформаційних систем (оскільки мережа відіграє роль усього лише допоміжної інфраструктури), зберігалася протягом декількох років.

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

Неминучим виявився й інший процес - інтеграція системного і мережного адміністрування, що змусила провідних виробників типу Hewlett-Packard і Computer Associates терміново модернізувати свої продукти. Проте і тут не обійшлося без перегинів: мережне адміністрування часом стало розглядатися як одна з множини складових частин адміністрування системного, а мережа - як один із керованих ресурсів поряд із комп'ютерами, периферійними пристроями, базами даних, додатками і т.д. Поборники такого дискримінаційного “прирівнювання в правах” начебто намірено не помічали того факту, що управління роботою складної гетерогенної мережі являє собою незрівнянно більш складну задачу, ніж, скажемо, контроль за функціонуванням мережних принтерів.

Питання про те, яка подальша доля цих двох областей управління корпоративними ИС, по якому шляху - інтеграційному або дезінтеграційному піде їхній розвиток, поки залишається відкритим. Варто врахувати, проте, що кінцевою ціллю всіх процедур управління є досягнення таких параметрів функціонування інформаційних систем, що відповідали би потребам користувачів. Останні ж оцінюють роботу ІС не по характеристиках мережного трафіка, застосовуваним протоколам, часу відгуку серверів на запити визначеного типу й особливостям виконуваних сценаріїв управління, а по поводженню додатків, щодня що запускаються на настільних комп'ютерах. Цей очевидний факт, що проте довгий час зникав з уваги як постачальників керуючого ПО, так і адміністраторів, дає підстави ряду експертів припустити, що на зміну мережному і системному адмініструванню в майбутньому прийде управління додатками і якістю сервісу, безвідносно до використовуваних обчислюванним платформам або мережам.

Втім, поки до остаточного об'єднання справа не дійшла, різні сфери адміністрування має сенс роздивитися один по одному.

Мережне адміністрування

Якщо не вдаватися в деталі, то задача, розв'язувані в даній області, розбиваються на дві групи: контроль за роботою мережного устаткування й управління функціонуванням мережі в цілому. У першому випадку мова йде про моніторинг окремих мережних пристроїв (концентраторів, комутаторів, маршрутизаторів, серверів доступу й ін.), настроюванню і зміні їхньої конфігурації, усуненні виникаючих збоїв. Ця достатньо традиційна група задач одержала назву реактивного адміністрування (reactive management). Друга група націлена на моніторинг мережного трафіка, виявлення тенденцій його зміни й аналіз подій із метою реалізації схем приоритизації і рішення проблем, що випереджає, пов'язаних із хибою пропускної спроможності ( попереджаюче, або профілактичне, адміністрування, proactive management). Сюди ж ставляться формування єдиного представлення мережі з метою внесення змін у її конфігурацію, урахування мережних ресурсів, управління IP-адресами користувачів, фільтрація пакетів в цілях забезпечення інформаційної безпеки і ряд інших задач.

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

Незважаючи на очевидні зручності двохрівневої схеми, її застосування в реальному мережному середовищі призводить до зростання обсягів службового трафіка і, як наслідок, зниженню ефективної пропускної спроможності, доступної додаткам. Цей ефект надається особливо виділен у складних сегментованних мережах, що містять велику кількість активних пристроїв. У якості часткового рішення проблеми вичерпання пропускної спроможності була запропонована трьохрівнева схема, у якій частина керуючих функцій делегувалася найважливішим мережним вузлам. Инстальовані в цих вузлах програми-менеджери через власну мережу агентів управляють роботою “підзвітних” їм пристроїв і в той же час самі виступають у ролі агентів стосовно основного програмі-менеджеру (менеджеру менеджерів), запущеної на керуючій станції. У результаті основна частина службового трафіка надається локалізованої в окремих мережних сегментах, оскільки “спілкування” локальних менеджерів з адміністративною консоллю здійснюється тільки тоді, коли в цьому дійсно виникає необхідність.

Очевидно, уперше трьохрівнева архітектура управління була реалізована в 1995 р. у продукті Solstice компанії Sun Microsystems. В даний час вона застосовується й у розробках інших виробників, наприклад у програмному забезпеченні Tivoli Enterprise компанії IBM.

Необхідність контролювати роботу різноманітного устаткування в гетерогенному середовищі зажадала уніфікації основних керуючих процедур. Згадана схема “менеджер - агенти” знайшла вираження в протоколі Simple Network Management Protocol (SNMP), що швидко став базовим протоколом мережного адміністрування, і в стандарті дистанційного моніторингу RMON. Управління настільними системами звичайно здійснюється на базі стандарту Desktop Management Interface (DMI), розробленого організацією Desktop Management Task Force (DMTF). Крім згаданих базових стандартів в області мережного адміністрування існують специфікації, що грають менше фундаментальну роль. Як приклад можна назвати стандарт Web-Based Enterprise Management (WBEM), запропонований улітку 1996 р. однойменним консорціумом, у який увійшли Microsoft, Intel, Cisco і ін., або з'явившийся приблизно тоді ж із йлегкої руки компанії Tivoli специфікації Network Management Environment (NME), так і не доведені! до статусу стандарту, але проте склали основу керуючої платформи TME цієї компанії.

Саме зацікавлене полягає в тому, що розв'язавши задачу упорядкування керуючих процедур і регламентації архітектури адміністративних платформ і додатків, згадані стандарти по великому рахунку не виправдали надій, що покладалися на них. Втім, сьогодні, наприкінці 90-х років здається, що інакше і бути не могло. Найгостріша конкуренція між провідними виробниками мережного устаткування змушує останніх застосовувати у своїх продуктах унікальні архітектурні рішення, деталі котрих практично ніколи не стають надбанням широкої громадськості. Тому навіть для реалізації базових можливостей протоколу SNMP модулі-агенти для конкретного устаткування звичайно надає його постачальник. Якщо ж справа доходить до детального контролю за роботою пристрою, то без керуючого ПО від виробника апаратного засобу попросту не обійтися.

Рекомендуем скачать другие рефераты по теме: культурология, скачать курсовую работу, налоги в россии.

Поделитесь этой записью или добавьте в закладки