Live migration гостьової системи KVM разом з її сховищем, крок за кроком

Переміщення працюючої віртуальної машини між хостами без спільного сховища звучить як магія, доки ви не зробите це кілька разів. Потім це стає контрольним списком: переконатися, що хости сумісні, підготувати призначення так, щоб гостьова система знайшла все, що очікує, виконати одну команду і знати, коли не пробувати. Ось цей контрольний список для звичайного KVM з libvirt.

Що насправді відбувається під час live migration

З --copy-storage-all libvirt просить QEMU на призначенні створити гостьову систему, потім передає диск потоком, поки гостьова система працює і пише далі. Щойно диск віддзеркалений, пам’ять копіюється раундами: кожен раунд надсилає сторінки, які гостьова система змінила під час попереднього. Коли залишковий набір змінених сторінок стає достатньо малим, щоб надіслати його за дозволений простій, гостьова система ставиться на паузу, останні сторінки і стан пристроїв переходять, і вона відновлюється на призначенні. Пауза зазвичай становить кілька сотень мілісекунд. Мережеві з’єднання виживають, бо гостьова система зберігає свої MAC і IP-адресу, а комутатор дізнається про нове розташування з перших пакетів гостьової системи.

Усе, що може піти не так, є невідповідністю між тим, що очікує гостьова система, і тим, що пропонує призначення. Тож спершу перевірте саме це.

Крок перший: вирішіть, наживо чи холодно

Live migration є правильним інструментом, коли джерело і призначення сумісні, а швидкість запису гостьової системи помірна. Вона є неправильним інструментом, коли все змінюється одразу: інше покоління CPU, інша схема мережі та інший випуск гіпервізора в одному переміщенні. Тоді безпечний шлях холодний: коректно вимкнути гостьову систему, скопіювати диск, визначити її на цілі, завантажити, і залишити джерело недоторканим як rollback.

Primary база даних з дуже високою швидкістю зміни сторінок також може ніколи не зійтися. Виміряйте, перш ніж пробувати:

virsh domdirtyrate-calc <guest> --seconds 5
virsh domstats <guest> --dirtyrate

Крок другий: перевірте сумісність CPU

Модель CPU гостьової системи має існувати на призначенні. Якщо гостьова система використовує host-passthrough, CPU обох хостів мають фактично збігатися. Порівняйте визначення гостьової системи з хостом призначення:

virsh dumpxml <guest> > guest.xml                       # on the source
xmllint --xpath '//cpu' guest.xml > guest-cpu.xml
virsh hypervisor-cpu-compare guest-cpu.xml              # on the destination

identical або superset означає «вперед». incompatible означає або змінити гостьову систему на іменовану модель CPU, яку підтримують обидва хости (при її наступному перезавантаженні), або перенести її холодно.

Крок третій: підготуйте мережу призначення

Кожен bridge, або VLAN на bridge, до якого під’єднані інтерфейси гостьової системи, має існувати на призначенні з тим самим іменем і нести ті самі VLAN на uplink:

virsh domiflist <guest>      # on the source: which bridges
ip -br link show type bridge # on the destination: do they exist?

Відсутній bridge чисто провалює міграцію на старті. Bridge, який існує, але сидить на uplink без потрібного VLAN, мігрує успішно і залишає гостьову систему недосяжною, що гірше. Перевірте також сторону комутатора.

Крок четвертий: підготуйте сховище призначення

Призначенню потрібне місце, куди ляже диск, за шляхом, яким libvirt керує як пулом сховища:

virsh pool-define-as images dir --target /var/lib/libvirt/images
virsh pool-start images && virsh pool-autostart images

Для більшості схем libvirt створює цільовий образ сам. Для незвичних створіть його заздалегідь з точно таким самим віртуальним розміром і форматом, як джерело:

qemu-img info --output=json /var/lib/libvirt/images/<guest>.qcow2   # note virtual-size
qemu-img create -f qcow2 /var/lib/libvirt/images/<guest>.qcow2 <virtual-size>

Крок п’ятий: мігруйте

З хоста-джерела, з доступом по ключу SSH до призначення від імені користувача libvirt:

virsh migrate --live --persistent --undefinesource \
  --copy-storage-all --auto-converge --verbose \
  <guest> qemu+ssh://<destination>/system

• --live тримає гостьову систему працюючою.
• --copy-storage-all віддзеркалює весь диск. (Існує --copy-storage-inc для дисків, базовий образ яких уже є на призначенні.)
• --auto-converge трохи пригальмовує CPU гостьової системи, якщо пам’ять змінюється швидше, ніж її можна надіслати, тож навантажені гостьові системи все одно завершують.
• --persistent і --undefinesource переносять визначення разом з гостьовою системою, щоб вона не з’явилася знову на старому хості при наступному перезапуску.

Ми використовуємо прямий шлях міграції, а не --tunnelled, коли копіюється сховище. Поки вона виконується, стежте за прогресом з другого термінала:

virsh domjobinfo <guest>

domjobinfo показує залишок даних, швидкість зміни сторінок і очікуваний простій. Якщо вона явно не сходиться, virsh domjobabort <guest> зупиняє завдання і залишає гостьову систему працюючою на джерелі, недоторканою.

Крок шостий: перевірте після прибуття

Перевірте ззовні гостьової системи:

virsh list --all                      # running on the destination only
virsh domblklist <guest>              # disk at the expected path
virsh domifaddr <guest> --source arp  # address visible on the network

Якщо гостьова система є балансувальником або реплікою бази даних, підтвердьте, що вона відновила свою роль (стан VRRP, потоки реплікації), а не припускайте цього.

Лише після цього видаляйте старий образ диска з джерела, або, ще краще, тримайте його до наступного циклу обслуговування.

Ваш контрольний список

• Наживо чи холодно вирішено свідомо, зі швидкістю зміни сторінок, виміряною для навантажених гостьових систем.
• Модель CPU порівняна з хостом призначення.
• Кожен bridge і VLAN присутні на призначенні, включно з uplink комутаторів.
• Пул сховища на призначенні, достатньо вільного місця і заздалегідь створений образ там, де схема цього потребує.
• Команда migrate виконана з копіюванням сховища і auto converge, під наглядом domjobinfo.
• Гостьова система перевірена ззовні, а копія на джерелі збережена, доки ви не впевнені.

Якщо ви хочете переміщувати гостьові системи, не вимикаючи їх, або потребуєте шляху з вашого поточного гіпервізора, ми радо допоможемо.

cta: Поговоріть з інженером

Related

• /what-we-do/data-web/live-migration-hypervisor-exits/
• /what-we-do/storage-compute/private-cloud-olvm/
• /what-we-do/network/layer-2-extension/