我有6个SQL Server实例，需要通过托pipe在两个站点（一个作为主体，一个作为DR）高度可用。 透明的自动故障转移是必需的。 大多数人都很无聊，而且没有太多的工作，有两个人被大量用于写作。
最繁忙的数据库平均每分钟处理40万次，达到900,000次，每天产生约10个新的数据。
两个站点都是一样的，都有nekpps 15k SAS iscsi sans。
目前我们有win server 2003，sql server standard 2005.同步镜像速度太慢，每次交易增加2ms。
我设法说服客户支付windows server 2008和sql server enterprise 2008，以便在两个站点之间可能有一个故障转移群集（每个群集中有一个节点），netapp正在进行跨站点复制。
你将如何完成双站点HA与单个服务器每个站点？
谢谢
如果要求真正的透明自动故障转移，并且每个事务不能处理2ms的开销，那么最好的select可能是具有非常好的负载均衡器前端（如F5 Big-IP）的双向复制。 这样，SQL Server始终都可用。
双向复制有很多缺点 – 模式更改可能会非常棘手，您必须重新修改您的标识字段（不同种子，奇数/偶数增量），而不是自我修复。 您需要进行监控，以了解复制何时停止，并且您需要全天候运行的团队才能快速行动，因为如果在两个节点之间没有看到一致的数据，客户将不会感到满意。 某些故障也可能导致数据在一个节点上而不在另一个节点上。 例如，如果复制停止工作，然后10分钟后整个服务器closures，第二台服务器将不会看到这10分钟的数据，直到您获得主要备份并修复复制。
没有什么是100％透明的。 在其他节点停止和启动期间，故障转移群集具有关联的停机时间。 如果应用程序是集群感知和/或具有重试逻辑，没有问题。 实例名称保持不变，因此在该级别上集群是透明的。
复制和日志传送具有不同的服务器名称（源/目标），因此您需要使用某种技术/别名/任何方法来抽象名称更改和/或能够更改应用程序configuration（假设它们没有硬编码名称）。 数据库镜像有一个相似的故事，但是如果应用程序被编码到SNAC，您可以使用Witness自动故障转移。
DBM / log shipping / repl还要求您同步不在数据库之外的对象，并确保备用服务器具有所有需要运行的对象（包括实例级别的login）。
所以只有具有Witness和高安全性的故障转移群集和DBM才能为您提供自动故障转移function。 这并不意味着透明。
没有一个绝对正确的方法来做到这一点。 它基于您的要求（包括总体SLA，RTO和RPO）。
如果您在镜像时遇到问题，可能是I / O和/或networking相关的问题。 它可能与SQL无关。 所以，当你看到一个新的架构，确保你评估的解决scheme的各个层面。
我build议你将文件共享见证与Windows Server 2008中的群集结合起来使用（如果你需要R2，我不记得我的头顶）。我没有亲自做过这个，但是去年夏天我花了一些时间来看。
如果有人相信营销和Netapp有适当的软件，它应该提供站点到站点故障转移。 是否可以处理这些交易量是一个担心，但责任将在networking上，并将其连接在一起。
请注意，如果没有用户应用程序本身的支持，“透明自动故障转移”可能无法实现。 如果你已经在做镜像，这可能不是一个问题。