我们目前有一个简单的3服务器设置：
我们正处于需要扩展/扩展我们的Web服务器的地步。 我们希望获得以下成果：
我想添加一个额外的networking节点，与原来的networking节点具有相同的容量，而不是将现有networking节点的容量加倍，因为这会给我们一个故障转移/镜像节点（当负载平衡时）来提高容量并提供冗余。
我已经深入地研究了这些选项，目前HAProxy似乎无法处理SSL问题（并且不希望在负载均衡器中终止，所有SSLstream量都必须进行端对端encryption，结束）。
我的select似乎是：
答：在两个networking节点的前面添加一个软件负载平衡器（例如Nginx）。 这里的问题是用户上传UGC时，在其他节点上不可用。 通过粘性会话这不是一个问题，但最终我们需要同步上传的内容，否则节点将失去同步。 可以使用Rsync，但我们正在看master-masternetworkingconfiguration，需要双向…。
B：如上所述，但是使用负载平衡器也可以提供静态内容。 然后，这将从Web节点卸载一些处理。 我们可以将所有从networking节点上传到负载均衡节点的rsync同步，这样它就只能从web-> load balancer单向rsync。 任何非静态请求都会对Web节点进行负载平衡。 这将所有的静态内容保留在一个地方，但我的目标是有一个小的负载平衡节点，这可能会增长相当大？
c：作为A，但是使用NGinx来指示上传可能（这很容易分割）的任何访问者stream量到一个“主”服务器上传，并且在其它节点之间为“只读”stream量进行相当的负载平衡。 这使得同步变得简单，因为它将是单向的（主节点networking节点 – >从属节点），使我们能够更好地使用networking节点上的磁盘空间，并保持负载平衡器的静态内容不变。 但是，这意味着如果主节点出现故障，我们需要手动将我们的“上传”区域的stream量切换到剩余的服务器（nginx可能能够做这个切换，我们只是有一个不同的负载平衡configuration我们的上传区域）
B似乎是一个很好的configuration，而且我可以将Load Balancer节点与我们现有的电子邮件/监控服务器结合，因为它闲置。 负载均衡节点有一个单点故障，但是在紧急情况下，我们可以调出一个新的云实例来替代这个实例。 不过，我不喜欢只有在一个节点上的静态图像的想法，因为我们没有固有的备份。 我也喜欢C的想法，因为这意味着它保持简单。 如果负载平衡器失败，我们可以直接将stream量引导到其中一个networking节点，而没有任何问题（因为它们都有一整套静态文件）。
任何上述解决scheme的input将非常感激
我会selectB，因为你提到的优点是正确和有说服力的。
如果您有两台Web服务器，则必须解决在多台计算机上保持内容同步的问题; 增加三分之一是微不足道的，因此将静态内容从任何源同步到负载平衡器的成本都很容易。
一般来说，磁盘空间非常便宜 – 而且如果你的增长速度很快，那么你可能希望将静态内容推送到CDN（例如：S3，Akami），以便让负载平衡知道它在哪里，并且适当地指导客户端一个合理的中间步骤。
鉴于在两个主节点之间同步内容的问题很困难 ，在大多数情况下，我会开始将所有上传stream量指向一台机器，并将只读复制指向其他服务器。 这可以使更改保持较小，并且可以在负载平衡器就位，运行和testing之后在主/主模型上工作。