工程

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

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

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

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

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

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

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

方案概览

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

RAID 0RAID 1RAID 5RAID 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 个磁盘发生故障,仍有可能丢失数据

• 恢复期间,阵列的性能会下降
• 容量损失介于低中之间

• 恢复时间可能很长

• 恢复期间,阵列的性能会下降
• 不会在路径间平衡分片

• 单磁盘水位线会影响整个节点

• 性能不一致

• 磁盘不可互换

• 添加磁盘会导致出现热点问题
* N 表示卷中的磁盘数量。X 表示单个磁盘能够实现的读/写 IOPS 次数。数值越高,性能越好。

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

RAID 0

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

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

性能和容量

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

恢复

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

注意之处

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

利弊

优势 (+) 劣势 (-)
  • 设置简单
  • 性能出色,因为其能使用 100% 的磁盘可用读写速度
  • 容量高,因为此阵列会使用全部磁盘容量进行存储
  • 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。

利弊

优势 (+) 劣势 (-)
  • 出色的数据保护,因为所有数据均已镜像到另一个磁盘上。
  • 一个磁盘发生故障时,可以很轻松地恢复;您只需替换发生故障的磁盘,然后数据便会复制到新磁盘上。
  • Elastic 将阵列视作单一磁盘。
  • 容量低,因为 RAID 1 会使用 50% 的总磁盘容量来实现冗余。
  • 相当于总体读/写性能降低 50%
  • 除非采用 RAID 10,否则只能有 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 的性能,因为阵列需要使用奇偶检验来重新计算需从磁盘中读取的数据。

利弊

优势 (+) 劣势 (-)
  • 中等的数据保护功能。阵列会计算并重建单个故障磁盘中丢失的数据。
  • 单个磁盘发生故障时,可以很轻松地恢复;您只需添加一个磁盘,然后数据便会重建。
  • 容量介于中高之间。您只需损失一个(如为 RAID 5)或两个(如为 RAID 6)磁盘的存储空间以进行奇偶校验。
  • 性能增益介于中高之间。您只需损失一个(如为 RAID 5)或两个(如为 RAID 6)磁盘的写入性能以进行奇偶校验。
  • Elastic 将阵列视作单一磁盘。
  • 容量损失介于低中之间。
  • RAID 5 只能承受一个磁盘发生故障。RAID 6 只能承受两个磁盘发生故障。
  • 恢复磁盘的用时可能超过 24 小时,具体取决于磁盘大小。
  • 在恢复过程中,如果有另外一个(如为 RAID 5)或两个(如为 RAID 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 节点配置中删除:

  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 负载高。

利弊

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

结论

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

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

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