如何通过其前面的AppGateway和负载均衡器(AppGw-> LB-> SF节点)实现对Service Fabric节点的粘性?

问题描述

我们目前有1个AppGw-> 1x磅-> 3个SF节点，我们希望获得粘性"到其中之一 SF节点.

使用基于AppGw Cookie的相似性，我们只会对(单个)LB产生粘滞感(即无法实现 我们想要).

借助LB会话持久性，我们可以粘在SF节点上，但是基于AppGw IP地址， 或更少总是相同的，因此所有请求最终都在同一个SF节点上(即，我们现在很粘，但仅使用单个SF节点).

在我看来，唯一的解决方案是摆脱LB并将SF节点添加到后端池 直接来自AppGw，例如1个AppGw-> 3个SF节点.

通过该设置，我们可以使用基于Cookie的亲和力来实现均匀分布，但也可以保持对 SF节点.如果没有LB，我们是否会失去一些东西?

解决方案

We currently have 1x AppGw -> 1x LB -> 3x SF Nodes and we want "stickiness" to one of the SF nodes.

With AppGw cookie based affinity we only get stickiness to the (singleton) LB (i.e. does not achieve what we want).

With LB session persistence we get stickiness to a SF node but based on the AppGw IP address, which is more or less always the same, thus all requests end up at the same SF node (i.e. we are sticky now, but only use a single SF node).

It seems to me that the only solution would be to get rid of the LB and add the SF nodes to the backend pool of the AppGw directly, e.g. 1x AppGw -> 3x SF nodes.

With that setup we could use cookie based affinity to achieve an even distribution but also stickiness to the SF nodes. Is there something that we would lose not having the LB inbetween anymore? Autoscaling of SF nodes maybe?

解决方案

这篇关于如何通过其前面的AppGateway和负载均衡器(AppGw-> LB-> SF节点)实现对Service Fabric节点的粘性?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！