【Elasticsearch】如何设计可扩展的 Elasticsearch 数据存储的架构

怼烎@ 2022-08-30 11:46 158阅读 0赞

![在这里插入图片描述][d1c5aca34f19e6057b4b0f5d8cc3783b.png]

# 1.概述 #

转载：[如何设计可扩展的 Elasticsearch 数据存储的架构][Elasticsearch]

Elasticsearch 允许您存储、搜索和分析大量的结构化或非结构化数据。因为在速度、可扩展性和灵活性方面拥有优势，Elastic Stack 是适用于广泛用例的强大解决方案，这些用例包括系统可观测性、安全（威胁猎捕和预防）、企业搜索，等等。由于具有这种灵活性，因此有效地架构部署的数据存储以实现规模扩展至关重要。

现在，有一点毋庸置疑，每个 Elasticsearch 都有不同之处。您的用例/部署/业务情况对下面这些要素设定了一定的容许度或阈值：总拥有成本、采集性能、查询性能、备份的数量/规模、平均恢复时间等等。

因此，在开始考虑这些不同因素时，您可能需要考虑下列三个问题以帮助加快进行决策，否则您将需要完成一个复杂的决策矩阵：

*  您的用例/部署可以容许丢失多少数据？
 *  性能在您的业务目标中占比如何？
 *  您的项目可以应对多长的停机时间？

在本篇博文中，我们将会查看几种您可以采用的数据存储方案，然后讨论每种方案的利弊。看完本篇博文后，您将会对下面这一点有更加透彻的了解：如何对您自己（所特有）Elasticsearch 部署的数据存储进行架构，以实现扩展。

不想为这些事情费心？重大利好消息：欢迎采用 Elastic Cloud 上的 Elasticsearch Service，这样我们便会为您处理架构事务以让您实现扩展。

##  ##

## 方案概览 ##

通过下表，您可以快速了解一下使用 Elasticsearch 对数据存储进行架构时可选的方案，我们在本篇博文中会对这些方案进行解释。我们将会详细讲解各种方案的利弊，以及在数据丢失、性能和停机时间方面的预期表现。

<table> 
 <tbody> 
  <tr> 
   <td></td> 
   <td><a rel="nofollow">RAID 0</a></td> 
   <td><a rel="nofollow">RAID 1</a></td> 
   <td><a rel="nofollow">RAID 5</a></td> 
   <td><a rel="nofollow">RAID 6</a></td> 
   <td><a rel="nofollow">多数据路径</a></td> 
  </tr> 
  <tr> 
   <td>数据保护 </td> 
   <td>无 </td> 
   <td>1 个磁盘故障 </td> 
   <td>1 个磁盘故障 </td> 
   <td>2 个磁盘故障 </td> 
   <td>无 </td> 
  </tr> 
  <tr> 
   <td>性能* </td> 
   <td>NX </td> 
   <td>X/2 </td> 
   <td>(N - 1)X </td> 
   <td>(N - 2)X </td> 
   <td>1X 至 NX </td> 
  </tr> 
  <tr> 
   <td>容量 </td> 
   <td>100% </td> 
   <td>50% </td> 
   <td>67% - 94% </td> 
   <td>50% - 88% </td> 
   <td>100% </td> 
  </tr> 
  <tr> 
   <td>优势 </td> 
   <td> •&nbsp;设置简单<br><br> •&nbsp;性能出色<br><br> •&nbsp;容量高<br><br> •&nbsp;Elasticsearch 会将其看做单个磁盘 </td> 
   <td> •&nbsp;出色的数据保护功能<br><br> •&nbsp;轻松恢复<br><br> •&nbsp;Elasticsearch 会将其看做单个磁盘 </td> 
   <td> •&nbsp;中等的数据保护功能<br><br> •&nbsp;轻松恢复<br><br> •&nbsp;容量介于中高之间<br><br> •&nbsp;性能增益介于中高之间<br><br> •&nbsp;Elasticsearch 会将其看做单个磁盘 </td> 
   <td> •&nbsp;出色的数据保护功能<br><br> •&nbsp;轻松恢复<br><br> •&nbsp;容量介于中高之间<br><br> •&nbsp;性能增益介于中高之间<br><br> •&nbsp;Elasticsearch 会将其看做单个磁盘 </td> 
   <td> •&nbsp;设置简单<br><br> •&nbsp;添加磁盘<br><br> •&nbsp;容量高 </td> 
  </tr> 
  <tr> 
   <td>劣势 </td> 
   <td> •&nbsp;无容错功能<br><br> •&nbsp;恢复时间长<br><br> •&nbsp;如果没有副本分片，可能会发生永久性数据丢失 </td> 
   <td> •&nbsp;容量低<br><br> •&nbsp;写入时没有性能增益<br><br> •&nbsp;只能使用 2 个磁盘 </td> 
   <td> •&nbsp;有部分容量损失<br><br> •&nbsp;最多只有 1 个磁盘可以发生故障，否则阵列会发生故障<br><br> •&nbsp;恢复时间可能很长<br><br> •&nbsp;如有多于 1 个磁盘发生故障，仍有可能丢失数据<br><br> •&nbsp;恢复期间，阵列的性能会下降 </td> 
   <td> •&nbsp;容量损失介于低中之间<br><br> •&nbsp;恢复时间可能很长<br><br> •&nbsp;恢复期间，阵列的性能会下降 </td> 
   <td> •&nbsp;不会在路径间平衡分片<br><br> •&nbsp;单磁盘水位线会影响整个节点<br><br> •&nbsp;性能不一致<br><br> •&nbsp;磁盘不可互换<br><br> •&nbsp;添加磁盘会导致出现热点问题 </td> 
  </tr> 
 </tbody> 
</table>

\* N 表示卷中的磁盘数量。X 表示单个磁盘能够实现的读/写 IOPS 次数。数值越高，性能越好。

随着您开始研究如何对磁盘容量进行扩展，有数个不错的方案可供选择。我们了解一下其中的某些方法，并讨论一下各种方法的利弊。由于每种情况都有其独特性，所以并没有放之四海而皆准的方法。

### RAID 0 ###

几十年来，RAID 一直都是多磁盘组合方式的基石。RAID 有三个组成要素：镜像、分条和奇偶校验。RAID 中的每个数字都代表这些要素之间的独特组合。

数字 0 表示在 RAID 中进行分条。分条指的是将数据分成大块，然后将这些大块数据写入卷中的所有磁盘上。

#### 性能和容量 ####

由于所有磁盘能够并行写入，所以分条可以提高读/写性能。实际上，您的阵列中有几个磁盘，此种方法就能将读写速度提高几倍。所以如果您的 RAID 0 阵列中有 6 个磁盘，那么您的读写速度将会变为差不多 6 倍。

#### 恢复 ####

RAID 0 不提供恢复功能，因此 Elasticsearch 必须通过快照或副本来实现恢复功能。这一过程可能会非常耗时，具体取决于磁盘大小，以及将数据复制到阵列时所采用的传输机制。在恢复步骤期间，网络流量以及其他节点的性能会受到影响。

#### 注意之处 ####

由于 Elasticsearch 索引是由很多分片组成的，所以如果索引中有分片位于 RAID 0 卷上，并且该卷上有磁盘发生故障，那么这个索引也会遭到损坏（假设没有其他副本）。如果您未通过快照生命周期管理 (SLM) 来管理备份，或者如果您未将 Elasticsearch 设置为具有副本，那么这种情况将会导致永久数据丢失。

#### 利弊 ####

<table> 
 <tbody> 
  <tr> 
   <td>优势 (+) </td> 
   <td>劣势 (-) </td> 
  </tr> 
  <tr> 
   <td> 
    <ul> 
     <li>设置简单</li> 
     <li>性能出色，因为其能使用 100% 的磁盘可用读写速度</li> 
     <li>容量高，因为此阵列会使用全部磁盘容量进行存储</li> 
     <li>Elasticsearch 将阵列看做单个大磁盘。所以，水位线级别以及分片分布会按照预期运行。</li> 
    </ul></td> 
   <td> 
    <ul> 
     <li>如果某个磁盘发生故障，那么整个阵列中的全部数据都会丢失，而不只是损失单个磁盘。这可能会影响很多索引。</li> 
     <li>恢复时，集群需要将副本分片复制到新阵列中，这会耗费大量资源和时间。</li> 
     <li>如果没有副本分片，可能会发生永久性数据丢失</li> 
    </ul></td> 
  </tr> 
 </tbody> 
</table>

### 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。

#### 利弊 ####

<table> 
 <tbody> 
  <tr> 
   <td>优势 (+) </td> 
   <td>劣势 (-) </td> 
  </tr> 
  <tr> 
   <td> 
    <ul> 
     <li>出色的数据保护，因为所有数据均已镜像到另一个磁盘上。</li> 
     <li>一个磁盘发生故障时，可以很轻松地恢复；您只需替换发生故障的磁盘，然后数据便会复制到新磁盘上。</li> 
     <li>Elastic 将阵列视作单一磁盘。</li> 
    </ul></td> 
   <td> 
    <ul> 
     <li>容量低，因为 RAID 1 会使用 50% 的总磁盘容量来实现冗余。</li> 
     <li>相当于总体读/写性能降低 50%</li> 
     <li>除非采用 RAID 10，否则只能有 2 个磁盘</li> 
    </ul></td> 
  </tr> 
 </tbody> 
</table>

### 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 的性能，因为阵列需要使用奇偶检验来重新计算需从磁盘中读取的数据。

#### 利弊 ####

<table> 
 <tbody> 
  <tr> 
   <td>优势 (+) </td> 
   <td>劣势 (-) </td> 
  </tr> 
  <tr> 
   <td> 
    <ul> 
     <li>中等的数据保护功能。阵列会计算并重建单个故障磁盘中丢失的数据。</li> 
     <li>单个磁盘发生故障时，可以很轻松地恢复；您只需添加一个磁盘，然后数据便会重建。</li> 
     <li>容量介于中高之间。您只需损失一个（如为 RAID 5）或两个（如为 RAID 6）磁盘的存储空间以进行奇偶校验。</li> 
     <li>性能增益介于中高之间。您只需损失一个（如为 RAID 5）或两个（如为 RAID 6）磁盘的写入性能以进行奇偶校验。</li> 
     <li>Elastic 将阵列视作单一磁盘。</li> 
    </ul></td> 
   <td> 
    <ul> 
     <li>容量损失介于低中之间。</li> 
     <li>RAID 5 只能承受一个磁盘发生故障。RAID 6 只能承受两个磁盘发生故障。</li> 
     <li>恢复磁盘的用时可能超过 24 小时，具体取决于磁盘大小。</li> 
     <li>在恢复过程中，如果有另外一个（如为 RAID 5）或两个（如为 RAID 6）磁盘发生故障，则您面临着丢失全部数据的风险。</li> 
     <li>在恢复期间，阵列的读/写性能会降低。</li> 
    </ul></td> 
  </tr> 
 </tbody> 
</table>

### 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 节点配置中删除：

1.  禁用分片分配。
2.  停用节点。
3.  从 Elasticsearch 配置中删除存在故障的数据路径。
4.  重启节点。
5.  重新启用分片分配。

为防止造成永久性的数据丢失，请确保您将 Elasticsearch 配置为启用复制功能，默认项为每个分片一个副本。

Elasticsearch 然后会从其他节点重新平衡分片。Elasticsearch 不会在数据路径间平衡分片，请参见“注意之处”部分了解详细信息。如果集群上没有足够容量进行再平衡，则节点会保持黄色状态。

如要替换新磁盘，请小心卸下磁盘并停用所有 LVM 组。这可帮助确保 OS 能正确地处理新磁盘。新磁盘安装完毕之后，您将需要把路径添回至 Elasticsearch `path.data` 设置中。更换完存在错误的磁盘后，Elasticsearch 将会开始使用新路径。

#### 注意之处 ####

当多数据路径中所指定的某个设备发生故障时，下次分配分片时便会忽略该路径。然而，后续操作会再次将该路径视为可以向其分配分片。除非采取上面所述的步骤，否则这会导致出现 IOException 错误。

Elasticsearch 会按照各节点的具体情况处理水位线情况。这一点很重要，需要多加注意，因为如果某个数据路径达到高水位线，整个节点都会达到高水位线。即使其他数据路径仍有足够的可用空间，也会发生这种情况。这意味着达到高水位线的节点将会停止接受新分片，主动将分片移离节点，或者将节点变为只读状态。

举个例子，某个节点上有 6 个数据路径，每个数据路径为 500 GB，总容量约为 3 TB。有可能发生的一种情况是某个数据路径达到了 90% 的磁盘利用率。这会致使整个节点达到洪水级水位线，将整个节点变为只读状态。即使节点上其他磁盘的利用率还不足 50%，也会发生这种情况。

Elasticsearch 不会处理单一节点内的分片平衡问题，亦即不会平衡数据路径间的分片。所以，如果用户使用多数据路径的话，Elasticsearch 会将分片置于当时拥有最多可用空间的磁盘上。如果某个分片的数据比其他分片多，并致使达到高水位线，Elasticsearch 不会平衡分片。如果不知道这一问题，这可能会导致 IO 负载分配不均衡。此外，如果节点中的其他路径上已有数据，再向该节点上添加新磁盘的话，可能会导致新路径上的 IO 负载高。

#### 利弊 ####

<table> 
 <tbody> 
  <tr> 
   <td>优势 (+) </td> 
   <td>劣势 (-) </td> 
  </tr> 
  <tr> 
   <td> 
    <ul> 
     <li>设置简单</li> 
     <li>能够随时添加磁盘</li> 
     <li>磁盘利用率高</li> 
    </ul></td> 
   <td> 
    <ul> 
     <li>Elasticsearch 不会在数据路径间平衡分片</li> 
     <li>当单个数据存储库达到水位线时，整个节点都会受到影响</li> 
     <li>性能会受到限制，具体取决于数据在数据存储库之间的分布情况</li> 
     <li>不能更换磁盘</li> 
     <li>添加磁盘可能会导致磁盘过载</li> 
    </ul></td> 
  </tr> 
 </tbody> 
</table>

## 结论 ##

达到了需开始增加数据量的关键时间点，这一定让您倍感兴奋！尽管我们在本篇博文中探讨了很多方案，但您要谨记下面一点：在对数据存储进行架构以实现扩展时，并没有“放之四海而皆准”的解决方案。

如果就如何对 Elasticsearch 部署的存储进行架构以实现扩展仍有问题或疑虑，您可以加入我们的[论坛][Link 1]，我以及我们不断发展壮大的用户社区都十分乐意为您答疑解惑。

还有更好的消息呢！如果您不愿意亲自管理所有这些事情，我还要再重复一下前面提到的好消息：Elastic Cloud 能够帮您管理所有这一切。应对数据量增长就这么简单，再添个节点就能搞定。无需再使用服务器，省去了开箱、安装机架和管理的麻烦。而且，无论您现在使用（或将来可能使用）什么平台（Amazon Web Services、Google Cloud Platform 和 Microsoft Azure），它都能良好运行。何不今天就免费试用一下呢？

## Sign up for product updates! ##

MarketoFEForm

Submit

By submitting you agree to Elastic Terms of Service. Your personal data will be processed in accordance with Elastic's Privacy Statement.

[d1c5aca34f19e6057b4b0f5d8cc3783b.png]: /images/20220829/eb002a2a727d45e5817069196af6eaa1.png
[Elasticsearch]: https://www.elastic.co/cn/blog/how-to-design-your-elasticsearch-data-storage-architecture-for-scale
[Link 1]: https://discuss.elastic.co/