Віртуальні комутатори VMware - штука хороша. Однак немає межі досконалості, і в великих інфраструктурах вам можуть бути цікаві розподілені віртуальні комутатори - vNetwork Distributed Switch. або dvSwitch.
Зверніть увагу на те, що налаштування розподілених віртуальних ком-
мутаторов описуються в різних розділах:
Q в розділах 2.3.4 і 2.3.5 описані унікальні настройки dvSwitch;
Q в розділі 2.4 описані настройки, доступні і для стандартних, і для розподілених віртуальних комутаторів, це групи налаштувань «Security»,
«VLAN», «Traffic shaping» і «NIC Teaming».
2.3.1. Основа поняття «розподілений віртуальний комутатор VMware»
Ідея їх полягає в наступному: в разі використання стандартних вКоммутаторов у вас різні (нехай дуже часто і ідентично налаштовані) віртуальні комутатори на кожному сервері. Акцент я хочу зробити ось на чому: створити і підтримувати цю, нехай навіть ідентичну, конфігурацію доведеться вам. При необхідності, наприклад, створити ще одну групу портів для ще одного VLAN вам буде потрібно повторити цю просту дію на всіх серверах ESX (i).
А в разі створення розподіленого комутатора ви отримуєте один-єдиний жавного (логічно) комутатор, який існує одразу на всіх серверах ESX (i).
Ви налаштовуєте тільки цей, логічно єдиний комутатор. Нову групу портів з прикладу вище ви створите один раз, і вона з'явиться для всіх серверів ESX (i), що входять в розподілений комутатор.
ВМ, навіть при міграції з сервера на сервер, залишаються не тільки на тому ж комутаторі, але і навіть на тому ж порту розподіленого віртуального комутатора (це називають Network vMotion). Це дозволяє простіше налаштовувати політики безпеки, здійснювати моніторинг трафіку ВМ, прив'язуючись навіть до окремого порту вКоммутатора.
На відміну від стандартних віртуальних комутаторів VMware, distributed vSwitch підтримують Private VLAN і двосторонній traffic shaping (про те, що це таке, см. В розділах 2.4.2 і 2.4.4). У версії 4.1 в список унікальних можливостей розподілених комутаторів додалися такі функції, як:
Q Network IO Control - можливість гнучко налаштовувати мінімально і мак
симально доступні ресурси пропускної здатності для трафіку різних типів. Подробиці про NIOC см. В главі 6, присвяченої розподілений нию ресурсів;
Q Load Based Teaming - балансування навантаження між фізичними кон-
Троллер одного вКоммутатора в залежності від навантаження на кожен контролер.
Ще один плюс - розподілений вКоммутатор доступний в реалізаціях від VMware і від Cisco.
Варіант від Cisco, розподілений віртуальний комутатор Cisco Nexus 1000V, набувається незалежно від vSphere (але підійде не будь-яка ліцензія vSphere, на момент написання - тільки Enterprise Plus). Він володіє всіма можливостями, притаманними мережевого обладнання від Cisco. Дозволяє домогтися того, що всі використовувані комутатори в мережі компанії створені одним виробником (тут мається на увазі Cisco), і мережеві адміністратори можуть керувати ними точно так же, як комутаторами фізичними, знімаючи, таким чином, ці завдання з адміністратора vSphere. Однак розгляд налаштувань і можливостей цього рішення в даній книзі описано не буде.
Тут буде описаний розподілений віртуальний комутатор від VMware.
Можливість їм користуватися з'являється після активації ліцензії, що дає на
нього право, - сьогодні це vSphere Enterprise Plus (і її ознайомчий 60-денний період після установки vSphere, Evaluation-ліцензія).
Як я вже сказав, dvSwitch - об'єкт швидше логічний, як такої існуючий тільки для vCenter. Ми створили один розподілений вКоммутатор, але на кожному сервері, для яких він існує, автоматично створюються стандартні вКоммутатори, приховані від нас (рис. 2.11). Таким чином, де-факто розподілений комутатор є шаблоном налаштувань. Ми створюємо його і вказуємо налаштування в vCenter - це control plane по документації VMware, тобто рівень управління. А після включення в створений розподілений комутатор серверів ESX (i) vCenter створює на них стандартні комутатори, приховані від нас. За документації VMware це IO Plane, прикладний рівень. За всю роботу відповідають приховані комутатори на серверах ESX (i), все управління здійснюється тільки через vCenter.
Мал. 2.11. Ілюстрація суті розподіленого віртуального комутатора Джерело: VMware
Мінусом такої схеми розподіленого віртуального комутатора VMware є зростаюча складність, зокрема залежність від vCenter. vCenter є керуючим елементом для dvSwitch, і при недоступності vCenter у адміністратора немає можливості змінювати налаштування розподіленого комутатора і навіть перемикати віртуальні машини на інші групи портів. Однак навіть при недоступності vCenter мережу буде продовжувати працювати - адже за технічну сторону питання відповідають приховані від нас комутатори на кожному ESX (i), втрачається тільки можливість зміни налаштувань.
До речі, підключення самого vCenter до розподіленого комутатора не підтримує VMware.
Підключіться клієнтом vSphere до vCenter. Передбачається, що в ієрархії vCenter вже створений об'єкт Datacenter, вже додані сервери. Розподілений віртуальний комутатор створюється для об'єкта Datacenter, і існувати для серверів з різних Datacenter один dvSwitch не може.
Пройдіть Home. Networking. У контекстному меню об'єкта Datacenter ви-
беріть пункт New vNetwork Distributed Switch.
У запустити майстра нас запитають:
Q Name - ім'я створюваного вКоммутатора. Впливає тільки на зручність;
Q Number of dvUplink ports - максимальна кількість підключень до зовнішньої мережі - прив'язаних vmnic - на кожному сервері. Зверніть увагу: один такий вКоммутатор може існувати для серверів з різною конфігурацією, з різною кількістю доступних мережевих контролерів - а тут ми обмежуємо максимальну кількість використовуваних для даного dvSwitch контролерів на одному сервері;
Q на останньому кроці можна буде зняти прапорець Automatically create a default port group. Якщо він стоїть, то автоматично буде створена група портів з 128 портами і ім'ям за умовчанням. Ім'я за замовчуванням малоинформативно, тому я рекомендую цей прапорець знімати і створювати групу портів самостійно, після створення вКоммутатора.
Зверніть вніманіе.У стандартних вКоммутаторов число портів налаштовується для них самих, групи портів «безрозмірні». У розподілених вКоммутаторов навпаки. Ви можете створити до 248 розподілених віртуальних комутаторів для сервера. На одному сервері може бути до 4096 портів стандартних і розбраті ділених вКоммутаторов. Це означає, що якщо не ставити свідомо величезних значень числа портів, то з обмеженнями з цього боку ви не зіткнетеся.
Коли ви створили dvSwitch, то на сторінці Home. Inventory. Networking
ви бачите картинку приблизно як на рис. 2.12.
Тут «Demo_dvSwitch» - це сам об'єкт - розподілений вКоммутатор. Об'єкт «Demo_dvSwitch-DVUplinks-28» - це група портів, в яку об'єднані його підключення до зовнішніх мереж. Тобто ті порти вКоммутатора, до ко
Мал. 2.12. свіжостворений dvSwitch
Другим підключені фізичні мережеві контролери серверів, на яких цей dvSwitch існує. Потрібен цей об'єкт для отримання інформації про зовнішніх підключеннях - зверніть увагу на стовпці в закладці Ports для даної групи портів. Число 28 в назві - це випадковим чином сгенерированное число, для унікальності імені цього об'єкта.
Ну і «Demo_dvPortGroup» - створена вручну група портів, туди можна підключати ВМ, а також віртуальні мережеві контролери Service Console і VMkernel.
Зверніть вніманіе.Прі використанні стандартних віртуальних комутаторів неможливо помістити в одну групу портів віртуальні машини і інтерфейс VMkernel або Service Console. На розподілених віртуальних комутаторах VMware це можливо, на dvSwitch в одній групі портів можуть співіснувати і ВМ, і інтерфейси SC і VMkernel в будь-яких поєднаннях.
До речі кажучи, об'єкт «VM Network» на цьому малюнку - це група портів на стандартних віртуальних комутаторах серверів цього vCenter.