Freigeben über

Automation–Service Management Automation Runbook Spotlight–Virtual Machine Startup by Priority (Part 1)

  • Artikel

Hello Readers and Viewers!

By now, especially if you are reading this, you likely have seen the following blog posts:

If not, I highly recommend you take some time and review the introductory content provided. The content in this blog post mini-series requires prior installation and/or knowledge of Service Management Automation (SMA), so those posts are pretty valuable, and actually should be considered pre-requisite materials.

SMA_thumb[4]

What’s This Post All About?

This is Part 1 (of 2)  in my mini-series for the SMA Runbook Spotlight on Virtual Machine Startup by Priority. Originally this was just going to be a single post with a simple example for “Virtual Machine Startup by Priority” leveraging PowerShell v3 Workflow and SMA. Then I discovered a slightly more complex (and elegant) way to accomplish the same task – So why not provide both examples as stepping stones from Orchestrator to SMA and PowerShell v3 Workflow?

That is right, like Jim, this blog post (as well as part 2) will not only contain new SMA/PSv3 Workflow examples but also the bridge from Orchestrator to SMA through the example itself.

Remember this post? Automation–Orchestrator Runbook Spotlight–Virtual Machine Startup by Priority

If not, check it out, because what comes next will take that example from Orchestrator to SMA…

On With the Example!

First things first - as I stated above, we need to get some pre-requisite stuff out of the way. The following will cover the specific configuration items needed to get this example up in running by leveraging the key steps outlined in the Automation–Service Management Automation–Getting Started with SMA Runbooks.

Ensure Your SMA Environment is Up and Available

Make sure you have SMA installed.  If you haven’t already, refer to our initial intro blog post for more information on that:Automation–An Introduction to Service Management Automation, then come back.

Configure Environment Specific Settings for Starting VMs in VMM from SMA

Because access to VMM will be via PowerShell Remoting, there are some simple pre-requisite steps that need to be taken care of (as well as some example specific configurations for a VMM Cloud and VM Startup Delay):

  • Prepare VMM and SMA for the Runbooks: Go here https://technet.microsoft.com/en-us/library/hh849694.aspx to figure out if PSRemoting will need to be configured, and if so, how to configure it on both the SMA and VMM systems. This was briefly covered in the Automation—Service Management Automation – Getting Started with SMA Runbooks post.
  • Create a Cloud in VMM with a set of VMs to Start: Just like in the Orchestrator example, this example solution depends on VMs in a Cloud. Create a cloud and add some VMs, the Cloud Name and its VMs will be needed in the example below.
  • Update the “Delay start up (seconds)” Values for each VM: Just like in the Orchestrator example, this example solution depends on the “Delayed Start” value for each VM as the “Startup Priority”. Update each VM in the created Cloud with the desired “Delayed Start” value.

Download the Example SMA Runbooks for Virtual Machine Startup by Priority (Part 1)

The example Runbooks can be found here (TechNet Gallery contribution):

SMA Example - Virtual Machine Startup by Priority (w/PowerShell v3 Workflow)
 BC-DLButtonDark
Download this ZIP and extract the PowerShell files to a location accessible by the Windows Azure Pack (WAP)/SMA console for import. The import process is outlined below.

Validate the Connection to VMM via PowerShell Remoting

The account used for the connection to VMM and the Startup of VMs needs to have the appropriate rights to do so. The connection from SMA to VMM using PowerShell Remoting also needs to be validated.

A simple way to validate rights and connectivity for the account being used, is to make a similar connection to VMM with a remote Invoke-Command. Execute a simple script within PowerShell ISE from the SMA Runbook Worker machine to validate the necessary rights (see example):

001 002 003 004 005 006 007 008 009 010 011 $cred = Get-Credential $VMMServer = "VMM01" Invoke-Command -ScriptBlock { param($VMMServer) Import-Module virtualmachinemanager Get-SCVMMServer -ComputerName $VMMServer } -ComputerName $VMMServer -Credential $cred -ArgumentList $VMMServer

Note Because SMA leverages PowerShell v3 Workflow the Invoke-Command call will need to change to an InlineScript call.

Connection to and specific VMM Server information should be seen if the test was successful – see the following example [successful] output:

image

Import the Runbooks into SMA

If you have any questions on this process, follow the details outlined here in Step 5:Automation—Service Management Automation – Getting Started with SMA Runbooks .

Once imported, a series of (3) Runbooks related to to this project should be visible within the AUTOMATION section of the WAP/SMA console. Validate the following Runbooks can be seen (they may span across pages so you may have to click page 2, 3, etc. to see all Runbooks).

image

Reconfigure and Test the Runbooks

The final step is to reconfigure the Runbook variables to match your environment and test the example solution within the WAP/SMA console. If you would like more information on executing SMA Runbooks in WAP/SMA, further detail can be found here in Step 6: Automation—Service Management Automation – Getting Started with SMA Runbooks post.

Overview of the SMA Runbooks

The following section will outline each of the Runbooks included in this example solution, and how they compare to their Orchestrator counterparts.

Start-VMs-by-Priority

This is the top process level Runbook that is used to execute the entire process.

  • Sets the variables for the execution of the entire process
  • Gathers a list of VMs from the identified VMM Cloud (calls Get-Cloud-VMs)
  • Starts the list of VMs (calls Start-VMs passing in the VM list)
  • Gather and output overall VM Status

 

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 workflow Start-VMs-by-Priority { <# Project Name: Start VMs by Priority Runbook Name: Start-VMs-by-Priority Runbook Type: Process Runbook Tags: Type:Process, Proj:Start VMs by Priority Runbook Description: Process Runbook for the "Start VMs by Priority" Project Runbook Author: Charles Joy & Jim Britt Runbook Creation Date: 06/19/2013 #> $CloudName = "Primary Cloud" $PSCredName = "Contoso Creds" $VMMServer = "VMM01" $AllRunning = 0 $VMStartResult = "" $NotRunning = "" $VMList = Get-Cloud-VMs -CloudName $CloudName -PSCredName $PSCredName -VMMServer $VMMServer $VMDataItems = Start-VMs -CloudName $CloudName -PSCredName $PSCredName -VMList $VMList -VMMServer $VMMServer ForEach ($VMData in $VMDataItems) { $VMDataArray = $VMData.Split(':') $VMName = $VMDataArray[0] $VMState = $VMDataArray[1] if ($VMState -ne "Running") { $AllRunning += 1 $NotRunning += $VMName + "," } } if ($AllRunning -gt 0) { $VMStartResult = "$CloudName VMs Not Running: " + $NotRunning.Substring(0,$NotRunning.Length-1) } else { $VMStartResult = "All VMs in $CloudName are Running"} $VMStartResult }

Note One thing to keep in mind, the “Contoso Creds” above is an SMA Credential Variable. Variables (credential or otherwise) are located and created in the RESOURCES section within the AUTOMATION area of the portal. SMA credential variables enable you to create and store PowerShell credential objects as connections to resources in your environment. These can then be referenced by name (as we did above) and leveraged throughout your Runbook execution without hard coding or prompting.

image

Process level Runbooks in SMA function the same as they do in Orchestrator. They are still top level Runbooks that invoke all the subroutine Runbooks. They essentially control the flow of Runbook execution. Take a look at the following post where process level Runbooks are detailed as part of our best practice series: Automation–System Center 2012 – Orchestrator Best Practice Series–Naming Conventions.

Orchestrator Compare / Contrast

The idea for this SMA Runbook originally came from the Automation–Orchestrator Runbook Spotlight–Virtual Machine Startup by Priority blog post and related Orchestrator example. As can be seen from that post, while the look is different, the functionality is the same. So you don’t have to jump back and forth between posts, here is a look at Orchestrator Runbook for this same process level portion (Start-VMs-by-Priority) of this SMA solution example:

image

Note The highlighted portion of the above SMA Runbook (PowerShell script) would represent variables that would be defined in the Global Settings section within Orchestrator.

Just like Orchestrator, these variables are used throughout the execution of the SMA Runbooks. Due to the nature of SMA (PowerShell v3 Workflow) these variables are simply defined here in the process level Runbook and passed as needed to the subroutine Runbooks. Also, much like Orchestrator, these variables can be stored like Global Settings, but for SMA they are stored in the RESOURCES section within the AUTOMATION area of the portal. This example simply leverages one SMA Credential Variable and no other SMA Variables – usage of the SMA Variables is up to you based on your solution requirements.

Get-Cloud-VMs

This subroutine Runbook gathers a list of VMs based on an identified VMM Cloud.

  • Consumes parameters from the process Runbook to provide connection info: VMM Server and the PS Credential Name (to be used with the SMA Credential Variable)
  • Consumes parameter from the process Runbook to provide the VMM Cloud Name
  • Connects to and queries VMM for a list of VMs based on the VMM Cloud Name consumed
  • Returns an array of VMs based on the VMM Cloud Name consumed

 

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 workflow Get-Cloud-VMs { <# Project Name: Start VMs by Priority Runbook Name: Get-Cloud-VMs Runbook Type: Sub-Runbook Runbook Tags: Type:Sub, Proj:Start VMs by Priority Runbook Description: Sub-Runbook for the "Start VMs by Priority" Project Runbook Author: Charles Joy & Jim Britt Runbook Creation Date: 06/19/2013 #> param( [string]$VMMServer, [string]$CloudName, [string]$PSCredName ) $PSUserCred = Get-AutomationPSCredential -Name $PSCredName $VMList = InlineScript { Import-Module virtualmachinemanager $Cloud = Get-SCCloud -Name $Using:CloudName -VMMServer $Using:VMMServer $VMList = Get-SCVirtualMachine -Cloud $Cloud | Select Name Return $VMList.Name } -pscomputername $VMMServer -psCredential $PSUserCred $VMList }

Orchestrator Compare / Contrast

The highlighted portion of the below process level Orchestrator Runbook represents the scope of this subroutine level portion (Get-Cloud-VMs) of this SMA solution example:

image

Start-VMs

This subroutine Runbook takes a list of VMs and starts them based on their specific VM configuration.

  • Consumes parameters from the process Runbook to provide connection info: VMM Server and the PS Credential Name (to be used with the SMA Credential Variable)
  • Consumes parameter from the process Runbook to provide the VMM Cloud Name
  • Consumes parameter from the process Runbook to provide the list of VMs
  • Connects to VMM and Starts the VMs based on the configured “Delay start up (seconds)” per VM
  • Returns an array of VMs and their status based on the executed Start commands per VM

 

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 workflow Start-VMs { <# Project Name: Start VMs by Priority Runbook Name: Start-VMs Runbook Type: Sub-Runbook Runbook Tags: Type:Sub, Proj:Start VMs by Priority Runbook Description: Sub-Runbook for the "Start VMs by Priority" Project Runbook Author: Charles Joy & Jim Britt Runbook Creation Date: 06/19/2013 #> param( [string[]]$VMList, [string]$VMMServer, [string]$CloudName, [string]$PSCredName ) $PSUserCred = Get-AutomationPSCredential -Name $PSCredName $VMStatus=@() ForEach -Parallel ($VM in $VMList) { $VMReturnData = InlineScript { Import-Module virtualmachinemanager $Cloud = Get-SCCloud -Name $Using:CloudName -VMMServer $Using:VMMServer $VMName = $Using:VM $VMData = Get-SCVirtualMachine -Name $VMName -Cloud $Cloud if ($VMData.Status -ne "Running") { $VMDelayStart = $VMData.DelayStart Start-Sleep -S $VMDelayStart $VMStartReturn = Start-SCVirtualMachine $VMData $VMStartReturn.Status } else { $VMData.Status } } -psComputerName $VMMServer -psCredential $PSUserCred $Workflow:VMStatus += $VM +":"+ $VMReturnData.Value } Return $VMStatus }

Orchestrator Compare / Contrast

Thesubroutine level Orchestrator Runbook below represents the subroutine level portion (Start-VMs) of this SMA solution example:

image

Example Solution VM Delay Start Up (seconds) Configuration Screen Captures (from VMM Console):

While the following screen captures originally came from the Automation–Orchestrator Runbook Spotlight–Virtual Machine Startup by Priority blog post, they are directly related to the “Update the “Delay start up (seconds)” Values for each VM” pre-requisite item above, and thus are provided for convenience here:

VM - spftest03 (Priority 3):

VM - spftest02 (Priority 2)

VM - spftest01 (Priority 1)

That’s it!  I hope this post has provided you with a helpful overview of another end-to-end example solution in SMA and how it compares to what could also be accomplished in Orchestrator. Thanks for taking a look!

Oh, and if you want more examples for SMA and PowerShell v3 Workflow, be sure to check out this list (to be updated as more examples are provided):

And for more information, tips/tricks, and example solutions for SMA, be sure to watch for future blog posts in the Automation Track!

enJOY!

Comments