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 存储空间三者之间并没有必然联系 

上面和你们介绍了下单机上面存储池，存储空间的概念，其实对于新上手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能够是一个，也能够是多个配置冗余

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

1. Windows server 2012/R2 标准版，数据中心版，或Windows Storage Server 2012 Standard

2. 微软认证的SAS JBOD机箱 JBOD官方认证列表
   

3. 故障转移群集中建立存储池至少须要三个物理驱动器，每一个驱动器的容量至少为4GB，更多取决于列数和弹性。双奇偶校验存储空间至少须要七个驱动器

4.  群集存储池必须由SCSI（SAS）链接的物理磁盘组成。不支持使用内部RAID卡或带有RAID控制器的RBOD

5.  存储池磁盘必须为固定格式，不支持精简磁盘

须要注意

在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磁盘的时候，单独留出来一块磁盘，不加入群集存储池，这块磁盘做为群集仲裁，不受群集存储池节点映像，第二设计是采用文件共享仲裁

其它须要注意的地方

1. 已经分配给群集存储池的磁盘不能再添加到其它存储池使用
   

2. 若是要部署具备更多节点的群集，则可能还须要SAS交换机以使全部节点可以链接到JBOD中的全部磁盘

3. 若是须要将群集配置为SOFS，须要为每一个节点安装文件服务器角色

4. 若是须要为群集磁盘或群集共享卷启用重复数据删除，需在每一个节点安装重复数据删除功能

5. 内部RAID卡或RBOD虽然在群集存储空间架构不被支持，可是单机上面能够支持

   
   

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

若是咱们有SCVMM架构的话，也能够利用SCVMM集中帮咱们管理群集存储池，群集存储空间，SOFS

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

管理群集存储池阵列

将添加进来的群集存储池，经过建立逻辑unit的方式划分，而后分配给计算节点

若是群集配置有SOFS，能够将SOFS与群集存储池一块儿加入SCVMM管理，构建端到端的存储管理

但愿能够经过这篇文章让你们了解群集存储空间的概念，为你们带来思考与应用