Azure Stack中的超融合存储-S2D进阶篇
连续快一周没有发东西，都有点不适应了。这段时间我生了点病，大概是除去经历过的骨折/运动损伤之外最严重的一次，现在好了有一半吧。所以最近只能优先保证日常工作，以及可持续战斗之体力，写东西分享给大家的频率还恢复不到之前的水平。见谅哈：）
————下面开始正文————
前段时间就听闻Windows Server 2016将要RTM及正式发布的消息，不知这次是否像以前那样一年后还有个R2出来？而同样备受期待的还有Azure Stack。
许多朋友应该都了解Azure Pack——一个System Center的插件，以类似Azure的门户来管理私有云，并与Azure云服务对接。而据微软的朋友讲，Azure Stack厉害的地方就是可以不依赖System Center去管理混合云。
在《微软WS2016原生分布式存储：还在追赶VSAN？》一文中，我曾经初步讨论过新增的分布式存储Storage Spaces Direct（S2D）。上周IDF有微软的架构师专门讲了Azure Stack，其中存储部分就包含有关于S2D的更多信息。
应该说本文只是一个“进阶理解”，距离权威专家还差得远，如有错误和不足欢迎批评指正。
为什么会有物理SSD缓存+逻辑分层？
Azure Stack如果采用超融合部署，那么就必然用到WS2016中的StorageSpaces Direct，而不能还是共享SAS JBOD的上一代SOFS。上图中用红框标出的将是本文的讨论重点——在ReFS弹性文件系统上的实时分层存储；以及更底层、只作用在本地服务器的Built-in Cache。
在对超融合的评价上，微软和业内小伙伴们的认识差不多：较小规模的起步点、允许增长/扩展、集群中服务器配置应该尽量相同等。目前WS2016的StorageSpaces Direct最大支持单一容错集群16个服务器节点。
相关阅读：《超融合面临的问题、SDS性能突破之路》
S2D的存储栈从下到上依次由这几层组成：
SoftwareStorage Bus：将本地磁盘/SSD进行一定的封装，通过SMB2和SMB Direct（RDMA）贡献给集群使用。这里面就包括Storage Bus Cache，稍后我会详细讲。
StorageSpace Storage Pool：“池”就是分布式存储的聚合层，实现多副本、纠删码等。
StorageSpace Virtual Disks：相当于LUN，从存储池中划出来的块设备。
ReFSOn-Disk File System：在Virtual Disk上创建弹性文件系统，目前看在这类用途中有替代NTFS的趋势。
CSVFSCluster File System：集群共享卷（CSV）文件系统的作用是，供Hyper-V集群中的多个主机同时访问，以配合MSCS实现HA等。
Cache类比VSAN、似曾相识的分层存储
“Built-In Cache”指的就是前面提到的“Storage Bus Cache”。它在启用S2D功能时自动配置，在每个Cache设备（SSD）上有特别的分区，并为pool和virtual disk的元数据预留32GB。SSD和HDD之间的绑定关系为Round robin，在拓扑改变（增/减盘）时会重新绑定。
这个Cache的行为包括：
- 所有不超过256KB的写操作被缓存；
- 64KB或者更小的读在第一次miss时被缓存；
- 64KB以上的读在10分钟以内的第二次miss时被缓存；
- 32KB以上顺序读不会被缓存；
- 在全闪存系统上，只进行写缓存
可见Storage Bus Cache与VMware的SSD缓存作用类似。我们知道上层的ReFS还可以配置自动分层存储，那么S2D缓存和分层之间的关系（协作）又是怎样的呢？
如果您对Dell SC（Compellent）的自动分层存储有所了解，看到上面这页ppt是否会有似层相识的感觉？前不久我发过一篇《存储极客：为什么说VSAN与Dell SC渐行渐近？》，就像音乐没有国界那样，IT技术原理也可以互相借鉴、取长补短，至于是否能够实现好则要看各自的功力了。
日前看到有同行朋友说某H记存储注册了双活专利，以至于秒杀其他所有人的感觉… 记得EMC VPLEX是最先提出存储双活的，好像也没说过别人一定做不到吧？对用户而言，真正的价值是解决了什么问题，如果换别家设备也能做到的话，可以测试下效果嘛。
回到上面的示意图，SSD Mirror（镜像）tier是热数据分层，HDD Parity（奇偶校验）tier则是冷数据分层。带有数字标号的深色圆圈表示物理层（Storage Bus Cache）的操作步骤：来自ReFS的写进入镜像层——SSD写缓存，然后按需降级到HDD。
而浅色圆圈则代表逻辑（ReFS）的数据实时分层：镜像层中的热数据变冷后按需调度（rotation）进校验层，这个操作会绕过SSD写缓存直接迁移到磁盘。
对于存储在校验层中的数据，如果进行修改都是写入到镜像层，校验层中的旧数据被无效化（元数据操作）。这一点就是为了充分保证写性能，可以说与Dell SC的Data Progression自动分层存储机制如出一辙。两者主要区别在于微软实时分层依赖ReFS和SMB3，适用于Windows/Hyper-V环境；而Dell SC则是通用SAN块存储优化技术。
网络流量：纠删码不得不考虑的问题
VSAN的重复数据删除和压缩
微软还表示纠删码的计算只在分层调度时进行，我们曾介绍过VMware VSAN和Dell SC是在这个时机进行重删和压缩处理，而VSAN的纠删码（RAID 5/6，只支持全闪存）则是一开始就写入多个节点的。这一点反应出微软S2D的设计要复杂些，相比之下VSAN则更简单。
从另一个角度来看，S2D和Dell SC都是用纠删码、RAID 5/6来放相对不活跃的数据。由于Dell SC是集中式存储阵列，数据分层处理都在内部进行，不像分布式存储那样产生网络流量；此外还可以在一组相同类型的磁盘中实现跨RAID级别分层（如下图）。
注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。进一步交流技术，可以加我的QQ/微信：490834312。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）
尊重知识，转载时请保留全文，并包括本行及如下二维码。感谢您的阅读和支持！《企业存储技术》微信公众号：huangliang_storage
长按二维码可直接识别关注