软件定义对象存储购买指南

数据是驱动现代企业的货币。能够代表组织多元化的利益相关者利用这些数据，是现代化、云原生、高性能且经济高效的系统的功能所在。这些现代化努力的核心是一个永恒的主题——使企业能够更好地服务客户。

这个目标可能很单一，但可以有很多途径。它可以是开发人员敏捷性、资本支出节省、运营支出节省、弹性或性能。所有这些途径都将与数据战略相交织。

本文概述了企业在评估软件定义存储时应考虑的因素。虽然一些组织会继续选择基于设备的解决方案，但这不是云原生的方式，最终会限制用例类型、部署场景和开发人员的吸引力。

该指南首先介绍对象存储、它的误区、它与文件和块的比较、它与云和 Kubernetes 的关系以及软件定义的重要性。

然后，它将注意力转向对象存储的关键选择标准，重点是软件定义的对象存储。

什么是对象存储

对象存储是一种数据存储类型，它将数据以不可变的方式存储为不同的单元，这些单元称为对象。对象是离散的数据单元，存储在命名空间中，命名空间可以是平面的，也可以包含“文件夹”或“存储桶”的概念，以便将它们分组管理。每个对象都是一个简单、独立的存储库，其中包含数据、元数据（与对象关联的描述性信息）和唯一的标识 ID 号。元数据可以与对象的内容一起以原子方式写入，也可以存储在对象外部，并为对象提供唯一的标识符。此信息使应用程序能够定位和访问对象。

对象存储以其无限的规模而闻名。对象存储通过称为存储池的构建块进行扩展。存储池可以组合并分布在网络中，实际上可以无限扩展。从弹性和灾难恢复的角度来看，这种分布式模型尤为重要。

与其他存储方法不同，对象存储中存储的数据无需按行和列排列。这类数据被称为非结构化数据，占企业总数据量的 80%。这些数据种类繁多，包括电子邮件、视频、照片、网页、音频文件、传感器数据以及其他类型的媒体和网页内容（文本或非文本）。此外，还可能包括流数据和时间序列数据。

对象存储系统中的对象（数据）通过应用程序编程接口 (API) 访问，其事实上的标准是 Amazon Web Service 的 S3。对象存储的原生 API 是基于 HTTP 的 RESTful API（也称为 RESTful Web 服务）。这些 API 查询对象的元数据，以便从任何地点、任何设备通过互联网定位所需的对象（数据）。因此，对象存储本质上是分布式的，可以通过 https 进行调用。

思考现代对象存储的另一种方式是将其作为与现代云数据库类似的键值存储。

对象存储的误区

现代对象存储与云原生运动之前开发的传统系统截然不同。许多与对象存储相关的谬论已不再成立或适用。以下列举一些谬论：

1. 对象存储速度慢。现代对象存储性能非常出色。通常，它可以达到硬件的最高性能水平，并且经常会达到硬件的饱和状态。对于 HDD 来说，这个速度指的是驱动器。对于 NVMe 来说，这个速度指的是网络。对于配置良好的 100 GBe NVMe 设置，对象存储的读取速度可以超过 365 GiB/s，写入速度可以超过 145 GiB/s。

2. 对象存储适用于归档工作负载。虽然对象存储更适合归档工作负载，但鉴于其可扩展性和性能特性，它非常适合 AI/ML、应用程序、分析甚至数据库工作负载。这在云端尤为明显，因为 Snowflake、Redshift 和 BigQuery 等核心服务都在对象存储上运行。

3. 对象存储无法处理小对象。正确架构的对象存储系统在处理 KB 级大小的对象时非常有效。这需要采用原子元数据方法。更多信息，请参阅所有关于小对象的文章。

4. 对象存储不适合以延迟为导向的用例。虽然对象存储在吞吐量方面表现出色，但架构合理的对象存储在 IOPS 驱动的工作负载下也非常有效。

对象存储、文件存储和块存储

现在我们了解了对象存储，那么它与文件和块相比如何？

文件存储将数据作为单一信息存储在文件夹中，以便于将其与其他数据进行组织。这也称为分层存储，模仿纸质文件的存储方式。当您需要访问数据时，您的计算机系统需要知道数据的路径。文件存储系统在互联网上的扩展性并不好，因此它们通常在数据量达到几 PB 时就会达到极限。

块存储将文件拆分成单个数据块，然后将这些块作为独立的数据片段存储。每个数据片段都有不同的地址，因此它们无需存储在文件结构中。由于块存储不依赖于单一数据路径，因此可以快速检索。它非常适合执行大型事务和部署大型数据库的企业。块存储价格昂贵，并且处理元数据的能力有限，这意味着需要在应用程序或数据库级别进行处理。

	目的	Block	文件
价格	$	$$$	$$
数据类型	半结构化和非结构化数据	结构化数据	结构化、半结构化和非结构化
规模	大规模（从 TB 开始，无缝扩展到 EB）	极少数TBs	TBs to PBs
协议	S3 API	Block Protocols (iSCSI)	CIFS, NFS
工作负载	人工智能/机器学习、大数据、流媒体、数据库、快照、备份	事务型数据库	存档，用户生成的文件
方法	对象 = 文件 + 元数据 + 全局唯一标识符	文件写入旋转介质的块中	文件和有限的元数据作为单独的条目一起存储

选择对象存储的企业可以获得以下好处：

1、更强大的数据分析能力。对象存储由元数据驱动，通过对每条数据进行这种级别的分类，分析的机会就大得多。

2、无限可扩展性。持续添加数据，永无止境。

3、更快的数据检索。由于对象存储的分类结构以及缺乏文件夹层次结构，您可以更快地检索数据。

4、降低成本。由于对象存储的横向扩展特性，存储所有数据的成本较低。

5、资源优化。由于对象存储没有文件层次结构，并且元数据完全可定制，因此与文件或块存储相比，限制要少得多。

对象存储和云

“云原生”一词在技术圈内被广泛使用，但并没有一个特别明确的定义。令人困惑的是，“云原生”与应用程序部署的环境几乎没有关系——该术语同样适用于本地部署或公有云。更确切地说，它指的是应用程序和架构的特性。容器、服务网格、微服务、不可变基础设施和声明式 API 都体现了这一点。

这些技术使松耦合系统具有弹性、可管理性和可观察性。结合强大的自动化功能，它们使工程师能够以最少的劳动频繁且可预测地进行高影响的变更。

这对于存储基础设施具有特别的意义。

现代应用程序架构基于亚马逊开发的 S3 API。该 API 仅与对象存储交互，并且由于它采用 RESTful（表述性状态转移）架构，使得对象存储成为云存储的主导类别。因此，从 Redshift 和 BigQuery 到 Snowflake 和 Datastax，云中的每项主要服务都构建在对象存储之上。

鉴于对象存储在云中占据主导地位，它沿着云原生路线图发展，遵循与云原生生态系统中的其他一切相同的动态、API 驱动的方式，其中自然包括 Kubernetes。

对象存储和 Kubernetes

存储成为Kubernetes原生存储究竟意味着什么呢？主要有六个标准。

1. 让 Kubernetes 编排存储节点

Kubernetes 是一个强大的编排工具，可以用来处理计算和存储编排。Kubernetes 集成了真正的云原生存储选项，允许运营商使用 Kubernetes 界面管理存储，并由 Kubernetes 处理从资源调配到卷放置的所有事务。

2. 高度多租户

多租户允许多个客户使用同一个应用程序实例。正确实施后，多租户架构可以降低运营开销、成本和复杂性，尤其是在大规模部署的情况下。然而，它也需要严格的资源隔离，以便多个用户可以访问计算或存储资源，而不会影响其他用户。真正的云原生存储解决方案将提供充分的资源隔离，以确保多租户架构的安全性、高可用性和高性能。

在对象存储领域，这意味着 Kubernetes 基础设施需要隔离和管理存储租户。如果 Kubernetes 不管理底层基础设施，那么它就不是真正的云原生。这使得那些提供 CSI 或 Operator 集成的设备供应商失去了资格。

3. 轻量级
除非存储系统极其轻量级，并且能够与应用程序堆栈打包在一起，否则多租户架构是无法实现的。如果存储系统占用过多资源或包含过多 API，则无法在同一基础架构上整合众多租户。

4.可扩展
可扩展性是云原生存储系统的关键属性之一。Kubernetes 的优势在于其在规模化方面已得到充分验证。Kubernetes 也可用于管理存储扩展，但前提是底层存储系统与 Kubernetes 集成，并将配置和停用功能移交给 Kubernetes。

5. API驱动
Kubernetes 和云原生系统的核心原则之一是尽可能通过自动化进行管理。要使存储系统真正实现云原生，它必须通过 API 与 Kubernetes 集成，并允许动态的、API 驱动的编排。

6. 用户空间
最后一点或许是最难的。对象存储解决方案要想成为云原生解决方案，必须完全在用户空间运行，且不依赖任何内核。大多数对象存储系统，尤其是硬件设备，并非如此构建。尽管如此，如果您希望将存储容器化并部署在任何 Kubernetes 集群上，就必须遵守这些限制。顾名思义，这意味着需要内核补丁或专用硬件的解决方案并非云原生解决方案。

虽然在某种程度上很简单，但要获得“云原生”地位，这两个标准在实践中实际上相当困难。公有云对象存储供应商在这方面表现相当不错——事实上，考虑到谷歌是 Kubernetes 的源头，而亚马逊是 S3 的源头，人们也预料到他们会如此。而私有云对象存储供应商在通过这些测试时则要困难得多。

传统的 SAN/NAS 架构不太适合云原生世界的需求，因此，你很难在公有云中看到它们大规模部署。除了技术因素之外，部分原因在于，云提供商为了确保这一点，将文件存储定价为对象存储的 13 倍，将块存储定价为对象存储的 4.6 倍，同时提供卓越的对象存储体验（快速、可靠、安全、RESTful）。

软件定义对象存储的重要性

虽然对象存储的优势显而易见，但只有选择软件定义对象存储的企业才能享受到所有这些优势。原因很简单：

1、软件定义是云的方式。您无法作为设备在云中或跨云运行。

2、您无法将设备容器化。对象存储的核心优势之一是其云原生性。而使用设备模型则需要放弃这一点。如果您无法将存储容器化，那么 Kubernetes 也将被淘汰。

3、软件定义扩展了硬件的范围。这一点至关重要，因为异构性是事物的自然状态，并且对象存储需要从边缘运行到核心。

4、软件定义技术在容量和性能方面提供了更大的灵活性。您可以购买一台用于 HDD 的设备，另一台用于 NVMe 的设备吗？是的——但软件提供了更高的灵活性和可选的芯片组（英特尔、ARM、Nvidia 等）。

软件定义对象存储的核心评估标准

纯粹的解决方案

许多解决方案试图在单一品牌下提供块、文件和对象存储。从管理角度来看，这似乎很有吸引力，但不可能同时成为一流的文件存储、一流的块存储和一流的对象存储。它们需要不同的侧重点、架构和方法。

选择一家只做对象存储的供应商。这将确保其在同类产品中处于领先地位。如果企业有文件和块存储需求，他们也应该在这些市场中寻找专业的解决方案。

AWS S3 兼容性

S3 兼容性是云原生应用的硬性要求。请选择同时支持 V2 和 V4 版本 API 的解决方案。与上述纯粹的竞争标准类似，寻找专注于 S3 的解决方案。

S3 API 是云中事实上的标准，因此，AWS 的替代品必须能够流畅地使用 API，才能在不同的环境（公共云、私有云、数据中心、多云、混合云和边缘）中运行和互操作。

最终的问题是，该应用程序是否可以使用标准 S3 调用来与对象存储端点兼容。这可以在选择之前确定。

对于更通用、用途更广的用例，请考虑供应商声明的有效性。这些声明可以测试吗？该软件是否专有，从而限制了通过 API 体验的用例、应用程序和硬件环境？

S3 选择

为了提供对大数据的高性能访问，分析和机器学习工作流需要服务器端过滤功能 - 也称为“谓词下推”。

开发人员和架构师应该寻求 S3 Select API 的 SIMD 加速版本，以便能够直接在对象存储上有效地启用 SQL 查询功能。用户可以对其对象执行 SELECT 查询，并检索对象的相关子集，而无需下载整个对象。借助 S3 Select API，应用程序现在可以下载对象的特定子集——仅下载满足给定 SELECT 查询的子集。

通过降低带宽需求、优化计算和内存资源，这直接转化为效率和性能，这意味着可以使用相同的计算资源并行运行更多作业。随着作业完成速度的加快，分析师和领域专家的利用率也将得到提升。此功能适用于 CSV、JSON 和 Parquet 格式的对象，并且对压缩对象也同样有效。

多云

对象存储应该在企业运营的任何云平台上运行。鉴于目前大多数企业都采用多云模式，这意味着所有主要的公有云（AWS、GCP、Azure）、所有主要的私有云和 Kubernetes 发行版（Tanzu、OpenShift、Ezmeral 和SUSE）、以及在云运营模式下运行的数据中心，甚至边缘计算。

如果对象存储无法实现多云功能，将严重限制对象存储占用空间、应用程序可移植性和业务连续性目标。顾名思义，多云只能通过软件定义的解决方案来实现。

擦除编码

任何对象存储都应使用每个对象都采用内联纠删码来保护其数据。纠删码应使用汇编代码编写，以提供尽可能高的性能。最先进的纠删码是 Reed-Solomon 算法，它将对象条带化为数据块和奇偶校验块——尽管这些块可以配置为任何所需的冗余级别。

这意味着，在 12 个驱动器配置（包含 6 个奇偶校验位）的情况下，一个对象会被条带化为 6 个数据块和 6 个奇偶校验块。即使丢失多达 5 ((n/2)-1) 个驱动器（无论是奇偶校验位还是数据），您仍然可以从剩余驱动器可靠地重建数据。请选择能够确保即使多个设备丢失或不可用，也能读取对象或写入新对象的实现方案。

纠删码保护数据不受 RAID 配置或数据副本的限制。复制会在每个站点上生成 3 个或更多对象副本。与复制相比，纠删码提供了更高级别的保护，同时仅占用极少的存储空间。

擦除编码应在单个对象级别进行。这样可以在对象级别粒度进行修复。对于受 RAID 保护的存储解决方案，修复是在 RAID 块层进行的，这会影响卷上存储的每个文件的性能，直到修复完成为止。

BitRot保护

选择可防止 BitRot 的对象存储。

静默数据损坏（或称比特腐烂）是硬盘面临的一个严重问题，会导致数据在用户不知情的情况下损坏。随着硬盘容量越来越大，数据需要保存多年，这个问题变得比我们想象的更常见。当磁极翻转并失去极性时，数据位就会衰减。即使是固态硬盘，当绝缘缺陷导致电子泄漏时，也容易出现这种衰减。还有其他原因，例如磨损、电压尖峰、固件错误，甚至宇宙射线。

最先进的 BitRot 保护解决方案将采用 HighwayHash 算法的 SIMD 加速实现。这将确保对象存储永远不会返回损坏的数据——它会动态捕获并修复损坏的对象。

通过在写入操作中计算哈希值，并在每次从应用程序、网络以及内存/驱动器读取操作时验证哈希值，确保端到端的完整性。实现方案应进行性能优化，并能够实现超过 10 GB/秒的哈希计算速度。

身份和访问管理

选择同时支持内部（包含所有功能）IAM 和外部 IAM 的对象存储。例如，OpenID Connect 和兼容 LDAP 的 IDP 提供商。通过创建此标准，开发人员和架构师可以集中访问，确保密码是临时的，并且令牌会轮换，而不是存储在配置文件和数据库中。

访问策略应该是细粒度的，并且在 API 级别粒度上高度可配置，这意味着支持多租户和多实例部署变得简单。

再次，这一要求将引导企业走向具有丰富集成网络的软件定义、云原生解决方案。

安全

选择对象存储时，请选择既支持 AWS 标准又支持其他复杂方案（包括针对对象存储本身进行优化的方案）的解决方案。这些加密方案应支持使用现代行业标准加密算法（例如 AES-256-GCM、ChaCha20-Poly1305 和 AES-CBC）进行细粒度的对象级加密。

从性能角度来看，加密应该能够在传输过程中和静止状态下应用，并尽量减少开销。任何选定的解决方案都应支持非 AWS 密钥管理服务，例如 Hashicorp Vault、Gemalto KeySecure 和 Google Secrets Manager。

主动复制

对象存储买家应该要求使用主动/主动复制 (Active Active Replication)。此功能对于关键任务生产环境至关重要，并在云运营模式下提供无与伦比的业务连续性。许多公共云提供商不允许跨云进行此类配置。

任何选定的解决方案都应支持同步和近同步复制，具体取决于架构选择和数据变化率、可用吞吐量和站点之间的延迟。

通过对象锁定进行数据保护

对象存储的数据保护始于不变性。根据定义，对象无法被更改（变异）。然而，这并不意味着它们无法被删除、覆盖、版本控制等。企业选择的任何对象存储都应支持全方位的功能，包括对象锁定、保留、合法持有、治理和合规性。

对象锁定与版本控制结合使用，以确保数据不变性，并消除数据篡改或破坏的风险。企业级对象存储应符合 FIPS 140 标准，并满足证券行业关于以不可重写和不可擦除的形式保存电子记录的要求，具体如下：

美国证券交易委员会 (SEC) 的 17 CFR § 240.17a-4(f)、金融业监管局 (FINRA) 规则 4511© 以及商品期货交易委员会 (CFTC) 的 17 CFR § 1.31©-(d)。

元数据架构

如上所述，对象存储领域中有两种处理元数据的方法。一种是与对象一起原子写入的元数据，另一种是存储在第三方数据库（通常是 Cassandra）中的元数据。

为了实现小对象的性能和可扩展性，对象存储应该以原子方式将元数据写入对象，并保证强一致性。这种方法可以将任何故障隔离在对象内部，并防止其蔓延到更大的系统故障。

由于每个对象都受到纠删码和比特腐散列的强力保护，即使在繁忙的工作负载中发生故障，也不会导致任何数据丢失。这种设计的另一个优势是严格的一致性，这对于分布式机器学习和大数据工作负载至关重要。

Lambda 函数支持

为了使对象存储能够将单个对象操作（例如访问、创建和删除）通知给无服务器应用程序，对象存储必须支持与 Amazon 兼容的 Lambda 事件通知。事件应使用行业标准的消息传递平台（例如 Kafka、NATS、AMQP、MQTT、Webhooks）或数据库（例如 Elasticsearch、Redis、Postgres 和 MySQL）进行传递。

并非所有情况都需要这样做，建筑师和开发人员应该考虑这一需求。

集成

在选择软件定义对象存储时，架构师和/或开发人员应寻求最广泛的集成组合。选择云原生对象存储是实现这一目标的一种方式。

这些集成将包括外部身份提供商、外部密钥管理、监控和警报、通知目标、联合、编排、负载均衡和备份目标。这包括与 Active Directory 和 LDAP（或任何兼容 OpenID (OIDC) 的提供商）的关键任务集成。

CLI 和图形用户界面

任何对象存储，尤其是软件定义的对象存储，都应支持 API 和命令行界面选项，以及强大的图形用户界面选项。这两种方案都应注重简洁性，同时确保功能齐全。

可扩展性

在对象存储领域，可扩展性是一个多维度的问题。虽然对象存储本身比其他方案（块+文件）更具可扩展性，但仍有一些因素需要考虑。

1、系统如何扩展。系统应该像超大规模系统那样，以离散的构建块进行扩展，同时要考虑故障域。系统还应该以支持异构硬件的方式进行扩展，这在硬件设备方法和软件定义方法中都是不可避免的事实。

2、规模化性能。性能可以从多个维度进行评估——原始性能、直线性能和规模化性能。区别很简单——为对象存储和几 TB 的数据运行基准测试可能会产生一些不错的结果，但真正的考验是，在各种访问模式和对象大小的多个 PB 数据上保持这种性能。

3、安全。这就是为什么安全也需要可扩展的原因。这意味着安全不能有性能开销，导致您无法始终运行它。可扩展加密还应该保护所有位置的数据——传输中（TLS 证书）和静态（KMS、加密）。安全还包括访问管理（身份验证和授权）和对象锁定。如果您想提供全面的保护，它们都必须可扩展。总而言之，这些都是大多数对象存储无法满足的艰巨要求。

4、运营规模。仅用少数人（甚至只需几个人就能跨时区管理）就能管理庞大的基础设施，这就是运营规模。随着时间的推移，运营成本 (OPEX) 比资本支出 (CAPEX) 高出几个数量级。扩展能力取决于所选的软件。简单而强大的软件最终会更胜一筹，因为运营可扩展性是软件问题，而非人员问题。

指标和日志记录

在跟踪任何系统的运行状况和性能时，指标和日志记录都至关重要。对象存储应提供对集群的完整可见性，并具备详细的存储性能监控、指标和每个操作的日志记录。

该对象理想情况下应支持与 Prometheus 兼容的指标端点。Prometheus 是一个云原生监控平台，由一个多维数据模型组成，该模型包含由指标名称和键/值对标识的时间序列数据，并输出到 Grafana。

在日志记录方面，对象存储应该为集群上的每个操作生成日志。每个操作都应生成一个包含唯一 ID 的审计日志，其中包含客户端、对象、存储桶以及所有其他操作相关元数据的详细信息。日志数据应写入已配置的 HTTP/HTTPS webhook 端点。应支持自定义适配器，以满足审计日志记录目标的特定需求。

数据生命周期管理和分层

对象存储应该支持跨介质、跨云平台，甚至在同一云的存储类别内进行数据分层。这些功能使企业能够优化性能和经济效益。

例如，为了最大限度地提高性能，“热”层中的数据存储在 NVMe 或 SSD 上，然后随着数据变冷，将其迁移到 HDD 上，以应对更大规模的工作负载或长期存储。或者，用户可以将高性能工作负载分层到私有云存储中，同时将较冷的数据迁移到成本更低的公有云基础设施。最后，对象存储应该能够确定是否应将数据迁移到公有云中的块存储或对象存储。

这里的底层要求是对象存储能够在多个云（公有云、私有云、边缘云）中无缝运行。为了实现此功能，对象存储必须是软件定义的。

概括

希望这篇文章的深度内容对您有所帮助。选择对象存储时，需要考虑许多关键因素。我们目前正在编写一份详细的文档，将这一思路融入到 RFP 中。完成后，我们会在 GitHub 上分享。