Hyper-V群集对群集复制

大部分人可能只知道Hyper-V复制是2012新引入的虚拟机复制功能，但殊不知道其实Hyper-V复制支持很是灵活的架构，如单机对单机，单机对群集，群集对单机，群集对群集，那么Hyper-V复制和群集扯上关系究竟是怎么回事呢

在WSFC 2012开始，WSFC新增长了一个Hyper-V副本代理角色，以下图所示

老王认为这个角色应该叫作群集对外复制代理比较合适，否则很容易让人误会是群集内部的复制，能够理解为微软将hyper-v复制与WSFC的整合实现为一个群集对外复制协调引擎，当咱们配置这个角色时会输入一个名称，这个名称就做为复制代理角色的客户端访问点，不论此群集做为来源端或者目的端，在复制向导填写名称时都会填写复制代理名称，而非单个节点，复制代理会自动协调群集内参与虚拟机复制节点，当一个外面的复制请求丢到群集，复制代理引擎接到请求会自动协调出来一个节点参与复制，当被挑选参与复制的节点宕机，则虚拟机将被故障转移到群集内其它节点继续复制，利用WSFC故障转移和复制引擎机制确保不会由于单个主机宕机而影响虚拟机复制

总结群集对外复制代理功能以下

1. 做为群集统一的对外代理，对外提供统一的复制名称

2. 挑选协调群集内主机参与复制，感知故障转移，告知外面复制请求流量最终应到达主机。

3. 确保群集内添加节点时不会对正在进行的复制产生影响

4. Broker角色将复制配置写入群集数据库并触发通知，每一个节点上的虚拟机管理服务都会获得复制配置，而且每一个节点都会使用复制设置的最新副本

5. 支持副本虚拟机在群集内实时迁移，当副本虚拟机被迁移到其它节点，复制流量自动从新路由，不须要人工干预。

2012R2，Hyper-V复制还引入了重磅新功能，扩展复制，更进一步的贴近实际应用，利用这个功能咱们能够实现 群集-群集-群集，群集-单机-单机，单机-单机-群集，群集-单机-群集等更加灵活的场景。

站在跨站点，跨群集的角度来看Hyper-V复制

首先，Hyper-V复制对比存储复制，WSFC来讲，最大的一个优点就是架构灵活，能够不受架构的限制，不受存储的限制，支持足够多的场景，可是，若是不和群集整合，单独Hyper-V单机对单机复制的话，也有一个最大的弊病，即计划内维护须要宕机，通过老王和好友张俊森的实际测验，发如今一个计划内维护的场景下，若是要维护宿主机，居然要把虚拟机关机才能够进行Hyper-V复制计划内故障转移，这个是单机场景下的不足，可是若是能够搭建群集则不会有这个问题，经过复制代理引擎会自动挑选参与复制的节点，那怕其中一个节点宕机，或者计划内要维护关机，复制代理引擎也会马上挑选其它主机来参与复制，从可用性的角度来说，利用复制代理能在外面Hyper-V复制机制里面再加上一层复制代理双保险，经过协调群集内复制节点，确保只要群集活着就始终有能参与复制的节点。

除此以外Hyper-V复制还有如下优势，支持多个还原点，不须要使用其它备份工具，直接经过Hyper-V窗口就可以回滚到不一样的时间节点，支持应用程序一致性感知，支持证书验证 SSL 443加密，支持固定端口发布到其它网络对接复制，支持Azure云端整合复制。

缺点来讲，除了单机对单机的维护问题，还有经过和好友张俊森讨论认为Hyper-V复制的复制间隔仍是过长，两方复制30秒 5分钟 15分钟，扩展复制5分钟 15分钟，对于一些核心关键的业务可能会但愿更短的复制间隔时间，以减小数据的丢失。

实际环境中使用Hyper-V复制的建议，若是是单机对单机的场景下，老王不建议跑重要业务，通常的业务能够由Hyper-V复制负责，下降成本，计划内维护关闭虚拟机需在维护窗口时间完成，若是环境容许的话，处于可用性的考虑，老王建议至少组建一个群集对单机的场景，这样就能够放心的跑一些业务，虚拟机正常状况下在群集内一个节点运做，由群集再将虚拟机异步复制到单机，以防止群集崩溃，一旦群集内单个节点宕机，复制代理协调另一个节点自动参与复制，一旦群集崩溃，手动在单机节点故障转移虚拟机。

WSFC对比Hyper-V复制来讲最大的优点就是自动故障转移，Hyper-V复制不管是单机对单机，群集对单机，群集对群集，假设其中一方忽然宕机，管理员都须要手动完成故障转移，跨站点的状况下可能更会延迟宕机时间，若是是搭建了WSFC，在跨站点的状况下，只要合理设计好网络，存储，仲裁，DNS延迟，放置策略，应用重试等群集配置，应用能够很快的自动故障转移。不管是Hyper-V复制仍是WSFC，若是设计跨站点的可用性方案，都须要考虑到网络和存储，Hyper-V复制对于存储没有要求，能够是共享存储也能够是本机存储，须要注意的是网络延迟，不一样的复制频率对网络带宽的质量要求也就越高，若是真的考虑跨站点应用Hyper-V复制，可能也须要搭建专线。

WSFC目前跨站点可用性方案有两种模型 

1. WSFC 2016+自带存储复制，构建成延伸群集

2. WSFC 2008R2/2012R2/2016+第三方存储复制/设备复制

从目前的架构上面来说，WSFC的跨站点仍是要考虑到存储的问题，缘由是目前S2D不能跨站点分布存储数据，只能作到跨机架级别，所以须要考虑存储的可用性，不管是那种方案，WSFC跨站点的话对于网络质量也是要求很高。

Hyper-V复制与WSFC两种方案，Hyper-V复制更加廉价，没有存储限制，异步复制，架构灵活，但须要和群集整合来实现更高的可用性，故障转移恢复时间较长，需手动进行计划外故障转移，WSFC能够作到自动的故障转移，可是对于管理员技术有所要求，要求管理员必须熟悉精通跨站点群集的网络，存储，仲裁，DNS延迟，放置策略，应用重试等概念设计，两种方案均对网络要求较高，想要作跨站点高可用应该想到这一点，实际决定采纳方案时，还应该结合管理人员对hyper-v复制和WSFC的熟悉程度决定。

跨站点仍是跨群集

WSFC从2008开始支持群集多子网，真正推动了跨站点群集的场景，支持调整跨子网心跳检测阀值，2008R2引入HostRecordTTL机制下降跨站点故障转移时DNS复制延迟，引入RegisterAllProvidersIP属性让支持的应用能够进行多子网的快速重试，支持调整跨网络群集检测通讯加密属性。2012R2新增动态仲裁，反相关性，加强优先级设置以便于跨站点故障转移时的可用性策略。2016时代对于跨站点新增了很多新功能，站点感知，存储站点感知，群集组站点感知，首选站点，跨站点心跳检测阀值，经过配置可以实现应用默认本地站点转移，本地站点所有宕机跨站点故障转移，虚拟机followCSV，CSV转移到其它站点则虚拟机也跟随转移，经过配置群集组站点感知实现多个群集组始终在不一样站点运行。经过站点属性配置50/50状况获胜，经过站点属性配置本地子网跨子网外的阀值规则。一切都源于2016引入了故障域的概念，管理员能够手动定义Site，Rack，Chassis等故障域属性，随后应用会感知到故障域定义以进行故障转移或策略应用，例如前面介绍的几个新功能都是围绕着故障域定义的Site属性来应用设计跨站点故障转移的策略，故障转移层面S2D实现效果最好，例如检测到rack故障域定义 能够将extent撒到不一样rack

WSFC 2016的故障域，站点感知等策略，在设计2016群集架构时是必不可少要思考的地方，合理的规划能够帮助减小不少的宕机时间，到了WSFC 2019，全部的2016新功能获得延续，而且新增了ClusterSet新功能。

ClusterSet和Hyper-V复制代理有点像，但也不全像

说他俩像是由于它俩都有一个共同的效果，不把鸡蛋放在一个篮子里，不所有押宝单个群集

ClusterSet前面已经单独写文章和你们聊过，简单来讲它就是一种基于统一的命名空间路径运行虚拟机，以及管理群集调度成员群集的机制，让多个群集造成一个大的Set，全部群集虚拟机都在同一个大命名空间下面流动，虚拟机能够跨群集/跨可用性集进行实时迁移，故障转移，目的主要有四，扩展单个群集虚拟化或S2D边界，实现虚拟机跨群集跨可用性集流动，便于群集生命周期管理，兼容不一样存储架构群集。

ClusterSet彻底是一个WSFC新引入的机制，这项技术的缺点就是太耗费资源，要构建管理群集，成员群集，管理员也须要理解2019SOFS的概念，而且目前阶段配置也彻底只能用Powershell，技术难度较大，所以更加适用于准备构建大型数据中心，私有云，混合云的企业用户

Hyper-V复制代理这项技术相对来讲更容易理解，没有ClusterSet那么复杂，可是它的缺点就是，一旦其中一方所有崩溃，整个复制关系要计划外故障转移时，只能经过手动故障转移，ClusterSet则能够自动化完成。

ClusterSet与Hyper-V复制有一个共同的好处就是都不须要Care群集的跨站点配置，设想一下，ClusterSet的话 北京一个管理群集，天津一个成员群集，张家口一个成员群集，每个群集都是本地站点，就不须要考虑跨站点的网络，存储，仲裁，站点策略等概念。Hyper-V复制也是一个道理，若是北京群集复制到天津群集，两边群集也都是本地站点，所以这种跨群集的解决方案，还有存储复制的跨群集复制，都不须要关注单群集跨站点时所涉及到的概念，稍微省心一点

可是缺点就是Hyper-V复制代理，存储复制，跨群集故障转移时都须要手动执行，若是不跨群集的话那就考虑单群集跨站点的方案，结合存储复制，能够达到最高的可用性，但须要管理员熟悉跨站点的群集策略，实际应用的时候你们能够结合本身的场景多多思考，到底有没有必要跨群集，仍是跨站点，采用那项技术最为适合。

实验环境

本文最后老王将为你们实做群集对群集Hyper-V复制的场景，北京站点12node1，12node2，天津站点12node3，12node4，分别链接各自站点的共享存储，我将在两个群集之间创建复制代理对复制代理的Hyper-V复制关系，而且逐个宕机宿主机验证理论。

北京群集

天津群集

北京群集添加Hyper-V副本代理群集角色

输入客户端访问点名称，以后不论此群集做为Hyper-V复制来源端或目的端都会经过此名称统一对外复制，一个小技巧，若是但愿限定复制时使用的网络，能够在这里选择其中群集网络类型1的网络子网做为客户端访问点IP，随后在对面各群集节点或单机添加复制代理客户端访问点的FQDN名称，NetBIOS名称进入hosts文件，由于复制代理的名称仅在复制时使用，并不对外，因此能够经过hosts文件限定网络

配置天津站点复制代理

当前北京站点存在一台虚拟机，虚拟机存储位于北京站点CSV

右键点击虚拟机，启用复制

进入复制配置向导，输入天津站点群集对外复制代理名称

分别配置两边群集Hyper-V复制代理配置，存储位置能够是SOFS或CSV路径

其它配置视实际状况而定

点击群集虚拟机，右键，查看复制运行情况，能够总体检视Hyper-V复制运做，若是有扩展复制也会在这里显示，能够看到当前北京站点复制代理，天津站点复制代理分别挑选的复制主机

虚拟机不停机实时迁移到北京站点12node2，此时移走12node1上面其它角色便可不停机维护12node1

再次检视复制运行情况，发现复制主机已经自动挑选为12node2

直接宕机12node2，复制引擎感知故障转移，从新协调由12node1进行复制

宕机12node1 北京站点群集所有关闭，天津站点此时虚拟机处于关闭状态，需手动进行故障转移

右键点击虚拟机 - 复制 - 故障转移

选择要使用的恢复点

虚拟机跨群集复制启动成功。

此时若是天津站点12node4崩溃，虚拟机和复制代理角色会故障转移到12node3，只要仲裁设计合理 ，虚拟机能够存活至最后一个节点

随后各节点陆续恢复，在天津站点群集上右键点击虚拟机 - 复制 - 反向复制，将数据反向同步回北京站点。

Hyper-V跨群集复制，不像ClusterSet那么复杂，也不须要精通跨站点的群集调优策略，它很简单，但也能实现很好的效果，只要正确掌握操做方法，发现故障及时手动故障转移，就能够将宕机时间尽可能降到最低，也许你值得拥有。