Механізми перерозподілу ресурсів в ESX (i) – ЧАСТИНА 1

Limit, shares, reservation – це налаштування, якими ми вказуємо, як розподіляти ресурси А тепер поговоримо про те, завдяки яким механізмам ESX (i) вміє ці налаштування втілювати в життя і як влаштовано розподіл ресурсів сервера між віртуальними машинами

З точки зору ESX (i) процесори бувають трьох типів:

Q фізичні (physical, PCPU) Це саме процесори, іноді говорять «сокети» Залежно від їх кількості ESX (i) ліцензується

Q логічні (logical, LCPU) Це ядра фізичного процесора Фізичні

ядра або, у разі hypertreading, ядра логічні Кожен LCPU – це одна черга команд

Q віртуальні (virtual, VCPU) Один vCPU – це один процесор віртуаль-

ної машини Нагадаю, що процесорів на віртуальну машину може бути до восьми

Найперше, що необхідно сказати:

Q один vCPU працює на одному LCPU Тобто віртуальна машина з одним віртуальним процесором працює на одному ядрі Тобто навіть якщо у вас однопроцесорний восьмиядерний сервер, на якому працює тільки одна ВМ з одним процесором, – вона задіє тільки одне ядро

Q а от якщо ця ВМ з вісьмома vCPU, то вона задіє всі вісім ядер –

ESX (i) в обовязковому порядку розводить по різних ядрам процесори однієї ВМ

Q на одному ядрі може виконуватися кілька vCPU різних віртуальних

машин (рис 623)

Рис 623 Ілюстрація роботи з процесорної підсистемою Джерело: VMware

На ілюстрації показаний двопроцесорний сервер, кожен процесор двоядерний

Гипервизор здійснює балансування навантаження, з інтервалом в 20 мілі секунд може переносити vCPU між LCPU для кращої їх утилізації Service Console завжди працює на CPU0, тобто перший ядрі першого процесора

Механізми перерозподілу ресурсів в ESX (i)

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

З тих же міркувань не варто видавати для віртуальної машини памяті більше, ніж локально доступно одному процесору фізичного сервера Визначити цю величину можна, наприклад, за допомогою esxtop, лічильника NUMA

Операційна система очікує, що всі її процесори будуть працювати одночасно У разі фізичних серверів так і відбувається Але у випадку ВІРТУАЛ зації процесори, видимі гостьовий ОС, є віртуальними процесора мі, якими управляє гіпервізор Зокрема, гіпервізор перерозподіляє ресурси фізичних процесорів (ядер) між багатьма процесорами віртуальними І саме через те, що на кожному фізичному ядрі працюють кілька віртуальних процесорів, гіпервізорами і незручно виділяти такти віртуальним процесорам однієї ВМ одночасно (адже навантаження на різні фізичні ядра різна, десь в даний момент є вільні такти, десь немає) А якщо виділяти їх не одночасно, то гостьові ОС як мінімум отримуватимуть пенальті по продуктивності, а як максимум – Падати в BSOD і Kernel panic

Для гіпервізорів попередніх поколінь ця проблема вирішувалася тим, що гіпервізор відстежував «розсинхронізація», тобто ситуацію, коли якісь vCPU працювали, а якісь ні Коли різниця в часу роботи досягала порогового значення (кілька мілісекунд), гіпервізор зупиняв «втекли вперед» vCPU і чекав можливості виділити процесорні такти всім vCPU цієї ВМ одночасно Виходило, що значну частку часу все трохи vCPU цієї ВМ простоювали Так чинив ESX версії 2

Однак ESX (i), починаючи ще з версії 3, використовує механізм під назвою

«Relaxed coscheduling» Суть його полягає в тому, що одночасно отримувати такти повинні не всі vCPU однієї ВМ, а лише ті, що «відстали» Це зменшує втрати продуктивності через віртуалізації, дозволяючи більш ефективно утилізувати процесорні ресурси сервера

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

Зверніть увагу Консольна утиліта esxtop  (resxtop  для vCLI) показує час очікування синхронізації в стовпці %CSTP Таким чином, ця величина характеризує накладні витрати на віртуалізацію процесорів многопроцес смітної ВМ

Також у властивостях ВМ на закладціResources є рядокAdvanced CPU

(Рис 624)

Тут ви можете задати налаштування Hyperthreaded Core Sharing і CPU Affinity

Рис 624 Налаштування Advanced CPU

Hyperthreaded Core Sharing керує тим, як будуть використовуватися логічні процесори, на які ділиться кожне фізичне ядро ​​при включенні гіпертрейдінга Нагадаю, що для процесорів з включеним гіпертрейдінгом кожне фізичне ядро ​​породжує два логічних, що теоретично дозволяє виконувати частину команд в два потоки

Варіанти налаштування:

Q  Any – Коли віртуальний процесор цієї ВМ працює на якомусь ядрі, то на другому логічному ядрі цієї фізичної ядра можуть працювати інші vCPU цієї та інших віртуальних машин

Q  Internal – Настройка доступна лише для багатопроцесорних віртуальних машин Коли ВМ з кількома vCPU, то вони можуть працювати на різних логічних ядрах однієї фізичної ядра Для ВМ c одним процесором таке значення цієї настройки еквівалентно значенням None

Механізми перерозподілу ресурсів в ESX (i)

Q  None – Коли vCPU цієї ВМ починає виконуватися на якомусь фізичному ядрі, то він захоплює його повністю Друге логічне ядро ​​простоює На даному ядрі виконується тільки цей один vCPU цієї однієї ВМ

Зверніть увагу: ця настройка скидається на значення за замовчуванням (Any), коли ВМ в DRS-кластері або при міграції ВМ на інший сервер Придатність цієї настройки невелика – лише для тонкого тюнінга продуктивності віртуальних машин на одному сервері Як правило, ESX (i) добре управляє розподілом ресурсів без нашої участі

Зверніть увагу Немає чітких даних щодо ефективності використання гіпертрейдінга для ESX (i) Як правило, від включення гіпертрейдінга продуктивність змінюється незначно Вірогідність погіршення продуктивності від включення цієї функції невелика

Scheduling Affinity – тут ми можемо вказати ядра, на яких можуть виконуватися vCPU цієї ВМ Якщо за замовчуванням гіпервізор може розташувати процесор ВМ на будь-якому ядрі, то за допомогою цієї налаштування ми можемо обмежити його вибір

Якщо ми змінили дану настройку зі значення за замовчуванням, то ВМ втрачає здатність до живої міграції, що значно знижує застосовність даної настройки

От у нас є сервер ESX (i), для простоти один У нього є скількись оперативної памяті для віртуальних машин («Доступна память сервера»), і на ньому працює скількись віртуальних машин Кожній з віртуальних машин виділено скількись памяті («Налагоджена память ВМ»), і кожна якусь частку від налаштованої памяті споживає («Споживана память ВМ») Що можна розповісти про це

Доступна память сервера – Це все гігабайти памяті сервера мінус:

Q память, яку гіпервізор витрачає на себе ESXi створює в памяті RAM диск для своєї роботи ESX відрізає 300-800 Мб для Service Console Віртуальним комутаторів, iSCSI-ініціатору та іншим компонентам також потрібні ресурси для своєї роботи

Q накладні витрати Це память, яку гіпервізор витрачає для створення

процесу віртуальної машини Overhead, говорячи в термінах лічильників навантаження Коли ми створюємо віртуальну машину і вказуємо для неї 1 Гб памяті, гіпервізор їй видає частину або 100% цього гігабайти І навіть у випадку стовідсоткового виділення ще 100-150 Мб гіпервізор витрачає на накладні витрати Притому 100-150 Мб накладних витрат – це для гігабайти налаштованої памяті Якщо для віртуальної машини налаштувати 64 Гб памяті, накладні витрати складуть приблизно 1,5-2 Гб

Q кластер VMware HA може резервувати скількись памяті під свої потреби

Налагоджена память ВМ – Це той обсяг памяті, який ми вказуємо в налаштуваннях ВМ на вкладці Hardware Саме цей обсяг бачить гостьова ОС Це максимум, який гостьова ОС може використовувати Однак гіпервізор може виділити для ВМ з реального оперативки і менший обсяг, ніж «показав» їй памяті Те, що гостю виділено лише, наприклад, 400 Мб з показаного гігабайти, зсередини не помітити З яких причин гіпервізор буде так чинити, поговоримо трохи пізніше

Споживана память ВМ – Це скільки реальної оперативної памяті використовує віртуальна машина Або, правильніше сказати, який обсяг реальної памяті виділив їй гіпервізор У термінах моніторингу це Consumed

При обговоренні роботи з памяттю різних гіпервізорів часто зустрічається термін «Memory Overcommitment» Притому нерідко під ним розуміються різні речі Ми ж під даним словосполученням будемо розуміти ситуацію, коли сумарна «налаштована память» (стовпецьMemory Size) Всіх включених ВМ на сервері більше, ніж «доступна память сервера» (поле Capacity) (Рис 625)

На рис 625 ви можете побачити MO в дії – на сервері esx1vm4ru до-

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

*

*