Stu*_*art 4 azure autoscaling azure-web-sites azure-app-service-plans azure-web-app-service
扩展后,我的应用程序服务无法扩展。这似乎是我几个月来一直试图解决的一种模式。
我已经尝试了以下方法,但是都没有成功:
我的缩放条件取决于CPU和内存。但是,我从未见过CPU超过12%,因此我假设它实际上是根据内存扩展的。
将横向扩展条件设置为在5分钟(平均10分钟)内超过90%的内存。在5分钟的平均时间内,冷却时间和内存缩放比例在70%以下。这似乎没有任何意义,因为如果我的内存利用率已经达到90%,则说明我确实存在底层内存泄漏,应该已经向外扩展。
将横向扩展条件设置为在60分钟(平均10分钟)内平均存储80%以上。冷却时间,并在5分钟内平均在60%以下的条件下扩展内存。这更有意义,因为我看到内存使用量在几个小时内突然下降而下降。
预期行为:在内存使用率降至60%以下的5分钟后,应用程序服务自动缩放将减少实例计数。
题:
如果我的基准CPU保持平均6%的平均水平,而内存保持53%的水平,则衡量指标平滑扩展的理想阈值是多少?意思是,在不担心诸如拍打之类的反模式的情况下,按比例放大的最佳最小值和按比例缩小的最佳最大值是多少?差异较大的阈值20%对我来说更有意义。
替代解决方案:
鉴于与“按钮缩放”一样简单的市场营销涉及的故障排除工作量,几乎不值得使配置模糊不堪(即使没有自定义powershell脚本,您也无法使用IIS度量标准,例如连接计数!) 。我正在考虑由于其不可预测性而禁用自动缩放,因此只需保持2个实例运行以进行自动负载平衡并手动缩放即可。
自动缩放配置:
{
"location": "East US 2",
"tags": {
"$type": "Microsoft.WindowsAzure.Management.Common.Storage.CasePreservedDictionary, Microsoft.WindowsAzure.Management.Common.Storage"
},
"properties": {
"name": "CPU and Memory Autoscale",
"enabled": true,
"targetResourceUri": "/redacted",
"profiles": [
{
"name": "Auto created scale condition",
"capacity": {
"minimum": "1",
"maximum": "10",
"default": "1"
},
"rules": [
{
"scaleAction": {
"direction": "Increase",
"type": "ChangeCount",
"value": "1",
"cooldown": "PT10M"
},
"metricTrigger": {
"metricName": "MemoryPercentage",
"metricNamespace": "",
"metricResourceUri": "/redacted",
"operator": "GreaterThanOrEqual",
"statistic": "Average",
"threshold": 80,
"timeAggregation": "Average",
"timeGrain": "PT1M",
"timeWindow": "PT1H"
}
},
{
"scaleAction": {
"direction": "Decrease",
"type": "ChangeCount",
"value": "1",
"cooldown": "PT5M"
},
"metricTrigger": {
"metricName": "MemoryPercentage",
"metricNamespace": "",
"metricResourceUri": "/redacted",
"operator": "LessThanOrEqual",
"statistic": "Average",
"threshold": 60,
"timeAggregation": "Average",
"timeGrain": "PT1M",
"timeWindow": "PT10M"
}
},
{
"scaleAction": {
"direction": "Increase",
"type": "ChangeCount",
"value": "1",
"cooldown": "PT5M"
},
"metricTrigger": {
"metricName": "CpuPercentage",
"metricNamespace": "",
"metricResourceUri": "/redacted",
"operator": "GreaterThanOrEqual",
"statistic": "Average",
"threshold": 60,
"timeAggregation": "Average",
"timeGrain": "PT1M",
"timeWindow": "PT1H"
}
},
{
"scaleAction": {
"direction": "Decrease",
"type": "ChangeCount",
"value": "1",
"cooldown": "PT5M"
},
"metricTrigger": {
"metricName": "CpuPercentage",
"metricNamespace": "",
"metricResourceUri": "/redacted",
"operator": "LessThanOrEqual",
"statistic": "Average",
"threshold": 40,
"timeAggregation": "Average",
"timeGrain": "PT1M",
"timeWindow": "PT10M"
}
}
]
}
],
"notifications": [
{
"operation": "Scale",
"email": {
"sendToSubscriptionAdministrator": false,
"sendToSubscriptionCoAdministrators": false,
"customEmails": [
"redacted"
]
},
"webhooks": []
}
],
"targetResourceLocation": "East US 2"
},
"id": "/redacted",
"name": "CPU and Memory Autoscale",
"type": "Microsoft.Insights/autoscaleSettings"
}
Run Code Online (Sandbox Code Playgroud)
对于CpuPercentage指标,当它超过60时,您有一个SCALE UP操作,而当它低于40时,您有一个Scale-down操作,两者之间的差异很小。这可能会导致描述为“拍打”的行为,并且将导致AutoScale的实际缩放无法起作用。类似的问题是您配置的MemoryPercent规则。
放大和阈值缩放之间应该至少有40的差异,以避免拍打。有关拍打的更多详细信息,请参见https://docs.microsoft.com/zh-cn/azure/monitoring-and-diagnostics/insights-autoscale-best-practices#choose-the-thresholds-carefully-for-all-metric-类型(搜索“拍打”一词)
我遇到了完全相同的问题,并且我开始相信像我们现在想要的那样自动缩放回一个实例是不可能的。
我当前的解决方法是缩小到 1 个实例,并使用每天 23:55 到 00:00 之间重复的第二个配置文件。
只是重申一下问题。我有以下场景。它与你的基本相同。
当平均内存百分比超过 80% 时,从 1 个实例扩展到 2 个实例将正常工作。但扩展到 1 个实例永远不会起作用,因为内存基线太高。
阅读最佳实践后,我的理解是,在扩展时,它会估计结果的内存百分比并检查是否没有触发扩展规则。
因此,如果两个实例的平均内存百分比下降到 50%,则会触发扩展规则,并且它将估计最终的内存使用量,这2 * 50% / 1 = 100%当然会触发扩展规则,因此不会扩展。
然而,当从 3 个实例扩展到 2 个实例时,它应该可以工作:3 * 50% / 2 = 75%这小于扩展规则的 80%。
| 归档时间: |
|
| 查看次数: |
1149 次 |
| 最近记录: |