对不起，以前不清楚。
我们有一个VMware虚拟化服务器实例，这是我们的主要生产服务器。 我在近百个独特的顶级域名上存储了一系列基于Web的应用程序。 为了提供网页，我们使用LAMP堆栈。 此服务器运行我们的主要和辅助DNS服务器（在两个不同的IP地址比用于服务Web内容）。 最后，我们还使用exim（我相信）托pipe我们的邮件（pop和smtp）。
最近我们遇到了问题，导致我们的root fs变成只读，从而阻止了apache2或mysql连接，并阻止了传入的电子邮件。 基本上减less了成千上万的客户端的networking存在和电子邮件。 这个问题的性质（仍然不受控制）并没有影响到这个问题，所以DNS仍然没有问题。
从那以后，我们开始将生产网站和相关的mysql数据库镜像到辅助服务器上。 这台服务器已经完全准备好了。
我的问题是 ，如果我们的主生产服务器上的apache发生故障（因为某种原因）很快（如果不是自动的话）开始将stream量尽可能无缝地转发到辅助服务器，那么推荐的故障转移方法是什么？
由于我们不希望在两台服务器上进行负载，实际上我们只希望次服务器在主服务器不响应的情况下接收http请求，所以我们不希望使用DNS round robing。 这部分是因为我们的镜像过程是一种方式，对辅助服务器的改变会反映在主服务器中，甚至丢失。
不build议使用DNS循环，因为：
1-不同的服务器可能不会受到相同数量的请求。 所以，他们将会以不均衡的方式加载。
2 DNS负载平衡不考虑服务器的可用性。 服务器DNlogging将保留并可能在失败的情况下使用。
3- DNScaching将使其更糟。 您无法控制客户端的DNScaching以及其间的任何中间DNS服务器。 如果您计划使您的TTL值samller，它可能无法正常工作。 看看这个post 。 接受的答案是Many DNS server do not honor your TTL 。
推荐的解决scheme是像HAProxy一样安装一个负载均衡器以及心跳等高可用性解决scheme。 这个设置应该安装在两台机器上。 如果一个人倒下，另一个人会接过VIP（心跳）。 运行的机器将负责检查后端服务器的运行状况并分配负载（通过haproxy）。
编辑：
如果您希望服务器以主动 – 被动模式工作，则不需要负载平衡器。 您可以安装心脏起搏器来监视系统资源，如apache，mysql等。群集可以configuration为只保留一个活动服务器。
在Apache之前安装nginx。 如果一个Apache服务器closures，nginx会将其排除在外，并为其他“工作人员”提供数据。
所以，安装应该看起来像这样
nginx – > worker＃1（Apache），worker＃2，worker＃3等
当然nginx应该安装在专用的盒子上。 你必须解决的一个问题 – 如果Nginx会下降，但是…
nginx网站： http ： //nginx.org
Linux虚拟服务器是一个高度可扩展且高度可用的服务器，构build在真实服务器集群上，并具有负载平衡器。
UCARP允许几台主机共享共同的虚拟IP地址，以提供自动故障转移
从我收集的信息来看，您正在寻找高可用性解决scheme – 即当一台服务器停机时，另一台服务器可以接pipe。
ThomK所build议的是一种方式，除了单点故障将是nginx盒子。 你可以看到的另一件事是使用HAProxy（甚至nginx），但也有一些基于IP的故障切换。
你可以从别处得到很多想法 。
为了在单个站点内冗余，在单个Internet Feed上，您希望将集群硬件放在您的前端，备用盒准备好接pipe失败盒子的IP地址。 但是，如果您的ISP出现故障，或者您的网站断电或遇到其他问题，您将无法使用。
如果你想防止整个网站的丢失或者ISP的丢失，那么实际上只有两种select。 一个是获取自己的BGP自治系统号码，并运行你自己的BGP路由，与几个不同的ISPs对等（好，付费运输）。 你可以做的最小的networking块是/ 24，所以你需要有一个networking块至less那么大。 如果您的主站点发生故障，您可以将不同的路由通告给其他站点。
正如您所build议的，您的其他选项是循环DNS。 有些人从理论上build议这样做，而且Windows Vista客户端非随机地select地址存在问题，但是它应该可以很好地工作，冗余备份只是将主机的stream量反向代理，除非主盒/网站/互联网Feed下降。
经过一些研究发现DNS round robining …是不可取的或推荐用于此服务。
真？ 我很乐意看到描述这个的文章。
你没有提到运行的是什么操作系统 – 这与集群的实现方式有很大关系，也没有提及你当前使用的DNS软件/改变这个有多容易。
如果你可能冒用它，我强烈推荐使用复制型集群而不是共享存储集群 – 特别是在数据不经常变化的情况下。
绑定已经提供了主/从复制，以便将数据分布在多个平台上 – 所以这只是一个将请求路由到可用服务器的方法。
对于MySQL也是如此。
使用rsync实现你的networking服务器文件是相同的。
与其他方法相比，轮询故障转移有点慢 – 它的大幅度更强大，pipe理更简单，而且比其他方法更便宜。 如果不知道你喜欢循环的原因，那么很难提出一些更可接受的build议。 （编写HA-Proxy的人推荐使用至less2个代理服务器，在HA群集前使用循环法）。
我build议你使用（至less内部）虚拟地址的主从服务器 – 这简化了促销奴隶的业务。 你甚至可能想为每个服务/集群节点使用虚拟地址。 这可以很容易地build立一个心跳地址来解决故障转移 – 这不会比循环法更快，但在减less服务的时候可以获得边际收益 – 假设它正确实施，并且可以解决分裂的大脑问题。