远程故障转移集群

  对于某些跨地区甚至是跨洲的大型集团来说，站点失效这个困扰会逐渐进入IT主管和DBA的脑海中。

  不过远程故障转移集群就不仅仅是SQL Server一个人就能完成的了，这个方案要依赖于SQL Server，Windows Server这些基础软件，还要依赖于存储设备、交换机、服务器这些硬件。

  因为在远程故障转移集群中，共享储存不再存在于一个数据中心，而是可能相距数十公里，甚至数千公里，因此中长距的底层存储同步往往是这一解决方案的关键。对于中长距的底层存储同步，通常分为两种，一种是在30公里内的，通过单模光纤可以实现两个数据中心存储设备间的同步复制，而另外一种则是在30公里之外了，而这种情况通常都是通过租用ICP的线路来实现两地间的异步复制。

  听上去好像很复杂，不过不用担心，EMC这样的厂商有非常成熟的硬件设备以及相关软件。这就是为什么在SQL Server的Always On中会出现EMC这样第三方厂商名字的原因。

  远程故障转移集群的替代方案

  哦，天哪！我们讨论的解决方案似乎越来越贵。我可不希望这样结束。

  其实对于远程故障转移集群来说，主要解决的问题是站点失效的问题，因此单纯使用SQL Server的功能也可以解决这个问题。尽管没有基于硬件的那么高效和稳定。

  那么怎么构建一个相对廉价的远程容灾方案呢？我们的答案是故障转移集群+日志传送/复制。在不提到这两项技术的话，他们两个一定会有意见的。

  日志传送依赖于日志备份以及还原来实现数据同步的，而复制呢，除了日志外多了一个快照(注意：复制中使用日志的方式与日志传送是不一样的)。因此我们只要确保主服务器的日志能够以一个合理的频率传送给远端的后备服务器，我们就可以提供一定程度上远程容灾能力了。

  可是在SQL Server 2005之前，复制和日志传送都有一些小问题，日志传送是依赖于日志备份作业、日志传送作业和日志还原作业，因此日志传送无法做到连续性，他的嘴短同步间隔是一分钟，无法再短了。事务复制尽管能做连续，但是事务复制有主从之分，如果是多站点这项技术会严重限制后备服务器的自治能力。

  不过从SQL Server 2005开始，事务复制有了一种新的模式，叫做对等事务复制。对等事务复制平等看待参与复制的所有节点，而取消了主从之分。这就给我们的多站点数据服务规划指出了一条新的道路。

  不过大家在这张有些夸张的图里面也许可以看出些端倪。通过对等事务复制，我们确实可以设计出一个非常复杂的数据复制拓扑，利用高速/低速线路，优质/常规线路，我们可以在分布于多个站点的服务器之间构建出一个复制拓扑。说上面这张图是开玩笑，原因是通常复制拓扑不会这么混乱，但是对等复制一定可以制成这张图上出现的服务器数量，关键是要良好规划和设计。

  算了，给张清楚点的吧。这是一个比较真实地对等复制拓扑，我们有两个站点。站点内拥有高速的链接，而站点间则是相对低速的租用链路。A、B、C分别是三个应用的数据库，A和C是本地性应用，因此仅在单个站点内进行了复制，保证其容灾能力，而B是一个集团性的应用，为了确保其数据的可用性，因此在站点内和站点间分别实现了复制冗余，同时站点A和站点B可以互不干扰对数据的使用(当然这要依赖于数据库的设计和对等复制链路的配置)。

  SQL Server 2008在对等复制方面也有一个小小的改进，那就是冲突检测。在SQL Server 2005的对等事务复制中，冲突是一个非常头疼的事情，因此才会要求非常严格的数据访问隔离设计。SQL Server 2008会在发生冲突的时候暂停复制，既保证了两个站点间的正常数据访问，也保证了在数据冲突时不会错误覆盖正确的数据版本。

  结束语

  其实SQL Server的可用性和数据应用的可用性完全是两个层面的事情，SQL Server仅仅是数据应用中的一个组成部分，因此如何达到真正的系统可用性，还要考虑更多的问题，通讯(交换机、路由器之类)、网络服务(DNS、DHCP之类)、操作系统、应用服务(IIS、中间件服务器)，还有很多很多的问题。
  美国人遭遇了911，我们遭遇了512，除了沉重的伤痛之外也留给我们许多需要思考的问题。尽管对于很多IT来说，911和512似乎很遥远，不过我们也讨论到了IT系统需要面对的不仅仅是这些巨大的灾难，还有飓风、火灾、硬件故障、软件缺陷、人为破坏，甚至是例行维护。因此规划和实施有效的可用性方案算是未雨绸缪，当遇到真正的突发事件时，才能避免花费成百数千倍的代价去弥补。