但是,对Linode进行DNS转换需要一些时间.我们提出了一种减少停机时间的策略,但我想就如何最好地实现它做一些建议.
该应用程序是一个ROR应用程序.我们在EC2上运行6个前端节点,并使用Nginx作为带有proxy_pass的负载均衡器.
然而,我们在Linode上的负载均衡器不能平衡到Linode节点,而是平衡到EC2节点.这是我们在我们的DNS记录中拥有我们的Linode LB的IP.因此,当客户端连接时,DNS循环到EC2或Linode LB.然后,所选择的LB将请求重定向到EC2上的节点之一.我遇到EC2中断的情况,我们只需更改Linode LB的配置以平衡它自己的节点(加上其他东西,比如DB翻转等).
我知道这对性能不是很好,但可靠性对我们来说更重要.
为了发布我们有任何原因,Linode LB无法连接到EC2.在这种情况下,Nginx将返回502 Bad Gateway错误,该错误不会导致客户端使用DNS故障转移.
我们希望有一种方法可以在出现这种情况时强制客户端使用DNS回退.有办法做到这一点吗？优选使用Nginx,但如果不支持,则考虑其他解决方案.
谢谢！
@R_301_323@
两个答案,首先是你的502问题,你应该把它添加到你的Nginx,所以如果至少有一些有能力的节点,Nginx将重试(默认情况下在502上它只是放弃)：
http://wiki.nginx.org/HttpProxyModule#proxy_next_upstream
proxy_next_upstream Syntax: proxy_next_upstream [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off];
其次,对于“返回DNS”,您需要稍微改变一下方法.对于这些设置,我通常所做的就是将DNS一直拉回到自己的应用程序节点,该节点通过负载均衡器和终端节点测试连接.作为奖励,您可以将DNS与您的应用程序集成,并在应用程序耗尽时关闭DNS服务器.这里的想法是让客户端DNS请求“测试”整个路径工作,而不仅仅是与LB的连接.显然你不能使用Nginx,我已经使用了pf规则,你可以在iptables中做同样的事情.您只需循环请求后端节点并在后端服务器上运行绑定.这样做的目的是确保你拥有多个NS条目,每个条目对应一个“LB”.客户端将负责测试每个NS记录,在测试中我已经完成了平均故障转移时间为2秒,并且它适用于我们查看的99％的操作系统.如果这有意义,请告诉我.它将比在客户端已经发出第一个TCP请求后尝试恢复的任何方案更好地工作.
根据Gomez和Keynote监控,我已经建立了可以保持100％可用性的站点.正如您已经提到的,它可能会导致DNS查找的一些初始性能损失,但该网站始终有效并且客户喜欢(就像我的寻呼机一样).
