机器学习+在线迁移=Azure复原能力UP

2018 年 12 月 18 日 微软研究院AI头条

编者按：微软Azure团队一直努力为企业的云平台使用提供更好的服务。借助于微软亚洲研究院软件分析组最新的磁盘故障预测和节点故障预测的两项研究成果（论文见文末），Azure团队能够更好地利用机器学习和在线迁移技术来主动地提前解决Azure可能出现的问题。

本文编译自微软研究院博客文章“Improving Azure Virtual Machine resiliency with predictive ML and live migration”

微软Azure团队致力于确保用户部署在Azure上的业务得以持续可靠地运行。为了优化Azure的可靠性，他们和微软亚洲研究院合作，利用机器学习来预测潜在的故障，并使用在线迁移技术提前缓解故障的影响。

自2018年初以来，Azure一直采用在线迁移技术来应对各种各样的故障场景，比如硬件故障、机架维护和软件/BIOS更新等常规操作过程中出现的错误等。借助在线迁移，Azure能够从容处理故障，并将故障的影响降低了50％。

尽管如此，想要进一步拓展在线迁移的应用领域，仍需要探究如何利用系统中的有效预测信号来挖掘在线迁移的用武之地。基于集群管理系统的各种监控数据，微软研究员实现了基于机器学习的故障预测模型，通过与自动在线迁移技术相结合，该故障预测模型被应用在了磁盘故障、IO延迟和CPU频率异常等多种硬件故障情况的处理中。

微软Azure团队与微软亚洲研究院联袂打造的高精度故障预测的机器学习模型，能够在出现故障迹象之前就把正在运行的任务从“有风险”的机器上迁移出去，这也就意味着在Azure上运行的虚拟机比底层硬件还要可靠。

利用这个模型，在线迁移对虚拟机的影响被控制到了最低。从客户的反馈来看，虚拟机在线迁移从未引发任何问题。在线迁移的过程中，虚拟机的状态和所有网络连接能够都保持正常。迁移的最后阶段，虚拟机会暂停几秒，继而迁移至新的主机。只有极少量对性能敏感的任务可能会在虚拟机暂停前的几分钟内受到轻微影响。

硬件故障预测

由于磁盘故障是导致硬件故障的主要因素，所以Azure团队最初主要专注于磁盘故障预测。在Azure这样复杂的系统中预测磁盘故障是十分困难的，需要克服多种挑战。磁盘预测模型必须考虑到下面一些因素：

• 多种多样的系统状态信号：例如客户虚拟机性能降级、主机操作系统行为以及磁盘状态的监测信号

• 不同的客户工作负荷：不同工作负载下的磁盘故障症状不同。磁盘操作密集型的任务中，磁盘故障可能在刚侦测到早期症状后就立即发生；而在磁盘操作强度相对较低的节点上，可能在症状出现后的几周或几个月内都不发生故障。

• 不同的磁盘制造商：不同制造商的磁盘行为和故障模式不同，甚至相同厂商的不同磁盘型号之间都会有差异。

• 样本极不均衡：通常，每10,000个节点中只有1个节点会出现磁盘故障迹象。经典的机器学习方法并不能很好地应对这种极度不均衡的情况。

为了应对这些挑战，Azure团队设计了一种创新的方法，既可以全面地收集各种信号，又可以灵活地应对故障误报。

首先，同时运用系统级和磁盘层级的监测数据。系统层级包括主机IO性能数据和系统中各类事件数据，磁盘级信号则利用S.M.A.R.T（标准磁盘遥测数据标准）数据。研究人员综合利用多种特征工程方法从异构信号中学习故障模式。

其次，将问题视为排序问题而非分类问题。在对磁盘故障概率进行排序以后，研究人员利用优化模型挑出N个故障可能性最高的磁盘（N的大小由最优成本/收益权衡来确定）。

第三，设计排序方法时把信号的异质性和相关性考虑进去。这样就降低了模型训练的复杂程度，并提高了验证方法的可用性。

我们来看一个今年10月30日在Azure上发生的一个真实案例：

• 01:59:26，系统预测到磁盘存在很高的故障概率，此故障可能会影响该节点上运行的5个虚拟机。

• 02:10:38，使用在线迁移，将这5个可能被影响的虚拟机移出节点。“断电”时间范围在0.1秒至1.6秒之间。

• 将节点迁出，进行详细诊断。

• 06:20:34，该节点未能通过磁盘压力测试，被送去维修。

这一案例中，借助磁盘故障预测技术，客户在Azure上运行的任务得以免受影响。

想要了解更多有关机器学习模型的应用细节，请参阅文末关于磁盘故障预测[1]和节点故障预测[2]的论文。

在线迁移的幕后工作

概括来说，在线迁移包含三个主要阶段：迁移前准备、过渡和中断。

在迁移前准备阶段，在线迁移协调器负责选择最佳目标节点，导出虚拟机配置并进行授权设置。在这个阶段，虚拟机仍在源节点上保持运行，资源的可用性或性能也不会受到影响。

在过渡阶段，内存和磁盘状态从源节点传输到目标节点；虚拟机仍在运行，但由于处理额外的工作，性能可能会有轻微下降。过渡阶段的时长取决于虚拟机的大小（特别是内存和磁盘）以及内存的变化率。过渡时长通常在“分钟”的量级——对于我们最常见的虚拟机规模，过渡阶段时长范围在1分钟至30分钟。

在线迁移的最后阶段是中断。一旦过渡阶段结束，源节点和目标节点上的虚拟机都将处于挂起状态。在启动目标虚拟机之前，Azure在线迁移程序还会传输其它Azure特有的状态信息。中断阶段的时间长度取决于虚拟机暂停后仍然有待传输的状态信息数量。与前文案例中的情况相同，中断阶段通常能控制在5秒以内。

局限性

利用在线迁移技术，Azure服务的可靠性已经取得了显著提升，但Azure团队始终深知还有更多工作要做，他们正逐步增加在线迁移的应用情境，并不断扩展它的技术能力。目前，在线迁移尚不支持以下情境：

• 硬件退役

• 专用计算（包括高性能计算[3]、GPU优化虚拟机[4]、内存优化虚拟机[5]和存储优化虚拟机[6]）

• Legacy A系列虚拟机[7]

• Cloud Services所使用的虚拟机[8]

虚拟机可用性对于客户在Azure平台的使用体验至关重要，而机器学习和在线迁移技术也是Azure能否实现对用户的服务承诺的关键所在。Azure团队使用在线迁移可以更透明地进行平台更新，并复原各种硬件和软件故障，机器学习的应用提升了在线迁移的有效性。在线迁移还存在一些技术上的局限性，Azure也一直在持续努力地进行改进。

参考文献

1. Improving Service Availability of Cloud Systems by Predicting Disk Error. Yong Xu, Kaixin Sui, Randolph Yao, Hongyu Zhang, Qingwei Lin, Yingnong Dang, Peng Li, Keceng Jiang, Wenchi Zhang, Jian-Guang Lou, Murali Chintalapati, Dongmei Zhang

USENIX ATC 2018 | July 2018

https://www.microsoft.com/en-us/research/publication/improving-service-availability-cloud-systems-predicting-disk-error/

2. Predicting Node Failure in Cloud Service Systems. Qingwei Lin, Ken Hsieh, Yingnong Dang, Hongyu Zhang, Kaixin Sui, Yong Xu, Jian-Guang Lou, Chenggang Li, Youjiang Wu, Randolph Yao, Murali Chintalapati, Dongmei Zhang

ESEC/FSE 2018 | November 2018

https://www.microsoft.com/en-us/research/publication/predicting-node-failure-in-cloud-service-systems/

3. 高性能计算：

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-hpc

4. GPU优化虚拟机：

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-gpu

5. 内存优化虚拟机：

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-memory

6. 存储优化虚拟机：

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-storage

7. Legacy A系列虚拟机：

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-previous-gen