在NetApp卷上设置配额是否合理?

当我得到一个由其他人configuration的NetApp时,我观察到所有卷都有配额,因此,我们经常会遇到问题,因为有人忘了在更改卷的大小时更新配额。

更明确的说,这些卷被同一个用户使用,所以我根本没有看到太多的配额逻辑。

当你想限制每个用户可以存储的数量时,我确实需要一个配额,但是当我有一个用户访问每个卷时,这些对我来说似乎是更多的开销。

请告知何时使用配额的好/好,而不是卷的大小。

注意:所有这些都是NFS共享,并且精简configuration未启用。

如果没有定义配额,您可以在几分钟内将所有存储空间填满。

这样做的后果是,你将不得不快速做一些清洁或购买另一个存储扩展柜来扩展你的可用存储空间。

启用配额后,您可以获得更多容量规划设施/更好地查看您的存储空间和使用情况。


顺便说一下,对于单个用户来说,如果你没有给他提供全部的存储容量,而是根据这个用户需求一步一步地增加音量,我看不到配额应该启用的原因,步骤将导致相同的容量规划概述和对存储的控制。

换一种说法 :

对于单个用户来说,在需要的时候增加音量就像给予给定用户更多的配额。

在那个特定的情况下,我会说配额的使用对我来说似乎是无用的。

如果只有一个用户,您可以拥有一个用户配额而不是qtree配额。 但是,配额通常不是必需的。

你应该始终做的是使qtrees作为你的主要存储点。 这样,你可以决定配额 – 或不。 但是,如果他们已经不是qtree,那么你不能。

在我的环境中,我们通常会configuration一切,只有有限的几个例子,因为我们精简configuration和重复数据删除。

我们的主要场景是:

  • 家庭驱动器 – 我们显着超额订阅,但给每个用户一个小配额。 因此足够的用户足够快地填满整个系统的可能性非常低。
  • 项目/服务为基础的规定 – 我们提出了一个小的(1 3左右)qtrees,每个单独配额。 我们将这些内容放在一个卷中,然后我们精简configuration,重复数据删除和应用快速预留。 卷大小设置为可以精简configuration达到配额大小总和+捕捉大小。
  • 大量删除卷,如VMWare磁盘映像 – 这些我们不配额,因为他们的许多用例是重复数据删除率。 我们经常得到70%以上的重复数据删除,这对空间和caching很有好处。

我们通常还会拍摄所有内容 – 在某些情况下,我们会进行快照检索,而且大多数情况下我们会自动删除主要内容。

我通常会build议配额是一件好事。 卷上的可用空间(报告)总是最低的:

  • 免费配额
  • 免费卷空间
  • 自由总计空间

注意 – 内置快照和重复数据删除。

所以,我们的配额,因为这最大限度地减less了困惑 – 否则你可以很容易地发生混淆,如何“如果我删除1G,为什么我的自由空间不变”的情况。 它还大大减less了逃跑进程/用户/日志文件的连锁效应。

我们不这样做的地方 – 我们在哪里提供批量和高重复数据删除 – 这些卷的“视图”仅限于对其工作原理有更好理解的pipe理员工。