Як я зробив віддзеркалення віртуальних машин для Free ESXi

У своїй домашній лабораторії я використовую безкоштовну віртуалізацію від VMware – це дешево і надійно. Спочатку був один сервер, потім у нього почав додавати локальні датасторы, потім зібрав другий сервер… Стандартною проблемою при цьому був переїзд віртуальної машини. Роблячи ці операції вручну, я натрапив на один спосіб, який дозволяв переключити працюючу віртуальну машину на копії флэтов зовсім в іншому місці. Спосіб дуже простий: досить створити снапшот віртуальної машини, скопіювати флэты в нове місце, а потім в дельті перебити посилання на батьківський диск. Гіпервізор не тримає файли метаданих диска відкритими, тому при видаленні снапшота відбувається зливання з новим диском, а старий можна спокійно видаляти. Цей спосіб прекрасно працює без всякого VDDK, який недоступний на безкоштовних гипервизорах і яким користується, наприклад, Veeam в схожій ситуації.
Я без праці автоматизував цю процедуру на python, застосувавши ще кілька трюків, які, при наявності запитів, зможу розкрити в наступних статтях. Трохи пізніше знайшовся добрий чоловік з моїх колишніх колег по цеху, який погодився написати гуй, останній, правда, реалізований на Unity, але для отриманого безкоштовного солюшена, названого нами Extrasphere, це було зовсім не погано. Чим не іграшка для адміна?
Зробивши для своєї домашньої лабораторії міграцію віртуальних машин, я задумався про захист від збоїв. Мінімальною вимогою було резервування працює виртуалки, максимально недосяжним відсутність відставання резервної копії від оригіналу. Не те щоб у мене були такі дані, де втрата 15 секунд критична, по правді сказати, для мене не критично втратити і пару днів, але ось до такого ідеалу хотілося прийти з доробком на майбутнє.
Я не стану наводити аналіз і порівняння доступних рішень – це було давно, нотаток з тих пір не збереглося, пам'ятаю тільки про немислимою тязі до велосипедизму.
На безкоштовному гипервизоре можна зробити найпростіший бекап-агент з Linux машини, до якої чіпляти флэты заснапшоченной віртуальної машини. Таке рішення добре підходить для створення фуловых резервних копій, але абсолютно не годиться для інкрементального бекапу, т. к. рідний CBT не доступний для безкоштовних гіпервізора.
Я подумав, що непогано б самому запив CBT, але як? Чув про Zerto і SRM з їх vSCSIFilter, але скачавши open-source пакет для ESXi не знайшов там нічого схожого — ну хіба що символьне пристрій написати можна. Вирішив поглянути на пристрій hbr_filter, там, на мій подив, все виявилося не надто складно. Три тижні експериментів – і ось я вже можу навісити свій фільтр-драйвер на диск виртуалки і трэкать зміни.
А що якщо не просто трэкать зміни, а відтворити їх? Тут найбільша небезпека в тому, щоб почати писати тонну коду забезпечує канал передачі: тут витягни зміни, спакуй і відправ в мережу, там візьми, распакуй і запиши, а ще й цілісність на кожному кроці потрібно забезпечити і обробку помилок. Без пари агентів здається не обійтися. Досить поглянути на архітектуру Zerto, щоб зрозуміти, що написати і стабілізувати таке рішення в поодинці нереально:
image
Рис. 1. Архітектура Zerto Virtual Replication з рекламного ролика.
Тут я згадав, що ESXi і сам вміє писати по мережі через iSCSI і NFS наприклад. Все що потрібно – це примонтувати таргетный датастор локально. А якщо ще і включити репліку, то можна писати в неї прямо з фільтр-драйвера! Я почав експерименти: спочатку не знав, що робити з включеною реплікою і просто вантажив її з Ubuntu Live CD, через пару-трійку тижнів почала виходити працездатна копія, а потім і навчився передавати зміни на льоту. Причому вихідна машина не отримує підтвердження запису, поки не пройдуть запису в обидва одержувача. Так у мене вийшла реплікація з нульовим відставанням.
Технологія вийшла безагентной, коду мінімум, створення репліки тут же швидко накидав на python. За таку несхожість на класичну реплікацію і простоту я вирішив називати її віддзеркаленням.
Проблему ж включеного дзеркала я вирішив написанням простенького бутлоадера, а щоб від нього хоч якась користь була, на буте він показує останній статус дзеркала, а потім завмирає. У підсумку фактичне споживання пам'яті прагнути до нуля, CPU трохи витрачається при передачі даних, але встановлений агент з'їв би ніяк не менше. Як результат графік дискової активності на запис у дзеркала і вихідної машини ідентичні.
image
Рис. 2. Споживання CPU на вихідній машині з навантаженням.
image
Рис. 3. Споживання CPU на дзеркалі в той же період.
image
Рис. 4. Споживання пам'яті на вихідній машині з навантаженням.
image
Рис. 5. Споживання пам'яті на дзеркалі в той же період.
image
Рис. 6. Дискова продуктивність вихідної машини під навантаженням.
image
Рис. 7. Дискова продуктивність дзеркала за той же період.
Для того, щоб перевірити стан дзеркала я зробив тестові машини, які запускаються як linked-clone від снапшота дзеркала. При бажанні снапшот можна зберігати і потім запускати тести повторно, а якщо тест дуже сподобався, то його можна перетворити на персистентную віртуальну машину вбудованої міграцією, про яку я розповідав на початку повісті.
Локальний таргет – це добре, а що робити, якщо необхідно віддзеркалювати в інший офіс/місто? Навіть якщо канал зв'язку буде досить широким, то тривалість відповіді серйозно просадит продуктивність вихідної машини, ми ж пам'ятаємо, що вихідна машина не отримує підтвердження запису, поки вона не завершиться в обидва одержувача. Рішення тут дуже просте: потрібно розширити інтервал невизначеності запису з нуля до деякого розумного значення. Скажімо, допустимий відставання в 3-5 секунд забезпечать як хорошу схоронність даних, так і пристойну продуктивність. Над цим рішенням я якраз працюю в даний момент. На черзі робота без ssh і консистентним рівня додатків, де теж не обійдеться без трюків, якими я з радістю поділюся.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.