ARUBA INSTANT WI-FI: ПРОСТІ, ПОТУЖНІ, ДОСТУПНІ
Перший і головний рада читачам в знаменитому фантастичному романі Hitchhiker's Guide to the Galaxy: «Ніколи не панікувати». Я часто звертаюся до нього в думках, коли говорю про якість обслуговування (QoS) в компанії: в очах з'являється тривога і всі згадують про призначене візит в поліклініку або батьківських зборах в школі, чому необхідно негайно покинути нараду.
Безумовно, така нервозність почасти обгрунтована.
необхідність QoS
Сучасні центри обробки даних відрізняються глибокої, розгалуженої зв'язком. Сервери, що становлять центр обробки даних, обмінюються один з одним даними багатьох видів:
- дані програми;
- реплікація;
- трафік кластера;
- трафік мережевого сховища (наприклад, SMB, iSCSI);
- трафік управління;
- дані архівації.
Завдання ще більше ускладнюється через віртуалізації. На сервері Hyper-V може знадобитися не менше п'яти здійснювати підключення до мережі! Врахуйте також надлишкові шляху, які можуть знадобитися для деяких типів трафіку, тому кілька з'єднань можуть об'єднуватися в групи. Окремі сполуки можуть знадобитися для сховищ при використанні таких технологій, як Fibre Channel. Все це може привести до досконалої плутанини. Як компаніям впорядкувати свою інфраструктуру?
Уявіть, що мережа - це шосе. Ви чуєте сирену за спиною. Автомобілі навколо намагаються звільнити шлях, але зробити це в годину пік складно, і машина швидкої допомоги не може проїхати. А якщо на шосе є спеціальна смуга для автомобілів аварійних служб, більшу частину часу ця смуга пустує. Автомобіліст в пробці з досадою думає, наскільки швидше можна було б доїхати додому, якщо дозволити іншим машинам використовувати цю смугу. Дорожнє відомство могло б додавати нові смуги до магістралі для боротьби з пробками, але таке рішення практично не реалізовується.
Мережа вашої компанії схожа на автомагістраль. Можливо, канал зв'язку є загальним для всього мережевого трафіку. У цьому випадку з'являється небезпека, що не вдасться своєчасно передати через мережу важливі дані в період високого навантаження. А може бути, ви виділили мережеві з'єднання для кожного типу трафіку, щоб при необхідності завжди надати смугу пропускання певних даних. Можливо, ви додаєте канали зв'язку, щоб забезпечити передачу всього трафіку.
Більшість компаній традиційно використовували другий варіант, але реалізація такого підходу утруднена з кількох причин.
- Центри обробки даних переходять від 1-гігабітних до 10-гігабітним мереж. Наявність більше двох 10-гігабітних з'єднань на один сервер - економічно невигідне рішення, тому виділення спеціальних з'єднань для кожного типу трафіку не має сенсу.
- У міру широкого впровадження віртуалізації все частіше застосовуються занадто щільні (blade) сервери. Але в цих серверах зазвичай є обмеження по числу адаптерів, що зменшує кількість з'єднань. Існують винятки, якщо в центрі обробки даних використовується об'єднана структура, яка дозволяє створювати для вузла віртуальні адаптери, забезпечуючи майже необмежену гнучкість в поділі трафіку (хоча в дійсності це всього лише своєрідний механізм QoS).
- Традиційно мережі будуються з великою надмірністю, щоб забезпечити доступність смуги пропускання. Через зрослої важливості і використання різних типів мережевого трафіку більшість компаній не здатне керувати такою надмірністю. Багато виділені мережеві з'єднання для певних типів трафіку або не використовуються, або використовуються дуже рідко.
Специфічні проблеми пов'язані з виртуализацией. Багато екземплярів операційних систем функціонують на одному апаратному пристрої і спільно задіють набір мережевих з'єднань. Використання окремих мережевих адаптерів для кожної віртуальної машини надзвичайно непрактично. Єдина некоректна віртуальна машина може використати усю вільну смугу пропускання, позбавивши ресурсів інші віртуальні машини. Тому необхідний механізм, який гарантує не тільки своєчасне виділення достатньої смуги пропускання для трафіку різних типів, але і справедливий розподіл ресурсів одного типу між різними віртуальними машинами, або клієнтами, які використовують віртуальну інфраструктуру.
Якщо у постачальника послуг розміщення багато клієнтів, то необхідно забезпечити кожному клієнту достатню кількість ресурсів. Також корисно мати різні рівні мережевих швидкостей, наприклад золотий, срібний і бронзовий.
На перший погляд, проблема вирішується простою заміною каналу зв'язку 1 Гбіт на 10 Гбіт - канал зв'язку з десятикратно збільшеною пропускною здатністю буде достатнім. Це відповідає збільшенню числа смуг на автостраді: на час гострота проблеми знижується, але які б ресурси не були виділені для робочого навантаження, в кінцевому підсумку їх виявиться мало і потрібно більше. Навіть 10-гигабитное з'єднання з часом виявляється повністю завантаженим, і проблема - для трафіку певних типів не виділяється достатньої смуги пропускання - знову стає актуальною.
QoS на основі програмного забезпечення
В конфігурації з максимальною пропускною здатністю робоче навантаження, на яку впливає політика, не може перевищувати виділену смугу пропускання. Це гарантує прогнозовану пропускну здатність мережі. Наприклад, трафік в 10-гігабітному мережевому каналі зв'язку можна розділити наступним чином:
- 1 Гбіт для управління;
- 1 Гбіт для динамічної міграції;
- 1 Гбіт для кластера або загального томи кластера CSV);
- 2 Гбіт для iSCSI;
- 5 Гбіт для віртуальних машин.
Метод максимальної смуги пропускання корисний, якщо необхідно платити за використану частину смуги пропускання в разі WAN-з'єднання між офісами. Тоді обмеження смуги пропускання - хороша ідея.
- 10 для управління;
- 20 для динамічної міграції;
- 20 для кластера або загального томи кластера CSV);
- 10 для iSCSI;
- 40 для віртуальних машин.
Зверніть увагу, що значення не мають розмірності; це просто відносні ваги.
Принцип політики мінімальної смуги пропускання наступний: за замовчуванням трафік будь-якого типу може використовувати всю доступну смугу пропускання мережі. Хоча вага трафіку віртуальних машин - 40, він може займати всю смугу пропускання мережі, якщо канал зв'язку не потрібен для передачі будь-якого іншого трафіку. За відсутності конкурентів робочі навантаження можуть використовувати будь-яку частку каналу зв'язку, до граничних можливостей мережевої структури. Відносні ваги враховуються тільки в разі конкуренції. В цьому випадку різним типам трафіку гарантується смуга пропускання в залежності від їх ваг: для трафіку динамічної міграції буде виділено 20%, а для трафіку віртуальних машин - 40%. Сума всіх ваг - 100. Мінімальну смугу пропускання для одного типу трафіку при наявності конкуренції можна знайти діленням відносного ваги цього типу трафіку на суму всіх ваг.
Крім того, можна використовувати сувору настройку мінімальної смуги пропускання, в якій типам трафіку призначаються абсолютні мінімальні значення смуги пропускання. Наприклад, трафіку управління виділяється 1 Гбіт, а трафіку віртуальних машин - 4 Гбіт. Однак такий підхід пов'язаний з труднощами адміністрування в порівнянні з відносними вагами. Необхідно виявляти обережність, щоб не завищити мінімальні значення, що виділяються робочим навантаженням. Крім того, призначення типу трафіку мінімального значення 1 Гбіт не гарантує, що він отримає 1 Гбіт. У більшості мереж є кілька комутаторів і шляхів. Типу трафіку можна гарантувати смугу пропускання 1 Гбіт всередині мережі локального сервера, але після того як трафік залишає сервер, показники залежать від іншого трафіку в мережі.
Існує ще одна проблема з використанням суворої настройки мінімальної смуги пропускання. Припустимо, що об'єднуються два 10-гігабітних мережевих адаптера; це забезпечує в справної середовищі пропускну здатність 20 Гбіт. Якщо чітко дотримуватися підходу, заснованого на мінімальній смузі пропускання, і задати значення 20 Гбіт, то неможливо забезпечити гарантію в разі відмови адаптера. Це суперечить самій ідеї об'єднання мережевих плат: безперебійно надавати послугу в разі аварії.
З цих причин строгий підхід на основі мінімальної смуги пропускання не рекомендується. Скрізь, де можливо, слід використовувати відносні ваги.
Апаратна технологія QoS
QoS при віртуалізації
Програмна QoS також доступна віртуальним машинам. Можливість поєднувати QoS з віртуальними машинами має вирішальне значення в багатьох середовищах, особливо для постачальників послуг або компаній з різними бізнес-підрозділами, спільно використовують інфраструктуру. Гарантія того, що клієнти отримують достатню кількість мережевих ресурсів, а різні рівні обслуговування надаються на основі пільгових тарифів для «золотого» мережевого з'єднання - величезна перевага. Віртуалізація забезпечує ці можливості для процесора, пам'яті і навіть сховищ даних, тому здатність надати їх для мережі довершує картину управління ресурсами.
Пам'ятайте, що можливості мінімальної смуги пропускання допускають відносне зважування або суворе призначення смуги пропускання. У випадку з віртуальними машинами використання мінімального відносного ваги ще більш важливо, так як віртуальні машини мобільні. Віртуальну машину можна переміщати між вузлами, тому спроби поставити строгий мінімум смуги пропускання не принесуть успіху, так як різні вузли мають різні віртуальні машини з власними параметрами. Якщо спробувати використовувати динамічну міграцію для переміщення віртуальної машини на інший вузол, на якому неможливо забезпечити настройку суворої мінімальної смуги пропускання, то динамічна міграція завершиться невдачею. Відносне зважування завжди спрацьовує, тому що смуга пропускання співвідноситься з робочим навантаженням сервера.
Важливо розуміти, що політики мінімальної смуги пропускання, що застосовуються до віртуальних машин, впливають тільки на трафік, що відправляється з віртуальної машини в фізичний канал зв'язку. Якщо розглядається трафік між машинами на одному вузлі, то політики мінімальної смуги пропускання незастосовні. Трафік між двома віртуальними машинами на одному вузлі ніколи не проходить через фізичний мережевий адаптер, але направляється всередині вузла віртуальним комутатором Hyper-V і тому не займає смуги пропускання мережі. Політики максимальної смуги пропускання застосовні до трафіку між двома віртуальними машинами на одному вузлі, як і до трафіку, що надходить з віртуальної машини в мережевий канал зв'язку. Причина відмінностей в тому, що деякі компанії стягують плату в залежності від використаних мережевих ресурсів. Якщо задана максимальна смуга пропускання, то клієнти не припускають платити за більшу, ніж встановлений для них максимум.
Зверніть увагу, що максимальна смуга пропускання застосовується тільки до вихідного трафіку з віртуальної машини; вхідний трафік не обмежений. Чому не обмежується вхідний трафік? Вхідний трафік вже присутній на вузлі, тому відмова від нього не принесе значної користі. Крім того, якщо трафік передається по протоколу TCP, не існує способу оповістити відправника, щоб той забарився або зупинив передачу.
В даний час тільки сувора смуга пропускання може бути налаштована для віртуальних машин з використанням графічного інтерфейсу Hyper-V Manager, як показано на екрані. Це викликає розчарування, так як оптимальний метод - використовувати не строгу мінімальну смугу пропускання, а щодо зважену мінімальну смугу пропускання.
