我正在考虑更改通过https API提供服务的“高可用性”网站的选项。
目前的设置是：
如果不需要负载均衡，那么我们可以通过在两台机器上简单地共同定位DNS服务器来实现负载均衡，而每台DNS服务器只有在查询DNS时才使用自己的地址进行响应。 在这种情况下，如果一个虚拟机closures，将删除指向该服务的服务和DNS服务器，因此没有客户端将被引导到服务器closures，是正确的吗？
编辑清晰度：
我们对我们目前拥有的不完善的“HA”感到满意，这个问题具体是关于我所想的改变是否会让事情变得更糟。
对你的问题的直接回答是肯定的，这会让事情变得更糟。
这是因为你的一个名字服务器没有响应会导致解决延迟所有的时间试图通过失败的名称服务器解决客户端，而目前的技术将只失败+ – 一半的客户端，直到你检测到虚拟机closures+ TTL秒。
通常，名称服务器会被caching48小时，所以在停机时间或名称服务器更新时间较短的48小时内，您的用户将有一个随机缓慢的体验。
除非虚拟机停机检测速度慢， 否则您当前的实施情况会更好 在虚拟机下行和你检测到+ TTL之间的时期，build议的解决scheme实际上会更好。 但是我认为那段时间是如此之短以至于可以忽略不计。
如果我理解正确，则build议将这两个分布式服务器作为所讨论域的列出名称服务器，每个服务器都有一个权威区域文件，其中包含指向本地服务器的单个Alogging，以便运行HTTPS服务的主机名。
如果这是正确的，那么是的，我希望这个工作基于对域名服务器的请求的循环/随机性。 如果一台服务器出现故障，将无法响应具有自己的地址的查询，因此客户端应该相当快地故障转移到另一台进行DNS查询 。
你说你理解并接受DNS高速caching意味着服务器崩溃可能会破坏已经高速caching指向该服务器的查找的客户端，可能在很长一段时间内，因为不遵守短TTL的ISP。 如果是这样，那么我的build议中就没有看到任何明显的漏洞。
我不会在星期天的一个月里自己做。
DNS负载平衡曾经是使用的“东西”，但是现在常用的caching是不实用的。
在Windows中，您有“networking负载平衡器”，它可以通过在专用networking上使用多播来协助您做什么。 您仍然可以在两者之间使用VPN的供应商进行此操作。
在Linux中，您需要使用haproxy或其他软件包来实现负载平衡。 不过，这自然会带来挑战。
看看你的select，并决定哪个是最符合你的需求的成本效益。 除了非常受欢迎的选项之外，我无法推测。