WSFC多站点与灾难恢复

随着企业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多站点须要考虑的点，但愿能够为感兴趣的朋友带来收获