
Базовий траблшутінг у середовищі VMware vSphere або що робити, якщо гальмує ВМ
Щось останнім часом технічні статті про віртуалізацію (та й не тільки про віртуалізацію) скочуються до формату «в новій версії очікується така фіча». Складається відчуття, що розбір механізмів і опис досвіду, проблем і рішень цікаві тільки закордонним експертам. З іншого боку, є така проблема у експертів - якщо щось вивчив, воно стає елементарним і сприймається само собою зрозумілим, настільки, що писати про це якось нерозумно. Особливо якщо вже було кимось описано десь. Колись. Якоюсь мовою. Ниженаписане - плід консолідації особистих нотаток, що спочатку призначався для особистого впорядкування думок, але наупорядкувавши значний обсяг тексту, подумав, що комусь може стати в нагоді.
Типова проблема «віртуалізаторів» - власник сервісу, замовник або користувач скаржиться, що у нього «гальмує» віртуальна машина. Оскільки віртуалізація передбачає консолідацію великої кількості ВМ на базі одного комплекту апаратних ресурсів, перепідписку (overprovision - коли ми припускаємо, що сервери не затребують одночасно максимум своїх ресурсів, а значить, наприклад, в 40 ГБ фізичної пам'яті ми можемо наштовхати не 10 серверів по 4 ГБ RAM, а 15, використовуючи Dynamic Memory), а крім того, сервери можуть гальмувати і через помилки в програмних компонентах і їх налаштуваннях, то кожен раз доводиться вирішувати за що хапатися і куди дивитися в першу чергу. Особливо, якщо з таким ємним описом проблеми, як «гальмує машина» не надано ніякої діагностичної інформації, як найчастіше і буває. Під палицею невелике керівництво для цього випадку.
Звичайно, все залежить від специфічності реалізації конкретної інфраструктури, але практика показує, що в більшості випадків має сенс наступна послідовність аналізу підсистем ВМ:
- Диски.
- Процесор.
- Оперативна пам'ять.
- Мережа
.
На практиці, до 4-го етапу майже ніколи не доходить, після третього (а то й після першого) має сенс запускати (або запитувати) паралельну діагностику гостьової ОС, але диски варто перевірити відразу - найзначніша частина інцидентів зі скаргами на продуктивність пов'язана з ними. Якщо, звичайно, у вас не All-Flash масив.
А тепер трохи детальніше по кожному пункту.
1. Диски (підсистема зберігання)
Найключовіший тут показник - це Latency. Затримка часу відгуку. Вона складається з великої кількості проміжних елементів і залежить від великої кількості факторів. Сюди входить час відгуку гіпервізора, час проходження сигналу по кабелях і проміжних пристроях (комутатори, адаптери і контролери), час перебування в чергах на всіх цих пристроях, якщо навантаження на них перевищує норму і ще деякі нюанси, такі як пошкодження обладнання. Однак, залишивши нюанси для розширеної діагностики, необхідної в рідкісних випадках, можна виділити простий загальний показник - час затримки від ВМ до дисків.
Інструменти діагностики:
Perfomance Tab
(закладка Perfomance в vSphere Client і лічильники продуктивності).
Найбільш часто використовувані лічильники групи Disk:
Highest Latency - норма до 10-15 мс. Якщо регулярно вище, треба щось змінювати, хоча разові піки не страшні;
Average write requests per second;
Average read requests per second.
Найбільш часто використовувані лічильники групи Virtual Disk:
Read/Write latency;
Average number of outstanding read/write requests - кількість одночасних IO-запитів (якщо їх число тримається вище 30 в сумі на датастор або на сервер, це буде призводити до додаткових затримок);
ESXTop
Консольна утиліта ESX/ESXi. Видає цілу купу діагностичної інформації про окремо взятого ESXi. Базову інформацію щодо використання можна отримати, натиснувши h після запуску утиліти.
У плані діагностики дискової підсистеми буде корисний контекст віртуальних дисків (натиснути v) і контекст HBA-адаптерів (натиснути d). В останньому випадку варто звернути увагу на такі показники:
KAVG (Kernel Latency Avg) - час відклику гіпервізора (норма - до 1 мс);
DAVG (Device Latency Avg) - час відгуку від HBA до дисків (норма - 10-15мс);
GAVG (Guest Latency Avg) - час відгуку для гостьової системи = сума KAVG і DAVG
До речі, в цій же області досліджень варто відразу перевірити чи немає у ВМ снапшоту. А то й кількох. Вони можуть стати проблемою не тільки паденрія продуктивності, а й збоїв операцій резервного копіювання, клонування та міграції.
2. Процесор
Тут аналогічний за важливістю дисковим затримкам показник - CPU Ready. Також варто звертати увагу на Used, Wait і Co-Stop. Можна також моніторити через Perfomance Tab або ESXtop.
CPU Ready (% RDY) -% часу, коли ВМ готова проводити якісь обчислення, але фізичні процесори в даний момент зайняті іншими процесами (системними або іншими ВМ) і vCPU віртуальної машини знаходяться в режимі очікування. Нормою вважається значення до 10%. При зростанні цього показника вище 40% розвивається висока ймовірність збоїв і зависань гостьової ОС. Причиною вимушеного простою може стати:
- інтенсивне споживання процесорних ресурсів великою кількістю ВМ, причому сумарна кількість vCPU істотно перевищує кількість логічних ядер (перепідписка).
- Наявність oversized ВМ (віртуальні машини з великою кількістю недозавантажених vCPU, наприклад якщо у машини 16 ядер, кожна з яких працює на 1-20% потужності). Проблема тут в тому, що при великій кількості vCPU, планувальнику гіпервізора доводиться синхронізувати їх роботу, що призводить до періодичного «заморожування» деяких ядер або навіть всієї машини, поки не звільниться повна кількість логічних ядер, що відповідає кількості vCPU, необхідна для певної операції. Механізм називається Co-Stop, і відповідний лічильник буде рости в цьому випадку. Це головний аргумент проти набивання віртуальної машини віртуальними процесорами «про запас» (другий аргумент - NUMA, але він вже за рамками статті). Краще 2 ядра, завантажених на 80%, ніж вісім ядер по 20%. У більшості випадків.
- Якщо використання CPU для віртуальної машини обмежено на рівні Resource Pool або самої машини. Після досягнення певного порогу, машина не отримає процесорних ресурсів і буде накопичувати CPU Ready. У цьому випадку буде збільшено значення лічильника Max-Limited (% ML).
Wait (% WAIT) -% часу, протягом якого ВМ чекає закінчення якоїсь активності VMkernel. Найчастіше це дискова IO-активність. Високі показники цього лічильника можуть говорити про недостатньо швидкий відгук від датастора. Також проблему можуть викликати некоректна робота USB або COM-портів або віртуальний CD/DVD-приводи, в який замонтовано відсутній нині ISO.
Used (% USED) -% часу, протягом якого машина реально працювала. Якщо він близько нуля, значить машина просто стоїть або її пересайзили процесорами. Якщо він близько 100 (на кожен vCPU), значить або недосайзили, або в ній щось зациклилося (якщо вона ще й не відгукується при цьому), або зараз там лопатиться якийсь квартальний звіт. Цей показник варто вивчати при роздумі на тему «чи дати ВМ ще процесорів, щоб швидше працювала?». Якщо у неї 4 ядра і жодне не задіяно більш ніж на 50%, то 8 ядер її швидше за все не прискорять. Можливо, навіть сповільнять (див. CPU Ready).
Інструменти діагностики ті ж.
Perfomance Tab
Зручно, що можна подивитися дані не тільки по машині в цілому, але і по кожному ядру. Крім того, доступна статистика за період. Однак інформація надається не у відсотках, а в мілісекундах. Оскільки дані збираються не в real-time, а за певний інтервал, відображається, скільки саме mc процесор знаходився в тому чи іншому стані. Перевести у відсотки можна розділивши значення на довжину інтервалу і помноживши на 100%.
Приклад: на малюнку діаграма з інтервалом 20 секунд (real-time), тобто 20 000 мс. Тобто середнє CPU Ready буде 50288 / 20000 * 100% = 251.44%. Оскільки у машини 4 ядра, а не одне, то результат ділимо на 4 і отримуємо майже 63%. Машина дуже страждає. А все тому, що лежить на третьому рівні вкладеності Resource Pools з низькими shares на кожному.
Ще раз, формула перетворення: < CPUReady >/< інтервал статистики у мс >/< кількість vCPU > * 100%. Виходить 5% на 1000 мс для одного ядра.
ESXTop
Тут вказано значення у%. Тільки воно вказано відразу в сумі для всіх ядер, так що не варто лякатися чисел більше 100. Діліть на кількість vCPU машини.
3. Оперативна пам'ять
Базова діагностика тут проста - так чи ні. Якщо є факт balooning'a означає хосту не вистачає пам'яті і процеси гостьових ОС страждають, тому що активно використовується файл підкачки. Якщо є факт свопінгу на рівні гіпервізора, треба терміново вживати заходів - машина, що потрапила в своп, впадає в кому в 100% випадків (принаймні моєї практики). Вищевказані факти дозволяють визначити такі лічильники як
Balloon (MCTLSZ) - кількість пам'яті, витягнута baloon-драйвером з гостьових ОС.
Swapped (SWCUR) - кількість пам'яті, розміщеної в .vswp (тобто на жорсткий диск).
4. Мережа
Щоб проблеми були на рівні мережі, у разі скарг на окрему віртуальну машину, я в своїй практиці пам'ятаю тільки один випадок - коли в VDI використовувалася якась дешева веб-камера, яка гнала незжатий потік відео і забивала всі 100 Мб/с.
Варто моніторити такі лічильники:
Transmit Dropped Packets (% DRPTX) - кількість (або відсоток у випадку esxtop) відкинутих відправлених пакетів;
Receive Dropped Packets (% DRPRX) - кількість (відсоток) відкинутих прийнятих пакетів.
Ненульове їх значення, що виникає на регулярній основі говорить про некоректну роботу мережевих пристроїв або некоректне їх налаштування.
Для базової діагностики, що покриває більше половини (мабуть, до 90%) звернень або власних потреб при діагностиці та тестуванні, цього достатньо.