Знімки стану (Snapshot)

ESX дозволяє нам створювати для віртуальних машин знімки стану Знімок стану – це точка повернення На рис 535 показаний диспетчер знімків (Snapshot Manager) віртуальної машини з двома знімками

Рис 535 Диспетчер знімків стану

Зверніть увагу на перший знімок з імям «Snapshot1_before_VMware_ tools» Його іконка з зеленим трикутником вказує на те, що він був зроблений при працюючій ВМ, із збереженням її памяті Тобто при поверненні на цей знімок ми повернемося в стан працюючої ВМ

Створення знімка стану вельми тривіально У контекстному меню ВМ вибираємо Snapshot Take Snapshot

У вікні (мал 536) нас попросять ввести імя знімка і опис

Рис 536 Майстра створення знімка стану

У разі якщо ВМ включена в момент зняття знімка, то доступні два прапорці: Q якщо верхній прапорець стоїть, то в окремому файлі буде збережено вміст памяті ВМ на момент зняття знімка У такому випадку при відновленні на збережений стан віртуальна машина виявиться рабо-

тающей

Q нижній прапорець вказує VMware Tools, щоб вони спробували забезпечити цілісність даних ВМ «Quiesce» означає, що буде проведена спроба зупинити роботу всіх служб з диском, щоб у момент зняття знімка на диску не було недописаних файлів

Зняття знімка створює точку повернення не тільки для стану і даних гостьовий ОС, але і для конфігурації ВМ Незважаючи на те що ВМ зі знімками можна мігрувати VMotion (але не можна Storage VMotion), майстер міграції перевіряє на коректність тільки поточну конфігурацію ВМ Наприклад, якщо ми перенесли ВМ на інший сервер, а потім відкотили її на якийсь із раніше створених знімків, а на момент цього знімка до неї був підключений диск з приватного сховища – ви зіткнетеся з непрацездатністю ВМ на поточному сервері

В однієї ВМ може бути безліч знімків, притому навіть кілька гілок (рис 537)

Рис 537 Диспетчер знімків стану для ВМ з великою кількістю знімків

Коли ви відкочуватися на якийсь із них, ви втрачаєте стан «You are here», тобто всі напрацювання з останнього знімка стану Якщо ви хочете їх зберегти – робіть ще один знімок, а потім вже відкочується до бажаного

У цій ситуації пряма аналогія із збереженням у компютерній грі – якщо ви завантажуєте якийсь збереження, то поточний стан гри втрачається А повернутися на нього ви можете, лише якщо збережете вже поточний стан перед завантаженням іншого збереження

Кнопка Delete видаляє виділений знімок стану Притому якщо поточний стан ВМ – після цього знімка, то файл-дельта цього знімка не видаляється, а зливається з файлом батьківського знімка На прикладі рис 536:

Q якщо ви видалите останній в гілці знімок (Snap4 або Snap32), то відповідний файл-дельта з диска віддалиться

Q якщо ви видалите будь-який з інших знімків, то відповідний йому

файл-дельта зіллється з файлом-дельта дочірнього знімка Так відбувається тому, що при видаленні (наприклад) Snap3 у нас залишається Snap4 – а він містить всі зміни щодо Snap3, який містить всі зміни щодо Snap22, і т д Виходить, якщо дані Snap3 видалити – Snap4 «зависне в повітрі» Тому файл-дельта Snap3 не видаляється, а зливається з файлом-дельта Snap4 А якщо видалити батьківський знімок верхнього рівня (Snapshot1_before_VMware_tools), то його файл-дельта зіллється з основним файлом диском ВМ

Давайте подивимося на знімки стану з точки зору файлової системи Якщо у нас є ВМ з двома знімками, як на рис 535, то за допомогою утиліти WinSCP ми побачимо наступну картину – рис 538

Серед інших ви бачите два файли, складові диск ВМ, – це файли SQL_Servervmdk і SQL_Server-flatvmdk Однак, крім них, ви бачите ще кілька файлів * Vmdk, а також не розглянуті раніше файли vmsn і vmsd Поговоримо про них

Рис 538 Список файлів віртуальної машини, у якої є знімки стану

Це текстові файли, в яких описані існуючі знімки стану та їх структура Приклад вмісту цього файлу:

.encoding = &quotUTF-8&quot

snapshotlastUID = 2 Це порядковий номер останнього знімка snapshotnumSnapshots = 2 Поточне кількість знімків snapshotcurrent = 2 Який знімок є останнім,

; Тобто після якого йде стан

;You are  here&quot.

snapshot0uid = 1 Це початок опису першого знімка

snapshot0filename = SQL_Server-Snapshot1vmsn Який vmsn файл містить в собі

; Вміст памяті на момент

; Створення знімка snapshot0displayName = Snapshot1_before_VMware_tools snapshot0description = “

snapshot0type = &quot1&quot snapshot0createTimeHigh =  &quot290757&quot snapshot0createTimeLow  = &quot-728460977&quot snapshot0numDisks = &quot1&quot

snapshot0disk0fileName = SQL_Servervmdk Який файл vmdk містить всі

; Зміни на диску починаючи

; З моменту створення цього знімка

snapshot0disk0node = &quotscsi0:0&quot

snapshot1uid = 2 Тут починається опис другого і

; Останнього (в даному випадку) знімка

; Цієї ВМ

snapshot1filename =  &quotSQL_Server-Snapshot2vmsn&quot snapshot1parent = &quot1&quot

snapshot1displayName =  &quotSnapshot2_Before_App_Upgrade&quot snapshot1description = &quot&quot

snapshot1createTimeHigh =  &quot291622&quot snapshot1createTimeLow  = &quot-717423872&quot snapshot1numDisks = &quot1&quot

snapshot1disk0fileName =  &quotSQL_Server-000001vmdk&quot snapshot1disk0node  = &quotscsi0:0&quot

У цих файлах знаходяться вміст оперативної памяті ВМ і конфігурація на момент зняття знімка стану Якщо в цей момент ВМ була виключена або прапорця «зберігати память» при створенні знімка не стояло, то цей файл текстовий, тільки з описом конфігурації ВМ на момент знімка

На рис 537 ви бачите дві пари файлів:

Q SQL_Server-000001vmdk і SQL_Server-000001-deltavmdk

Q SQL_Server-000002vmdk і SQL_Server-000002-deltavmdk

Первинний Vmdk = SQL_Servervmdk

. Vmdk, створений після 1-го знімка = SQL_Server-000001vmdk

. Vmdk, створений після 2-го знімка = SQL_Server-000002vmdk

Файли 00000 # Vmdk є файлами метаданих Приклад змісту:

# Disk  DescriptorFile version=1 encoding=&quotUTF-8&quot CID=26a39a09 parentCID=411fd5ab

createType=&quotvmfsSparse&quot parentFileNameHint=&quotSQL_Servervmdk&quot

# Extent  description

RW   6291456 VMFSSPARSE  &quotSQL_Server-000001-deltavmdk&quot

# The Disk Data Base

#DDB

ddblongContentID =  &quot8d7a5c7af10ea8cd742dd10a26a39a09&quot ddbdeletable =  &quottrue&quot

Звернемо увагу на три поля в Vmdk-файлі:

Q поле CID

Q посилання на parentCID

Q поле parentNameHint

Зверніть увагу Первинний Vmdk не містить поля «parentNameHint », а його

«parentCID »завжди дорівнює« ffffffff»

Суть тут у наступному – знімки стану утворюють ланцюжок, і всі ланки цього ланцюжка залежать один від одного Якщо з якихось причин цілісність ланцюжка порушується, ВМ перестає включатися У такому випадку має сенс вручну перевірити і при необхідності відновити ланцюжок Тобто відкриваємо файл 00000 # Vmdk останнього знімка перед поточним станом У ньому має бути вказаний CID передостаннього знімка У передостанньому повинен бути вказаний CID предпредпоследнего Ітерацію повторити

Подивіться на рис 539

Коли ВМ працює без знімків, її дисками є вихідна пара файлів vmdk Коли ви робите перший знімок стану, ця вихідна пара переводиться в режим тільки читання Тепер змінювати ці файли гіпервізор не може – адже ми зафіксували стан ВМ Тому гіпервізор створює пару 00001vmdk і 00001-deltavmdk – тепер всі зміни на дисках з моменту першого знімка пишуться в них Але потім ми фіксуємо і наступний стан знімком номер 2 Тепер зміни починають писатися в створені гіпервізором файли 00002vmdk і 00002-deltavmdk Але вони не самодостатні, тому файли 00001-deltavmdk і-flatvmdk продовжують використовуватися на читання

Рис 539 Звязок знімків з файлами vmdk

Зверніть увагу: у файли-deltavmdk пишуться всі зміни даних на диску ВМ Як максимум, на диску може помінятися все Тому кожен файл

-Deltavmdk за розміром може дорівнювати номінальному обєму диска ВМ Спочатку файли deltavmdk створюються розміром в один блок VMFS і по одному блоку збільшуються при необхідності Нагадаю, що розмір блоку VMFS ми вказуємо при створенні розділу, і допустимі значення – від 1 (за замовчуванням) до 8 Мб

Існує ще один нюанс, повязаний зі знімками стану Диски ВМ можуть бути розташовані на інших сховищах, ніж її файл настройок Наприклад, файл настройок і системний диск ВМ ми розмістили на одному зберігали ще, де VMFS відформатований з блоком в 1 Мб Нагадаю, що наслідком цього є максимальний розмір одного файлу на цьому розділі VMFS в 256 Гб Припустимо, диск з даними цієї ВМ ми розташовуємо на іншому сховище, з великим розміром блоку, тому що цей диск хочемо зробити розміром в 400 Гб Все добре, це штатна ситуація Однак якщо тепер ми спробуємо зробити знімок цієї ВМ, то нам не дозволять цього зробити – так як файл-deltavmdk для диска з даними цієї ВМ створюється в робочому каталозі, на першому зберігали ще А максимальний розмір цього-deltavmdk дорівнює розміром вихідного диска У моєму прикладі це 400 Гб – а файл такого розміру неможливо створити на VMFS з блоком в 1 Мб

Також якщо розмір диска ВМ близький до максимально можливого на даному VMFS, ми не зможемо створити знімок цієї ВМ Це повязано з тим, що-deltavmkd файл вимагає до 2 Гб додаткового місця за накладних витрат Отримувачі ється, що якщо «розмір диска ВМ» плюс 2 Гб більше, ніж максимальний розмір файлу на цьому розділі VMFS, то знімок не створиться

Зверніть увагу При створенні знімка стану ВМ у нас фіксується стан гостьовий файлової системи і, необовязково, памяті ВМ Однак, крім цього, зберігається і конфігурація ВМ як обєкта ESX (i) Можлива ситуація, коли ви зробили знімок, після цього якось змінили конфігурацію інфраструктури та повязані з цим параметри конфігурації ВМ Наприклад, поміняли імена груп портів і переключили мережеві контролери ВМ на нові групи портів Або перебудували сховища, і CD-ROM віртуальної машини тепер посилається на файл iso по іншому, ніж раніше, шляху Тоді при поверненні на знімок стану віртуальна машина виявиться в некоректній конфігурації Можливо, її не можна буде включити до усунення конфлікту

Плюсами знімків стану є їх суть – створення точки повернення Це, без сумніву, здорово для тестових віртуальних машин Це буває корисно для виробничих ВМ Наприклад, зручно зробити знімок стану перед установкою якогось великого оновлення – у разі виникнення якихось проблем після його встановлення нам легко повернутися на попередній стан Практично всі кошти резервного копіювання віртуальних машин створюють знімок стану на час самої операції резервного копіювання Однак все інше є мінусами, і давайте ці мінуси перерахуємо:

Q якщо ви використовуєте диски ВМ в thick-форматі, то вони відразу займають все

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

Q ВМ зі знімками стану не можна наживу мігрувати на інше храни-

лище за допомогою Storage VMotion

Q простий VMotion працює, проте показує вам попередження виду

«У ВМ є знімки стану Я її мігрувати можу, але не рекомендую » Наслідком цього є те, що перестає працювати DRS для ВМ зі знімками Це буває дуже неприємно, коли відповідальний за ВМ адміністратор зробив знімок стану віртуальної машини для підстраховки перед якимись своїми маніпуляціями Підстраховка не знадобилася, і про знімок благополучно забули Але DRS тепер цю ВМ НЕ мігрує

Q зменшується надійність – для ВМ зі знімками стану вище імовірність

ність якихось проблем саме через наявність знімків Зазвичай ці проблеми виглядають як не запускати після міграції або місячного затемнення віртуальна машина

Q величезною обережності вимагає використання знімків стану на ВМ

з розподіленими додатками (найтиповіший приклад – Active Directory) Якщо не всі, а тільки частина ВМ, що беруть участь в цьому приложе нии (один або декілька контролерів домена), повернулися в минуле –

ми ризикуємо отримати серйозні проблеми аж до повної неработоспо собности всього розподіленого додатку (у разі Active Directory див «USN Rollback») Практично 100%-ва ймовірність таких проблем призвела до того, що Майкрософт не підтримує використання будь-яких механізмів знімків (включаючи знімки ВМ, знімки СГД та резервне копіювання за допомогою програм зняття образів) з контролерами домену Active Directory

Q коли на одному сховищі багато ВМ зі знімками стану, може

зменшитися продуктивність дискової підсистеми за накладних витрат, що виникають внаслідок того, що файли vmdk знімків збільшуються блоками

Q видалення знімків стану в деяких випадках вимагає дуже багато сво-

Бодня місця на сховище

Висновок: для виробничих ВМ знімки стану використовуємо строго по справі і видаляємо відразу після того, як в них пропала потреба

Зверніть увагу У цій книзі під «знімками стану (snapshot)» розуміються «знімки стану (snapshot) VMware» Це застереження робиться з тієї причини, що багато чого з перерахованого невірно для «апаратних» снапшотов систем зберігання Працюють такі снапшоти десь подібним, а десь іншим чином

Джерело: Міхєєв М О Адміністрування VMware vSphere 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*