1 / 36

Комп'ютерні мережі

Комп'ютерні мережі. Лекція 20 Централізоване керування. План лекції. Завдання системи керування Об’єкти керування Багаторівнева декомпозиція завдань керування Архітектура систем керування Протокол SNMP. Завдання системи керування. Рекомендації ITU-T X.700 Стандарт ISO/IEC 7498-4

clark-estes
Download Presentation

Комп'ютерні мережі

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Комп'ютерні мережі Лекція 20 Централізоване керування

  2. План лекції • Завдання системи керування • Об’єкти керування • Багаторівнева декомпозиція завдань керування • Архітектура систем керування • Протокол SNMP Лекція 20

  3. Завдання системи керування • Рекомендації ITU-T X.700 • Стандарт ISO/IEC 7498-4 • Управління конфігурацією мережі та іменуванням (Configuration Management) • Оброблення помилок (Fault Management) • Аналіз продуктивності й надійності (Performance Management) • Управління безпекою (Security Management) • Облік роботи мережі (Accounting Management) Лекція 20

  4. Configuration Management • Конфігурування параметрів як елементів мережі, так і мережі у цілому • Для елементів мережі (маршрутизатори, мультиплексори) – визначення мережних адрес, ідентифікаторів, географічного положення • Для мережі у цілому – побудова карти мережі • Може здійснюватись в автоматичному, ручному і напівавтоматичному режимах • Налаштування комутаторів і маршрутизаторів на підтримання маршрутів і віртуальних шляхів між користувачами мережі • У деяких мережах не існує протоколів маршрутизації Лекція 20

  5. Fault Management • Виявлення, визначення і усунення наслідків збоїв і відмов у роботі мережі • Реєстрація повідомлень про помилки • Фільтрація, маршрутизація повідомлень про помилки • Аналіз на основі кореляційної моделі (пошук причин) • Усунення помилок – автоматично чи напівавтоматично Лекція 20

  6. Performance Management • Накопичування статистичної інформації • Аналіз • Часу реакції системи • Пропускної спроможності реальних та/або віртуальних каналів зв’язку • Інтенсивності трафіка в сегментах • Ймовірності спотворення даних • Коефіцієнту готовності мережі • Зазначені функції аналізу необхідні як для оперативного керування, так і для планування розвитку мережі • Результати аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA), щоукладається між користувачем мережі і її адміністраторами (або провайдером) Лекція 20

  7. Security Management • Контроль доступу до ресурсів мережі • Збереження цілісності даних під час їх зберігання і передавання мережею • Ідентифікація й автентифікація • Призначення й перевірка прав доступу до ресурсів мережі • Розподіл і управління ключами шифрування • Управління повноваженнями Лекція 20

  8. Accounting Management • Реєстрація часу і обсягу використання ресурсів • Billing Лекція 20

  9. Об’єкти керування • Модель керування OSI не розрізняє об’єкти керування • Канали • Сегменти локальних мереж • Мости • Комутатори • Маршрутизатори • Модеми • Мультиплексори • Апаратне і програмне забезпечення комп’ютерів • СКБД • На практиці системи керування часто розрізняють об’єкти, і здатні керувати лише об’єктами визначених типів Лекція 20

  10. Приклади систем керування • SunNet Manager • HP OpenView • Керування комунікаційними об’єктами корпоративних мереж (концентратори і комутатори локальних мереж, маршрутизатори і пристрої доступу до глобальних мереж) • RADView (RAD Data Communications) • MainStreetXpress (Newbridge) • Обладнання територіальних мереж • Tivoli (IBM) • Універсальна система Лекція 20

  11. Багаторівнева декомпозиція завдань керування • Стандарт Telecommunication Management Network (TMN) – розроблений спільно ITU-T, ISO, ANSI, ETSI • Бізнес-керування (Business Management Layer) • Керування послугами (Service Management Layer) • Керування мережею (Network Management Layer) • Керування елементами мережі (Network Element Management Layer) • Елементи мережі (Network Element Layer, NE) Лекція 20

  12. Елементи мережі • Окремі елементи мережі можуть містити вбудовані засоби керування – сенсори, інтерфейси керування Лекція 20

  13. Керування елементами мережі • Елементарні системи керування, що автономно керують окремими елементами мережі • Як правило, такі системи розробляються і постачаються виробниками обладнання • Cisco View (Cisco) • Optivity (BayNetworks, Nortel) • Device Manager (Nortel) • RAD View (RAD Data Communications) Лекція 20

  14. Керування мережею • Координує роботу елементарних систем керування • Завдяки цьому рівню мережа починає працювати як єдине ціле Лекція 20

  15. Керування послугами • Керування транспортними та інформаційними послугами, що надаються кінцевим користувачам мережі • Підготовка мережі до надання певної послуги (формування послуги – service provisioning) • Її активізація • Оброблення викликів клієнтів • Видача завдань рівню керування мережею для формування віртуального або фізичного каналу зв’язку • Контроль якості надання послуги Лекція 20

  16. Бізнес-керування • Планування мережі на тривалий термін з урахуванням фінансових аспектів діяльності власника мережі • Підраховують доходи від експлуатації мережі • Враховують витрати на експлуатацію і модернізацію мережі • Ухвалюють рішення про розвиток мережі з урахуванням фінансових можливостей • Вітчизняна термінологія: • Усі попередні рівні – АСУТП (автоматизована система управління технологічними процесами) • Цей рівень – АСУП (автоматизована система управління підприємством) Лекція 20

  17. Архітектура систем керування мережами Модельресурсу Менеджер Агент Модельресурсу Ресурс, якимкерують • Менеджер і агент повинні використовувати однакові моделі ресурсу, яким керують • Агент наповнює свою модель фактичними параметрами, що відповідають ресурсу, яким керують • Прикладом такої моделі є MIB – Management Information Base Лекція 20

  18. Менеджер Менеджер Менеджер Менеджер Менеджер Агент Агент Агент Агент Агент Агент Агент Агент Агент Агент Агент Агент Агент Агент Агент Керування у великих розподілених системах 1. Однорангове 2. Ієрархічне Менеджер Агент Агент Агент Лекція 20

  19. Протокол SNMP • Протокол SNMP(Simple Network Management Protocol) і пов’язана з ним концепція SNMP MIB (Management Information Base) були розроблені в якості тимчасового рішення для керування маршрутизаторами Інтернет • Це тимчасове рішення вирізнялось простотою, ефективністю, гнучкістю і великим потенціалом для розширення • Протокол SNMP набув значного поширення, і в наш час використовується для керування практично усіма видами мережевого обладнання локальних і глобальних мереж • Під час розроблення протокол SNMP був однозначно орієнтований на мережі TCP/IP • В наш час він іноді використовується і для телекомунікаційного обладнання (аналогові модеми, модеми ADSL, комутатори ATM тощо) • Існують реалізації SNMP для мереж IPX/SPX • Альтернативний протокол CMIPорієнтований на стек ISO і входить до стандартів ITU-T Лекція 20

  20. Основні риси SNMP • SNMP – це протокол прикладного рівня • SNMPвикористовує схему “менеджер-агент” • У протоколі SNMP агенти є досить примітивними, від них вимагається лише мінімальний інтелект • В якості спільної моделі, якою користуються менеджери та агенти SNMP, застосовуються так звані бази даних інформації керування (Management Information Base, MIB) Лекція 20

  21. Стандарти SNMP • В системах керування, побудованих на протоколі SNMP, стандартизуються: • протокол взаємодії агента і менеджера; • мова опису моделей MIB і повідомлень SNMP: мова абстрактної синтаксичної нотації ASN.1 • стандарт ISO 8824 • рекомендації ITU-T X.680-683 • кілька конкретних моделей MIB, імена об’єктів яких реєструються у дереві стандартів ISO • MIB-I • MIB-II • RMON • RMON 2 Лекція 20

  22. Стандарти SNMP – IETF RFC • RFC-3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks / D. Harrington, R. Presuhn, B. Wijnen. – December 2002 • RFC-3412, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) / J. Case, D. Harrington, R. Presuhn, B. Wijnen. – December 2002 • RFC-3413, Simple Network Management Protocol (SNMP) Applications / D. Levi, P. Meyer, B. Stewart. – December 2002 • RFC-3414, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) / U. Blumenthal, B. Wijnen. – December 2002 • RFC-3415, View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) / B. Wijnen, R. Presuhn, K. McCloghrie. – December 2002 • RFC-3416, Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) / R. Presuhn, Ed. – December 2002 • RFC-3417, Transport Mappings for the Simple Network Management Protocol (SNMP) / R. Presuhn, Ed. – December 2002 Лекція 20

  23. Стандарти SNMP – ASN.1 • ITU-T Rec. X.680 / ISO/IEC 8824-1, Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation – July 2002. • ITU-T Rec. X.681 / ISO/IEC 8824-2, Information technology – Abstract Syntax Notation One (ASN.1): Information object specification – July 2002. • ITU-T Rec. X.682 / ISO/IEC 8824-3, Information technology – Abstract Syntax Notation One (ASN.1): Constraint specification – July 2002. • ITU-T Rec. X.683 / ISO/IEC 8824-4, Information technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications – July 2002. Лекція 20

  24. Стандарти SNMP – MIB • RFC-3418, Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) / R. Presuhn, Ed. – December 2002 • RFC-1156, Management Information Base for network management of TCP/IP-based internets / K. McCloghrie, M.T. Rose. – May 1990 • RFC-1213, Management Information Base for Network Management of TCP/IP-based internets: MIB-II / K. McCloghrie, M. Rose. – March 1991 • RFC-2819, Remote Network Monitoring Management Information Base / S. Waldbusser. – May 2000 • RFC-1513, Token Ring Extensions to the Remote Network Monitoring MIB / S. Waldbusser. – September 1993 • RFC-4502, Remote Network Monitoring Management Information Base Version 2 / S. Waldbusser. – May 2006 Лекція 20

  25. Команди протоколу SNMP • Get-request – цю команду надсилає менеджер агенту для того, щоби отримати від нього значення деякого об’єкта за його ім’ям • GetNext-request – цю команду надсилає менеджер агенту для того, щоби отримати від нього значення наступного об’єкта (ім’я не вказується) • Get-response – це відповідь агента менеджеру на команди Get-request або GetNext-request • Set – цю команду надсилає менеджер агенту для того, щоби встановити значення деякого об’єкта • Саме ця команда і використовується для керування • Trap – цю команду надсилає агент менеджеру для інформування останнього про виникнення особливої ситуації • GetBulk – ця команда була додана уSNMP v.2, її використовує менеджер для того, щоби отримати кілька значень об’єктів за один запит Лекція 20

  26. Особливості протоколу SNMP • Команди SNMP передаються з використанням транспортного протоколу UDP • UDP не забезпечує ні ідентифікації джерела команди, ні гарантій доставки • Команди Get-request і GetNext-request вимагають відповіді командою Get-response, і менеджер завжди може повторити команду, якщо не дочекається відповіді • На команди керування Set, як і на аварійні повідомлення Trap, підтверджень не передбачено, і це створює загрозу втрати повідомлень • В SNMP передбачена ідентифікація джерела команди, яка здійснюється передачею так званої Community String – “рядка співтовариства” • Цей рядок передається у відкритому вигляді, ніяк не захищений від підробок, і тому є лише засобом структурування системи керування • менеджери реагують лише на повідомлення “своїх” агентів і навпаки • SNMP може бути реалізованим поверх будь-якого транспортного протоколу, але такі реалізації не є розповсюдженими • Існує також версія SNMP v.3, яка, на відміну від ранніх версій, застосовує автентифікацію з використанням алгоритму хешування MD5 • Саме цю версію можна рекомендувати для мереж, де є загроза стороннього втручання у процес керування Лекція 20

  27. SNMP MIB • Взаємодія за протоколом SNMP спирається на припущення, що менеджер і агент мають спільну модель об’єкта • Коли менеджер запитує об’єкт за його іменем, а тим більше коли він вказує встановити певне значення об’єкта, він повинен знати, який тип має цей об’єкт • Для цього існують стандарти баз даних інформації керування, головними з яких є • MIB-I, • MIB-II, • RMON, • RMON 2. • Крім того, існують стандарти MIB для певних типів пристроїв (концентраторів, модемів тощо), а також MIB окремих компаній – виробників обладнання • Останні MIB можуть бути закритими (пропрієтарними) і підтримуватися лише системами керування тих самих компаній – виробників • Як правило, в специфікаціях конкретного обладнання, що має вбудований агент SNMP, наводиться перелік MIB, які він підтримує, і такий перелік може включати не один десяток найменувань Лекція 20

  28. MIB-I • MIB-I (RFC 1156) визначає 114 об’єктів, які підрозділяються на 8 груп: • System – загальні дані про пристрій • Interfaces – параметри мережевих інтерфейсів пристрою • Address Translation Table – опис відповідності між мережними і фізичними адресами • Internet Protocol – дані, що відносяться до протоколу IP • ICMP – дані, що відносяться до протоколу ICMP • TCP– дані, що відносяться до протоколу TCP • UDP – дані, що відносяться до протоколу UDP • EGP – дані, що відносяться до протоколу EGP Лекція 20

  29. Подальший розвиток MIB • У версії MIB-II (RFC 1213) набір стандартних об’єктів розширений до 185, а число груп збільшилось до 10 • RMON MIB (остання версія – RFC 2819 для мереж Ethernet, RFC 1513 для мереж Token Ring) є суттєвим розширенням до специфікацій MIB-I та MIB-II • Має значно поліпшені властивості щодо дистанційного моніторингу та керування пристроями • RMON – Remote Monitoring – віддалений контроль • Об’єкти RMON MIB включають • додаткові лічильники помилок в пакетах • більш гнучкі засоби аналізу трендів і статистики • потужніші засоби фільтрації для захоплення й аналізу окремих пакетів • складніші умови встановлення сигналів попередження • Агенти RMON MIB значно інтелектуальніші за агентів MIB-I та MIB-II, вони здатні виконувати значну частину аналізу інформації про пристрій, яку раніше виконували менеджери • RMON MIB також має перевагу в тому, що не залежить від протоколу мережного рівня, і тому придатна для гетерогенних середовищ • Пізніше був прийнятий стандарт RMON 2, який поширив ідеї інтелектуальної бази RMON MIB на протоколи верхніх рівнів Лекція 20

  30. Іменування і опис об’єктів MIB • Для іменування об’єктів MIB і однозначного визначення їх форматів використовується специфікація, що називається SMI (Structure of Management Information– структура інформації керування) • Наприклад, специфікація SMI включає в якості стандартних: • ім’я IpAddress– його формат визначений як рядок з 4 байтів • ім’я Counter– його визначений формат – ціле число в діапазоні 0...232–1 • Специфікація SMI спирається на формальну мову ASN.1 (Abstract Syntax Notation– абстрактна синтаксична нотація) • Мова ASN.1 ухвалена ISO в якості стандартної мови опису термінів комунікаційних протоколів • Але багато протоколів, в числі яких IP, PPP, Ethernet та інші, обходяться без цієї нотації • Зручність ASN.1 в тому, що вона забезпечує точну і однозначну трансляцію між описами термінів, зручними для сприйняття людиною, і формою кодів, притаманних протоколам • Існують правила трансляції структур даних, що описані на ASN.1, в структури даних мов програмування, наприклад, С++ • Існують транслятори, які виконують цю роботу Лекція 20

  31. Числові імена об’єктів SNMP MIB • Імена змінних MIB можуть бути записані як у символьному, так і у числовому форматах • Перший використовується у текстових документах і у повідомленнях на екрані, а числові імена – у командах протоколу SNMP • Наприклад, символьному імені SysDescrвідповідає числове ім’я 1.3.6.1.2.1.1.1. • Повне числове ім’я об’єкта SNMP MIB відповідає імені цього об’єкта у дереві реєстрації об’єктів стандартизації ISO • В стандартах Інтернет частіше застосовується інший підхід – розробники фіксують числові параметри протоколу у спеціальному RFC “Assigned Numbers” • Розробники SNMP скористались для цього реєстрацією в універсальному дереві реєстрації ISO • У дереві відображено той факт, що Інтернет – це проект Міністерства оборони США (DoD), і все, що має відношення до Інтернет, у цьому дереві має префікс 1.3.6.1. • Стандарти MIB потрапили у гілку dod.internet, а далі, цілком природно – до стандартів керування (mgmt) • Група стандартів Інтернет, для яких виділена гілка privat (1.3.6.1.4) – це стандарти, які розробляються приватними компаніями, як Cisco, Nortel Networks, Hewlett-Packard тощо Лекція 20

  32. Простір імен об’єктів ISO Лекція 20

  33. Частина дерева ISO, що включає групи об’єктів MIB-I Лекція 20

  34. Формат повідомленьSNMP • Характерною особливістю повідомлень SNMP є відсутність заголовку з фіксованими полями • Повідомлення SNMP складаються з довільної кількості полів, кожному з яких передують описувачі його типу й розміру • Обов’язковими полями є версія протоколу (version), що має цілочисловий формат (INTEGER), та ідентифікаційний рядок співтовариства (community), що має формат рядку байтів (OCTET STRING) • За обов’язковими полями йдуть описані вище команди протоколу SNMP, кожна з яких поміщається у відповідного формату блок даних протоколу (Protocol Data Unit, PDU) • Формат кожного з типів PDU і формати змінних, які в ньому містяться, чітко визначені у стандарті SNMP Лекція 20

  35. Приклад: запит про значення об’єкта SysDescr (1) 30 SEQUENCE 29 len=41 02 INTEGER ; version = 0 (SNMP v.1) 01 len=1 00 0 04 STRING ; community string = public 06 len=6 70 p 75 u 62 b 6C l 69 i 63 c A0 GETREQ ; GetRequest-PDU 1C len=28 02 INTEGER ; RequestID = 05 AE 56 02 04 len=4 05 AE 56 02 Лекція 20

  36. Приклад: запит про значення об’єкта SysDescr (2) 02 INTEGER ; ErrorStatus = 0 01 len=1 00 0 02 INTEGER ; ErrorIndex = 0 01 len=1 00 0 30 SEQUENCE ; послідовність об’єктів(VarBindList) 0E len=14 30 SEQUENCE ; перший об’єкт 0C len=12 06 OBJECTID ; ідентифікатор об’єкта 08 len=8 ; довжина 8 байт 2B 1,3 ; 1.3.6.1.2.1.1.1.0 06 6 01 1 02 2 01 1 01 1 01 1 00 0 06 NULL ; значення об’єкта (в запиті = null) 00 len=0 Лекція 20

More Related