Bootstrap 检查

最新推荐文章于 2024-10-04 10:08:05 发布

dismylife

最新推荐文章于 2024-10-04 10:08:05 发布

阅读量1.3k

点赞数

分类专栏： ElasticSearch 7.6 文章标签： elasticsearch 搜索引擎

原文链接：https://www.elastic.co/guide/en/elasticsearch/reference/7.6/bootstrap-checks.html

版权

ElasticSearch 7.6 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

OnError 和 OnOutOfMemoryError 检查

总的来说，很多人会遇到意外问题，因为他们没有配置重要的设置。在以前版本的 Elasticsearch 中，其中一些设置的错误配置被记录为警告。可以理解，用户有时会错过这些日志消息。为了确保这些设置得到应有的关注，Elasticsearch 在启动时进行了引导检查。

这些引导程序会检查各种 Elasticsearch 和系统设置，并将其与 Elasticsearch 操作安全的值进行比较。如果 Elasticsearch 处于开发模式，则任何失败的引导程序检查都会在 Elasticsearch 日志中显示为警告。如果 Elasticsearch 处于生产模式，任何失败的引导程序检查都会导致 Elasticsearch 拒绝启动。

有一些引导程序检查总是被强制执行，以防止 Elasticsearch 在不兼容的设置下运行。这些检查是单独记录的。

开发与生产模式

默认情况下，Elasticsearch 绑定到用于HTTP 和传输（内部）通信的环回地址。这对于下载和使用 Elasticsearch 以及日常开发来说都很好，但对于生产系统来说却毫无用处。要加入集群，必须可以通过传输通信访问 Elasticsearch 节点。要通过非环回地址加入集群，节点必须将传输绑定到非环回地址并且不使用单节点发现。因此，如果一个 Elasticsearch 节点不能通过非环回地址与另一台机器形成集群，我们认为它处于开发模式，否则如果它可以通过非环回地址加入集群，则认为它处于生产模式。

请注意，HTTP 和传输可以通过http.host和独立配置 transport.host；这对于将单个节点配置为可通过 HTTP 访问以进行测试而不触发生产模式很有用。

单节点发现

我们认识到一些用户需要将传输绑定到外部接口以测试他们对传输客户端的使用。对于这种情况，我们提供发现类型single-node（通过设置discovery.type为 single-node）；在这种情况下，一个节点将选举自己成为主节点，并且不会与任何其他节点一起加入集群。

强制引导程序检查

如果在生产中运行单个节点，则可以逃避引导程序检查（通过不将传输绑定到外部接口，或通过将传输绑定到外部接口并将发现类型设置为 single-node）。对于这种情况，可以通过将系统属性es.enforce.bootstrap.checks设置为true （在设置 JVM 选项中设置，或通过环境变量ES_JAVA_OPTS添加-Des.enforce.bootstrap.checks=true ）来强制执行引导程序检查。如果处于这种特定情况，我们强烈建议这样做。此系统属性可用于独立于节点配置强制执行引导程序检查。

堆大小检查

如果 JVM 以不相等的初始堆大小和最大堆大小启动，则在系统使用期间调整 JVM 堆大小时，它很容易出现暂停。为避免这些调整大小暂停，最好以初始堆大小等于最大堆大小的方式启动 JVM。此外，如果 bootstrap.memory_lock启用，JVM 将在启动时锁定堆的初始大小。如果初始堆大小不等于最大堆大小，则调整大小后不会出现所有 JVM 堆都锁定在内存中的情况。要通过堆大小检查，必须配置堆大小。

文件描述符检查

文件描述符是用于跟踪打开的“文件”的 Unix 构造。在 Unix 中，一切都是文件。例如，“文件”可以是物理文件、虚拟文件（例如，/proc/loadavg）或网络套接字。Elasticsearch 需要大量文件描述符（例如，每个分片由多个段和其他文件组成，以及与其他节点的连接等）。此引导程序检查在 OS X 和 Linux 上强制执行。要通过文件描述符检查，必须配置文件描述符。

内存锁检查

当 JVM 进行FULL GC时，它会接触堆的每一页。如果这些页中的任何一个被换出到磁盘，它们将不得不被换回内存，这会导致大量磁盘抖动，而 Elasticsearch 更愿意将其用于服务请求。有多种方法可以将系统配置为禁止swap。一种方法是请求JVM将堆锁定在内存中时通过mlockall（Unix）或虚拟锁（Windows）。这通过 Elasticsearch 设置bootstrap.memory_lock完成。在某些情况下，此设置可以传递给 Elasticsearch，但 Elasticsearch 无法锁定堆（例如，如果elasticsearch 用户没有memlock unlimited）。该内存锁定检查验证，如果该bootstrap.memory_lock设置已启用， JVM即能够成功锁定堆。要通过内存锁定检查，需要配置bootstrap.memory_lock.

最大线程数检查

Elasticsearch 通过将请求分解为多个阶段并将这些阶段交给不同的线程池执行程序来执行请求。Elasticsearch 中有针对各种任务的不同线程池执行器。因此，Elasticsearch 需要能够创建大量线程。最大线程数检查确保Elasticsearch进程在正常使用情况下有权创建足够多的线程。此检查仅在 Linux 上强制执行。如果在 Linux 上，要通过最大线程数检查，必须配置系统以允许 Elasticsearch 进程创建至少 4096 个线程的能力。通过/etc/security/limits.conf 使用nproc设置来完成（请注意，可能还必须增加root用户的限制）。

最大文件大小检查

作为单个分片组件的段文件和作为 translog 组件的 translog 生成可能会变得很大（超过数 GB）。 Elasticsearch 进程可以创建的文件的最大大小受到限制的系统上，这可能会导致写入失败。因此，这里最安全的选项是最大文件大小不受限制，这就是最大文件大小引导程序检查强制执行的内容。要通过最大文件检查，必须将系统配置为允许 Elasticsearch 进程写入无限大小的文件。可以通过 /etc/security/limits.conf使用fsize设置为unlimited来完成（请注意，可能还必须增加root用户的限制）。

最大虚拟内存检查

Elasticsearch 和 Lucene 用mmap将索引的部分映射到 Elasticsearch 地址空间中的效果很好。这将某些索引数据保留在 JVM 堆之外，但保留在内存中的部分可更快速的访问。为了使其有效，Elasticsearch 应该有不受限的地址空间。最大虚拟内存检查强制 Elasticsearch 进程具有不受限的地址空间，并且仅在 Linux 上强制执行。要通过最大虚拟内存检查，必须配置系统以允许 Elasticsearch 进程拥有无限地址空间的能力。需在/etc/security/limits.conf添加<user> - as unlimited . 这也可能需要同时增加root用户的限制。

最大map计数检查

继续上一点，为了mmap有效地使用，Elasticsearch 还需要能够创建许多内存映射区域。最大map计数检查检查内核是否允许进程具有至少 262,144 个内存映射区域，并且仅在 Linux 上强制执行。要通过最大map计数检查，必须通过sysctl将vm.max_map_count配置为至少262144.

仅当使用mmapfs或hybridfs作为索引的存储类型时才需要最大map计数检查。如果不允许使用mmap，则不会强制执行此引导程序检查。

客户端 JVM 检查

OpenJDK 派生的 JVM 提供了两种不同的 JVM：客户端 JVM 和服务器 JVM。这些 JVM 使用不同的编译器从 Java 字节码生成可执行的机器代码。客户端 JVM 针对启动时间和内存占用进行了调整，而服务器 JVM 则针对最大化性能进行了调整。两个 VM 之间的性能差异可能很大。客户端 JVM 检查确保 Elasticsearch 不在客户端 JVM 内运行。要通过客户端 JVM 检查，必须使用服务器 VM 启动 Elasticsearch。在现代系统和操作系统上，服务器 VM 是默认设置。

使用串行收集器检查

针对不同工作负载的 OpenJDK 派生 JVM 有各种垃圾收集器。串行收集器特别适合单逻辑 CPU 机器或极小的堆，但这两种机器都不适合运行 Elasticsearch。将串行收集器与 Elasticsearch 结合使用可能会对性能造成破坏性影响。串行收集器检查确保 Elasticsearch 未配置为与串行收集器一起运行。要通过串行收集器检查，不得使用串行收集器启动 Elasticsearch（无论它是来自正在使用的 JVM 的默认值，还是使用-XX:+UseSerialGC明确指定它）。请注意，Elasticsearch 附带的默认 JVM 配置将 Elasticsearch 配置为使用 CMS 收集器。

系统调用过滤器检查

Elasticsearch 会根据操作系统（例如 Linux 上的 seccomp）安装各种风格的系统调用过滤器。安装这些系统调用过滤器是为了防止执行与分叉相关的系统调用的能力，作为抵御对 Elasticsearch 的任意代码执行攻击的防御机制。系统调用过滤器检查确保如果启用了系统调用过滤器，则它们必须已成功安装。要通过系统调用过滤器检查，必须修复系统上阻止系统调用过滤器安装的任何配置错误（检查您的日志），或者自担风险通过设置bootstrap.system_call_filter为false来禁用系统调用过滤器。

OnError 和 OnOutOfMemoryError 检查

如果 JVM 遇到致命错误 ( OnError) 或 (OnOutOfMemoryError ) 时，通过JVM的OnError和OnOutOfMemoryError 选项启用执行任意命令。默认情况下，Elasticsearch 系统调用过滤器 (seccomp) 处于启用状态，这些过滤器可防止分叉。因此，OnError、OnOutOfMemoryError和系统调用过滤器是不兼容的。OnError和OnOutOfMemoryError检查防止Elasticsearch启动时JVM选项，此两项配置和系统调用过滤器的设置不冲突。次检查强制执行。要通过此检查，请不要启用 OnError或OnOutOfMemoryError；也可升级到 Java 8u92 使用 JVM 的ExitOnOutOfMemoryError标志。虽然这不具有OnError或OnOutOfMemoryError的全部功能，至少在启用 seccomp 时将不支持任意分叉。

Early-access检查

OpenJDK 项目提供了即将发布的版本的抢先体验快照。这些版本不适合生产。抢先体验检查检测这些抢先体验快照。要通过此检查，必须在 JVM 的发布版本上启动 Elasticsearch。

G1GC 检查

众所周知，JDK 8 附带的 HotSpot JVM 的早期版本存在一些问题，当启用 G1GC 收集器时，这些问题可能会导致索引损坏。受影响的版本早于 JDK 8u40 附带的 HotSpot 版本。G1GC 检查检测这些 HotSpot JVM 的早期版本。

所有权限检查

all 权限检查确保引导期间使用的安全策略不会授予Elasticsearch java.security.AllPermission权限。使用所有权限运行等效于禁用了安全管理器。

发现配置检查

默认情况下，当 Elasticsearch 首次启动时，它会尝试发现在同一主机上运行的其他节点。如果在几秒钟内没有发现任何选定的主节点，那么 Elasticsearch 将形成一个集群，其中包含发现的任何其他节点。在开发模式下无需任何额外配置即可形成此集群，但这不适用于生产，因为可能形成多个集群并因此丢失数据。

此引导程序检查可确保不使用默认配置运行。可以通过设置至少以下属性之一来通过此项检查：