引导检查
Last updated
Was this helpful?
Last updated
Was this helpful?
总的来说，由于用户尚未配置 ,因此他们在遇到意料之外的问题方面拥有丰富的经验 。在Elasticsearch的早期版本中，其中一些设置的错误配置被记录为警告。可以理解，用户有时会错过这些日志消息。为了确保这些设置得到应有的关注，Elasticsearch在启动时进行引导检查。
这些引导检查将检查各种Elasticsearch和系统设置，并将它们与对Elasticsearch的操作安全的值进行比较。如果Elasticsearch处于开发模式，则任何失败的引导检查都会在Elasticsearch日志中显示为警告。如果Elasticsearch处于生产模式，则任何失败的引导检查都会导致Elasticsearch拒绝启动。
总会强制执行一些引导检查，以防止Elasticsearch以不兼容的设置运行。这些检查是单独记录的。
默认情况下，Elasticsearch绑定到用于 和 通信的环回地址。对于下载和使用Elasticsearch以及日常开发来说，这是很好的选择，但对生产系统没有用。要加入集群，Elasticsearch节点必须可以通过传输通信到达。要通过非环回地址加入集群，节点必须将传输绑定到非环回地址，并且不能使用。因此，如果Elasticsearch节点无法通过非环回地址与另一台机器形成集群，则认为该节点处于开发模式，如果它可以通过非环回地址加入集群，则该节点处于生产模式。
注意，可以通过和单独配置HTTP和传输 。这对于将单个节点配置为可通过HTTP进行访问以进行测试（而不触发生产模式）很有用。
我们认识到某些用户需要将传输绑定到外部接口以测试其对传输客户端的使用。对于这种情况，我们提供发现类型single-node（通过设置discovery.type为来 配置single-node）；在这种情况下，节点将选举自己为主节点，并且不会与任何其他节点一起加入群集。
如果您在生产中运行单个节点，则可以逃避引导检查（通过不将传输绑定到外部接口，或通过将传输绑定到外部接口并将发现类型设置为 single-node）。对于这种情况，您可以通过将system属性设置es.enforce.bootstrap.checks为true （在设置此属性，或通过添加-Des.enforce.bootstrap.checks=true 到environment variable ES_JAVA_OPTS）来强制执行引导检查。如果您身处这种情况，我们强烈建议您这样做。该系统属性可用于强制执行独立于节点配置的引导检查。
如果以不同的初始堆大小和最大堆大小启动JVM，则在系统使用过程中调整JVM堆大小时，它很容易暂停。为了避免这些调整大小的停顿，最好以初始堆大小等于最大堆大小的方式启动JVM。此外，如果 启用，JVM将在启动时锁定堆的初始大小。如果初始堆大小不等于最大堆大小，则在调整大小之后，并非所有JVM堆都锁定在内存中。要通过堆大小检查，必须配置。
作为各个分片的组成部分的段文件以及作为translog记录的组成部分的translog记录可能会变得很大（超过数GB）。在Elasticsearch流程可以创建的文件的最大大小受到限制的系统上，这可能导致写入失败。因此，这里最安全的选择是最大文件大小不受限制，这就是最大文件大小引导检查强制执行的内容。要通过最大文件检查，您必须配置系统以使Elasticsearch进程能够写入无限大小的文件。这可以通过 /etc/security/limits.conf使用fsize设置来完成unlimited（请注意，您可能还必须增加root用户的限制）。
Elasticsearch和Lucene mmap很有用，可以将索引的某些部分映射到Elasticsearch地址空间中。这将某些索引数据保留在JVM堆之外，但保留在内存中，以实现快速访问。为了使此方法有效，Elasticsearch应该具有无限的地址空间。虚拟内存的最大大小检查要求Elasticsearch进程具有无限的地址空间，并且仅在Linux上强制执行。要通过最大大小的虚拟内存检查，您必须将系统配置为允许Elasticsearch进程具有无限的地址空间。可以通过添加到来<user> - as unlimited 完成/etc/security/limits.conf。这可能还需要您增加root用户的限制。
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来禁用系统调用过滤器。
如果JVM遇到致命错误（OnError）或 （OnOutOfMemoryError），则JVM选项OnError并OnOutOfMemoryError启用执行任意命令。但是，默认情况下，Elasticsearch系统调用过滤器（seccomp）已启用，并且这些过滤器可防止派生。因此，使用OnError 或者OnOutOfMemoryError 和系统调用筛选器是不兼容的。该OnError 和 OnOutOfMemoryError 检查防止Elasticsearch从如果这两个JVM选项的使用和系统调用过滤器可启动。始终执行此检查。在不开启OnError 或 OnOutOfMemoryError的情况下通过检查，通过升级到 Java 8u92 然后使用JVM flag ExitOnOutOfMemoryError.虽然这没有OnError还是OnOutOfMemoryError的完整功能,任意分支将不支持seccomp启用。
OpenJDK项目提供了即将发布的版本的早期访问快照。这些发行版不适合生产。抢先检查将检测到这些抢先快照。要通过此检查，您必须在JVM的发行版上启动Elasticsearch。
已知JDK 8附带的HotSpot JVM的早期版本存在一些问题，当启用G1GC收集器时，这些问题可能导致索引损坏。受影响的版本早于JDK 8u40随附的HotSpot版本。G1GC检查会检测到这些早期版本的HotSpot JVM。
所有权限检查可确保引导过程中使用的安全策略不会将权限授予java.security.AllPermissionElasticsearch。使用授予的所有权限运行等同于禁用安全管理器。
默认情况下，当Elasticsearch首次启动时，它将尝试发现在同一主机上运行的其他节点。如果在几秒钟内找不到任何选举出的主节点，则Elasticsearch将形成一个包含所有其他已发现节点的集群。无需在开发模式下进行任何额外配置就可以形成此群集很有用，但这不适用于生产，因为有可能形成多个群集并因此丢失数据。
此引导检查可确保发现未使用默认配置运行。可以通过设置以下至少一个属性来满足：
discovery.seed_hosts
discovery.seed_providers
cluster.initial_master_nodes
文件描述符是Unix构造用于跟踪打开的“文件”。但是在Unix中，。例如，“文件”可以是物理文件，虚拟文件（例如/proc/loadavg）或网络套接字。Elasticsearch需要大量文件描述符（例如，每个分片都由多个段和其他文件以及与其他节点的连接等组成）。此引导检查是在OS X和Linux上强制执行的。要通过文件描述符检查，您可能必须配置。
JVM执行主要垃圾回收时，它会触及堆的每个页面。如果将这些页面中的任何一个换出到磁盘，则必须将其换回内存。这导致大量磁盘崩溃，Elasticsearch宁愿使用它们来处理请求。有几种方法可以配置系统以禁止交换。一种方法是通过mlockall（Unix）或虚拟锁（Windows）请求JVM将堆锁定在内存中。这是通过Elasticsearch设置完成的 。但是，在某些情况下，可以将此设置传递给Elasticsearch，但Elasticsearch无法锁定堆（例如，如果elasticsearch 用户没有memlock unlimited）。该内存锁定检查验证，如果该bootstrap.memory_lock启用此设置，表明JVM已成功锁定了堆。要通过内存锁定检查，您可能必须配置。
Elasticsearch通过将请求分解为多个阶段并将这些阶段交给不同的线程池执行程序来执行请求。Elasticsearch中有各种任务的不同程序。因此，Elasticsearch需要具有创建大量线程的能力。检查最大线程数可确保Elasticsearch进程有权在正常使用下创建足够的线程。仅在Linux上强制执行此检查。如果您使用的是Linux，要通过最大线程数检查，必须将系统配置为允许Elasticsearch进程创建至少4096个线程。这可以通过/etc/security/limits.conf 使用nproc设置来完成（请注意，您可能还必须增加root用户的限制）。
从上一，为了有效地使用mmapElasticsearch还需要具有创建许多内存映射区域的能力。最大映射计数检查可检查内核是否允许进程至少具有262,144个内存映射区域，并且仅在Linux上强制执行。要通过最大地图计数检查，您必须将vm.max_map_countvia sysctl至少配置为262144。
或者，仅当您正在使用mmapfs或hybridfs作为索引的，才需要最大地图计数检查 。如果您使用，mmap则将不会执行此引导检查。