如何设计可扩展的 Elasticsearch 数据存储的架构
Elasticsearch 允许您存储、搜索和分析大量的结构化或非结构化数据。因为在速度、可扩展性和灵活性方面拥有优势，Elastic Stack 是适用于广泛用例的强大解决方案，这些用例包括系统可观测性、安全（威胁猎捕和预防）、企业搜索，等等。由于具有这种灵活性，因此有效地架构部署的数据存储以实现规模扩展至关重要。
现在，有一点毋庸置疑，每个 Elasticsearch 都有不同之处。您的用例/部署/业务情况对下面这些要素设定了一定的容许度或阈值：总拥有成本、采集性能、查询性能、备份的数量/规模、平均恢复时间等等。
因此，在开始考虑这些不同因素时，您可能需要考虑下列三个问题以帮助加快进行决策，否则您将需要完成一个复杂的决策矩阵：
- 您的用例/部署可以容许丢失多少数据？
- 性能在您的业务目标中占比如何？
- 您的项目可以应对多长的停机时间？
在本篇博文中，我们将会查看几种您可以采用的数据存储方案，然后讨论每种方案的利弊。看完本篇博文后，您将会对下面这一点有更加透彻的了解：如何对您自己（所特有）Elasticsearch 部署的数据存储进行架构，以实现扩展。
不想为这些事情费心？重大利好消息：欢迎采用 Elastic Cloud 上的 Elasticsearch Service，这样我们便会为您处理架构事务以让您实现扩展。
方案概览
通过下表，您可以快速了解一下使用 Elasticsearch 对数据存储进行架构时可选的方案，我们在本篇博文中会对这些方案进行解释。我们将会详细讲解各种方案的利弊，以及在数据丢失、性能和停机时间方面的预期表现。
| RAID 0 | RAID 1 | RAID 5 | RAID 6 | 多数据路径 | |
| 数据保护 | 无 | 1 个磁盘故障 | 1 个磁盘故障 | 2 个磁盘故障 | 无 |
| 性能* | NX | X/2 | (N - 1)X | (N - 2)X | 1X 至 NX |
| 容量 | 100% | 50% | 67% - 94% | 50% - 88% | 100% |
| 优势 |
• 设置简单 • 性能出色 • 容量高 • Elasticsearch 会将其看做单个磁盘 |
• 出色的数据保护功能 • 轻松恢复 • Elasticsearch 会将其看做单个磁盘 |
• 中等的数据保护功能 • 轻松恢复 • 容量介于中高之间 • 性能增益介于中高之间 • Elasticsearch 会将其看做单个磁盘 |
• 出色的数据保护功能 • 轻松恢复 • 容量介于中高之间 • 性能增益介于中高之间 • Elasticsearch 会将其看做单个磁盘 |
• 设置简单 • 添加磁盘 • 容量高 |
| 劣势 |
• 无容错功能 • 恢复时间长 • 如果没有副本分片，可能会发生永久性数据丢失 |
• 容量低 • 写入时没有性能增益 • 只能使用 2 个磁盘 |
• 有部分容量损失 • 最多只有 1 个磁盘可以发生故障，否则阵列会发生故障 • 恢复时间可能很长 • 如有多于 1 个磁盘发生故障，仍有可能丢失数据 • 恢复期间，阵列的性能会下降 |
• 容量损失介于低中之间 • 恢复时间可能很长 • 恢复期间，阵列的性能会下降 |
• 不会在路径间平衡分片 • 单磁盘水位线会影响整个节点 • 性能不一致 • 磁盘不可互换 • 添加磁盘会导致出现热点问题 |
随着您开始研究如何对磁盘容量进行扩展，有数个不错的方案可供选择。我们了解一下其中的某些方法，并讨论一下各种方法的利弊。由于每种情况都有其独特性，所以并没有放之四海而皆准的方法。
RAID 0
几十年来，RAID 一直都是多磁盘组合方式的基石。RAID 有三个组成要素：镜像、分条和奇偶校验。RAID 中的每个数字都代表这些要素之间的独特组合。
数字 0 表示在 RAID 中进行分条。分条指的是将数据分成大块，然后将这些大块数据写入卷中的所有磁盘上。
性能和容量
由于所有磁盘能够并行写入，所以分条可以提高读/写性能。实际上，您的阵列中有几个磁盘，此种方法就能将读写速度提高几倍。所以如果您的 RAID 0 阵列中有 6 个磁盘，那么您的读写速度将会变为差不多 6 倍。
恢复
RAID 0 不提供恢复功能，因此 Elasticsearch 必须通过快照或副本来实现恢复功能。这一过程可能会非常耗时，具体取决于磁盘大小，以及将数据复制到阵列时所采用的传输机制。在恢复步骤期间，网络流量以及其他节点的性能会受到影响。
注意之处
由于 Elasticsearch 索引是由很多分片组成的，所以如果索引中有分片位于 RAID 0 卷上，并且该卷上有磁盘发生故障，那么这个索引也会遭到损坏（假设没有其他副本）。如果您未通过快照生命周期管理 (SLM) 来管理备份，或者如果您未将 Elasticsearch 设置为具有副本，那么这种情况将会导致永久数据丢失。
利弊
| 优势 (+) | 劣势 (-) |
|
|
RAID 1
性能和容量
镜像在 RAID 中用数字 1 表示。镜像指将相同数据写入其他磁盘的过程。这实际上会创建一个数据副本。尽管数据写入了两个磁盘，但在大部分 RAID 实施过程中，并不会读取两个磁盘。所以，读写性能实际上减半。由于相同的数据会同时写入两个磁盘，所以您会损失掉一半的容量。
恢复
RAID 1 仅设计用于两个磁盘的情况。所以如果一个磁盘发生故障，另一张磁盘上仍存有数据。这实现了高数据冗余，但是却需要牺牲性能和容量。当一个磁盘发生故障时，只需将其替换掉，然后数据便会复制到新磁盘上。
注意之处
由于 RAID 1 只支持两个磁盘，所以大多数情况下 RAID 1 会和 RAID 0 搭配使用。这意味着您需要将多个 RAID 1 卷与一个分条式 RAID 0 配合使用。这种方案称作 RAID 10，您有四个或更多磁盘时可以使用。
这意味着您既拥有 RAID 0 的部分性能优势，还拥有 RAID 1 的高冗余性。RAID 10 的性能取决于阵列中有多少个磁盘。RAID 10 的性能为 Nx/2。
利弊
| 优势 (+) | 劣势 (-) |
|
|
RAID 5 和 6
性能和容量
奇偶校验在 RAID 中会通过下面几个数字来表示：2、3、4、5、6。我们这里只关注 5 和 6，因为 2、3 和 4 已基本上被其他 RAID 取代。计算机可以通过奇偶校验这种方法来修复（或计算）因磁盘故障而丢失的数据。奇偶校验为分条操作提供了数据保护。然而，数据恢复功能也是有代价的。RAID 5 会使用一个磁盘的容量来实现奇偶校验，RAID 6 会使用两个磁盘的容量。
恢复
使用 RAID 5 和 6 时需要考虑的其他因素包括恢复过程的重建时间。向阵列中添加新磁盘来替换阵列中旧磁盘时，便会发生重建过程。对于旋转存储介质，需要添加更多磁盘，而非增加磁盘容量。添加磁盘会延长读/写时间以及重建时间。对于 SSD，您需要查看容量较高的磁盘是否读/写性能更快。很多较高容量的 SSD 磁盘能够实现更出色的读/写性能。如果是这种情况，那么较高容量的磁盘可帮助提高读/写性能。RAID 5 可以承受一个磁盘发生故障，如果更多磁盘发生故障，则阵列会丢失数据。RAID 6 可以承受两个磁盘发生故障。
注意之处
虽然 RAID 5 和 6 能够承受磁盘故障，但您也需要承担相应的后果。对 RAID 5 而言，这意味着在添加新磁盘之前您的阵列实际上和 RAID 0 一样脆弱。也就是，如果再有一个磁盘发生故障，阵列中的所有数据都会丢失，我们需要从其他分片或快照中进行恢复。有鉴于此，很多人都建议运行 RAID 6，因为磁盘组有可能同时发生故障。如开始时提到的那样，在这两种方法之间选择时，您要了解自己项目对性能和数据完整性的承受能力，这一点至关重要。
损失磁盘还会大幅影响 RAID 5 和 6 的性能，因为阵列需要使用奇偶检验来重新计算需从磁盘中读取的数据。
利弊
| 优势 (+) | 劣势 (-) |
|
|
Elasticsearch 中的多数据路径 (MDP)
Elasticsearch 有一个名为 path.data 的设置，该设置可用来为 Elasticsearch 数据文件配置文件系统位置。当为 path.data 指定一个列表后，Elasticsearch 将会使用多个位置来存储数据文件。举例说明，如果您的 elasticsearch.yml 包含下列内容：
path.data: [ /mnt/path1, /mnt/path2, /mnt/path3 ]
那么 Elasticsearch 会向多个文件系统位置写入。每个路径都可以是单独磁盘。
通过定义多个数据路径，用户能够将 Elasticsearch 设置为使用多个数据存储库。
性能和容量
Elasticsearch 会按分片对数据进行切分，而且分片会写入拥有最多可用空间的数据路径。如果某个分片接收到大部分的写入操作，那么您的性能将会受限于这个数据路径的速度。然而如果您的数据均衡地写入多个数据路径，那么您会获得所使用全部磁盘的写入速度。Elasticsearch 不能确保写入时会使用多个数据路径，所以性能可能有变化，造成不一致。
MDP 不包括数据的任何镜像或奇偶检验。这意味着可以使用磁盘的全部容量来存储数据，达到水位线（将会在利弊部分详细讲解）时除外。如要使用完整的磁盘容量，您的分片数量至少要与数据路径的数量相同。
如果某节点在其他路径中已存有数据，这时再向该节点上添加新的数据路径，将会导致新磁盘上出现热点问题。由于 Elasticsearch 不会在数据路径之间平衡分片，所以全部新分片都会发送到新路径上（因为该路径拥有最多可用空间）。因为 Elasticsearch 只有在启动时才会读取 elasticsearch.yml 中的更新，所以添加任何磁盘后，都需要重启整个节点。
恢复
磁盘会遇到问题。当多数据路径中的某个存储设备发生故障时，该节点会变为黄色，且位于该设备上的数据将无法访问。然而，Elasticsearch 仍会继续向发生故障的数据路径中写入数据，这将导致出现 IOExceptions 错误。为预防发生这种情况，很重要的一点是按照下列步骤将存在问题的数据路径从 Elasticsearch 节点配置中删除：
- 禁用分片分配。
- 停用节点。
- 从 Elasticsearch 配置中删除存在故障的数据路径。
- 重启节点。
- 重新启用分片分配。
为防止造成永久性的数据丢失，请确保您将 Elasticsearch 配置为启用复制功能，默认项为每个分片一个副本。
Elasticsearch 然后会从其他节点重新平衡分片。Elasticsearch 不会在数据路径间平衡分片，请参见“注意之处”部分了解详细信息。如果集群上没有足够容量进行再平衡，则节点会保持黄色状态。
如要替换新磁盘，请小心卸下磁盘并停用所有 LVM 组。这可帮助确保 OS 能正确地处理新磁盘。新磁盘安装完毕之后，您将需要把路径添回至 Elasticsearch path.data 设置中。更换完存在错误的磁盘后，Elasticsearch 将会开始使用新路径。
注意之处
当多数据路径中所指定的某个设备发生故障时，下次分配分片时便会忽略该路径。然而，后续操作会再次将该路径视为可以向其分配分片。除非采取上面所述的步骤，否则这会导致出现 IOException 错误。
Elasticsearch 会按照各节点的具体情况处理水位线情况。这一点很重要，需要多加注意，因为如果某个数据路径达到高水位线，整个节点都会达到高水位线。即使其他数据路径仍有足够的可用空间，也会发生这种情况。这意味着达到高水位线的节点将会停止接受新分片，主动将分片移离节点，或者将节点变为只读状态。
举个例子，某个节点上有 6 个数据路径，每个数据路径为 500 GB，总容量约为 3 TB。有可能发生的一种情况是某个数据路径达到了 90% 的磁盘利用率。这会致使整个节点达到洪水级水位线，将整个节点变为只读状态。即使节点上其他磁盘的利用率还不足 50%，也会发生这种情况。
Elasticsearch 不会处理单一节点内的分片平衡问题，亦即不会平衡数据路径间的分片。所以，如果用户使用多数据路径的话，Elasticsearch 会将分片置于当时拥有最多可用空间的磁盘上。如果某个分片的数据比其他分片多，并致使达到高水位线，Elasticsearch 不会平衡分片。如果不知道这一问题，这可能会导致 IO 负载分配不均衡。此外，如果节点中的其他路径上已有数据，再向该节点上添加新磁盘的话，可能会导致新路径上的 IO 负载高。
利弊
| 优势 (+) | 劣势 (-) |
|
|
结论
达到了需开始增加数据量的关键时间点，这一定让您倍感兴奋！尽管我们在本篇博文中探讨了很多方案，但您要谨记下面一点：在对数据存储进行架构以实现扩展时，并没有“放之四海而皆准”的解决方案。
如果就如何对 Elasticsearch 部署的存储进行架构以实现扩展仍有问题或疑虑，您可以加入我们的论坛，我以及我们不断发展壮大的用户社区都十分乐意为您答疑解惑。
还有更好的消息呢！如果您不愿意亲自管理所有这些事情，我还要再重复一下前面提到的好消息：Elastic Cloud 能够帮您管理所有这一切。应对数据量增长就这么简单，再添个节点就能搞定。无需再使用服务器，省去了开箱、安装机架和管理的麻烦。而且，无论您现在使用（或将来可能使用）什么平台（Amazon Web Services、Google Cloud Platform 和 Microsoft Azure），它都能良好运行。何不今天就免费试用一下呢？