Переклад. Оригінальна стаття доступна в блозі Xen.
Автор - Felipe Franciosi.
Останні тестові збірки XenServer Creedence Alpha відрізняються підвищеною продуктивністю дискової підсистеми порівняно з XenServer 6.2 (подробиці в блозі Маркуса Гранадо (Marcus Granado) - Performance Improvements in Creedence). В основному, поліпшення пов'язані з впровадженням нової архітектури дискової підсистеми - tapdisk3. Ми опишемо цю технологію організації віртуального сховища, а також наведемо і пояснимо результати експериментів, в яких досягається продуктивність приблизно 10Gb/s одному хості з підключеним кластерним сховищем.
Кілька місяців тому я писав про проект Karcygwins, який включав серію експериментів і досліджень, спрямованих на вивчення особливостей роботи дискового введення-висновку. Ми зосередилися на випадку, коли навантаження генерує одна ВМ з одним віртуальним диском. Зокрема, нас цікавило розуміння природи додаткових витрат (overhead) на віртуалізацію, особливо на пристроях з малими затримками, наприклад - сучасних SSD. Порівнюючи різні способи віртуалізації дискового введення-виведення, доступні користувачеві (тобто blktap і blktap2), ми зуміли пояснити, де і чому виникають додаткові витрати, а також як їх значно зменшити. Докладніше про проект Karcygwins можна прочитати за посиланням.
З цього моменту ми розширили коло досліджень на випадки з більш складною структурою навантаження. Особливо нас цікавило спільне навантаження від декількох ВМ, які порожнечею завантажують сховище. Ми вивчали особливості нової підсистеми tapdisk3, розробленої для XenServer Таносом Макатосом (Thanos Makatos). Tapdisk3 написаний для спрощення архітектури і винесення її повністю в простір користувача, а це, в свою чергу, призводить до істотного підвищення продуктивності.
Між tapdisk2 і tapdisk3 є дві суттєві відмінності. Перше - це спосіб, яким tapdisk з'єднується з підсистемою дискового введення-виведення: старий tapdisk звертається до пристроїв blkback і blktap2 всередині гіпервізора, а новий - безпосередньо до паравіртуального драйвера всередині ВМ. Друге - метод, яким гостьова ВМ і гіпервізор обмінюються даними: старий tapdisk використовує доступ до показаних сторінок пам'яті в пам'яті ВМ і подальше їх копіювання в адресний простір гіпервізора, другий же використовує технологію копіювання при доступі (grant copy).
Все ж інші модифікації необхідні для того, щоб зробити можливим таку зміну архітектури. Більша їх частина зачіпає рівень керування віртуальними машинами (control plane). Для цього ми змінили стек керування (xapi) таким чином, щоб він підтримував постійний зв'язок з модулем tapdisk. Через ці зміни (а так само через деякі інші, що відносяться до того, як tapdisk3 обробляє дані, що надходять) змінився і спосіб представлення віртуальнго диска в пам'яті гіпервізора. Оскільки tapdisk3 поки ще не випущений офіційно, в майбутньому можливі й інші зміни.
Щоб виміряти досягнуту в рамках tapdisk3 продуктивність, ми вибрали найшвидший з наявних у нас сервер і найшвидше сховище.
- Платформа Dell PowerEdge R720
- 64 GB ОЗП
- Процесор Intel Xeon E5-2643 v2 @ 3.5 GHz
- 2 сокети, 6 ядер на сокет, hyperthreading = 24 pCPU
- Частота в режимі Turbo - 3.8 GHz
- Планувальник CPU гіпервізора переведений в режим «Performance» (за замовчуванням встановлений в «On Demand» для збереження електроенергії). Рейчл Беррі (Rachel Berry) у своєму блозі описала роботу планувальника більш докладно.
- У BIOS встановлено режим «Performance per Watt (OS)», режим «Maximum C-State» встановлено в 1
- 4 x Micron P320 PCIe SSD (175 Гб кожен)
- 2 x Intel 910 PCIe SSD (400 ГБ кожен)
- Кожен з них представлений як 2 SCSI пристрої по 200 Гб кожен (всього - 4 пристрої і 800 Гб в сумі)
- 1 x Fusion-io ioDrive2 (785 Гб)
Після встановлення XenServer Creedence з номером збірки 86278 (приблизно на 5 номерів старше XenServer Creedence Alpha 2) і дисків Fusion-io ми створили сховище на кожному доступному пристрої. Вийшло 9 сховищ і приблизно 2,3 Тб вільного місця. На кожному сховищі ми створили 10 віртуальних дисків у форматі RAW по 10 Гб кожен. Кожен віртуальний диск ми з'єднали з його віртуальною машиною, вибираючи диски «по колу», як це показано на діаграмі нижче. В якості гостьової ОС була обрана Ubuntu 14.04 (архітектура x86_64, 2 логічних CPU, жорстко не прив'язаних до реальних, 1024 Мб ОЗУ). Ми також передали 24 логічних CPU гіпервізору і вирішили не асоціювати з їх з реальними (у статті XenServer 6.2.0 CTX139714 більш детально описана методика прив'язки логічних CPU до реальних).
Спочатку ми виміряли сукупну продуктивність каналу між гіпервізором і віртуальною машиною, якщо диски підключені стандартним способом tapdisk2 < - > blktap2 < - > blkback. Для цього ми змусили одну віртуальну машину посилати 10-секундні запити на запис на всі її диски одночасно, а потім підрахували загальний обсяг переданих даних. Розмір запиту варіювався від 512 байт до 4 Мб. Після цього ми збільшили число віртуальних машин до 10-и, а потім змінили запити на запис запитами на читання. Результат показано на графіках нижче:
Вимірювання показали, що віртуальні машини не в змозі звертатися до диска зі швидкістю понад 4 Гб/с. Потім ми повторили експеримент з використанням tapdisk3. Результат явно покращився:
У разі запису, сукупна пропускна здатність дискової підсистеми для всіх ВМ досягає позначки в 8 Гб/с, у разі ж читання - 10 Гб/с. З графіка випливає, що в деяких випадках продуктивність tapdsik3 більше продуктивності tapdisk2 приблизно в 2 рази на запис і 2,5 рази на читання.
Щоб зрозуміти, чому tapdisk3 настільки перевершує tapdisk2 у продуктивності, слід спочатку розглянути архітектуру підсистеми віртуального сховища, яке використовують паравіртуальні ВМ і гіпервізор. Ми зосередимо увагу на компонентах, які використовує XenServer і звичайна ВМ під управлінням Linux. Тим не менш, слід мати на увазі, що інформація, викладена нижче, актуальна і для ВМ під управлінням Windows, якщо ця ОС використовує встановлені паравіртуальні драйвери.
Як правило, гостьова ВМ під керуванням Linux при старті завантажує драйвер під назвою blkfront. З точки зору гостьової ВМ це звичайний блочний пристрій. Відмінно ж у тому, що замість взаємодії з реальним обладнанням, blkfront спілкується з драйвером blkback в тілі гіпервізора через поділену пам'ять і механізм подій (event channel), який використовується для передачі переривань між доменами.
Програми всередині гостьової ОС ініціюють операції читання або запису (через бібліотеки libc, libaio тощо) файлів або ж безпосередньо блокових пристроїв. Операції в кінцевому рахунку транслюються в запити до блокових пристроїв і передаються blkfront через випадково обрані сторінки пам'яті в адресному просторі гостя. Blkfront, у свою чергу, надає гіпервізору доступ до цих сторінок таким чином, що blkback може читати і писати в них. Цей тип доступу називається «надання доступу до показаних сторінок пам'яті» (grant mapping).
Незважаючи на те, що спільнота розробників Xen Project проводить кампанію з поліпшення масштабованості і продуктивності механізму доступу до відображених сторінок, залишається ще багато роботи, оскільки система влаштована складно і має ряд обмежень, особливо - що стосуються спільного доступу до сховища з декількох ВМ. Найбільш помітна недавня зміна - набір патчів від Метта Вілсона (Matt Wilson) для поліпшення механізму блокувань і більшої продуктивності.
Щоб зменшити додаткові витрати на виділення і звільнення пам'яті для кожного запиту в механізмі доступу до відображених сторінок, Роджер По Мун (Roger Pau Monne) реалізував у протоколі blkback/blkfront нововведення, назване «доступ за постійними адресами» (persistent grant). Такий доступ може бути використаний, якщо обидва домени (гіпервізора і ВМ) його підтримують. У цьому випадку blkfront надає blkback-у доступ до постійного набору сторінок і обидва драйвери використовують цей набір так довго, як тільки зможуть.
Зворотна сторона полягає в тому, що blkfront не може вказувати, які сторінки будуть асоційовані із запитом, що надійшов з рівня блочного пристрою гостьової ВМ. Йому в будь-якому випадку доводиться копіювати дані з запиту в цей набір перед тим, як передати запит в blkback. Однак, навіть якщо врахувати цю операцію копіювання, доступ за постійними адресами залишається хорошим методом для збільшення масштабованості при одночасному введенні-виведенні з декількох ВМ.
Обидва представлені вище зміни повністю реалізовані в просторі ядра гіпервізора. Однак ми не враховуємо, що запит до блочного рівня гіпервізора містить посилання на сторінки в адресному просторі гостя. Це може викликати стан перегонів при використанні мережевих сховищ, таких як NFS, і, можливо, iSCSI: якщо мережевий пакет (який містить покажчик на сторінку обміну) поміщений в чергу для повторної передачі і приходить підтвердження передачі оригінального пакета, гіпервізор може повторно відправити невірні дані або навіть аварійно закінчити роботу, оскільки сторінка обміну може або містити неправильні дані або взагалі бути звільнена.
Щоб уникнути проблем, XenServer копіює сторінки в пам'ять гіпервізора замість того, щоб використовувати їх безпосередньо. Ця функція вперше з'явилася в драйвері blktap2 і компоненті tapdisk2, поряд з технологіями виділення місця на вимогу (thin-provisioning) і переміщенням дисків ВМ між сховищами (Storage Motion). У рамках цієї архітектури blktap2 копіює сторінки перед тим, як передати їх tapdisk2, щоб забезпечити безпечну роботу мережевих сховищ. З цієї ж причини blktap2 надає гіпервізору повнофункціональний блочний пристрій для кожного віртуального диска незалежно від його природи (в тому числі і «урізаним» дискам у форматі thin-provisioning, розміщеним на сховищах NFS).
Як ми бачимо з результатів наведених вище вимірювань, ця технологія має обмеження. Вона хороша для різних типів класичних сховищ, однак демонструє низьку продуктивність при роботі з сучасними засобами зберігання даних, наприклад, SSD-дисками, підключеними безпосередньо до сервера по шині PCIe. Щоб врахувати останні зміни в технологіях зберігання даних, XenServer Creedence буде містити новий компонент - tapdisk3, який використовує ще один спосіб доступу до пам'яті - копіювання при доступі (grant copy).
Починаючи з версії ядра 3.x в якості домену гіпервізора (dom0) і появою пристрою доступу (gntdev), ми отримали доступ до сторінок інших доменів безпосередньо з користувальницького простору гіпервізора. Ця технологія реалізована в tapdisk3 і використовує пристрій gntdev, а також канал подій evtchn, щоб обмінюватися даними безпосередньо з blkfront.
Копіювання при доступі набагато швидше, ніж просто надання доступу за постійними адресами, а потім - копіювання. При такому доступі більшість операцій виконується всередині ядра Xen Project Hypervisor, крім того, забезпечується присутність даних в адресному просторі домену гіпервізора для безпечного функціонування мережевих сховищ. Також, оскільки логіка реалізована повністю в просторі користувача, включення додаткового функціоналу (на зразок thin-provisioning, снепшотів або Storage Motion) не створює особливих труднощів. Щоб забезпечити доступ гіпервізора до блокового пристрою, відповідного диску віртуальної машини (для копіювання диска та інших операцій) ми підключаємо tapdisk3 до blktap2
Останнє (але не за значенням), про що ми хотіли написати: спокушений читач може запитати, чому XenServer не використовує можливості qemu-qdisk, який реалізує технологію доступу за постійними адресами в просторі користувача? Справа в тому, що, для забезпечення безпечної роботи мережевих сховищ (в тому числі і для доступу за постійними адресами, при якому запит до сховища посилається на сторінки в пам'яті гостьовий ВМ), qemu-qdisk знімає прапор O_DIRECT при доступі до віртуальних дисків. Це призводить до того, що дані копіюються в кеш домену гіпервізора, чим забезпечується безпечний доступ до даних. Таким чином, доступ за постійними адресами в цьому випадку призводить до надлишкового копіювання і до затримок при обслуговуванні запитів. Ми вважаємо, що копіювання при доступі - краща альтернатива, ніж qemu-qdisk.
