在考虑超融合（HCI）产品时，供应商，合作伙伴，经销商和客户通常会比较多种解决方案，这当然非常合理。
在进行对比时，市场营销材料通常用“ 对勾”样式对比表格作为技术参数对比，但是这样的形式往往非常片面，甚至可能误导对关键架构/规模考虑因素（例如容量，弹性和性能）的错误假设和理解。
让我举一个简单的例子：
客户选择/需要16个节点来满足他们的需求，他们选择最流行的2个机架单元（4N2U）4个节点规格的设备，以实现空间电力效率和高性能。
节点上装有6 x 1.92TB驱动器（全闪存），因为其用例需要闪存。
因此，我们有16个主机* 6个驱动器= 总共96个驱动器
96个1.92TB驱动器格式化后的容量约为1.78TB = 170.88TB
然后，客户对比了vSAN和Nutanix，它们都使用副本作为数据保护的主要形式（与传统RAID相对），使用两个副本（Nutanix中的RF2，vSAN中的FTT1）或三个副本（RF3或FTT2）。
如果贸然进行一些快速数学运算，可得出如下结论：
170.88TB / 2（RF2或FTT1）= 85.44TB可用
170.88TB / 3（RF3或FTT2）= 56.96TB可用
客户/合作伙伴/ VAR可以得出结论，两种产品的可用容量相同，或者至少对于购买或架构决策而言，差异不明显，对吗？
这里有两个关键的误区，导致计算是非常有误的。
原因1：文件系统/对象存储开销
所有新的和旧的存储产品（包括vSAN和Nutanix）都具有开销，这是很正常的，但是需要了解这些开销。
从Nutanix ADSF开始，“ curator”为后台操作预留（并隐藏）了一些容量，例如磁盘平衡和垃圾管理，也为持久性写缓冲区（称为“ Oplog”）预留（隐藏）了其他容量。
vSAN在每个“disk group磁盘组”中使用一个SSD进行缓存，而整个SSD的容量不是可用容量的一部分，就像Nutanix oplog容量没有被报告为可用容量一样。
VMware建议每个节点使用多个磁盘组，因此在本示例中，我们假设有2个磁盘组，因此假设有2个SSD用于缓存。
需要注意的重要事项：在全闪存vSAN配置中，自vSAN 6.7 u1起，缓存设备的100％专用于写缓冲，但最多只能达到800GB（以前为600 GB）。
参考：[了解vSAN架构：磁盘组（2019年4月）](Virtual Blocks: Understanding vSAN Architecture: Disk Groups)
原因2：空闲空间需求
在最近的一篇标题为“重新审视vSAN的可用容量建议”的文章中，讲到VMware过去几年一直建议所有vSAN集群都建议25-30％的“空闲空间”，而不管其大小如何。
根据经验，我实际上并不介意，好像该规则可以适用于容量规划非常保守的（可以说是容量过大的）Nutanix客户。但是，缺点是成本会大大增加，并且在许多情况下可能在商业上不可行，更重要的是，该解决方案可能会大大超出交付所需业务结果的要求。
旁注：（Nutanix）HCI的核心价值之一是能够根据需要从小规模开始规模经营。由于vSAN的空闲空间需求，因此确实会限制这个目标。另一方面，如这篇文章所示，Nutanix在容量，性能（线性）和弹性方面可以支持非常出色地扩展：
[使用Nutanix存储节点扩展性能测试](Scale out performance testing with Nutanix Storage Only Nodes)
这是上面引用的有关空闲空间的文章的摘录：
Nutanix ADSF在报告可用容量之前，已经考虑了临时活动（例如磁盘平衡和垃圾管理）的容量预留，以确保不会无意中使用该容量，避免可能导致的平台不稳定，性能问题甚至停机。由于Nutanix ADSF具有1MB / 4MB的粒度，因此后台活动所需的容量也要低得多，而vSAN对象的容量可能高达255GB，这可能导致容量碎片化，导致容量无法充分利用，或需要强制手动操作对环境进行碎片整理以增加容量的利用。
Vmware预留容量作为故障容忍是正确的，在4节点集群上使用N + 1可以证明25％的建议是合理的，但是当我们扩展到常见的8节点集群时，建议25％（较低的推荐范围的上限）已经是N + 2的余量，在许多环境中是不必要的。
如果我们扩展到16个节点的集群（至少对于Nutanix环境而言这也是非常普遍的），那么25％的集群将保留N + 4。如果客户希望防止整个模块（4N2U机柜）丢失，则可以证明该值是合理的，但是对于大多数环境（如果不是大多数环境）来说，该值仍然过高。
在32节点集群规模上，最低的VMware建议将使您保留相当于N + 8的水平。让我怀疑VMware的好处，这种保留水平仅能迎合少部分客户防止集群中的整个机架故障的需求，尽管我建议其他选择（例如4个单独的集群）可以实现更高的弹性/可用性，其中有4个节点保留用于空闲空间/ HA /故障。
但是，让我们回到两种产品的可用容量上，然后将实际值与我在该领域中得出的假设进行比较：
格式化容量170.88TB / 2（RF2或FTT1）= 85.44TB可用
格式化后的容量为170.88TB / 3（RF3或FTT2）= 56.96TB可用
让我们从一个16节点集群开始讨论
注意：对于所有计算，将使用最低VMware建议值25％，而不是建议值上限的30％。
理论最大可用容量（格式化/弹性水平）
现在让我们来看一下相同原始容量（170.88TB）配置下的vSAN的可用容量:
以下是具有此精确配置的vSAN集群的屏幕截图。
下面让我们对比一下Nutanix ADSF的可用容量:
下面是Nutanix环境的截图:
我们不需要成为数学专家即可看到两种产品之间的可用容量差异巨大，但是对于有兴趣的用户，对于完全相同的硬件和空闲空间预留，vSAN的可用容量比Nutanix低31.45％（尽管并不需要）。
以下显示了其中一台vSAN主机上的存储设备：
如果我们降低Nutanix ADSF的空闲空间会怎样？
如果将Nutanix的空闲空间设置为我通常建议的16节点集群（N + 2或16％集群的N + 2或12.5％），则计算（如下所示）对Nutanix更加有利，可用容量从61TB增加到71TB。
对于那些认为我选择了集群大小以显示Nutanix优势的人，让我们回顾一下具有相同硬件的4节点和8节点集群。
8 节点集群
vSAN 8节点集群摘要:
vSAN 报告的物理容量
Nutanix 8节点集群摘要:
同样，我们看到vSAN的可用容量仍低于Nutanix，但在这种情况下，对于完全相同的硬件，vSAN的可用容量少了41.25％。注意空闲空间保留已减少至12.5％（N + 1）
接下来，进行4节点集群比较：
现在让我们看一下vSAN的可用容量：
注意：4个节点集群不支持vSAN或Nutanix的RF3 / FTT2。
接下来让我们看看Nutanix ADSF的可用容量:
在这种情况下，两种产品的“空闲空间”均为25％，因为两者都需要维持至少N + 1才能承受单节点故障（N + 1）。这是vSAN的最佳情况，并且与Nutanix相比，我们仍然看到**vSAN的可用容量少了31.45％**，这也是完全相同的硬件和弹性级别。
但是，如果我们使用更大的驱动器会怎样？
VSAN使用3.84TB SSD的摘要:
Nutanix 使用3.84TB SSD的摘要:
Nutanix ADSF仍具有41.25％的优势。原因很简单，因为vSAN需要大量空闲空间的基础架构以及缓存驱动器不会对可用容量做出贡献的事实。
更新：参考[第2部分](Usable Capacity Comparison PART 2 – Nutanix ADSF vs VMware vSAN)，显示了在24个大尺寸驱动器系统上可用容量的比较。
有没有办法提高vSAN的可用容量？
简而言之，是的。我始终尝试保持公正，并提供双方意见，以下选项可以帮助增加vSAN的可用容量。
1）使用单个磁盘组，以便仅“丢失”一个SSD的容量
虽然这将增加磁盘组中“容量”驱动器的数量并因此增加可用容量，但代价是巨大的，因为这将影响性能，因为仅单个驱动器将用于写入/读取缓存。假设性能不是一个因素，那么不幸的是，弹性也会受到影响，因为单个高速缓存SSD故障会使整个磁盘组（包括其所有可用容量）脱机。如果仅存在单个磁盘组，则单个高速缓存SSD故障也将导致节点故障。
注意：Nutanix节点中的所有SSD均贡献永久性写入缓冲区（oplog），默认情况下，该缓冲区在所有驱动器上进行条带化，以实现最佳性能，并避免在少数驱动器上产生热点，而ADSF避免了仅使用闪存用于缓存带来的容量问题。
2）每个磁盘组使用更多的SSD和/或更大容量的SSD
在此示例中，我们有两个磁盘组，分别具有1个缓存驱动器和2个容量驱动器，这符合VMware关于性能的建议。如果节点支持更多驱动器，则每个磁盘组最多可以有7个容量的驱动器。
在这种情况下，由于缓存与容量的比率较小，因此性能再次降低。更为关键的问题是，如果单个缓存驱动器发生故障，则整个磁盘组将脱机，弹性将再次受到影响。由于需要重新复制大量数据，大尺寸的磁盘组会显著增加弹性风险，故障对性能的影响以及恢复弹性的时间。
使用Nutanix ADSF，任何单个SSD故障都仅仅是 “单个SSD故障”，仅此而已。这样，与整个磁盘组相对，仅单个驱动器数据需要重新被保护。唯一的例外是单SSD节点，SSD故障会导致节点故障，这是为什么我对于任何平台都不建议使用单一SSD系统的原因，也是为什么我不喜欢vSAN磁盘组架构的原因之一。
3）使用压缩/重复数据删除
这可能有助于提高存储效率，但是由于两种产品都支持这些功能，所以这样做不会显著改变解决方案之间可用容量的差异。
但是，如果vSAN解决方案是Hybrid，则不支持压缩和重复数据删除，因此Nutanix在可用容量方面将具有更大的优势。
4）使用纠删码/ RAID5或6
使用vSAN的RAID将增加可用容量，但与压缩和重复数据删除一样。Nutanix支持纠删码，这意味着它不会缩小两种产品之间的可用容量差距。
实际上，Nutanix率先把Erasure Coding引入HCI市场（2015年），这意味着容量优化再次重洗市场。vSAN RAID也可以线内（inline）工作，这听起来不错。但实际上这意味着对前端IO性能有直接影响，如果对于不适合RAID的数据集仍然应用RAID，则会造成不必要的主机资源成本浪费和前端性能的牺牲。
注意：尽管纠删码/ RAID对于不经常修改或访问类型的数据，例如WORM（一次写入多次写入），快照，备份，存档，对象存储，这些类型的数据非常有吸引力，但是，vSAN上的RAID配置仅限于全闪存配置。而在真正支持纠删码（EC-X）的Nutanix混合架构上效果也非常好。
话虽如此，请查看[Nutanix –纠删码（EC-X）深度分析](Nutanix – Erasure Coding (EC-X) Deep Dive)，突显了Nutanix实施Erasure Coding的独特优势，它避免了对前端IO的影响，并且仅适用于适合纠删码的数据，反对采用全有或全无的方法（例如vSAN实施）。这意味着Nutanix可提供最大的容量效率，而不会对写入路径产生直接的前端IO影响。同时意味着通过避免将纠删码应用于不合适的数据，从而降低对主机资源（或CVM vCPU）的消耗。
集群碎片及其对可用容量的影响：
由于vSAN使用对象存储的方式，每个对象存储的最大容量为255GB， vSAN的粒度粗糙，因此无论VM如何放置，并写入/读取操作通常转到某个节点上，而不是整个集群。如果对象的尺寸大于集群中磁盘剩余的可用容量，这可能导致某些容量无法使用。
借助Nutanix ADSF，无论空闲容量在哪里，都可以全部使用它并将其写入本地或远程，直到少于2个节点具有足够的可用空间来写入下一个1MB范围。（对于RF3 / FTT2，为3个节点）。
这是通过Nutanix智能副本放置实现的，该放置根据存储容量和性能放置写入IO（通常只有副本，除非本地节点已满）。
容量效率的优势会因工作负载类型而异，对于VDI场景效益不大，但对于混合工作负载优势明显，因为集群承载不同大小的VM可能会导致存储碎片化。
有关更多信息，请参阅：[Nutanix弹性–第6部分–在CVM维护或故障期间的写I / O](Nutanix Resiliency – Part 6 – Write I/O during CVM maintenance or failures)，其中将更深入地介绍此概念和故障方案。
总结：
在比较Nutanix和vSAN的可用容量时，对于vSAN需要确保根据磁盘组配置多出20-45％的物理容量，以适应本文中讨论的高开销，才是一个相对公平的对比。
这表明Nutanix ADSF（Acropolis分布式存储结构）与vSAN相比具有显著的[性能、可伸缩性和弹性优势](Nutanix | Scalability, Resiliency & Performance | Index)。Nutanix的简单易用还有助于确保客户（和架构师）不必关注磁盘组的复杂配置，同时提供了开箱即用的解决方案，同时拥有(curator/stargate)的后台功能，而无需再考虑“空闲空间” ”。
无论您选择Nutanix还是vSAN或任何其他HCI或传统存储产品/解决方案，请始终考虑弹性/可用性要求并进行相应的设计，因为可用容量只是要考虑的因素之一（尽管非常重要）。