解决了

自动精简配置?

  • 2016年3月16日
  • 7回复
  • 2831的浏览量

徽章 +5
从这个技术笔记-http://go.nutanix.com/rs/nutanix/images/TechNote-Nutanix_Storage_Configuration_for_vSphere.pdf,我的印象是,如果磁盘设置为“Thick provision Lazy zeroing”,Nutanix thin将提供虚拟机。

默认情况下,所有Nutanix容器都是薄配置的;这是NDFS的一个特性。精简配置是一种被广泛接受的技术,已经被多家存储供应商(包括VMware)证明了这一点。由于容器默认作为NFS数据存储呈现给VMware vSphere主机,所有虚拟机也会默认进行精简配置。这极大地提高了存储容量利用率,而不会对传统性能造成影响。如果需要用于有限的用例,如容错(FT)或要求很高的数据库和I/O工作负载,则可以使用VMDK级别的粗配置。可以通过创建Eager Zero Thick vmdk来完成普通发放。Eager Zero Thick vmdk将自动保证NDFS中的空间预留。

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

最佳答案乔恩2016年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。

这是因为如果您告诉Nutanix您想要厚的,我们不希望像其他一些存储系统那样意外地耗尽系统的空间,所以我们会自动地尊重这种惰性保留。

总结-你看到的跳跃是因为我们自动保留了空间。这并不意味着我们为您零,只是预订。


总之,有趣的是,在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
RE压缩-你成功了。您可以拥有一个可压缩的文件,并且可以将其重删到最细的一层,但是如果您对VMDK进行了粗配置,那么NOS仍然会尊重粗磁盘设置的前端预留。


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

乔恩
Userlevel 6
徽章 + 29
此外,为了后代的缘故,我们在持久性存储(又名Extent Store)中已经进行了零避免,因为我记得很久了,所以我们从未存储过零。这就是为什么如果您在nutanix VM中运行sdelete,您会看到VMDK(假设是瘦的)变得更小,空间回到容器中可用的原因。

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

4.6中的变化是将该逻辑提升到写缓存中,这样我们就不用把它们写到缓存中,这样一来,零写的确认就会非常快,缓存的使用也会更加有效。
徽章 +5
我有一种预感,我们会看到克隆可以节省大量的磁盘使用,但我想再次与社区确认。我们基本上有一个125GB的精简模板。我们已经从这个模板部署了100多个虚拟机(所有的部署都是精简的)。我们看到了令人难以置信的磁盘使用节省,我认为这是由于Nutanix在后端处理克隆的方式。在IE中,它只是一个新的块映射到不可变块映射的创建,所以几乎没有关于磁盘使用的成本。我知道,随着虚拟机覆盖和写入新数据,磁盘使用率将增长,但我们在stargate页面中看到每个虚拟机的使用率约为1.5GB。同样,这也是我所期望的,但是使用的磁盘空间非常少。想知道其他人是不是也看到了同样的东西。我不认为影子克隆在这里发挥作用,因为它们在多读取器场景中更活跃,而且我认为它只提高了性能,而不是实际的磁盘使用。
Userlevel 6
徽章 + 29
你已经击中了它的头(块映射复制,不可变的块切片等),我们做了非常高效的克隆,无论是从速度和利用率的角度,所以它们是快速的,只占用你调用的“增量”。

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

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

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


此外,你对影子克隆是正确的,严格的多读取器情况下,如链接克隆VDI(和vCloud Director)。


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

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

回复


Baidu