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


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

2018-10-12_104345.png

老王认为这个角色应该叫做群集对外复制代理比较合适，不然很容易让人误会是群集内部的复制，可以理解为微软将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复制关系，并且逐个宕机宿主机验证理论。


北京群集

2018-10-13_135734.png


天津群集

2018-10-13_140617.png


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

2018-10-13_140844.png

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

2018-10-13_142410.png

配置天津站点复制代理

2018-10-13_143002.png

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

2018-10-13_144256.png

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

2018-10-13_144308.png

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

2018-10-13_144558.png

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

2018-10-13_154412.png

其它配置视实际情况而定

2018-10-13_144948.png

点击群集虚拟机，右键，查看复制运行状况，可以整体检视Hyper-V复制运作，如果有扩展复制也会在这里显示，可以看到当前北京站点复制代理，天津站点复制代理分别挑选的复制主机

2018-10-13_145149.png

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

2018-10-13_145417.png

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

2018-10-13_145645.png

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

2018-10-13_152300.png

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

2018-10-13_152741.png

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

2018-10-13_152821.png

选择要使用的恢复点

2018-10-13_152843.png

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

2018-10-13_153001.png

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

2018-10-13_153709.png

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

2018-10-13_154158.png


2018-10-13_154848.png

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