高质运维：能否用重复数据删除功能优化 WSUS ？
笔者一直认为，只有高质量的运维才是达成网络安全的基础。要达成高质运维，少不了分析、设计、实现和验证的过程，这是实现高质运维的必经之路。
之前一篇文章表达这个观点时还写漏了一件事。前不久某公众号一篇文章，介绍 Oracle 数据库的安装，居然还是基于业已停服的 CentOS 7 进行过程介绍。
如果该文的读者不假思索地将其直接转化为 SOP，这妥妥的就是低质量 SOP。
更无论继续使用 CentOS 7 会产生什么样的网络安全风险。
笔者：国际认证信息系统审计师、软考系统分析师、软件工程硕士
说回 WSUS。本篇的内容是尝试通过启用重复数据删除功能而优化 WSUS 补丁更新缓存容量，进而从侧面提升 WSUS 服务器的性能。
从结果上看，其实并不算成功。但这个过程值得一写，因为高质量的运维文档，在 SOP 之外，还应该有 KB（Knowledge Base）。
关于WSUS 服务器的优化，笔者在前一篇文章：
提出要优化构成 WSUS 服务器的各个软件组件。
同样地，硬件方面也应该进行优化，所以笔者就把目光投向了：
存储子系统。
也就是试图提升补丁更新缓存的读性能。
即使服务器用的是固态硬盘，存储子系统依然是计算机系统中影响整体性能的关键组件。
WSUS 的补丁更新缓存容量可以非常庞大。所选择的分类越多、缓存清理的间隔时间越长，缓存的总容量就会飙升至以TB计算，总文件数量动辄过万也不在话下。
每月微软补丁日开始的一周内，WSUS 服务器的读压力相当重，如果还是在用机械硬盘，性能影响就更加明显。
所以，优化提升 WSUS 服务器补丁更新缓存的读性能，是隐性的刚需。
但多级 WSUS 服务器、企业级固态硬盘、阵列卡加缓存、服务器加内存充当缓冲等等这些都是花钱堆料获得性能，即使高效了也不算高质。
读性能要提升，最直接的措施就是减少数据总量。当数据总量越少，在操作系统这一级利用内存实现的数据读取缓冲区的效率就越高，整体读性能自然就越高。
NTFS 的文件透明压缩功能其实挺好的，所以必然会让系统管理员想到，能否将其用于 WSUS 的补丁更新缓存目录实现读性能提升。
这个想法的本质，是用 CPU 计算能力（计算时间相对较短）置换提升存储子系统读性能（数据读取时间相对较长）。
但可惜是，NTFS 压缩仅能对运行程序（微软甚至不建议）、工作文档这类文件有效，对 WSUS 的补丁更新缓存基本上没有效果。
原因是 WSUS 的补丁更新缓存基本上都是数据已经压缩了的 CAB 、WIM 和 PSF 文件。
手工尝试对 CAB 进行压缩，就算用 7-zip 的最大设置也难以获得多少压缩率，更何况是基于平衡性考虑的文件系统压缩功能。
下图1是笔者测试环境，对 WSUS 补丁更新缓冲目录整体应用压缩的结果：
图1 WSUS 补丁缓冲目录应用 NTFS 压缩实例
花费了2.5小时的压缩过程，获得的整体压缩比相当感人：99.75%。
具体点看看。随机选取其中一个子目录，内含4个 CAB 文件加起来总共 392MB，压缩后占用空间是 388MB，压缩比仅为约98.98%，详见图2、图3。
图2 WSUS 补丁更新缓存某子目录内容
图3 WSUS 补丁更新缓存某子目录压缩情况
而且，仔细看看还可以发现，实际只有其中一个 83.9MB 的 CAB 文件是被压缩了的，另外3个文件根本压缩不了。
图4 能被压缩的1个 CAB 文件
至于效能，因为压缩率的不足，就这一个被压缩的文件而言，不用测试都可以知道读速度提升不了多少，反而还因需要额外处理解压过程而浪费了 CPU 时间。
这还没完。WSUS 控制台的“选项”功能中，提示管理员可以选择下载快速安装文件（Express Installation，即 PSF 文件），如图5。快速安装文件可以提高终端计算机部署补丁更新的效率，但这些文件较大。
图5 WSUS 控制台-选项-更新文件和语言
快速安装文件体积较大......会不会可以被二次压缩？
这就涉及到了快速安装的实质[1]。
根据微软的文档，快速安装的实质是增量安装，也就是快速安装文件打包的内容是需要被更新的文件新旧两个版本之间的差异数据。
在执行更新时，通过旧版本文件+差异=新版本文件的方式完成更新。
由于仅包含差异部分，所以在这些差异内容数据之间，不压缩时的重复性都不高，更何况是被打包为 PSF 文件时业已压缩了一次。
再甚之，快速安装的过程需要从 PSF 大包中按需提取某些差异数据小文件，而 NTFS 压缩的工作原理[2]中 64KB 组合簇这个特性会导致更大的计算（时间）开销。
继续看看实例。笔者随手找了一个 PSF 文件，查看压缩情况如图6：
图6 快速安装文件 PSF 应用 NTFS 压缩情况
651MB 的大文件仅减少了 58658 字节。
所以 NTFS 压缩对于 WSUS 更新补丁缓存......一无是处了属于是。这分析下来，笔者认为不需要进一步的实践，直接放弃。
启用重复数据删除功能方法很简单[3]，笔者就简单放张图7算了：
图7 启用文件服务器和重复数据删除功能。
完成功能安装后，对存放有 WSUS 补丁更新缓冲的卷配置重复数据删除功能，如图8：
图8 重复数据删除功能配置
关于重复数据删除功能的原理可以参考图9：
图9 重复数据删除功能原理图
笔者建议读者详细阅读微软关于重复数据删除的文档[4]。文档质量非常高，把原理说得很清楚。
从微软的文档还可以了解到，经过重复数据删除处理的文件，还会同时对其中的可压缩的重复片段实施压缩，而不是整个文件压缩。
因此，在读取时并不需要 CPU 对整个文件实施解压操作，只有实施了压缩的部分数据片段需要解压。
这就在理论上达到了存储容量占用最小化、CPU 时间资源消耗最小化，以及关键的文件读缓冲效率最大化（相同的数据片段无论有多少片，都只占用同一块内存缓冲）等效果。
顺带一提，如果需要手工启动重复数据删除任务，可以在计划任务如图10的分类树中对后台优化（BackgroundOptimization）任务操作运行：
图10 重复数据删除任务的分类树位置
说了这么多，好像重复数据删除功能会很有效。但为何笔者说这次是不太成功的优化呢？
因为依然是通过实践说话。
在服务器执行了重复数据删除的优化作业之后，在服务器管理器界面检查执行的结果，有如图11：
图11 服务器管理器界面查看卷状态
顺带一提，图11中卷列表列标题的中文有错误。“删除重复保存”的意思实质是“删除重复数据后获得的空间”。微软自从应用机器翻译后很多界面文本是不准确的。
读者也可使用如下的一系列 PowerShell 命令进行查看：
PS C:\Users\Administrator> Get-DedupStatus -Volume "D:"
FreeSpace SavedSpace OptimizedFiles InPolicyFiles Volume
--------- ---------- -------------- ------------- ------
72.58 GB 4.79 GB 507 507D:
PS C:\Users\Administrator> Measure-DedupFileMetadata -Path "D:"
Path : {D:}
Volume : D:
VolumeId : \\?\Volume{d4615a74-4d0a-4caa-9d39-dbaddcf35445}
FilesCount : 511
OptimizedFilesCount : 506
Size : 80.15 GB
SizeOnDisk : 2.07 MB
DedupSize : 75.29 GB
DedupChunkCount : 1041412
DedupDistinctSize : 75.29 GB
DedupDistinctChunkCount : 1041412
PS C:\Users\Administrator> Get-DedupStatus -Volume "D:" |
>> select @{n=" Space saved (%)"; e={$_.SavingsRate}}, `
>> @{n=" Space saved (GB)"; e={$_.SavedSpace/1GB}}
Spacesaved (%)Spacesaved (GB)
---------------- -----------------
5 4.78830694966018
以上测试结果表明，在笔者的测试环境，重复数据删除功能对516个文件中的507个文件有效，占比约98.3%；释放出空间约4.79GB；重复数据删除率整体约5%。
5%，相比使用 NTFS 压缩实际等于没有效果的0.25%，比例上好很多，但对于总数据量并不多，和笔者理想中的两位数以上还是差得有点远。
这个数据量减少的程度，对读性能的提升不可能产生多少正面作用。所以也没有必要进一步花时间去做I/O测试，姑且就当读性能提升了5%吧。
本次设想用重复数据删除功能优化 WSUS 服务器，虽然可行，但并没有获得显著的成功，理论上仅能提升5%，在实际场景还可能小于这个数。
重复数据删除功能之所以能对压缩文件生效，主要原因在于这些压缩包内包含的文件有一些是完全相同的，所以经过相同参数的字典压缩算法后产生的压缩码流之间也会有部分相似。
任何技术发展都离不开试错过程。信息化运维中的调优更是完全离不开反复的分析、设计、实现和测试过程，这和软件工程的实现过程是一致的，也是计算机科学作为实践科学的典型特征。
所以，实践不仅是检验真理的唯一标准，实践也是认识内容的来源和认识发展的动力。
本文参考引用：
[1] Using Express Installation Files
[2] File Compression and Decompression
https://learn.microsoft.com/en-us/windows/win32/fileio/file-compression-and-decompression
[3] Install and enable Data Deduplication
https://learn.microsoft.com/en-us/windows-server/storage/data-deduplication/install-enable
[4] Understanding Data Deduplication
https://learn.microsoft.com/en-us/windows-server/storage/data-deduplication/understand
本站微信订阅号：
本页网址二维码：