如果一个站点出于冗余原因有 2 个负载均衡器，那么 DNS 应该指向哪一个？
如果我只是在 DNS 记录中同时指向这两者，那么 50% 的流量不是也会遇到麻烦吗？
If I simply point to both in my DNS record, wouldn't 50% of traffic be in trouble as well?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有多种简单的方法可以使用一个 IP 地址提供弹性服务，而无需花费大量资源。
例如，您可以将公共 IP 地址配置到每个代理服务器的环回接口上，然后通过 OSPF 路由协议（或类似协议）将其公布到内部路由表中。
如果服务器完全挂掉，该路由将从内部路由表中撤回，并且流量会在 30 秒内自动停止流向挂掉的服务器。
在大多数网络中，该解决方案无需花费。 如果您的代理运行的是 Linux 或其他 UNIX 变体，则可以使用 Quagga 完成 OSPF 路由。
您的内部网络也需要能够使用 OSPF，但这对于大多数 Cisco 或 Juniper 级硬件来说都是开箱即用的。 您计划运行一些相当不错的网络设备来支持这数千个站点，不是吗;-)？
FWIW，我过去使用过类似的技术来处理从一个数据中心到另一个数据中心的大规模共享网络托管的故障转移。
There are easy ways of providing resilient services using one IP address that needn't cost the earth.
For example, you can just configure the public IP address onto a loopback interface onto each of the proxy servers and then announce it via the OSPF routing protocol (or similar) into your internal routing tables.
If a server dies completely, the route is withdrawn from your interior routing tables and traffic automatically stops flowing to the dead server within 30 seconds.
In most networks this solution costs nothing. The OSPF routing can be done using Quagga if your proxies are running Linux or some other UNIX variant.
Your internal network will need to be able to speak OSPF too, but that comes out of the box with most Cisco or Juniper class hardware. You are planning to run some reasonably OK network gear to support these thousands of sites, aren't you ;-) ?
FWIW, I've used a similar technique in the past to handle fail-over of large scale shared web-hosting from one data center to another.
您可以在 DNS 中指向两者。 当其中一个出现故障时，用户的浏览器将发出请求，注意到出现问题并请求新的 A 记录。 第二个 A 记录应该有效并且仍然有效。
You can point to both in your DNS. When one of them goes down, the user's browser will make a request, notice something is wrong and request a new A Record. The second A Record should be valid and working still.
有很多方法可以看待这个问题。 当您开始研究这些类型的事物时，您可能会看到诸如“主动-主动”或“主动-被动”设置之类的术语。
您所描述的是“主动-主动”设置，其中主硬件和“故障转移”硬件都满足客户的需求。 主动-被动通常意味着需要一些手动部分才能从“主动”服务器故障转移到备用“被动”服务器。
两种配置都是完全合法的，您问题的正确答案实际上取决于对您个人情况的分析。 需要考虑的事项：
1. 两个硬件是否等效？ （即：无论您的客户通过您的基础设施采取哪条路径，他们都会有相同的体验）。
始终运行两个实例的成本值得吗？
故障转移期间的停机时间有何影响？ （即：您将停机多长时间？这样的中断会让您损失多少费用）。
维护过程中的哪些要素（升级、备份）中主动-主动是否有帮助？ （即：升级负载均衡器后面的服务器上的软件、升级负载均衡器本身等）。 在这些场景中，您将从该对中拉出一个成员，执行升级工作，然后在升级第二个成员时将流量重新路由到已升级的成员。
一般来说，主动-主动成本较高，但对客户造成影响的风险最小。 因此，“正确”的答案更多地与业务方面有关，而不是技术方面。
现在，如果所有情况不相等，您可能需要查看以下内容：
每个平衡器上预先存在的（不是您的应用程序）负载。
每个平衡器
每个上的硬件/容量。
年龄（是否接近生命的终点，或可能很快就会失败？）
地点（如果您是谈论多数据中心...地理位置可能会影响性能）。
我知道我没有给你一个“做这个”的答案......但希望我已经提供了一些关于你在得到答案时会考虑的类型的见解。
There's any number of ways to look at this. When you start looking at these types of things you'll likely see terminology like "Active-Active" or "Active-Passive" setup.
What you're describing is an "Active-Active" setup where both the primary and "failover" hardware are serving customer's needs. Active-Passive generally means there's some manual portion to failover from the "active" server to the standby "passive" server.
Either configuration is perfectly legitimate and the correct answer to your question really comes down to an analysis of your individual situation. Things to consider:
1. Are both pieces of hardware equivalent? (IE: will your customers have the same experience regardless of which path they take through your infrastructure).
Is it worth the cost of running both instances all the time?
What is the impact of down time during failover? (IE: How long will you be down? How much would such an outage cost you).
Are the elements of your maintenance process (upgrades, backups) where active-active is helpful? (IE: upgrading software on the servers behind the load balancer, upgrading the load balancer itself, etc). These are scenarios where you would pull one member out of the pair, do the upgrade work, and re-route traffic to the upgraded member while you upgrade the second member.
In general Active-Active is more costly but gives you the least risk of impact to your customers. So the "right" answer has more to do with business aspects than technical ones.
Now if all things aren't equal you might want to look at things like:
Pre-existing (not your application) load on each of the balancers.
Hardware/capacity on each.
Age (is one close to end of life, or likely to fail soon?)
Location (if you're talking multi-datacenter... geo-location might impact performance).
I know I didn't give you a "DO this" answer... but hopefully I've provided some insight into the types of considerations you'd make when arriving at your answer.