Рекомендації з налагодження Limit, Reservation і Shares

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

Тут ви бачите, що ресурсів сервера (велика окружність) достатньо для задоволення поточних апетитів ВМ (маленькі кола) Проте їх недостатньо для одночасного задоволення максимально можливих апетитів (три пунктирні кола) Якщо у нас немає твердої впевненості в тому, що ці віртуальні машини не будуть вимагати максимуму своїх ресурсів одновремен але, то ця ситуація неправильна Правильною ситуацією є та, коли ресурсів сервера свідомо більше, ніж необхідно для всіх ВМ (рис 617)

Якщо у вас ситуація як на другому малюнку – то Limit, Reservation і Shares вам особливо й не потрібні, і саме до такої ситуації ви повинні прагнути при сайзінге сервера / серверів під ESX (i)

Рис 616 Ілюстрація недостатньої кількості ресурсів сервера

Рис 617 Ілюстрація достатньої кількості ресурсів сервера

Відмінно, цей момент прийнятий до уваги, конфігурація і кількість серверів достатні для задоволення навантаження з боку ВМ Проблема в тому, що кількість серверів може різко зменшитися в результаті збою Це не проблема для доступності додатків в ВМ – за наявності розділяється сховища ми легко можемо перезапустити ВМ з відмовив сервера на інших за хвилини А за наявності ліцензії на VMware High Availability це відбудеться автоматично

Таким чином, можлива ситуація, коли всі наші ВМ працюють на меншій кількості серверів – і ресурсів на всіх може вже не вистачити

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

Все-таки як ми можемо використовувати ці налаштування, коли ресурсів в достатку: Q може бути непоганою ідеєю створити пул ресурсів з встановленим limit для некритичних (тестових, тимчасових) ВМ, від яких можна очікувати вcплесков навантаження або навантаження з боку яких мало прогнозована

Q якщо у вас запитують сервер з великими ресурсами памяті / процесора, притому ви твердо знаєте, що запитують зайвого, то можна за допомогою limit вказати достатню кількість ресурсів Плюсом є те, що вам не потрібно сперечатися і доводити завищені вимоги до ресурсів, і те, що якщо більше ресурсів дати таки захочете, то досить буде підняти limit, і ВМ без перезавантаження зможе скористатися доповни тільних ресурсами

Q збільшення reservation для оперативної памяті зменшує розмір файлу підкачки, який ESX (i) створює при включенні кожної ВМ

Q якщо політика використання віртуальної інфраструктури передбачає

виділення під якісь завдання фіксованої кількості ресурсів, то має сенс створити пул ресурсів, в налаштуваннях якого і зафіксувати максимальну (limit) і мінімальне гарантоване (reservation) кількість ресурсів Класичний приклад таких завдань – хостинг ВМ, коли клієнт платить за якусь продуктивність, і в наших інтересах зробити так, щоб він отримував за що заплатив, і не більше

Типові рекомендації такі:

Створюйте пули ресурсів для ВМ різної важливості Крім того, пули ресурсів часто є зручними обєктами для призначення прав доступу – тому для ВМ однієї важливості може бути створено кілька пулів, тому що ці ВМ відносяться до різних адміністраторам Не забувайте, що пули ресурсів можуть бути вкладеними – це іноді зручно, в основному з організаційних міркувань

Якими настройками краще маніпулювати – shares або reservation / limit У типових випадках краще shares, тому що це не блокуюча настройка Нагадаю, що якщо недостатньо ресурсів для забезпечення reservation, ВМ не увімкнеться У разі shares таких проблем гарантовано не буде

Reservation може мати сенс давати для критичних ВМ, для того щоб гарантувати ресурси для їх роботи в разі нестачі ресурсів Однак найчастіше не варто резервувати весь обсяг памяті для них Для віртуальних машин гіпервізор надає нам лічильники Active Memory – до такого обєму оперативної памяті віртуальна машина звертається активно, часто Зазвичай має сенс резервувати середнє значення Active Memory за період часу не менше тижня Це гарантує, що досить великий обсяг памяті для ВМ буде виділений в будь-якому випадку

Чим менше reservation, тим менше ймовірність того, що ВМ не увімкнеться через брак ресурсів для забезпечення цього reservation Ще ВМ з високим reservation може бути мінусом для кластера HA, см присвячений йому розділ

Не забувайте, гарантія ресурсів для одних ВМ означає гарантоване витіснення в файл підкачки і недостатність процесорних тактів для інших, у разі коли ресурсів перестане вистачати на всіх

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

Якщо якась ВМ критична для нас і критичний рівень відгуку цієї ВМ (тобто швидкість роботи) – для неї має сенс зарезервувати всі або більшу частину виділених ресурсів

Отже, зведений план дій приблизно такий:

1 Думаємо, чи потрібна нам ця схема розподілу ресурсів Може бути, навіть вихід з ладу сервера іншого не призведе до нестачі ресурсів

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

2 Створюємо пули ресурсів для ВМ різного ступеня критичності

3 Відповідно критичності налаштовуємо shares: High – для критичних пулів, Low – для некритичних Залишаємо Normal для всіх інших Якщо є пули для тестових ВМ, пули, ВМ в яких створюються і видаляються не нами, – може мати сенс для них поставити limit, щоб ці ВМ не задіяли занадто багато ресурсів

4 При необхідності гарантувати якимось ВМ рівень ресурсів налаштовуємо для них reservation Це зажадає налаштувати reservation для пулів, в яких вони знаходяться

Не настроюйте reservation пулів ресурсів «впритул» Поверніться до рис 614 – сума reservation дочірніх обєктів менше, ніж reservation батьківського пулу, і так чинити правильно

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

*

*