☰

具有大量主轴的 RAID - 如何安全地利用“浪费的”空间

tag-icon • tag-icon storage best-practices
具有大量主轴的 RAID - 如何安全地利用“浪费的”空间

我有相当多的 RAID 阵列（服务器控制器以及中端 SAN 存储），它们都面临同样的问题：几乎没有足够的主轴来保持峰值 I/O 性能，并且有大量未使用的磁盘空间。

我猜这是一个普遍存在的问题，因为供应商提供容量最小为 300 GB 的驱动器，但自从最小驱动器为 36 GB 以来，随机 I/O 性能并没有真正提高多少。

一个例子是，一个数据库有 300 GB 并且需要 3200 IOPS 的随机性能，因此它有 16 个磁盘（4800 GB 减去 300 GB，我们有 4.5 TB 的浪费空间）。

另一个常见示例是 OLTP 数据库的重做日志，该数据库对响应时间非常敏感。重做日志有自己的 300 GB 镜像，但占用了 30 GB：浪费了 270 GB。

我希望看到一种适用于 Linux 和 Windows 环境的系统方法。如何设置空间，以便系统管理员团队能够意识到阻碍主数据库/应用程序性能的风险？或者更好的是，如何避免这种风险？我想到的典型情况是“哦，我有这个非常大的 zip 文件，我在哪里解压它？嗯，让我们看看，df -h我们很快就会找到办法……”我不强调安全性的严格性（系统管理员值得信赖，会真诚行事），而是强调方法的整体简单性。

对于 Linux 来说，如果能定制一个文件系统来将 I/O 速率限制在很低的水平就太好了 —— 这可能吗？

答案1

我会考虑将高 IOPS/低空间需求数据库迁移到基于 SSD 的阵列 - 这些磁盘很小，可提供出色的吞吐量。这是最简单的方法

答案2

LUN，分区并有选择地呈现资源……

SAN 有 16 个磁盘轴，但这并不意味着使用该数据的服务器需要查看阵列的全部容量。直接附加存储也是如此。有时我可能在阵列中拥有大量磁盘，但我仍然会正确调整呈现给操作系统的 LUN/分区/设备的大小。

以下示例来自 HP ProLiant SmartArray 控制器，显示了 RAID 1+0 阵列中的 4 x 480GB SSD。也就是说有 960GB 可用。我从这 960GB 中分割出一个 400GB LUN。操作系统只能看到 400GB。而且，即使是这 400GB 也被划分为对应用程序有意义的逻辑块。关键在于，您可以控制存储空间使用者看到的内容：

   array B (Solid State SATA, Unused Space: 1012121  MB)


      logicaldrive 3 (400.0 GB, RAID 1+0, OK)

      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, Solid State SATA, 480.1 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, Solid State SATA, 480.1 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, Solid State SATA, 480.1 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, Solid State SATA, 480.1 GB, OK)

但最终，如果性能满足您的需求并且组织可以负担得起当前配置，那么您为什么会认为未使用的空间是“浪费”呢？

顺便说一句 -是可以在 Linux 中在块设备级别限制 I/O使用 cgroups。但如果您的主要应用程序或数据库存在风险，为什么不分离工作负载呢？

相关内容