WSFC2012 群集存储空间

从2008R2到2012R2 2016 再到即将发布的2019，仿佛就在弹指一瞬间，在这个演变过程中很多技术都发生了变化，有很多新鲜的场景涌现出来，很多好的技术在演变过程中国内没有人提到，尤为可惜，今天老王来为大家补遗一个群集存储池的技术场景

上来先来看图左侧是传统的SAN架构，右侧是微软软于Windows Server 2012引入引入的简单存储管理架构，微软提出来一个存储空间的架构，用来替换掉原来价格昂贵的SAN，通过为服务器接入简单的JBOD或RBOD架构，然后，通过2012新推出的存储池，存储空间功能，来完成存储上控制器的工作，存储池化，磁盘分层，精简磁盘，磁盘去重，磁盘镜像奇偶校验，将SAN上面控制器实现的功能，现在通过2012OS本身的存储功能实现，底层只需要接入一个没有控制器的JBOD磁盘捆绑，或者有RAID控制器的RBOD即可，适配器层使用微软OS自带的ISCSI，SMB3.0，NFS协议直接连接存储，所有对于存储的配置不再需要由存储管理员完成，系统管理员就可以直接在OS上面进行存储配置，简单管理，节约SAN成本，存储虚拟化，灵活分配存储，这是微软存储池，存储空间所解决的目的

常有人将存储空间，SOFS的概念搞混，以为SOFS就是存储空间，老王这里特地和大家解释下这几个概念的区别

存储空间是为了解决通过简单存储+OS配置，软件实现硬件存储阵列的容错，存储池，存储分层，去重功能

SOFS是基于SMB3.0，DNS轮询，WSFC CSV的连续性共享功能，利用SOFS共享可以获得，AA模式的访问交付，横向扩展优化，透明故障转移能力

Windows Server 2016的SDS是一种超融合交付存储资源池的模型，通过SDS可以支持由各节点本地共享磁盘，形成跨服务器的存储池，结合WSFC与存储空间实现端到端存储故障域感知

SOFS底层可以是JBOD存储空间，SAN，SDS，ISCSI ， SOFS SDS 存储空间三者之间并无必然联系

QQ图片20180717192436.jpg

上面和大家介绍了下单机上面存储池，存储空间的概念，其实对于新上手2012的人可能会对存储空间这个名词有点陌生，我在管理工具里面看不见存储空间，只能看见存储池，那个是存储空间？其实存储空间就是基于存储池上面创建的虚拟磁盘，当我们创建虚拟磁盘时会配置分层，精简，容错，这个过程其实就是在创建存储空间

那么大家看到微软这套简单存储管理架构里面，最关键的是那部分，无疑是第一张图里面存储控制器的部分，通过这部分实现存储池，存储空间，但是大家都只知道这是单台架构，如果只能用于单台服务器，那企业最多只是用来解决存储虚拟化，节约SAN成本的问题，但是距离真正的企业级应用还是有一点距离

因此还有另外一个技术场景，群集存储空间，如果我将存储控制器这一层实现的存储池，存储空间，通过高可用群集实现，默认情况下有一个服务器承载，这台服务器宕机，由另外一台存储服务器继续承载存储控制器，是否更加贴合实际应用了呢，这样的话我们就可以利用这样一套简单存储+Windows群集的架构，来真正的为业务提供存储使用

需要注意的是群集存储空间的概念，与ISCSI target服务器群集的概念不一样，如果我在群集里面提供了ISCSI target角色，那么我实际上是做的存储前端适配器这一层的容错，即是说我对外面用户访问我的ISCSI协议进行了高可用，如果一台节点连接不上ISCSI，其它节点还可以连接，而群集存储空间是存储池+存储空间的高可用

通过群集存储空间，我们会在WSFC2012上面构建群集存储池，再基于群集存储池创建群集存储空间，创建群集磁盘卷，被创建的群集磁盘卷，将直接作为群集磁盘，群集磁盘可以直接转为CSV提供给自身Hyper-V使用，或构建后端SOFS群集，提供给前端Hyper-V群集使用，但不论如何，这个CSV的底层是由一个高可用的存储空间而来，我们对这个存储空间进行容错或分层设置，即便当前节点失败，转移到另外节点，CSV底层磁盘仍然是保留我们的设置

双端架构上可以选择

前端单台Hyper-V，后端群集存储空间SOFS

前端多台单机Hyper-V，后端群集存储空间SOFS

前端Hyper-V群集，后端单台存储空间

前端Hyper-V群集，后端群集存储空间SOFS

不同的选择也将获得不同的弹性，高可用性，但是需要注意的一点是，如果您是这种前端Hyper-V，后端存储空间架构，那么Hyper-V连接到存储时会采用SMB3.0协议，去掉传统SAN的代价是网络改造，建议为前端虚拟化到后端存储之间准备10GB网络，以保证存储性能，最好网卡能够支持RDMA技术

除了这四种场景外，还有一种微软在国内很少提及的场景，Cluster in a box解决方案

这种解决方案是什么意思呢，大家可以把它想象成一个开箱即用的盒子，这个盒子里面有两个计算节点，SAS Expander连接JBOD存储，盒子买来会直接帮我们配置好硬件容错，配置好群集，配置好群集存储池，群集存储空间，我们只需要上电使用就可以了，通常这种盒子是由厂商OEM提供，它们会把盒子设计成故障域架构，始终帮我们保证有一个计算节点和存储可用，对于中小企业或分支机构不失为一个不错的方案，据老王所知Dataon 富士康现在在提供这种盒子

实际环境下如果要配置群集存储空间您可以结合自己公司的场景选择合适的架构，并不一定非要是这种CIB，如果是构建一组群集存储空间服务器，那么只要各节点SAS Expander接入JBOD存储即可，JBOD可以是一个，也可以是多个配置冗余

下面说下群集存储空间的先决条件

Windows server 2012/R2 标准版，数据中心版，或Windows Storage Server 2012 Standard
微软认证的SAS JBOD机箱 JBOD官方认证列表
故障转移群集中创建存储池至少需要三个物理驱动器，每个驱动器的容量至少为4GB，更多取决于列数和弹性。双奇偶校验存储空间至少需要七个驱动器
群集存储池必须由SCSI（SAS）连接的物理磁盘组成。不支持使用内部RAID卡或带有RAID控制器的RBOD
存储池磁盘必须为固定格式，不支持精简磁盘

需要注意

在2012时代，群集存储池还不支持底层由SATA构成的磁盘加入，2016 SDS可以支持SATA磁盘

在2012时代如果想要利用SATA磁盘创建高可用的存储池，建议借助Starwind产品

实验场景

08DC 10.0.0.2 255.0.0.0

30.0.0.2 255.0.0.0

12node1

10.0.0.5 255.0.0.0 10.0.0.2

18.0.0.5 255.0.0.0

30.0.0.5 255.0.0.0

12node2

10.0.0.6 255.0.0.0 10.0.0.2

18.0.0.6 255.0.0.0

30.0.0.6 255.0.0.0

在我的环境中由于我没有JBOD，所以我用DC模拟ISCSI服务器提供给两台存储节点

通过ISCSI分配给群集存储空间节点3个4GB磁盘

打开故障转移群集管理器管理控制台（cluadmin.msc），在面板左侧，展开“ 存储”，右键单击“ 池”，然后点击“新建存储池”

指定存储池的名称，选择拥有群集存储空间的存储子系统，点击下一步

配置群集磁盘物理磁盘架构，自动或热备用，如果需要配置分层，稍后创建完成后可以手动更新MediaType标签

创建完成界面如下，当前已经构建了群集存储池，可以勾选下面按钮继续创建存储空间，或稍后手动创建

创建完成后手动选择存储池界面下的新建虚拟磁盘，此步骤即是开始创建群集存储空间

输入虚拟磁盘名称，即群集存储空间名称，如果需要配置存储分层，应该在创建完成群集存储池之后去更新标签

选择配置群集存储空间容错布局，在2012时代群集存储空间仅支持简单和镜像，2012R2开始群集存储空间支持奇偶校验布局

创建完成群集虚拟空间后，自动弹出新建卷向导，选择基于群集存储空间磁盘创建卷

创建出来的卷，将自动显示在群集可用存储中

可以将由群集磁盘添加上来的再添加为CSV，上面我们提到的四种场景都是说的Hyper-V与存储分离，我们也可以尝试一种超融合的架构，这种超融合架构可以看到从2012时代就开始了，例如我们就四个节点，可以构建起来群集，先用着四个节点构建群集存储空间，最终到这一步构建出群集共享卷，然后再这四个节点上面安装Hyper-V，就跑在由群集存储空间构建出来的CSV上。有人说这样性能不好，但是为了保证存储到计算端到端容错，这也未尝不是一种合适的架构。

那么到了2016这种架构是不是就消失了呢，2016的群集存储池既可以用2012延续的JBOD这种方式构建，也可以用SDS构建，在2012如果使用这种超融合架构我们需要好好设计仲裁以及维护操作，以确保架构稳定运行，2016我们可以进一步利用站点感知和故障域感知技术。

或者我们也可以将群集做成基于群集存储空间上层的SOFS，然后通过这个SOFS为上层的SQL群集或Hyper-V群集使用

测试存储控制器故障转移，当前群集存储池由12node1承载

暂停12node1节点，存储池架构直接在12node2上面联机

群集虚拟空间，以及群集共享卷，联机上线正常使用，存储控制器配置信息即便转移到另外节点也得到保留

在群集运行中也支持手动故障转移群集存储池

这里需要为大家指出的一个问题是采用群集存储空间后的群集仲裁设置，最开始老王犯了一个错误，让群集直接使用群集存储空间的仲裁磁盘，这就有可能会存在一个问题，假设我群集只剩下两个节点+群集存储空间构建出来的见证磁盘，假设见证磁盘背后存储池所在的节点宕机，为什么是群集存储池，因为一切群集磁盘都是通过群集存储池创建的，群集存储池节点如果宕机，那么一切也就不存在了。假设剩下两个节点，或关键票数节点的时候，群集存储池节点土壤宕机，导致见证磁盘，来不及调整投票，导致需要强制启动群集，之后要手动联机存储池，存储空间

因此最优设计，应该是在最初设计JBOD磁盘的时候，单独留出来一块磁盘，不加入群集存储池，这块磁盘作为群集仲裁，不受群集存储池节点映像，第二设计是采用文件共享仲裁

其它需要注意的地方

已经分配给群集存储池的磁盘不能再添加到其它存储池使用
如果要部署具有更多节点的群集，则可能还需要SAS交换机以使所有节点能够连接到JBOD中的所有磁盘
如果需要将群集配置为SOFS，需要为每个节点安装文件服务器角色
如果需要为群集磁盘或群集共享卷启用重复数据删除，需在每个节点安装重复数据删除功能
内部RAID卡或RBOD虽然在群集存储空间架构不被支持，但是单机上面可以支持

存储空间的管理可以通过群集管理器或2012服务器管理器，不论是单机存储空间，或是群集存储空间，都可以在服务器管理器里面配置，利用存储空间，存储池配置的磁盘将获得灵活弹性，磁盘享受存储空间的容错配置，分层配置，如果磁盘大小不够可以由存储空间给予在线扩展，如果存储空间不够，可以通过增加磁盘扩展，存储池可以配置为自动修复机制，自动替换备用磁盘

如果我们有SCVMM架构的话，也可以利用SCVMM集中帮我们管理群集存储池，群集存储空间，SOFS

将存储池群集作为Providers添加进入存储基础结构