Передісторія
Існує гарне рішення для створення надійного недорогого кластера засноване на DRBD + Proxmox VE. Сторінка в Wiki проекту Proxmox з'явилася 11 вересня 2009-го року і створена вона була CEO компанії Martin-ом Maurer-ом.
Відтоді це рішення стало дуже популярним, і ніхто не підозрював, що у цього рішення є прихований підводний камінь. У документації про це не пишуть, а ті, хто стикався з наслідками цієї проблеми (наприклад, зависання машини при онлайн міграції з одного хосту на інший), списували все на «випадок». Хтось грішив на залізо, хтось на Proxmox, а хтось на драйвери всередині віртуальної машини. Звичайно, хотілося б, щоб DRBD сам повідомляв про свої проблеми, і, якось підсвідомо віриш в те, що він так і робить. Перевіряєш/proc/drbd, бачиш рядок "cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate "і продовжуєш вірити що DRBD не причому.
Одного разу, уважно читаючи документацію до DRBD, я знайшов рекомендацію робити регулярну перевірку DRBD на цілісність, тобто на ідентичність двох нод між собою. Ну, а чому б і ні, подумав я, перевірка зайвою не буде. І тут почалася історія довжиною в цілий рік.
Виявилося, що щотижня в DRBD з'являлися нові блоки out-of-sync. Тобто. дані на двох серверах відрізнялися. Але чому?!
Заміна заліза, оновлення версії DRBD, відключення offload і bonding-а до позитивного результату не приводили, а нові блоки все з'являлися і з'являлися. Аналіз того, які саме блоки виявлялися out-of-sync, призвів до таких результатів:
- часто - swap розділ віртуальної машини з Linux
- рідко - Windows з розділом NTFS на віртуальній машині
- ніколи - ext4 на віртуальній машині з Linux
Це було «цікаво», але відповіді на питання «чому і як це може бути» не давало. Про всі свої вишукування я розповідав у списку розсилки «DRBD Users» (http://www.gossamer-threads.com/lists/drbd/users/25227) і одного разу я отримав відповідь, якої так довго чекав. Lars Ellenberg, один з основних розробників DRBD, розповів, що саме відбувається, і як це перевірити.
Як відбувається запис у DRBD
Загальний випадок:
1) DRBD отримує запит від ОС за запис даних з буфера;
2) DRBD записує дані на локальний блочний пристрій;
3) DRBD надсилає дані другій ноді по мережі;
4) DRBD отримує підтвердження закінчення запису від локального блокового пристрою;
5) DRBD отримує підтвердження закінчення запису від другої ноди;
6) DRBD надсилає ОС підтвердження закінчення запису.
А тепер уявімо собі, що дані в буфері несподівано змінилися і ми отримаємо:
1) DRBD отримує запит від ОС за запис даних з буфера;
2) DRBD записує дані на локальний блочний пристрій;
2.5) дані буфера змінилися;
3) DRBD надсилає дані другій ноді по мережі;
4) DRBD отримує підтвердження закінчення запису від локального блокового пристрою;
5) DRBD отримує підтвердження закінчення запису від другої ноди;
6) DRBD надсилає ОС підтвердження закінчення запису.
І ми тут же отримуємо out-of-sync.
Як же таке виходить? Дуже просто. Буфер може використовуватися програмою для кешування на запис (додаток, у нас, це процес віртуальної машини). У цьому випадку програма може оновлювати дані в буфері, не чекаючи підтвердження запису цих даних на фізичний пристрій або контролер, а у випадку з DRBD це неприйнятно.
Найнеприємніше в усьому цьому те, що для можливості втратити дані не потрібно навіть відключення живлення. Достатньо лише включити кеш на запис.
Як перевірити? Потрібно включити в налаштуваннях DRBD data-integrity-alg і чекати. Якщо ви отримаєте щось на зразок «buffer modified by upper layers during write», то це воно і є. Будьте обережні, якщо DRBD працює в режимі dual-primary, то при включеному «data-integrity-alg» ви тут же отримаєте split brain (про це не написано в документації).
Кешування запису QEMU/KVM
Типово, віртуальні машини у Proxmox VE використовують режим cache = none для віртуальних дисків. Незважаючи на те, що «none» ніби говорить нам «нічого не кешуємо», насправді це не зовсім так. None, в даному випадку, означає не використовувати «host cache», але кеш на запис в блочний пристрій як і раніше використовується. А звідси ми отримуємо проблему з розсинхронізацією блоків в DRBD.
Всього два режими можна вважати надійними при використанні з DRBD: directsync и writethrough. Перший не використовує кешування взагалі, тобто читає завжди безпосередньо з блочного пристрою (це може бути RAID контролер) і пише в блочний пристрої (це може бути RAID контролер) обов'язково чекаючи підтвердження запису. Другий режим використовує «host cache» для читання.
Таким чином, система віртуалізації може стати катастрофічно повільною, якщо ви не використовуєте фізичний RAID з кешуванням за запис і BBU. А якщо ви використовуєте RAID з BBU, то віртуальна машина отримає підтвердження про запис відразу ж після приміщення даних в кеш контролера.
Чому ж ні out-of-sync на ext4
Використання режимів cache = directsync і cache = writethrough є найнадійнішими, оскільки, в цьому випадку, нам не потрібно турбуватися про те, що відбувається всередині віртуальної машини. Але це не єдиний спосіб. Це потрібно враховувати в тих випадках, коли нам недостатньо продуктивності RAID або ж у нас немає RAID взагалі.
Переконатися в тому, що дані вже записані можна не тільки на рівні процесу віртуальної машини, але і всередині VM. Тут ми знайомимося з поняттям barrier, яке передбачає, що файлова система сама знає, коли її потрібно скинути дані з кешу на фізичний пристрій і дочекатися завершення цієї операції. А man mount говорить нам, що «The ext4 filesystem enables write barriers by default». Саме тому ми і не побачимо ніколи out-of-sync на тих областях, де розташована файлова система, що використовує barriers.
Корисні посилання:
— Proxmox и DRBD: pve.proxmox.com/wiki/DRBD
— Out of sync: www.gossamer-threads.com/lists/drbd/users/25227
- Ще про out of sync: forum.proxmox.com/threads/18259-KVM-on-top-of-DRBD-and-out-of-sync-long-term-investigation-results
- Опис параметра cache для kvm/qemu: www.suse.com/documentation/sles11/book_kvm/data/sect1_1_chapter_book_kvm.html
- Ще про кеш: www.ilsistemista.net/index.php/virtualization/23-kvm-storage-performance-and-cache-settings-on-red-hat-enterprise-linux-62.html?start=2
