为 AIStor 部署选择最佳硬件
从一开始,AIStor 就被设计为在许多不同类型的硬件上高效运行。我们建议我们的用户和客户在纯 JBOD 模式下使用带有磁盘的商用硬件,以确保底层基础设施尽可能简单和高性能。AIStor 是高性能和可扩展性的完美结合,这使得每个数据密集型工作负载都触手可及。

选择最佳数据中心站点
在考虑灾难恢复或分布式数据时,数据中心的物理位置及其与客户的距离确实很重要。您希望在能够在尽可能靠近边缘客户提供数据,但同时能够访问能够将数据复制到多个位置的大型 Internet 管道之间取得平衡。
AIStor 提供以下类型的复制:
- 存储桶复制:配置每个存储桶规则以在两个 AIStor 存储桶之间同步对象。Bucket Replication 在存储桶级别同步数据,例如存储桶前缀路径和对象。您可以随时配置存储桶复制,远程 AIStor 部署可能在复制目标存储桶上具有预先存在的数据。
- 批量复制:您可以使用复制作业类型创建批处理作业,以间隔将对象从本地 AIStor 部署复制到另一个 AIStor 位置。定义文件可以按存储桶、前缀和/或筛选条件限制复制,以仅复制某些对象。
- 站点复制:将跨多个站点的多个 AIStor 部署配置为称为对等站点的副本集群。每个对等站点都会同步存储桶作、STS 以及其他组件。
自从我们引入多站点主动-主动复制以来,我们的重点一直是最大限度地提高复制性能,而不会对集群执行的现有作造成任何额外的降级。这允许您跨多个数据中心、云复制数据以进行持续运营和分析,甚至用于灾难恢复,其中一个站点离线不会降低整体应用程序可用性。复制配置完全在服务器端处理,本着一劳永逸的精神——使用 AIStor 的应用程序不需要以任何方式修改。我们致力于灵活性,这意味着 AIStor 支持现场和存储桶级别的复制,使您能够根据应用程序的需求微调复制配置,并尽可能多地控制该过程。使用 S3 样式策略和 PBAC 在多个 AIStor 部署中通过 IAM 保持数据保护。复制会同步对象和存储桶的创建、删除和修改。此外,它还同步元数据、加密设置和安全令牌服务 (STS)。请注意,您可以使用站点复制或存储桶复制,但不能同时使用两者。如果您已经在运行存储桶复制,则必须禁用它才能使站点复制正常工作。
选择服务器硬件
在基准测试、压力测试或建议生产硬件期间,我们一直是商用硬件的支持者。使用 AIStor,不需要像具有专有网络的专用 infiniband 基础设施这样的东西来最大限度地提高吞吐量。性能和扩展(以及大规模性能)由在商用硬件上运行的 AIStor 进行管理。我们不建议在 AIStor 之外添加 RAID 控制器或任何其他分发复制组件。理想情况下,服务器只需要包含一组具有足够驱动器容量的磁盘 (JBOD),以便能够满足您预期的数据对象需求和速度,以使网络饱和。AIStor 旨在跨多个站点在软件级别处理数据的持久性、复制和弹性,同时可以将底层硬件配置保持在最低限度。稍后,我们将详细介绍 Server 内部的特定组件。
驱动器
由于这里的主要用例是存储,让我们先来谈谈驱动器。有许多不同类型的驱动器,每一种在成本、性能和容量方面都有很大差异;必须根据用例进行选择。驱动器大致可分为以下三类:由于这里的主要用例是存储,让我们先来谈谈驱动器。有许多不同类型的驱动器,每一种在成本、性能和容量方面都有很大差异;必须根据用例进行选择。驱动器大致可分为以下三类:

通常,如果您在生产环境中使用 AIStor 集群进行基本对象存储,那么您可能应该考虑使用像 NVMe SSD 这样的东西,它可以在成本和性能之间取得良好的平衡。如果您正在处理超过一年的备份和存档数据,并且不经常查询,但仍需要访问它,尽管速度不是闪电般,那么可以将其分层到更实惠的媒体。在这些情况下,您很可能会选择存档层中的简单主轴 SATA HDD 以节省成本。这就是 AIStor 的美妙之处;它非常简单、灵活,不仅可以在无数硬件上运行,而且您可以对对象进行版本控制和分层数据,以将未使用的旧数据发送到慢速驱动器(如 SATA),但将最新或经常访问的数据保留在快速介质(如 NVMe)上。如前所述,根据我们的基准测试,NVMe 提供了最佳的性能成本比。
网络
在您自己的本地系统上工作时,您可能会将驱动器视为存储方面的主要瓶颈。虽然情况可能是这样,但当您将分布式存储添加到 AIStor 等组合中时,瓶颈会发生变化,您还需要考虑取决于网络的节点间性能。由于数据存储在多个服务器上,因此您需要确保服务器之间的数据速度尽可能快。虽然可以以 1 Gbps 或 10 Gbps 的速度运行,但如果您真的想要最佳性能,则需要使用双 NIC 以最低 25 Gbps 的速度运行。为了实现高性能,我们建议您使用您能负担得起的最快的网络和 NIC – 100GbE、200GbE 和 400 GbE NIC 是我们目前在生产中看到的常态。在谈论网络性能时,您需要考虑一些事情。由于某些开销,在物理上不可能达到 NIC 的最大理论速度,尤其是在考虑分布式设置时。除了 AIStor 之外,还有其他网络服务在正常运行期间会使用带宽。因此,您可以预期大约 50% 的 NIC 容量可用于 AIStor。在以后的博客文章中,我们将详细介绍网络的内部结构以及为 AIStor 设置网络的最佳方法。
低带宽会人为地影响 AIStor 的性能,因此必须确保所有网络组件(如光纤/以太网电缆、路由器、交换机和 NIC)都支持这些级别的高吞吐量。以下是我们推荐的准则的基本图表:

例如,如果您从我们的多服务器多驱动器文档中按照 4 个节点、每个节点 4 个驱动器(总共 16 个驱动器)的最低要求进行配置,则需要 25GbE 的总网络可能聚合输出。
CPU 和内存
AIStor 的 CPU 效率非常高,使用 TLS、内容加密、纠删码、压缩等功能通常不会对 AIStor 产生任何重大影响。典型的 CPU 使用率用于 IO - 网络,尤其是磁盘 IO。通常,AIStor 不建议购买 SMP 系统,除非您希望在离散 CPU 上运行多个 AIStor 实例。由于 AIStor 能够实现非常高的吞吐量,这意味着互连流量延迟和非一致性内存访问 (NUMA) 通常会大大降低系统的速度,以至于 SMP 几乎没有任何好处。通常,AIStor 不建议购买 SMP 系统,除非您希望在离散 CPU 上运行多个 AIStor 实例。由于 AIStor 能够实现非常高的吞吐量,这意味着互连流量延迟和非一致性内存访问 (NUMA) 通常会大大降低系统的速度,以至于 SMP 几乎没有任何好处。相反,AIStor 将从具有更高内核数的单个 CPU 中受益更多,或者将差价用于其他硬件改进。在考虑内存时,主要因素之一是集群上的并发请求量。并发请求总数的计算方式如下
totalRam / ramPerRequest
要计算每个请求使用的 Ram 量,请使用以下计算

让我们看看基于驱动器和 RAM 数量的最大并发请求数的几个问题

一般来说,内存量取决于请求数和集群中的驱动器数。下表显示了存储量和建议的最小内存。

如果您看到性能下降,例如系统内存不足,则可以通过向集群添加更多节点来分散负载,或者通过向当前节点添加更多内存来水平扩展。对于生产工作负载,我们建议使用 128GiB 的 RAM,以确保内存永远不会成为瓶颈。
机架电源
除了服务器故障外,机架及其周围的组件(如配电单元 (PDU)、交换机、路由器等设备)也会出现故障。此外,有时由于定期维护,这些需要离线,虽然采取了一切预防措施来确保维护不会破坏整个基础设施,但事情并不总是按计划进行,从而导致一些不可预见的单点故障 (SPOF) 失败。在为 AIStor 部署设计配电时,确保每台服务器至少有 2 个电源单元 (PSU),并且它们从不同的断路器连接到两个不同的 PDU,这一点至关重要。这是为了确保以下每个级别都有冗余:
- 电源故障(断路器跳闸)
- PDU 插座或条带故障
- PSU 设备或电源线故障
将服务器连接到 PDU 时,通常建议不要超过电路额定电流的 80%。例如,如果您配置了 30 安培电路,则不应将其负载超过 24 安培,否则存在电路过热和断路器跳闸的风险。然而,情况并非总是如此。某些数据中心是有线的,因此您可能会使用电路额定容量的 100% 全部。这些通常效率更高,因为每个机架可以比其他方式为更多的服务器供电。但是,当有 2 个电路用于冗余时呢?此时应该消耗多少电量?好吧,如果你仔细想想,如果你只能在一个 30 安培的电路上使用 24 安培,那么如果有 2 个电路,我们每个电路只能使用 12 安培。原因是当整个电路中断时,另一个电路需要接管额外的负载。如果两个电路都负载到 80%,那么在故障转移期间,单个电路最终将使用 24 + 24 总电流或 48 安培,并且它也将使“良好”电路跳闸。因此,建议在使用 2 个电路进行冗余时仅使用 50% 的可用电路容量。
但是,当有 2 个电路用于冗余时呢?此时应该消耗多少电量?好吧,如果你仔细想想,如果你只能在一个 30 安培的电路上使用 24 安培,那么如果有 2 个电路,我们每个电路只能使用 12 安培。原因是当整个电路中断时,另一个电路需要接管额外的负载。如果两个电路都负载到 80%,那么在故障转移期间,单个电路最终将使用 24 + 24 总电流或 48 安培,并且它也将使“良好”电路跳闸。因此,建议在使用 2 个电路进行冗余时仅使用 50% 的可用电路容量。
基准测试工具
对于任何生产环境,您都需要确保在基础设施上执行性能和压力测试。这可确保在将生产数据放置在节点上之前解决设置中的任何瓶颈或边缘情况。我们为开源社区和客户提供许多基准测试工具。
性能测试:作为“mc”管理工具的一部分,性能测试可帮助您对 AIStor 集群进行快速性能评估。使用结果,您可以跟踪加班性能或查看您可能遇到的特定陷阱。您将按如下方式运行命令:
mc support perf alias
WARP:这是由 AIStor 内部开发并作为单独的二进制文件开源的工具,它通过对 AIStor 集群使用的所有磁盘执行读写的混合测试,对 AIStor 或任何 S3 兼容存储进行全面基准测试。例如,这是启动 warp 混合基准测试的方法:
WARP_ACCESS_KEY=minioadmin WARP_SECRET_KEY=minioadmin ./warp mixed --host host{1...4}:9000 --duration 120s --obj.size 64M --concurrent 64
DD:这是测试驱动器性能的默认作系统工具。独立测试每个驱动器并比较结果,以确保所有驱动器都提供相同的性能。要显示具有一致 I/O 的实际驱动器性能,请在写入作期间测试驱动器性能。
dd if=/dev/zero of=/mnt/driveN/testfile bs=128k count=80000 oflag=direct conv=fdatasync > dd-write-drive1.txt
此外,test is 在读取作期间
dd if=/mnt/driveN/testfile of=/dev/null bs=128k iflag=direct > dd-read-drive1.txt
运行 dd 时要记住的一点是,确保您使用的大小与生产中预期大小相似的对象,以获得准确的结果。例如,如果您希望处理许多(数百万个)小文件,那么使用这么多文件和大小测试性能,以确保它在生产环境中表现良好。
IO 控制器测试:IOZone I/O 测试集群内节点上控制器和所有驱动器的读写性能。下面是你将运行的示例命令:
iozone -s 1g -r 4m -i 0 -i 1 -i 2 -I -t 160 -F /mnt/sdb1/tmpfile.{1..16} /mnt/sdc1/tmpfile.{1..16} /mnt/sdd1/tmpfile.{1..16} /mnt/sde1/tmpfile.{1..16} /mnt/sdf1/tmpfile.{1..16} /mnt/sdg1/tmpfile.{1..16} /mnt/sdh1/tmpfile.{1..16} /mnt/sdi1/tmpfile.{1..16} /mnt/sdj1/tmpfile.{1..16} /mnt/sdk1/tmpfile.{1..16} > iozone.txt
SUBNET:除了上述开源工具外,我们的标准和企业客户还可以通过 SUBNET 门户访问性能和运行状况检查工具。这增加了对性能数据的额外见解,并且我们的工程师能够指导您了解基础设施的架构和性能。
SUBNET 不仅深入到集群的性能检查中,而且还具有许多额外的好处,例如诊断、日志、集群检查等。但最重要的是,您将得到我们编写 AIStor 代码库的工程师的直接支持。在升级之前,您无需打开票证多次解释同一内容。我们的 SUBNET 门户在设计时考虑到了用户体验,它提供了一种类似于聊天的体验,与 Slack 类似,您可以在思绪流动时编写消息,而我们的工程师会帮助您解决问题。我们的一些客户告诉我们,SUBNET 很神奇 – 没有其他软件公司可以一键式编写代码的工程师。
利用 Chaos 建立Confidence
Chaos Monkey 是 Netflix 最初开发的一种工具,用于有意降低原本良好的基础设施,以便理解和预测不同的故障场景。该工具可以执行许多作,但一个示例是在负载下使一定数量的服务器脱机,以查看其他服务器如何正常地接管额外的负载。与 AIStor 类似,我们可以发挥创造力并尝试模拟故障。让几个驱动器或服务器离线,看看您设置的擦除码计算器设置是否真的根据计算器,它应该可以按预期工作。例如,如果您的设置要求在任何给定时间最多关闭 4 台服务器/脱机,请尝试实际随机关闭 4 台服务器,以查看集群是否仍在运行。这是在管理 AIStor 时在团队中建立信心的好方法,因此将来发生故障或需要进行维护时,每个人都可以确切地知道集群会发生什么。您还可以尝试使单个网络设备离线,例如交换机或整个机架,因为 AIStor 不仅可以了解驱动器和服务器级冗余,还可以了解机架级冗余,如下所示:
minio server http://rack{1…n}.host{1…n}/drive{1…n}
理想的硬件配置是什么?
事实是,AIStor 没有最佳的硬件配置。我们的客户根据其使用案例和要求选择硬件。如果 AIStor 有一个最佳硬件配置,那么我们会在设备上销售 AIStor,但这将剥夺您为工作选择最佳硬件的自由,并将您锁定在特定的外形规格中。相反,我们选择让您能够选择最佳硬件或实例来满足您的目标。请放心,无论您选择哪种硬件,AIStor 都能从中获得最大性能。在上述 32 节点基准测试中,我们没有使用任何性能调优的硬件,而是依赖于商用硬件上的通用 NVMe SSD。设置如下:在上述 32 节点基准测试中,我们没有使用任何性能调优的硬件,而是依赖于商用硬件上的通用 NVMe SSD。设置如下:
- 32 个节点,每个节点都有:
- 96 个 CPU 内核
- 768 GB 内存
- 8 个 7500 GB NVMe SSD
- 带双 NIC 的 100 Gbps 网络
此外,在将配置部署到生产环境之前,请务必使用上述工具对基础设施进行压力测试,以获得基准性能。执行 Chaos Monkey 类型的作,以确保基础设施尽可能具有弹性,并确保您的团队为意外故障做好准备。