Записки віртуального адміну Вплив снапшотів на продуктивність

Новини, огляди та нотатки про віртуальні машини та платформи віртуалізації.

субота, 21 травня 2011 р.

Вплив снапшотів на продуктивність - 1

Найчастіше користувачі скаржаться: "Якщо я натискаю "Delete snapshot" - все просто встає!" Причому в когось справді все гальмує, а хтось практично не помічає, що взагалі щось відбувається. Так що ж відбувається із снапшотами і як вони впливають на продуктивність?

Опис тестового середовища:

  • Windows 2003-R2-SP2 ВМ (32 bit);
  • 1 vCPU;
  • 2048 МБ RAM;
  • 5 GB завантажувальний диск у режимі "independent" - SAN;
  • Конфігураційні файли ВМ та 4 GB диск для вимірювань на локальних дисках (10K RAID1);
  • IOmeter (version 27.07.2006);
  • Perfmon вимірює reads/writes на PhysicalDisk з інтервалом 20 секунд;
  • ВМ створені на ESX3.5 та 4.0 для порівняння.
Звертаю вашу увагу, як і конфігураційні файли і диск для вимірювань перебувають у локальних дисках, тобто. всі файли снапшота також будуть на локальних дисках. Оскільки завантажувальний диск ВМ в режимі independent - снапшот до нього не застосовується і відповідн. впливу на продуктивність не надає.

IOmeter налаштований на два тести – з 25мс затримкою та 0мс. Для обох тестів використовуються такі параметри:

Детальний опис тесту:

  1. Завантажити ВМ;
  2. Запустити perfmon (read-і write операції за секунду (ROPS і WOPS);
  3. Видалити тестовий файл IOmeter та запустити IOmeter workload;
  4. Виміряти IOPS без снапшота;
  5. Зупинити IOmeter, видалити тестовий файл;
  6. Створити снапшот (пам'ять у снапшот не включати);
  7. Перезапустити IOmeter після того,як снапшот створено;
  8. Виміряти IOPS зі снапшотом;
  9. Видалити снапшот;
  10. Виміряти IOPS у процесі видалення снапшота;
  11. Якщо снапшот не вдається видалити, зупинити IOmeter і дочекатися видалення снапшота;
  12. Зупинити perfmon;
  13. Зберегти дані: Статистика VMware у реальному часі для ROPS та WOPS на рівні хоста та ВМ, статистику perfmon;
  14. Перенести всі дані в один великий файл Excel.
Як працюють снапшоти VMware

VMware вибрала технологію здійснення снапшотів прямо протилежну тій, яку використовують більшість виробників СГД. У VMware всі блоки, що підлягають запису в VMDK насправді пишуться в дельта-файл снапшота. Сам дельта-файл збільшується блоками 16MB.

Оригінальний файл віртуального диска стає замороженим і не змінюється. В силу цього додатку для резервного копіювання досить просто його скопіювати. До того ж, відкат до точки снапшота здійснюється не менш просто – видаляється дельта-файл, а незмінений оригінальний диск розморожується.

Але хто регулярно відкочується на снапшоти? Більшість їх створюється та комітується після (сценарії резервного копіювання)! І ось тут ми якраз отримуємо проблему, оскільки для комміту змін (видалення снапшота) необхідно прочитати весь дельта-файл (а він може зрости до розміру оригінального диска) та записати всі змінені блоки у файл віртуального диска. Тому й виходить ситуація, коли ВМ починає гальмувати і практично завмирає, поки снапшоти видаляються.

Інша проблема у коміті/видаленні снапшота VMware - куди зберігати дані, які змінюються в процесі видалення снапшота? Можна, звичайно, просто заморозити ВМ, закоммітити зміни і розморозити ВМ. Але впродуктивних середовищах це прямо скажемо сумнівне рішення, великі снапшоти вимагають багато часу для комміту. І саме тому VMware запропонувала рішення створити ще один снапшот.

Як видаляється снапшот

Припустимо, ми маємо ВМ зі снапшотом, і адміністратор натиснув на кнопку "Delete snapshot". Що ж відбувається?

Спочатку VMware створює другий снапшот, дочірній. Усі операції запису, здійснювані ВМ з цього моменту, йдуть у другий снапшот. А перший снапшот починає коміт змін до базового диска.

На момент остаточного видалення снапшота ми отримуємо ситуацію, з якої починали - ВМ зі снапшотом. Залишається сподіватися, що снапшот буде меншим за розміром, ніж початковий. VMware просто повторює процес, поки снапшот стане досить маленьким (макс. 16MB). Потім ВМ заморожується, останній снапшот комітується і ВМ розморожується. Оскільки останній снапшот був маленьким, час заморожування операцій введення-виведення залишається прийнятним.

Однак, як добре б це не виглядало, видалення снапшота може закінчитися неуспішно, якщо ВМ багато пише на диск. У цьому випадку другий снапшот може зростати швидше, ніж VMware комітіт перший, і як результат снапшот з кожною ітерацією росте замість зменшуватися!

Результати тестів: Загальна продуктивність читання/запису при снапшоті

У першому тесті навантаження генерувалося на рівні 32 ROPS + 32 WOPS одночасно, щоб не перевантажити дзеркало із 10k SAS дисків. Графіки продуктивності були практично ідентичними для ESX3.5 та vSphere, тому я наведу лише графік для ESX3.5: