标签: storage

我正在考虑实施一个非常大的存储服务器，用作其他几台服务器（均基于 Linux）的实时 NAS。

非常大，我的意思是 4TB 和 20TB 之间的可用空间（尽管我们不太可能真正做到 20TB）。

为了数据安全和性能，存储服务器将是 RAID 10，但我们仍然需要一个备份解决方案，包括异地备份。

我的问题是：你如何备份这么多数据！？

这不像我可以只连接一个便携式硬盘驱动器并传输文件。我们目前没有其他设备具有如此大的存储空间。

我是否需要为第二台异地存储服务器做预算，还是有更好的解决方案？

有没有人遇到过接近 100% Amazon S3 RESTful API 兼容的对象存储系统？

我所追求的是一个位于任何（最好是 POSIX）文件系统之上的层，它提供 Amazon S3 风格的 RESTful API 来存储 ( PUT)、检索 ( GET)、统计 ( HEAD) 和删除 ( DELETE)，并具有适当的身份验证。

也欢迎商业项目/想法。

笔记：

到目前为止，我已经尝试过Eucalyptus和Cumulus；其中 Eucalyptus 似乎盲目地称自己为 S3 兼容。响应 XML 文档根本不兼容，并且在某些地方不完整，根本没有 XML 文档。Cumulus 设法使响应文档保持非常相似，但似乎忘记了数据完整性！

让我解释后一部分：Eucalyptus 和 Cumulus 都不支持 Amazon S3 提供的完整性验证。您可以使用 S3 做的是，您可以提供 Base64(MD5(FILE)) 以及 PUT 请求，然后在 S3 成功响应之前对其进行验证。Eucalyptus 和 Cumulus 不支持这一点。有了 Eucalyptus，我们至少可以通过检查响应文档中给出的 MD5 来解决这个问题（不是 S3 兼容的行为）。在 Cumulus 中，这是不可能的，因为它不响应任何东西（如 S3）。由于未在HEAD请求中提供ETag，Cumulus 使情况变得更糟。

我在 CentOS 6.3 上设置了 Qemu-KVM 主机系统。四个 1TB SATA 硬盘在软件 RAID10 中工作。来宾 CentOS 6.3 安装在单独的 LVM 上。人们说他们认为客人的表现几乎等同于主持人的表现，但我不这么认为。我的 i/o 测试显示来宾系统的性能比主机系统慢 30-70%。我尝试更改调度程序（设置elevator=deadline在主机和elevator=noop来宾上），blkio.weight在 cgroup 中设置为 1000，将 io 更改为 virtio ......但这些更改都没有给我任何显着的结果。这是访客 .xml 配置部分：

<disk type='file' device='disk'>
  <driver name='qemu' type='raw'/>
  <source file='/dev/vgkvmnode/lv2'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</disk>

有我的测试：

主机系统：

臭氧测试

# iozone -a -i0 -i1 -i2 -s8G -r64k
                                                            random  random 
              KB  reclen   write rewrite    read    reread    read   write 
         8388608      64  189930  197436   266786   267254   28644 …

我们的 SQL 服务器负载越来越重，所有迹象都表明磁盘通道是瓶颈。当前的 HP 服务器具有相当低端的阵列卡，我们希望通过 Smart Array 卡和带有 SSD 驱动器的外部存储阵列来增强该服务器。

当前配置是：

• DL360 G7
• 智能阵列 P410i
• 视窗服务器 2008R2
• 32Gb 内存
• 当前阵列是用于启动/操作系统的 2 个 300Gb SAS RAID1 逻辑驱动器和用于数据的 1 个 120Gb SATA SSD 驱动器。

数据库服务器托管一个相当大的数据库 (~100Gb)，包含实时数据和历史数据。由于很多原因，拆分数据库不是一个选项，所以目前的想法是在新阵列上有多个逻辑驱动器，每个在它自己的通道上，然后将数据库拆分为逻辑 SQL 分区。

例如，该数组可能具有：

• 2 个 SSD (RAID1)
• 2 个 SSD (RAID1)
• 4 个 SSD (RAID1+0)

目前，我们正在研究带有高端智能阵列卡的D2600。

为了获得最大性能，我们确实需要每个逻辑驱动器都尽可能快地运行。惠普的规格表明，他们的高端 SSD 可以接近最大化智能阵列卡支持的 6Gb 连接。

但是，一些较大的 SA 卡表明它们支持“多通道”；我不清楚的是这是如何工作的。这是否意味着，使用从 SA 到 D2600 的单根电缆，每个 RAID 组都可以配置为获得自己的 6Gb 通道？或者 6Gb 是互连的限制，如果是，是否有任何配置选项（甚至不同的 HP 产品 - 不试图绕过“没有主观问题”规则，老实说 :) ）可以克服这个限制？

编辑：我看不到任何可以执行此操作的 HP 服务器，但是如果有一个不错的 Proliant …

一般来说，我想知道需要清理 RAID 阵列的频率。是什么导致需要更频繁地清理（读取数据？，写入数据？，意外关机？，驱动器寿命？，驱动器大小？，用户数量？等）？

我一直在这里阅读 Arch wiki ，它真正说的是应该定期进行擦洗。我只是想知道如何定期就足够了。显然这取决于，但合理的范围是多少？每年？每月？每周？日常的？非常感谢您提供任何信息。

我正在用 ESXi 服务器替换 KVM 服务器。我刚刚安装了 ESXi 5.5u1 并添加了一个数据存储。新服务器在使用硬件 RAID 的 RAID 6 中有 4 个 SSD 驱动器。当我添加数据存储时，VMware 说该存储不是 ssd。

这是正常的吗？显然，VMware 看到的是 RAID 卡暴露的虚拟磁盘，而不是 SSD 本身。是否应该告诉 VMware 这些是固态硬盘以获得最佳性能？还是应该留给RAID卡？我最担心的是TRIM。

小型 (SFF) / 2.5" 磁盘现在似乎比 LFF 磁盘更受欢迎，因为它们在许多情况下（低功耗、更高密度等）优于 LFF 磁盘。然而，LFF 磁盘似乎仍然具有在主要供应商的产品中（以最近发布的惠普 Gen9 系列服务器为例）。

从磁盘的价格来看，在大多数较低（低于 500GB）的容量中，这些天似乎几乎没有价格差异。这就引出了一个问题，为什么它们仍然足够受欢迎，让供应商觉得值得投资以支持他们的最新产品？纯粹是因为 LFF 外形尺寸的磁盘比 SFF 磁盘的容量更大，还是有其他原因使它们仍然受欢迎？

在此基础上，我试图了解在 SSF 上指定带有 LFF 机箱/磁盘的现代服务器的客观理由是什么。什么场景/要求可能意味着 LFF 将是首选？如果您需要以合理的成本购买数 TB 的大型磁盘，您真的会这样做吗？还是有其他原因？

关于 IOPS，我在网上看到几个消息来源表明给定磁盘数量的 IOPS 只是单个磁盘的 IOPS 乘以磁盘数量。

如果我对 IOPS 的理解是正确的（我完全不确定），我会认为现实将取决于 - 在许多其他因素中 - RAID 级别。使用 RAID 1/10，所有数据都至少在两个磁盘上复制，从而减少了某些 IO 模式在特定磁盘上的争用。但是，在条带化 RAID 级别（例如 RAID 0/5/6）中，数据是分布的而不是复制的，这意味着连续的读取请求可能针对同一主轴，从而导致在前一个 IO 完成时发生阻塞。写的更有争议。

我应该补充一点，由于各种优化和其他因素，我意识到现实要复杂得多。我的问题实际上只是在非常基本的层面上推动我对 IOPS 含义的理解是否在正确的轨道上。可能是我断言 IOPS 甚至可能以这种方式受到 RAID 级别的影响，这表明对该概念的基本误解。

我们正在采购新的联想 SR650 服务器（将托管多个 Oracle DB 服务器、SAP）& 供应商提出以下存储选项

• ThinkSystem 2.5" 1.2TB 10K SAS 12Gb 热插拔 512n 硬盘（数量：16 个磁盘）
• ThinkSystem 2.5" 5210 960GB 入门级 SATA 6Gb 热插拔 QLC SSD（数量：16 个磁盘）
• ThinkSystem 2.5" 5210 1.92TB 入门级 SATA 6Gb 热插拔 QLC SSD（数量：16 个磁盘）

我们在某处读到，在突然断电时，与 SAS 磁盘相比，数据完全损坏的可能性更大。

从性能和可靠性的角度来看，什么是更合适的存储选项？

我们有冗余的 UPS 以及数据中心专用的在线生成器。最初我们将托管 2 个 SAP 服务器（生产和开发）。两者都是虚拟化的。每个 VM 空间使用量约为 3 TB。过去我们使用Raid 5的经验并不好，我们所有的服务器都使用RAID 10，而在RAID10之后，我们没有遇到过去几年的任何故障。

将 16 个磁盘分成两个 Raid 10 阵列是个好主意吗？第一个阵列上的 PRD 和第二个阵列上的 DEV，所以无论进行什么操作（数据复制、备份等），都不应该影响第二个阵列？

在我的职业生涯中，我曾多次在各种环境（例如 CentOS/Debian 机器、Synology/QNAP NAS）中遇到 mdadm RAID 集（RAID1+0、5、6 等），它们似乎根本无法处理故障磁盘。该磁盘并未完全失效，但有数以万计的坏扇区，并且根本无法处理 I/O。但是，它并没有完全死亡，它仍然在工作。内核日志通常充满 UNC 错误。

有时，SMART 会将磁盘识别为故障，有时除了 I/O 缓慢之外没有其他症状。

缓慢的 I/O 实际上会导致整个系统冻结。通过 ssh 连接需要很长时间，webGUI（如果是 NAS）通常会停止工作。通过 ssh 运行命令也需要很长时间。直到我断开/故意将磁盘从阵列中“故障”出来，然后事情就会恢复到“正常” - 这与降级阵列一样正常。

我只是想知道，如果磁盘读取/写入需要很长时间，为什么不将其从阵列中剔除，在日志中添加一条消息并继续？这似乎让整个系统陷入瘫痪，因为一个磁盘有点奇怪，完全抵消了使用 RAID 的主要好处之一（容错 - 在磁盘发生故障时继续运行的能力）。我可以理解，在单磁盘场景中（例如，您的系统连接了单个 SATA 磁盘，并且无法正确执行读/写），这是灾难性的，但在 RAID 集（尤其是容错“个性”）中，它看起来不仅令人讨厌而且违背常识。

mdadm 的默认行为基本上会削弱该盒子，直到有人远程登录并手动修复它，这是否有充分的理由？