搭建 ElasticSearch 集群环境

发布时间:2023年12月20日

在这里插入图片描述

安装基础环境

我们用虚拟机创建出3台机器,查看centos版本为7.9

[root@s1 ~]# cat /etc/centos-release
CentOS Linux release 7.9.2009 (AltArch)

下载相关命令

yum -y install vim*
yum -y install net-tools
yum -y install lsof
yum -y install wget
yum -y install unzip

执行ifconfig命令获取ip地址

hostnameip
s1192.168.9.128
s2192.168.9.129
s3192.168.9.130

在3台服务器上配置host,添加如下内容
vim /etc/hosts

192.168.9.128 s1
192.168.9.129 s2
192.168.9.130 s3

我们配置一下server-1到server-2和server-3的ssh登陆

# 在3台机器执行如下命令
ssh-keygen -t rsa
# 查看server-1的公钥
cat ~/.ssh/id_rsa.pub
# 将server-1的公钥放到server-1,server-2和server-3的如下文件中
vim ~/.ssh/authorized_keys
# 在server-1执行如下命令能正常调转则说明成功
ssh root@s1
ssh root@s2
ssh root@s3

启动 es 不能使用 root 用户,所以创建一个其他用户

https://www.elastic.co/cn/downloads/past-releases/elasticsearch-8-1-0
注意要选对版本,不然 java 命令执行会报错

以下命令同时在 3 台服务器执行

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.1.0-linux-aarch64.tar.gz
# 创建数据文件目录
mkdir /opt/soft/elasticsearch-8.1.0/data
# 创建证书目录
mkdir /opt/soft/elasticsearch-8.1.0/config/certs
# 新增 es 用户
useradd es
# 修改文件拥有者
chown -R es:es /opt/soft/elasticsearch-8.1.0

生成安全证书

以下命令同时在 3 台服务器执行

# 切换用户
su es
cd /opt/soft/elasticsearch-8.1.0
# 签发 ca 证书,过程中需按两次回车键
bin/elasticsearch-certutil ca
# 用 ca 证书签发节点证书,过程中需按三次回车键
elasticsearch-certutil cert --ca elastic-stack-ca.p12
# 将生成的证书移动到 config/certs 目录中
mv elastic-stack-ca.p12 elastic-certificates.p12 config/certs

生成 http 证书

在第一台服务器节点设置集群多节点 http 证书

bin/elasticsearch-certutil http
[root@localhost elasticsearch-8.1.0]# bin/elasticsearch-certutil http

## Elasticsearch HTTP Certificate Utility

The 'http' command guides you through the process of generating certificates
for use on the HTTP (Rest) interface for Elasticsearch.

This tool will ask you a number of questions in order to generate the right
set of files for your needs.

## Do you wish to generate a Certificate Signing Request (CSR)?

A CSR is used when you want your certificate to be created by an existing
Certificate Authority (CA) that you do not control (that is, you don't have
access to the keys for that CA). 

If you are in a corporate environment with a central security team, then you
may have an existing Corporate CA that can generate your certificate for you.
Infrastructure within your organisation may already be configured to trust this
CA, so it may be easier for clients to connect to Elasticsearch if you use a
CSR and send that request to the team that controls your CA.

If you choose not to generate a CSR, this tool will generate a new certificate
for you. That certificate will be signed by a CA under your control. This is a
quick and easy way to secure your cluster with TLS, but you will need to
configure all your clients to trust that custom CA.

Generate a CSR? [y/N]n

## Do you have an existing Certificate Authority (CA) key-pair that you wish to use to sign your certificate?

If you have an existing CA certificate and key, then you can use that CA to
sign your new http certificate. This allows you to use the same CA across
multiple Elasticsearch clusters which can make it easier to configure clients,
and may be easier for you to manage.

If you do not have an existing CA, one will be generated for you.

Use an existing CA? [y/N]y

## What is the path to your CA?

Please enter the full pathname to the Certificate Authority that you wish to
use for signing your new http certificate. This can be in PKCS#12 (.p12), JKS
(.jks) or PEM (.crt, .key, .pem) format.
CA Path: certs/elastic-stack-ca.p12
Reading a PKCS12 keystore requires a password.
It is possible for the keystore's password to be blank,
in which case you can simply press <ENTER> at the prompt
Password for elastic-stack-ca.p12:

## How long should your certificates be valid?

Every certificate has an expiry date. When the expiry date is reached clients
will stop trusting your certificate and TLS connections will fail.

Best practice suggests that you should either:
(a) set this to a short duration (90 - 120 days) and have automatic processes
to generate a new certificate before the old one expires, or
(b) set it to a longer duration (3 - 5 years) and then perform a manual update
a few months before it expires.

You may enter the validity period in years (e.g. 3Y), months (e.g. 18M), or days (e.g. 90D)

For how long should your certificate be valid? [5y] 5y

## Do you wish to generate one certificate per node?

If you have multiple nodes in your cluster, then you may choose to generate a
separate certificate for each of these nodes. Each certificate will have its
own private key, and will be issued for a specific hostname or IP address.

Alternatively, you may wish to generate a single certificate that is valid
across all the hostnames or addresses in your cluster.

If all of your nodes will be accessed through a single domain
(e.g. node01.es.example.com, node02.es.example.com, etc) then you may find it
simpler to generate one certificate with a wildcard hostname (*.es.example.com)
and use that across all of your nodes.

However, if you do not have a common domain name, and you expect to add
additional nodes to your cluster in the future, then you should generate a
certificate per node so that you can more easily generate new certificates when
you provision new nodes.

Generate a certificate per node? [y/N]n

## Which hostnames will be used to connect to your nodes?

These hostnames will be added as "DNS" names in the "Subject Alternative Name"
(SAN) field in your certificate.

You should list every hostname and variant that people will use to connect to
your cluster over http.
Do not list IP addresses here, you will be asked to enter them later.

If you wish to use a wildcard certificate (for example *.es.example.com) you
can enter that here.

Enter all the hostnames that you need, one per line.
When you are done, press <ENTER> once more to move on to the next step.

s1
s2
s3

You entered the following hostnames.

 - s1
 - s2
 - s3

Is this correct [Y/n]y

## Which IP addresses will be used to connect to your nodes?

If your clients will ever connect to your nodes by numeric IP address, then you
can list these as valid IP "Subject Alternative Name" (SAN) fields in your
certificate.

If you do not have fixed IP addresses, or not wish to support direct IP access
to your cluster then you can just press <ENTER> to skip this step.

Enter all the IP addresses that you need, one per line.
When you are done, press <ENTER> once more to move on to the next step.

11.11.11.11
22.22.22.22
33.33.33.33

You entered the following IP addresses.

 - 11.11.11.11
 - 22.22.22.22
 - 33.33.33.33

Is this correct [Y/n]y

## Other certificate options

The generated certificate will have the following additional configuration
values. These values have been selected based on a combination of the
information you have provided above and secure defaults. You should not need to
change these values unless you have specific requirements.

Key Name: s1
Subject DN: CN=s1
Key Size: 2048

Do you wish to change any of these options? [y/N]n

## What password do you want for your private key(s)?

Your private key(s) will be stored in a PKCS#12 keystore file named "http.p12".
This type of keystore is always password protected, but it is possible to use a
blank password.

If you wish to use a blank password, simply press <enter> at the prompt below.
Provide a password for the "http.p12" file:  [<ENTER> for none]

## Where should we save the generated files?

A number of files will be generated including your private key(s),
public certificate(s), and sample configuration options for Elastic Stack products.

These files will be included in a single zip archive.

What filename should be used for the output zip file? [/opt/soft/elasticsearch-8.1.0/elasticsearch-ssl-http.zip] 

Zip file written to /opt/soft/elasticsearch-8.1.0/elasticsearch-ssl-http.zip
unzip elasticsearch-ssl-http.zip
mv elasticsearch/http.p12 kibana/elasticsearch-ca.pem config/certs

配置节点

配置第一个节点

elasticsearch.yml

cluster.name: es-cluster
node.name: node-1

path.data: /opt/soft/elasticsearch-8.1.0/data
path.logs: /opt/soft/elasticsearch-8.1.0/logs

network.host: s1
http.port: 9200

discovery.seed_hosts: ["s1"]


# 安全认证
xpack.security.enabled: true
xpack.security.enrollment.enabled: true

xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: /opt/soft/elasticsearch-8.1.0/config/certs/http.p12
xpack.security.http.ssl.truststore.path: /opt/soft/elasticsearch-8.1.0/config/certs/http.p12

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /opt/soft/elasticsearch-8.1.0/config/certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: /opt/soft/elasticsearch-8.1.0/config/certs/elastic-certificates.p12

# node-1 为上面配置的节点名称
cluster.initial_master_nodes: ["node-1"]

http.host: [_local_, _site_]
ingest.geoip.downloader.enabled: false
xpack.security.http.ssl.client_authentication: none
# 前台启动
bin/elasticsearch
# 后台启动
bin/elasticsearch -d

9300 端口为 es 集群组件的通信端口,9200 端口为浏览器访问的 http 协议的 restful 端口

启动报错

ERROR: [3] bootstrap checks failed. You must address the points described in the following [3] lines before starting Elasticsearch.
bootstrap check failure [1] of [3]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
bootstrap check failure [2] of [3]: max number of threads [2723] for user [es] is too low, increase to at least [4096]
bootstrap check failure [3] of [3]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

设置系统参数


配置其他节点,将 node.name 和 network.host 改成对应的值即可

node.name: node-2
network.host: s2

参考博客

创建虚拟机遇到的问题
[1]https://blog.csdn.net/qq_35448165/article/details/107631793
使用自带的 jdk
[2]https://www.cnblogs.com/TonyJia/p/16064064.html
[3]https://www.cnblogs.com/zhuhuibiao/p/16446105.html

文章来源:https://blog.csdn.net/zzti_erlie/article/details/135078307
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。