VMware Data Recovery – VSS application-consistent quiescing

Na, itt már a cím sem egyszerű:-). Szóval adott a VMware Data Recovery (VDR), ami futó virtuális gépekről készít mentéseket. Létrehoz egy pillantképet (snapshot) a virtuális géphez, lemásolja a virtuális lemezek tartalmát (inkrementális mentést végez, csak a megváltozott blokkokat másolja), majd a végén eldobja a pillanatképet.

• Mi itt a gond? Az, hogy az operációs rendszer pufferelheti az írásokat, így lehet, hogy nincs minden változtatás kiírva még a lemezre, tehát nem konzisztens állapotot tárolunk. Ezért érdemes szólni a vendég OS-nek, hogy írjon ki mindent a lemezre, és egy ideig tartsa fel az I/O kéréseket (ezt hívják quiescingnek).
• Mi a további gond? A futó alkalmazásaink sem tudják, hogy most épp egy mentés megy, így (i) ha ők is pufferelnek, akkor nem biztos, hogy ki van írva minden fontos adat a memóriából (pl. adatbáziskezelők vagy címtárak esetén lehet gond), (ii) nem tudják, hogy mentés zajlik, és ezért nem jönnek az I/O kérések, (iii) a mentés vége után nem értesülnek arról, hogy sikerült a mentés (az SQL Server pl. ilyenkor csonkíthatja a tranzakciós naplót).

(A problémáról kicsit részletesebben: Can your VM be restored? VMware and VSS — Part 1)

Ennek megfelelően a VDR különböző konzisztencia szinteket biztosíthat (hivatalos definíciót nem találtam ezekre, talán ez a legjobb: vDR and Quiescing Mechanisms):

• Crash-consistent: legegyszerűbb, olyan állapotban van a fájlrendszer a mentésben, mintha kihúznánk a tápot a gépből. Írások elveszhetnek, az alkalmazások semmit nem tudnak arról, hogy mentés történik.
• File-system consistent: az első feladatokat elvégzi, azaz fájlrendszer szintű írások nem lesznek függőben. De az alkalmazások még mindig nem értesülnek a mentésről.
• Application-consistent: itt már az alkalmazás is értesül a mentés tényéről.

Hogyan lehet ezt megvalósítani? Windows alatt létezik a Volume Shadow Copy Services (VSS), ami pont ezt csinálja. Operációs rendszer szintű támogatás van arra, hogy a mentést végző eszköz értesítést küldjön, és az alkalmazások pedig saját providereket regisztrálhatnak be, ami a konzisztens állapotba hozást elvégzi. Egy rövid összefoglaló a VSS-ről: What is Windows VSS & why you should care, a részletes leírás a Techneten pedig: How Volume Shadow Copy Service Works.

Kezdetben a VMware egy SYNC driver nevű komponenst használt, ami fájlrendszer szintű konzisztenciát garantált, aztán megírták a saját VSS providerüket. Ennek is a különböző verziói még más és mást biztosítottak csak, az aktuális képességeket a VDR Admin Guide-ban lehet megtalálni (2010. július óta már tudja sok esetben az alkalmazás szintűt is, előtte még nem tudta, ezzel kapcsolatban volt elég sok blog bejegyzés).

Most már Windows Server 2008 R2 esetén is támogatott az alkalmazás szintű konzisztencia. Ehhez, ha nem vSphere 4.1-ben hoztuk létre, akkor a virtuális gép konfigurációs paramétereit módosítani kell, hozzá kell adni a disk.EnableUUID = true értéket (lásd admin guide).

Ezeket hozzá is adtam a virtuális gépeinkhez, azonban a VDR mentés így két gépen nem futott le, a tartományvezérlőn és az egyik fájlszerveren.

Fájlszerver

A pontos hiba ez volt a VMware Data Recovery naplójában:

Failed to create snapshot for server, error -3960 ( cannot quiesce virtual machine)

A másik hibajelzés pedig ez:

Cannot create a quiesced snapshot because the create snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine.

A fájlszerver eseménynaplójában ilyen hibák voltak még.

Log Name:      Application
Source:        VSS
Event ID:      12289
Level:         Error
Description:
Volume Shadow Copy Service error: Unexpected error DeviceIoControl(\\?\fdc#generic_floppy_drive#6&2bc13940&0&0#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b} - 0000000000000448,0x00560000,0000000000000000,0,00000000003D8760,4096,[0]).  hr = 0x80070001, Incorrect function.
. 

Operation:
 Exposing Recovered Volumes
 Locating shadow-copy LUNs
 PostSnapshot Event
 Executing Asynchronous Operation

Context:
 Device: \\?\fdc#generic_floppy_drive#6&2bc13940&0&0#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}
 Examining Detected Volume: Existing - \\?\fdc#generic_floppy_drive#6&2bc13940&0&0#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}
 Execution Context: Provider
 Provider Name: VMware Snapshot Provider
 Provider Version: 1.0.0
 Provider ID: {564d7761-7265-2056-5353-2050726f7669}
 Current State: DoSnapshotSet

Meg ilyen:

Log Name:      System
Source:        VDS Basic Provider
Event ID:      1
Level:         Error
Description:
Unexpected failure. Error code: D@01010004

A kapcsolódó VMware KB cikkek és fórumbejegyzések, amik a fenti hibaüzenetekre előjöttek:

• Troubleshooting Volume Shadow Copy (VSS) quiesce related issues
• Unable to take a quiesced VMware snapshot of a virtual machine
• Unable to create snapshots on Windows guest operating systems
• Using a Microsoft or 3rd party software iSCSI Initiator in a VMware environment
• Cannot create a quiesced snapshot because the create snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine.

Az első cikk alapján elkezdtem nézni, hogy hol lehet a hiba, és a VSS írók listázásánál elő is került, hogy nem sikerült a shadow copy létrehozása (a beépített VSS writerek leírása itt van: In-Box VSS Writers):

C:\>vssadmin list writers
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
...

Writer name: 'FSRM Writer'
 Writer Id: {12ce4370-5bb7-4c58-a76a-e5d5097e3674}
 Writer Instance Id: {6a7e82ab-12e3-4c50-a3a6-cd0d11faca81}
 State: [8] Failed
 Last error: Inconsistent shadow copy

A KB cikkeket tovább nézve könnyű volt megtalálni a hiba okát: a virtuális gépen belül fel volt csatolva egy iSCSI kötet, ami nem támogatott, mert a VMware Snapshot Provider annak a helyes kezelését nem tudja garantálni. A további információként megadott VMware SAN System Design and Deployment Guide leírásban is csak ennyi van:

When performing a VMware snapshot, suspend, or resume operation on virtual machines, advanced administrator action or advanced integration is required to coordinate with iSCSI attached volumes to obtain true consistency.

Így megoldásként csak annyit tudtam tenni, hogy kikapcsolom a korábban hozzáadott disk.EnableUUID paramétert, így ezen a virtuális gépen csak fájlrendszer szintű konzisztencia biztosított.

(Megjegyzés: az első hibaüzenet téves hibának tűnik nekem, olyan gépen is láttam ilyet, ahol egyébként lefutott a mentés rendesen. Nem tudom mit akar a VMware a floppy meghajtóval kezdeni:)

Tartományvezérlő

A tartományvezérlőn már kicsit más üzenetek is megjelentek:

Log Name:      Application
Source:        VSS
Event ID:      8229
Level:         Warning
Description:
A VSS writer has rejected an event with error 0x800423f4, The writer experienced a non-transient error.  If the backup process is retried,
the error is likely to reoccur. Changes that the writer made to the writer components while handling the event will not be available to the requester.
Check the event log for related events from the application hosting the VSS writer. 

Operation:
 PostSnapshot Event

Context:
 Execution Context: Writer
 Writer Class Id: {b2014c9e-8711-4c5c-a5a9-3cf384484757}
 Writer Name: NTDS
 Writer Instance ID: {bd3013ea-0171-4b88-8836-e357e76cee7c}
 Command Line: C:\Windows\system32\lsass.exe
 Process ID: 405

Meg ez:

Log Name:      Application
Source:        ESENT
Event ID:      482
Level:         Error
Description:
lsass (405) An attempt to write to the file "\\?\Volume{19aa9060-18f9-11e0-b5dc-056056951ca5}\Windows\NTDS\edb.log" at ... failed after 0 seconds
with system error 19 (0x00000013): "The media is write protected. ". 
The write operation will fail with error -1032 (0xfffffbf8). 
If this error persists then the file may be damaged and may need to be restored from a previous backup.

Itt már az Active Directory címtár adatbázisa esetén volt gond. Mások is tapasztaltak ilyesmit:

• Creating a snapshot with quiesce guest succeedes, but triggers vss-error in eventvwr on server 2008 r2 DC

Elég hosszú a javaslatok sora:

• Újraindítás megoldotta problémát:)
• Győződjünk meg, hogy legfrissebb verziójú VMware Tools van feltelepítve.
• Ellenőrizzük, hogy a VMware Snapshot Provider szolgáltatás létezik-e és nincsen letiltva.
• A VMDK leíróban szereplő disk UUID nem volt azonos azzal, amit a VMware Tools keresett (itt kézzel hackeltek utána valamit, de később úgy tűnt, hogy nem ez a gond).
• Szedjük le, és rakjuk fel újra a VMware Tools csomagot, ez elég sok embernek megoldotta a problémát

Nekem ezek nem oldották meg, bár a kérdéses virtuális gép Server Core volt, a fenti bejegyzésekben viszont teljes szerver szerepelt. Azonban egyébként is van egyéb gond a DC ilyen típusú mentésével:

• Things to consider when you host Active Directory domain controllers in virtual hosting environments

Ez a rész az érdekes:

“Active Directory does not support other methods to roll back the contents of Active Directory. In particular, Active Directory does not support any method that restores a “snapshot” of the operating system or the disk volume the operating system resides on. This kind of method causes a rollback in the update sequence number (USN) used to track changes in Active Directory. When a USN rollback occurs, the contents of the Active Directory databases on the improperly restored domain controller and its replication partners may be permanently inconsistent.”

Úgyhogy egyébként is nagyon észnél kell lenni tartományvezérlő visszaállításánál, tehát egyszerűbbnek tűnt, ha itt is visszakapcsolom a disk.EnableUUID paramétert, és alkalmazás szinten oldjuk meg a mentést (system state mentés készítése rendszeresen).