好久没有写博了，最近特别忙而且也没想到什么好的题材，这次想分享一下存储空间与SMB的一些内容，其实这方面网上能搜到的信息不少，但是把存储空间与SMB3.0再加hyper-v群集串联在一起的就很少了，我也是溺水三千只取一瓢饮之
#####################################################################################
在这次测试环境中，我已经创建好了两个存储空间，testpool1与testpool2；以pool1为例下图可以看到这个池是由4块硬盘构成的，但是有个问题，如果是一些主流设备比如JBOD或者其他盘柜类产品，OS是可以正确识别出磁盘类型的，HDD或SSD；但拿我这个测试环境的老旧HP服务器来看，显然OS不能直接识别出来，mediatype里默认是unknown
这样就产生了一个问题，我们知道windows存储空间功能的一大特点是可以做存储分层，也就是storagetier（存储分层），系统可以根据使用习惯来区分热数据与冷数据，然后分别存放在传统硬盘或固态硬盘之上，此外还可以手动将指定的文件定位在高速介质上；但它的一个前提就是你的池中一定要包含HDD于SSD的mediatype才行，缺一不可；那么如果我的SSD无法正确识别的话我就需要手动来修改了
在操作系统的powershell中可以看到当前系统识别出的硬盘，以下图为例，有一些盘我已经手动将它们的类型修改过来了，还剩下一些unspecified的
接下来通过set-physicaldisk来修改，这里只需简单的指定磁盘uniqueid或friendlyname再加上mediatype就可以了
按照下面的例子将physicaldisk5修改成HDD盘
之后在server manager中刷新一下
可以看到磁盘类型已经变为HDD了，方法很简单的
接着来看一下pool2，我已经如法炮制将他们配置为HDD+SSD了，其实745GB那块本身就是SSD，但因为我的服务器比较老，RAID卡不做阵列的话OS中认不出来
后面就是在池中创建VHD了，这里就不做说明了，创建的向导中可以启用存储分层，并且制定分层的容量，在这个测试环境中，我把每块盘的全部容量都利用了，也就是说SSD的全部容量定义为SSD Tier，同理HDD也是，通过下面的get-storagetier可以看到不同层的相应参数
通过resize-storagetier也可以修改分层容量
下图中的F卷就是在pool2中创建的，使用simple模式也就是条带（raid0那种），这样以牺牲数据安全为前提来提高吞吐，并且磁盘采用固定大小而不是精简置备，这也是系统推荐的默认选项
####################################################################################
存储空间准备好之后，就要创建SMB共享了，在server manager中的shares部分创建一个共享
用于存放hyper-v或sql的话，一定要选择applications
然后选择这个共享是建立在哪个卷上，我就选择刚才存储池中创建的F卷
然后输入这个共享的名称，共享路径会自动利用该名称
然后可以选择是否加密数据以提高安全性
需要注意的一点是，对于存放hyper-v虚机的SMB共享一定要将每个节点的计算机名称和群集名称以及对应的操作账户（一般都是拥有域管理员权限的）加入到下图列表中并且授予完全控制
确认无误后就可以创建SMB共享了
按照上面的方法我在F卷上创建了名为ssd的共享路径
#####################################################################################
上面的内容从底层磁盘-存储空间-SMB共享这一条线都准备好了，下面就要准备hyper-v的群集环境了，failover cluster不多说了，这里我用两个节点A和B建立了一个hyper-v群集
对于hyper-v over smb的方案，可以参照下图中的几种模式，左边是最简单的独立hyper-v主机与独立的smb共享服务器（成本低，但后端存储单点故障，smb服务器挂了就废了，前端hyper-v不支持高可用但能手动live migration）；中间的是双节点smb文件服务器，前端还是独立hyper-v主机（这个方案主要是提高了后端smb的高可用，并且smb的fileserver群集是AA模式的，也就是全活的，带宽也是累加的，也就是所谓的“横向扩展文件服务器群集”http://technet.microsoft.com/en-us/library/hh831349.aspx）；最后的方案是更多节点的smb群集，也就是多机头的，但前端仍然没有改变，这里要说明的是，对于前端hyper-v层，最佳实践也是建议采用群集模式的，所以最终的拓扑应该是前端hyper-v群集+后端smb群集，这样vm支持高可用，smb支持高可用，并且吞吐量更高，还可以配合RDMA等硬件加速技术来提升性能
那么传统hyper-v群集是会按照下图规划的，磁盘方面首先要有数据盘用来存放虚机，然后还会有仲裁判来进行投票以便高可用场景，如下图所示，但是在hyper-v over smb的环境中，因为我们的存储是不依赖于以往的SAN或者直连存储的，我们是通过网络访问共享文件的方式来做，类似NAS；那么其实数据盘是不需要的，且仲裁的配置也因人而异，可有可无，如果我们是个十足的低成本场景，那么肯定是不会特地准备一块仲裁盘的，那么就直接用文件夹仲裁就好了，有关这方面的配置我就不多说了
接下来存储空间，SMB还有hyper-v都准备好了，这时候来到SCVMM，通过system center来对基础架构资源进行统一化管理才是云平台的核心价值之一，VMM对存储的功能是在架构部分来实现的，如下图所示，首先在providers中新加刚才准备好的smb服务器，选择windows-based file server即可
接着输入smb服务器的ip或者主机名，再选择有足够权限的运行方式账户
很快就会扫描出这台服务器，可以看到我是用一台HP DL580G4来做的，包括容量也能看到
下一步之后就能看到我之前创建好的两个共享目录了，ssd是刚才上面所讲到的混合vhd，hdd是在pool1中用那四块hdd做的，total和可用空间一目了然
最有价值的是classification，也就是分类，在vmm中对存储可以设置分类，对网络端口也可以进行分类，别小看分类，这不光是一个标识，它是对数据中心里的众多类型的资源进行合理的规划和分类，一是方便了管理（清晰），二是在通过自服务门户时可以交付给用户，因为用户不关心你的基础架构有多么复杂，他不会关心你用了哪些品牌的存储设备或网络设备，你只需要给他一个金银铜或三六九等的类型就可以了，下图中我创建了三个分类，FC SAN顾名思义，另外两个hdd与ssd fileshare是给这两个smb共享用的
此外你还可以新建更多的类型来进行管理
添加完providers之后就可以通过vmm来管理文件共享了
在file servers中可以同步出所有共享及分类并且资源使用情况也是一目了然
接着在群集属性中查看file share storage，可以看到两个共享已经分配给群集使用了
在对vm进行存储迁移的时候可以放置在新的smb共享中了
以VM01这台虚机为例，当前vhd存放路径已经是在smb共享中了
另外要提到的是，刚才前面说过存储分类的意义在于交付给最终用户，那么面向最终用户的就是“云”了，在vmm的clouds中可以对云资源分配指定的存储类别，这样用户在通过自服务门户时候或者租户申请订阅的时候，就可以选择他要使用哪一种类型来放置资源了，至于这一类型后面对应的磁盘类型及更底层的细节，用户可不关心
下面回到群集管理器，图中的三台虚机最上面这个ab是存放在CSV中的
而另外两台都是放在SMB共享上的，这里顺便说一下群集管理器左边的storage中也有一个pools，这里是什么意思呢，比如你有存储设备，不管是FC，iscsi或者DAS，whatever~你把他们挂载给每一个群集节点，然后通过这里来创建存储空间，并用于群集，在windows2012r2中，存储池无论是simple，mirror还是带校验的类型都可以用于群集了
接下来测试一下live migration，同时选择CSV上的ab与SMB3.0上的VM01一起迁移
迁移从A节点到B节点
SMB3.0的速度还是很快的，可能是由于SSD的原因，SMB迁移完成时HP FCSAN的迁移刚到69%
从测试效果来看，SMB3.0很靠谱，实际在生产环境中也是可以应用的，不会说有什么致命的性能或稳定性缺陷，并且配合SMB多通道技术，可以实现非常好的负载平衡效果（参考http://3387405.blog.51cto.com/3377405/1118659）
