您好,登录后才能下订单哦!
前阵子有位网友在老王的博客下面询问微软双机双柜方案,那种性价比最高,需要最少的硬件投入,老王觉得这个话题挺有意思,今天特地与大家分享讨论
按照老王的理解所谓双机双柜是指两台服务器,每台服务器接自己的存储机柜,然后两台服务器实现复制,以确保应用故障转移时的存储支援
如果按照这个概念来讲,微软双机双柜方案有两个,一个是Hyper-V复制,另外一个是存储副本,下面我们来逐个进行分析
Hyper-V复制是微软在2012 hyper-v3.0时引入的虚拟机复制技术,支持将虚拟机复制到其它主机或群集或Azure,支持在没有群集的情况下灾难恢复虚拟机
Hyper-V复制技术优缺点
存储无关性,参与复制的hyper-v宿主机可以连不同的存储,可使用现有盘柜或本地磁盘
支持标准版与数据中心版
支持工作组部署
复制过程使用80或443端口,支持证书加密
支持单机对单机复制,群集对群集复制,单机对群集复制,群集对单机复制
支持扩展复制,A-B B-C (2012R2引入)
支持计划内故障转移
支持灾难恢复,但是需在备份节点手动故障转移
支持多子网架构TCP/IP预设,例如可以设定虚拟机转移到备站点开机后自动设置为备站点IP
支持反向复制
支持LAN环境或WAN环境
复制过程区分主备架构,对于一台参与复制的虚拟机来说,仅在主节点开机,备节点关机,主节点按照时间间隔复制虚拟机增量数据至备节点
支持测试故障转移,开一台测试虚拟机出来,监视资料是否正常复制
支持通过ASR将虚拟机复制到Azure
Hyper-V虚拟机级别复制,支持复制虚拟机所有虚拟磁盘(除直通)
支持多个恢复点
支持应用程序一致性,如果虚拟机里面承担SQL等数据库服务,使用应用程序一致性复制虚拟机,可以支持复制时内存数据Flush到磁盘上后再创建恢复点
具备官方复制规划软件,微软SCOM平台可以对其监控,SCVMM不能操作hyper-v复制
总结,hyper-v复制可以说以一款虚拟机复制的灾难恢复解决方案,对于硬件的改变老王认为是几种方案里面最小的,直接使用现有双机双柜架构即可,对于存储没有要求,复制功能本身并不过多占用系统资源,各项复制功能,如扩展复制,测试故障转移,恢复控制,架构支持,应用感知,数据安全等都相对完善,缺点主要还是计划外故障必须手动故障转移,原生不能自动故障转移,如果需要自动故障转移还需要再学习SCO或使用ASR,仅适用于Hyper-V虚拟机负载,如果没有使用虚拟化则不适用
存储副本技术是微软Windows Server 2016上面推出的基于块级别复制技术,在系统级别对分区进行复制,支持分区对分区,单机对单机,延伸群集,跨群集复制等灾备场景的复制,帮助组织更好的提高业务连续性
优缺点总结
仅支持2016数据中心版
参与存储复制的节点必须加入域
系统级别分区复制,应用并不知道底层发生复制
复制使用SMB 3.1.1通讯协议,445端口
支持同步复制与非同步复制
存储无相关性,节点底层可以是任何存储结构
支持固定式磁盘和精简置备磁盘
复制过程存在主备关系,主复制分区可读写,备复制分区不可读写,暂未支持备只读模式
单机对单机和跨群集复制时只能使用Powershell命令管理复制,延伸群集支持GUI管理
单机对单机和跨群集复制需手动故障转移,延伸群集实现全自动故障转移
延伸群集仍需每个站点接入各自站点存储,不支持直接使用各节点本地磁盘
跨群集复制支持两个群集使用不同架构存储
复制时会需要日志磁盘与数据磁盘,数据先写入日志磁盘,再Commit数据磁盘
复制节点至少需要两个磁盘,一个数据磁盘,一个日志磁盘
数据磁盘和日志磁盘的格式必须为GPT,不支持MBR格式磁盘
两个数据磁盘大小与分区大小必须相同,最大 10TB
两个日志磁盘大小与分区大小必须相同,最少 8GB
不支持扩展复制,不支持多个恢复点,不支持应用一致性感知,不支持工作组,不支持群集对单机
支持通过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复制
存储复制是系统系别,不支持复制系统磁盘,Hyper-V复制是虚拟机级别,不支持复制直通类型磁盘
存储复制可以用于物理机,虚拟机,私有云,公有云,只要有OS就可以实现,hyper-v复制需在物理机上面配置实现
两者都不需要额外更换存储,都可以使用现有存储机柜来完成利旧
存储复制就是复制存储,做好存储的切换,别的不管,hyper-v复制会包含内存状态,也会把主节点内存状态进行复制。
存储复制功能只有2016数据中心版才有,如果企业没有需要额外构建,且2016对于系统要求比2012要大,如果配置存储复制功能,建议为系统至少预留2-4GB内存
存储复制实现为日志磁盘加数据磁盘架构,管理员需额外管理日志磁盘和数据磁盘,hyper-v复制则无此架构
存储复制不是基于检查点,而是连续复制,所以变化的增量往往远低于基于快照的产品
如果希望在虚拟机级别复制一个应用,并且希望实现虚拟机直接开机就用,应用事务并不丢失,建议使用Hyper-v复制配应用一致性
如果是希望复制VHDX库,数据库MDF结果集文件,归档虚拟机,或一些会被打开的日常文件,可以使用存储复制
如果希望实现双机双柜存储复制+自动化故障转移,建议使用延伸群集
如果希望获得虚拟机级别的扩展复制 等更灵活的复制架构,建议使用Hyper-V复制
以上为老王关于微软正儿八经双机双柜方案,hyper-v复制与存储复制的浅谈,两者的主要优势都是可以直接利旧,使用现有存储机柜,不需要改变基础架构就可以实现灾难恢复,hyper-v复制不能做到自动故障转移,存储复制可以配置延伸群集实现自动故障转移,这个可能是一个主要的思考点,另外存储复制比hyper-v复制更占用系统CPU和内存资源,hyper-v复制比存储复制在灾难恢复上面更加专业,更适用于重要的虚拟机整体复制,具体大家实际使用时,可以结合老王提到的这些功能点选择适用的场景。
除了这两种可以直接利旧的方案外,针对于此类没有共享存储的场景,微软2016还推出了S2D的功能,它将2012R2的存储池和存储空间功能,扩展到了多个节点上,具体实现为以下两点
可以把各群集节点上面本地磁盘汇集到一起,每个节点会有一个clusport组件充当适配卡角色,群集中会有一个clusblft角色,负责连接各个节点的clusport,通过这两个组件,可以把各个群集节点上面符合要求的本地磁盘汇集到一起,形成群集的逻辑存储池,这个逻辑存储池可以被进一步配置存储空间,但其实这个逻辑存储池里面是各个群集节点的本地磁盘,经过构建完成存储空间后,生成的虚拟磁盘就可以被用于群集磁盘
另外一点是存储空间延伸至群集后实现的全新容错机制,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的方式提供给各个群集节点使用。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。