Платформений підхід

Платформи управління мережею в свій час здавалися хорошою ідеєю. Коли альтернативою платформі управління було або використання безлічі розрізнених програмних інструментів для конфігурації, моніторингу, діагностування або супроводу кожного окремого компонента, або написання свого власного додатка, що розглядав всі компоненти як систему, гідності HP OpenView, SunNet Manager, NetView 6000 або Cabletron Spectrum не піддавались сумніву .

Платформи управління мережею надають цілий сонм цінних і складних сервісів. Вони мають механізм автоматичного виявлення всіх компонентів в мережі. Вони відображають знайдені компоненти на графічній карті, що відбиває реальну топологію мережі. Вони застосовують SNMP для збору даних про конфігурації і продуктивності маршрутизаторів, комутаторів, мостів і концентраторів. Вони зберігають зібрані відомості в базі даних, доступ до якої здійснюється за допомогою спеціального додатка для консолі. Такі події, як зміна стану пристроїв і трафіку, обробляються програмним забезпеченням платформи, причому генеруються попередження відображаються на консолі або, як варіант, пересилаються електронною поштою або на пейджер. Консольний додаток може також складати звіти про продуктивність мережі і кожного пристрою в ній за певний період часу. Ці додатки служать платформою для двох типів розробників. Виробники пристроїв і розробники оригінального ПЗ можуть написати власні додатки, що використовують платформу для отримання стандартних сервісів; в результаті їм не доведеться піклуватися про автоматичне виявленні, відображенні топології, SNMP-комунікаціях і т. п. Друга група, корпоративні розробники зі своїми специфічними запитами, які комерційні додатки задовольнити не в силах, можуть "підчепити" свій інструментарій до платформи і виконувати завдання, на які у них інакше не вистачило б ні сил, ні коштів. Зараз платформи управління мережами доживають свої останні дні, тому що мережі більше не є автономними, самодостатніми домініонами, вони стали частиною бізнес-процесів. Ще рік тому управління системами можна було відрізнити від управління мережами по тому, які процеси або пристрої перебували у віданні відповідної програми; платформи управління мережами займалися всіма процесами і пристроями між кінцевими точками (або хостами, якщо використовувати не цілком підходящу до світу ПК термінологію), а додатки управління системами обмежувалися виключно контролем над кінцевими точками (серверами, клієнтськими комп'ютерами та принтерами). У міру того як мережа набувала все більшого значення в повсякденних ділових процедурах, керування мережами стало складовою частиною управління системами. Корпоративні користувачі як споживачі мережевих сервісів зацікавлені не стільки в доступності та продуктивності підсистем, стільки в надійній роботі системи в цілому, точно так само, як для очікує відправки літака пасажира не має особливого значення, чим викликана затримка - несправністю двигуна, навантаженням продуктів або нез'ясовним шумом в кабіні пілотів.9

Ключовими концепціями сучасного управління є наскрізне управління з кінця в кінець, управління рівнем сервісу і управління відповідно до заданих правил. Наскрізне управління передбачає можливість контролю над усіма компонентами бізнес-процесу - включаючи програмне забезпечення і операційну систему, базу даних і систему транзакцій, сервери і мейнфрейми, елементи локальної та глобальної мережі - як єдиного цілого. Управління рівнем сервісу - це спосіб вираження очікувань користувачів за допомогою формального опису, у зрозумілих їм термінах, того, за що відповідають відділи ІТ. Ці вимоги користувачів знаходять конкретне вираження в так званих угодах про рівень сервісу. Управління відповідно до заданих правил - це спроба "прив'язати" технічні специфікації і параметри до конкретних бізнес-цілям. Так, корпорація може визначити, що додатки А, Б і В повинні мати пріоритет у цьому каналі глобальної мережі в робочі години, а додатки X і Y - обслуговуватися в міру можливості. Ідеальна система управління повинна автоматично визначати конкретні параметри пристрої, що дозволяють реалізувати дані правила, звільняючи адміністратора від необхідності вручну конфігурувати маршрутизатори, брандмауери, сервери і т. д.

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

SNMP-агенти на маршрутизаторах, комутаторах і концентраторах являють собою базовий інструментарій для збору інформації, що управляє. Зонди RMON, як автономні, так і інтегровані в комутатори, здійснюють збір інформації більш ефективно, а з розгортанням RMON-2 вони будуть відігравати важливу роль у здійсненні наскрізного управління. Настільні системи і ПК-сервери тепер оснащуються DMI. Настільні, серверні і мейнфреймовие операційні системи надають конфігураційну інформацію та статистику про свою роботу, яка буде недаремна для всеохоплюючої системи управління. Багато додатків створюють журнальні файли, що містять записи про такі події, як реєстрація, транзакції і помилки. Бази даних оснащуються власними специфічними агентами. Замовні програми зазвичай мають можливість генерації звітів про свою роботу в стандартному форматі. Потенціал розсилаються агентів (можливо, написаних на Java), які встановлюються на льоту або поблизу проблемного компоненту, починає нарешті використовуватися і для цілей управління; опинившись на місці, агенти посилають діагностичну та зневадження. Одні SNMP-агенти здатні породити величезний потік даних. Будь-який з цих джерел допоміжних даних в змозі заповнити весь канал, як і весь диск, "кібермусором". Таким чином, інтегрована система управління повинна мати відповідну архітектуру для збору і маніпулювання потрібними даними в потрібному місці. Наприклад, якщо мережею філії керують з центральною адміністративної станції управління, то керуючу інформацію переважніше проте тримати в локальному сховищі даних, а не передавати всі дані в центральну систему.

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

Інтелектуальна обробка подій. З ростом числа і різноманітності подій, з якими системі управління доводиться стикатися, кореляція і ототожнення подій стають нагально необхідними. У великій мережі один несправний канал може викликати цілу бурю попереджень, якщо немає будь-якого механізму для сортування артефактів з метою виявлення їх першопричини. Якщо система управління змушує дюжину адміністраторів розбиратися у вторинних попередженнях, то вона нікуди не годиться.Інтегрована система управління повинна забезпечувати гнучкість щодо консолей і доменів відповідальності. Якщо відділу ІТ для контролю за виконанням угод про рівень сервісу з користувачами необхідно бачити весь бізнес-процес від початку до кінця, це не означає, що кожен співробітник ІТ зобов'язаний знати, як конфігурувати маршрутизатор або встановлювати автоматизовану стрічкову бібліотеку. Конкретні співробітники або відділи повинні мати можливість контролювати ту частину системи, за яку вони відповідають. Всього лише пару років тому всі платформи управління мережами підтримували тільки одну консоль, тісно пов'язану з базою керуючої інформації і механізмом опитування SNMP. Всі основні виробники платформ управління видозмінили архітектуру своїх продуктів з метою підтримки декількох консолей і декількох видів представлення даних. Більш того, багато з них підключили сервери Web до виконання функцій консолі, так що адміністратори можуть принаймні здійснювати віддалений контроль над додатками з браузера.Основні виробники мережевого устаткування - Cisco Systems, Bay Networks і 3Com - послідовно пропонують програмне забезпечення для конфігурації і контролю своїх продуктів, що використовує сервіси однієї або більше платформ управління мережами. Виробники автономних додатків управління, наприклад NetScout, також розробляють програми для платформ управління. Хоча для багатьох пристроїв і процесів немає готових додатків, проте вони повинні бути якимось чином включені у всеохоплюючу систему управління. Крім того, ця система повинна підтримувати безліч специфічних для конкретної галузі додатків і правил, а також автоматизувати певні операції керування підприємством. Всі ці завдання можна вирішити тільки за умови, що незалежні розробники мають безперешкодний доступ до внутрішніх механізмам платформи управління. На щастя, всі провідні виробники корпоративних платформ управління мають діючі програми підтримки розробників.

Виробники і частки. Зі зміною самого змісту поняття "платформа управління" показники часткою ринку недостатньо відбивають справжнє становище на ринку того чи іншого продукту. Проте дані за 1995 і 1996 роки наводять на певні роздуми. За даними International Data Corp. (IDC), Hewlett-Packard, творець HP OpenView, є світовим лідером з постачань за ці два роки. Однак частка HP знизилася з 34,8% у 1995 році до 30,9% в 1996 р. Частка SunSoft також зменшилася з 31% у 1995 році до 27,4% в 1996 р. Частка платформи Spectrum компанії Cabletron зросла з 18,6 % у 1995 році до 23,6% в 1996 р. А частка NetView 6000 зросла з 6% до 12,3% (у 1996 році NetView став спільним продуктом IBM / Tivoli). Зазначимо, що NetView 6000 не була в той час включена в TME 10, спільну систему або корпоративну платформу управління цих компаній.

Дві платформи, чия частка на ринку зросла (Spectrum і NetView 6000), виявилися лідерами у розподілі функції консолі між кількома рівнями і доменами відповідальності. Крім того, завдяки розподілу функцій цими продуктами могло керувати більше число операторів, ніж в змозі підтримувати SunNet Manager або HP OpenView. SunSoft приділила головну увагу своєму Solstice Enterprise Manager, який представляє найбільший інтерес для мають власні мережі зв'язку великих замовників, - на шкоду додаткам, орієнтованим на інші категорії кінцевих користувачів. З деяким запізненням Hewlett-Packard представила версію OpenView з розподіленими консолями.

Тим часом Computer Associates і IBM / Tivoli досягли успіху в зміні правил гри на ринку платформ управління. Незважаючи на відсутність поки достовірної статистики того, яка частка ринку відійшла до нових його учасникам, Tivoli і CA займають чільне місце в коментарях експертів та відгуках користувачів.IBM / TIVOLI TME 10

Коріння Tivoli Systems йдуть в управління системами UNIX. Один час компанія спеціалізувалася на управлінні розгортанням систем (поширенні програмного забезпечення), управлінні доступністю серверів, адмініструванні інформаційного захисту, адмініструванні операцій (наприклад, резервного копіювання і відновлення) та управлінні додатками. Компанія стала використовувати у своїх продуктах об'єктно-орієнтовані засоби, як тільки вони з'явилися. Tivoli отримала цілу колекцію допоміжних інструментів управління, коли IBM придбала компанію в 1996 році. Їм було тут же присвоєно ім'я TME 10, але повна інтеграція в лінію продуктів Tivoli зажадала певного часу і зусиль. Наприклад, до злиття з IBM, Tivoli не розташовувала продуктом для управління мережами на базі SNMP, і, перш відомий як NetView 6000, продукт став (крім інших) складовою частиною TME 10 NetView. По суті включення NetView 6000 і продуктів IBM для управління мейнфреймами дало TME 10 засоби для наскрізного управління.Власні продукти Tivoli підтримували численні різновиди UNIX, а також різні версії Windows і NetWare, а об'єктно-орієнтоване спадщину зробило інтеграцію з операційними системами IBM практично безболісним. Таким чином, досьє IBM / Tivoli містить вичерпний список зустрічаються сьогодні обчислювальних середовищ. Центральний модуль TME 10 називається TME 10 Framework (раніше - Tivoli Management Platform). Framework має графічний користувальницький інтерфейс для конфігурації і моніторингу, а також інтерфейс командного рядка. Демон oserv, свого роду об'єктна шина, забезпечує глубокоуровневое взаємодію компонентів TME 10. Крім того, Framework володіє об'єктно-орієнтованої базою даних і базовими сервісами, наданими всіма компонентами TME 10, наприклад планування, поширення та встановлення додатків.Додаткові модулі здійснюють розповсюдження програмного забезпечення, інвентаризацію апаратного і програмного забезпечення, моніторинг систем, кореляцію і керування подіями, а також адміністрування користувачів та груп. Події програм, як TME 10 NetView, обробляються і корелюються поряд з генерованими іншими модулями або навіть модулями сторонніх виробників. IBM / Tivoli проводить агресивну програму підтримки незалежних розробників, завдяки якій платформа має модулі для додатків SAP R / 3, різних реляційних баз даних і таких додатків, як довідкова система Action Request компанії Remedy.

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Архітектура систем управління мережами	\|	Історія Tivoli

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.