Забезпечення продуктивності додатків

Андреас Штайн

Якщо і можна охарактеризувати сьогоднішні мережі і програми одним словом, то це "складність". Програми стали вкрай непрості. Вони взаємодіють через цілий ряд портів 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 № 8 2005