解决了

瘦身供应?

  • 2016年3月16日
  • 7回复
  • 2833意见

徽章 +5
从这个技术笔记-http://go.nutanix.com/rs/nutanix/images/technote-nutanix_storage_configuration_for_vsphere.pdf,我的印象是,如果磁盘设置为“厚的配置延迟归零”,那么Nutanix精简提供了VM。

默认情况下,所有Nutanix容器都是精简的配置;这是NDFS的一个特征。精简配置是一项广泛接受的技术,通过多个存储供应商随着时间的推移被证明,包括VMware。由于默认情况下作为NFS数据存储到VMware vSphere主机,因此默认情况下,所有VM也将默认配置。如果没有传统的性能影响,这导致大大提高了存储能力利用率。如果有限用例(例如容错(FT)或高苛刻的数据库和I / O工作负载等有限用例,则可以在VMDK级别上提供厚的供应。可以通过创建急切零厚的VMDK来完成厚的配置。急切零厚VMDK将自动保证NDFS内的空间预留。

这就是脱节的地方。当我提供一个延迟置零或即时置零的1TB VM时,这两者都会导致容器存储利用率上升2TB(使用的复制因子为2)。我希望只看到主动置零的VM引起跳转,因为lazy应该被精简配置。此外,当我创建一个延迟置零的虚拟机,在虚拟机创建完成后,磁盘被列为主动置零?
图标

最佳答案j2016年3月16日,20:56

\n
\nThick ANY causes NOS to reserve the space on the backend. The only difference is whether it zeros it out up front or not, as you know lazy vs eagar.
\n
\nThis is because if you are telling Nutanix you want thick, we dont want to accidently have the system run out of space, like some other storage systems do, so we'll respect that lazy reservation for you automagically.
\n
\nSummary - the jump you are seeing is because we automatically reserve the space. This doesnt mean we zero it out for you, just make a reservation.
\n
\n
\nAnyhow, fun fact, win NOS 4.6, we added Zero avoidance to the write cache layer (aka oplog), so zero operations should be much faster now, because we just see the zero and update metadata, instead of writing the zero to cache. very slick and cool stuff.","className":"post__content__best_answer"}">
查看原版

7回复

UserLevel 6.
徽章 + 29
在那个文档中有一点语法上的脱节。

Thick ANY导致NOS在后台预留空间。唯一的区别是它是否预先将其置零,就像你知道的lazy和eagar。

这是因为如果你告诉努力你想要厚,我们不想意外地让系统用完空间,就像一些其他存储系统一样,所以我们会尊重自动为您提供懒惰的预订。

摘要 - 您看到的跳跃是因为我们自动保留了空间。这并不意味着我们为您归零,只是进行预订。


总之,有趣的是,在NOS 4.6中,我们在写缓存层(又名oplog)添加了零避免,所以现在零操作应该更快了,因为我们只看到零并更新元数据,而不是将零写入缓存。非常圆滑和酷的东西。
徽章 +5
thanks for the reply John and you beat me to my next question of how do you protect against exceeding the actual usable disk amount if you are thin provisioning with lazy Very cool on using metadata magic to improve things. So, if VMs are provisioned thick, I'm assuming dedup and compression will not allow for overcommiting storage as the space will still be reserved per the VM being thickl provisioned.
UserLevel 6.
徽章 + 29
重新压缩 - 你钉了它。您可以拥有一个千里至1个压缩的文件,并将其缩小到最优秀的沙子,但如果您厚的配置VMDK,NOS仍会尊重厚磁盘设置的前端保留。


这并不是说压缩和/或重复数据删除在Thick中是有用的,恰恰相反,因为你仍然可以从对后端磁盘的更少的读/写和缓存放大(分别)中获得性能上的好处,你只是不能超过GB和TB的订阅。

j
UserLevel 6.
徽章 + 29
此外,为了后代,我们已经在持久存储(又名范围商店)中已经避免了零避免,因为我可以记住,所以我们从未存储零。这就是为什么如果您在营养内VM内部运行Sdelete,则会看到VMDK(假设瘦)变小,并且空间返回到容器中。

在以前的版本中,我们仍然会将0写入缓存,只是在缓存耗尽时不再写入它们。

4.6中的变化是将该逻辑推广到写缓存,因此我们只是将它们写入缓存,因此使零的确认零写入超快速,并更有效地使用缓存。
徽章 +5
我有一个亨希,我们会看到克隆的巨大磁盘使用量,但要仔细检查社区。我们基本上,有一个125GB薄的配置模板。我们从此模板部署了100多个VM(所有部署也很薄)。我们在磁盘使用情况下看到令人难以置信的节省,我认为是由于Nutanix在后端处理克隆的方式。即,它只是创建一个新的块映射到不可变块地图,因此几乎没有关于磁盘使用情况的成本。我得到的是,随着VMS覆盖和写入新数据,磁盘使用将增长,但我们在星形页面中看到每次VM的使用1.5GB左右。同样,这是我预期的一种,但是使用的很少使用的磁盘空间是疯狂的。想知道其他人是否看到同样的事情。我不是在思考影子克隆在这里扮演一部分,因为它们在多读者场景中更加活跃,而且我认为只需要提高性能而不是实际磁盘使用情况。
UserLevel 6.
徽章 + 29
你已经在头上击中它(块地图副本,不可变块片等),我们做了非常高效的克隆,都是从速度和利用率的角度来看,所以它们很快,只占用“三角洲”叫出来。

又名“数据回避”,意思是由于源数据永远不会复制(每说,即不复制图像一遍又一遍),它是超级光滑的。

看看《Nutanix圣经》中的这个片段,它讲述了我们是如何做到这一点的:
http://nutanixbible.com/#anchor-snapshots-and-clones-65

这里的整洁之处是,它使缓存之类的事情更高效,也允许你更高效地使用数据减少技术,如压缩、重复数据删除和ecx。


此外,您就在卷影克隆上,这是严格的多读者情况,如链接克隆VDI(和VCLoud Director)。


现在,所有这些都说,有一件事我们可以做得更好的工作是报告影响我们的竞争对手用“数据规避”和“精简配置”来夸大他们的“数据节省”数字。显然,你可以通过你正在看的东西看到它,但是数据回避在数据储蓄下的Prism中是不计算的。图片/比率只显示重复数据删除、压缩和ECX等内容。

未来的版本将分解这些领域,这样你就可以从各个角度看到完整的数据。
数据避免(智慧)
数据减少(储蓄)
自动精简配置
徽章 +5
超酷!谢谢jon为伟大的信息!

回复


Baidu