简介

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%。