软件定义的存储改变了我们存储数据的方式；随着功能的增加，在设计合适的解决方案时，需求也会增加。设计存储集群时，需要考虑大量的变量。
本章探讨了使用 GlusterFS 及其各种组件实现软件定义的存储解决方案的不同设计方面。
在本章中，我们将涵盖以下主题:
- GlusterFS 计算要求
- 使用合适的存储大小
- 定义性能需求
- 决定高可用性的正确方法
- 确定工作负载如何将一切联系在一起
在本章中，我们将使用以下网址上的 GlusterFS 文档:
与任何软件一样，GlusterFS 有一组由开发人员定义的要求，以确保它能按预期工作。文档中描述的实际要求相对较低，并且在过去 10 年中销售的几乎每台计算机都可以运行 GlusterFS。这可能不是最好的性能水平，但它仍然显示了能够在混合条件下运行的灵活性。
对于计算需求，我们在设计带有 GlusterFS 的解决方案时，主要需要考虑以下两个资源:
- 随机存取存储
- 中央处理器
有了内存，选择就相对简单了——尽可能多地使用。不幸的是，没有无限内存这种东西，但是使用尽可能多的说法再真实不过了，因为 GlusterFS 使用内存作为每个节点的读缓存，同时 Linux 内核使用内存作为预读缓存来加速对频繁访问的文件的读取。
根据所选的砖块布局和文件系统，可用内存在读取性能中起着重要作用。作为使用高级 ZFS 文件系统的砖块的例子，它使用内存作为其自适应替换缓存 ( ARC )。这在高速内存上增加了一层额外的缓存。缺点是它会消耗尽可能多的可用内存，所以选择一个提供大量内存的服务器会有很大帮助。
GlusterFS 不需要 1tb 的 RAM——每个节点拥有 32 GB 或更多的 RAM 可以确保缓存足够大，可以分配频繁访问的文件，如果通过向每个节点添加更多的砖块来增加集群的大小，则应该考虑添加更多的 RAM，以便增加缓存的可用内存。
请考虑以下情况:即使是像 DDR2 这样的旧内存技术，也可以在 GBps 提供吞吐量和几纳秒左右的延迟。另一方面，在大多数情况下，从常规旋转介质(硬盘驱动器)读取的吞吐量峰值为 150 MBps，延迟在几百毫秒内。
从缓存中读取总是比转到磁盘更快—等待磁盘移动其磁头，找到请求的数据块，然后将其发送回控制器和应用。
需要记住的一点是，缓存需要先预热；这是允许系统确定哪些文件正在被定期访问，然后将这些数据移动到缓存的过程。当它预热时，请求会变慢，因为它们首先必须从磁盘中取出。
任何软件都需要 CPU 周期，GlusterFS 也不例外。对 CPU 的要求比较低，这取决于所使用的卷的类型，例如，一个复制卷需要的 CPU 远远少于一个分散卷。
CPU 需求还受到砖块使用的文件系统类型和它们具有的功能的影响。回到 ZFS 的例子，如果启用压缩，这会增加 CPU 的负载，并且没有足够的 CPU 资源会大大降低性能。
对于一个简单的存储服务器，没有砖级的高级功能，任何具有四个或更多 CPU 的东西就足够了。启用文件系统功能(如压缩)时，需要八个或更多 CPU 才能获得最佳性能。此外，更多的中央处理器允许对集群进行更多的并发输入/输出。在为高性能计算 ( 高性能计算)应用设计存储集群时，这一点至关重要，在这些应用中，成千上万的用户同时执行输入/输出操作。
Use the following rules as general rules of thumb:
- 对于高并发工作负载，根据并发级别，选择更高的 CPU 数量，超过 8 个 CPU
- 对于低性能要求和经济高效的解决方案，选择较少数量的 CPU，例如四个 CPU
许多云提供商为其虚拟机大小提供了一组固定的给定资源，这些资源不允许自定义 vCPU 与 RAM 的比率。找到正确的平衡取决于哪个虚拟机大小提供了必要的资源。
云中 GlusterFS 的概念将在接下来的章节中进一步详细探讨。但是，要了解这个概念的概述，让我们使用微软的 Azure 产品来探索虚拟机的大小。
Azure 虚拟机系列从通用计算到特定工作负载(如 GPU)都有。对于 GlusterFS，我们非常喜欢针对存储工作负载进行优化的 L 系列虚拟机。该虚拟机系列具有良好的 vCPU 与 RAM 之比，并且提供了所有系列中最高的存储性能与成本之比。
这个总体思路可以应用于其他云供应商。应该选择一个虚拟机大小，它能提供出色且经济高效的虚拟机配置单元与内存的比率。
如果我们能使用我们需要的空间，那不是很好吗？现实中，存储是有成本的，无限存储是不存在的。
在确定可用存储规模时，必须考虑以下因素:
- GlusterFS 卷型
- 应用所需的空间
- 预计增长
让我们从一些技术考虑开始。每个 GlusterFS 卷在可用空间方面都有其特点。根据卷的类型，最终可用空间可能会比最初计算的要少。我们将探讨我们在第 2 章、定义 GlusterFS 存储中描述的每种卷类型的空间考虑。
这种音量类型相当简单。每个节点的可用空间总和是全局命名空间(GlusterFS 卷装载的另一个名称)上的总空间。
一个例子是 50 TB 容量的请求，其中砖块所需的空间量正好是 50 TB。这可以分为五个节点，每个节点 10 TB，或者两个节点，每个节点 25 TB。
对于复制副本卷，一半的可用原始块空间用于数据的镜像或复制。这意味着，在调整这种类型的卷时，您需要将请求的存储容量至少增加一倍。这取决于卷的具体配置。一般的经验法则是，可用容量是砖块上总空间的一半。
例如，如果请求的是 50 TB 的卷，则节点配置应该在两个节点(每个 50 TB)之间的砖状空间中至少有 100 TB 可用。
分散的卷在大小上更加棘手，因为它们的功能类似于 RAID 5，在 RAID 5 中，数据分布在节点上，节点的容量用于奇偶校验。这取决于卷的配置，但是您可以预期空间效率会随着节点数量的增加而增加。
为了进一步解释，可以在 6 个节点上配置 50 TB 的卷请求，每个节点 10 TB。请注意，考虑了一个额外的节点。选择五个 10 TB 的节点，每个节点的容量只有 40 TB，低于请求的大小。
每个应用都有自己的一组需求，存储需求和任何其他需求一样必要。
提供媒体文件比用户少、媒体文件少的网站需要更多的资源。准确了解存储系统的预期用途有助于正确确定解决方案的规模，并防止出现存储估计值低于一开始所需的情况。
确保您了解应用开发人员推荐的最低要求，并了解它如何与存储交互，因为这有助于避免令人头痛的问题。
作为建筑师，你的工作是问正确的问题。说到存储，请确保考虑到增长率或变化率。
考虑到无论发生什么情况，数据都会增长，提前思考可以避免空间不足的复杂情况，因此为未来的利用留出一些空间是一个很好的做法。留出 10%或更多的空间应该是一个很好的起点，因此，如果请求 50 TB 的空间，则向解决方案中增加 5 TB 的空间。
走最划算的路线。虽然 GlusterFS 允许无缝扩展，但请尽量避免将此功能用作简单的解决方案，并确保从一开始就定义了正确的大小，并为未来的增长考虑了缓冲区。
性能差的应用可能比根本不起作用的应用更糟糕。对任何企业来说，让一件事情在一半的时间里发挥作用都是令人难以置信的沮丧和昂贵。
作为一名架构师，您需要设计符合规范或更好的解决方案，以避免因性能不佳而出现问题的情况。
首先要定义什么是性能需求。大多数时候，应用开发人员会在他们的文档中提到性能需求。不满足这些最低要求意味着应用要么根本不工作，要么几乎不工作。两者都不可接受。
以下是设计面向性能的解决方案时需要注意的事项:
- 生产能力
- 潜伏
- 吞吐量
- 输入输出大小
吞吐量是一定时间内给定数据量的函数，通常用兆字节/秒 ( 兆位/秒来描述。这意味着每秒从存储系统发送或接收 X 个数据量。
根据工作负载，最高吞吐量可能是不可能的，因为应用无法执行足够大或足够快的输入/输出。这里没有硬数字推荐。尝试获得尽可能高的吞吐量，并确保存储集群能够维持所需并发级别所需的传输速率。
延迟至关重要，需要格外小心，因为一些应用对高延迟或响应时间非常敏感。
延迟是对完成输入/输出操作所需时间的度量，通常以毫秒为单位(1 秒等于 1000 毫秒)。高延迟或响应时间会导致应用需要更长时间才能响应，甚至完全停止工作。
争取尽可能低的延迟。在这种情况下，获得尽可能低的数字总是最好的方法。有了延迟，就不会有不够的问题，或者，在这种情况下，不会有太短的响应时间。考虑您使用的存储介质类型。传统硬盘驱动器的响应时间(或寻道时间)在几百毫秒范围内，而较新的固态驱动器可以超过亚毫秒标记并进入微秒。
每秒输入/输出操作数是给定操作数随时间变化的函数，在本例中为秒。这是一种衡量一秒钟可以完成多少操作的方法，许多应用都提供了关于 IOPS 的最低要求。
大多数应用都要求最低 IOPS 数，这样它才能按预期工作。请确保满足这些要求，否则应用可能无法正常运行。
在设计存储解决方案时，请确保在做出规模调整决策时，将 IOPS 考虑在内。
输入/输出大小是每个操作执行的数据量。这取决于工作负载类型，因为每个应用与存储系统的交互方式不同。输入/输出大小直接影响前面提到的性能方面。
较小的输入/输出会导致较低的吞吐量，但是，如果速度足够快，则会导致较高的 IOPS 和较低的延迟。另一方面，更大的输入/输出提供了更高的吞吐量，但通常会产生更低的 IOPS，因为在相同的时间内完成的操作更少。
关于输入/输出大小，没有可靠的建议。在一个理想的、非现实的世界中，输入/输出做得足够大和足够快，这导致了高吞吐量和高 IOPS。实际上，要么是这样，要么是那样。小的输入/输出最终在吞吐量方面会很慢，但完成得足够快，以至于 IOPS 看起来更高。使用大输入/输出时，数量会反转，吞吐量会变高，但由于需要更长时间才能完成，IOPS 就会下降。
在设计 GlusterFS 存储集群时，需要考虑以下方面的性能:
- 音量类型
- 砖块布局
- 节点数
- 调谐参数
所选的卷以不同的方式影响性能，因为 GlusterFS 为每种类型分配的数据不同。
例如，复制的卷跨节点镜像数据，而分散的卷试图最大化节点利用率并并行使用它们。
如果性能是分散或分布式卷的主要目标，请考虑分布式卷不提供冗余，而分散卷则以性能下降为代价。
将一个节点的所有磁盘放在一个大的块中，与将磁盘用几个块以较小的数量分组的方式不同。砖块布局是对性能贡献最大的因素，因为这直接决定了磁盘的使用方式。
如果所有磁盘最终都放在一块砖上，性能就会受到影响。通常，用更少的磁盘拥有更多的砖块会带来更好的性能和更低的延迟。
考虑为组成砖块的磁盘配置软件 RAID0。例如，您可以有 10 个可用磁盘，为了简单起见，在一块砖上配置一个 RAID0 中的所有 10 个磁盘。或者，您可以选择更高效的路线，配置五块砖，其中每个砖由一个 RAID0 中的两个磁盘组成。
这也允许更平滑的增长，因为用更少的磁盘添加更多的砖块比添加大量磁盘要容易得多。您应该将更多的砖块和更少的磁盘放在更小的 RAID 配置中。
在下图中，我们可以看到每个砖块是如何由两个不同的磁盘组成的:
增加集群中的节点数量可以实现更高的并发性。虽然性能提升可能不是线性的，但是添加节点允许更多的用户和应用访问卷。
目标是有足够的节点来平衡可用空间和并发性。这里没有固定的数字，但是作为架构师，您的工作是通过测试来定义特定解决方案的正确节点数。在概念验证阶段，使用较少数量的节点进行测试，并检查性能是否可以接受。
文件系统可调参数(如块大小)可以发挥重要作用，目标是将工作负载输入/输出大小、GlusterFS 卷块大小和文件系统块大小匹配到相同的数量。
通常，4 K 是最常用的块大小，适用于一般工作负载。对于大量小文件，请选择较小的块大小。对于大文件，目标是更大的块大小，例如 1 M
使用 GlusterFS，可以通过卷配置提供高可用性；如何实现取决于应用需求、可用空间和所需性能。
由于 GlusterFS 处理高可用性，因此不需要在块级配置任何形式的冗余。对于云实例和虚拟机来说尤其如此，因为它们没有可能损坏的物理磁盘。对于物理安装，最好通过配置 RAID5 或 RAID6 的本地磁盘来获得额外的冗余层，以实现性能和弹性的平衡。现在，让我们继续关注云部署。
使用 GlusterFS，只有两种卷类型提供高可用性:复制卷和分散卷。复制卷相当简单，因为数据只是从一个节点复制到另一个节点。它们的性能较低，但配置、部署和维护却容易得多。
当不需要极高性能时，选择复制卷。根据卷应该允许的节点或块的数量选择副本的数量。考虑使用更高的副本数量会减少可用空间量，但会增加卷的可用性。
以下示例显示，丢失复制卷中的节点不会中断卷操作:
分散的卷在高可用性和性能之间提供了良好的平衡；当两者都需要时，这应该是目标卷。配置分散的卷是一个更复杂的过程，因为冗余是在 RAID5 设置中处理的，其中一个节点用作奇偶校验。冗余值可以在卷创建时选择，这允许更大的灵活性。
在下图中，您可以看到丢失一个节点不会中断卷:
当有特定需求时，规划高可用性。请记住，音量类型可以混合和匹配。例如，分布式复制卷将具有可用空间和冗余的良好组合。
地理复制允许通过本地网络或互联网在不同站点之间异步复制数据。这通过将数据拷贝到不同的地理位置来提供高可用性，并确保在出现故障时进行灾难恢复。
当存在需要增加冗余层的特定使用情形时，考虑采用地理复制路线。请记住，这是异步复制，因此，在发生灾难的情况下，请考虑前面几章中解释的 RPO 和 RTO 时间。
下图让您大致了解了地理复制的工作原理— 站点 A 通过广域网复制到站点 B :
将视频文件传送到流式网络服务器不同于托管大型数据库。I/O 以完全不同的方式完成，准确了解工作负载与存储系统的交互方式对于成功确定规模和设计强健的存储解决方案至关重要。
在尝试了解存储需求时，应用文档是您最好的朋友。当存在应用的现有实现时，询问管理员软件对性能的期望，以及当它不满足最低要求时如何反应。
使用iostat等工具可以很好地理解应用如何与存储交互，例如，使用以下命令:
iostat -dxctm 1前面的代码显示了每块设备的使用情况，areq-sz列(以前称为avgrq-sz)显示了以千字节为单位的平均请求大小，这是理解应用通常使用的输入/输出大小的一个很好的起点。
输出类似于下面的截图:
在上图中，我们可以看到块设备及其各自的性能。
例如，为媒体流服务器设计存储解决方案需要使用大块大小，因为媒体文件往往比小文本文件大。如果对砖块使用更大的块大小，GlusterFS 卷不仅可以更有效地利用空间，还可以进行更快的操作，因为事务大小与文件大小相匹配。
另一方面，通常创建大量包含文本的小文件的传感器 Logstash 服务器需要较小的块大小来匹配正在创建的文件的大小。使用较小的块大小可以避免为一个只有 1 K 大小的文件分配整个块，比如 4 K。
作为架构师，您的目标是确保工作量非常明确。存储服务器的预期用途定义了需要分配多少资源。如果做不到这一点，可能会导致资源浪费，这反过来意味着金钱浪费，或者在最坏的情况下，可能会导致解决方案不符合规格，从而导致应用失败和用户无法工作。
记住从第 1 章、设计方法论介绍:问对问题。调整存储解决方案时，您可以问以下问题:
- 当前的实现占用了多少空间(如果已经有了)？
- 应用的性能要求是什么？
- 有多少用户与应用交互？
- 是否需要高可用性？
- 应用如何存储其数据？
- 它会创建大型文件并向其中追加数据吗？
- 它会产生大量的小文件吗？
这些问题的可能答案如下:
- 目前，该应用消耗 20 TB，但我们预计每月会增加 5%，并稳定在 80 TB。
- 该应用需要至少 100 MB/s 的吞吐量和不高于 10 ms 的延迟。
- 目前，约有 300 名用户可以访问该应用；同时，我们看到了 150 个用户的峰值，但我们预计用户数量将大幅增加。
- 我们可以忍受在一段时间内无法访问存储，但我们确实需要能够合理地快速从故障中恢复，并且可能在异地拥有一份数据拷贝。
- 该应用主要将其信息保存在小文件中。
- 它不追加数据，如果需要更多的空间，它只会创建更多的小文件。
- 是的，我们已经看到创建了几千个不超过 4 KB 的文件。
从前面的示例中，您可以推测应用创建了许多小文件，并且它可以容忍关闭一段时间，但需要异地复制以实现平稳的灾难恢复。性能要求似乎相对较高，因此我们可以选择启用地理复制的分散或分布式卷。
设计存储解决方案的过程需要知道许多变量。在本章中，我们定义了决定需要多少空间取决于 GlusterFS 卷类型、应用要求和数据利用率的估计增长。
根据卷的类型，可用空间会受到影响，分布式卷会聚合所有可用空间，使其成为空间效率最高的卷，而复制的卷会使用一半的可用原始空间进行镜像。
应用和用户基础决定了需要多少空间。这是因为，根据所服务的数据类型，存储要求会发生变化。提前考虑和规划存储增长可以避免资源耗尽的可能性，并且在规模调整适合大多数情况时，至少留出 10%的缓冲空间。
根据性能要求，我们定义了吞吐量、延迟、IOPS 和输入/输出大小的概念，以及它们之间的交互方式。我们定义了在配置 GlusterFS 以获得最佳性能时，哪些变量起作用，每个卷如何具有其性能特征，以及在尝试优化 GlusterFS 卷时，砖块布局如何发挥重要作用。
我们还定义了高可用性要求如何影响规模，以及每个卷如何提供不同级别的高可用性。当需要灾难恢复时，GlusterFS 地理复制通过将数据复制到另一个物理区域来增加所需的可用性级别，这允许在发生灾难时顺利恢复服务。
最后，我们介绍了工作负载如何定义解决方案的设计方式，以及如何使用工具来验证应用与存储的交互方式，从而实现存储集群的正确配置。我们还发现了文件类型和大小如何定义性能行为和空间利用率，以及问正确的问题如何更好地理解工作负载，从而产生更高效和优化的解决方案。
主要的要点是总是询问应用和工作负载如何与其资源交互。这允许最有效的设计。
在下一章中，我们将讨论 GlusterFS 所需的实际配置。
- GlusterFS 的计算要求是什么？
- GlusterFS 如何使用 RAM？
- 什么是缓存？
- 并发性如何影响 CPU 规模？
- GlusterFS 卷如何影响可用空间？
- 应用需要多少空间？
- 预计增长是多少？
- 吞吐量、延迟 IOPS 和输入/输出大小是多少？
- 什么是砖布局？
- 什么是地理复制？
- Anuj Kumar 设计数据密集型应用
- 微软 Azure 存储精粹由 Chukri Soueidi 提供
- 建筑师的蔚蓝作者:里提什·莫迪