桌面云存储扩容第一步

背景

桌面云运行一段时间后，最初的存储空间可能不够，需要考虑扩容。这时候我们可能会发现，要向干系人描述清楚扩容的必要性和合理性并不容易。

想法提出后，问题也随之而来。

“为什么存储的空间这么快就不够用了？”“需要扩容多少？”“这次扩完未来多久可以不扩了？”

看似简单的问题要答好不容易。

今天分享自己面对桌面云存储扩容情形时会采取的第一步动作——技术信息收集。

假设前提：

1、环境中用户数据全部重定向到企业NAS存储。

2、存储采用外置NAS控制器提供NAS服务，非采用SAN+NAS多功能控制器。

1 数据增长来源

容量消耗项	关联因素	特点
基础架构（组件服务器、黄金镜像等）	桌面规模	不自动增长
写缓存	桌面规模	不自动增长
用户个人数据、共享文件	用户数量	随使用持续增长

容量检讨需求的出现通常是因为桌面规模的扩大，或者用户个人数据的自然增长。如果环境中的用户数量较多，那后者通常就是消耗容量的主因。

虽然根据上述常识或直觉，我们就可以尽快对用户数据展开分析。但我还是更推荐慢一点，把这套存储的空间到底是怎么配置和使用的仔细梳理一遍。

2 SAN磁盘池结构

凡是有系统查的，都应该从系统看。

首先从SAN存储中看磁盘构成。假设从存储管理软件或监控软件中得到下图。

我们可以看到所有的磁盘组成了三个Pool。通过对业务的了解，可以排除对Pool0和ssd-pool的关注——前者属于系统内置，而后者不承担容量增长型业务。

需要关注的是sas-pool，设备上所有的sas磁盘都应该在这个池中。因为环境中采用外置NAS控制器。那么在sas-pool磁盘池中，必然包含至少三部分空间：

1. 给NAS控制器使用的。
2. 直接给服务器主机使用的。
3. 未分配的。

2.1 未分配空间

首先，观察有没有未分配空间。同样通过管理软件或者监控工具生成图表。

上图中的Y轴单位是GB。

代表已管理空间的黑线，和代表总空间的绿线之间的间距，就代理了磁盘池中还没有使用的磁盘容量的大小。可以看到没有多少未使用的空间，大约6T。

这6T空间是可以随时分配使用的。事实上，实施扩容后新加入的磁盘也会先加入未分配空间，然后再划分给业务。有些存储系统在搭建时可能会有意预留较多的未分配空间。这是为了后续视业务占用情况灵活分配，因为存储中划分完成的空间基本很难缩小容量。

蓝线代表未使用空间，目测还有大约60T以上（这60T包含刚才未分配的6T）。

2.2 磁盘池最大占用

如果问设备原厂磁盘池最多能用到多少的话，一般会得到一个很保守的建议值，比如不超过80%。实际生产中，空间用到80%以上不少见，随着使用率向100%靠近，风险会上升，设备性能也会下降。这时一般就会启动扩容检讨，不会让它真正写满的。

2.3 磁盘池中LUN的分配

需要了解上图中标红色的内容：有多少LUN分给了NAS控制器，多少给了服务器，多少目前没有分配给任何设备。

此时，项目原先的空间规划资料非常值得参考（如果有的话），但最终确认需要分别登录进NAS控制器的管理界面和服务器虚拟化平台的管理界面查看。

经过上述步骤，我们对存储的整体把握感会进一步提升，再结合项目背景，某些认知就已经明确了，比如：

1、实际情况符合最初设计，LUN都在正常状态。

2、有40个4T的LUN分配给NAS控制器。有8个2T的LUN分配给服务器虚拟化平台。

3、用户规模基本不增长，LUN不需要增加。重点看提供给NAS使用的部分。

3 NAS控制器

NAS控制器相当于是一个主机，它使用SAN存储提供给它的LUN。建立文件系统，建立共享。给用户映射使用。下图是某NAS控制器的工作流程，从下到上有几个步骤。

我们首先要做基础检查，确认LUN的使用情况。LUN在NAS控制器看来，可能变成其它的名字，比如Drive，其实是一回事。如果有Unused Drives，那就是闲置资源，可以留意一下。但是有再多的Unused Drive，它们的空间也是包含在之间看到的sas pool的总的Free空间中了。

下一步，确认Storage Pool和文件系统内容。

如果发现这样的Storage Pool，其中包含的文件系统大部分都是办公型用户数据文件重定向目的地。那么基本可以判断这些文件系统就是容量消费大户，而这个Storage Pool就是重点分析目标。

4 数据增速分析

4.1 监控工具

最理想的情况是当然是能在系统中看到容量趋势分析报表。但这要求有点高。

系统中只能看到文件系统和Storage Pool的当前使用量，甚至很可能在存储自家的监控软件中也不提供趋势分析功能。

但一个有意思的现象是，当存储和其它监控分析平台集成的时候，后者也许能提供这样的功能。比如Vmware的软件VROPS通过HDS management pack集成HDS存储后，能收集到HDS的SAN存储信息，可以生成各种类型的趋势图，其中就包括SAN磁盘池的使用率，很有价值。

4.2 人工记录

如果运维习惯良好，比如管理员每月都会手动记录最新的Storage Pool使用量，那么大家很容易根据这些数据测算出平均月增量、平均年增量等信息，意义重大。

在不加干预的情况下，数据增速会随着桌面云整体规模的扩大而增加。道理很简单，使用的用户多了，文件也就产生得多了。因此，在估算未来若干年的数据增长情况时应考虑此因素。

4.3 Storage Pool最大占用

我们知道Storage Pool是经过多层虚拟化的复杂过程后的产物。

1. Raid被虚拟化成磁盘Pool。
2. 磁盘Pool分出N个LUN给NAS控制器。
3. NAS控制器把获得的LUN做成若干个Storage Pool。一个Storage Pool中可以划分出若干文件系统。

关于最大可用容量，类似SAN存储中的磁盘池，Storage Pool同样不能按照100%使用来计划。而且还要考虑到文件系统一般会做快照，快照通常会占文件系统5%空间。

5 总结

信息收集工作完成，意味着后续所有干系人基本能在相同的信息基础上检讨，偏差和误解不易产生。换言之，只有完成了第一步，检讨才能迎来真正的起点。