WSFC2012 群集存储空间

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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网络,以保证存储性能,最好网卡能够支持SMB RDMA技术


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


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

技术分享图片


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


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


  1.  故障转移群集中创建存储池至少需要三个物理驱动器,每个驱动器的容量至少为4GB

  2.  群集存储池必须由SCSI(SAS)连接的物理磁盘组成。不支持嵌套层提供的存储,无论是内部RAID卡还是外部RBOD

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


需要注意的一点,在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. 如果需要将群集配置为SOFS,需要为每个节点安装文件服务器角色

  3. 如果需要为群集磁盘或群集共享卷启用重复数据删除,需在每个节点安装重复数据删除功能


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


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


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

技术分享图片

管理群集存储池阵列

技术分享图片

将添加进来的群集存储池,通过创建逻辑unit的方式划分,然后分配给计算节点

技术分享图片

如果群集配置有SOFS,可以将SOFS与群集存储池一起加入SCVMM管理,构建端到端的存储管理


希望可以通过这篇文章让大家了解群集存储空间的概念,为大家带来思考与应用 


以上是关于WSFC2012 群集存储空间的主要内容,如果未能解决你的问题,请参考以下文章

WSFC2016 延伸群集

WSFC2016 跨群集复制

WSFC2016 跨站点运行状况检测

WSFC2012R2滚动升级至WSFC2016

WSFC2008R2跨群集迁移WSFC2012R2

WSFC文件应用数据磁盘扩容替换