深入理解Azure自动扩展集VMSS(2)
VMSS中Auto Scale基本原理及诊断
在前面的介绍中,我们看到通过定义规则可以实现虚拟机扩展集的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包含多个虚拟机,当压力增加的时候,你发现自动扩展没有发生,应该从哪些地方入手?
- 当然是检查你的ARM模版,看看你的LinuxDiagnotics是否定义,autoscale是否设置,规则是否正确等等。
- 打开你的Powershell并用RM登录,VMSS的autoscale依赖于两个Resource Provider,一个是Microsoft.Insights, 一个是Microsoft.Compute, 要确保他们的状态都是"Registered",否则需要使用命令Register-AzureRmResourceProvider手工注册这两个provider:
- 登录到新的Azure Portal,单击你的VMSS的资源组,你会看到上次部署的记录,检查部署日志,正常情况下,所有的部署操作都应该是成功的,如果有任何问题,查看详细日志,修复错误操作并重新部署:
- 检查你的自动扩展选项是否为打开状态:
- 根据我们之前对于VMSS自动扩展的机制的了解,metrics数据会被写到Azure Storage Account里面,如果上面的配置都没有问题,那么我们需要看一下VMSS里面创建的存储账号,其中一个存储账号是存放诊断数据的:
如果你看到WADMetrics*这样的表产生了,至少说明你的诊断的存储账号配置是正确的;如果你没有看到任何这样的如下的表产生,则说明你的存储账号和自动扩展配置是错误的
- 请下载相关的Azure存储管理工具,比如http://storageexplorer.com/,拷贝你的诊断存储账号的账户名和密码,进行连接,查看WAD*表中是否存在数据,WADMetricsPT1H*存放每小时汇总数据,WADMetricsPT1M*存放每分钟采集数据,如果你看到数据产生,则说明你的Linux Diag Agent工作正常:
- 到此为止,如果上述检查都通过,而你看到你的VMSS中的虚拟机你所希望的度量值的确达到了要求,那么你需要看看你在ARM模板中定义的度量值和采集到的值是否一样,因为就CPU而言,也有非常多的度量值,例如早本例中,我们使用的是"\\Processor\\PercentUserTime":
那么在storage explorer中,选择Query,在查询条件中field选择CounterName,查询值选择"\Processor\PercentUserTime",查询该值的大小:
在大部分的情况下,如果前面的设置没问题,你的auto scale还是不工作,一般都是你的度量值设置有问题,比如如果你使用的是\Processor\PercentIdleTime,但实际上你看到度量值中这个并不高,你需要检查并调整下你的自动扩展策略。
基本上绝大部分问题都可以在上述的诊断中解决,了解了VMSS的基本工作原理,可以帮助我们更好的使用这个强大的功能~
posted on 2016-10-19 23:07 StevenLian 阅读(1339) 评论(0) 编辑 收藏 举报