Eoi*_*ell 6 load-balancing azure azure-app-service-plans azure-web-app-service azure-load-balancer
我们的问题是 Azure 应用服务(S3 x 5 实例)未在 5 个实例之间均匀分配请求。结果是,一个实例被请求淹没,并且该应用程序服务的整体 P50 和 P95 响应时间 SLA 被违反。
我已确认应用服务已关闭 ARR Affinity。它是一个完全无状态的 Web API,因此它本身没有什么粘性。
技术细节如下,但问题本质上是这样的
为什么 Azure 晚上不在所有 5 个实例之间分配/循环分配我的流量?
就目前情况而言,扩大或缩小在这里似乎没有意义,因为我最终会得到额外的昂贵实例闲置,而 1 个实例被淹没。
技术细节
以下两张来自 6 月 1 日至 6 月 25 日的应用洞察图表显示了该问题。
requests
| where timestamp > datetime("2020-06-25 00:00:00")
| where timestamp < datetime("2020-06-25 08:00:00")
//comaprison between 00:00-08:00 on June 1st vs. Today
| where url contains "**ommitted**"
| project cloud_RoleInstance, itemCount, bin(timestamp, 1h)
| evaluate pivot(cloud_RoleInstance, sum(itemCount))
| render timechart
Run Code Online (Sandbox Code Playgroud)
下面第一张图显示了 6 月 1 日的流量分布。分布不完全但接近。第三台服务器比第五台服务器承担的流量大约多 50%
34,708 26,436 38,313 30,617 24,355
22% 17% 25% 20% 16%
Run Code Online (Sandbox Code Playgroud)
下面的下图显示了今天早上同一时间范围内的流量分布...第四个实例处理的流量比下一个最接近的实例多 250%,比实例 1 多 600%
11,980 21,671 34,180 85,041 24,508
7% 12% 19% 48% 14%
Run Code Online (Sandbox Code Playgroud)
不幸的是,当您扩展应用程序时,您对所使用的负载均衡器没有任何权力。据我所知,它是不可配置的,并且应该随机地将请求发送到实例。
尽管如此,从所附图表来看,您的分布在第一个图表中相当平衡。当然,你提出的第二天就有一个明显的问题,但我可以想象这可能只是暂时的。
随机性包括统计数据,从统计数据来看,在较小的时间窗口(有限的采样)内可能有更多的请求发送到您的实例之一。
我建议您获取更多有关负载平衡的样本,因为只有两天是不够的。我非常确定,您收集的数据越多,您就会看到曲线收敛得越多。
我可以理解 SLA 是一个问题,为此我建议升级到另一层,以便更快地满足您的请求。
| 归档时间: |
|
| 查看次数: |
1809 次 |
| 最近记录: |