Обмеження пропускної спроможності (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 віртуальних мережних контролери в одній групі портів, то для кожного з них ці настройки застосовуються незалежно.
Для розподілених віртуальних комутаторів можливе обмеження як вихідного, так і вхідного трафіку.
2.4.3. NIC Teaming. Угруповання мережевих контролерів
Якщо зайти в налаштування вКоммутатора або групи портів, то останній закладкою ми побачимо «NIC Teaming», угруповання контролерів. Вона нам буде потрібно в тому випадку, якщо до вКоммутатору у нас підключений більш ніж один фізкабінет ний мережевий контролер сервера (vmnic).
А навіщо ми можемо захотіти, щоб до одного вКоммутатору були підключені декілька vmnic? Відповідь проста: для відмовостійкості в першу чергу і для підвищення пропускної здатності мережі - в другу.
Зверніть вніманіе.Еслі ми підключаємо до одного віртуального комутатора, стандартному або роздільного, кілька фізичних мережевих контролерів, то вони повинні бути з одного домену широкомовної розсилки. VMware не рекомендує підключати до одного вКоммутатору мережеві карти, підключені в різні фізичні мережі або різні VLAN: комутатори віртуальні обробляють тільки кадри Ethernet (другий рівень моделі OSI) і не можуть здійснювати маршрутизацію.
Якщо у вКоммутатора тільки один фізичний мережевий контролер, то сам цей контролер, його порт в фізичному комутаторі і фізичний комутатор цілком є єдиною точкою відмови. Тому для доступу в мережу критичних ВМ більш ніж правильно використовувати два або більше vmnic, підключених в різні фізичні комутатори.
Але тут постає питання політики їх використання. Ми можемо використовувати конфігурацію, що дає лише відмовостійкість - коли працює тільки один vmnic, а решта чекають його виходу з ладу, щоб підмінити його. Або ми можемо задіяти одразу кілька мережевих контролерів сервера, тим чи іншим чином балансуючи між ними навантаження.
Погляньмо на вікно налаштувань - рис. 2.32.
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.
Мал. 2.32. Вікно налаштувань угруповання контролерів - NIC Teaming
Network Failover Detection. Яким чином ESX (i) буде визначати, що фізичний мережевий контролер непрацездатний? Варіантів два:
Q Link Status Only - коли критерієм служить лише наявність линка, сигналу. Подібний режим дозволить виявити такі проблеми, як вихід з ладу самого vmnic, відключений мережевий кабель, знеструмлений физиче ський комутатор.
Такий підхід не допоможе визначити збій мережі в разі неправильної настройки порту, наприклад внесення його в неправильний VLAN і т. П. Також
він не допоможе в разі, якщо обрив мережі стався десь за фізичним комутатором;
Q Beacon Probing - ця функція потрібна тільки тоді, коли у вКоммутатора
Мал. 2.33. Приклад конфігурації мережі,
при якій має сенс використовувати 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 - балансування за номером порту.
Q Route based on ip hash - балансування по хешу (контрольної сумі) IP.
Також цей метод балансування вимагає налаштованої угруповання портів (відомої як link aggregation, Ether-Channel, Ethernet trunk, port channel, Multi-Link Trunking) на фізичному комутаторі, до якого підключений
У зворотний бік - якщо ви хочете налаштувати угруповання портів між фізичним і віртуальним комутаторами, то ви налаштовуєте її на фізичному; а на віртуальному ставите балансування по хешу IP для потрібних груп портів - і все.
Останній нюанс: якщо у вас один комутатор віртуальний підключений до декількох фізичних (з міркувань відмовостійкості), то далеко не з будь-якими фізичними комутаторами вийде використовувати цей тип балансування навантаження в такій конфігурації.
ESX (i) не підтримує автоматичної настройки угруповання портів за допомогою Link Aggregation Control Protocol (LACP).
Link Aggregation (Etherchannel) на фізичному комутаторі повинен бути налаштований, тільки якщо на віртуальному комутаторі використовується балансування навантаження по IP;
Q Route based on physical NIC load - цей метод балансування навантаження
доступний тільки для розподілених комутаторів і лише починаючи з ESX (i) версії 4.1. Суть даного механізму нагадує роботу першого варіанту балансування - по Port ID. Однак є і суттєві відмінності. По-перше, при прийнятті рішення, через який pNIC випускати чергову «сесію», вибір здійснюється в залежності від навантаження на цей pNIC, а не випадковим чином. По-друге, вибір повторюється кожні 30 секунд (в той час як у всіх інших варіантах одного разу здійснений ний вибір не змінюється до виключення ВМ).
Якщо не підходять і Route based on ip hash. і Route based on physical NIC
load. використовуйте Route based on the originating port ID.
Більш ефективну балансування навантаження рекомендується ставити лише для тієї групи портів, для якої вона необхідна, - з метою звести до мінімуму накладні витрати у вигляді навантаження на CPU сервера.
Для розподілених віртуальних комутаторів все так же, з поправкою на абстрактність каналів в зовнішню мережу, для яких виконується ця настройка.
2.4.4. Cisco Discovery Protocol, CDP
CDP - протокол від Cisco, що дозволяє виявляти і отримувати інформа цію про мережевих пристроях. ESX (i) 4 підтримує цей протокол.
Щоб змінити налаштування CDP для стандартних вКоммутаторов, вам знадобиться командний рядок. команда
esxcfg-vswitch -b
покаже поточну настройку CDP для вКоммутатора
esxcfg-vswitch -B
допоможе змінити значення настройки CDP для вКоммутатора
Q Down - CDP не використовується;
Q Listen - ESX отримує і відображає інформацію про комутатори Cisco, до яких підключений. На комутатори інформація про вКоммутаторах не надсилається;
Q Advertise - ESX відправляє інформацію про вКоммутаторах назовні, але не приймає і не відображає інформацію про фізичних комутаторах;
Q Both - ESX і виявляє підключення фізичні комутатори, і відправляє на них інформацію про комутатори віртуальних.
від vSwitch (рис. 2.34).
Для розподілених комутаторів ця настройка виконується з графічного інтерфейсу.