IIS – configuration问题和疑虑

我们的环境主要由在IIS / ASP.Net上运行的SSL网站组成。大多数网站代码是报告，分析和用户特定的数据视图。我们正在扩大并发用户的数量，我需要规划故障切换和集群能力。我一直在研究设置nginx和haproxy以及可能的清漆来处理SSL卸载，负载平衡和caching。

我的一个问题涉及到configuration。我相信，从我所读到的，由于我们运行的SSL站点，nginx需要在清漆面前。我设想适当的设置是：

 * ------- *
 * nginx *
 * ------- *
     |
 * --------- *
 *清漆*
 * --------- *
     |
 * --------- *
 * haproxy *
 * --------- *
     | \
     |  -   -   -   -   - 
     |  |
 * ------ * * ------ *
 * web1 * * web2 *
 * ------ * * ------ *

首先，这是我们的环境（IIS 7.5）的最佳情况设置，并且在大多数内容本质上是每个请求的dynamic内容的情况下实施清漆是否有任何好处？我正在通过分析这个话题达到瘫痪的地步，似乎无法得到清漆中间层用例的良好答案。

我的第二个问题是处理单点故障。现在我们的ASA5510路由到每个Web服务器，所以我们的单点是防火墙/连接。连接有一个很小的机会，甚至会下降，我真的只考虑防火墙作为我们的configuration单点故障。 pipe理层一定要看上面的图表，看看3个可能的新的失败点。有没有一种方法来设置这个消除所有服务器的主要瓶颈的任何点？我无法find与nginx或haproxy不稳定的一致报告，所以他们似乎是坚实的，但我仍然想尽可能提供故障转移。

对于在不牺牲基础设施的情况下实现这些集成的最佳方式有何想法或想法？

这与我们的设置相似，只是我们没有清漆。 nginx和HAProxy“服务器”在同一个盒子里。 nginx为我们做SSL卸载，然后HAProxy将请求发送到几个Web服务器之一。我们希望来自HAProxy的增强负载平衡，所以我们都有。整个过程很好。

我们发现的唯一问题是客户端的IP地址。我们无法find一种方法来告诉IIS将x-forwarded-for IPlogging为日志中的clientip，但是我们发现ASP.Net可以要求IIS在请求string的末尾附加一些附加信息日志，所以我们坚持客户端IP在那里。不理想，但它的作品。 nginx设置为添加一个x-forwarded-for头，HAProxy 没有设置为添加转发的信息（因为它只是指向nginx）。而且，nginx似乎只是在保持活动会话中为第一个请求添加头文件 – 同样不理想，但对我们来说已经足够了。

我们的nginxconfiguration摘录（HAProxy正在监听127.0.0.1:5000）：

location / { proxy_pass http://127.0.0.1:5000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; proxy_buffering off; client_body_buffer_size 64k; }

ASP.Net代码（在global.asax中）将ip添加到请求头中：

 protected void Application_BeginRequest(Object sender, EventArgs e) { //If there's an X-ForwardedFor header (Proxy) append it to the query string for logging purposes. if (HttpContext.Current.Request.Headers["X-Forwarded-For"] != null) HttpContext.Current.Response.AppendToLog((HttpContext.Current.Request.QueryString.Count == 0 ? "" : "&") + "X-Forwarded-For=" + HttpContext.Current.Request.Headers["X-Forwarded-For"]);

就个人而言，我只是开始使用nginx – 当你的瓶颈是静态的（或者至less是半静态的）内容时，清漆速度会更快，但从你的描述来看，似乎nginx的内置cachingfunction足够好; 与haproxy类似，它是一个比nginx更好的负载平衡器，但除非你推动负载平衡的限制，否则nginx可能会相当高兴地照顾简单的东西。

也就是说，如果你正在推动caching和负载平衡的限制，我发现一次全部三个都是好的，唯一的麻烦是通过每一层跟踪客户端IP地址。