Механізми перерозподілу ресурсів в ESX (i) - ЧАСТИНА 1
Limit, shares, reservation - це налаштування, якими ми вказуємо, як розподіляти ресурси. А тепер поговоримо про те, завдяки яким механізмам ESX (i) вміє ці настройки втілювати в життя і як влаштовано розподіл ресурсів сервера між віртуальними машинами.
6.2.1. CPU
З точки зору 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 різних віртуальних
машин (рис. 6.23).
Мал. 6.23. Ілюстрація роботи з процесорної підсистемою Джерело: 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
(Рис. 6.24).
Тут ви можете задати налаштування Hyperthreaded Core Sharing і CPU Affinity.
Мал. 6.24. Налаштування 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 цієї ВМ. Якщо за умовчанням гипервизор може розташувати процесор ВМ на будь-якому ядрі, то за допомогою цієї настройки ми можемо обмежити його вибір.
Якщо ми змінили цю настройку зі значення за замовчуванням, то ВМ втрачає здатність до динамічної міграції, що значно знижує можливість застосування даної настройки.
6.2.2. Memory
Ось у нас є сервер 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 Overcommitment». Притому нерідко під ним розуміються різні речі. Ми ж під цим словосполученням будемо розуміти ситуацію, коли сумарна «налаштована пам'ять» (стовпець Memory Size) всіх включених ВМ на сервері більше, ніж «доступна пам'ять сервера» (поле Capacity) (рис. 6.25).
На рис. 6.25 ви можете побачити MO в дії - на сервері esx1.vm4.ru до-
Джерело: Міхєєв М. О. Адміністрування VMware vSphere 4.1. - М .: ДМК Пресс, 2011. - 448 с .: іл.
на Ваш сайт.
Що можна розповісти про це?