微软双机双柜方案讨论

   前阵子有位网友在老王的博客下面询问微软双机双柜方案，那种性价比最高，需要最少的硬件投入，老王觉得这个话题挺有意思，今天特地与大家分享讨论

   按照老王的理解所谓双机双柜是指两台服务器，每台服务器接自己的存储机柜，然后两台服务器实现复制，以确保应用故障转移时的存储支援

   如果按照这个概念来讲，微软双机双柜方案有两个，一个是Hyper-V复制，另外一个是存储副本，下面我们来逐个进行分析

   Hyper-V复制是微软在2012 hyper-v3.0时引入的虚拟机复制技术，支持将虚拟机复制到其它主机或群集或Azure，支持在没有群集的情况下灾难恢复虚拟机

   Hyper-V复制技术优缺点

1. 存储无关性，参与复制的hyper-v宿主机可以连不同的存储，可使用现有盘柜或本地磁盘

2. 支持标准版与数据中心版

3. 支持工作组部署

4. 复制过程使用80或443端口，支持证书加密

5. 支持单机对单机复制，群集对群集复制，单机对群集复制，群集对单机复制

6. 支持扩展复制，A-B B-C （2012R2引入）

7. 支持计划内故障转移

8. 支持灾难恢复，但是需在备份节点手动故障转移

9. 支持多子网架构TCP/IP预设，例如可以设定虚拟机转移到备站点开机后自动设置为备站点IP
   

10. 支持反向复制

11. 支持LAN环境或WAN环境

12. 复制过程区分主备架构，对于一台参与复制的虚拟机来说，仅在主节点开机，备节点关机，主节点按照时间间隔复制虚拟机增量数据至备节点

13. 支持测试故障转移，开一台测试虚拟机出来，监视资料是否正常复制

14. 支持通过ASR将虚拟机复制到Azure

15. Hyper-V虚拟机级别复制，支持复制虚拟机所有虚拟磁盘(除直通)

16. 支持多个恢复点
    

17. 支持应用程序一致性，如果虚拟机里面承担SQL等数据库服务，使用应用程序一致性复制虚拟机，可以支持复制时内存数据Flush到磁盘上后再创建恢复点

18. 具备官方复制规划软件，微软SCOM平台可以对其监控，SCVMM不能操作hyper-v复制

总结，hyper-v复制可以说以一款虚拟机复制的灾难恢复解决方案，对于硬件的改变老王认为是几种方案里面最小的，直接使用现有双机双柜架构即可，对于存储没有要求，复制功能本身并不过多占用系统资源，各项复制功能，如扩展复制，测试故障转移，恢复控制，架构支持，应用感知，数据安全等都相对完善，缺点主要还是计划外故障必须手动故障转移，原生不能自动故障转移，如果需要自动故障转移还需要再学习SCO或使用ASR，仅适用于Hyper-V虚拟机负载，如果没有使用虚拟化则不适用

存储副本技术是微软Windows Server 2016上面推出的基于块级别复制技术，在系统级别对分区进行复制，支持分区对分区，单机对单机，延伸群集，跨群集复制等灾备场景的复制，帮助组织更好的提高业务连续性

优缺点总结

1. 仅支持2016数据中心版

2. 参与存储复制的节点必须加入域

3. 系统级别分区复制，应用并不知道底层发生复制

4. 复制使用SMB 3.1.1通讯协议，445端口

5. 支持同步复制与非同步复制

6. 存储无相关性，节点底层可以是任何存储结构

7. 支持固定式磁盘和精简置备磁盘

8. 复制过程存在主备关系，主复制分区可读写，备复制分区不可读写，暂未支持备只读模式

9. 单机对单机和跨群集复制时只能使用Powershell命令管理复制，延伸群集支持GUI管理

10. 单机对单机和跨群集复制需手动故障转移，延伸群集实现全自动故障转移

11. 延伸群集仍需每个站点接入各自站点存储，不支持直接使用各节点本地磁盘

12. 跨群集复制支持两个群集使用不同架构存储
    

13. 复制时会需要日志磁盘与数据磁盘，数据先写入日志磁盘，再Commit数据磁盘
    

14. 复制节点至少需要两个磁盘，一个数据磁盘，一个日志磁盘

15. 数据磁盘和日志磁盘的格式必须为GPT，不支持MBR格式磁盘

16. 两个数据磁盘大小与分区大小必须相同，最大 10TB

17. 两个日志磁盘大小与分区大小必须相同，最少 8GB

18. 不支持扩展复制，不支持多个恢复点，不支持应用一致性感知，不支持工作组，不支持群集对单机

19. 支持通过SCOM监控，SCVMM管理，OMS监控，Honolulu管理

总结，存储复制是server 2016上面系统级别的块存储复制，工作在分区之上卷之下的区域，对于单机对单机，存储底层没有太多限制，但是对于延伸群集仍然要求各自节点连接自身存储机柜，存储复制和Hyper-V复制的不同在于存储复制只是系统级别的实现，并不绑定在虚拟化，因此大多数应用都可以利用此功能，缺点在于，虽然说存储复制也算是一种灾难恢复技术，单机对单机可以实现存储的复制，手动切换，延伸群集可以实现存储加计算的全自动故障转移，但是在灾难恢复软件的层面看，存储复制还是缺少一部分功能，例如扩展复制功能不支持，群集对单机功能不支持，导致存储复制在架构上非常不灵活，这也是未来需要改进的地方，区别于微软的DFS，存储复制不像DFS原理那么复杂，检测NTFS USN，更新DFSR DBID ，更新GVSN，RDC同步数据，存储复制使用日志+存储机制，主要检测磁盘的写入IO，检测到有写入IO，按照同步复制机制或异步复制机制执行日志和存储的写入，因此存储复制可以复制正在打开的文件，讨论使用场景的话，老王认为单机对单机的复制适用于以下场景

1.文件经常被打开，使用DFS有时候不会复制，这时候可以使用存储复制整体复制分区

2.针对于VHDX文件，VMM库共享，数据库MDF结果集文件，这类经常被打开的大文件，可以在两个节点直接进行复制

3.适用于归档场景，例如有些虚拟机常年处于关机状态，但是里面又有一些关键数据，这时候可以使用存储复制，简单复制归档虚拟机的虚拟磁盘

以上为老王设想到的存储复制单机对单机场景，另外一点要说的是延伸群集，延伸群集可以说是存储复制的最大亮点，即使用非对称存储架构，各自节点挂载存储，通过存储副本+群集配合可以做到发生故障时先故障转移存储，再故障转移上层虚拟机

大家看到很多文档，可能都会说延伸群集适用于多站点架构，例如北京站点和上海站点各自站点只是接入简单存储机柜，并未配置硬件级别的存储复制，而通过微软2016延伸群集实现，当北京站点宕机时，可以在上海站点连同存储和计算资源一起启动，这确实是延伸群集的最主要意义，帮助公司省一大笔硬件费用，两点，一点是实现了原生自带的存储复制，一点是实现了存储复制和群集融合，群集检测节点宕机，自动故障转移存储和应用。

但是，这种自动故障转移存储和应用的实现，如果没有多站点是不是就不能实现了，答案是不是的，即使你就一个数据中心，一个机房，两个节点，两个存储机柜，各自节点接入机柜，就可以做到延伸群集的架构，只要符合延伸群集的配置要求，延伸群集并不关心你是否是本地数据中心还是异地数据中心，这取决于您的技术选型

延伸群集架构带来的好处是存储复制和群集的融合，完美处理存储的单点故障和应用的单点故障，并且做到存储和群集节点故障转移联动，因此如果本地数据中心，您想要这个功能，也是OK的。

存储复制对比Hyper-V复制

1. 存储复制是系统系别，不支持复制系统磁盘，Hyper-V复制是虚拟机级别，不支持复制直通类型磁盘

2. 存储复制可以用于物理机，虚拟机，私有云，公有云，只要有OS就可以实现，hyper-v复制需在物理机上面配置实现
   

3. 两者都不需要额外更换存储，都可以使用现有存储机柜来完成利旧

4. 存储复制就是复制存储，做好存储的切换，别的不管，hyper-v复制会包含内存状态，也会把主节点内存状态进行复制。
   

5. 存储复制功能只有2016数据中心版才有，如果企业没有需要额外构建，且2016对于系统要求比2012要大，如果配置存储复制功能，建议为系统至少预留2-4GB内存

6. 存储复制实现为日志磁盘加数据磁盘架构，管理员需额外管理日志磁盘和数据磁盘，hyper-v复制则无此架构

7. 存储复制不是基于检查点，而是连续复制，所以变化的增量往往远低于基于快照的产品
   

8. 如果希望在虚拟机级别复制一个应用，并且希望实现虚拟机直接开机就用，应用事务并不丢失，建议使用Hyper-v复制配应用一致性

9. 如果是希望复制VHDX库，数据库MDF结果集文件，归档虚拟机，或一些会被打开的日常文件，可以使用存储复制

10. 如果希望实现双机双柜存储复制+自动化故障转移，建议使用延伸群集

11. 如果希望获得虚拟机级别的扩展复制 等更灵活的复制架构，建议使用Hyper-V复制
    

以上为老王关于微软正儿八经双机双柜方案，hyper-v复制与存储复制的浅谈，两者的主要优势都是可以直接利旧，使用现有存储机柜，不需要改变基础架构就可以实现灾难恢复，hyper-v复制不能做到自动故障转移，存储复制可以配置延伸群集实现自动故障转移，这个可能是一个主要的思考点，另外存储复制比hyper-v复制更占用系统CPU和内存资源，hyper-v复制比存储复制在灾难恢复上面更加专业，更适用于重要的虚拟机整体复制，具体大家实际使用时，可以结合老王提到的这些功能点选择适用的场景。

除了这两种可以直接利旧的方案外，针对于此类没有共享存储的场景，微软2016还推出了S2D的功能，它将2012R2的存储池和存储空间功能，扩展到了多个节点上，具体实现为以下两点

1. 可以把各群集节点上面本地磁盘汇集到一起，每个节点会有一个clusport组件充当适配卡角色，群集中会有一个clusblft角色，负责连接各个节点的clusport，通过这两个组件，可以把各个群集节点上面符合要求的本地磁盘汇集到一起，形成群集的逻辑存储池，这个逻辑存储池可以被进一步配置存储空间，但其实这个逻辑存储池里面是各个群集节点的本地磁盘，经过构建完成存储空间后，生成的虚拟磁盘就可以被用于群集磁盘

2. 另外一点是存储空间延伸至群集后实现的全新容错机制，2016 S2D，可以根据存储空间的不同容错配置，把数据写入分成多个extent，一个extent 1GB，如果配置为双重镜像，那就是数据后台会生成两个extent，两个extent可以被洒在不同节点，不同机柜，不同机架，通过这个功能就把存储空间延伸至了群集，一个节点或磁盘的故障，并不会影响上层应用的读取，因为所有的磁盘会被在另外节点上面读取，数据也会在另外节点上面重建，S2D会遵循extent容错反相关性原则，始终把同一份数据的多个extent撒在不同节点，当一个IO进来，只有当数据所有extent都完成写入后，这个IO才会回传结束

因此，如果全新部署的一个环境，利不利旧也无所谓，那么您可以尝试这种全新的超融合架构，非对称存储架构不用，直接超融合使用各节点本地存储，透过数据始终容错写入不同节点，以确保数据的高度可用，并且支持SSD,NVME,NVDIMM-N缓存设定，能够获得更高的性能，缺点在于，S2D比存储复制更消耗资源，尤其是网络和内存，而且S2D并不是备份方案或灾难恢复方案，一旦S2D这个功能不work了，数据读取将非常麻烦，所以如果采用S2D，您需要额外考虑单独的备份机制

除了微软自身的三种方案外，DataKeeper SIOS，Starwind，Symantec SFW也是不错的解决方案，SIOS支持各节点本地存储或非对称机柜的复制，可以在SIOS上面完成存储的复制配置，经过SIOS复制后的磁盘可以直接显示在WSFC群集磁盘，如果没有server2016使用这个工具也不错，它和群集完美集成，也可以做到自动故障转移，SFW与它类似，自身管理不同节点存储，构建出磁盘组，然后交付给群集，Starwind是连接各节点存储，进行复制，复制好了后虚拟出磁盘，再以ISCSI的方式提供给各个群集节点使用。