I'm running a 2-node ejabberd cluster (behind an elastic load balancer) that in turn connects with a 3-node Riak cluster (again, via an ELB) on AWS. When I load-test the platform via Tsung (creating 0.5 million user registrations), I notice that the CPU utilization for the ejabberd nodes differs amongst themselves by around 10%. For the Riak nodes, the CPU and memory utilization amongst nodes differs by around 5%.
The nodes are of identical configuration, so wondering what could be leading to these non-trivial differences in utilization. Can anyone throw some light here please / educate me?
Is it due to the load balancer? Or a network impact? I expect that once a cluster is formed (either of ejabberd or of Riak KV), the nodes are all identical in behavior, especially for ejabberd where the entire database is replicated across the cluster.
Not that these differences are a problem, but would be good to understand the inner workings of the clusters here...
Many thanks.
答案 0 :(得分：1)
弹性负载平衡机制
更详细的说明：
可用区（不太可能是您的情况）
默认情况下，负载均衡器节点将流量路由到同一可用区内的后端实例。为确保后端实例能够处理每个可用区中的请求负载，在每个区域中拥有大约相等数量的实例非常重要。例如，如果在可用区us-east-1a中有10个实例，在us-east-1b中有两个实例，则流量仍将在两个可用区之间平均分配。因此，us-east-1b中的两个实例将必须提供与us-east-1a中的十个实例相同的流量。
会话（很可能是您的情况）
默认情况下，负载均衡器将每个请求独立路由到负载最小的服务器实例。相比之下，粘性会话将用户的会话绑定到特定的服务器实例，以便会话期间来自用户的所有请求都将发送到同一服务器实例。
AWS Elastic Beanstalk在为应用程序启用粘性会话时使用负载均衡器生成的HTTP Cookie。负载均衡器使用特殊的负载均衡器生成的cookie来跟踪每个请求的应用程序实例。当负载均衡器收到请求时，它首先检查请求中是否存在此cookie。如果是，则将请求发送到cookie中指定的应用程序实例。如果没有cookie，则负载均衡器根据现有的负载均衡算法选择应用程序实例。将cookie插入响应中，以便将来自同一用户的后续请求绑定到该应用程序实例。策略配置定义cookie到期，它确定每个cookie的有效期。
路由算法（不太可能是您的情况）
负载均衡器节点使用 leastconns 路由算法将请求发送到同一可用区内的正常实例。 leastconns 路由算法支持具有最少连接或未完成请求的后端实例。
来源：Elastic Load Balancing Terminology And Key Concepts
希望它有所帮助。