在 Azure 上自动化 SQL Server DR 许可以最大程度地节省成本

深入探讨为 SQL Server 灾难恢复环境构建成本优化、有弹性且完全自动化的许可工作流程。

了解更多：如何解决 SQL Server 中的最大工作线程问题

1. 许可框架

有效的许可证管理是优化成本的战略要务。在 DR 环境中，了解“DR”与“AHUB”许可证类型是关键。最好的部分？它们之间的切换是一种无中断、仅元数据的操作，停机时间为零，这是通过 SQL IaaS 代理扩展实现的。

交互式许可证比较

成本影响

要求

自动化标志

程序控制片段

在自动化脚本中使用这些无中断命令来动态切换许可证类型。

2. 架构蓝图

一个简单的脚本不足以完成 30 天的有状态进程。我们需要一个弹性架构，结合多个 Azure 服务来进行检测、编排、操作和状态管理。

解决方案组件信息图

Azure自动化
（检测操作手册）

逻辑应用程序
（编排）

自动化
（行动手册）

表存储
（状态管理）

写入状态
读取状态

3. 检测引擎

IaaS VM 中的故障转移是来宾内事件，对 Azure 活动日志不可见。这意味着我们不能使用简单的基于事件的警报。我们必须使用计划的 Runbook 和强大的“Invoke-AzVMRunCommand”主动轮询 VM 的状态。

专业提示：关键挑战是 IaaS 故障转移不会生成 ARM 事件。我们的检测逻辑必须查询虚拟机“内部”的 SQL 实例，以确定其真正的角色。

检测操作手册

此 PowerShell Runbook 使用托管标识进行身份验证、查询 VM 的 SQL 角色、将其与表存储中的状态进行比较，并触发相应的逻辑应用。

4 & 5. 故障转移和故障恢复工作流程

我们使用两个不同的逻辑应用来编排该流程。故障转移应用程序管理 30 天的延迟，而故障恢复应用程序提供立即恢复，并且最重要的是，取消正在进行的故障转移过程。

故障转移工作流程（30 天延迟）

1. 从检测中收到的 HTTP 触发器。
2. 更新状态表：将状态设置为“FailoverDetected”，存储“LogicAppRunID”。
3. 启动 30 天延迟行动。
4. 延迟后，重新验证表中的状态。
5. 如果状态仍然是“FailoverDetected”：
   • 调用“Set-LicenseToAHUB”运行手册。
   • 更新状态表：将状态设置为“主要”。

故障回复工作流程（立即操作）

1. 从检测中收到的 HTTP 触发器。
2. 立即调用“Set-LicenseToDR” Runbook。
3. 从状态表获取“LogicAppRunID”。
4. 使用“取消运行”操作终止运行中的故障转移逻辑应用程序。
5. 更新状态表：将状态设置为“被动”，清除运行 ID。

6. 部署和成本影响

使用 IaC (Bicep/ARM) 进行部署可确保一致性。监控自动化本身的故障是关键。但真正的故事是节省成本。

交互式成本节省分析

调整滑块以查看通过使用“DR”许可证权益（而不是被动副本的“PAYG”）预计每月节省的费用。

SQL VM 大小 (vCPU)

4 个 vCPU
16 个 vCPU
32 个 vCPU
64 个 vCPU