纠删码计算器
参考硬件
软件定义对象存储购买者指南
数据是为现代企业提供动力的货币。代表组织的不同利益相关者利用该数据的能力是现代、云原生、高性能和具有成本效益的系统的功能。强调这些现代化努力的是一个持久的主题——使企业能够更好地为客户服务。
这个目标可能是单一的，但有很多途径。它可以是开发人员的敏捷性、CAPEX 节省、OPEX 节省、弹性或性能。所有这些路径都将与数据策略相交。
这篇文章概述了企业在评估软件定义存储时应考虑的因素。虽然一些组织将继续选择基于设备的解决方案，但这不是云原生方式，并且最终会限制用例的类型、部署场景和开发人员的吸引力。
该指南从对象存储、它的神话、它与文件和块的比较、它与云和 Kubernetes 的关系以及为什么软件定义很重要开始。
然后，它将注意力转向对象存储的关键选择标准，重点是软件定义的对象存储。
什么是对象存储
对象存储是一种数据存储类型，它将数据不可变地存储为不同的单元，称为对象。对象是存储在命名空间中的离散数据单元，命名空间可以是平面的，也可以包含“文件夹”或“桶”的概念，从而允许将它们作为组进行管理。每个对象都是一个简单、独立的存储库，其中包括数据、元数据（与对象关联的描述信息）和唯一的标识 ID 号。元数据可以用对象的内容自动写入，或者可以存储在对象的外部，并且为对象提供唯一标识符。此信息使应用程序能够定位和访问对象。
对象存储以其无限的规模而闻名。对象存储通过称为存储池的构建块进行扩展。池可以组合并分布在整个网络中——有效地无限。从弹性和灾难恢复的角度来看，这种分布式模型尤为重要。
与其他存储方法不同，对象存储中存储的数据不需要适应行和列。此类数据称为非结构化数据，占企业整体数据量的 80%。这可能包括范围广泛的数据，包括电子邮件、视频、照片、网页、音频文件、传感器数据和其他类型的媒体和网络内容（文本或非文本）。这也可能包括流数据和时间序列数据。
对象存储系统中的对象（数据）通过应用程序编程接口 (API) 访问，事实上的标准是 Amazon Web Service 的 S3。对象存储的原生 API 是基于 HTTP 的 RESTful API（也称为 RESTful Web 服务）。这些 API 查询对象的元数据，以通过 Internet 从任何地方在任何设备上定位所需的对象（数据）。正因为如此，对象存储天生就是分布式的，可以通过https调用。
考虑现代对象存储的另一种方式是将其视为与现代云数据库没有什么不同的键值存储。
对象存储的神话
现代对象存储与云原生运动之前开发的传统系统有很大不同。许多与对象存储相关的神话不再是真实的或相关的。这里有一些：
1.对象存储速度慢。现代对象存储非常高效。通常，可以预期它会在硬件的顶级范围内运行，并且经常会使该硬件饱和。对于将成为驱动器的 HDD。对于 NVMe，那将是网络。对于配置良好的 100 GBe NVMe 设置，对象存储在读取时可以超过 365 GiB/s，在写入时可以超过 145 GiB/s。
2. 对象存储用于归档工作负载。虽然对象存储更适合归档工作负载，但鉴于其可扩展性和性能特征，它非常适合 AI/ML、应用程序、分析甚至数据库工作负载。这在云中很明显，Snowflake、Redshift 和 BigQuery 等核心服务都在对象存储上运行。
3.对象存储不能处理小对象。正确架构的对象存储系统对于 KB 范围内的对象大小非常有效。这需要一种原子元数据方法。有关这方面的更多信息，请参阅所有关于小对象的帖子。
4. 对象存储不适合面向延迟的用例。虽然对象存储在吞吐量方面表现出色，但同样，正确架构的对象存储在 IOPS 驱动的工作负载上也非常有效。
对象存储与文件存储与块存储
现在我们了解了对象存储，它与文件和块相比如何？
文件存储将数据作为单个信息存储在文件夹中，以帮助将其与其他数据组织在一起。这也称为分层存储，模仿纸质文件的存储方式。当您需要访问数据时，您的计算机系统需要知道找到它的路径。文件管理器在 Internet 上的扩展性不是特别好，因此它们通常会在几个 PB 的数据上达到上限。
块存储将文件拆分为单个数据块，然后将这些块存储为单独的数据块。每条数据都有不同的地址，所以它们不需要存储在文件结构中。因为块存储不依赖于单一的数据路径，所以可以快速检索数据。它适用于执行大交易的企业和部署大型数据库的企业。块存储可能很昂贵并且处理元数据的能力有限，这意味着它需要在应用程序或数据库级别进行处理。
选择对象存储的企业可以获得以下好处：
更强大的数据分析。对象存储由元数据驱动，通过对每条数据进行这种级别的分类，分析的机会要大得多。
无限的可扩展性。永远不断地添加数据。没有限制。
更快的数据检索。由于对象存储的分类结构，并且没有文件夹层次结构，您可以更快地检索数据。
降低成本。由于对象存储的横向扩展特性，存储所有数据的成本更低。
优化资源。因为对象存储没有归档层次结构，而且元数据是完全可定制的，所以与文件或块存储相比，限制要少得多。
对象存储和云
“云原生”这个词在技术界被广泛使用，但并没有一个特别明确的定义。混淆之处在于，“云原生”与您的应用程序部署到的环境关系不大——该术语同样适用于内部部署或公共云。相反，该术语指的是应用程序和体系结构特征。容器、服务网格、微服务、不可变基础设施和声明式 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）。
软件定义对象存储的重要性
虽然此时对象存储的好处应该很清楚，但这些好处的全部只适用于那些选择软件定义的对象存储的企业。原因很简单：
软件定义是云的方式。您不能作为设备在云中运行。
您不能将设备容器化。对象存储的核心优势之一是其云原生性。你放弃了一个设备模型。如果您无法将存储容器化，Kubernetes 也不在考虑之列。
软件定义扩大了硬件的范围。这很重要，因为异构是事物的自然状态，而您的对象存储需要从边缘运行到核心。
软件定义在容量和性能方面提供了更大的灵活性。您可以为 HDD 购买一个设备，为 NVMe 购买另一个设备吗，是的，但是软件提供了更大的灵活性和替代芯片组（英特尔、ARM、Nvidia 等）。
软件定义对象存储的核心评估标准
纯播放解决方案
许多解决方案试图在单一品牌下提供块、文件和对象。从管理的角度来看，这似乎很有吸引力，但不可能成为一流的文件管理器、一流的块存储和一流的对象存储。它们需要不同的重点、架构和方法。
选择一个只做对象存储的供应商。它将确保它是一流的。如果企业有文件和数据块需求，他们也应该在这些市场中寻找纯粹的解决方案。
AWS S3 兼容性
S3 兼容性是云原生应用程序的硬性要求。选择同时支持 API V2 和 V4 版本的解决方案。类似于上面的纯游戏标准，寻找专门针对 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，它将对象条带化为数据和奇偶校验块——尽管这些可以配置为任何所需的冗余级别。
这意味着在具有 6 个奇偶校验配置的 12 个驱动器设置中，一个对象被条带化为 6 个数据和 6 个奇偶校验块。即使丢失多达 5 ((n/2)–1) 个驱动器，无论是奇偶校验还是数据，您仍然可以从其余驱动器可靠地重建数据。选择确保即使多个设备丢失或不可用也可以读取对象或写入新对象的实现。
纠删码保护数据不受 RAID 配置或数据副本的限制。复制会在每个站点上生成对象的 3 个或更多副本。与复制相比，纠删码提供更高级别的保护，同时只占用一小部分存储空间。
擦除编码应该在单个对象级别。这允许在对象级别粒度进行修复。对于受 RAID 保护的存储解决方案，修复是在 RAID 块层完成的，这会影响存储在卷上的每个文件的性能，直到修复完成。
BitRot 保护
选择防止 BitRot 的对象存储。
静默数据损坏或比特腐烂是驱动器的一个严重问题，会在用户不知情的情况下导致数据损坏。随着驱动器变得越来越大，数据需要保存很多年，这个问题比我们想象的更普遍。当磁方向翻转并失去极性时，数据位会衰减。当电子由于绝缘缺陷而泄漏时，即使是固态驱动器也容易出现这种衰减。还有其他原因，例如磨损、电压尖峰、固件错误甚至宇宙射线。
最先进的 BitRot 保护解决方案将采用 SIMD 加速实现 HighwayHash 算法。这将确保对象存储永远不会返回损坏的数据——它将即时捕获并修复损坏的对象。
通过在 WRITE 上计算散列并在每次从应用程序、跨网络到内存/驱动器的 READ 上验证它来确保端到端的完整性。实现应该是性能优化的，并且应该能够达到超过 10 GB/秒的散列速度。
身份和访问管理
选择支持内部（包括所有电池）IAM 和外部 IAM 的对象存储。示例包括 OpenID 连接和 LDAP 兼容的 IDP 提供商。通过创建此标准，开发人员和架构师可以集中访问，确保密码是临时的并且令牌是轮换的，而不是存储在配置文件和数据库中。
访问策略应该在 API 级别粒度上是细粒度和高度可配置的，这意味着支持多租户和多实例部署变得简单。
同样，这一要求将引导企业采用软件定义的云原生解决方案，其中存在丰富的集成网络。
图 6：身份保护和单点登录 (SSO) 是关键的企业功能。
安全
选择对象存储时，选择既支持 AWS 标准又支持其他复杂方案（包括针对对象存储本身优化的方案）的解决方案。这些加密方案应支持使用现代行业标准加密算法（例如 AES-256-GCM、ChaCha20-Poly1305 和 AES-CBC）的粒度对象级加密。
从性能的角度来看，加密应该能够以最小的开销在飞行中和静止时应用。任何选定的解决方案都应包括对非 AWS 密钥管理服务的支持，例如 Hashicorp Vault、Gemalto KeySecure 和 Google Secrets Manager。
图 7：加密和 WORM 保护动态和静态数据。
主动主动复制
对象存储购买者应该需要Active Active Replication。此功能对于任务关键型生产环境非常重要，并在云操作模型中提供无与伦比的业务连续性。许多公共云提供商不允许跨云进行此类配置。
任何选定的解决方案都应支持同步和近同步复制，具体取决于架构选择和数据变化率、可用吞吐量和站点之间的延迟。
通过对象锁定保护数据
对象存储上的数据保护始于不变性。根据定义，对象不能被改变（变异）。然而，这并不意味着它们不能被删除、覆盖、版本控制等。企业选择的任何对象存储都应该支持完整的功能范围，包括对象锁定、保留、合法保留、治理和合规性。
对象锁定与版本控制结合使用，以确保数据不变性并消除数据篡改或破坏的风险。企业级对象存储应符合 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、Webhooks）或数据库（如 Elasticsearch、Redis、Postgres 和 MySQL）来传递。
并非在所有情况下都需要这样做，架构师和开发人员应该考虑这种需要。
集成
在选择软件定义的对象存储时，架构师和/或开发人员应该寻求最广泛的集成组合。选择云原生对象存储是实现目标的一种方式。
这些集成将包括外部身份提供者、外部密钥管理、监控和警报、通知目标、联合、编排、负载平衡和备份目标。这包括与 Active Directory 和 LDAP（或任何 OpenID (OIDC) 兼容提供商）的关键任务集成。
CLI 和图形用户界面
任何对象存储，尤其是软件定义的对象存储，都应该支持 API 和命令行界面选项以及强大的图形用户界面选项。这两种选择都应该在确保功能齐全的同时简化操作。
可扩展性
可扩展性是对象存储世界中的一个多维问题。虽然本质上比其他方法（块 + 文件）更具可扩展性，但仍有一些因素需要考虑。
系统如何扩展。一个系统应该在离散的构建块中扩展，就像超扩展器一样，牢记故障域。系统还应该以支持异构硬件的方式进行扩展，这在硬件设备方法和软件定义方法中都是一个事实。
大规模的性能。可以从多个维度评估性能——原始、直线性能和大规模性能。区别很简单——为您的对象存储运行基准测试，几 TB 的数据可能会产生一些不错的数字，但真正的测试是在多个 PB 上针对各种访问模式和对象大小维持该性能。
安全的。这就是安全性也需要扩展的原因。这意味着安全性不会有性能开销来阻止您一直运行它。可扩展加密还应该在任何地方保护数据——传输中的（TLS 证书）和静态的（KMS，加密）。安全性还包括访问管理（身份验证和授权）和对象锁定。如果您想提供全面的保护，它们都必须扩展。这些都是大多数对象存储无法满足的巨大要求。
经营规模。只需少数人（甚至只需几个人来跨时区管理）即可管理大规模基础设施的能力是可操作的规模。随着时间的推移，OPEX 比 CAPEX 高出几个数量级。扩展能力取决于所选软件。简单、强大的软件最终会变得更好，因为操作的可扩展性是软件问题，而不是人的问题。
指标和日志记录
在跟踪任何系统的运行状况和性能时，指标和日志记录至关重要。对象存储应该提供对集群的完整可见性，包括详细的存储性能监控、指标和每个操作的日志记录。
理想情况下，该对象应支持与 Prometheus 兼容的指标端点。Prometheus 是一个云原生监控平台，由多维数据模型组成，时间序列数据由指标名称和键/值对识别并输出到 Grafana。
在日志记录方面，对象存储应该为集群上的每个操作生成一个日志。每个操作都应生成一个审计日志，其中包含唯一 ID 以及有关客户端、对象、存储桶和所有其他与操作相关的元数据的详细信息。日志数据应写入已配置的 HTTP/HTTPS webhook 端点。应支持自定义适配器以满足审计日志记录目标的特定要求。
数据生命周期管理和分层
对象存储应该能够跨媒体、跨云甚至在云的存储类中对数据进行分层。这些功能使企业能够优化性能和经济性。
例如，“热”层中的数据可以存储在 NVMe 或 SSD 上以最大限度地提高性能，然后在温度变冷时移动到 HDD 以处理更大规模的工作负载或长期存储。或者，用户可以在私有云存储中对高性能工作负载进行分层，同时将较冷的数据移动到成本较低的公共云基础设施。最后，对象存储应该能够确定是否应该将数据移动到公共云中的块存储或对象存储。
这里的基本要求是对象存储能够在多个云（公共云、私有云、边缘云）中无缝运行。要实现此功能，对象存储必须是软件定义的。
概括
希望这篇文章的深度对您有所帮助。选择对象存储时需要考虑许多关键因素。我们目前正在制定一份详细的文件，将把这种思路纳入 RFP。当我们这样做时，我们将在 GitHub 上分享它。
在此期间，请随时在您的选择过程中使用这些概念，或者联系我们就任何主题进行更多讨论。您始终可以通过下载试用该产品，并在我们的 Slack 社区中获得帮助。