背景
桌面云运行一段时间后,最初的存储空间可能不够,需要考虑扩容。这时候我们可能会发现,要向干系人描述清楚扩容的必要性和合理性并不容易。
想法提出后,问题也随之而来。
“为什么存储的空间这么快就不够用了?”“需要扩容多少?”“这次扩完未来多久可以不扩了?”
看似简单的问题要答好不容易。
今天分享自己面对桌面云存储扩容情形时会采取的第一步动作——技术信息收集。
假设前提:
1、环境中用户数据全部重定向到企业NAS存储。
2、存储采用外置NAS控制器提供NAS服务,非采用SAN+NAS多功能控制器。
1 数据增长来源
容量消耗项 | 关联因素 | 特点 |
---|---|---|
基础架构(组件服务器、黄金镜像等) | 桌面规模 | 不自动增长 |
写缓存 | 桌面规模 | 不自动增长 |
用户个人数据、共享文件 | 用户数量 | 随使用持续增长 |
容量检讨需求的出现通常是因为桌面规模的扩大,或者用户个人数据的自然增长。如果环境中的用户数量较多,那后者通常就是消耗容量的主因。
虽然根据上述常识或直觉,我们就可以尽快对用户数据展开分析。但我还是更推荐慢一点,把这套存储的空间到底是怎么配置和使用的仔细梳理一遍。
2 SAN磁盘池结构
凡是有系统查的,都应该从系统看。
首先从SAN存储中看磁盘构成。假设从存储管理软件或监控软件中得到下图。
我们可以看到所有的磁盘组成了三个Pool。通过对业务的了解,可以排除对Pool0和ssd-pool的关注——前者属于系统内置,而后者不承担容量增长型业务。
需要关注的是sas-pool,设备上所有的sas磁盘都应该在这个池中。因为环境中采用外置NAS控制器。那么在sas-pool磁盘池中,必然包含至少三部分空间:
- 给NAS控制器使用的。
- 直接给服务器主机使用的。
- 未分配的。
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是经过多层虚拟化的复杂过程后的产物。
- Raid被虚拟化成磁盘Pool。
- 磁盘Pool分出N个LUN给NAS控制器。
- NAS控制器把获得的LUN做成若干个Storage Pool。一个Storage Pool中可以划分出若干文件系统。
关于最大可用容量,类似SAN存储中的磁盘池,Storage Pool同样不能按照100%使用来计划。而且还要考虑到文件系统一般会做快照,快照通常会占文件系统5%空间。
5 总结
信息收集工作完成,意味着后续所有干系人基本能在相同的信息基础上检讨,偏差和误解不易产生。换言之,只有完成了第一步,检讨才能迎来真正的起点。