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

数据是驱动现代企业的货币。代表组织中不同利益相关方利用这些数据的能力，是现代、云原生、高性能且经济高效的系统的一个功能。强调这些现代化努力的核心是一个持续的主题——使企业能够更好地服务于他们的客户。

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

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

本指南从对象存储开始，包括其误区、与文件和块存储的比较、与云和 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 的数据量时达到上限。

块存储将文件分解成单个数据块，然后将这些块作为单独的数据存储。每个数据块都有不同的地址，因此它们不需要存储在文件结构中。因为块存储不依赖于单个数据路径，所以可以快速检索。它适用于执行大型交易的企业以及部署大型数据库的企业。块存储可能很昂贵，并且处理元数据的能力有限，这意味着需要在应用程序或数据库级别处理元数据。

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

1. 更强大的数据分析。对象存储由元数据驱动，并且每个数据片段都具有这种级别的分类，因此分析的机会要大得多。
2. 无限可扩展性。永远持续添加数据。没有限制。
3. 更快的 数据检索。由于对象存储的分类结构以及缺少文件夹层次结构，因此可以更快地检索数据。
4. 降低成本。由于对象存储的横向扩展特性，存储所有数据的成本更低。
5. 优化资源。因为对象存储没有文件层次结构，并且元数据是完全可定制的，所以与文件或块存储相比，限制要少得多。

对象存储和云

术语“云原生”在技术圈中被广泛使用，但没有特别明确的定义。困惑在于，“云原生”与应用程序部署的环境几乎无关——该术语同样适用于本地或公有云。相反，该术语指的是应用程序和架构特性。容器、服务网格、微服务、不变基础设施和声明式 API 体现了这种方法。

这些技术支持松耦合系统，这些系统具有弹性、可管理性和可观察性。结合强大的自动化，它们允许工程师频繁且可预测地进行高影响力更改，同时最大程度地减少工作量。

这对存储基础设施具有特殊意义。

现代应用程序架构基于 Amazon 开发的 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 集群上部署它，则必须遵守这些约束。根据定义，这意味着需要内核补丁或具有专用硬件的解决方案将不是云原生的。

尽管在某种程度上很简单，但在实践中，这两个声称“云原生”状态的标准实际上相当困难。公共云对象存储供应商在这方面做得相当好——实际上，考虑到 Google 是 Kubernetes 的来源，而 Amazon 是 S3 的来源，人们会期望他们这样做。私有云对象存储供应商在通过这些测试方面面临着更大的困难。

传统的 SAN/NAS 架构不适合云原生世界的需求，因此，您不会发现它们在大规模部署在公共云中。除了技术论点之外，部分原因是云提供商通过将文件价格定为对象存储的 13 倍，块存储为 4.6 倍来确保这一点，同时提供卓越的对象存储体验（快速、可靠、安全、RESTful）。

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

虽然此时对象存储的好处应该很清楚，但这些好处的全部只有那些选择软件定义的对象存储的企业才能获得。原因很简单

1. 软件定义是云的方式。您不能像使用设备一样在云中运行和跨云运行。
2. 您无法将设备容器化。对象存储的核心优势之一是其云原生特性。使用设备模型会放弃这一点。如果无法将存储容器化，Kubernetes 也会被排除在外。
3. 软件定义扩展了硬件范围。鉴于异构性是事物自然状态，并且您的对象存储需要从边缘运行到核心，这一点很重要。
4. 软件定义在容量和性能方面提供了更大的灵活性。您可以为 HDD 购买一个或多个设备，为 NVMe 购买另一个或多个设备，是的——但软件提供了更大的灵活性以及替代芯片组（英特尔、ARM、英伟达等）。

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

纯粹的解决方案

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

选择只做对象存储的供应商。这将确保它是同类最佳的。如果企业有文件和块存储需求，也应该在这些市场中寻找纯粹的解决方案。

AWS S3 兼容性

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

S3 API 是云中的事实标准，因此，AWS 的替代方案必须能够流利地使用 API 才能在各种环境中运行和互操作——公共云、私有云、数据中心、多云、混合云以及边缘。

最终的问题是相关应用程序是否可以使用标准 S3 调用在对象存储端点上工作。可以在选择之前确定这一点。

对于更通用、多用途的用例，请考虑供应商做出的声明的有效性。他们能进行测试吗？软件是否专有，从而限制通过 API 体验的用例、应用程序和硬件环境？

S3 Select

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

开发人员和架构师应该寻找 S3 Select API 的 SIMD 加速版本，该版本有效地实现了对象存储上的 SQL 查询功能。用户可以在其对象上执行 SELECT 查询，并检索对象的相关子集，而不是必须下载整个对象。使用 S3 Select API，应用程序现在可以下载对象的特定子集——仅满足给定 SELECT 查询的子集。

这直接转化为效率和性能，因为它减少了带宽需求，优化了计算和内存资源，这意味着可以使用相同的计算资源并行运行更多作业。随着作业更快地完成，分析师和领域专家的利用率也更高。此功能适用于 CSV、JSON 和 Parquet 格式的对象，并且对压缩对象也有效。

多云

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

无法从对象存储中获得多云功能将严重限制对象存储的占用空间、应用程序的可移植性和业务连续性目标。根据定义，只有软件定义的解决方案才能实现多云。

擦除编码

任何对象存储都应该使用每个对象的内联擦除编码来保护其数据。擦除编码应该用汇编代码编写，以提供尽可能高的性能。擦除码的最新技术是 Reed-Solomon，它将对象分成数据和奇偶校验块——尽管这些可以配置为任何所需的冗余级别。

这意味着在具有 6 个奇偶校验配置的 12 个驱动器设置中，一个对象被条带化成 6 个数据块和 6 个奇偶校验块。即使您丢失了多达 5 个 ((n/2)–1) 个驱动器，无论是奇偶校验还是数据，您仍然可以从剩余的驱动器可靠地重建数据。选择确保即使多个设备丢失或不可用，也可以读取对象或写入新对象的实现。

擦除码保护数据，而没有 RAID 配置或数据副本的限制。复制会在每个站点上生成对象的 3 个或更多副本。与复制相比，擦除码提供了更高的保护级别，同时仅占用一小部分存储空间。

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

BitRot 保护

选择保护免受 BitRot 的对象存储。

静默数据损坏或 bitrot 是驱动器的一个严重问题，会导致数据损坏，而用户却不知情。随着驱动器越来越大，数据需要持续保存多年，这个问题比我们想象的更常见。当磁性方向翻转并失去极性时，数据位会衰减。即使是固态硬盘也容易发生这种衰减，因为电子会因绝缘缺陷而泄漏。还有其他原因，例如磨损、电压尖峰、固件错误甚至宇宙射线。

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

从应用程序到网络再到内存/驱动器，通过在写入时计算哈希并在每次读取时进行验证来确保端到端的完整性。实现应该针对性能进行优化，并且应该能够实现超过 10 GB/秒的哈希速度。

身份和访问管理

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

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

同样，此要求将引导企业转向软件定义的云原生解决方案，这些解决方案拥有丰富的集成网络。

图 6：身份保护和单点登录 (SSO) 是关键的企业功能。

安全

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

加密应该能够在传输中和静止时应用，并且从性能角度来看开销最小。任何选定的解决方案都应包括对非 AWS 密钥管理服务（例如 Hashicorp Vault、Gemalto KeySecure 和 Google Secrets Manager）的支持。

图 7：加密和 WORM 保护传输中和静止状态下的数据。

主动-主动复制

对象存储购买者应该要求主动-主动复制。此功能对于关键生产环境非常重要，并在云运营模型中提供无与伦比的业务连续性。许多公共云提供商不允许跨云进行此类配置。

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

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

对象存储上的数据保护始于不变性。根据定义，对象无法更改（变异）。但是，这并不意味着它们不能被删除、覆盖、版本化等。企业选择的任何对象存储都应支持一系列完整的功能，包括对象锁定、保留、法律保留、治理和合规性。

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

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

元数据架构

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

为了实现小对象性能和可扩展性，对象存储应该与对象一起原子写入元数据，并保证强一致性。这种方法将任何故障限制在对象内，并防止溢出到更大的系统故障。

由于每个对象都通过擦除码和比特腐烂哈希进行了强保护，即使在繁忙的工作负载中间发生故障，也不会导致任何数据丢失。这种设计的另一个优点是严格一致性，这对于分布式机器学习和大数据工作负载非常重要。

Lambda 函数支持

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

这并非所有情况下都必需，架构师和开发人员应考虑其必要性。

集成

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

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

CLI 和图形用户界面

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

可扩展性

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

1. 系统如何扩展。系统应以离散的构建块进行扩展，就像超大规模厂商一样，同时牢记故障域。系统还应以支持异构硬件的方式进行扩展，这是硬件设备方法和软件定义方法中都存在的现实情况。
2. 大规模性能。性能可以从多个维度进行评估——原始的直线性能和扩展时的性能。区别很简单——对您的对象存储和几 TB 的数据运行基准测试可能会产生一些不错的数字，但真正的考验是在所有类型的访问模式和对象大小下，跨多个 PB 持续保持这种性能。
3. 安全。这就是为什么安全也需要扩展的原因。这意味着安全不能具有会阻止您始终运行它的性能开销。可扩展的加密也应该在任何地方保护数据——在传输中（TLS 证书）和在静止状态下（KMS、加密）。安全还包括访问管理（身份验证和授权）和对象锁定。如果您想提供全面的保护，它们都必须扩展。总而言之，这些都是大多数对象存储无法满足的巨大要求。
4. 运营规模。能够仅用少数（甚至只需一两个人跨时区管理）人员管理庞大的基础设施就是运营规模。从长远来看，运营支出比资本支出高出几个数量级。扩展能力是所选软件的功能。简单、强大的软件最终会更胜一筹，因为运营可扩展性是一个软件问题，而不是人员问题。

指标和日志记录

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

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

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

数据生命周期管理和分层

对象存储应支持跨媒体、跨云甚至在云的存储类别之间分层数据。这些功能允许企业优化性能和经济效益。

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

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

总结

希望本文的深度对您有所帮助。在选择对象存储时，需要考虑许多关键因素。我们目前正在编写一份详细的文档，将这种思路转化为 RFP。我们将在 GitHub 上共享它。

在此期间，请随时在您的选择过程中使用这些概念，或联系我们以进一步讨论任何主题。您可以通过下载试用产品，并在我们的 Slack 社区中获得帮助。要获取本文的 .pdf 版本，请点击此处。