Потреба в проектуванні IP-мереж 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Потреба в проектуванні IP-мереж



Якщо планування мережі не здійснювалося, то звичайне взаємосполучення з використанням TCP/IP може створити ряд проблем. Тому заздалегід необхідно вказати на ці проблеми і вияснити суть рішень, які слід зреалізувати для впровадження розв’язань TCP/IP. Наприклад, відсутність ефективного планування розподілу мережевих адрес може призвести до значних обмежень кількості станцій, які можна під’єднати до мережі. Відсутність централізованої координації веде до дублювання найменувань та адрес ресурсів, що не дозволить об’єднати ізольовані мережі. Неузгодженість адрес може заважати під’єднанню до Internet. Інші можливі проблеми включають відсутність трансляції імен ресурсів в їх адреси, оскільки відсутнє сполучення зі серверами імен тощо. Окремі проблеми, які виникли внаслідок неправильного спроектованої або неспланованої мережі, можна просто виправити, але деякі вимагають значного часу і зусиль для корекції. Важко здійснити, наприклад, переконфігурування вручну декількоїх сотень чи тисяч станцій в мережі, якщо схема адресації не відповідає потребам організації.

Коли розглядаються завдання проектування нової мережі або можливості під’єднання наявної мережі, то виникають окремі важливі питання, які необхідно розв’язати. Наприклад, як розподілити адреси мережевих ресурсів, як змінити наявні адреси, чи вибрати статичний, чи динамічний раутінг, як сконфігурувати сервер імен і як захистити мережу. В той сам час слід вирішити питання надійності, доступності і резервування, а також питання адміністрування та управління мережею.

Проектування IP-мережі

Внаслідок простоти та гнучкості IP, мережі можуть бути з’єднані між собою невпорядкованим чином. Це поширений спосіб сполучення мереж і вони можуть добре працювати. Якщо масштаб мереж невеликий. Проблеми виникають тоді, коли необхідно внести зміни, а документація відсутня. IP-мережа, яка не була систематично спроектована, неодмінно створює проблеми від початку стдії впровадження. Коли модернізується чинна мережа, то звичайно наявні інші чинні мережі. Які необхідно під’єднати.Впровадження нової технології без вивчення обмежень наявної мережі також може вести до появи непередбачених проблем. Тому проектування мережі слід здійснювати перед будь-яким впровадженням. Проект мережі повинен постійно переглядатися, коли протягом певного часу змінюються вимоги. Добрий проект включає детальну документацію мережі, потрібну для наступних посилань. Добле спроектовані мероежі прості для впровадження і створюють небагато несподіванок.

Методика проектування. Рекомендованою методикою проектування IP-мереж є підхід “зверху вниз”. Ця технологія слідує стеку протоколі TCP/IP. Як видно з рис., зверху стеку розташований рівень застосувань, тому він єпершим рівнем, який розглядається при проектуванні IP-мережі. Наступні два рівні – це Транспорнтий і Мережевий, а Канальний рівень є останнім.

Проектування застосувань визначається потребами організації. Правила діяльності організації, потоки процесів, вимоги безпеки і очікувані результати перетворюють у специфкації застосувань. Ці вимоги не тільки впливають на проектування застосувань, але суттєво відчутні на всіх нижчих рівнях.

Як тільки вимоги до Рівня застосувань визначені, то з них слідують вимоги до нижчих рівнів. Наприклад, якщо Рівень застосувань містить програму, яка вимагає двосекундного часу реакції на будь-яку мережеву транзакцію, то у проекті IP-мережі слід взяти це до уваги і вважати оптимізацію характеристик мережі найвищим пріоритетом. Канальний рівень повинен бути спроектований таким чином, щоб ці вимоги могли бути дотримані. При цьому використання плоскої моделі мережі з сотнями станцій, базованих на Windows, не є ідеальним вирішенням. Коли проектування IP-мережі завершене у погодженні з Рівнем застосувань, розпочинається її впровадження.

Проектування мережевої інфраструктури відіграє важливу роль і має визначальний вплив на загальний проект. Добрим прикладом є модульність і масштабованість всієї мережі. Нижче наведені основні аспекти проектування IP-мережі.

Загальний погляд на проектування.

Масштабованість. Добре спроектована IP-мережа масштабується, тобто може зростати при збільшенні вимог до неї. Під’єднання нових станцій, серверів або мереж не повинне вимагати повного перепроектування мережевої топології. Зміни топології можуть з’являтися внаслідок пристосування до зросту вимог організації.

Вікриті стандарти. Цілий проект і компоненти, з якиїх складається мережа, повинні базуватися на відкритих стандартах. Відкриті стандарт гарантують гнучкість, необхідну для сполучення різних пристроїв від різних виробників. Власні вирішення можуть бути придатні на короткий час, однак їх тривале застосування може обмежувати можливості внесення змін і може ускладнювати знаходження спільних технологій.

Доступність і надійність. Потреби організації безумовно вимагають певного рівня доступності та надійності мережі. Бізнес-система (наприклад, у торгівлі), яка гарантує час реакції для транзакцій у три секунди, не може працювати, якщо мережа не функціонує три зі семи днів у тижні. При проектуванні мережі слід враховувати середній час між відмовами мережі, а також середній час ремонту. Проектування логічної надлишковості мережі є так само важливе, як фізична надлишковість. Це важко здійснити під час стадії впровадження.

Модульність. Важливою концепцією є модульний підхід при побудові мережі. Модульність ділить складну систему на малі керовані блоки, що спрощує впровадження. Модульність також дозволяє ізолювати відмову у певній частині мережі, так що вона не спричиняє зупинку всієї мережі. Модульність спрощує розширення мережі. Наприклад, додавання нового мережевого сегменту або нових застосувань до мережі не вимагатиме переадресації всіх станцій.

Безпека. Безпека мережі організації є важливим аспектом проектування, зокрема тоді. Коли мережа має доступ до Internet. Аналіз ризиків і вживання заходів для їх зменшення на етапі проектування IP-мережі суттєве для повної впевненості в мережі. Розгляд питань безпеки на пізніх стадіях робить мережу доступною для атак, доки “дірки” в захисті не закриті, тому такий підхід може бути значно коштовніший. Хоч нові “дірки” в захисті можуть бути виявлені пізніше, основні проблеми захисту простіше впроваджувати на стадії проетування.

Управління мережею. Управління мережею не повинно розглядатися після побудови мережі. Воно важливе, бо забезпечує шляхи для моніторингу завантаженості мережі, для встановлення умов виконання операцій, для ізолювання відмов і конфігурування пристроїв при внесенні змін. Впровадження структур управління повинне бути інтегроване у процес проектування мережі від самого початку, бо спрби ввести структури управління у спроектовану і впроваджену мережу ведуть до виникнення небажаних проблем.

Характеристики. Існують два типи характеристик, які повинні бути враховані при проектуванні мережі. Це вимоги до перепускної здатності мережі і до часу відгуку (затримки). Масштабованість мережі також повинна враховувати вимоги до характеристик.

Економічні питання. Збалансування вимог організації до мережі і коштів, які можуть бути виділені для її створення є найбільш складним питанням при проектуванні мережі, яке вирішується шляхом компромісу.

Етапи проектування мережі

Нижче викладено суть структурованого підходу до проектування IP-мереж. Основні етапи процесу проектування показані на рис. 3.2.

 
 

Рис. 3.2. Етапи проектування мережі.

Визначення цілей мережі. Цей етап проектування вимагає проведення досліджень і може бути тривалим. При цьому слід розглянути такі питання:

q Хто є користувачами IP-мережі і якими є їх потреби?

q Які застосування повинні підтримуватися?

q Чи IP-мережа заміняє чинну комунікаційну систему?

q Які кроки міграції необхідно розглянути?

q Якими є конкретні вимоги, загалом сформульовані вище в п. “Загальний погляд на проектування”?

q Хто відповідає за управління мережею?

q Чи мережа повинна бути поділена на більш керовані сегменти?

q Яким є час інснування мережі?

q Яким є бюджет?

Збір інформації для проектування. Інформація, неоюхідна для побудови мережі, залежить від кожного індивідуального впровадження, однак основні види потрібної інформації можуть бути виведені з “Загального погляду на проектування”. Важливо зібрати цю інформацію і витратити дещо часу на її аналіздля зрозуміння вимог середовища і обмежень перед проектуванням нової 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 на Транспортному рівні, то воно мусить використовувати власне шифрування і забезпечити власні потреби захисту.

Розгляд платформ.

Важливим кроком до побудови застосувань є вибір платформ для застосувань. Слід відповісти на деякі основні питання:

q Чи робоча станція підтримує графіку, чи тільки текст?

q Чи робоча станція відповідає основним вимогам щодо характеристик – швидкість процесора, обсяг пам’яті, дисковий простір тощо?

q Чи робоча станція має можливості для під’єднання до мережі, які відповідають вимогам?

Відповіді на наступні запитання можуть бути потрібні, якщо опрацьовуються застосування для робот під стеком TCP/IP:

q Чи робоча станція підтримує потрібну карту мережевого інтерфейсу? Мультимедійні застосування можуть потребувати використання мережі ATM, однак не всі робочі станції підтримують мережеві карти ATM.

q Чи ця карта відповідає застосованій кабельній системі? Сучасні мережеві карти мають порт для під’єднання до кабельної системи UTP, однак може бути потрібне під’єднання до багатомодового оптичного кабеля.

q Чи мережева карта оснащена потрібним драйвером?

q Чи операційна система станції підтрмує TCP/IP? Існують різні варіанти впроваджень TCP/IP. Добрим прикладом є Classical IP (CIP) та емуляція LAN (LANE) при використанні мережі ATM. Певні операційні системи можуть підтримувати тільки CIP.

q Чи стек TCP/IP підтримує підмережі? Не всі системи підримують підмережі, особливо старі системи.

q Чи операційна система підтримує потрібні API? Поширений спосіб побудови застосувань в TCP/IP полягає у використанні програмування гнізд (sockets), однак стек TCP/IP на робочій станції може не повністю підтримувати це програмування. Це особливо небезпечно в мережах з різними типами робочих станцій, які оснащені різними операційними системами.

q Чи операційна система підтримує декілька маршрутів за замовчуванням (default routes)? Деякі операційні системи (наприклад, Windows 95) не підтримують декількох маршрутів за замовчуванням. Це може бути серйозним пунктом відмови для деяких цільових застосувань.

q Чи операційна система підтримує багато визначень DNS? Якщо клієнти здатні мати тільки одне визначення DNS, то потрібні опції повинні бути вбудовані в сервер DNS. З другого боку, коли клієнти здатні підтримувати багато DNS, то застосування мусить підтримуватися API, які забезпечують таку можливість.

q Чи операційна система підтримує багатоадресні пересилання? Це може бути потрібне для доручення відео до користувачів, що дозволяє ощадно використовувати смугу мережі. Однак не всі клієнти підтримують багатоадресні пересилання.

q Чи операційна система підтримує новітні властивості, такі як протокол резервування ресурсів (Resource Reservation Protocol – RSVP)?



Поделиться:


Последнее изменение этой страницы: 2016-08-01; просмотров: 292; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.223.119.17 (0.032 с.)