Windows Server2022存储池容量解析和群晖SHR的对比

前言：

        因为手头上有一些不同容量大小的硬盘，所以对于怎么更好的利用这些硬盘的空间有一定执念。查来查去比较合适的方案就是群晖的SHR了，然后黑裙就很不给面子的炸了我三次，每次都是只坚持了一个星期左右，最后还是装了win server直接用，做个屁raid。

        然后最近刷到视频说win server的存储池也有类似群晖SHR的效果，经过一通搜索后无果，大部分都是老掉牙的教程，教的也是普通windows的存储池，只能使用相同的硬盘大小来做单奇偶阵列。遂还是请教最开始刷到的那个视频的UP进行部署，终于成功。

        但是我和他都对于这个存储池最后建出来的大小也表示疑惑，这篇专栏就来记录一下我猜测的windows server存储池单奇偶阵列的容量计算方式（双奇偶应该也可以），也记录一下这个存储池的创建步骤。

首先，因为我没这么多真实的硬盘，所以只能用虚拟机进行测试。

测试环境如下：

4块100G、4块400G、1块50G的硬盘，其他的配置就不重要了，这里的硬盘容量乘以10就能模拟真实的硬盘容量大小。

（VM虚拟磁盘在动态分配的情况下，未使用的时候是不怎么占空间的，可以要插多少就插多少）

打开虚拟机，打开服务器管理器的文件和存储服务，新建一个存储池，我这里的存储池名称叫chi，先挂了三块100G的硬盘。

我理解的存储池就是把几个硬盘包含起来的一个集合体。

第二步就是创建虚拟磁盘了，要使用PowerShell来操作。

命令：

New-VirtualDisk -StoragePoolFriendlyName chi -ResiliencySettingName Parity -FriendlyName pan -Size 20GB -ProvisioningType Fixed -PhysicalDiskRedundancy 1 -NumberOfColumns 3

用我的工地英语翻译一下这段命令：

New-VirtualDisk      //新建虚拟磁盘

-StoragePoolFriendlyName chi    //关联存储池 chi

-ResiliencySettingName Parity    //磁盘阵列模式 单奇偶(raid5)

-FriendlyName pan    //新磁盘名称 pan

-Size 20GB    //磁盘大小20G，因为这时候不知道能多大，所以先建个小的

-ProvisioningType Fixed    //磁盘类型 固定大小(还有个动态扩展)

-PhysicalDiskRedundancy 1    //冗余磁盘 1 (1就是raid5，2就是raid6)

-NumberOfColumns 3    //阵列列数 3 (重要)

为什么要用命令创建而不用GUI直接创建，就是因为最后这个列数在GUI创建时是不能调整的。

这时候右键虚拟磁盘，点击扩展虚拟磁盘，就能查看磁盘的最大容量是多少：

计算一下虚拟磁盘对实际磁盘的利用率：190/(100*3) ≈ 63.3%

虽然不知道为啥不是100*(3-1)=200G，比预想的少了10个G，就当他是被系统占用了吧。

对比一下群晖的SHR：

群晖的1TB硬盘是931GB的，计算一下利用率是：1800/(931*3) ≈ 64.4%

这么看来还是群晖的SHR好点

那4个硬盘的情况下呢？

居然只有258！！！

正常来说100*(4-1)=300，再减去10G系统吃掉的空间，应该有290左右，显然不对劲！

这是因为前面创建虚拟磁盘的时候：-NumberOfColumns 3    //阵列列数 3 

阵列最大列数使用了3，存储池就把前3个硬盘做了一次Raid5，后一个硬盘又单独自己做了一次Raid5。（我是这么理解的，错了指正）（后面推翻了这个猜想）

所以实际的空间大小就是100*(3-1)+100*0.66 ≈ 258GB了。（0.66是3列数的理论利用率）

删除原来的虚拟磁盘，将命令的列数改为4后，创建虚拟磁盘：

熟悉的吞掉十几G，利用率达到了285/400=71.25%。

而群晖4TB硬盘的SHR利用率是72.5%，看来同等大小硬盘下还是群晖占优。

后面重复的测试我就不再赘述了，直接上结果：

直接说结论：

根据测试结果，存储池的列数要以最大容量硬盘的数量为准，假如有3块4TB的硬盘，那么列数就应该为三，否则像结果7和结果14一样，所有的硬盘会被以小容量硬盘计算（4T硬盘变成1T）。

而虚拟磁盘的空间计算公式约为：(n-1)/n       n不能小于3。

列数越高，利用率越高。

从利用率和体验来看，群晖的SHR确实强，但是它炸了我三次呐三次🤬！

然后来对比一下存储池和SHR的存储方式：

SHR的存储方式官方有说明，是以最小容量的硬盘为基底，把大容量硬盘都切成小容量硬盘的大小，然后在冗余一块硬盘情况下自动做Raid1或者Raid5：

这可能就是炸的快的原因吧(念念不忘.jpg)

存储池的存储方式（我猜的）：

以列数为准，取符合列数的硬盘为最大容量，如1T+4T+4T（3列）创建的虚拟磁盘，最后在虚拟磁盘眼里就是3块1T的硬盘。

而当1T+4T+4T+4T（3列）创建虚拟磁盘，在虚拟磁盘眼里就是3块4T+3块333G。

取出符合列数的最大容量硬盘后，剩下的凑数硬盘会被整合到一起，切成列数份（也有可能是每个硬盘都切成列数份）。

以下是第二次修改：

（后续测试后不是我想的这么回事，否则那个1T硬盘挂的话，因为没有在其他硬盘上做备份肯定会丢数据，而实际上在损坏任意一块硬盘后并不会丢数据）

以下是第三次修改：

后续查到了微软官方的资料，微软表示会均匀的将文件存在每个硬盘上，保证能够完全利用所有空间。(https://learn.microsoft.com/en-us/azure-stack/hci/concepts/drive-symmetry-considerations)

(示例讲的是多服务器之间的存储集群，但存储池的原理应该也是相同的)

文件会分布在所有硬盘上，这样既保证了文件的安全性，也保证了使用效率。即使损坏了任意一块硬盘，也能通过校验得到完整的数据。

但是我没猜错的话，当第4块硬盘(15TB)的容量过大的话，也是会导致会有空间闲置浪费的。

如果不想要有空间的闲置浪费，硬盘的总容量应该能被列数整除，且列数应该等于硬盘数-1。（使文件能均匀的分配到每个硬盘上）

如示例的(10+10+10+15)/3=15，四硬盘三列。

假设：

(10+10+10+15+15)/3=20，五硬盘三列。（因校验位比四列使用的更多，利用率低）

(10+10+10+15+15)/4=15，五硬盘四列。（利用率更高）

(10+10+10+15+15)/5=15，五硬盘五列。（会丧失两个15T硬盘多出来的5T）

因为列数是在创建后就不可变了，所以最大的硬盘要一开始就买好，否则后续添加硬盘，利用率将以最开始创建的时候为准了。

而对于后续扩展的硬盘，不管怎么优化，最大空间都不会比新建的存储池最大空间大。如：

4T+4T+4T+1T建立的存储池，创建出来的虚拟磁盘空间为858GB，通过右键属性存储池的物理硬盘，能看到硬盘的使用率都很高，剩余的可用空间不会很多：

4T+4T+4T建立的存储池，创建出来的虚拟磁盘空间为790G，然后再添加一块1T的硬盘进存储池，使用命令优化空间后，再扩展出来的总空间为844G，比刚才创建的虚拟磁盘少了14G。通过硬盘属性的利用率可以看出来，后续加进来的硬盘利用率不高：

所以win存储池可能只适合后续不会再扩充硬盘的情况。

据说存储池效率奇低，有空真机试试，看他炸不炸我就完了🤪。

感谢阅读

以上