我们已成功部署HAProxy作为所有基于Exchange 2013 SP1 HTTPstream量(自动发现,OWA,EXP,EWS,MAPI等)的第4层负载均衡器。
但是,由于各种原因,我们正在转向第7层“SSL卸载”架构。
我们将大部分configuration都基于ALOHA优秀指南: https : //www.haproxy.com/static/media/uploads/eng/resources/aloha_load_balancer_appnotes_0065_exchange_2013_deployment_guide_en.pdf
好消息是几乎所有的东西都工作得很好。 我们唯一的问题是与MAPI,即在Exchange 2013 SP1中引入的RPC的替代。
从我已阅读的Exchange 2013支持MAPI的卸载 – 请参阅http://blogs.technet.com/b/rmilne/archive/2014/02/25/exchange-2013-sp1-released.aspx 。 ALOHA文件build议不要使用Layer-7 SSL卸载MAPI,但纯粹是由于性能问题而没有任何技术原因。
如果我们尝试和平衡MAPI,那么我们看到的症状是
HAProxyconfiguration的相关位在下面(它不是整个文件)
frontend ft_exchange_2013_https bind 1.1.1.3:443 ssl crt /blah/blah.pem capture request header Host len 32 capture request header User-Agent len 64 capture response header Content-Length len 10 maxconn 10000 acl ssl_connection ssl_fc acl host_mail hdr(Host) -i mail.company.com acl path_slash path / acl path_mapi path_beg -i /mapi http-request deny if path_check http-request redirect scheme https code 302 unless ssl_connection http-request redirect location /owa/ code 302 if path_slash host_mail use_backend bk_exchange_2013_https_mapi if path_mapi backend bk_exchange_2013_https_mapi option httpchk GET /mapi/HealthCheck.htm http-check expect string 200\ OK timeout server 600s server SERVER1 1.1.1.1:443 maxconn 2000 weight 10 check ssl verify none server SERVER2 1.1.1.2:443 maxconn 2000 weight 10 check ssl verify none
我们试图解决这个问题的东西是
但是,这些问题都没有解决。 如果任何人有任何想法如何进一步诊断或有一个工作configuration,他们可以共享,如HAProxyconfiguration+交换MAPI虚拟目录configuration将是伟大的!
编辑1
我也设法通过去https://mail.company.com/mapi/emsmdb重复Outlook的行为,这反复提示凭据相同的Outlook