3.3. 存储资源

应用程序应该了解底层存储子系统来有效地使用云存储解决方案。如果原生可用的复制不可用，操作人员必须能够配置应用来提供复制服务。

可检测底层存储系统的应用程序可在各种基础架构中正常工作，无论底层基础架构的差异如何，仍然具有相同的基本行为。

input-output 性能的基准为预期的性能级别提供基准。基准结果数据有助于对不同负载下的行为建模，并帮助您设计合适的架构。

架构生命周期中较小的脚本基准有助于在不同时间记录系统健康状况。脚本基准中的数据可以帮助到范围，并深入了解组织需求。

设计对象存储资源池，以提供对象数据所需的可用性级别。考虑机架级和区域级设计，以适应必要副本数。副本数为三个。每个数据副本都应该存在于一个单独的可用区，带有独立电源、冷却和服务特定区域的网络资源。

OpenStack Object Storage 服务将特定数量的数据副本作为对象放在资源节点上。这些副本根据一致的散列环在集群中分发，该环存在于集群中的所有节点上。另外，对象存储代理服务器池提供对对象节点上存储的数据的访问应服务每个可用区。

设计对象存储系统具有足够数量的区，以便为副本数量提供最低所需的成功响应。例如，如果您在 Swift 集群中配置三个副本，建议在 Object Storage 集群中配置的区域数为五个。

虽然您可以使用较少的区域部署解决方案，但有些数据可能不可用，但对存储在集群中的某些对象的 API 请求可能会失败。因此，请确保考虑 Object Storage 集群中的区数量。

每个区域中的对象代理应利用本地的读取和写入关联性，以便本地存储资源能够尽可能地访问对象。您应该部署上游负载平衡，以确保代理服务分布到多个区域。在某些情况下，您可能需要第三方解决方案来协助服务地理分布。

Object Storage 集群中的区是一个逻辑划分，它由单个磁盘、节点、节点集合、节点集合组成。您必须在提供可用的和冗余存储系统的同时，允许 Object Storage 集群扩展。您可能需要为副本、保留和其他可能会影响特定区域中存储设计的其他因素配置存储策略。

在为 OpenStack Object Storage 设计硬件资源时，主要目标是最大化每个资源节点中的存储量，同时确保每个 terabyte 的成本保持最小。这通常涉及使用可以保存大量旋转磁盘的服务器。您可以使用带有附加存储的 2U 服务器表单因素，或使用包含大量驱动器的外部机箱。

OpenStack Object Storage 的一致性和分区容错特征可确保数据保持最新且存活的硬件故障，而无需特殊的数据复制设备。

OpenStack Object Storage 提供了在 swift 环内混合和匹配驱动器的功能。在设计 swift 存储集群时，您可以使用最经济的存储解决方案。

许多服务器机箱可以在 4U 机架空间中容纳 60 个或更多驱动器。因此，您可以把每个机架单元的存储量最大化为每 TB 的最佳成本。但是，不建议在对象存储节点中使用 RAID 控制器。

在设计存储解决方案时，您必须确定对象存储服务所需的最大分区功能，然后决定您可以创建的最大分区数。对象存储在整个存储集群中分发数据，但每个分区无法跨越多个磁盘。因此，分区的最大数量不能超过磁盘数量。

例如，具有初始单一磁盘和三个分区能力的系统可以容纳 8 (2³)分区。添加第二个磁盘意味着每个磁盘都可以包含四个分区。1-disk-per-partition 限制意味着此系统不能有超过 8 个磁盘并限制其可扩展性。但是，具有初始单一磁盘和 10 分区能力的系统最多可有 1024 (2¹⁰)分区。

每当您增加系统后端存储容量时，分区都会在存储节点上重新分发数据。在某些情况下，此复制由非常大的数据集组成。在这些情况下，您应该使用不与租户访问数据冲突的后端复制链接。

如果更多租户开始访问集群中的数据，且数据集增长，您必须添加前端带宽才能服务数据访问请求。为对象存储集群添加前端带宽需要设计对象存储代理，供租户用于获取数据的访问权限，以及启用代理层扩展的高可用性解决方案。

您应该设计一个前端负载平衡层，供租户和使用者用于获取集群中存储的数据的访问权限。这种负载平衡层可以在区域、地区甚至跨地理界限之间分发。

在某些情况下，您必须在代理服务器和存储节点之间服务请求的网络资源中添加带宽和容量。因此，提供对存储节点和代理服务器访问权限的网络架构应该可扩展。

应用程序每秒的 input-output (IOPS)要求决定是否应使用 RAID 控制器，以及需要哪个 RAID 级别。对于冗余，您应该使用冗余的 RAID 配置，如 RAID 5 或 RAID 6。一些特殊功能（如自动复制块存储卷）可能需要第三方插件或企业块存储解决方案来满足更高的需求。

在对块存储具有极端需求的环境中，您应该使用多个存储池。每个设备池应该在那个池中的所有硬件节点之间有类似的硬件设计和磁盘配置。此设计可让应用程序访问具有各种冗余、可用性和性能特性的各种块存储池。

网络架构也应考虑实例使用可用存储资源所需的东西带宽量。所选网络设备应该支持巨型帧来传输大量数据块。在某些情况下，您可能需要创建额外的专用后端存储网络，以提供实例和块存储资源之间的连接，以减少网络资源的负载。

在部署多个存储池时，您必须考虑对 Block Storage 调度程序的影响，该调度程序在资源节点之间置备存储。确保应用程序可以在带有特定网络、电源和冷却基础架构的多个区域调度卷。此设计允许租户构建在多个可用区间分布的容错应用程序。

除了块存储资源节点外，还务必要设计用于负责置备和提供对存储节点的访问的 API 和相关服务的高可用性和冗余。您应该设计了硬件或软件负载平衡器的一层，以实现 REST API 服务的高可用性，以提供不间断的服务。

在某些情况下，您可能需要部署额外的负载均衡层，以提供对负责服务和存储块存储卷状态的后端数据库服务的访问。您应该设计一种高可用性数据库解决方案，以存储块存储数据库，如 MariaDB 和 Galera。

块存储服务可以利用由硬件供应商开发的插件驱动程序，利用企业存储解决方案。大量企业插件随 OpenStack 块存储一起提供，其他插件则可通过第三方渠道获得。

常规用途云通常在大多数块存储节点上使用直接附加存储。因此，您可能需要向租户提供额外的服务级别。这些级别可能仅由企业存储解决方案提供。

您可以升级块存储池来添加存储容量，而不中断整个块存储服务。通过安装和配置适当的硬件和软件，将节点添加到池。然后，您可以将新节点配置为使用消息总线报告正确的存储池。

由于块存储节点将节点可用性报告给调度程序服务，所以当新节点上线并可用时，租户就可以立即使用新的存储资源。

在某些情况下，对来自实例的块存储的需求可能会耗尽可用的网络带宽。因此，您应该设计网络基础架构来服务块存储资源，以便您无缝添加容量和带宽。

这通常涉及动态路由协议或高级网络解决方案，来向下游设备添加容量。前端和后端存储网络设计应包括快速轻松地添加容量和带宽的能力。

节点硬件应该为云服务支持足够的存储，并且应确保部署后可以添加容量。硬件节点应支持大量成本成本的磁盘，且不受 RAID 控制器卡的依赖。

硬件节点还应能够支持高速存储解决方案和 RAID 控制器卡，以提供基于硬件的存储性能和冗余。选择自动修复损坏的阵列的硬件 RAID 控制器有助于替换降级或销毁存储设备。

可扩展性是存储解决方案的主要架构因素。扩展至 50 PB 的存储解决方案被视为比仅扩展至 10 PB 的解决方案进行扩展。此指标与可扩展性不同，即随着工作负载增加而解决方案的性能度量。

例如，开发平台云的存储架构可能不需要与商业产品云相同的可伸缩性和可扩展性。

Object Storage 资源节点不需要硬件容错或 RAID 控制器。您不需要规划对象存储硬件中的容错功能，因为对象存储服务默认在区域之间提供复制。

块存储节点、计算节点和云控制器在硬件级别带有硬件 RAID 控制器和不同级别的 RAID 配置应具有容错内置。RAID 的级别应与云的性能和可用性要求保持一致。

运行对象存储服务的磁盘不需要是快速性能的磁盘。因此，您可以最大化每 TB 的存储成本效率。但是，运行块存储服务的磁盘应使用性能提升功能，这些功能可能需要 SSD 或闪存存储来提供高性能块存储池。

应该考虑您用于实例的短期磁盘的存储性能。如果计算池需要高利用短期存储，或需要非常高性能，您应该部署类似硬件解决方案作为块存储部署。