创建无需排队的单实例 Runbook

Orchestrator 的一个妙处是它可以自动处理 Runbook 的多实例线程,或者根据您的需要将它们排队。例如,您可以将处理新用户的 Runbook 添加到 Active Directory,对于大公司而言,可能存在多个并发请求,因此可能需要运行 Runbook 的多个实例。或者,您可能有一个更改系统的事务类型的流程,并希望确保在多个用户请求更改时将这些请求排队并按顺序运行,以避免相互之间发生潜在冲突。通过 Runbook 的“属性”对话框中的“作业并发”选项卡可以轻松控制此 Runbook 行为: 默认情况下,该值设置为 1,这意味着一个 Runbook 将运行一个实例,并将所有其他请求排队。如果希望增加此数字,以允许多个并发实例,只需将该数字调大一些即可。相当容易,不是吗? 但是,如果您有一些作业需要作为单一实例运行,但希望在当前作业完成之前忽略所有其他请求,应该怎么办?此情况的一个示例是云服务的自动横向扩展。让我们假定您在使用 Operations Manager 监视一个服务,一个性能警报触发一个 Runbook,开始横向扩展该服务。该横向扩展进程可能需要一些时间,并且在该进程完成之后可能还需要一段时间,以使性能平均数下降到一个可接受的范围(我们称其为“冷却”期间)。无论出于何种原因,都可能会再次触发警报,告诉 Orchestrator 纵向扩展该服务。如果已经有一个 Runbook 正在纵向扩展该服务,您不希望接受任何其他请求,当然也不希望只是将它们排队。您知道您只是想忽略或丢弃任何请求,直到此 Runbook 完成之后为止。那么如何处理此情况? 注意:与任何示例一样,我向您展示的是一个相对简单的视图,在现实世界中,您拥有的可能是一些更为详细的逻辑。不过,我认为通过这个基本示例可以学到这种理念,并在自己的环境中根据情况举一反三。 首先,创建一个新的 Runbook。现在,如果希望避免将 Runbook 作业的请求排队,我们首先需要做的是增加同步作业的数量。在上面所示的对话框中,我们将该数字增加到了 10(这样,如果后续请求快速连发,我们可以处理它们而无需排队)。 接下来,将“初始化数据”活动和“查询数据库”活动拖放到 Runbook 并将它们链接起来。 我们在这里完成的工作基本上是,在 Orchestrator 数据库中查询包含此 Runbook 中“初始化数据”活动的活动 ID 的任何活动作业 (TimeEnded = NULL)。但是我们需要采取迂回的办法完成此工作。在运行时我们无法访问 Runbook 的 ID,因此我们需要使用连接两个表的查询从活动 ID 中推测该 ID,如下图所示: 您可能会注意到,查询中执行了一些奇怪的字符串替换。此问题是由于每个活动的活动…


Azure Automation:使用检查点实现可靠的容错Runbook执行

原文地址:http://azure.microsoft.com/blog/2014/09/03/azure-automation-reliable-fault-tolerant-runbook-execution-using-checkpoints/ 作为Azure Automation Runbook的编写者,我们都希望创建的Runbook在遇到意外问题(如错误、异常、网络问题和崩溃)时能够可靠地执行。Azure Automation可以帮助您实现这一目标。Azure Automation构建于Windows PowerShell工作流基础之上,支持检查点技术,能够保持工作流状态,这样一旦发生中断,随后将可以在中断点或其附近恢复。因此,检查点是一项十分强大的功能,大家势必希望在Automation Runbook中加以利用。有效利用检查点可使您创建的Runbook自动执行长时间运行的流程,顺利访问不同的网络系统,保证不重复那些不应该重复(非幂等任务)或重复起来较为昂贵的操作,并可有计划地中断以纳入手动步骤。 在本文中,我们将探讨在Automation Runbook中使用检查点的原因、场景和方式。大家可以重温一些有关PowerShell 工作流检查点的现有信息,从而帮助理解本文。 什么是检查点? 检查点是Runbook作业的当前状态快照,包括当前的变量值、所有输出及其他可序列化状态信息。每个检查点均将保存到存储中。如果有意或无意导致Runbook挂起,接着重新恢复,工作流引擎将使用最新检查点数据还原和恢复Runbook。 Azure Automation检查点 在Azure Automation中,当您保持一个Runbook作业时,将会创建检查点并将其存储到Azure Automation数据库中。数据库中仅会存储每项作业的最新检查点。各检查点会替换前一个检查点。如果Runbook先挂起而后恢复,最后存储的检查点将用于存储和恢复Runbook。 与PowerShell 工作流(将检查点存储到托管工作流会话的计算机硬盘中)不同,Azure Automation将检查点存储到Azure Automation数据库中。因此,如果运行Runbook的工作进程发生崩溃,那么待该进程重新启动后或其他工作进程可以继续完成作业,使用数据库中的最新检查点恢复作业。 为什么使用检查点? 以下是在Runbook中使用检查点的几点原因: 确保某些操作不重复 检查点对于在Runbook发生崩溃(挂起)后又恢复时保证不重复执行那些不应该重复的操作(非幂等任务)。例如,创建虚拟机后立即核查Runbook检查点,如果Runbook作业挂起后又恢复,则不能创建重复的虚拟机。 保护长时间运行的任务 在现实世界中,错误时常发生。包含多个步骤、长时间运行的任务容易因网络问题、计算机重启或崩溃、超时、电源中断等造成中断。为避免重新执行昂贵任务,需要检查Runbook的检查点,确保任何Runbook重新启动后都不会重新执行任务。 确保长时间运行的Runbook完成运行 Azure Automation具有“公平共享”功能,该功能会卸载运行时间达 30 分钟的所有Runbook,以便其他Runbook继续运行。最终,将会重新加载被卸载的Runbook,完成加载后,将从最后一个Runbook检查点恢复执行。因此,为保证Runbook最终完成,您必须不时添加检查点且运行间隔不得超过 30 分钟。(此论坛文章列举了有关这个问题的一个示例。) 允许计划内中断或手动中断 在某些场景下,您可能希望挂起正在运行的Runbook。例如,挂起Runbook作业等到批准后再继续运行,或者挂起Runbook作业等待修复意外或计划内系统问题。   如何向Runbook添加检查点? Checkpoint-Workflow 活动 Checkpoint-Workflow活动(别名:Persist)是一项标准的PowerShell工作流活动,在Runbook中可用于在某个特定的点创建检查点。在Runbook中发生Checkpoint-Workflow活动的特定点创建检查点。 …Download-UpdatesReboot-VMCheckpoint-WorkflowEmail-TeamCheckpoint-Workflow… -PSPersist活动通用参数 每当调用此活动时,都可以纳入–PSPersist工作流活动通用参数。这将会在活动完成后,立即强制创建检查点。 … Download-Updates Reboot-VM –PSPersist $True Email-Team –PSPersist $True … $PSPersistPreference工作流首选项变量…


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

原文地址:http://blogs.technet.com/b/privatecloud/archive/2013/08/27/automation-service-management-automation-utility-runbook-spotlight-vmm-custom-property-management.aspx 大家好! 如今,项目的复杂度不断攀升,需要满足各种先决条件。这篇文章自动化 – Service Management Automation Runbook 聚焦 – 按优先级启动虚拟机(第 1 部分)就是其中一个实例。按照自动化 – Service Management Automation Runbook 聚焦 – 按优先级启动虚拟机(第 1.5 部分)中所述的方法,我将会通过 VMM 自定义属性重新介绍数据存储概念。在那篇文章中,我说明了创作本文的需求(实际先决条件),并承诺举例说明以下任务: 创建 VMM 自定义属性 更新 VMM 自定义属性值 获取 VMM 自定义属性值 删除 VMM 自定义属性值 删除 VMM 自定义属性 在本文中,我将会履行这项承诺。 示例 SMA Runbook 断开! 以下 PowerShell v3 工作流示例已在 SMA 中实现并测试。每个示例均可从此处进行复制/粘贴,也可从 TechNet Gallery 资源(可在下面找到相应的链接)中提供的 PS1…


自动化 – Service Management Automation – SMA Runbook 入门手册

原文地址:http://blogs.technet.com/b/privatecloud/archive/2013/08/14/automation-service-management-automation-getting-started-with-sma-runbooks.aspx 本文将介绍有关准备使用 Service Management Automation (SMA) 及如何导入未来示例的具体操作信息,并使用两者以便在操作中查看解决方案!应将本文视作您的文章列表的“主要参考资料”,用来充分熟悉和学习 SMA。这些步骤很基础但至关重要,可能会为您的学习过程大有裨益。 启用步骤 以下分步方法用于指导大家完成从下载/配置到测试的整个过程。配置和权限部分最重要,因此无疑将成为以下几节的学习重点。大家可以将其视作“成功启用 SMA 的 6 步方法”。 注意    下面介绍的步骤反映的是当前 System Center 2012 R2 Preview 的体验。如果 GA 版本中出现任何调整,我们必定会更新本文以体现更新后的体验。 步骤 1:下载 SMA 此步骤旨在介绍获取 SMA 的过程。有关详细信息,请参阅我们的首篇介绍性博客文章:自动化 – Service Management Automation 简介。将这篇介绍性文章作为蓝图,收集所有 SMA 数据并进行安装。只需要执行一次操作(或在测试/开发过程中根据需要执行多次),但却是一项重要步骤。 步骤 2:配置您的环境 在环境中准备 PowerShell SMA 的核心利用 PowerShell v3 工作流。配置将因您的特定需求及构建的解决方案而有所不同。在接下来的几篇文章中,我们将围绕自身提供的各项解决方案的相关领域重点介绍我们取得的工作进展。但是,至少大家可能需要在 Runbook Worker 上运行 Enable-PSRemoting(位于特权 PowerShell 控制台中)及解决方案的所有目标端点。 作为指导,下面提供了一些有用的 PowerShell 远程处理链接: PowerShell 远程处理启用…


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

原文地址:http://blogs.technet.com/b/privatecloud/archive/2013/08/29/automation-service-management-automation-runbook-spotlight-virtual-machine-startup-by-priority-part-2.aspx 大家好! 迷你系列第 2 部分的最后一篇(第 4 篇)文章(继 Douglas Adams 之后)终于与大家见面了! 文章结构 下面我们花点时间看看已经讲到了这个系列的哪个部分。我在第 1.5 部分中曾说过,以下是目前发布的 SMA 简介 系列文章集合:https://aka.ms/IntroToSMA 在本集合中,您将会发现第 1 部分、第 1.5 部分和 Utility Runbook 聚焦 – VMM 自定义属性管理(以及其他一些与本迷你系列不存在直接关联的文章)。虽然第 1 部分和第 1.5 部分并非第 2 部分的先决条件,但强烈建议进行阅读。VMM 自定义属性管理文章中所述的功能将第 2 部分得到广泛应用。 下面继续介绍相关内容! 这是 SMA Runbook 聚焦 – 按优先级启动虚拟机迷你系列文章的第 2 部分(共 2 部分)。鉴于我将第 1 部分称为“简单示例”,第 2 部分将深入介绍了一些更加复杂的主题/功能。我们依然会利用 PowerShell v3 工作流。我们依然会从 SMA Runbook 调用工作流。甚至依然会通过 VMM 启动 Hyper-V…


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

原文地址:http://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 背景 以上是简单情况的介绍,下面我们来介绍发布本文的原因 – 阐释相关需求并作为后续文章的必备知识以供参考:自动化 – 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 功能:通过控制 Runbook 流进行测试和故障诊断

当您使用 Service Management Automation(SMA)创建并运行 Runbooks 时,有两个关键任务:授权期间测试 Runbooks,以及在生产环境中运行 Runbook 作业时的故障诊断。在这两种情况下,都需要 Runbooks 来生成适当的信息,以便了解执行期间的情况。幸运的是,PowerShell 工作流作为给 SMA Runbooks 提供动力的引擎,拥有您可以控制的多个信息流,使您在测试及故障诊断时达到最佳效果。在这篇文章中,我将介绍几个关于控制 Runbook 流的概念和最佳实践,从而帮助您调试和排除 Runbooks 故障。 SMA 中的测试 您可以在 SMA Runbook 授权页面中创建 Runbook。该页面中有编辑 PowerShell 工作流代码窗格、查看测试输出窗格和插入活动、Runbooks、全局设置等控件(下图是调试 Runbook 输出的截图)。授权 SMA Runbook 时,您或许想在关键点处进行测试,以便保证其功能按预期运行。启动 Runbook 测试十分简单:只需单击 Test按钮。测试工作启动后会出现输出窗格,来自 Runbook 的大多数流会被写入该窗格中。当然,输入流中的信息和您使用的特定流决定着您能在多大程度上对 Runbook 进行调试。为了帮助解决这一问题,在下一节中我将展示如何控制 PowerShell 工作流所提供的各种流。 控制 Runbook 输出 PowerShell 工作流支持 6 种不同的流,每个流都具有不同目的:包括 Output (输出流)、Progress (进度流)、Warning (警告流)、Error (错误流)、Verbose (冗长流)和…


SMA 功能深入介绍:Runbook 创作

借助于 Orchestrator 2012 R2 的最新 Service Management Automation (SMA) 功能,IT 专业人员和服务管理员现在可以跨越系统和流程自动执行耗时而又容易出错的重复性任务,从而更快地实现其 Windows Azure 包云操作的价值。SMA 之所以能够实现这种价值,完全依靠所谓的 Runbook 概念 – 包含自动执行 IT 和业务流程的逻辑的 PowerShell 工作流。 虽然起初 Runbook 可能看起来有些可怕,但只需要稍微接受一点培训,人们就能轻松掌握这项技术。在这篇博文中,我们将深入介绍 SMA 为帮助您更有效地编写和使用 Runbook 而提供的一些功能,同时还会介绍一些最佳实践和常见问题解决方法,帮助您真正掌握 Runbook、破茧成蝶。如果尚不具备 SMA 和 SMA Runbook 背景知识,请首先查看 SMA 和 Runbook 概念简介文章了解入门信息,然后再继续学习以下内容。   Runbook 生命周期 在深入了解 SMA 提供哪些类型的 Runbook 创建和编辑功能之前,我们首先来探讨一下如何管理 Runbook,从而避免您本人或您的同事意外运行正在创建的半成品 Runbook。SMA Runbook 具有“已发布”版本和“草稿”版本的概念之分。当创建新的 Runbook、导入 Runbook 亦或只是单纯希望改进当前的成品…


使用 Windows 任务计划程序调用计划的 Runbook

本文是我的上一篇文章超酷工具:用于启动 Runbook 的新命令行实用工具的后续内容,在上一篇文章中,我讨论了使用 Web 服务通过命名参数快速启动 Runbook 的方法。现在该将它付诸行动了! Orchestrator 管理员知道 Orchestrator 不是作为一个日程安排工具而设计的。没错,它可以使用“监视日期/时间”活动主动地定期启动新的 Runbook 作业。问题是它有点笨拙。假设我想让一个 Runbook 在每周一的晚上 10:15 运行。下面是我要执行的操作: 在我的 Runook 的开头放置一个“监视日期/时间”活动并将它设置为每小时运行一次,在整点后 15 分钟发生。 创建一个计划(在“全局设置”下),将它命名为“Monday 10-11”,并对其进行设置,以便它在每周一运行,并且唯一允许的一个小时是晚上 10 点到晚上 11 点之间。 向 Runbook 中添加一个“检查日程安排”活动并将其指向刚创建的日程安排。 更改从“检查日程安排”活动到下一个活动的链接条件,以便仅在当前时间符合日程安排要求时才触发下一个活动。 下面是步骤 1 至步骤 4 的屏幕截图: 现在该过程将会提供我所需的结果。“检查日程安排”活动之后的活动将在每周一的晚上 10:15 运行。因此,它的笨拙之处此时就显现出来了: 此 Runbook 是一个监视器,它始终运行,因而始终会消耗策略限制中的一个可用位置 当您有多个以类似方式设置的计划 Runbook 时,它们全都始终运行并消耗您的策略限制。 该 Runbook 将每小时触发一次“检查日程安排”活动。一天 24 小时 x 7 天等于 168(没错,我不得不使用计算器)。…


向自定义活动添加选项菜单配置

昨天,我写了有关如何使用 Visual Studio 调试自定义活动的文章。今天,我将介绍如何向选项菜单添加项目,以获取可以在一个 IP 中跨多个活动使用的可重用配置设置。这通常用于配置连接设置,或用于在多个活动中通用并且您不希望为每个活动反复输入的设置。 使用选项菜单配置的妙处在于,您可以将其用于单级级联依赖关系操作。例如,您可以基于用户对配置所作的选择来更改活动的输入、输出甚至主要功能。在本例中,我将介绍如何添加 ActivityConfiguration 项并使用它改变活动的工作方式。在下一篇文章中,我将介绍在使用命令性方法创建活动时,如何使用该项改变输入和输出。 在我昨天介绍的“Hello World”活动的基础上(在 http://orchestrator.codeplex.com 的 SDK 示例中),我创建了一个名为“Hello World 2”的新活动。还创建了一个名为“HelloWorldConfiguration”的新类,如下所示。 using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Microsoft.SystemCenter.Orchestrator.Integration.Examples.HelloWorld2 {     [ActivityData("Hello World Configuration")]     public class HelloWorldConfiguration     {         private AlterationMethod _alterationType = AlterationMethod.None;         public HelloWorldConfiguration()         {             AlterationType = AlterationMethod.None;         }         public HelloWorldConfiguration(AlterationMethod alterationType)         {             AlterationType = alterationType;         }…