#RUN BOOK TEMPLATE CODE#
#RUN BOOK TEMPLATE PDF#
1.2 Install LaTeX (TinyTeX) for PDF reports.1.1 Use a Pandoc version not bundled with the RStudio IDE.
Write-output ("The failover type parameter is $RecoveryPlanContext") $ErrorMessage = "Connection $connectionName not found." "Īdd-AzureRmAccount -ServicePrincipal -TenantId $servicePrincipalConnection.TenantId -ApplicationId $servicePrincipalConnection.ApplicationId -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint "Logging in to Azure using $connectionName. $servicePrincipalConnection=Get-AutomationConnection -Name $connectionName # Get the connection "AzureRunAsConnection " Write-Output ("This is an unplanned failover") Write-Output ("This is a planned failover") Write-Output ("This is a cleanup after test failover") If some unexpected value is found, the runbook will exit. There is an if statement to look for cleanup, and if that’s not the value, a switch statement checks $RecoveryPlanContext.FailoverType to see what the scenario is. My template has 4 functions, one for each of the above 4 scenarios. Once my script sees that task it runs a cleanup function.
The runbook still expects a parameter you are prompted to enter a value, so I enter “cleanup”. finding PIPs used by VMs before the VMs and their NICs are deleted). The runbook will typically be executed before the cleanup (some tasks must be done before VMs are removed to make scripting easier, e.g. So what I’ve come up with is a way to tell the runbook that I want to do a cleanup. But what happens if I run a test, am happy with everything and run a cleanup task? Guess what … our recovery plan does not execute in reverse order, and the runbook is not executed. That would be useful in all kinds of failover, including a test failover. This machine could be a jump box, enabling remote access into that machine, and from there we can jump to failed over machines. Let’s assume that I use a runbook to start up some machine(s) during a failover. However, there is as much value in dealing with FailoverDirection, because the runbook can be used to orchestrate a failback. My template currently only queries for FailoverType, because my goal was to automate failover to Azure. ResourceGroupName: The name of the resource group that the failover VMs are in.VmMap: An array listing the names of the VMs included in the runbook.FailoverDirection: primary or secondary are the destinations.FailoverType: test, unplanned, or planned.Some of the interesting values we can query for are: The parameter has multiple attributes, as documented by Microsoft here. When an ASR executes a runbook it passes some information into the script via this parameter. They key to the magic is a parameter in the runbook called $RecoveryPlanContext. That last one is tricky, but I’ll come back to it. I needed to write a runbook for ASR recently and I found that I needed this runbook to be able to work differently in different scenarios: This allows us to do virtually anything inside of Azure during a failover or failback. This can be a basic ordering of virtual machine power-up and power-down actions, but we can also inject runbooks from Azure Automation. I’m sharing a template PowerShell-based Azure Automation runbook that I’ve written, to enable advanced automation in the Recovery Plans that can be used in Azure Site Recovery (ASR) failover.ĪSR allows us to orchestrate the failover and failback of virtual machines.
0 kommentar(er)
