Elasticsearch学习笔记(7)

目录

Bootstrap Checks

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

这些引导检查检查各种Elasticsearch和系统的设置,并将它们与适合Elasticsearch操作的值进行比较。如果弹性搜索处于发展模式,任何失败的引导检查都会作为警告出现在Elasticsearch日志中。如果Elasticsearch处于生产模式,任何引导检查失败都会导致Elasticsearch拒绝启动。

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

开发模式 vs 生产模式

默认情况下,Elasticsearch绑定回路地址,用于HTTP和传输(内部)通信。对于下载,把玩,以及日常开发来说这是很好的,但是对于生产系统来说是没有用的。要加入一个集群,一个Elasticsearch节点必须能够通过传输通信到达。要通过非环回地址加入集群,节点必须将传输绑定到非环回地址,并且不能使用单节点发现。因此,如果一个Elasticsearch节点不能通过非环回地址与另一台机器形成集群,则认为该节点处于开发模式,如果它可以通过非环回地址加入集群,那么它就处于生产模式。

注意,HTTP和传输可以独立配置通过http.host和transport.host;对于将单个节点通过HTTP配置为可访问的,来达到测试目的而无需触发生产模式,这非常有用。

单节点发现

我们意识到一些用户需要将传输绑定到外部接口,以测试传输客户机的使用情况。对于这种情况,我们提供发现类型single-node (通过设置discovery.type为single-node来配置它);在这种情况下,节点将选择自己为主节点,而不会与任何其他节点连接集群。

强制引导检查

如果您在生产环境中运行单个节点,有可能逃避引导检查(要么不将传输绑定到外部接口,要么将传输绑定到外部接口并将发现类型设置为单节点)。对于这种情况,可以通过设置系统属性强制执行引导检查 es.enforce.bootstrap.checkstrue(在Setting JVM options中设置这个, 或者用过增加-Des.enforce.bootstrap.checks=true到环境变量ES_JAVA_OPTS)。如果您处于这种特殊情况,我们强烈鼓励您这样做。此系统属性可用于强制执行独立于节点配置的引导检查。

Heap size check

如果JVM以不相等的初始和最大堆大小启动,那么在系统使用期间,当JVM堆被调整大小时,它很容易暂停。为了避免这些调整大小暂停,最好启动JVM时初始堆大小等于最大堆大小。另外,如果bootstrap.memory_lock启用,JVM将在启动时锁定堆的初始大小。如果初始堆大小不等于最大堆大小,则在调整大小之后,不会将所有JVM堆锁定在内存中。要通过堆大小检查,必须配置heap size。

File descriptor check

文件描述符是用于跟踪打开的“文件”的Unix构造。在Unix中,everything is file。例如,“文件”可以是物理文件、虚拟文件(例如/proc/loadavg)或网络套接字。Elasticsearch需要大量的文件描述符(例如,每个碎片由多个段和其他文件组成,加上到其他节点的连接,等等)。这个引导检查是在OS X和Linux上强制执行的。要通过文件描述符检查,可能需要配置文件描述符。

Memory lock check

当JVM执行一次主要的垃圾收集时,它会触及堆的每个页面。如果这些页面中的任何一个被交换到磁盘,它们将不得不被交换回内存。这会导致大量磁盘抖动,而Elasticsearch更愿意使用这些磁盘抖动来服务请求。有几种方法可以配置系统来禁止交换。一种方法是请求JVM通过mlockall (Unix)或virtual lock (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/limited.conf使用nproc设置来实现(请注意,您可能还必须增加root用户的限制)。

最大文件大小检查

作为单个碎片组件的段文件和作为translog组件的translog生成可以变得很大(超过多个gb)。在系统上弹性搜索进程可以创建的文件的最大大小是有限定的,这会导致写操作失败。因此,这里最安全的选项是最大文件大小是无限的,这就是最大文件大小引导检查的作用。要通过最大文件检查,您必须配置您的系统,使Elasticsearch进程能够写入无限大小的文件。这可以通过修改/etc/security/limited.conf文件中fsize设置为unlimited(注意,您可能还需要增加root用户的限制)。

最大虚拟内存检查

Elasticsearch和Lucene使用mmap非常有效地将索引的部分映射到Elasticsearch地址空间。这使某些索引数据远离JVM堆,但保存在内存中,以便快速访问。为了有效,弹性搜索应该有无限的地址空间。最大大小的虚拟内存检查强制Elasticsearch进程具有无限的地址空间,并且仅在Linux上执行。要通过最大大小的虚拟内存检查,您必须配置您的系统,使Elasticsearch进程能够拥有无限的地址空间。这可以通过修改/etc/security/kimits.conf文件,将as设置为unlimited来实现(注意,您可能还需要增加root用户的限制)。

最大map数检查

从上一节继续,为了有效使用mmap,Elasticsearch还要求具有创建多个内存映射区域的能力。最大映射计数检查内核是否允许进程拥有至少262,144个内存映射区域,并且仅在Linux上强制执行。要通过最大映射计数检查,必须通过sysctlvm.max_map_count设置为至少262144。

或者,只有在使用mmapfs作为索引的存储类型时,才需要检查最大映射计数。如果不允许使用mmapfs,则不会强制执行此引导检查。

客户端JVM检查

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

使用串行搜集器检查

针对不同工作负载的openjdk派生jvm有各种垃圾收集器。串行收集器尤其适合于单个逻辑CPU机器或非常小的堆,它们都不适合运行Elasticsearch。使用带有弹性搜索的串行收集器会对性能造成很大的破坏。串行收集器检查确保Elasticsearch没有配置为与串行收集器一起运行。要通过串行收集器检查,您不能使用串行收集器启动Elasticsearch(无论是来自您正在使用的JVM的默认值,还是您已经用-XX:+UseSerialGC显式地指定了它)。请注意,随Elasticsearch附带的默认JVM配置将Elasticsearch配置为使用CMS收集器。

系统调用过滤器检查

Elasticsearch根据操作系统(例如Linux上的seccomp)安装各种风格的系统调用过滤器。安装这些系统调用过滤器是为了防止执行与分叉相关的系统调用的能力,分叉是一种防御机制,用于抵御对Elasticsearch上任意代码执行攻击。要通过系统调用筛选器检查,您必须修复系统上阻止系统调用筛选器安装的任何配置错误(检查日志),或者通过设置bootstrap.system_call_filterfalse禁用系统调用过滤器。

OnError和OnOutOfMemoryError检查

如果JVM遇到致命错误(OnError)或OutOfMemoryError (OnOutOfMemoryError),则JVM选项OnError和OnOutOfMemoryError允许执行任意命令。但是,在默认情况下,Elasticsearch系统调用过滤器(seccomp)是启用的,这些过滤器可以防止分叉。因此,使用OnError或OnOutOfMemoryError与系统调用筛选器是不兼容的。OnError和OnOutOfMemoryError检查防止在使用这两个JVM选项之一并启用系统调用筛选器时启动Elasticsearch。这种检查总是强制执行的。要通过此检查,请不要启用OnError或OnOutOfMemoryError;或者,升级到Java 8u92并使用JVM标志ExitOnOutOfMemoryError。虽然它不具备OnError或OnOutOfMemoryError的全部功能,但在启用seccomp的情况下,不支持任意分支。

抢险体验检查

OpenJDK项目提供了即将发布的版本的早期访问快照。这些版本不适合生产。早期访问检查检测这些早期访问快照。要通过这个检查,必须在JVM的发布版本上启动Elasticsearch。

G1GC检查

JDK 8附带的HotSpot JVM的早期版本已知在启用G1GC收集器时存在可能导致索引损坏的问题。受影响的版本是JDK 8u40附带的HotSpot版本之前的版本。G1GC检查检测HotSpot JVM的这些早期版本。

所有权限检查

所有权限检查确保在引导过程中使用的安全策略不会授予java.security.AllPermission给Elasticsearch。在授予所有权限的情况下运行等同于禁用安全管理器。

下一章 —— Elasticsearch学习笔记(8)

你可能感兴趣的:(Elasticsearch学习笔记(7))