随着企业IT规模的不断扩大，各大企业开始不再仅仅考虑单个服务器节点的灾难恢复，而是考虑到整个数据中心的灾难恢复，一旦我整个数据中心都出现灾难，我应该怎么去恢复，因此这两年很多企业都意识到了这一点，开始在同城或异地建立多个数据中心，以实现数据中心级别的全面高可用，灾难恢复，那么在制定这种灾难恢复过程中会遇到的一些问题，应该如何制定灾难恢复计划，如果使用微软WSFC作为灾难恢复方式，我应该如何去考虑，有哪些需要注意的地方，就是我们今天需要讨论的话题。

首先，谈起灾难恢复，很多企业想过要做，但是一些情况下，做了灾难恢复方案，但是最终灾难发生的时候，却没有成功，其原因大概有三

1. 灾难恢复机制未生效

2. 没有明确的灾难恢复计划，操作人员未进行测试，导致延迟灾难恢复时间

3. 未实现自动化机制，灾难发生时需要手动操作，人员因为灾难发生无法进行操作

总结来看，不外乎两点，1.灾难恢复计划未经过周密测试 2.灾难恢复机制未实现自动化机制

自动化技术是IT运维的利器，可以帮助我们节省很大效率，一些时候我们应该去使用自动化，但也不应该全部使用自动化，不过在灾难恢复领域，当我们真正去采用一个灾难恢复方式时，一定要越自动化越好，就是说，我这个灾难恢复方案，在恢复的时候，越少通过人为操作越好，理想情况下，我们应该是实现既定的一套灾难恢复机制，灾难发生时一切自动化执行，应用恢复，如果灾难恢复过多依赖人为操作，则这不一定是个很好的方案，因为一旦真的灾难发生，人不一定能够第一时间到现场恢复应用。

所以，当我们要做异地数据中心时，一定要认真的坐下来，定好灾难恢复的计划，定义灾难恢复计划 我们首先要考虑以下几个内容

1. 灾难发生后，我们应该做那些事，完成那些目标，如何尽快达成这些目标

2. 这些事情的优先级顺序是怎么样的，我应该先做那件，后做那件

3. 这些事情应该有那些人做，是否每件事情都在由最合适的人做，每个步骤每个人是否有备岗

4. 执行灾难恢复的具体步骤，应该是形成标准化手册。

大体内容想好了后，我们就可以开始制定具体的灾难恢复计划，一个完整的灾难恢复计划至少应该包含以下内容

灾难恢复的范围：定义灾难恢复的范围，范围越大，这里要写的内容就越多，数据中心，下面的服务器，上面的应用，等等。

灾难恢复系统相依性：此处以业务系统级别为主，按照应用系统级别来看每个系统的依赖性，便于我们制定恢复策略流程

灾难恢复策略：根据灾难恢复范围和依赖性的定义，编写恢复策略，每一个系统，每一个组件，灾难发生时应该如何恢复，使用什么方式，应该按照怎么样的顺序，如何操作，操作完成后如何验证，如何规避风险。

灾难恢复方式：具体灾难恢复策略执行时要使用的方式：可以是手动，高可用群集，复制副本，备份，等等，尽可能采用业务系统支持的，人员熟悉的，自动化的方式。

紧急联络方式：灾难恢复干系人，领导负责人，灾难恢复操作人员，应用验证人员的联系方式，确保可以第一时间联系到

灾难定期演练 : 灾难恢复一大部分没有成功的原因就是因为缺少定期演练，导致灾难发生时，既定的灾难恢复计划失效，不能得到执行，因此灾难定期演练事关重要，建议最少每年执行一次灾难演练

灾难重现 ：如果能做到这一点最好，每次灾难恢复演练后，或实际的灾难恢复后，要求操作人员，或灾难恢复小组，将此次灾难恢复过程进行记录，事后回看，是否按照计划执行，还有那些可以优化的地方，作为宝贵的知识。

以上，老王结合自己的一点学习，为大家总结的灾难恢复基本理论，之所以要写这些呢，是因为老王看到很多企业明明想要做多地数据中心，想要做双活数据中心，灾备数据中心，但是一拍脑袋就做了，没有事先规划好，也就没有意义，希望看到的朋友可以有所收获，在制定灾备数据中心的时候可以带来一些帮助。

那么，我们今天主要谈的是灾难恢复的方式，微软对于灾难恢复的方式有很多，hyper-v复制，备份，WSFC群集，ASR，等等，都可以做灾难恢复的方式

其中我们今天关注的就是WSFC群集，WSFC用于多站点数据中心群集，它有一个好处，就是WSFC系统本身，是可以实现完全自动化的故障转移机制的，只要群集得到正确的配置，故障发生时，WSFC会自动的进行切换，不需要人为干预，除非你WSFC群集上面跑的应用，需要故障转移后额外做配置。

WSFC真正开始对于多站点数据中心支持的是WSFC 2008，在2008时代，WSFC开始支持多子网的群集架构，即是说，你可以北京两个节点是10网段，上海两个节点是20网段，也可以允许你创建一个群集，北京节点崩溃时候，应用也可以漂移到20网段的上海上面继续工作，而在2003则不可以，2003时代所有群集节点必须是同一子网。

实现多子网技术，最关键的是2008时代WSFC开始支持群集组网络名称依赖关系自定义了，对于一个群集组，我们可以让网络名称对应很多个子网的IP地址，这些不同子网IP地址可以是OR关系，只要其中一个能够联机注册，那么应用就可以正常提供服务。当故障转移之后，在另外子网地址联机注册名称，应用切换到另外子网地址提供服务。

在WSFC 2008时代，虽然WSFC本身实现了对于多子网的支持，但是一些群集上面的应用却并不能很好的支持多子网，例如SQL 2005，SQL 2008，Hyper-V 2008实时迁移 ，虽然我们部署了多子网的群集，但是这些应用却并不支持多子网，依然也没有意义，SQL2008R2，Hyper-V 2012后，一切都得到了改善。

在我们考虑WSFC多站点时，我们主要可以从以下几个方面来看

1. 网络

2. 仲裁

3. 存储

网络

对于WSFC多站点网络，我们首先要思考，整个多站点环境采用什么样的网络架构

1. 多子网

不同站点的节点，是否要使用不同子网，如果使用不同子网，上层应用是否支持，是否会带来额外的手动操作，多子网是对外网络多子网，还是心跳网络也要多子网，如果心跳网络多子网如何通讯，是否需要添加静态路由。

 2.延伸VLAN，网络打通

不同站点的节点，网络已经打通，不需要各节点使用不同子网，所有节点都在一个子网，这种方案，对于群集，应用来讲最为省事，支持度最好，但是可能网络人员会需要额外进行一些配置。

多站点群集网络环境下的思考

1. 跨站点心跳检测阀值

由于群集部署为多站点，其间网络肯定会多或少会有一些延迟，如何调整心跳检测阀值为最合适，这里的心跳检测阀值为最关键，一旦由于网络延迟，或网络质量，导致心跳检测阀值达到，将会触发故障转移，因此务必要确保网络质量可靠，并根据实际的网络延迟情况调整最为合适，最能准确反应故障的检测阀值，如果多站点网络架构使用延伸VLAN的方式，可以使用WSFC 2016里面的跨站点阀值定义功能

2.跨站点群集通讯是否加密

默认情况下同一子网内节点群集通信，将会被签名，通常情况下不需要更改此内容，如果说您的群集架构是跨站点，会经过internet，您可以把群集通信安全级别改为加密，这样群集间通信会通过加密，更为安全，如果您的跨站点架构，是通过单独的安全通道构建，那么您也可以取消签名和加密，需要注意的是取消群集通信签名和加密会带来性能提高，如果采用群集通信加密，会带来一点点的性能下降，因为节点每次收发流量都会多一个加密解密的过程，如需更改，建议事先做好测试，确认加密后性能带来的下降可以接受，再更改为加密

3.多子网环境下VM如何连接

如果我们在多子网的环境下部署了虚拟机，那么虚拟机的网络连接是个问题，如果虚拟机在北京站点配置的静态IP，是通过北京虚拟交换机出去的，到了上海子网不同，虚拟机原有IP将无法通信

因此，对于多站点环境下的VM，我们通常有以下几种办法

1. 针对虚拟机使用DHCP IP地址

2. 针对虚拟机使用静态IP，但是在虚拟机内部编写脚本，一旦检测到网络环境发生改变，即切换为目标静态IP

3. 针对多站点环境使用延伸VLAN网络架构，虚拟机接入同一个子网

4. 针对虚拟机使用网络虚拟化功能，让虚拟机带着IP迁移到不同站点

在Hyper-V复制中和ASR中又更好的解决方案，可以实现灾难恢复后自动设置虚拟机为目标IP，因此对于虚拟化的灾难恢复，如果考虑到多子网WSFC不太方便，您也可以选择Hyper-V复制，或ASR。

4.多站点环境下客户端连接延迟的问题

所谓客户端连接延迟，即是说，群集完成了故障转移，但是客户端却还是不能访问应用的这段时间，通常情况下，有两种原因，1.群集故障转移完成后应用需要额外配置才可以提供访问 2.DNS客户端延迟

这里我们主要谈的是DNS客户端延迟的问题，什么是DNS客户端延迟，以下图为例，如果我们使用多站点多子网的网络架构，就会面临这样的问题，VCO在 SiteA是10网段IP，注册到DNS，DNS把这条记录复制到SiteB，SiteB客户端访问VCO以为地址就是10网段，当发生故障转移，群集从SiteA转移到SiteB，VCO的地址发生了改变，修改后的记录复制到DNS Server 2，虽然群集完成了故障转移，DNS记录也得到了复制，但是SiteB的客户端在1200秒内还是没办法访问转移后的服务，因为DNS服务器上每个记录都会有一个HostRecordTTL时间，这段时间内，客户端将使用缓存的地址，而不再请求新的地址，因此，这是我们需要考虑的地方。

要解决DNS客户端延迟问题，有几种办法

1. 使用延伸VLAN的网络架构，都是同一个子网，不需要修改地址，不涉及到DNS缓存

2. 使用网络抽象设备，让群集网络名称始终注册到一个抽象的网络设备上面，然后网络设备在把一个抽象的地址注册到DNS，不论是Site A或是Site B，DNS Server始终面对抽象网络设备的地址，不涉及到DNS缓存

3. 使用优先本地转移方案，配置应用的首选所有者未本地节点，本地所有者失败后，再转移至跨站点

4. 优化多子网下的DNS缓存时间和机制：2008时代WSFC针对于多站点，新增两个属性，分别是HostRecordTTL和RegisterAllProvidersIP，HostRecordTTL属性可以修改DNS缓存的时间，默认是1200秒客户端再和DNS请求新的地址，我们修改某个群集网络名称的这个时间为300秒，这样客户端就会更频繁的和DNS服务器请求新的地址。微软建议最短不要超过300秒，否则会带来DNS服务器性能问题。RegisterAllProvidersIP属性可以让一个网络名称，同时注册多个子网的地址，默认情况下网络名称对应多个OR关系IP，同一个时间只会注册一个地址，如果这个网络的地址不可用，切换到另外站点，再注册另外一个，而RegisterAllProvidersIP则是直接支持注册所有站点的DNS记录，但此功能要求应用支持，SQL 2012之后开始支持此功能，应用实际上会先尝试连接一个IP，如果尝试连不到，自动连另外一个地址。

仲裁

对于多站点群集来说，仲裁也是个值得思考的问题

1. 见证应该放在那

对于多站点群集而言，见证最好不要放在多站点本身，因为这样会存在一定的偏袒效应，当发生网络分区时，只要获得见证的一方将会启动提供服务

因此，建议对于多站的见证仲裁，最好放在第三个站点的文件见证，磁盘见证，或使用WSFC 2016的云见证功能，这样不存在偏袒效应，那个站点可以正常与第三个站点或云连接，即存活。

 2.见证网络应该如何设计

一个失败的见证网络设计是和心跳网络，对外网络设计在一起，例如，如果多站点的对外网络线路彻底瘫痪，而见证连接网络和对外网络使用相同网络链路，那么见证连接网络也将会瘫痪，灾备站点可能因此没办法正常启动，因此见证的连接一定要做到单独使用一个网络，防止因为网络故障，而导致见证失去效果。

3.是否要搭建冷备站点

一些企业可能会有冷备站点的需求，即一个正常情况下，不对外提供服务的站点，只有当出现重大灾难时才会将其启动，例如北京一个站点，天津一个站点，上海一个站点，我希望正常情况北京坏了，只要转移到天津就好了，只有万不得已的情况下才转移到上海，这时候您就可以搭建一个冷备站点，操作有两种选择 1.取消上海站点的投票资格，这样上海站点将无法获得争取资格，除非您再强制启动上海站点，并为其赋予投票。 2.设置应用可能所有者只有北京和天津，这样也可以实现类似的效果，但是如果群集应用少还可以，群集应用过多，到时操作起来会有所麻烦，需要一个一个改。

4.是否要优先本地站点转移

当灾难发生时，如果未满足一定阀值，我们其实没必要启动数据中心级别的灾难恢复的计划，可以在数据中心内部主机级别实现灾难恢复，这时可以配置应用首选所有者为本地，本地没办法转移再转移至跨站点，或如果使用WSFC 2016可以利用应用站点感知功能，实现应用多主站点运作。

或者说数据中心内部，针对于重要应用，架设几台冷备机，平时关机，应急时候开机使用，强制启动，赋予投票，加入群集，但前提是见证磁盘存活，冷备机可以获得最新群集配置数据库。

5.脑裂或少数站点情况如何处理的操作规范

在2008R2时代，如果我们部署多站点架构，很容易碰见网络问题而导致群集出现脑裂，2012开始，微软新增动态仲裁功能，在动态仲裁情况下，我们很少可以看见脑裂的情况，一般如果出现脑裂情况，我们会根据业务需要，选择最合适的一个站点，强制启动它，其它站点稍后启动时需要经过阻止启动，以和强制启动站点同步最新群集数据库，因此，多站点架构需要考虑脑裂情况下，如何评定那方为权威站点，应该如何操作启动权威站点。

WSFC 2012时代开始推出动态仲裁功能，即是说当群集为偶数节点，没有见证的情况下，群集会始终自动去掉一个节点的投票，维持群集未奇数投票，当发生网络分区时，被去掉节点投票的站点，将会下降，没有被去掉节点投票的站点继续提供服务，我们可以通过2012时代的LowerQuorumPriorityNodeID，或者2016时代的PreferredSite功能来指定，让群集始终去掉某个节点的投票，最终达成控制站点启动的效果，在多站点WSFC架构也可以考虑该功能的使用，如果有多个站点，50 50节点数情况下希望某个站点始终不要获胜。

还有一种情况即，少数节点数站点，当发生灾难恢复时，可能会有好几个站点，有的站点有多数节点，有的站点有少数节点，正常情况下应该是多数节点的站点获胜，但是我们知道少数节点的站点才是我们最希望提供服务的站点，所以我们可以阻止多数节点启动，强制启动少数节点。这项功能需要事先规划好，灾难恢复后应用应该首先在那些站点启动，如果发生意外情况，理想站点是少数节点，我应该如何操作。

存储

对于多站点群集而言共享存储放在那里是个问题，因为我们需要确保群集在灾难发生时可以完整的在另外一个站点启动起来

如果群集的共享存储放在两端任何一个数据中心，当这个数据中心出现灾难时，另外一个站点也没办法继续提供服务，因为联系不到共享存储

因此，要架设多站点群集，我们还需要考虑到共享存储放置问题

通常情况下，多站点的灾备恢复，人们会对存储实现复制机制

1. 基于设备级别存储复制：直接选择支持存储复制的阵列，当存储交付给群集节点时候就是被复制的，设备会基于存储块级别进行复制，如果在多站点实现这种设备级别复制，最好要有专门线路，因此会花费一笔不少的费用

2. 基于主机软件级别存储复制：可以使用类似于赛门铁克，SteelEye DataKeeper Cluster Edition，或Windows Server 2016原生自带的存储复制，这类软件会把多个节点操作系统上面的存储构建成一个逻辑，经过复制的磁盘，交付给群集磁盘识别，现在越来越多人开始使用这种方案实现跨站点存储的复制

3. 基于应用级别存储复制：直接使用类似于exchange dag，SQL ag等，应用可以具备存储复制技术

除了选择合适的存储复制机制，确保存储持续可用外，我们还需要选择存储复制的方法

使用同步复制或异步复制

使用同步复制，不会丢失数据，每次写入要求会确保同时写入两个站点存储，才会完成，容易带来应用延迟，对网络性能要求高。

使用异步复制，有可能会丢失数据，每次写入请求只写入到所在站点即结束，稍后再复制到其它站点，这样应用不会感觉到延迟，复制稍后会在后台一点一点进行，对网络性能要求不高，但可能还没复制过去时发生灾难，而导致数据丢失。

在实际环境中，老王看到大部分企业还是在使用同步复制，以确保数据的完整性

很多人会考虑到DFS复制，实际上，微软的DFS复制的适用场景是信息工作组，用于存放视频，文件，图片，等资料，对于群集，或者VMM的库，DFS则并不适合，因为DFS只会复制关闭后的数据，如果我们的群集里面有虚拟机，数据库，这些不会关闭的文件，DFS是不会复制的

以上老王从网络，仲裁，见证的角度，来为大家讲解了下WSFC多站点需要考虑的点，希望可以为感兴趣的朋友带来收获

本文转自 老收藏家 51CTO博客，原文链接:http://blog.51cto.com/wzde2012/1976857