Netapp机头使用其它品牌SAN存储提供NAS服务的空间损耗率

简介

1.1 背景

Netapp NAS机头可以使用其它品牌存储的SAN空间提供NAS服务。发现两个使用这种方式部署的实际案例(Alpha和Bravo)中,损耗率与官方文档23.5%存在差异。Alpha损耗率为19%,Bravo损耗率为22%。

1.2 调查目的

明确差异原因

1.3 调查周期

2018年2月15日-7月26日

1.4 名词解释

损耗率(Overhead)

1 -(Netapp NAS文件系统初始总可用空间 / 底层存储 LUN总裸空间)* 100%

注意:不是磁盘标称容量 * 磁盘数,是SAN存储提供的LUN Raw capacity

BCS (Block Checksums)

是Netapp存储的默认checksum类型,注重性能,是虚拟化接管磁盘阵列LUN的优选checksum类型.

AZCS (Advanced Zoned checksum)

Netapp虚拟化接管第三方存储时可选的另一种checksum类型,不可用于Netapp自身磁盘,Netapp不推荐在要求高性能随机读的负载需求中使用这种checksum类型。

WAFL

Netapp Data ONTAP的文件系统名称。磁盘做成聚合后,都会以这种文件系统进行初始化,后续再以NAS或者SAN的形式提供服务。

1.5 调查结论

Netapp加底层存储SAN存储使用于桌面云环境,损耗率在22%,即文件系统得盘率78%左右,若不保留snapshot空间,得盘率即为78%,若保留5%snapshot空间,可用空间得盘率约为74%。如开启去重压缩功能,得盘率能够提升。

注:Alpha开启了snapshot和去重,当前可用空间得盘率为81%

调查经过

2.1 Alpha损耗信息

Alpha底层存储端截图如下:

图中每一行均为底层存储提供的LUN,大小见最后一列,3145728和2097152,单位为MB,换算后可见LUN的大小分别为 2TB 和 3TB

总容量 = 3T * 10 + 2T * 7 = 44T

4个Netapp机头看到的文件系统总容量如下:

Alpha-01:
已用 9.39TB
可用 1.52TB
Alpha-02:
已用 351.97GB
可用 203.49GB
Alpha-03:
已用 351.97GB
可用 241.3GB
备用 665.88GB
Alpha-04:
已用 21.53TB
可用 1.42TB
TOTAL 35.63TB

共35.63 TB

所以,损耗率 = 1 – 35.63/44 = 19%。

2.2 Netapp官方文档检查损耗率

该文档中可以清楚看到checksum若使用BCS类型,总损耗在23.5%,若使用AZCS类型,总损耗为12.56%,没有进一步深入描述。

跟代理商和及原厂交流,均表示为保证性能,一定会采用BCS模式。BCS损耗分为两部分:自身损耗12.5%,WAFL损耗11%,相加为23.5%。

2.3 Bravo现场实施情况

初始部署时,损耗率26%,经过关闭snapshot后,损耗率降低为22%。

至此,存在Alpha 19%,官方文档23.5%,Bravo实施22%(或26%)等多种各异的情况。

详细调查

登入Alpha的Netapp机头收取日志,分析。

从命令aggr status –r 命令输出,可以看到使用的是block chesksum,同时看到有7个LUN,每个LUN大小为1835008MB

7个LUN对应于底层存储提供的7个2T LUN,每个2097152MB

计算一个LUN的损耗率 = 1 – 1835008/2097852 = 1 – 87.47% = 12.53%

能与文档第一步对应,如图:

继续查看df – A –r命令输出

Aggr0 为SSD盘,Aggr1 为刚才7个LUN所做成的聚合。可以看到Alpha启用了snapshot空间(默认配置为5%,该空间可以取消),其大小也应该加入初始可用空间内。

故可用空间为: 11133511124 + 585974268 = 11719485392KB = 11444810MB

本次做文件系损失 = 1 – 11444810 / (7 * 1835008 (Netapp识别到的LUN空间,非底层存储提供的LUN空间)) = 1 – 89.10% = 10.9%

与官方手册貌似能对应上,但是注意:这一步对应的分母是经过Netapp初始化后的LUN空间,10.9%是相对于此来说的。

真正的损耗率应相对于底层存储原始做出的LUN空间(2.1中描述的2T一个的LUN),损耗率 = 1 – 11444810 / (7 * 2097852) = 1 – 77.94% = 22.06%

此数值与Bravo去掉snapshot之后得到的22%数值一致。

可见,官方文档中12.5%与11%直接相加疑似有误。

2018年7月24日,在另一份官方文档中,我找到了详细的计算方式:

Checksum type Formula
BCS–array LUNs less than 2 TB N x(0.875 x 0.9 x 0.99 x Snapshot reserve)= Y
BCS–array LUNs greater than 2 TB N x(0.875 x 0.9 x 0.998 x Snapshot reserve)= Y
AZCS-array LUNs less than 2 TB N x(0.984 x 0.9 x 0.99 x Snapshot reserve)= Y
AZCS–array LUNs greater than 2 TB N x(0.984 x 0.9 x 0.998 x Snapshot reserve)= Y

表中可以看到,小于2T的LUN,文件系统总可用空间得盘率(不考虑reserve)为 = 0.875 * 0.9 * 0.99 * 1 = 77.96% ,损耗率=1-77.96% = 22.04%,此结果和上述计算一致,和Bravo去掉reserved后实际情况一致。

以Bravo初始情况,文件系统总可用空间得盘率(考虑reserved)为 = 0.875 * 0.9 * 0.99 * 0.95 = 74.06% ,损耗率=1-74.06% = 25.94%,与实际一致。

那么为什么Alpha的可用空间损耗率只有19%呢?

用df -s命令查看,发现Netapp开启了去重功能,节省了15%的空间。由此推测,Alpha截图中的可用空间增大可能与该因素有关,并导致计算出来的损耗率偏低。

调查结论及后续建议:

Netapp机头使用底层SAN存储(单个LUN 2T)提供NAS服务,损耗率在22%左右,即文件系统得盘率78%左右,若不保留snapshot空间,得盘率即为78%,若保留5%snapshot空间,可用空间得盘率约为74%。

此条目发表在IT技术分类目录。将固定链接加入收藏夹。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注