Віртуальні контролери Service Console і VMkernel

Перше, чим відрізняються віртуальні мережеві контролери, – це приналежність Належати вони можуть Service Console (для ESX, у ESXi немає Service Console), VMkernel (самому гіпервізорами) і віртуальним машинам

Якщо віртуальний контролер належить ВМ, то він може бути різних типів – Flexible, vmxnet2, vmxnet3, E1000 Але про них поговоримо в розділі, присвяченому властивостям і обладнанню віртуальних машин, а тут сконцентруємо увагу на віртуальних мережевих контролерах для Service Console і VMkernel

Віртуальний мережевий контролер для Service Console використовується для управління сервером ESX Один такий контролер створюється монтажником сервера ESX, саме йому належить той IP-адреса, який ви вказали при установці Саме на IP-адресу Service Console ви підключаєтеся клієнтом vSphere, через нього з сервером працює vCenter, на цей IP підключаються утиліти для роботи з ESX Також через інтерфейс Service Console йдуть сигнали пульсу (heartbeat) при роботі кластера VMware HA Нарешті, деякі варіанти резервного копіювання віртуальних машин здійснюються через інтерфейси Service Console

Вам слід резервувати керуючий інтерфейс, зробити це можна двома шляхами, див рис 26

У лівій частині малюнка ви бачите дубльовану конфігурацію єдиного інтерфейсу Service Console Вона задублірована за рахунок того, що до вКоммута-

Рис 26 Два варіанти дублювання керуючого інтерфейсу ESX

тору підключено два мережних контролери Таким чином, вихід з ладу однієї фізичної мережевий картки (а якщо вони підключені до різних фізичних комутаторів – то і одного з них) не призведе до недоступності управління сервером ESX по мережі

У правій частині малюнка ви теж бачите дубльовану конфігурацію, але дубльовану по-іншому – створено два інтерфейсу Service Console, на різних вКоммутаторах, отже, на різних vmnic Якщо вийде з ладу один з каналів у зовнішню мережу (сам vmnic або порт у фізичному комутаторі, до якого він підключений, або сам фізичний комутатор), то один з інтерфейсів SC стане недоступний, але залишиться інший

Перший варіант зручніше у використанні, але якщо ми не можемо собі дозволити виділити два vmnic на вКоммутатор з Service Console, то він буде неможливий Виділити може не вийти, якщо кількість мережевих контролерів в сервері недостатньо під всі наші завдання Тоді має сенс піти по другому шляху Само собою, на вКоммутаторах інтерфейси Service Console можуть сусідити з будь-якими іншими віртуальними інтерфейсами в будь-яких кількостях – на рис 26 їх немає для простоти

Проте перший варіант резервування не захистить від двох додаткових типів проблем:

Q помилки налаштувань інтерфейсу SC

Q проблеми в зовнішній мережі У другому прикладі двох різних інтерфейсів SC дані адреси з різних мереж, і це захистить в тому випадку, якщо одна з цих мереж почне відчувати проблеми (наприклад, перевантаження паразит вим трафіком або збій маршрутизатора)

Створити ще один інтерфейс дуже просто: Configuration ⇒  Networking

Аdd Networking (Для створення нового вКоммутатора – тобто резервування

по правому варіанту з рис 26) Нас запитають, групу портів для чого ми хочемо створити на цьому вКоммутаторе Нескладно здогадатися, що зараз нас цікавить Service Console Вибираємо, тиснемо Next Виберемо, які vmnic привязати до створюваного зараз вКоммутаторуNext Вказуємо імя (Network Label) – це назва групи портів

Ця назва – для людини, так що рекомендую давати говорять назви

«Service_Console_2» цілком підійде

Однак при чому тут група портів, ми ж створюємо віртуальний мережевий інтерфейс Service Console Справа в тому, що будь-який віртуальний мережевий контрол лер числиться підключеним саме до групи портів, тому при створенні інтерфейсу SC з GUI ми створюємо і інтерфейс Service Console, і групу портів для нього

На стандартному віртуальному комутаторі інтерфейс Service Console завжди займає свою групу портів цілком (або, що те ж саме, група портів для Service Console завжди складається з одного порту) Цей факт не є обмеженням – на одному вКоммутаторе можуть співіснувати будь-які віртуальні інтерфейси в будь-яких комбінаціях, просто під кожен інтерфейс Serice Console (і, забігаючи вперед, VMkernel) створюється окрема група портів

Зверніть увагу Я не рекомендую використовувати прогалини і спецсимволи в яких би то не було назвах Це не смертельно, але може створити додаткові проблеми при роботі в командному рядку і сценаріях

все

Потім для віртуального контролера вказуємо налаштування IP В принципі,

Єдиний, напевно, нюанс – якщо хочемо створити інтерфейс SC не так на но-

вом, а на вже існуючому вКоммутаторе Тоді робимо так: Configuration

Networking ⇒ для потрібного вКоммутатора натискаємоProperties ⇒ і на вкладці

Ports натискаємо Add Далі все так само

Нарешті, у разі розподілених віртуальних комутаторів пройдіть Configuration Networking ⇒ кнопкаDistributed Virtual Switch ⇒ посилання Manage Virtual Adapters Add

Будьте акуратні в разі зміни налаштувань інтерфейсу SC, коли він один, – у разі помилки (наприклад, друкарські помилки в IP-адресі) доступ до управління ESX по мережі стане неможливий Вирішується така проблема з командного рядка для ESX або з BIOS-подібного локального інтерфейсу ESXi У будь-якому випадку знадобиться доступ до локальної консолі сервера – фізично або по iLO і аналогам

Зверніть увагу Віртуальний мережевий контролер для Service Console називається vswif – при створенні їх з GUI їм даються імена виду vswif #, в командному рядку ми управляємо цими обєктами за допомогою esxcfg-vswif

Для ESX управління йде через інтерфейс Service Console Але у складі ESXi немає Service Console Тому для ESXi в якості інтерфейсів управління використовуються віртуальні мережеві контролери VMkernel, ті з них, у властивостях яких встановлений прапорець «Management traffic» (рис 27)

Таким чином, організаційні міркування тут ті ж самі, що і для інтерфейсів Service Console в ESX, але в якості самих інтерфейсів виступають інтерфейси VMkernel з відповідним прапорцем у властивостях

І в ESX, і в ESXi ми можемо створити віртуальні мережеві адаптери для VMkernel, для гіпервізора Потрібні вони для:

Q vMotion – по цих інтерфейсів передаватиметься вміст оперативними-

ної памяті переносимої ВМ

Q підключення дискових ресурсів по iSCSI у разі використання програмного ініціатора iSCSI

Q підключення дискових ресурсів по NFS

Q Fault Tolerance – по цих інтерфейсів передаватимуться процесорні інструкції на резервну ВМ в Fault Tolerance-парі

Q (тільки на ESXi) управління сервером (на ESX для цього використовується

мережа Service Console)

Рис 27 Керуючий інтерфейс ESXi

Див подробиці і вимоги до мережі для відповідних функцій в розділах, їм присвячених

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

Віртуальні мережеві контролери для гіпервізора створюються точно так само, як для Service Console (на ESX): Configuration Networking ⇒ і потім:

Q абоАdd Networking для створення нового вКоммутатора і інтерфейсу VMkernel на ньому

Q або для існуючого вКоммутатора Properties Add на закладці

Q у випадку розподілених віртуальних комутаторів пройдітьConfiguration Networking ⇒ кнопкаDistributed Virtual Switch ⇒ посилання Manage Virtual Adapters Add

У будь-якому випадку як тип додається інтерфейсу вибираємо VMkernel Вкажемо імя групи портів і налаштування IP для створюваного інтерфейсу

Зверніть увагу на те, що для інтерфейсу VMkernel у нас є можливість встановити три прапорці (рис 28)

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

Рис 28 Налаштування інтерфейсу VMkernel на ESXi

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

До того ж у разі використання ESXi через інтерфейс з прапорцем «Management traffic» за замовчуванням не пересилається трафік iSCSI і NFS Якщо ви плануєте використовувати один інтерфейс для управління і звернення до IP-СГД, то краще всього створити кілька інтерфейсів, нехай навіть з однієї підмережі і на одному і тому ж віртуальному комутаторі

Зверніть увагу Віртуальні мережеві контролери цього типу називаються vmk – при створенні їх з GUI їм даються імена виду vmk #, в командному рядку ми управляємо цими обєктами за допомогою команди esxcfg-vmknic

Джерело: Міхєєв М О Адміністрування 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>

*

*