自动分层的实现与元数据密不可分

核心提示：EMC的FASTcache和次LUN(逻辑单元号)级别的FAST--此前被认为是FAST 2.0--让我再次思考如何在花费大量成本购买闪存记忆体之后获得最好的效益，自动分层的主要思想就是将热数据迁移到闪存而将访问频率低的冷数据留在旋转式磁盘上，自动分层的实现与元数据密不可分，我的问题是如何决定哪些数据是热数据，很明显，

EMC的FASTcache和次LUN(逻辑单元号)级别的FAST--此前被认为是FAST 2.0--让我再次思考如何在花费大量成本购买闪存记忆体之后获得最好的效益。自动分层的主要思想就是将热数据迁移到闪存而将访问频率低的冷数据留在旋转式磁盘上。我的问题是如何决定哪些数据是热数据。

很明显，自动分层要求存储系统搜集一些关于访问频率的统计数据。最简单的就是保留几天关于数据块的IOP(输入输出处理)/天统计数据或IOP/小时移动平均值。然后管理员可以创建一个政策，针对选定的卷，将拥有更高访问数字的数据块迁移到闪存层，将更冷的数据块迁移到高容量SAS驱动器所组成的垃圾层。

像平均温度这样的数据是很好的衡量指标，不过任何登过山的人都知道如果要判断穿什么衣服，平均温度还不足以提供关于天气的足够信息。即使某天的平均温度是70度，它可以是全天都是70度，也可以是上午7点50度而下午4 点90度。同样地，一些工作负荷是突发性的，它们在某些时候可能需要很高的IOP/分钟，但是全天的平均IOP却很低。我们通常只能将5-10%的数据放到闪存中去。如果根据平均IOP的话，那么这种数据可能不能归类到需要放到闪存的数据类别中去。比起迁移那些全天都是"74到85度温度"的数据，将当时是"90度温度"的数据块迁移到闪存可以为应用程序性能和成本带来更大的影响。然后还有定期工作负荷，比如每周的数据仓库立方体构建，月底数据处理等可以预测的任务。当我要在周五晚上或在月底最后一天进行数据分层的时候，我可能宁愿调出上个周六或上个月底数据仓库载入后的访问元数据。

最后，我们还必须考虑块的大小。在系统的每个块上保存访问元数据会很快耗光阵列CPU资源，而且还需要足够的空间，用户还得注意到他们的实际可使用空间要比往常的少5-15%。大的数据块分层很简单，但是它们同时携带热数据和冷数据，因此其有效性要打折扣。厂商们通常不怎么讨论分层中的数据块大小，不过我认为大部分使用的是可以和RAID(独立磁盘冗余阵列)条带相匹配的64K-4MB的数据块。

至于高速缓存，这个问题则一直都比较简单。