Обмеження пропускної здатності (Traffic Shaping)

Для вКоммутатора цілком або для якоїсь однієї групи портів у нас є можливість обмежити пропускну здатність його портів

Зверніть увагу на те, що обмеження не піддається трафік, що залишається тільки на віртуальному комутаторі Якщо віртуальні машини працюють на одному сервері і підключені до одного вКоммутатору, то трафік між ними не виходить за межі даного вКоммутатора (за винятком випадку, коли ці ВМ у різних VLAN) У такому разі обмеження пропускної здатності каналу на трафік між цими двома віртуальними машинами поширюватися не будуть

Зайшовши у вікно налаштувань Traffic shaping (Configuration Network Properties

для потрібного вКоммутатора ⇒ Edit для самого вКоммутатора або однієї групи

портів), ми побачимо три налаштування:

Q  Average Bandwidth – Стільки кілобіт на секунду в середньому може проходити через кожен порт цього комутатора / групи портів Фактично – середня, звичайна швидкість мережі

Q  Peak Bandwidth – Стільки кілобіт на секунду може проходити через порт, якщо смуга пропускання зайнята не повністю Фактично – максималь ная швидкість мережі Це значення завжди повинно бути не менше Average Bandwidth

Q  Burst Size – Якщо ВМ намагається передавати дані зі швидкістю більшою, ніж average bandwidth, то перевищують це обмеження пакети поміщаються в спеціальний буфер, розмір його якраз і задається цією налаштуванням Коли буфер заповниться, то дані з нього будуть передані зі швидкістю Peak Bandwidth (якщо у комутатора є вільна смуга пропускання)

Зверніть увагу: ці налаштування застосовуються до кожного віртуального мережевого контроллера (насправді – до порту вКоммутатора, куди ті підключені) Таким чином, якщо ВМ має 2 віртуальних мережевих контролера в одній групі портів, то для кожного з них ці налаштування застосовуються незалежно

Для розподілених віртуальних комутаторів можливе обмеження як вихідного, так і вхідного трафіку

Якщо зайти в налаштування вКоммутатора або групи портів, то останньою закладкою ми побачимо «NIC Teaming», угруповання контролерів Вона нам буде потрібно в тому випадку, якщо до вКоммутатору у нас підключений більш ніж один физи чний мережевий контролер сервера (vmnic)

А навіщо ми можемо захотіти, щоб до одного вКоммутатору були підключені декілька vmnic Відповідь проста: для відмовостійкості в першу чергу і для підвищення пропускної здатності мережі – в другу

Зверніть увагу Якщо ми підключаємо до одного віртуального комутатора, стандартному або розподіленому, кілька фізичних мережевих контролерів, то вони повинні бути з одного домену широкомовного розсилання VMware не рекомендує підключати до одного вКоммутатору мережеві карти, підключені в різні фізичні мережі або різні VLAN: комутатори віртуальні обробляють тільки кадри Ethernet (другий рівень моделі OSI) і не можуть здійснювати маршрутизацію

Якщо у вКоммутатора тільки один фізичний мережевий контролер, то сам цей контролер, його порт у фізичному комутаторі і фізичний комутатор цілком є ​​єдиною точкою відмови Тому для доступу в мережу критичних ВМ більш ніж правильно використовувати два або більше vmnic, підключених в різні фізичні комутатори

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

Погляньмо на вікно налаштувань – рис 232

Failover Order Саме нижнє поле дозволяє вибрати використовувані (Active Adapters), запасні (Standby Adapters) і невикористовувані (Unused Adapters) фізичні мережеві контролери з підключених до цього вКоммутатору Якщо ви хочете, щоб якісь vmnic стали резервними і не були задіяні в нормальному режимі роботи, тоді переміщайте їх у групу Standby Всі (або декілька) залишайте в Active, Якщо хочете балансування навантаження Ну а Unused зазвичай потрібна на рівні груп портів – коли у вКоммутатора багато каналів у зовнішню мережу, але трафік саме конкретної групи портів ви через якісь пускати не хочете ні за яких обставин

Failback Ця настройка безпосередньо відноситься до Failover Order Якщо у вас vmnic3 Active, А vmnic2 Standby, То в разі виходу з ладу vmnic3 його підмінить vmnic2 А що робити, коли vmnic3 повернеться в лад От якщо Failback виставлений в Yes, то vmnic2 знову стане Standby, А vmnic3 – знову Active Відповідно, якщо Failback = No, то навіть коли vmnic3 знову стане працездатним, він стане Standby Яким чином ESX (i) розуміє, що vmnic непрацездатний Див пункт Network Failover Detection

Notify Switches Ця настройка включає (Yes) або вимикає (No) оповіщення фізичних комутаторів про зміни в MAC-адресах ВМ на ESX (i) Коли ви створюєте нову ВМ і підключаєте її до групи портів (як варіант – Додаєте в ВМ ще один віртуальний мережевий контролер) або коли трафік ВМ починає йти через інший vmnic через збій раніше задіяного – тоді ESX (i) відправить пакет rarp з оповіщенням виду «Такий-то MAC-адресу тепер доступний на цьому порту»

Рис 232 Вікно настройок угруповання контролерів – NIC Teaming

Рекомендується виставляти в Yes для того, щоб фізичні комутатори максимально швидко дізнавалися про те, на якому їх порту доступний MAC-адресу ВМ Однак деякі програми зажадають виключення цієї функції, наприклад кластер Microsoft NLB

Network Failover Detection Яким чином ESX (i) визначатиме, що фізичний мережевий контролер непрацездатний Варіантів два:

Q  Link Status Only – Коли критерієм служить лише наявність линка, сигналу Подібний режим дозволить виявити такі проблеми, як вихід з ладу самого vmnic, відключений мережевий кабель, знеструмлений физиче ський комутатор

Такий підхід не допоможе визначити збій мережі в разі неправильної настройки порту, наприклад внесення його до неправильний VLAN і т п Також

він не допоможе у випадку, якщо обрив мережі стався десь за фізичним комутатором

Q  Beacon Probing – Ця функція потрібна тільки тоді, коли у вКоммутатора

кілька зовнішніх підключень (рис 233) до різним фізичним комутаторів При цьому налаштуванні, крім перевірки статусу підключення, віртуальний комутатор ще розсилає (з інтервалом близько 5-10 секунд) через кожен свій vmnic широкомовні пакети, містять MACадрес того мережевого інтерфейсу, через який вони пішли І очікується, що кожен такий пакет, посланий з одного vmnic, буде прийнятий на інших vmnic цього вКоммутатора Якщо цього не відбувається – значить десь з якихось причин мережа не працює

Рис 233 Приклад конфігурації мережі,

при якій має сенс використовувати Beacon Probing

У цьому прикладі пакети, послані через vmnic5, не дійдуть до клієнтів, підключених до «далеким» фізичним комутаторів Якщо для визначення відмов мережі використовується «Link status only» – то ESX (i) НЕ зможе визначити таку непрацездатність мережі А beaconing зможе – тому що широкомовні пакети від vmnic5 не будуть прийняті на vmnic3 і vmnic2

Але зверніть увагу: якщо beacon-пакети відправляються і не приймаються в конфігурації з двома vmnic на вКоммутаторе, то неможливо визначити, який з них не треба використовувати – адже з обох beacon-пакети йдуть і на обидва не приходять

Тоді вКоммутатор починає працювати в режимі «Shotgun», що тут можна перекласти як «двостволка», – починає відправляти весь трафік через обидва підключення, мовляв, через якийсь да дійде

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

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

Нарешті, сама цікава настройка

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

Варіант настройки Use explicit failover order вказує не використовувати балансування навантаження Використовується перший vmnic зі спискуActive – Див трохи вище описFailover Order А інші три варіанти настройки – це якраз вибір того, за яким принципом буде балансуватися навантаження Суть в чому – є трафік, і є кілька каналів назовні (vmnic #) Треба трафік поділити між каналами Три варіанти настройки відрізняються тим, яким чином буде ділитися трафік:

Q  Route based on the originating port ID – Балансування за номером порту

У кожної ВМ (у кожного віртуального мережевого контролера в ВМ) є порт в вКоммутаторе, до якого вона підключена При даному варіанті настройки балансування навантаження трафік буде ділитися по цих портам – весь трафік від одного порту вКоммутатора буде йти в якийсь один vmnic трафік з іншого порту – через інший vmnic і т д Вибір чергового vmnic здійснюється випадковим чином, не щодо його завантаження Даний метод балансування навантаження використовується за замовчуванням і є ється рекомендованим Рекомендованим він є тому, що дає какуюнікакую балансування навантаження, а накладні витрати на аналіз трафіку мінімальні Однак трафік від одного віртуального контролера не отримає смуги пропускання більше, ніж дає один фізичний інтерфейс, який виступає каналом в зовнішню мережу Непрямий висновок звідси – віртуальна машина з кількома віртуальними мережевими контролерами зможе задіяти кілька каналів в зовнішню мережу

Q  Route based on source MAC hash – Балансування по MAC-адресу источни-

ка У цьому випадку трафік ділиться на основі MAC-адреси джерела пакета Таким чином, вихідний трафік ділиться точно так само, як і у випадку балансування по портам На практиці метод практично не застосовується

Q  Route based on ip hash – Балансування по хешу (контрольній сумі) IP

Тут критерієм поділу трафіку вважається пара IP-джерела – IP одержувача Таким чином, трафік між однією ВМ і різними клієнтами, в тому числі за маршрутизатором, може виходити з різних vmnic Цей метод балансування навантаження є найефективнішим, проте він може викликати велике навантаження на процесори сервера, так як саме на них буде обчислюватися хеш IP-адрес для кожного пакета

Також цей метод балансування вимагає налаштованої угруповання портів (відомої як link aggregation, Ether-Channel, Ethernet trunk, port channel, Multi-Link Trunking) на фізичному комутаторі, до якого підключений

комутатор віртуальний Це викликано тим, що при цьому методі балансування навантаження MAC-адресу однієї ВМ може одночасно значитися на декількох vmnic, як наслідок – на декількох портах комутатора фізичного Що не є допустимим у штатному режимі роботи, без угруповання портів

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

Останній нюанс: якщо у вас один комутатор віртуальний підключений до декількох фізичним (з міркувань відмовостійкості), то далеко не з будь-якими фізичними комутаторами вийде використовувати цей тип балансування навантаження в такій конфігурації

ESX (i) не підтримує автоматичної настройки угруповання портів за допомогою Link Aggregation Control Protocol (LACP)

Link Aggregation (Etherchannel) на фізичному комутаторі повинен бути налаштований, тільки якщо на віртуальному комутаторі використовується балансування навантаження по IP

Q  Route based on physical NIC load – Цей метод балансування навантаження

доступний тільки для розподілених комутаторів і лише починаючи з ESX (i) версії 41 Суть даного механізму нагадує роботу першого варіанту балансування – по Port ID Однак є й значні відмінності По-перше, при прийнятті рішення, через який pNIC випускати чергову «сесію», вибір здійснюється залежно від навантаження на цей pNIC, а не випадковим чином По-друге, вибір повторюється кожні 30 секунд (у той час як у всіх інших варіантах одного разу здійснений ний вибір не змінюється до вимикання ВМ)

Резюме: рекомендованим у випадку є Route based on the physical NIC load – За сукупністю характеристик Він дає балансування навантаження з мінімальними накладними витратами (але використовувати цей метод балансування можливо тільки на розподілених комутаторах, і лише починаючи з версії 41) У випадку якщо ви твердо впевнені, що вам необхідна велика ефективність балансування, використовуйте Route based on ip hash Приклад такої ситуації – одна ВМ, генеруюча великий обсяг трафіку і працює з великою кількістю клієнтів Проте якщо немає можливості налаштувати etherchannel на фізичному комутаторі, то Route based on ip hash використовувати неможливо

Якщо не підходять і Route based on ip hash, І Route based on physical NIC

load, Використовуйте Route based on the originating port ID

Ефективнішу балансування навантаження рекомендується ставити лише для тієї групи портів, для якої вона необхідна, – з метою звести до мінімуму накладні витрати у вигляді навантаження на CPU сервера

Для розподілених віртуальних комутаторів все так же, з поправкою на абстрактність каналів в зовнішню мережу, для яких виконується ця настройка

CDP – протокол від Cisco, дозволяє виявляти і отримувати інформа цію про мережевих пристроях ESX (i) 4 підтримує цей протокол

Щоб змінити настройки CDP для стандартних вКоммутаторов, вам знадобиться командний рядок Команда

esxcfg-vswitch -b  &ltvSwitch&gt

покаже поточну настройку CDP для вКоммутатора

Команда

esxcfg-vswitch -B &ltmode&gt  &ltvSwitch&gt

допоможе змінити значення настройки CDP для вКоммутатора Доступні значення параметра :

Q  Down – CDP не використовується

Q  Listen – ESX отримує і відображає інформацію про комутатори Cisco, до яких підключений На комутатори інформація про вКоммутаторах не надсилається

Q  Advertise – ESX відправляє інформацію про вКоммутаторах назовні, але не приймає і не відображає інформацію про фізичних комутаторах

Q  Both – ESX і виявляє підключення фізичні комутатори, і відправляє на них інформацію про комутатори віртуальних

Коли CDP налаштований в listen або both, нам доступна інформація про коммутато рах Cisco Для перегляду пройдіть Configuration Networking ⇒ іконка праворуч

від vSwitch (рис 234)

Рис 234 Перегляд інформації від CDP

Різне

Для розподілених комутаторів ця настройка виконується з графічного інтерфейсу

Джерело: Міхєєв М О Адміністрування VMware vSphere 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*