SMA is a great tool for automation of many kind like IT related tasks or as an interface between two systems or business processes you would like to have done automatically. Building workflows is not that easy, but once you get the trick it is not that hard. After you built your workflows, at some point in time you need to troubleshoot, especially if you are dealing with highly available and highly automated environments which run many runbooks / workflows at the same time. Soon you will bump into the terms “job” and “sandbox”, but what is it and how do they relate to each other? Because there is a lot of confusion about these terms, I try to explain how this stuff fits together.
What is a SMA job?
Every time you start a runbook (= workflow) in SMA it generates a job, it is an instance of your workflow. If you open the Windows Azure Portal (WAP) you get a near real time overview of the jobs that are currently running in your SMA infrastructure.
It does not matter if you start the runbook by pressing the Start button in WAP or using Start-SMARunbook Cmdlet the runbook or if you schedule the workflow. In any case an instance of the workflow respectively a job is created.
What is a sandbox?
If you open the event log on a runbook worker you will find an event about the Orchestrator.Sandbox process.
So what is this event all about and what is this sandbox thing? When you start your first job in SMA a new sandbox (Orchestrator.Sandbox ) process is created.
The sandbox is basically a closed space where your SMA jobs live in. This means you have at least one sandbox on each runbook worker. Can you have more than one sandbox on your runbook worker? Yes. There are two cases when a new sandbox is created. The first case is if a new user module has been imported, which would allow to run runbook jobs to use the old module version and the runbooks using the new module version would run in a separate sandbox. The second case is, if the count of TotalAllowedJobs is hit. If you hit this limit a new sandbox will be created, but usually if a job is finished the job should be recycled. What does TotalAllowedJobs mean?
TotalAllowedJobs : The total number of jobs that a Sandbox can process during its lifetime. When this limit is hit, the Sandbox is no longer assigned new jobs and the existing jobs are allowed to complete. After that, the Sandbox is disposed. [Source: Microsoft]
Where can I find this setting? It is placed in the SMA configuration file C:\Program Files\Microsoft System Center 2012 R2\Service Management Automation\Orchestrator.Settings.config\Orchestrator.Settings.config.
So what is this sandbox for? A sandbox is an environment where SMA runs safely SMA jobs. Beth Cooper PM on the Microsoft automation team explained it like this:
A sandbox process is equivalent to a PowerShell runtime and ensures reliability. By putting SMA jobs in sandboxes, if there is an unexpected error in a sandbox, we can kill that runtime process and resume the jobs in a new runtime with a clean state. Sandboxes also allow for different PowerShell module versions since one PS session can have one version and the other can have an updated version.
I think this explains it very well.
What is the relation between jobs and sandboxes?
So this means that there is always an Orchestrator.Sandbox process running on a runbook worker? No. If there is a runbook currently running, then yes, if the runbook / job is finished and no more jobs are running the Orchestrator.Sandbox process is disposed. Therefore no jobs, no Orchestrator.Sandbox process.
What if nested runbooks come into play?
What is a nested runbook? A nested runbook is if you create a Workflow A which calls inside Workflow B and Workflow C.
There are two different methods to call a nested / child workflow. Either you call Workflow B and Workflow C directly from Workflow A or you start these runbooks with Start-SMARunbook Cmdlet. So what is the difference? If you call the runbook directly from Workflow A, like in this picture, ONE SMA job and one sandbox is created.
If you call the child workflows using Start-SMARunbook like in this picture, THREE jobs and one sandbox are created.
I hope you get a better understanding of SMA and I would like to thank Beth Cooper from Microsoft for answering my questions! Additionally to this post, the automation team has published an excellent blog post about nested runbooks in SMA. After reading both posts, you should have the full understanding how things work in SMA / workflows.
One Reply to “SMA – About Jobs & Sandboxes”