微软双机双柜方案讨论

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

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

   若是按照这个概念来说，微软双机双柜方案有两个，一个是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，您须要额外考虑单独的备份机制

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