我有些报告真的很重。当一个给定的实例开始处理它时,它将很容易地消耗我的实例所拥有的两个核心中的100% .如果该实例获得其中的两个,则肯定会导致该实例无法处理任何其他的aprox请求1分钟.
我确实有其他实例正在运行(通常是4-6)。负载均衡器是否会选择实例A被阻塞的事实,并且它不应该在此负载下向其发送请求?或者不是,负载均衡器平均分配请求?
发布于 2017-09-22 15:58:54
Azure负载均衡器是一种基于TCP和UDP流的负载均衡器,不处理应用层流量。负载平衡决策是根据新的流程做出的。负载均衡器使用散列函数来确定新流的分布。分发模式控制计算哈希时所考虑的内容。
应用程序客户端的握手是直接与VM进行的。负载均衡器不知道您的HTTP请求,也不对它们进行排队。您需要查看此类处理的应用层负载均衡器,如Azure应用程序网关。我不清楚这是否会解决您的场景;根本的问题似乎是,当实例繁忙时,您不希望流到达。
也就是说,您可以做的是使用探测状态作为一种方式,向负载均衡器发出信号,表示您不希望接收更多的流。您可以使用HTTP探测配置,并通过响应HTTP 200以外的其他内容,让应用程序发出探测失败的信号,Load平衡器将停止向其发送新的流。平衡到该实例的现有流负载不会终止并将继续。您不能使用探测来发现虚拟机的负载;负载均衡器无法看到VM的负载。
发布于 2017-09-20 17:30:15
您可以在负载平衡器上设置几种分发模式,请参阅配置负载均衡器的分配模式。
从该链接中可以看到,系统存在一定程度的粘性,称为5元组算法,因为它使用5个属性:源IP、源端口、目标IP、目标端口、协议类型。
您可以使用PowerShell命令Set-AzureLoadBalancedEndpoint ... -LoadBalancerDistribution [opt]手动切换到2或3元组模式。
在门户中,我相信这个设置是由“负载平衡规则”部分中的“会话持久性”属性控制的,但是这些选项并不像在PowerShell中那样细粒度。
正如你所看到的,这不是真正的循环模式。
您可以通过原始TCP (是端口可连接的)或HTTP (我可以从web服务器获得响应)设置探测以检查活动端点,因此在您的示例中,最好的选择是依靠HTTP探测来检测端点响应不够快,并相应地路由通信量。
它绝对不知道服务器上的任何HTTP队列--不要忘记负载均衡器并不一定在路由HTTP流量,而且您可能正在使用各种各样的web服务器。要让北草坪会议大楼在所有可能的情况下都能看到你所说的能见度是非常困难的。
https://stackoverflow.com/questions/46002339
复制相似问题