Сьогодні розберемо метрики дискової підсистеми у vSphere. Проблема зі стораджем – найчастіша причина повільної роботи віртуальної машини. Якщо у випадках з CPU та RAM траблшутинг закінчується на рівні гіпервізора, то при проблемах з диском, можливо, доведеться розбиратися з мережею передачі даних та СГД.
Тему розбиратиму на прикладі блочного доступу до СХД, хоча при файловому доступі лічильники приблизно ті ж.
Трохи теорії
Коли говорять про продуктивність дискової підсистеми віртуальних машин, зазвичай звертають увагу на три пов'язані один з одним параметри:
- кількість операцій введення/виводу (Input/Output Operations Per Second, IOPS);
- пропускну спроможність (Throughput);
- затримку операцій введення/виведення (Latency).
Кількість IOPS зазвичай важливо для навантажень довільного характеру (random): доступ до блоків на диску, що у різних місцях. Прикладом такого навантаження можуть бути бази даних, бізнес-додатки (ERP, CRM) і т.д.
Пропускна здатність важлива для навантажень послідовного характеру: доступ до блоків, які розташовані один за одним. Наприклад, таке навантаження можуть генерувати файлові сервери (але не завжди) та системи відеоспостереження.
Пропускна здатність пов'язана з кількістю операцій введення/виводу таким чином:
throughput = IOPS * Block sizeде Block size – це розмір блоку.
Розмір блоку є досить важливою характеристикою. Сучасні версії ESXi пропускають блоки розміром до 32 КБ. Якщо блок ще більший, він ділиться на кілька. Не всі СГД можуть ефективно працювати з такими великими блоками, тому Advanced Settings ESXi має параметр DiskMaxIOSize. За допомогою нього можна зменшити максимальний розмір блоку, що пропускається гіпервізором (докладніше ). Перед зміною даного параметра рекомендую проконсультуватися з виробником СГД або хоча б протестувати зміни на лабораторному стенді.
Великий розмір блоку може згубно позначатися на продуктивності СГД. Навіть якщо кількість IOPS і черезвихід відносно невелика, при великому розмірі блоку можуть спостерігатися високі затримки. Тому звертайте увагу на цей параметр.
Затримка - Найцікавіший параметр продуктивності. Затримка операцій введення/виведення для віртуальної машини складається з:
- затримки усередині гіпервізора (KAVG, Average Kernel MilliSec/Read);
- затримки, яку дають мережу передачі даних та СГД (DAVG, Average Driver MilliSec/Command).
Загальна затримка, яку можна побачити у гостьовій ОС (GAVG, Average Guest MilliSec/Command), – це сума KAVG і DAVG.
GAVG та DAVG вимірюються, а KAVG розраховується: GAVG-DAVG.
Зупинимося докладніше на KAVG. При нормальній роботі KAVG повинен прагнути до нуля або принаймні бути значно менше, ніж DAVG. Єдиний відомий мені випадок, коли KAVG очікувано високий - обмеження по IOPS на диску ВМ. У такому разі при спробі перевищення ліміту зростатиме KAVG.
Найзначнішою складовою KAVG є QAVG – час у черзі на обробку всередині гіпервізора. Інші складові KAVG зневажливо малі.
Черга в драйвері дискового адаптера та черги до місяців має фіксований розмір. Для високонавантажених середовищ цей розмір корисно збільшити. описано, як збільшити черги в драйвері адаптера (одночасно збільшиться черга до місяців). Дана настройка працює, коли з місяцем працює лише одна ВМ, що буває рідко. Якщо на місяць кілька ВМ, необхідно також збільшити параметр Disk.SchedNumReqOutstanding (інструкція ). Збільшивши чергу, ви зменшуєте QAVG та KAVG відповідно.
Але, знову ж таки, спершу ознайомтеся з документацією від вендора HBA та протестуйте зміни на лабораторному стенді.
На розмір черги на місяць може впливати включення механізму SIOC (Storage I/O Control). Він забезпечує рівномірний доступ до місяця з боку всіх серверів кластера за рахунок динамічної зміни черги до місяця на серверах. Тобто, якщо на якомусь із хостів працює ВМ, яка потребує непропорційно багато продуктивності (noisy neighbor VM), SIOC зменшує довжину черги до місяця на даному хості (DQLEN). Детальніше .
З KAVG розібралися, тепер трохи про DAVG. Тут все просто: DAVG – це затримка, яку вносить зовнішнє середовище (мережа передачі та СГД). У будь-якій сучасній і не дуже СГД є свої лічильники продуктивності. Для аналізу проблем із DAVG має сенс дивитися на них. Якщо з боку ESXi та СГД все нормально, перевіряйте мережу передачі даних.
Щоб не було проблем із продуктивністю, вибирайте правильну Path Selection Policy (PSP) для вашої СГД. Практично всі сучасні СГД підтримують PSP Round-Robin (з ALUA, Asymmetric Logical Unit Access або без). Ця політика дозволяє використовувати всі доступні шляхи до СГД. У випадку ALUA використовуються тільки шляхи до контролера, який володіє місяцем. Не для всіх СГД на ESXi є дефолтні правила, які встановлюють політику Round-Robin. Якщо для вашого СГД правила немає, використовуйте плагін від виробника СГД, який створить відповідне правило на всіх хостах кластера, або створіть правило самостійно. Деталі .
Також частина виробників СГД рекомендують змінювати кількість IOPS на шлях зі стандартного значення 1000 на 1. У нашій практиці це дозволяло «вичавити» із СГД більше продуктивності та значно скоротити час, який потрібно на failover у разі виходу з ладу чи оновлення контролерів. Звіртеся з рекомендаціями вендора, і якщо протипоказань немає, спробуйте змінити цей параметр. Деталі .
Основні лічильники продуктивності дискової підсистеми віртуальної машини
Лічильники продуктивності дискової підсистеми vCenter зібрані в розділах Datastore, Disk, Virtual Disk:
У розділі Магазин даних знаходяться метрики за дисковими сховищами vSphere (датасторами), на яких лежать диски ВМ. Тут ви знайдете стандартні лічильники:
- IOPS'ам (Average read/write requests per second),
- пропускну здатність (Read/Write rate),
- затримкам (Read/Write/Highest latency).
З назв лічильників у принципі все зрозуміло. Ще раз зверну увагу, що тут статистика не за конкретною ВМ (або диском ВМ), а загальна по всьому датастору. На мій погляд, цю статистику зручніше дивитися в ESXTOP, хоча б виходячи з того, що мінімальний період виміру там 2 секунди.
У розділі Диск знаходяться метрики по блокових пристроях, що використовуються ВМ. Тут є лічильники по IOPS типу summation (кількість операцій введення/виводу за період вимірювання) і кілька лічильників, що належать до блокового доступу (Commands aborted, Bus resets). Цю інформацію, на мою думку, також зручніше дивитися в ESXTOP.
Розділ Віртуальний диск – найкорисніший з погляду пошуку проблем продуктивності дискової підсистеми ВМ. Тут можна переглянути продуктивність по кожному віртуальному диску. Саме ця інформація потрібна, щоб зрозуміти, чи є проблема конкретної віртуальної машини. Крім стандартних лічильників кількості операцій введення/виводу, обсягу читання/запису та затримок, в даному розділі є корисні лічильники, які показують розмір блоку: Read/Write request size.
На малюнку нижче графік продуктивності диска ВМ, на якому можна побачити кількість IOPS, затримки та розмір блоку.
Також метрики продуктивності можна подивитися по всьому датастору, якщо увімкнено SIOC. Тут представлена базова інформація по середній Latency та IOPS'ам. За умовчанням цю інформацію можна переглянути тільки в реальному часі.
ESXTOP
В ESXTOP кілька екранів, на яких представлена інформація щодо дискової підсистеми хоста в цілому, окремих віртуальних машин та їх дисків.
Почнемо з інформації з віртуальних машин. Екран "Disk VM" викликається клавішею "v":
NVDISK - Це кількість дисків ВМ. Щоб переглянути інформацію по кожному диску, натисніть “e” і введіть GID, що цікавить ВМ.
Значення інших параметрів цьому екрані зрозуміло з їх назв.
Ще один корисний під час пошуку проблем екран – Disk adapter. Викликається клавішею “d” (на зображенні нижче вибрані поля A, B, C, D, E, G):
NPTH – кількість шляхів до місяців, які видно з даного адаптера. Щоб отримати інформацію щодо кожного шляху на адаптері, натисніть “e” та введіть назву адаптера:
AQLEN – максимальний розмір черги адаптера.
Також на цьому екрані представлені лічильники затримок, про які я розповідав вище: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.
На екрані Disk device, який викликається клавішею “u”, представлена інформація щодо окремих блокових пристроїв – місяців (на малюнку нижче вибрані поля A, B, F, G, I). Тут можна побачити стан черги до місяців.
DQLEN - Розмір черги для блокового пристрою.
ACTV – кількість команд введення/виведення в ядрі ESXi.
QUED – кількість команд введення/виводу у черзі.
%USD - ACTV / DQLEN × 100%.
НАДАННЯ - (ACTV + QUED) / DQLEN.
Якщо %USD є високим, варто розглянути можливість збільшення черги. Що більше команд у черзі, то вище QAVG і, відповідно, KAVG.
Також на екрані Disk device можна переглянути, чи працює на СХД VAAI (vStorage API for Array Integration). Для цього потрібно вибрати поля A та O.
Механізм VAAI дозволяє перенести частину роботи з гіпервізора безпосередньо на СГД, наприклад занулення, копіювання блоків або блокування.
Як видно на картинці вище, на цій СХД VAAI працює: активно використовуються примітиви Zero та ATS.
Поради щодо оптимізації роботи з дисковою підсистемою на ESXi
- Звертайте увагу на розмір блоку.
- Встановлюйте оптимальний розмір черги на HBA.
- Не забувайте вмикати SIOC на датасторах.
- Вибирайте PSP відповідно до рекомендацій виробника СГД.
- Переконайтеся, що VAAI працює.
Корисні статті по темі:
Джерело: habr.com