标签:
在前面的介绍中,我们看到通过定义规则可以实现虚拟机扩展集的auto scale,那么在后台执行上VMSS的扩展依赖于哪些组件,出现问题(比如自动扩展没有发生的时候),我们在拨打400之前,如何快速的检查是否是配置问题?
本文简单介绍一下VMSS下auto scale的原理,以及出现问题如何快速的检查问题。下图展示了Azure的计算资源监控和数据收集机制,从数据源来讲,Azure的监控数据可以来自于应用程序,诊断日志,系统、自定义的指标数据,也包括审计和操作日志。
例如在我们VMSS例子中用于自动化扩展的度量数据,来自于Linux Diagnostic扩展,扩展载我们做ARM模版定义的时候必须正确配置才能获得数据:
通过在Guest OS获得的metric数据会被保存在Azure Storage的Table当中,也可以保存在EventHub当中进行日志收集处理,收集的数据会被用于告警或者自动扩展处理,对于这些日志数据的访问,你可以通过Azure的portal,或者Powershell,或者使用命令行,或者使用REST API提供给第三方的工具进行监控:
在VMSS的ARM模板中,我们已经预先定义了一自动扩展的规则,获取数据的时间窗口,周期,进行scale out或者scale in的规则,那么在运行的时候,自动扩展引擎会根据定义的规则,时间窗口和度量值检测是否满足触发条件,一旦满足,就会执行相应的操作,例如增减,减少虚拟机,邮件通知等等:
到此为止,我简单介绍了一下VMSS的auto scale的工作原理和机制,那么现在问题来了,你部署了一个VMSS包含多个虚拟机,当压力增加的时候,你发现自动扩展没有发生,应该从哪些地方入手?
如果你看到WADMetrics*这样的表产生了,至少说明你的诊断的存储账号配置是正确的;如果你没有看到任何这样的如下的表产生,则说明你的存储账号和自动扩展配置是错误的
那么在storage explorer中,选择Query,在查询条件中field选择CounterName,查询值选择"\Processor\PercentUserTime",查询该值的大小:
在大部分的情况下,如果前面的设置没问题,你的auto scale还是不工作,一般都是你的度量值设置有问题,比如如果你使用的是\Processor\PercentIdleTime,但实际上你看到度量值中这个并不高,你需要检查并调整下你的自动扩展策略。
基本上绝大部分问题都可以在上述的诊断中解决,了解了VMSS的基本工作原理,可以帮助我们更好的使用这个强大的功能~
标签:
原文地址:http://www.cnblogs.com/cloudapps/p/5979104.html