Етапи проектування мережі
Нижче викладено суть структурованого підходу до проектування IP-мереж. Основні етапи процесу проектування показані на рис. 3.2.
Р
ис.
3.2. Етапи проектування мережі.
Визначення цілей мережі. Цей етап проектування вимагає проведення досліджень і може бути тривалим. При цьому слід розглянути такі питання:
Хто є користувачами IP-мережі і якими є їх потреби?
Які застосування повинні підтримуватися?
Чи IP-мережа заміняє чинну комунікаційну систему?
Які кроки міграції необхідно розглянути?
Якими є конкретні вимоги, загалом сформульовані вище в п. “Загальний погляд на проектування”?
Хто відповідає за управління мережею?
Чи мережа повинна бути поділена на більш керовані сегменти?
Яким є час інснування мережі?
Яким є бюджет?
Збір інформації для проектування. Інформація, неоюхідна для побудови мережі, залежить від кожного індивідуального впровадження, однак основні види потрібної інформації можуть бути виведені з “Загального погляду на проектування”. Важливо зібрати цю інформацію і витратити дещо часу на її аналіздля зрозуміння вимог середовища і обмежень перед проектуванням нової IP-мережі.
Формування пропозицій або специфікацій. Після збору інформації та визначення цілей мережі можна сформулювати пропозиції, які потім можуть бути оптимізовані. Міркування щодо проекту можуть надавати перевагу одній цілі за рахунок інших. Наприклад, мережа може бути оптимізована за характеристиками, за стійкістю до відмов, за захищеністю. Коли пріоритети для проектування визначені, можна створювати і документувати проект.
Огляд. Останнім етапом процесу проектування є огляд проекту перед впровадженням. На цьому етапі проект може бути модифікований, перш ніж здійснено інвестиції в інфраструктуру або в роботи з впровадження. Коли цей етап завершено, переходять до впровадження.
Розгляд застосувань
Як вказано вище, найвищим рівнем TCP/IP є Рівень застосувань. Елементи, які містяться на цьому рівні, визначаються потребами організації і ці компоненти повинні розглядатися як дуже важливі при початковому розгляді проекту в методиці проектування “зверху вниз”. Існує цілий ряд питань, які слід розглянути, при чому окремі з них є спільними для всіх застосувань, тоді як інші стосуються тільки до підмножини застосувань. Ці питання повинні бути визначені та опрацьовані.
Вимоги до ширини смуги. Різні застосування потребують різного обсягу смуги мережі. Очевидно, що застосування, які повинна підтримувати мережа, визначають тип мережі, яка буде остаточно спроектована. Не слід проектувати мережу без розгляду того, які застосування потрібні негайно, а які будуть потрібні в майбутньому.
Вимоги до характеристик. Слід розглянути вимоги до характеристик мережі від її користувачів. Користувачі мережі можуть допускати більший час відгуку від HTTP- або FTP-застосувань, але можуть не сприймати змін затримок (jitter) при пересиланні голосу через IP (VoIP), оскільки це викликає спотворення звуку. Також слід враховувати величину затримки при пересиланні трафіку. Великі затримки неприйнятні для застосувань, які оперують потоками даних, таких, як відео через IP. Правильність, з якою мережа здатна забезпечити дані для застосувань, також відноситься до проеткування мережі. Різна інфраструктура забезпечує різні рівні правильності для мережі.
Необхідні протоколи. Рівень застосувань TCP/IP підтрмує постійно зростаючу кількість протоколів. Основним при виборі протоколу для застосувань є те, чи застосування використовує TCP, чи UDP. TCP здійснює послуги віртуальних кіл, тоді як UDP – послуги данограм. UDP швидше доручає мережевий відгук власлідок того, що відсутнє службове навантаження від заголовку TCP, однак він не має надійності TCP, властивостей управління потоком і корекції помилок.
Якість послуг і тип послуг. Якість послуг (Quality of Service – QoS) і тип послуг (Type of Service – ToS) з’являються з одної причини – певні дані користувачів “важливіші” від інших і повинні бути обслужені у першу чергу. Вимоги до QoS і ToS включені в застосування і мають вплив на проектування мережі. Пристрої для сполучення, такі як раутери і комутатори, повинні мати можливість першочергового доручення інформації для підтримки вимог застосування.
Окремі застосування, такі як VoIP або системи впорядкування (сортування)інформації повинні працювати в режимі реального часу. Для них мережа повинна гарантувати рівень послуги. Застосування реального часу можуть потребувати впровадження власного управління потоками та виправлення помилок, якщо вони використовують UDP як транспортний протокол. Вимоги застосувань реального часу можуть також мати вплив на впровадження мережевої інфраструктури. Нариклад, мережа ATM може повністю задовільнити ці вимоги, тоді як мережа Ethernet зі спільним використанням середовища (протокол CSMA/CD) не може їх задовільнити.
Чутливість до втрат пакетів і затримок. Чутливість застосувань до втрат пакетів і затримок може мати драматичний вплив на користувача. Мережа повинна забезпечувати надійне доручення пакетів для таких застосувань. Наприклад, застосування реального часу з малою буферизацією не допускає затримок в дорученні пакетів, але поодинокі пакети втрачаються. VoIP є одним з прикладів таких застосувань,на відміну від перегляду Web.
Багатоадресне пересилання. Доказано, що багатоадресне пересилання (multicastang) – це добрий засіб для ощадності ширини смуги мережі, якщо вона правильно впроваджена. Впровадження багатоадресності залучає до тісної співпраці всі пристрої для сполучення, такі як раутери та комутатори, застосування, клієнтські операційні системи і сервери. Багатоадресне пересилання не може працювати, якщо кожна з цих підсистем не буде дотрмуватися вимог або якщо вони мають жорсткі обмеження.
Оснащення дорученнями. Наявність протоколів застосувань, які здійснюють доручення (proxyed), має вплив на вимоги до ширини смуги і на безпеку мережі. Так, застосування HTTP можуть бути просто керовані, коли для безпеки зінстальована “пожежна стінка” (firewall), бо послуги за дорученням (proxy) можуть бути розташовані поза пожежною стінкою в “демілітаризованій зоні” для обслуговування трафіку HTTP через пожежну стінку до застосувань. Однак для застосувань, базованих на протоколі TELNET, це не так просто. Протокол TELNET не підтрмує послуг за дорученням для свого трафіку. Тому або пожежна стінка повинна залишатися відкритою для цього порта, а застосування повинні використовувати сервер SOCK, або застосування не зможуть комунікуватися через пожежну стінку.
Потреба у директоріях. Різні застосування вимагають послуг директорій в IP-мережі. Послуги директорій включають DNS (Domain Name Service – послуга доменних імен), NIS, LDAP, X.500, DCE (Distributed Computing Environment – середовище розподілених обчислень) і, можливо, інші. Вибір послуг директорій залежить від підтримки застосувань цими послугами. Наприклад, застосуванням, базованим на стандарті ITU X.500, мало відповідають мережі, яка мають тільки сервери DNS. Певні застосування, базовані на протоколах PING та TFTP, не вимагають послуг директорій для свого функціонуванняч, хоч без цього складнощі з їх вживанням можуть значно зрости. Інші застосування безумовно вимагають послуг директорій, наприклад, електронна пошта, базована на протоколі SMTP.
Розподілені застосування можуть вимагати певного рівня послуг від IP-мережі. Ці послуги повинні поставлятися мережею, тому вони мусять бути враховані при її проектуванні. Наприклад, Distributed Computing Environment – середовище розподілених обчислень забезпечує платформу для побудови і використання розподілених застосувань, пов’язаних з такими послугами, як послуга директорії комірок (Cell Directory Service – CDS), послуга глобальної директорії (Global Direcriry Service – GDS), послуга захисту ( Security Service), DCE Threads, послуга розподілу часу (Distributed Time Service – DTS) і послуга розподілених файлів (Distributed File Service – DFS). Ці послуги роблять доступними через мережу, тобто колективними, і вони забезпечують основу захищеного ядра для середовища DCE.
Масштабованість. Застосування, які вимагають масштабованості, повинні мати мережу, здатну задовільнити їх майбутні потреби, або придатну до модернізації. Якщо застосування спроектовані модульно, то мережа також повинна бути модульною.
Безпека. Безпека застосувань забезпечується протоколами, розташованими нижче, або самими застосуваннями. Наприклад, якщо застосування вживає протокол UDP на Транспортному рівні, то воно мусить використовувати власне шифрування і забезпечити власні потреби захисту.