Jaa


自动化 – Service Management Automation Runbook 聚焦 – 按优先级启动虚拟机(第 1.5 部分)

原文地址:https://blogs.technet.com/b/privatecloud/archive/2013/08/23/automation-service-management-automation-runbook-spotlight-virtual-machine-startup-by-priority-part-1-5.aspx

大家好!

在开始介绍本文的内容之前,我想向持续关注我们的 System Center 2012 R2 Service Management Automation 入门博客文章的广大读者们表示诚挚的感谢。为便于查看,方便大家在一个区域跟踪查看所有文章,我们创建了一个简单的链接供大家使用和分享:

https://aka.ms/IntroToSMA

SMA


背景

以上是简单情况的介绍,下面我们来介绍发布本文的原因 - 阐释相关需求并作为后续文章的必备知识以供参考:自动化 – Service Management Automation Runbook 聚焦 按优先级启动虚拟机(第 1 部分)

在第一篇文章中,我已经基于先前的 Orchestrator 文章(用于完成相同的任务)提供了 SMA Runbook 示例。我将此称为“按优先级启动虚拟机”的“简单”示例。本迷你系列博客的第 2 部分将提供更高级的示例,而且随着复杂度的上升,所需的必备知识也会相应增加。创作本文的意义也在于此。以上是复杂度问题说明…

事实上,之所以采用这种新方法,是为了摆脱使用 Delay start up (seconds)  值(假设实际启动虚拟机时启用 Start-Sleep 操作)。本迷你系列博客的第 2 部分利用更加优雅(因而复杂)的解决方案,同时还使用优先启动组并实际检查 Hyper-V 集成服务状态(与新版 Hyper-V Recovery Manager 在故障转移期间的运行方式极为类似)。

注意鉴于以上原因,应考虑学习第1.5 部分(共2 部分)。


那么,面临哪种新的复杂局面呢?

很简单 使用存储的数据。

与 Orchestrator 极为类似,SMA 没有“状态”(日志中除外,通过 SMA 变量进行操作)概念。毕竟,SMA 是一项用于存储、编译和执行 PowerShell v3 工作流的自动化解决方案。在本迷你系列博客的第 2 部分中,我需要设法访问存储的信息,也就是容器(或云)级 Startup Priority Groups 和虚拟机级 Startup Group 信息。其中,Startup Priority Groups 包含不同 Startup Group 值的总计数;而 Startup Group 值则用于描述每个虚拟机在启动流程中的实际优先级。

换言之:

image

利用 Startup Priority Groups 启动虚拟机的想法源自我所在的团队目前正在开发的最新大型配置流程。该配置流程以 XML 文件为中心,完成各种虚拟机特定数据的存储和检索。请查看事先整理的虚拟机启动优先级 XML 示例:

image

注意本迷你系列博客的第 2 部分将不会使用 XML 数据检索方法,只想确保提供这个示例,以便有人感兴趣时使用。

我们已从虚拟机启动流程的 XML 文件访问这些数据 – 基本上,SMA Runbook PowerShell 工作流已经按照虚拟机启动优先级创建了哈希表以及对应的虚拟机名称阵列。请参阅下面的示例 PowerShell,了解如何使用数据访问 XML 文件完成此操作:

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 InlineScript { $XmlFile = $Using:XmlFile $XML = #This was defined by an Invoke-Command to access an XML file used in the example $StartupPriorityGroups = $XML.Body.Metadata.StartupPriorityGroups if ($StartupPriorityGroups -gt 0) { $StartupGroupList = @{} for( $i = 1; $i -le $StartupPriorityGroups; $i++ ) { $VMList =@() foreach ($VMitem in $XML.Body.VM) { if ($i -eq $VMitem.StartupGroup) { $VMList += $VMitem.Name } } $StartupGroupList.Add($i,$VMList) } Return $StartupGroupList.GetEnumerator() | Sort-Object Name } else {Return $null} }

注意这只是从整项解决方案中摘录的一个代码段,因此  $Using:VariableName 引用的变量不包含作为上方脚本的一部分定义的原始参数。需要注意的是上方8-23 提供的逻辑(这是一种共用方法,我将会在本迷你博客系列的第 2 部分进行阐释)。


明白了,那么新方法是什么?

同样很简单 – 利用 VMM 自定义属性。

这是一个自动化概念,我在先前的 Orchestrator 文章自动化 使用System Center 精心设计Hyper-V 副本实施计划内故障转移中已经针对数据存储和检索进行介绍。我仍然相信,处理这类云和虚拟机特定数据(如果可以成功提取)的最佳位置是 VMM 本身。

因此,上方引用的数据(存储在 XML 文件中)现将存储在 VMM 中并由此进行访问,因为您可以定义和管理 VMM 自定义属性数据。


各位注意,好消息!

我已经将旧解决方案这部分的示例 Orchestrator Runbook 重构至 PowerShell v3 工作流(直接转换为 SMA Runbook)。

在我提供的示例中,大家将能够通过 PowerShell v3 工作流和/或 SMA 执行以下任务:

  • 创建 VMM 自定义属性
  • 更新 VMM 自定义属性值
  • 获取 VMM 自定义属性值
  • 删除 VMM 自定义属性值
  • 删除 VMM 自定义属性

注意我已经针对各项任务创建了PS1 文件示例,并可直接导入SMA 。我发布了另一篇博客文章,专门介绍这些“ Utility Runbook ,并提供了相关  TechNet Gallery 资源供大家下载。

以下是大家等待已久的文章(目前大家甚至不知道它的存在):

自动化 – Service Management Automation – Utility Runbook 聚焦 – VMM 自定义属性管理


介绍完毕!希望通过“第 1.5 部分”的介绍,大家充分了解相关知识,以及为什么我要创作迷你系列第 2 部分(共 4 篇文章)。

如果希望了解更多 SMA 和 PowerShell v3 工作流示例,请务必查阅以下列表(随着提供更多示例不断更新):

有关 SMA 的更多信息、提示/窍门和示例解决方案,请查阅自动化跟踪系列未来发布的其他博客文章!

敬请查阅!