A visszaállíthatóság háttere

A visszaállíthatóságot úgy valósítja meg a rendszer, hogy egyrészt naplózza az ellenőrzési pontokat, másrészt az eredményeket szerializált formában elmenti. PowerShell esetében ez a diszkre történik, a C:\Users\<userid>\AppData\Local\Microsoft\Windows\PowerShell\WF\PS\default\<SID> helyre alaphelyzetben:

PS C:\> dir C:\Users\ST\AppData\Local\Microsoft\Windows\PowerShell\WF\PS\defaul

t\S-1-5-21-2583457872-4292199810-2893339361-1000\a211af55-8292-4cbf-b279-ced7f1

a0a9c0

 

 

    Directory: C:\Users\ST\AppData\Local\Microsoft\Windows\PowerShell\WF\PS\de

    fault\S-1-5-21-2583457872-4292199810-2893339361-1000\a211af55-8292-4cbf-b2

    79-ced7f1a0a9c0

 

 

Mode                LastWriteTime     Length Name

----                -------------     ------ ----

d----       2015.02.11.     21:57            Def

d----       2015.02.11.     21:57            Meta

d----       2015.02.11.     21:57            Stat

d----       2015.02.11.     21:57            Str

-a---       2015.02.11.     21:57        259 V.xml

Látható, hogy workflow-nként egy GUID alatt egy könyvtárstruktúrában mindenféle adat van elmentve. Annak ellenére, hogy sok fájlnak XML kiterjesztése van itt, nem érdemes nagyon nézegetni ezeket, mert a tartalmuk titkosított.

Hogyan tudjuk megfeleltetni a GUID-okat a workflow-kkal? Valójában, ha workflow-t futtatunk PowerShellből, akkor 2 háttérfolyamatot (job) indítunk, melyeket a Get-Job –IncludeChildJob kpacsolójával futtatva meg is nézhetünk:

PS C:\> Get-Job -IncludeChildJob | ft ID, State, ChildJobs

 

                        Id State                     ChildJobs

                        -- -----                     ---------

                         4 Completed                 {Job5}

                         5 Completed                 {}

A „fő” job az, amelyiknek van ChildJobs  tulajdonsága, ami egy utalás egy vagy több másik jobra. Igazából akkor válik érthetővé, hogy miért kell fő- és aljob, ha nem is egy gépre, hanem többre futtatjuk a workflow-t. Itt direkt eleve job-ként futtatom a workflowt az –AsJob kapcsolóval, hogy még egyszerűbb legyen a vizsgálat:

PS C:\> Test-Checkpoint -AsJob -PSComputerName AzureWin7-1, AzureWin7-2

 

Id     Name            PSJobTypeName   State         HasMoreData     Location

--     ----            -------------   -----         -----------     --------

2      Job2            PSWorkflowJob   NotStarted    True            AzureW...

Ha megvizsgáljuk az aljobokat is, akkor ezt látjuk (kicsit mélyebben van maga a GUID, így ezt kihozom a format-table segítségével):

PS C:\> Get-Job -IncludeChildJob | ft id, location, state, @{n="GUID";e={$_.PSW

orkflowInstance.InstanceID.guid}} -AutoSize

 

Id Location                State     GUID

-- --------                -----     ----

 2 AzureWin7-1,AzureWin7-2 Suspended

 3 AzureWin7-1             Suspended 33944393-698c-4101-837f-cce5483dea97

 4 AzureWin7-2             Suspended 2e6a7b5c-bb7e-4e0e-8feb-d869d8b6a099

Látható tehát, hogy a fő jobnak az a szerepe, hogy a tényleges, célgépenként külön aljobbal futó workflow-kat összefogja. A tényleges munkát az aljobok végzik el, és ezeknél látható az a bizonyos GUID, ami alapján kideríthetük, hogy melyik szál hol tartja nyilván a státuszát a fájlrendszerben:

PS C:\> dir C:\Users\soostibor.STAD\AppData\Local\Microsoft\Windows\PowerShell\

WF\PS\default\S-1-5-21-852094961-2763772764-3754700265-500_EL | ft -AutoSize

 

 

    Directory: C:\Users\soostibor.STAD\AppData\Local\Microsoft\Windows\PowerSh

    ell\WF\PS\default\S-1-5-21-852094961-2763772764-3754700265-500_EL

 

 

Mode         LastWriteTime Length Name

----         ------------- ------ ----

d----  2/11/2015   9:18 PM        2e6a7b5c-bb7e-4e0e-8feb-d869d8b6a099

d----  2/11/2015   9:18 PM        33944393-698c-4101-837f-cce5483dea97

Ezen háttérinformációk után nézzük meg, hogyan élik túl a workflow-k a gép újraindítását.



Word To HTML Converter