HAProxy and ejabberd
英文链接：https://blog.onefellow.com/post/76702632637/haproxy-and-ejabberd
虽然以前我已经发布了关于使用Cisco SLB的负载均衡ejabberd的文章，主要针对那些有能力使用基于思科的解决方案的人 ，虽然这种解决方案成本非常昂贵。
今天我会写一点关于HAProxy的内容，针对那些没有思科硬件基础的人。
许多管理员构建XMPP集群，并按照RFC标准说，使用SRV记录将流量路由到它们。 但是这并不是最好的选择，SRV有几个弱点（主要与它的DNS性质有关）：
- DNS没有关于可靠性和节点负载的信息
- SRV需要在客户端正确实现（这通常是由DNS缓存等引起的问题）
- 如果有多个entries和失败事件，可能造成客户端连接延迟严重
这就是为什么我认为DNS平衡（srv或round-robin）永远不应被视为“负载平衡器”，更好的解决方案是HAproxy。
这是可用的解决方案之一，但从我的经验 - 这是最好的可选方案之一。 HAproxy“是一款免费的，快速和可靠的解决方案，为基于TCP和HTTP的应用提供高可用性，负载平衡和代理服务”， 由于它提供TCP代理，因此非常适合负载平衡XMPP协议。
好的，那我们该怎么做呢？ 以下是简单设置的概述：
正如您所看到的，我们正在使用ejabberd - ProcessOne开发的最佳行业标准XMPP服务器，由３个节点组成的集群。 在这个例子中，我们将设置一个指向HAproxy的SRV记录（可选地，作为故障切换，您可以添加另一个HAproxy实例或直接为任何单个节点添加SRV记录 - 但请记住以适当的“优先级”设置添加它 - 以便与haproxy 总能优先选择它），所有连接都将由负载平衡器处理。 （这里插一个知识点介绍，单点故障-SPOF，为了缓解它，你可以运行HAproxy的第二个实例并将它作为第二个选项添加到SRV记录中）
接下来是haproxy.conf的一个案例，只是个简单的配置，在一些中等环境测试通过：
global
log /var/run/syslogd.sock local0
maxconn 60000
nosplice
chroot /usr/share/haproxy
uid 65534
gid 65534
pidfile /var/run/haproxy.pid
stats socket /usr/share/haproxy/haproxy-stats.sock
daemon
defaults
log global
mode tcp
retries 2
option redispatch
option tcplog
option tcpka
option clitcpka
option srvtcpka
timeout connect 5s #timeout during connect
timeout client 24h #timeout client->haproxy(frontend)
timeout server 60m #timeout haproxy->server(backend)
frontend access_clients 213.134.1.1:5222
default_backend cluster_clients
frontend access_clients_ssl 213.134.1.1:5223
default_backend cluster_clients_ssl
frontend access_servers 213.134.1.1:5269
default_backend cluster_servers
backend cluster_clients
log global
balance leastconn
option independant-streams
server server1 10.0.0.1:5222 check fall 3 id 1005 inter 5000 rise 3 slowstart 120000 weight 50
server server2 10.0.0.2:5222 check fall 3 id 1006 inter 5000 rise 3 slowstart 120000 weight 50
server server3 10.0.0.3:5222 check fall 3 id 1007 inter 5000 rise 3 slowstart 120000 weight 50
backend cluster_clients_ssl
log global
balance leastconn
option independant-streams
server server1 10.0.0.1:5223 check fall 3 id 1008 inter 5000 rise 3 slowstart 240000 weight 50
server server2 10.0.0.2:5223 check fall 3 id 1009 inter 5000 rise 3 slowstart 240000 weight 50
server server3 10.0.0.3:5223 check fall 3 id 1010 inter 5000 rise 3 slowstart 240000 weight 50
backend cluster_servers
log global
balance leastconn
option independant-streams
server server1 10.0.0.1:5269 check fall 3 id 1011 inter 5000 rise 3 slowstart 60000 weight 50
server server2 10.0.0.2:5269 check fall 3 id 1012 inter 5000 rise 3 slowstart 60000 weight 50
server server3 10.0.0.3:5269 check fall 3 id 1013 inter 5000 rise 3 slowstart 60000 weight 50这里我就不再一一解释每一个选项，因为有官方文档可以参考，但我将快速解释下这里发生了什么。正如您可以看到之前介绍的配置反映图，我们有3个“前端”服务（5222,5223,5299 - 用于客户端TLS，客户端SSL和服务器2服务器），指向三个后端服务器。在这个例子中，HAproxy将负载平均分配给所有服务的所有后端服务器（最小+加权），并且在失败（慢启动）时它将逐渐接受连接，以防止连接风暴在服务器启动时触及服务器。有几个选项可以根据需要进行微调 - 例如超时，失败计数。这是您使用LB话题进行实验的基础。去玩吧！
HAproxy的主要优点之一是它非常简单，安装快速，可靠性高，硬件占用空间小。感谢所有的专业人士，我们可以想象XMPP（超级感兴趣的主题 - 将在某天写入）的地理位置错位的代理服务器等各种用途，或交叉代理以获得更好的可用性。
这不是我关于LB和XMPP的最后一篇文章，下一站是Amazon Elastic Load Balancing（ELB），这是管理员在AWS上托管服务器的绝佳解决方案。