SQL Server的“高可用性”与“灾难恢复” 之六 高可用和灾难恢复技术的选择

分享到:

2015-02-28 21:20:56

过前面的介绍,相信你对各种高可用和灾难恢复技术已经有一定程度的了解。这些技术都已经被广泛的应用在了全世界的各种企业环境中,为应用持续运行提供保障。

高可用和灾难恢复技术的比较

每一种技术都有其优点和局限,这些因素决定了它适用于怎么样的环境。要比较各种不同的高可用和灾难恢复技术,就要了解它们的优点和局限。这样才能根据你的需求选择最合适的一款。

故障转移群集

故障转移群集是SQL Server最早的高可用技术,它的功能也随着每次SQLServer的版本升级而得到加强。它的优势包括:

-      得益于Windows故障转移群集,SQL Server故障转移群集可以自动检测SQLServer的健康状况,并在发生故障的时候自动进行切换。

-      切换所需的时间基本等于SQL Server服务重启的时间,如果没有太大的事务需要前滚,SQL Server可以很快完成数据库恢复并继续提供服务,停机时间一般比较短。

-      提供了一个虚拟网络名给客户端。对客户端而言,当前是群集的哪个节点在运行SQLServer是完全透明的。服务器发生故障切换后,客户端能够自动切换连接,不需要修改任何配置。

-      从SQL Server 2008开始,你可以现在非活跃节点上进行升级维护的工作,然后手工故障转移到这个升级后的节点,最后再升级维护之前那个活跃节点。于是整个升级维护带来的停机时间,只是SQLServer做一次故障转移(failover)所花的时间。

故障转移群集的限制包括:

-      由于节点间使用的是共享磁盘,数据库只有一份。一旦数据库损坏,或者共享磁盘出现故障,整个SQLServer就瘫痪了。可以说故障转移群集完全无法提供灾难恢复的功能。

-      非活跃节点上的SQL Server实例完全处于停止状态,不能提供给报表等程序使用,无法分担活跃节点的负载,浪费了一定的硬件资源。

-      实施成本相对较高。群集需要标准版或以上的SQLServer和Windows Server。用来实施Windows群集的硬件以及硬件设置必须符合微软的硬件兼容列表的要求(Windows 2003群集)或者通过Windows群集验证工具的检查(Windows 2008群集),否则群集无法建立。

-      故障转移群集发生在整个实例范围。个别数据库的问题可能会触发整个实例故障转移,导致那些“无辜”的数据库也发生了短暂的停机。

-      维护群集环境需要额外的成本。举例来说,对于一个活跃/非活跃模式的SQL Server实例,每次对这个实例进行维护的时候,都需要同时维护两个节点来保持两个节点一致。相对单机而言,维护成本上升了一倍。

-      虽然群集支持将几个节点部署在相隔很远的物理位置,但是这种部署都网络和存储的要求迥异于普通的群集,实施的成本会高很多。

日志传送

日志传送一直以其“物美价廉”的特点而获得SQL Server用户的青睐。虽然它的功能不是最强大,但是它简单易用的特点和几乎不给主服务器带来额外负担的特性,使得它依旧是生命力非常强大的技术。日志传送可以用于补充或替代数据库镜像。虽然异步数据库镜像与日志传送在概念上很相似,但它们仍有很大差异。日志传送的优势包括:

-      辅助数据库可以设置为只读模式,在上面可以运行例如报表之类的只读应用,能够一定程度上分担主数据库的负担。

-      支持多个冗余数据库副本。针对单个主数据库可以在多个服务器实例上配置多个辅助数据库,只读的辅助数据库用于报表,而处于还原模式的辅助数据库作为灾难恢复的备用数据库库。

-      日志传送所需的软硬件成本低,工作组版本的SQLServer就可以使用日志传送,对硬件也没有特殊的要求。

-      由于使用的是备份/还原的方式来同步主数据库和辅助数据库,且备份操作的执行有一定的时间间隔,因此对主服务器的性能带来的额外开销比较小。

-      如果日志传送的备份/复制/还原作业设置的相对较长,则意味着主数据库和辅助数据库间的同步间隔较长。如果主数据库上的数据被误操作意外更改或删除,由于较长的同步间隔,您可以在辅助数据库上得到仍未更改或删除的数据。管理员可以用辅助数据库上的数据,恢复误操作。

-      日志传送的工作原理决定了它对网络的速度和可靠性的依赖程度相对较低,可用于非常远距离的异地灾备。

-      较简单的实现机制,一旦日志传送不能正常工作,问题排查起来相对简单。

再来看看日志传送的局限所在:

-      不支持在不同版本SQL Server间实现日志传送。

-      无论把作业执行的间隔设置的多短,日志传送都不能达到完全的数据同步。也就是说一旦主数据库发生故障,你有可能会损失一部分数据。相比较而言,同步模式的数据库镜像可以做到完全同步,确保在主体数据库出现故障时,不会有数据损失发生。

-      日志传送不提供自动侦测和解决故障的能力,无法提供自动故障切换。主体数据库发生故障后,管理员必须人工发现问题,然后手动执行故障转移才能解决问题。整个故障转移的操作步骤相对较繁琐,停机时间较长。

-      日志传送。一旦执行了故障转移后,日志传送就被破坏了,需要重新建立。

-      不能为客户端提供一个自动切换的连接接口。当发生故障转移后,客户端需要做手动干预才能被重定向到新的服务器。

-      虽然辅助数据库可以被配置为“只读”。但是在还原作业正在进行还原日志操作的时候,整个数据库是不可用的。所以辅助数据库不是每时每刻都能够被访问的。

-      日志传送提供的同步是以数据库为单位的。你无法使用日志传送来仅同步一个数据库中的部分对象,也无法同步系统数据库。

数据库镜像

很多用户对数据库镜像技术给予厚望,因为它是SQL Server第一个同时能够实现高可用性和灾难恢复的技术。也就是说,它既能够在系统发生故障时,实现一定程度上的自动切换,也能够提高数据冗余拷贝,预防数据库损坏灾难。在它身上,集合着故障转移群集和日志传送的优点。具体来讲,它的优势有:

-      数据库镜像提供了一个自动化的、完全同步或者基本同步的数据库副本。配置了镜像,就能在镜像服务器上得到一份和主服务器上一模一样的数据库备份。只要镜像工作正常,这两份数据完全一致,或者差距不大。这个比自己配置备份恢复任务要省心,效率也比较高。一旦主数据库出现故障,你可以用这个副本进行灾难恢复,而不会承受(或者承受很少的)数据丢失。

-      在高可用操作模式下,数据库镜像会在侦测到故障时自动经行角色切换,其高可用性可以和群集技术媲美。在高保护操作模式/高性能操作模式下,虽然需要人工干预执行切换,但是其切换的速度比日志传送要快很多,难度也低。

-      数据库镜像的故障转移是数据库级别的,发生角色切换后,只要数据库完成恢复操作就可以正常使用。相比较群集的实例级别的故障转移,数据库镜像切换的速度更快。

-      在客户端使用SQL Native client或者ADO.NET的时候,客户端能够在连接字符串中加入failoverpartner属性,这样客户端就知道了镜像数据库的名字。当发生镜像数据库自动角色切换后,客户端会根据连接重试算法自动重定向到新的主体服务器上,不需要人为干预来手动重定向客户端到SQLServer的连接。

-      同步模式下,数据库镜像能确保两个伙伴服务器完全同步,就算发生故障转移也不会有数据损失。而异步模式下,数据的同步也远比日志传送更快。

-      数据库镜像对服务器的硬件和硬件配置没有特殊要求。

-      在对SQL Server进行升级的时候,你可以先升级镜像服务器,然后手动执行镜像角色切换,再升级新的镜像服务器。这样停机时间可以缩短为一个故障切换的时间,提高了数据库系统的可用性。

但是,数据库镜像技术还不能完全替代故障转移群集和日志传送技术。它的局限性主要表现在:

-      主体数据库和镜像数据库必须是相同版本的SQLServer。这个限制故障转移群集和日志传送也都有。

-      一个数据库镜像管理和切换的是一个数据库。数据库镜像无法使多个数据库一起切换,这个对于需要同时使用多个数据库的应用,其高可用性还不够完全。

-      数据库镜像的同步是以数据库为单位的。你无法使用日志传送来仅同步一个数据库中的部分对象。

-      一个主体数据库只能配置一个镜像数据库。不支持多个冗余数据库副本。

-      系统数据库无法配置数据库镜像。因此,登录、SQLServer实例的配置、维护计划、作业等保存在master、msdb或 model数据库里的信息不能自动同步到镜像服务器上,需要管理员事先同步好。

-      对于非ADO.NET和SQL Native Client的客户端,在镜像发生切换后无法自动重定向到新的主体服务器。对于那些以前开发的使用ADO.NET和SQL Native Client的客户端,如果要获得自动重定向的特性,也需要修改连接字符串加入failoverpartner属性。从这点上来讲,数据库镜像还是达不到群集技术对客户端那样的透明度。

-      内部实现机制复杂。一旦数据库镜像没有按预期那样的工作,故障排查的难度比较高。

-      镜像数据库是不可访问的,无法在上面运行报表程序来分担主体服务器的负载。一个变通方案是给镜像数据库做做一个快照,然后在快照上运行报表程序。不过这样一来报表程序获得的数据必定滞后于实际的数据。

-      在同步模式下,为了实现零数据丢失,会在主体数据库上使用延迟提交,这一定程度上影响了主体数据库的性能。

-      同步模式虽然实现了零数据丢失,但是对网络的速度和可靠性要求非常高,因此不适合作为一个远距离的异地灾备方案。

-      在负载较高的情况下,对镜像服务器的磁盘性能,主体服务器与镜像服务器间的网络速度及可靠性的要求比较高。

事务复制

正如前面提到的,复制本身并不是一个很好的灾难恢复技术。复制更适合用于纯粹的数据同步目的,而不应该优先考虑其作为灾难恢复方案的一部分。前面已经列出了事务复制作为灾难恢复方案的局限所在。这里我们把事务复制的优势和局限再总结下。事务复制的优势在于:

-      事务复制可以实现数据库对象级别的数据同步,你甚至可以筛选表中的部分数据来同步。也就是说主数据库可以只给灾备数据库提供其数据的子集。

-      灾备数据库可以访问,因此可用于报表等只读功能,分担主服务器的负载。

-      由于灾备数据库始终处于可以访问的状态,故障转移比较简单,仅需要重定向客户端即可。

-      支持多个冗余数据库副本,可用于灾难恢复。

-      使用推送订阅并将分发代理配置为连续发送的情况下,数据同步的速度快于日志传送。

-      对网络要求较低,可用于远距离的异地灾备方案。

-      主数据库和灾备数据库可以使用不同版本的SQLServer。

限制:

-      复制不提供自动侦测和解决故障的能力。主数据库发生故障后,你必须自己发现这个问题,然后手动执行故障转移操作才能解决问题。一旦执行了故障转移后,复制就被破坏了,需要重新建立。

-      不能为客户端提供一个透明的连接接口。当发生故障转移后,客户端需要做手动将客户端重定向到新的服务器。

-      无法像同步模式的数据库镜像那样提供完全零数据损失的保障。

-      内部实现机制复杂。一旦事务复制运行出现故障,排查的难度比较高。

-      复制的运行机制给主服务器带来较大的开销。同步的过程涉及到多个实例和代理程序,这带来了一定的同步延迟。

-      复制是在订阅服务器端建立一个ODBC或OLEDB的连接,然后执行保存在分发数据库中的命令来重做事务。而日志传送是使用还原日志的方法来重做事务。因此,日志传送在灾备服务器上重做事务的速度会快于事务复制。

-       复制对表的定义有要求。在已经上线的系统中使用复制功能可能会带来一些二次开发的工作。

-      与数据库镜像和日志传送不同,订阅数据库本身不限制写操作。订阅服务器上的数据存在被人错误改写的风险。而且很可能你完全没意识改写的行为的发生,在进行故障转移后就使用了错误的数据。

选择高可用和灾难恢复技术是个系统工程。没有一种技术是完美无缺的,都有自己最擅长的领域和不适合的领域。在选择技术之前,你首先要将明确自己的关键需求,有了需求才能找到最合适的技术。大多数情况下,鱼和熊掌不可兼得,完全同步和性能之间总是有一个要妥协的。这个时候就你对自己需求有个清楚优先级,哪些是不容妥协的,哪些是可以放宽的。经过这样一个筛选的过程就一定能找到符合自己要求的高可用和灾难恢复方案。

下面的表格(2-5)中横向罗列了各种技术之间的关键区别,希望能有助于你决定哪个技术更符合你的需求。

 

 

功能

故障转移群集

日志传送

数据库镜像

事务复制

保护级别

实例级

数据库级

数据库级

数据库对象级

是否有数据损失

/

可能有少量数据损失

无数据损失(同步模式)

可能有少量数据损失

自动故障转移

是(高可用操作模式)

故障转移后是否可逆

对客户端是否透明

是,自动重连接到相同IP的另一个节点

是,自动重定向(需要驱动程序支持)

停机时间

约等于SQL Server服务重启的时间+数据库恢复时间

较长

约等于数据库恢复时间

较长

多个备用数据副本

备用数据副本可读

/

能抵御用户误操作

能抵御磁盘故障

是否有特定硬件要求

windows群集

要求有较好的磁盘和网络

对性能的影响

版本支持

SQL Server 2000及以后

SQL Server 2000及以后

SQL Server 2005及以后

SQL Server 2000及以后

 

 

高可用和灾难恢复技术的组合

当某个单一的技术不能完全满足你的需求时,你可以考虑将几种技术组合起来,以此实现更强大的高可用和灾难恢复的方案。技术组合的目的是扬长避短,将几种技术的优势组合起来,弥补单一技术的不足。不过,作为获得更强大的功能的代价,你也需要投入更多的硬件资源来实现这些方案。接下来我们就来看看一些比较典型的组合。

故障转移群集+日志传送

这个组合是在数据库镜像出现之前最常见的方案。故障转移群集提供了非常好的高可用性,但是对于数据损坏问题却非常脆弱。日志传送提供了灾难恢复的功能,但是在高可用性上很薄弱。它们两者的互补性非常强。

整个方案需要至少3台服务器。两台服务器用于实现故障转移群集,可以抵御SQLServer服务突然出现故障的情况。故障转移群集实例需要被配置为日志传送的主服务器,而第三台服务器作为日志传送的辅助服务器维护一个冗余的副本数据库。一旦故障转移群集的数据库出了问题,你有两个选择:

(1)    将第三台服务器(日志传送的辅助服务器)上的数据库恢复使其上线。将应用程序重定向到这台服务器上。如果故障转移群集上数据库的问题是由于磁盘问题导致的,短期内很难解决,这个选择会比较合适。这个选择需要你在发生故障转移后将应用程序重定向到新的主服务器上。

(2)    将第三台服务器上的数据库复制到故障转移群集实例上,替代损坏的数据库上线。这个方案适用于仅是数据库文件损坏而磁盘系统正常的情况。虽然复制数据库可能需要花费一定的时间,但是好处是不用重定向应用程序,而且问题解决后你的SQLServer依旧拥有群集提供的高可用性。

另外要注意的是,一旦做过日志传送的故障转移,日志传送就被破坏了。因此无论你的选择上面哪种办法,都要在完成灾难恢复后重新配置日志传送。

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

由于日志传送无法实现主数据库和辅助数据库的完全同步,因此故障转移群集+日志传送的组合在执行灾难恢复的时候可能会有一定的数据损失。为了弥补这个缺陷,从SQL Server 2005开始,你可以选择故障转移群集+数据库镜像这样的组合。数据库镜像替代日志传送,提供了数据损失更少(甚至是零损失)的灾难恢复能力;同时也可以提供更快的故障转移,提高了可用时间。

当镜像与群集一起使用时,你有三种部署的方案:

1.  两台服务器的方案。两个服务器配置成一个群集,在该群集上安装两个SQLServer实例,分别运行在两个节点,即所谓的活跃/活跃模式。而镜像的主体服务器在其中一个实例上运行,镜像服务器在另一个实例中运行。这个方案虽然很省硬件但是风险也很大。一旦某一个群集节点失败,就会造成镜像的主体服务器和镜像服务器运行在同一个节点上,该节点的硬件资源很可能捉襟见肘,严重影响主体服务器的性能。另外,主体服务器和镜像服务器作为一个Windows群集上的两个实例,意味它们其实是共用一个硬件存储器的。一旦这个存储器出了问题,那么主体服务器和镜像服务器上的两个数据副本就都不可用了,灾难恢复和高可用也无从谈起。

2.  三个服务器的方案。这个方案中,故障转移群集作为主体服务器,而镜像服务器驻留在一个单独的非群集的服务器上。

3.  四台服务器的方案。四台服务器分别组成两个故障转移群集,一个群集作为镜像的主体服务器实例,另一个群集作为镜像的镜像服务器实例。最佳情况下,这两个群集使用两个独立的存储器,避免存储区损坏导致整个方案失败的可能性。

数据库镜像的故障转移是可逆的,因此在解决故障后可以比较简单地将一切都恢复到出问题前的样子。另外,对于使用ADO.NET和SQL Native Client的应用,无论是使用哪种方案,无论是镜像还是群集发生了故障转移,都不需要重定向连接。

当决定如何在群集环境中配置数据库镜像时,所使用的镜像操作模式至关重要。

·        高可用操作模式

如果镜像使用这种操作模式,你可以选择上述第三种方案,因为该方案提供了最高的可用性。见证服务器可以安装在一个第三个群集上或一个非群集的服务器上。

假设现在有两个群集:ClusterA和ClusterB,还有另一台非群集的服务器ServerC作为见证服务器。ClusterA上的SQL Server实例作为主体服务器,而ClusterB上的SQL Server实例作为镜像服务器。如果ClusterA的活跃节点失败,将在几秒钟内先开始进行数据库镜像自动故障转移,同时群集也会开始启动故障转移。数据库镜像的故障转移完成后, ClusterB就从镜像服务器变为了主体服务器。在ClusterA群集故障转移完成(通常需要几分钟)之后,ClusterA的SQL Server就被切换到另一个节点,并且该实例变为了镜像服务器。这样配置的优点在于:

(1)  镜像的故障转移速度比群集更快,因此停止时间更短。

(2)  一旦在短时间内ClusterB也出了问题,而原来ClusterA的活跃节点上的故障还没来得及解决,SQL Server还能切换到ClusterA上新的活跃节点继续工作。如果是单机环境的数据库镜像就无法实现这点。

 

·        高保护操作模式

这种操作模式下,第二种方案和第三种方案都适用。你也不需要额外的服务器做见证服务器。

假设现在的环境是一个群集ClusterA和一个非群集的服务器ServerB。ClusterA作为主体服务器而ServerB作为镜像服务器。一旦ClusterA的活跃节点失败,并不会发生数据库镜像的故障转移,而是等到ClusterA的群集故障转移完成后,Cluster新的活跃节点继续维持主体服务器的角色并和ServerB维护镜像对话。

这种方案和单纯的故障转移群集相比,通过数据库镜像获得了额外的灾难恢复的能力(镜像数据库提供数据库副本)。但是就高可用性而言,该方案和单纯的故障转移群集差别不大。另外,如果群集的两个节点都失败了,整个数据库就不可用了,你需要手动的执行镜像的故障转移才能解决问题。

·        高性能操作模式

此操作模式的部署方案基本和高保护模式相同。区别是你可以考虑将主体服务器放置在群集的故障转移群集实例中,而将镜像服务器放置在远程位置的非群集服务器上,这样实现了异地灾备。

故障转移群集+数据库镜像+日志传送

故障转移群集+数据库镜像已经能提供非常高的可用性和不错的灾难恢复能力了。不过如果你觉得还是不放心,对于你的关键应用来说每一分钟的意外停机时间都会带来的巨大的损失,那你需要一个更加强大的方案。下面这个方案可能对你有帮助。

1.  你的主机房设在城市A,在主机房内,你选择使用故障转移群集+数据库镜像的第三套方案,即双群集和数据库镜像的方案,这样可以提供最好的高可用性。

2.  由于双群集都在一个机房里,当面临一些不可抗的因素,比如全市范围的停电,整个SQLServer系统还是会受到影响。为了进一步提高可用性和抵御灾难的能力,你可以为数据库镜像的主体数据库配置日志传送。主体服务器作为日志传送的主服务器,然后为其配置一个或多个远程的辅助服务器。你可以考虑配置两个远程的辅助服务器,一个设立在离城市A比较近的城市B,另一个设立在离城市A很远的城市C。这样你的数据在面对一些自然灾害时也有了一定的抵御能力。

3.  若要使日志传送在数据库镜像故障转移后仍能继续进行,还必须使用相同的配置将镜像服务器也配置为日志传送的主服务器(使用同样的备份共享目录,同样辅助服务器等)。由于镜像数据库平时处于还原状态,这样可以防止备份作业备份镜像数据库中的日志。这确保了镜像数据库配置的日志传送不会影响主体数据库的日志传送。

4.  如果数据库镜像进行故障转移,以前的镜像数据库将作为主体数据库并联机。此时,该数据库也将作为日志传送主数据库进入活动状态。以前无法在该数据库中完成的备份作业也将开始执行备份并传送日志。相反,故障转移将使以前的主体数据库进入还原状态,同时该数据库上日志传送的备份作业也将停止备份日志。 

这种方案可靠性最高,代价是硬件成本和维护复杂度也很高。

 

声明:此篇为用友服务中心文章,转载请标明出处链接:
  • 相关文章
  • 热门下载
  • 数据修复
  • 热门标签
合作伙伴