在负载均衡的Amazon EC2节点socket.io [英] Node socket.io on load balanced Amazon EC2

查看:823
本文介绍了在负载均衡的Amazon EC2节点socket.io的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个标准灯泡的EC2实例建立在Amazon的AWS上运行。说完还安装了Node.js的,socket.io和Ex preSS以满足实时更新的要求,我现在是在负载均衡的应用阶段。这是所有的工作,但我的插座都没有。这就是我的建立看: -

I have a standard LAMP EC2 instance set-up running on Amazon's AWS. Having also installed Node.js, socket.io and Express to meet the demands of live updating, I am now at the stage of load balancing the application. That's all working, but my sockets aren't. This is how my set-up looks:-

                  --- EC2 >> Node.js + socket.io
                /
Client >> ELB --
                \
                  --- EC2 >> Node.js + socket.io


[RDS MySQL - EC2 instances communicate to this]

正如你所看到的,每个实例有一个安装点和socket.io的。但是,偶尔的Chrome调试将400插座请求返回的原因 {code:1,消息:会话ID未知} ,我猜这是因为它的通信的其他实例

As you can see, each instance has an installation of Node and socket.io. However, occasionally Chrome debug will 400 the socket request returning the reason {"code":1,"message":"Session ID unknown"}, and I guess this is because it's communicating to the other instance.

此外,让我们说,我第A和插座需要输出到网页B - 因为负载平衡器这两个页面很可能是在不同的实例(它们都将在同一时间打开)的。使用类似的粘性会话,据我所知,也不会在那种情况下工作,因为这两个页面将被限制在各自的实例。

Additionally, let's say I am on page A and the socket needs to emit to page B - because of the load balancer these two pages might well be on a different instance (they will both be open at the same time). Using something like Sticky Sessions, to my knowledge, wouldn't work in that scenario because both pages would be restricted to their respective instances.

我怎样才能解决这个问题得到什么呢?我需要的只是一个节点整个专用实例?这似乎有点矫枉过正...

How can I get around this issue? Will I need a whole dedicated instance just for Node? That seems somewhat overkill...

推荐答案

在问题出现时,你同时考虑的WebSocket流量(第4层-ish)和HTTP流量(第7层)在负载平衡器只能检查一个活动层的时间。例如,如果你设置了ELB加载在7层的平衡(HTTP / HTTPS),那么的WebSockets将不会在所有的工作在整个ELB。但是,如果将ELB加载第4层(TCP)余额那么任何后备HTTP轮询请求最终可能在任何上游服务器。

The issues come up when you consider both websocket traffic (layer 4 -ish) and HTTP traffic (layer 7) moving across a load balancer that can only inspect one layer at a time. For example, if you set the ELB to load balance on layer 7 (HTTP/HTTPS) then websockets will not work at all across the ELB. However, if you set the ELB to load balance on layer 4 (TCP) then any fallback HTTP polling requests could end up at any of the upstream servers.

您有两个选择。你可以想出一个办法来有效负载均衡HTTP和WebSocket的请求,或者找到一个方法来确定性请求映射不管协议到上游服务器。

You have two options here. You can figure out a way to effectively load balance both HTTP and websocket requests or find a way to deterministically map requests to upstream servers regardless of the protocol.

第一种是涉及pretty的,并且需要另一负载平衡器。 一个很好的演练可以在这里找到。值得一提的是,当帖子撰写HAProxy的没有原生支持SSL。现在,这种情况有可能只删除了ELB完全,如果这就是你想要去的路线。如果是这样的情况下,第二个选项可能会更好。

The first one is pretty involved and requires another load balancer. A good walkthrough can be found here. It's worth noting that when that post was written HAProxy didn't have native SSL support. Now that this is the case it might be possible to just remove the ELB entirely, if that's the route you want to go. If that's the case the second option might be better.

否则,您可以自己使用HAProxy的(或Nginx的付费版本)来实现确定性的负载平衡机制。在这种情况下,你可以使用IP哈希因为socket.io不提供基于路由的机制找出像sockjs 特定的服务器。这将使用的IP地址的前3个字节,以确定哪些上游服务器收到的每个请求,除非用户改变HTTP民调那么这应该工作的IP地址。

Otherwise you can use HAProxy on its own (or a paid version of Nginx) to implement a deterministic load balancing mechanism. In this case you would use IP hashing since socket.io does not provide a route-based mechanism to identify a particular server like sockjs. This would use the first 3 octets of the IP address to determine which upstream server gets each request so unless the user changes IP addresses between HTTP polls then this should work.

这篇关于在负载均衡的Amazon EC2节点socket.io的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆