Централізуя управління мережею

    image
 
Якщо за родом своєї діяльності ви є мережевим або ІТ-адміністратором, то напевно вам доводилося стикалися з ситуаціями, коли існуючим програмним та апаратним технічним рішенням, які перебувають в експлуатації, бракує прозорого, інтуїтивно зрозумілого, централізованого засоби управління, налагодження та моніторингу.
 
Що б не придумували розробники систем управління мережевою інфраструктурою в спробі надати технічному персоналу зручний інструмент з графічним інтерфейсом, який замінив би собою всі інші засоби управління, донині робочою конячкою "мережевий братії" залишається всім вже давно знайомий і звичний CLI (вона ж командна рядок). Тут я не буду розглядати невеликі рішення, начебто домашніх роутерів або комутаторів для SMB, оскільки вони спочатку не припускають широкий вибір підтримуваних технологій і протоколів, і простого web інтерфейсу там цілком достатньо (хоча який-ніякий CLI є і на них). Мова скоріше йде про комплексні розподілених мережах, що включають багаторівневу архітектуру, логічну й фізичну сегментацію, географічний розподіл, а також різнорідність представлених виробників устаткування. На мій погляд причина тому далеко не одна:
 
 
 
 - Більшість з уществует платформ управління, моніторингу, налагодження не дає тієї повноти функціональних можливостей, якими наділена командна рядок. Якісь системи більш просунуті, якісь менш, але в цілому необхідність зайти в CLI і щось вбити вручну залишається завжди;
 
 - Навіть у невеликих мережах можна зустріти цілий "зоопарк" з назв виробників заліза і їх моделей (особливо це часто зустрічається в компаніях, що працюють досить давно без виразної ІТ-політики управління). З іншого боку ми бачимо, що кожен виробник прагне обмежити кінцевих користувачів використанням саме свого обладнання, а тому ніякої мови про мультивендорної підтримці систем управління не йде;
 
 - Існуючі мережі передачі даних досягли того ступеня розвитку, коли навіть добре спроектовані і побудовані мережі рясніють такою кількістю різних протоколів і технологій (особливо з початку бурхливого будівництва центрів обробки даних і розвитку віртуалізації обчислювальних ресурсів), що знайти підходящий програмний продукт для відповідності всім задачам і вимогам вкрай складно;
 
 - Поступове зникнення чіткої грані між традиційною мережею передачі даних і обчислювальними середовищами в міру розвитку технологій віртуалізації. Прикладами можуть служити такі протоколи, як OpenFlow або VEPA. А оскільки розподіл зон відповідальності між "сетевиками" і "серверістамі", як правило, завжди цілком зрозумілі і визначені, не зовсім ясно для кого писати і як позиціонувати кінцевий продукт;
 
 - Як централізувати управління різними функціональними сегментами мережі — залишається питанням відкритим: бездротова мережа керується через один додаток, політики безпеки і нині вкрай популярний BYOD реалізуються через інше, оркестрації середовища Цода через третю…
 
Подібних аргументів можна знайти ще багато, але всі вони будуть так чи інакше зводиться до вищеописаних. Як можна реалізувати через одне вікно функції конфігурації, моніторингу, управління, пошуку та усунення проблем для дротової і бездротової інфраструктури, ресурсів ЦОД, віддалених майданчиків, мереж SDN і MPLS?
 
Компанія HP традиційно дотримувалася / дотримується принципу відкритих архітектур і використання стандартизованих рішень і протоколів, тому при виборі стратегії розвитку власної системи управління був узятий курс на централізацію управління всіма функціональними підсистемами мережевий середовища, забезпечуючи підтримку широкого спектру обладнання від різних виробників. Модель розвитку продукту передбачає гомогенну архітектуру, де функціонал не розпорошувати по декількох окремим один від одного продуктам, які вимагають самостійного адміністрування. Ми прагнемо об'єднати весь набір інструментів для управління різними мережами в єдиний, зручний і зрозумілий інтерфейс.
 
 
 
Дати вичерпну інформацію по даному продукту в рамках однієї статті справа практично нездійсненне, тому я б хотів почати з питань, пов'язаних насамперед із проектуванням і розгортанням системи управління, загальними питаннями по виборі моделі та архітектури, які дозволять не помилитися у стратегічному плані. Наступні статті обов'язково будуть присвячені глибокому розбору функціональних можливостях з прикладами практичного застосування.
 
Отже, що ж таке IMC? Це модульне програмне засіб, який реалізує функції FCAPS (Fault, Configuration, Accounting, Performance, Security), а відкинувши маркетингові абревіатури, попросту дозволяє централізовано керувати мережевою інфраструктурою, проводити пошук і налагодження проблем, здійснювати моніторинг різних сервісів і ресурсів, створювати і застосовувати різні політики, а також формувати різну звітну інформацію.
 
Короткий список підтримуваних функцій виглядає наступним чином:
 
• автоматичне виявлення і визначення мережевих пристроїв;
• автоматична побудова топологій L2 і L3, IRF, LLDP-MED, віртуальних мереж VMware і Hyper-V, а також їх кастомизация;
• графічне відображення і керування протоколами xSTP;
• управління аварійними подіями, їх кореляція;
• генерація статистики та звітної документації;
• генерація різних графіків і аналіз продуктивності мережі;
• управління списками доступу ACL;
• управління віртуальними мережами VLAN;
• управління конфігураціями і програмним забезпеченням мережевих пристроїв;
• моніторинг в реальному режимі часу;
• розподіл завдань за ролями;
• управління гостьовим доступом;
• наявність мобільного клієнта під Android та iOS
 
і багато, багато іншого.
 
На сьогоднішній день 7-я версія є найбільш актуальною. У ній був повністю перероблений призначений для користувача інтерфейс (тепер практично всі модулі використовують HTML5), додані безліч нових і корисних функцій в базову платформу, такі як підтримка MDC, VCF, ISSU, динамічна промальовування топологій, додані нові модулі, UI для мобільних пристроїв, стала більш зручною та зрозумілою схема ліцензування. Список змін дуже великий, тому краще почитати відповідний release note, які додається до файлу з дистрибутивом IMC.
 
Дистрибутив доступний для скачування і дозволяє використовувати додаток безкоштовно в режимі trial протягом 60 днів, після чого буде потрібно або ввести ліцензію, або перевстановити з нуля.
 
 Версії IMC
 
На даний момент доступно 6 версій для скачування:
 
• Standard
• Enterprise
• Basic
• Basic WLAN Manager
• Smart Connect
• Smart Connect with WSM Virtual Appliance
 
У більшості випадків вам підійдуть версії або Standard, або Enterprise, оскільки обидві вони, крім функцій базової платформи, пропонують серйозне розширення функціоналу шляхом установки додаткових модулів (про які я розповім трохи пізніше). Обидві версії включають в себе ліцензію на 50 пристроїв. Можна говорити про те, що одна IP адресу пристрою в IMC дорівнює однієї ліцензії. Якщо з комутаторами, маршрутизаторами, контролерами, файрволлами все більш чи менш зрозуміло, то як бути з кластерами з декількох пристроїв (наприклад, стек з комутаторів або маршрутизаторів з об'єднаними control plane). Оскільки IP адреса для управління один на весь стек, то і ліцензія буде використана одна.
 
Також обидві версії дозволяють використовувати ієрархічну модель установки, про яку я також згадаю далі, і нарощувати кількість пристроїв, керованих через IMC. При максимальних апаратних ресурсах сервера можна управляти до 15 000 пристроїв з однієї платформи.
 
У чому Enterprise краще Standard:
 
• Модуль NTA (Network Traffic Analyzer) і ліцензія на 5 пристроїв для нього йдуть разом з основною платформою IMC
• Доступний eAPI для написання власних скриптів і розробки власних розширень і кастомізації
• Може бути master'ом в ієрархічній моделі впровадження
 
Коротенько, Enterprise орієнтований на дуже великі моделі застосування у великих розподілених мережах; Standard відповідає вимоги підприємств середнього рівня.
 
 Перед установкою
 
Розрахувати мінімальні апаратні обчислювальні ресурси можна на основі наведених нижче таблиць:
 
     
        
           
           
     
          
     
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
Розрядність ОС
  
  
Кількість пристроїв
  
  
Кількість одиниць збору *
  
  
Кількість операторів онлайн
  
  
Кількість ядер
  CPU **
  
  
  
Обсяг пам'яті
  
  
Розмір пам'яті для
  Java
  
  
Обсяг жорсткого диска для установки
  
  
Обсяг жорсткого диска для експлуатації
  
  
32 біта
  
  
0 — 200
  
  
0 -5К
  
  
20
  
  
2
  
  
4 Гб
  
  
512 Мб
  
  
3 Гб
  
  
30 Гб
  
  
5К -50К
  
  
10
  
  
60 Гб
  
  
200 — 500
  
  
0 — 10К
  
  
30
  
  
4
  
  
6 Гб
  
  
1 Гб
  
  
3 Гб
  
  
50 Гб
  
  
10К — 100К
  
  
10
  
  
100 Гб
  
  
 
     
        
           
           
     
          
     
          
     
          
     
          
     
          
     
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
Розрядність ОС
  
  
Кількість пристроїв
  
  
Кількість одиниць збору *
  
  
  
Кількість операторів онлайн
  
  
Кількість ядер
  CPU **
  
  
  
Обсяг пам'яті
  
  
Розмір пам'яті для
  Java
  
  
Обсяг жорсткого диска для установки
  
  
Обсяг жорсткого диска для експлуатації
  
  
64 біта
  
  
0 — 200
  
  
0 -5К
  
  
20
  
  
2
  
  
4 Гб
  
  
2 Гб
  
  
3 Гб
  
  
30 Гб
  
  
5К -50К
  
  
10
  
  
60 Гб
  
  
200 — 500
  
  
0 — 10К
  
  
30
  
  
4
  
  
8 Гб
  
  
2 Гб
  
  
3 Гб
  
  
50 Гб
  
  
10К — 100К
  
  
10
  
  
100 Гб
  
  
1К — 2К
  
  
0 — 20К
  
  
30
  
  
6
  
  
12 Гб
  
  
4 Гб
  
  
4 Гб
  
  
60 Гб
  
  
20К-200К
  
  
10
  
  
200 Гб
  
  
2К — 5К
  
  
0 — 30К
  
  
40
  
  
8
  
  
24 Гб
  
  
8 Гб
  
  
5 Гб
  
  
80 Гб
  
  
30К — 300К
  
  
20
  
  
250 Гб
  
  
5К — 10К
  
  
0 — 40К
  
  
50
  
  
16
  
  
32 Гб
  
  
12 Гб
  
  
7 Гб
  
  
100 Гб
  
  
40К — 400К
  
  
20
  
  
300 Гб
  
  
10К — 15К
  
  
0 — 40К
  
  
50
  
  
24
  
  
64 Гб
  
  
16 Гб
  
  
10 Гб
  
  
200 Гб
  
  
40К — 400К
  
  
20
  
  
600 Гб
  
  
Одиниця збору * — являє собою збір будь-якої статистики за 5 хвилин. Наприклад, якщо моніторимо завантаження фізичного інтерфейсу вихідним трафіком раз в 1 хвилину, то вважається, що використовуємо 5 одиниць збору. Якщо ж будемо заміряти вихідний + вхідний трафік, тоді 10 одиниць збору.
 
CPU ** — під ядром CPU розуміються фізичні ядра, а не віртуальні.
 
Дані вимоги поширюються лише на саму платформу IMC без урахування додаткових модулів.
 
На даний момент підтримується інсталяція на наступних операційних системах:
 
• Windows® Server 2003 with Service Pack 2
• Windows® Server два тисячі три X64 with Service Pack 2 and KB942288
• Windows® Server 2003 R2 with Service Pack 2
• Windows® Server 2003 R2 X64 with Service Pack 2 with KB942288
• Windows® Server 2008 with Service Pack 2
• Windows® Server 2 008 X64 with Service Pack 2
• Windows® Server 2008 R2 with Service Pack 1
• Red Hat Enterprise Linux 5
• Red Hat Enterprise Linux 5 X64
• Red Hat Enterprise Linux 5.5
• Red Hat Enterprise Linux 5.5 X64
• Red Hat Enterprise Linux 6.1 X64
 
Також хотілося б привести список підтримуваних БД, в разі якщо знадобитися щось більш продуктивне і масштабується ніж та, що йде разом з платформою:
 
• Microsoft SQL Server 2005 Service Pack 3 (тільки Windows)
• Microsoft SQL Server 2008 Service Pack 3 (тільки Windows)
• Microsoft SQL Server 2008 Service Pack 3 (тільки 64-bit-Windows 64-bit)
• Microsoft SQL Server 2008 R2 Service Pack 1 (тільки Windows)
• Microsoft SQL Server 2008 R2 Service Pack 1 (тільки 64-bit-Windows)
• Oracle 11g Release 1 (тільки Linux)
• Oracle 11g Release 2 (тільки Linux)
• Oracle 11g Release 2 (тільки 64-bit-Linux)
• MySQL Enterprise Server 5.1 (Linux і Windows-до 1,000 пристроїв)
• MySQL Enterprise Server 5.5 (Linux і Windows- до 1,000 пристроїв)
 
Також варто відзначити, що HP рекомендує встановлювати IMC на окремий фізичний сервер. Втім, це не заважає розгорнути платформу на "виртуалке" з аналогічними апаратними характеристиками.
 
Для збільшення продуктивності введення / виводу є наступні рекомендації:
 
• Якщо кількість одиниць збору становить 100 000 — 200 000, рекомендується використання 2-х або більше жорстких диска і карта RAID з кешем 256 Мб або більше;
• Якщо кількість одиниць збору становить 200 000 — 300 000, рекомендується використання 2 або більше жорстких диска і карта RAID з кешем 512 Мб або більше;
• Якщо кількість одиниць збору становить 300 000 — 400 000, рекомендується використання 2 або більше жорстких диска і карта RAID з кешем 1 Гб або більше;
• HP рекомендує RAID 5-го рівня, які вимагає 3 або більше дисків. Якщо ж ви використовуєте більш 4-х дисків, рекомендується використовувати рівень RAID 0 + 1.
 
 Установка
 
Сам процес установки займає близько 2-3 годин залежно від складності обраного рішення. Тут я його наводити не буду, оскільки він вельми простий і подібний установці будь-якого додатку під Windows. Також він дуже докладно розписаний у мануалах, прикладених до самого інсталяційного образу платформи.
 
Я ж хотів би загострити увагу на концептуальних питаннях, які допоможуть вам не помилитися при проектуванні та впровадженні платформи.
 
 Централізоване або ієрархічне впровадження
 
 Централізоване рішення IMC є ідеальним рішенням для інфраструктур з невеликою кількістю керованих вузлів, кожен з яких розташовані в одному або декількох будівлях одного міста. В такому випадку IMC повинна бути встановлена ​​на виділений сервер, причому база даних може бути встановлена ​​разом з платформою, або ж на окремому сервері.
 
 
 
 
 
У яких випадках краще застосовувати централізоване управління:
 
• Коли кількість керованих за допомогою IMC вузлів менш 5000
• Коли більшість вузлів розташовані територіально в одному місці
• Коли кількість одиниць збору не перевищує 400000
• Коли кол-во операторів IMC, мають одночасний доступ, не перевищує 50.
 
 Иерархический спосіб впровадження відповідає вимогам управління у великих географічно розподілених мережах з великою кількістю керованих вузлів. Кожна з IMC платформ працює зі своєю вбудованою якої зовнішньої БД. Оператор, при зверненні до child IMC платформі, отримує повний доступ до функціонала. У той же час інформація по продуктивності і аварій реплицируется на parent IMC. Варто відзначити, що в ролі parent може виступати тільки версія IMC Enterprise.
 
 
 
У яких випадках краще застосовувати централізоване управління:
 
• Коли кількість керованих за допомогою IMC вузлів більше 5000
• Коли більшість вузлів географічно рознесені один від одного
• Коли оператори IMC знаходяться географічно в різних місцях
• Коли кількість одиниць збору перевищує 400000
• Коли кол-во операторів IMC, мають одночасний доступ, перевищує 50.
 
 Карта протоколів IMC
 
У разі, якщо на одній з ділянок мережі працюють міжмережеві екрани, корисно знати по яким протоколам і портам працює IMC.
 
 
 
 Варіанти забезпечення відмовостійкості
 
Платформа IMC включає в себе інструмент DBman, який дозволяє автоматично здійснювати резервне копіювання і відновлення бази даних, оскільки саме вона містить всю корисну інформацію про вашу мережі. Також даний інструмент відповідає за бекап інформації сервісних модулів розширення. Ви можете вибрати одну з двох моделей резервного копіювання: single system HA або dual system HA.
 
 Single system HA . Це найбільш проста реалізація відмовостійкості, коли БД копіюється або на локальний жорсткий диск, або на зовнішній сервер.
 
 
 
 Dual system HA. Дана модель є найбільш стійкою до різного роду неприємностей, оскільки ми маємо на ділі 2 платформи IMC, які мають однаковий набір функціональних модулів і які синхронізують свої бази даних, забезпечуючи безперервну роботу системи управління на випадок виходу з ладу основний копії. Якщо зупинка IMC загрожує вашій мережі значущими наслідками у наданні сервісу, саме ця модель забезпечення відмовостійкості повинна розглядатися в першу чергу.
 
 
 
Додаткову інформацію по платформі і модулям для нього, різні конфиг і адмін керівництва можна знайти на нашому сайті в відповідному розділі .
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.