基于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）[无共享存储]”，先了解下，那我这次采用的是如下架构：