Андреас Штайн
Якщо і можна охарактеризувати сьогоднішні мережі та додатки одним словом, то це "складність". Програми стали вкрай непрості. Вони взаємодіють через цілий ряд портів TCP / UDP, працюють в багатоланкових середовищах і все частіше переміщуються з розподілених на централізовані сервери. Управляти важливими діловими службами стає все важче. У такій ситуації допоможе лише глибоке знання відбуваються в мережі процесів.
Конвергенція трафіку даних і голосового трафіку на порядок підвищує складність корпоративної мережі. Раніше мережі передачі голосу, відео і даних були розділені, сьогодні ж всі ці види трафіку передаються по єдиній мережі. З появою IP-телефонії відділи ІТ намагаються оцінити, як IP-телефонія, передача графічних файлів і управління якістю послуг (Quality of Service, QoS) впливають на працюючі в мережі ділові додатки. Мережеве обладнання також стало складніше. ІТ-ме-неджер вже найближчі два роки планують впровадження 10 Gigabit Ethernet, MPLS, віртуальних приватних мереж (Virtual Private Network, VPN) і механізмів QoS. Однак, як і раніше, використовуються Gigabit Ethernet, ретрансляція кадрів і ATM. Неважливо, внаслідок яких причин виникає необхідність реструктуризації мережі: з-за потреби в пропускної здатності, неправомірного використання мережі або появи нових програм - без конкретних і детальних характеристик все це набагато більше нагадує мистецтво, ніж науку.
Специфічна проблема полягає в тому, що при зверненні до служби технічної підтримки більшість користувачів описують саме труднощі, пов'язані з виконанням повсякденних ділових операцій: «Електронна пошта повільно працює» або «Додаток CRM занадто довго реагує». Подібні приклади підтверджують необхідність системного підходу до аналізу роботи всіх додатків для розпізнавання та усунення проблем, планування змін продуктивності і мінімізації часу реакції.
Абсолютно необхідна інформація про функціонування TCP і UDP, а також про випадки, коли HTTP займає більшу частину пропускної здатності в порівнянні з DNS або FTP (див. врізання «Ідентифікація важливих індикаторів продуктивності»). Вона дає мережевим адміністраторам і розробникам додатків уявлення про те, як співробітники використовують мережу і наскільки мережеві послуги, наприклад запит до DNS, відповідають очікуванням.
Рішення для управління продуктивністю мережі та програм повинно володіти певними основними функціями. Дуже важливо, щоб воно призначалося для застосування в конвергентних мережах. При забезпеченні безпеки польотів жодна авіакомпанія не покладається виключно на власні системи спостереження, оскільки всі використовують один і той же повітряний простір. Цей принцип повинен застосовуватися і в разі голосових, відео-та інформаційних програм в одній і тій же мережі. Відповідальний за ІТ повинен мати можливість аналізу та огляду всіх додатків, а також збирання відповідних даних. Інші вимоги звучать таким чином:
ідентифікація і знаходження всіх додатків, будь то широко поширені, комплексні, розроблені усередині компанії або на базі Web, як, наприклад, SAP, Citrix, IP Multicast, HTTP і однорангові додатки;
виявлення всіх адрес відправників та одержувачів з числа користувачів додатків;
погляд на додатки відповідно до класів QoS (з розрізненням по кодової точці диференційованих послуг - Differentiated Services Code Point, DSCP);
виявлення додатків по сегменту, наприклад по з'єднанню Gigabit Ethernet, по віртуальному каналу (віртуальної локальної мережі) і одночасно відповідно з QoS (див. Малюнок i);
погляд у реальному часі і ретроспективні звіти при простій навігації між тимчасовими зрізами;
моніторинг голосових додатків і протоколів: протоколу передачі в реальному часі (Real Time Protocol, RTP) та протоколу ініціації сеансів (Session Initiation Protocol, SIP), а також власних протоколів таких виробників, як Avaya і Cisco;
надання різноманітних недорогих інструментальних опцій для охоплення різних частин мережі;
аналіз і зіставлення зібраних даних для виявлення найбільш часто або, навпаки, рідко застосовуються додатків, незалежно від інструментарію і топології;
подача сигналу про активне використання додатків: наприклад, при перевищенні 50-відсоткової завантаження пропускної здатності сегмента трафіком HTTP або рівня в 3% у випадку однорангових додатків, подібних Kazaa;
аналіз часу реакції додатка до і після впровадження голосових послуг з метою забезпечення роботи ділових додатків і дотримання угод про рівень сервісу (Service Level Agreement, SLA) для відділів при міграції на конвергентні послуги.
Єдине рішення включає в себе пасивний інструментарій для розпізнавання програми поряд з активними агентами і розвиненими засобами аналізу продуктивності. Тільки так забезпечуються найкращий можливий огляд і аналіз того, що відбувається на рівнях з другого по сьомий, і в підсумку можна скласти і конфігурувати внутрішні угоди про рівень сервісу з відділами та філіями, а також керувати ними. Критеріями стають надання даних по мережі відповідно до пріоритетів QoS, гарантована пропускна здатність і цільове використання корпоративної мережі. Крім того, зазначений підхід вимагає меншої кількості інструментів для керування додатками на всьому підприємстві. У результаті підвищується продуктивність роботи співробітників відділу ІТ, а вартість поточного ремонту і повна вартість володіння знижуються.
Ще одним позитивним результатом є широкий, але контрольований доступ до звітів. Таким чином, відділ ІТ може допомогти своїм колегам з бізнес-відділів вирішувати виникаючі проблеми, будь то взаємодія фінансових менеджерів при узгодженні бюджетних документів або ретельний аналіз роботи філіальної мережі керівниками підрозділів компанії.
Ідентифікація важливих індикаторів продуктивності
Рішення з управління продуктивністю мережі ведуть пошук специфічної інформації на всіх семи рівнях для визначення та аналізу поведінки мережі та програм:
при вимірюванні QoS використовується технологія другого рівня 802.1р або DSCP в заголовку пакета відповідно до стандартів RFC 2474 і 2475;
моніторинг віртуальних локальних мереж відбувається відповідно до 802.lq або з межкоммутаторним канальним протоколом (Inter-Switch Link Protocol, ISL) від Cisco;
широко відомі програми - HTTP, FTP і т. д. - ідентифікуються на основі стандартного номера порту;
складні додатки, наприклад SAP, часто задіяні кілька портів; рішення моніторингу здатне об'єднувати ці дані, зіставляючи порти і IP-адресу сервера для визначення загального використання;
однорангові додатки (Kazaa, Morpheus та інші рішення спільного використання файлів) часто задіяні інші порти крім порту HTTP 80; для розпізнавання однорангових додатків і порівняння схем трафіку даних рішення моніторингу можуть стежити за будь-якими сеансами TCP, якщо ті не відносяться до певного порту програми або широко відомому додатком.
Від повсякденному проблеми до пізнання
Для прийняття рішення про надання ділових послуг з мережі необхідна більш-менш детальна інформація. Ще раніше слід з'ясувати, якого роду має бути це рішення: введення нових ділових додатків піднімає питання, чи достатньо висока пропускна здатність самої корпоративної мережі і доступу по глобальній мережі до штаб-квартирі, в обчислювальному центрі і у віддалених філіях. Приклад: відповідальна за додатка група в банку постійно додає нові послуги без попереднього повідомлення про це іншим підрозділам ІТ. У відповідь на це відповідальний адміністратор встановлює зонд перед серверної фермою. У ході перевірок проводиться моніторинг всіх додатків і негайно розпізнаються нові.
Ще однією проблемою є визначення того, де знаходиться причина зниження часу реакції: у мережі або на сервері додатків. Так, наприклад, в одній великій організації охорони здоров'я, де для управління електронними медичними даними використовувалося вимогливе до ресурсів програмне забезпечення, час реакції становило більше 10 с. Потрібно було встановити, викликана така затримка сервером або додатком. Зонд сьомого рівня з вбудованим активним і пасивним аналізом часу реакції визначив причину затримки у додатку. Після цього організація змогла змусити розробника програми випустити латку для усунення проблеми.
Впровадження IP-телефонії веде до розробки внутрішніх SLA між відділом ІТ та виробничими підрозділами для забезпечення високоякісного надання голосових додатків і додатків обробки даних. Для дотримання SLA часто застосовується управління QoS, однак цього не завжди достатньо. Приміром, у фінансового програми незважаючи на управління QoS були помітні проблеми. Після установки зонда вдалося з'ясувати, що майже всіх програм було надано високий клас QoS, так що з'являлися проблеми з якістю. Це лише деякі приклади з практики, коли більш глибоке вивчення на всіх семи рівнях моделі OSI дозволяло складне зробити простим. LAN
Список літератури
Журнал LAN № серпня 2005