基于磁盘的备份

　　首先来看的是最简单的技术——备份。在SQL Server 2008的企业版中，备份有了一个新的特性，那就是备份压缩。那么备份压缩对于高可用有什么帮助呢?

　　那么就要提到现在业界非常流行的一种备份解决方案——磁盘备份解决方案，有很多与该解决方案相近的名称：在线备份、虚拟磁带库等等。这些方案其实都是基于一个思想，将数据备份到快速的在线磁盘设备上，这样就可以利用磁盘的高速IO和高速检索能力。不过磁盘的高昂代价往往是这种企业在这一解决方案面前驻足不前的主要原因，而现在SQL Server 2008企业版中的备份压缩可以大幅度减少备份后的文件尺寸，因此基于磁盘的备份解决方案看起来也更加有竞争力了。

　　基于磁盘的备份带来最大的好处就是利用磁盘高速IO的能力进行快速的还原。这就可以缩短数据库服务离线的时间，同时也可以减少数据库备份这一维护操作对应用的影响。

　　数据库镜像+故障转移集群

　　上面我们介绍的故障转移集群、日志传送亦或基于磁盘的备份都是作为单一技术出现的，而在真实的大中型企业环境中为了确保数据应用的持续在线，我们通常有一些组合多种高可用技术的方案。通过混合不同可用性技术，我们将可以采长补短。

　　例如数据库镜像技术。

　　虽然数据库镜像可以解决故障转移集共享存储存在单点失效威胁、依赖于特殊硬件等一系列的问题，但是数据库镜像最大的问题就是故障转移路径过短。对于大中型企业来说，仅有两个节点的故障转移路径有些不足。因此通过增加一个故障转移集群作为数据库镜像的镜像节点就可以解决了数据库镜像故障转移路径过短的问题。

　　上面这种解决方案当主体服务器失效后，数据库镜像会将启动镜像节点，而由于镜像节点是由一个故障转移集群承担的，因此当镜像节点中的一个节点失效后还有一个后备节点，因此还可以有一个后备节点承担。

　　其实故障转移集群和数据库镜像是各有利弊，因此这两种技术融合在一起后的解决方案不仅仅是上面这一种，下面就给出另外一种解决方案的示意图：

　　细心的读者可能会发现，方案二种没有了见证节点，这意味着从主集群切换到镜像集群需要手动完成。那么为什么这种解决方案中没有了见证节点呢?

　　因为数据库镜像和故障转移集群都拥有自动故障转移的特性，如果两种技术的自动切换都生效的话，那么在主体集群的活动节点失效后就会有两个节点同时试图生效——主体集群的后备节点和镜像集群的活动节点，那么结果就只有一个，数据库镜像会话失败。

　　远程故障转移集群

　　对于某些跨地区甚至是跨洲的大型集团来说，站点失效这个困扰会逐渐进入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系统需要面对的不仅仅是这些巨大的灾难，还有飓风、火灾、硬件故障、软件缺陷、人为破坏，甚至是例行维护。因此规划和实施有效的可用性方案算是未雨绸缪，当遇到真正的突发事件时，才能避免花费成百数千倍的代价去弥补。