基于WinSrv2016(TP)构建的“超融合基础架构”

最近发现一个很热门的话题，国内的不少厂商也搞出了本身的“超融合基础架构服务器”，那么什么是“超融合基础架构”呢？

超融合基础架构（Hyper-Converged Infrastructure，或简称“HCI”）也被称为超融合架构，是指在同一套单元设备（x86服务器）中不只仅具有计算、网络、存储和服务器虚拟化等资源和技术，并且还包括缓存加速、重复数据删除、在线数据压缩、备份软件、快照技术等元素，而多节点能够经过网络聚合起来，实现模块化的无缝横向扩展（scale-out），造成统一的资源池。

        其实把计算资源，网络资源，服务器虚拟化集成不是很难理解，但我这里的存储资源须要拿出来单独说一下，这里我不是说专业的存储设备或者构建共享存储，我采用的是利用服务器的本地硬盘构建的存储资源（存储池）来实现，这点不少厂商也能够作到，例如VMware的VSAN，那么微软是否能够作到呢？这里就是我所关注的地方。

在开始测试以前，我须要应用“隔壁老王（王老师）”的一段话给你们普及下微软的一些关键词与群集技术：

        微软在2012版本提出了一个SOFS的概念，所谓的SOFS，老王的理解就是File Server On CSV，就和当时的Hyper-V on CSV同样，2008里面的Hyper-V群集，只能同时容许一个节点对虚拟机进行读取操做，同时虚拟机会对群集磁盘进行锁定，虚拟机群集组就会占用一个群集磁盘，你们都懂的，后来2008R2微软看出来了这个问题，推出了CSV群集分布式文件系统，其实也并不能算彻底分布式，可是能够容许全部Hyper-V节点，同时读取虚拟机资源，虚拟机没必要独占一个群集磁盘，其实幕后真正的数据文件，仍是存放在lun里面，只不过CSV在每一个群集节点的C盘作了一个mount文件夹作share volume，而后2008R2开始的群集能够感应到CSV，能够把虚拟机文件存放在CSV里面，CSV会经过群集网络，来同步CSV元数据，群集数据库变化信息，心跳检测信息，当其中一个群集节点出现故障，并不会实际上发生群集磁盘彻底的离线再上线，后台实际上发生的只是CSV节点从这个节点切换到另一个节点，大大的缩减了故障转移的时间。

        同理SOFS也是这个道理，微软所说的SOFS AA模式，我想也是这个道理，个人SOFS是基于CSV创建起来的，CSV是分布在不一样的群集节点，当发生故障的时候，实际上SOFS会作的，只是从一个节点，切换到另一个节点，并不会实际上发生故障转移的过程（卸载群集磁盘，挂载群集磁盘）。SMB3.0实现的SOFS最终交付的是一个UNC路径，不一样的对象访问SOFS，会根据访问的共享对象，进行负载均衡，可能这一次SMB客户端访问SOFS UNC路径是1节点提供链接，下一次SMB客户端访问就是2节点提供链接，当1节点出现故障，用户自动链接至2节点。

        SOFS又有不少形态组成，不少人觉得SOFS只能是存储池的模型，其实不是的，所谓的SOFS只是一种AA模式的文件服务器概念，提供最短的故障转移时间，能够透明的添加，或缩减节点。

可是SOFS并不会限制底层的存储，究竟是什么，SOFS只是认CSV，提供CSV，SOFS就能够基于CSV作 “File Server on CSV”

        举个例子，若是你有四个节点，前端两个Hyper-V节点，后端两个File Server节点

那么个人File Server底层能够接的是SAN，ICSI，还有这两年很热的JBOD，RBOD，SAS共享等等

        只是说，微软从2012开始，推出了他的存储池，存储空间的概念，原来SAN控制器作的事情，如今微软的2012也能够作了，微软提倡的是采用JBOD或者SAS共享的方式，直接把一堆磁盘阵列接给服务器，为企业节约硬件成本，而后原来SAN控制器作的事情，如今微软帮你作了，好比分层，存储池，去重，缓存，等等。

        顺便提一下，这里的JBOD说的是纯粹的磁盘阵列，JBOD只负责把磁盘装在一个盒子里，而RBOD则支持在阵列中进行群集RAID的配置

只是按照微软的最佳实践来说，微软推荐，底层是JBOD，接给文件服务器，文件服务器再作群集，而后在群集里面作群集存储池，群集存储空间，群集存储空间上面再作CSV，CSV上面再作SOFS，最终交付UNC路径出来，而后经过SCVMM去管理监控SOFS和群集存储池，SCOM去监控SOFS的运行状态

       因此在作SOFS架构设计的时候，文件服务器底层并不必定受限于JBOD，底层也能够是ICSI,RBOD，SAS共享，SAN

这里顺便提一下，有的人说有有SAN了，就不必用SOFS了，其实不是这个概念，咱们架构设计的时候，是为了SOFS提供出来的AA模式文件共享，为了使用SMB wintess的透明切换，这一点是SAN存储所作不到的，要实现AA模式共享，只有操做系统level，群集level才能够实现，，而微软偏偏就是最懂系统的人，硬件厂商是不擅长作这种事情的。只是说有了SAN，咱们就能够直接享受SAN控制器提供的高级功能，不用再在2012上面配置存储池，存储分层，硬件控制器提供的功能，比系统级别更加的可靠稳定，这就是SAN的优势，我认为。

       顺便再提下，微软推荐的这种模型，我相信有一部分人仍是不太理解的，

微软推荐底层是JBOD，接给文件服务器，文件服务器再作群集，而后在群集里面作群集存储池，群集存储空间，群集存储空间上面再作CSV，CSV上面再作SOFS，这种model

剖析下来看，JBOD，接文件服务器，没什么好说的，文件服务器作群集也没什么好说的，而后群集存储池呢，就是说个人群集创建的时候，先不使用群集磁盘，而后把群集磁盘堆栈起来，留给群集群处吃，在群集里面构建群集存储池，在构建群集存储池的时候，群集能够把群集节点上面存在的全部群集磁盘添加进入群集存储池，而后再基于群集存储池作群集存储空间，群集空间里面能够实现为群集磁盘容错，群集存储控制器的容错，举个例子，群集存储空间里面作镜像的存储空间，那么一个节点的一块磁盘快掉，另一个节点仍是能够正常使用，这个实现为群集磁盘的容错，好比我在群集存储空间配置了存储分层，那么一个群集节点坏掉，个人群集存储空间依然能够提供存储分层的服务，这个就是实现出来的群集存储控制器的容错，可是群集存储空间，实现的模式是A/P模式，一主一待，并不会同时提供服务，这就是群集存储空间和SOFS的区别。

      当你试着打破这个群集存储空间的时候，好比你删除了这个群集存储空间，你会发现两个群集节点上面，添加过到群集磁盘的磁盘，内容都是同样的。

      群集存储空间再上一层，可使用CSV，而后作CSV读缓存，还能够在群集存储空间开启存储分层，回写缓存，从而为上层的SOFS交付最佳的性能。

      最后再提一下，cluster in a box的概念，这个也是各个厂商都在提的，微软和CIB,Super micro合做，也推出了使用于微软的方案

      即提供一个盒子或者说是机架，这个盒子里面包括存储群集节点和Hyper-v节点，任意一个存储节点或者hyper-v节点宕机，并不会影响到整个业务的运营，存储节点和Hyper-v节点都是能够横向扩展的，而且能够提供存储分层，去重，存储池等高级存储功能。

      那么在微软新的Windows Server 2016（TP）版本中，这块有了什么变化呢？老王接着说“2012R2和2016的区别就是，2012R2SOFS的底层必须是JBOD，RBOD,ISCSI,SAN，2016开始，不叫SOFS了，叫SDS。2016可使用服务器自己的服务器硬盘，来贡献群集存储池”。

备注：RBOD一组冗余的磁盘；JBOD：简单磁盘捆绑。

      那今天我就来测试一把微软在Windows Server 2016构建“超融合基础架构”的效果吧，这里个人测试重点网络部份较弱，还请你们包含，重点体现计算资源、存储资源、虚拟化资源。个人测试环境也由于受到一些限制，所以我这里采用了Hyper-V嵌套虚拟化来盗梦空间（既然是这样的测试环境，天然生产环境要更好，不能比拟哟）

对于Windows Server 2016的SOFS，你们能够先看看我以前写的这篇文章“WinSrv2016横向扩展存储（SDS）[无共享存储]”，先了解下，那我此次采用的是以下架构：

你们能够参考：

https://technet.microsoft.com/en-us/library/mt126109.aspx

https://technet.microsoft.com/en-us/library/mt693395.aspx

测试角色以下：

1台DC，4台WinSrv2016(tp4)，上层构建Win7虚拟机。

4台WinSrv2016每台宿主机挂载了4块10G的磁盘。

那么部署的过程我就再也不详细描述，我只会对特别的地方进行截图给你们介绍，基本的步骤和“WinSrv2016横向扩展存储（SDS）[无共享存储]”同样。

#建立群集和启用S2D

#建立存储池

#建立虚拟磁盘

能够启用机箱感知了

选择磁盘类型

这里我选择Mirror类型

在大小处就是从可用的64G中建立虚拟磁盘，为何是64G呢？由于咱们的存储池总大小是144G，双副本就是除以2就是大约64G（可能要消耗点磁盘的一些空间存储信息吧，个人猜想）

#建立卷

#建立群集共享卷

开启嵌套虚拟化

4台宿主机安装Hyper-V

重启2次后在一台节点宿主机上建立一个Win7的虚拟机

这就是嵌套虚拟化哟：（怎么作嵌套虚拟化你们能够看看徐老师的博客：Microsoft 嵌套虚拟化技术(Nested Virtualization)）

接下来把该虚拟机变成高可用的群集虚拟机

OK。接下来我测试下故障转移链接咱们的嵌套虚拟化里的Win7掉几个包，记得我这里是测试环境，若是是生产环境应该会好更多。

固然在线迁移是不会让个人Win7关机再重启的，而是掉1个包就切换到其余节点继续运行

开始实时迁移节点

从Stor1节点到Stor2节点看只掉了一个包

若是某个服务器节点须要关机，那么您能够直接关机会自动触发故障群集转移，让Win7在线迁移到其余节点继续运行的

最后我关掉了3个节点，只剩下Stor4节点，Win7就挂了，缘由是存储空间不足而让存储池脱机。(还剩2个节点时，Win7还能够继续正常运行)

 

个人能力有限，所以先给你们分享到这，欢迎你们拍砖指正，您的支持，个人动力！