解决了

自动精简配置?

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

徽章 +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导致跳跃,因为懒惰应该精简配置。另外,当我创建一个懒惰归零的VM时,在VM创建完成后,磁盘被列为急切?
图标

最好的答案乔恩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
它在该文档中有一点语法断开连接。

厚的任何导致NOS在后端保留空间。唯一的区别是,如你所知道的懒惰vs eagar,它是否会出现在前面。

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

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


无论如何,有趣的事实,赢得NoS 4.6,我们向写缓存层(AKA 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仍然会尊重粗磁盘设置的前端预留。


这并不是说,压缩和/或dedupe是ulleles,完全相反,因为你仍然可以从较少的读/写入到后端磁盘和缓存放大(分别)中的性能优势,你只是能够结束订阅那些GB和TB的。

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

在这些以前的版本中,我们仍然将ZERO写入缓存,然后在我们排放缓存时才会写入它们。

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

AKA“数据避免”,意思是由于源数据永远不会复制(每次说,即不再常常复制图像),它是超级光滑的。

从Nutanix圣经中看到这段代码谈论我们如何做到:
http://nutanixbible.com/#anchor-snapshots-and-clones-65.

这里的整洁的事情是这使得能够更高效地制作更有效的东西,并且还允许您更有效地使用压缩,DEDUPE和ECX等数据减少技术。


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


综上所述,我们可以做得更好的一件事是报告影响在数据避免和瘦的供应中,我们的竞争对手使用的东西来利用他们的“数据节省”数字。显然,您可以通过您正在研究的内容来看待它,但在数据节省时普遍计算数据避免。该图片/比率仅显示Dedupe,压缩和ECX等内容。

未来的释放将分解这些区域,因此您可以从所有角度看到全部信息效率的数字。:
数据避免(智能)
数据还原(储蓄)
瘦身
徽章 +5
超级酷!感谢Jon提供的信息!

回复


Baidu