Діагностика локальних обчислювальних мереж

При використанні SNMP присутні керовані та керуючі системи. До складу керованої системи входить компонент, званий агентом, який відправляє звіти керуючій системі. По суті SNMP агенти передають управлінську інформацію на управляючі системи як змінні (такі як "вільна пам'ять", "ім'я системи", "кількість працюючих процесів").

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

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

Апаратний агент - вбудована апаратура (з процесором і пам'яттю), в якій зберігаються програмні агенти.

Змінні, доступні через SNMP, організовані в ієрархії. Ці ієрархії та інші метадані (такі, як тип і опис змінної) описуються Базами Керуючої Інформації Management Information Bases (MIBs)).

На сьогодні існує декілька стандартів на бази даних керуючої інформації [3, 4]. Основними є стандарти MIB-I і MIB-II, а також версія бази даних для віддаленого управління RMON MIB. Крім цього, існують стандарти для спеціальних MIB пристроїв конкретного типу (наприклад, MIB для концентраторів або MIB для модемів), а також приватні MIB конкретних фірм-виробників обладнання.

Первісна специфікація MIB-I визначала лише операції читання значень змінних. Операції зміни або установки значень об'єкта є частиною специфікацій MIB-II.

Версія MIB-I (RFC 1156) визначає до 114 об'єктів, які поділяються на 8 груп:

* System - загальні дані про пристрій (наприклад, ідентифікатор постачальника, час останньої ініціалізації системи).

* Interfaces - описуються параметри мережевих інтерфейсів пристрою (наприклад, їх кількість, типи, швидкості обміну, максимальний розмір пакета).

* AddressTranslationTable - описується відповідність між мережевими і фізичними адресами (наприклад, за протоколом ARP).

* InternetProtocol - дані, що належать до протоколу IP (адреси IP-шлюзів, хостів, статистика по IP-пакетах).

* ICMP - дані, що належать до протоколу обміну керуючими повідомленнями ICMP.

* TCP - дані, що належать до протоколу TCP (наприклад, про TCP-судинних).

* UDP - дані, що належать до протоколу UDP (число переданих, прийнятих та помилкових UPD-дейтаграм).

* EGP - дані, що належать до протоколу обміну маршрутною інформацією ExteriorGatewayProtocol, використовуваному в мережі Internet (число прийнятих з помилками і без помилок повідомлень).

З цього переліку груп змінних видно, що стандарт MIB-I розроблявся з жорсткою орієнтацією на управління маршрутизаторами, що підтримують протоколи стека TCP / IP.

У версії MIB-II (RFC 1213), прийнятої в 1992 році, був істотно (до 185) розширено набір стандартних об'єктів, а число груп збільшилася до 10.

2.3.2 Агенти RMON

Новітнім додаванням до функціональних можливостей SNMP є специфікація RMON, яка забезпечує віддалену взаємодію з базою MIB.

Стандарт на RMON з'явився в листопаді 1991 року, коли Internet Engineering Task Force випустив документ RFC 1271 під назвою "Remote Network Monitoring Management Information Base" ("Інформаційна база дистанційного моніторингу мереж"). Даний документ містив опис RMON для мереж Ethernet.

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

До появи RMON протокол SNMP не міг використовуватися віддаленим чином, він допускав лише локальне управління пристроями. База RMON MIB володіє поліпшеним набором властивостей для віддаленого управління, оскільки містить агреговану інформацію про пристрій, що не вимагає передачі по мережі великих обсягів інформації. Об'єкти RMON MIB включають додаткові лічильники помилок в пакетах, гнучкіші засоби аналізу графічних трендів і статистики, більш потужні засоби фільтрації для захоплення і аналізу окремих пакетів, а також більш складні умови встановлення сигналів попередження. Агенти RMON MIB більш інтелектуальні порівняно з агентами MIB-I або MIB-II і виконують значну частину роботи з обробки інформації про пристрій, яку раніше виконували менеджери. Ці агенти можуть розташовуватися усередині різних комунікаційних пристроїв, а також бути виконані у вигляді окремих програмних модулів, що працюють на універсальних ПК і ноутбуках (прикладом може служити LANalyzerNovell).

Інтелект агентів RMON дозволяє їм виконувати прості дії з діагностики несправностей та попередження про можливі відмови - наприклад, в рамках технології RMON можна зібрати дані про нормальне функціонування мережі (Виконати так званий baselining), а потім виставляти попереджувальні сигнали, коли режим роботи мережі відхилиться від baseline - це може свідчити, зокрема, про неповну справності обладнання. Зібравши інформацію, що отримується від агентів RMON, додаток управління може допомогти адміністратору мережі (що знаходиться, наприклад, за тисячі кілометрів від аналізованого сегмента мережі) локалізувати несправність і виробити оптимальний план дій для її усунення.

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

Вбудовані зонди являють собою модулі розширення для мережевих пристроїв. Такі модулі випускаються багатьма виробниками, зокрема, такими великими компаніями, як 3Com, Cabletron, Bay Networks і Cisco. (До речі, 3Com і Bay Networks нещодавно придбали компанії Axon і ARMON, визнаних лідерів в області розробки і виробництва засобів управління RMON. Такий інтерес до цієї технології з боку найбільших виробників мережевого устаткування зайвий раз показує, наскільки потрібним для користувачів є дистанційний моніторинг.) Найбільш природним виглядає рішення вбудовувати модулі RMON в концентратори, адже саме з спостереження за цими пристроями можна скласти собі уявлення про роботу сегмента. Гідність таких зондів очевидна: вони дозволяють отримувати інформацію по всіх основних групах даних RMON при відносно невисокій ціні. Недоліком в першу чергу є не надто висока продуктивність, що проявляється, зокрема, в тому, що вбудовані зонди часто підтримують далеко не всі групи даних RMON. Не так давно 3Com оголосила про намір випустити підтримуючі RMON драйвери для мережевих адаптерів Etherlink III і Fast Ethernet. В результаті виявиться можливим збирати та аналізувати дані RMON безпосередньо на робочих станціях в мережі.

Зонди на базі комп'ютера - це просто підключені до мережі комп'ютери з встановленим на них програмним агентом RMON. Такі зонди (до числа яких належить, наприклад, продукт Cornerstone Agent 2.5 компанії Network General) володіють більш високою продуктивністю, ніж вбудовані зонди, і підтримують, як правило, всі групи даних RMON. Вони дорожчі, ніж вбудовані зонди, але набагато дешевші автономних зондів. Крім цього, зонди на базі комп'ютера мають досить великий розмір, що може іноді обмежувати можливості їхнього застосування.

Автономні зонди володіють найвищою продуктивністю; як легко зрозуміти, це одночасно і найбільш дорогі продукти з усіх описаних. Як правило, автономний зонд - це процесор (класу i486 або RISC-процесор), оснащений достатнім обсягом оперативної пам'яті і мережним адаптером. Лідерами в цьому секторі ринку є компанії Frontier і Hewlett-Packard. Зонди цього типу невеликі за розміром і дуже мобільні - їх дуже легко підключати до мережі і відключати від неї. При вирішенні задачі управління мережею глобального масштабу це, звичайно, не надто важлива властивість, однак якщо кошти RMON застосовуються для аналізу роботи корпоративної мережі середніх розмірів, то (враховуючи високу вартість пристроїв) мобільність зондів може зіграти дуже позитивну роль.

Об'єкту RMON привласнений номер 16 в наборі об'єктів MIB, а сам об'єкт RMON об'єднує відповідно до документа RFC 1271, складається з десяти груп даних.

* Statistics - поточні накопичені статистичні дані про характеристики пакетів, кількості колізій і т.п.

* History - статистичні дані, збережені через певні проміжки часу для подальшого аналізу тенденцій їх змін.

* Alarms - порогові значення статистичних показників, при перевищенні яких агент RMON посилає повідомлення менеджеру. Дозволяє користувачеві визначити ряд порогових рівнів (ці пороги можуть відноситись до самих різних речей - будь-якому параметру з групи статистики, амплітуді або швидкості його зміни і багато чому іншому), при перевищенні яких генерується аварійний сигнал. Користувач може також визначити, за яких умов перевищення порогового значення має супроводжуватися аварійним сигналом - це дозволить уникнути генерації сигналу "по дрібницях", що погано, по-перше, тому, що на постійно палаючу червону лампочку ніхто не звертає уваги, а по-друге , тому, що передача непотрібних аварійних сигналів по мережі призводить до зайвого завантаження ліній зв'язку. Аварійний сигнал, як правило, передається в групу подій, де і визначається, що з ним робити далі.

* Host - даних про хостах мережі, у тому числі і про їх MAC-адресах ..

* HostTopN - таблиця найбільш завантажених хостів мережі. Таблиця N головних хостів (HostTopN) містить список N перших хостів, що характеризуються максимальним значенням заданого статистичного параметра для заданого інтервалу. Наприклад, можна зажадати список 10 хостів, для яких спостерігалося максимальну кількість помилок протягом останніх 24 годин. Список цей буде складений самим агентом, а додаток управління отримає лише адреси цих хостів і значення відповідних статистичних параметрів. Видно, до якої міри такий підхід економить мережеві ресурси

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

* Filter - умови фільтрації пакетів. Ознаки, за якими фільтруються пакети, можуть бути найрізноманітнішими - наприклад, можна зажадати відфільтровувати всі помилкові пакети, довжина яких виявляється менше деякого заданого значення. Можна сказати, що установка фільтра відповідає як би організації каналу для передачі пакета. Куди веде цей канал - визначає користувач. Наприклад, всі помилкові пакети можуть перехоплюватися і направлятися в відповідний буфер. Крім того, поява пакету, відповідаючого встановленому фільтру, може розглядатися як подія (event), на яку система повинна реагувати заздалегідь обумовленим чином.

* PacketCapture - умови захоплення пакетів. До складу групи перехоплення пакетів (packet capture) входять буфери для захоплення, куди направляються пакети, чиї ознаки задовольняють умовам, сформульованим у групі фільтрів. При цьому захоплюватися може не пакет цілком, а, скажімо, тільки перші кілька десятків байт пакета. Вміст буферів перехоплення можна згодом аналізувати за допомогою різних програмних засобів, з'ясовуючи цілий ряд дуже корисних характеристик роботи мережі. Перебудовуючи фільтри на ті чи інші ознаки, можна характеризувати різні параметри роботи мережі.

* Event - умови реєстрації і генерації подій. У групі подій (events) визначається, коли слід відправляти аварійний сигнал додатком управління, коли - перхоплювати пакети, і взагалі - як реагувати на ті чи інші події, що відбуваються в мережі, наприклад, на перевищення заданих в групі alarms порогових значень: чи слід ставити до відома додаток управління, або треба просто запротоколювати дану подію і продовжувати працювати. Події можуть і не бути пов'язані з предачі аварійних сигналів - наприклад, напрямок пакета в буфер перехоплення теж являє собою подію.

Дані групи пронумеровані у вказаному порядку, тому, наприклад, група Hosts має числове ім'я 1.3.6.1.2.1.16.4.

Десяту групу складають спеціальні об'єкти протоколу TokenRing.

Всього стандарт RMON MIB визначає близько 200 об'єктів в 10 групах, зафіксованих в двох документах - RFC 1271 для мереж Ethernet і RFC 1513 для мереж TokenRing.

Відмінною рисою стандарту RMON MIB є його незалежність від протоколу мережевого рівня (на відміну від стандартів MIB-I і MIB-II, орієнтованих на протоколи TCP / IP). Тому, його зручно використовувати в гетерогенних середовищах, що використовують різні протоколи мережевого рівня.

2.4 Огляд популярних систем управління мережами

Система управління мережею (Network management system) - апаратні і/або програмні засоби для моніторингу та управління вузлами мережі. Програмне забезпечення системи управління мережею складається з агентів, що локалізуються на мережевих пристроях і передають інформацію мережевій керуючій платформі. Метод інформаційного обміну між керуючими додатками і агентами на пристроях визначається протоколами.

Системи управління мережами повинні володіти цілим рядом якостей:

* істинним розподілом відповідно до концепції клієнт / сервер,

* масштабністю,

* відкритістю, що дозволяє впоратися з різнорідним - від настільних комп'ютерів до мейнфреймів - обладнанням.

Перші дві властивості тісно пов'язані. Хороша масштабованість досягається за рахунок розподілу системи управління. Розподіленість означає, що система може включати кілька серверів і клієнтів. Сервери (менеджерами) збирають дані про поточний стан мережі від агентів (SNMP, CMIP або RMON), вбудованих в обладнання мережі, і накопичують їх у своїй базі даних. Клієнти являють собою графічні консолі, за якими працюють адміністратори мережі. Програмне забезпечення клієнта системи управління приймає запити на виконання яких-небудь дій від адміністратора (наприклад, побудова докладної карти частини мережі) і звертається за необхідною інформацією до сервера. Якщо сервер володіє потрібною інформацією, то він відразу ж передає її клієнту, якщо ні - то намагається зібрати її від агентів.

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

Підтримка різнорідного устаткування - скоріше бажана, ніж реально існуюча властивість сьогоднішніх систем управління. До числа найбільш популярних продуктів мережевого управління відносяться чотири системи: Spectrum компанії CabletronSystems, OpenView фірми Hewlett-Packard, NetView корпорації IBM і Solstice виробництва SunSoft - підрозділи SunMicrosystems. Три компанії з чотирьох самі випускають комунікаційне обладнання. Природно, що система Spectrum найкраще управляє обладнанням компанії Cabletron, OpenView - обладнанням компанії Hewlett-Packard, а NetView- обладнанням компанії IBM.

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

Для виправлення цього недоліку розробники систем управління включають підтримку не тільки стандартних баз MIB I, MIB II і RMON MIB, а й численних приватних MIB фірм-виробників. Лідер в цій області - система Spectrum, що підтримує близько 1000 баз MIB різних виробників.

Іншим способом більш якісної підтримки конкретної апаратури є використання на основі якої-небудь платформи управління додатку тієї фірми, яка випускає це обладнання. Провідні компанії - виробники комунікаційного устаткування - розробили і постачають вельми складні і багатофункціональні системи управління для свого обладнання. До найбільш відомих систем цього класу відносяться Optivity компанії BayNetworks, CiscoWorks компанії CiscoSystems, Transcend компанії 3Com. Система Optivity, наприклад, дозволяє робити моніторинг і управляти мережами, що складаються з маршрутизаторів, комутаторів і концентраторів компанії BayNetwork, повністю використовуючи всі їх можливості і властивості. Обладнання інших виробників підтримується на рівні базових функцій управління. Система Optivity працює на платформах OpenView компанії Hewlett-Packard і SunNetManager (попередник Solstice) компанії SunSoft. Однак, робота на основі якої-небудь платформи управління з декількома системами, такими як Optivity, занадто складна і вимагає, щоб комп'ютери, на яких все це буде працювати, володіли дуже потужними процесорами і великим обсягом оперативної пам'яті.

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

Відкритість платформи управління залежить також від форми зберігання зібраних даних про стан мережі. Більшість платформ-лідерів дозволяють зберігати дані в комерційних базах даних, таких як Oracle, Ingres або Informix. Використання універсальних СУБД знижує швидкість роботи системи управління в порівнянні зі зберіганням даних у файлах операційної системи, але зате дозволяє обробляти ці дані такими додатками, які вміють працювати з цими СУБД.

У таблиці представлені найбільш важливі характеристики найбільш популярних платформ управління

Таблиця 2.1 - Характеристики популярних платформ діагностики

3. Організація діагностики комп'ютерної мережі

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

- Виявлення дефектів фізичного рівня мережі: кабельної системи, системи електроживлення активного устаткування; наявності шуму від зовнішніх джерел.

- Вимірювання поточної завантаженості каналу зв'язку мережі і визначення впливу величини завантаження каналу зв'язку на час реакції прикладного ПЗ.

- Вимірювання числа колізій в мережі і з'ясування причин їх виникнення.

- Вимірювання числа помилок передачі даних на рівні каналу зв'язку і з'ясування причин їх виникнення.

- Виявлення дефектів архітектури мережі.

- Вимірювання поточної завантаженості сервера і визначення впливу ступеня його завантаження на час реакції прикладного ПЗ.

- Виявлення дефектів прикладного ПЗ, наслідком яких є неефективне використання пропускної здатності сервера і мережі.

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

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

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

Діагностика мережевих пристроїв (або компонента мережі) також має свої тонкощі. При її проведенні застосовують різні підходи. Вибір конкретного підходу залежить від того, що вибирається в якості критерію хорошої роботи пристрою. Як правило, можна виділити три типи критеріїв і, три основні підходи.

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

Другий підхід заснований на дослідженні базових ліній параметрів (так званих трендів), що характеризують роботу діагностуючого пристрою. Основний принцип другого підходу можна сформулювати наступним чином: "пристрій працює добре, якщо він працює так, як завжди". На цьому принципі заснована упереджувальна (proactive) діагностика мережі, мета якої - запобігти настанню її критичних станів. Противагою що попереджує є реактивна (reactive) діагностика, мета якої не запобігти, а локалізувати і ліквідувати дефект. На відміну від першого, даний підхід дозволяє виявляти дефекти, які проявляються не постійно, а час від часу. Недоліком другого підходу є припущення, що спочатку мережа працювала добре. Але "як завжди" і "добре" не завжди означають одне і те ж.

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

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

3.1 Документування мережі

Ведення документування мережі дає адміністратору цілий ряд переваг. Документування мережі може виступити:

- Інструментом для усунення несправностей - в тому випадку, якщо що-небудь йде не так як треба, документація може служити керівництвом при пошуку та усунення несправності. Вона збереже час і гроші.

- Допомогою в підготовці нового персоналу - новий співробітник буде скоріше готовий до роботи, якщо доступна документація по тій ділянці роботи, де йому належить працювати, що знову збереже час і гроші.

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

Кожна мережа має свої унікальні особливості, але володіє і багатьма загальними елементами, які повинні бути включені в документацію:

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

Інформація про сервери - тобто, та інформація, яка необхідна вам для управління та адміністрування серверами, така як ім'я, функції, IP адреси, конфігурація дисків, ОС і сервіс-паки, дата і місце покупки, гарантія і т.д

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

Конфігурація мережевих служб - мережеві служби, такі як DNS, WINS, DHCP, і RAS, критичні для операцій в мережі, слід детально описати, як вони структуровані. Дану інформацію завжди можна отримати з серверів, але документація її заздалегідь в легкочитаючому форматі дозволяє заощадити час.

Політики і профілі доменів - можна обмежити можливості користувачів за допомогою Policy Editor в Windows NT або за допомогою Group Policies в Windows 2000. При цьому існує можливість створити профілі користувачів, збережені на сервері, а не на локальній машині. Якщо такі можливості використовуються, то така інформація повинна бути документована.

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

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

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

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

Основним завданням сучасних систем документування мережі на базі програмного забезпечення є досягнення гнучкості і точності документації, а також управління мережами при низьких витратах і мінімальних труднощах. Система документування мережі зберігає дані про всіх пасивних (кабелі, роз'єми, панелі перемикань, розподільчі шафи) і активних (маршрутизатори, комутатори, сервери,, ПК, УАТС) компонентах мережі, включаючи інформацію про з'єднання та їх стану (Connectivity) в центральній реляційній базі даних (наприклад, Oracle, SQL, DB2), і візуалізує всю систему як в алфавітно-цифровий, так і в графічній формі. Крім того, грунтуючись на планах будівель та земельних ділянок, можна відобразити розташування окремих компонентів і маршрути прокладки кабелю Інформація про компоненти і їх зображення зберігаються в бібліотеці компонентів, яка постійно оновлюється. Багато сучасних систем вже пропонують клієнти Web, що дозволяють отримувати доступ до документації по мережі через Internet. Так, обслуговуючі техніки можуть на місці безпосередньо запитувати робочі завдання за допомогою мобільних пристроїв, а після виконання редаговувати їх у виробничій системі. Деякі системи документування мережі навіть мають функцію виявлення (Discovery) для автоматичного виявлення допомогою SNMP нових активних компонентів і включення їх в документацію.

При наявності системи документування мережі користувач в будь-який час може отримати актуальний і цілісний огляд всіх мережевих ресурсів інфраструктури організації. Згідно з підрахунками Міжнародної організації управління службами IT (IT Service Management Forum, ITSMF), протягом усього життєвого циклу системи IT витрати на її утримання скорочуються в результаті на 80%. Система документування мережі дозволяє здійснювати більшу (ніж при обробці вручну) кількість дій, необхідних для функціонування інфраструктури мережі, і при цьому значно економить час на їх виконання. Вдобавок предотвращаются помилки при введенні даних або їх дублювання. У систему можна вводити автоматизовані процеси для зміни інфраструктури (Change Requests) і, нарешті, автоматично створювати робочі завдання, наприклад, при ремонтних роботах або переїздах. Діяльність обслуговуючого персоналу на місцях стає набагато ефективніше, за рахунок чого істотно спрощуються процеси обслуговування та зміни комп'ютерної мережі. Розрахунки показали, що скорочення зусиль, а відповідно, і фінансових витрат на планування та документування необхідних змін в мережі може досягати 90%.

Згідно зі статистикою по Network Operating Centers (NOC), близько 80% всіх неполадок в мережі викликані несправністю проводки. При використанні системи документування мережі підприємства можна швидко локалізувати проблемну зону і, таким чином, оперативно усунути неполадки. Більш того, за допомогою системи документування мережі можна планувати і організовувати надлишкові маршрути передачі сигналу, з тим щоб у разі неполадок просто підключити їх.

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

Як приклад розглянемо деякі з подібних систем.

Friendly Pinger - це потужний і зручний додаток для адміністрування, моніторингу та інвентаризації комп'ютерних мереж. Представляє наступні можливості:

* Візуалізація комп'ютерної мережі в гарній анімаційній формі з відображенням, які комп'ютери включені, а які ні;

* Сповіщення про зупинку / запуску серверів;

* Перегляд, хто, до яких файлів звертається на комп'ютері по мережі;

* Автоматичний збір інформації про програмне і апаратне забезпечення комп'ютерів у мережі.

Малюнок 3.1- Карта мережі

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

LANState містить безліч корисних функцій для адміністраторів і користувачів мережі, наприклад, відправлення повідомлень, перезавантаження і завершення роботи віддалених комп'ютерів, пінг, визначення імені за ip адресою, трасування маршруту, сканування портів і хостів. Також є можливість отримання різної інформації про віддалених комп'ютерах (без інсталяції серверної частини на них). Наприклад, перегляд реєстру по мережі, перегляд віддаленого event log'а, перегляд списку встановлених програм. Підтримуються Windows 95/98 / Me / NT / 2000 / XP.

Для користувачів мережі: програма дозволяє наочно бачити які комп'ютери в мережі включені, а які - ні. У будь-який момент програму можна викликати з трею Windows і швидко звернутися до ресурсів потрібного комп'ютера (заміна вікна мережевого оточення). Можна налаштувати сигналізацію на включення / вимикання певних комп'ютерів і серверів в мережі, на доступність файлів і папок, на запуск web- і FTP-серверів, і на інші події. LANState здійснює контроль підключень до загальних ресурсів і відстежує звернення до файлів з мережі. Є можливість з'ясувати, хто і до яких файлів на комп'ютері звертається по мережі, в тому числі і через адміністративні ресурси.

Для адміністраторів: управління комп'ютерами в мережі, отримання різноманітної інформації про віддалені комп'ютери (списки користувачів, запущені служби і додатки, встановлені програми, доступ до реєстру і журналу подій), віддалене адміністрування, перезавантаження, включення / вимикання, і т.п. Сигналізація дозволяє своєчасно дізнатися про включення / вимикання комп'ютерів і серверів в мережі, розриві VPN-підключень, зміні розмірів або доступності файлів і папок.

Розглянемо процес створення схеми локальної мережі за допомогою цієї програми. LANState підтримує сканування SNMP-пристроїв і може малювати схему мережі автоматично із створенням ліній, що з'єднують хости. При цьому номери портів комутаторів проставляються в підписах до ліній. Для автоматичної побудови схеми мережі:

1. SNMP потрібно включити на комутаторах. Програма повинна бути дозволена в брандмауері для успішної роботи по протоколу SNMP.

2. Запустити Майстер Створення Карти Мережі.

3. Вибрати сканування мережі по діапазону IP-адрес. Вказати діапазони. Пристрої з SNMP повинні знаходитися всередині зазначених діапазонів.

Малюнок 3.2 - Задавання діапазону адрес

4. Вибрати методи сканування і налаштувати їх параметри. Поставити галочку поруч з опцією "Пошук пристроїв з SNMP ..." і вказати правильні community strings для підключення до комутаторів.

Малюнок 3.3 - Параметри і способи сканування

5. Після сканування програма повинна намалювати схему мережі. Якщо сканування SNMP пройшло успішно, з'єднання між мережевими пристроями будуть намальовані автоматично. Схема мережі може бути вивантажена в картинку, або в схему Microsoft Visio

Малюнок 3.4 - Збільшена схема мережі

Висновок

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

Щоб оцінити якість роботи мережі, необхідно не тільки провести аналіз функціонування всіх її компонентів, але і правильно узагальнити і інтерпретувати статистику спостережень і отримані результати діагностики. Головне завдання при проведенні діагностики - локалізувати проблему (умоглядно або за допомогою відтворення в ході експерименту), що вже - 99% її рішення.

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

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

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

мережевий діагностика комп'ютерний моніторинг

Список літератури

1. www.colan.ru Стів Штайнке. Діагностика мереж третього тисячоліття

2. Оліфер В.Г., Оліфер Н.А. Комп'ютерні мережі. Принципи, технології, протоколи. - СПб.: Питер, 2003. - 864 с.

3. Столлінгс В. Сучасні комп'ютерні мережі. - СПб.: Питер, 2003. - 784 с.

4. Таненбаум Е. Комп'ютерні мережі. - СПб.: Питер, 2004. - 992 с.

5. У. Річард Стівенс Протоколи TCP / IP. Практичний посібник, BHV, Санкт-Петербург, 2003.

6. А.В. Фролов і Г.В. Фролов, Локальні мережі персональних комп'ютерів. Використання протоколів IPX, SPX, NETBIOS, Москва, "Діалог-МІФІ", 1993.

7. ISDN. Цифрова мережа з інтеграцією служб. Поняття, методи, системи. П. Боккер, Москва, Радіо і зв'язок, 1991.

8. Довідник "Протоколи інформаційно-обчислювальних мереж". Під ред. І.А. Мізіна і А.П. Кулешова, Радио и связь, Москва 1990.

Размещено на Allbest.ru