[ELK Stack] Elasticsearch Cluster 구축 - 2. 구축

[업데이트 2016.12.09 10:28]

 

Node Instance를 실행 할 때, 하나의 Cluster안에서 동작하려면 각각의 Elasticsearch configuration 파일에 동일한 Cluster 이름을 명시해야 합니다.

 

cluster.name: big-data-cluster-1

  

Node별 다른 역할 부여를 위해 다음과 같이 설정 합니다. 또한 각 Node의 이름은 다르게 구별되어야 합니다.

 

# Master Node  node.name: node-1 node.master: true node.data: false node.ingest: false # Load Balancer Node node.name: node-2 node.master: false node.data: false node.ingest: false # Data Node node.name: node-3 node.master: false node.data: false node.ingest: false   # Master + Data Node node.name: node-4 node.master: true node.data: true node.ingest: false

 

 

* 참고: https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html

  

또한 각 Node별 아래와 같이 host IP address, HTTP port, TCP port, Node간 통신을 위한 unicast 설정, 최소 master node수를 설정합니다. 참고로 Node간에는 TCP Port를 통해 통신하기 때문에, HTTP port에 대해서는 disable을 하고 Load Balancer Node에 HTTP port만 enable하여 사용합니다. 불필요한 HTTP request를 차단하고 모든 HTTP request를 Load Balancer Node로 유입시키기 위함입니다.

 

아래의 경우는 Node1에 대한 설정입니다. (아래의 전체 서버 구조도 참조)

 

network.host: 192.168.0.1 http.port: 9200 transport.tcp.port: 9300 discovery.zen.ping.unicast.hosts: ["192.168.0.1:9300", "192.168.0.2:9301", "192.168.0.3:9302"] discovery.zen.minimum_master_nodes: 1

 

또한 여기서 중요한 것은 최소 master node수를 전체 Node수를 통해 지정하는 것입니다. 이것을 지정하는 이유는 각 master node간 통신에 장애가 발생하였을 때, 새로운 master node를 선택함에 있어서 문제가 발생 할 수 있습니다. 다시 말하면 Master Node가 속해 있는 Cluster를 관리하는데, 하나의 Cluster가 마치 두 개의 독립된 Cluster로 인식되어 data loss가 발생 할 수 있습니다. 따라서 아래의 내용처럼 split brain 현상을 막기 위해 아래와 같이 최소 master node수를 계산하여 설정합니다.

 

To avoid a split brain, this setting should be set to a quorum of master- eligible nodes:

(master_eligible_nodes / 2) + 1

In other words, if there are three master-eligible nodes, then minimum master nodes should be set to (3 / 2) + 1 or 2:

discovery.zen.minimum_master_nodes: 2

자세한 내용은 아래 링크 참조하시기 바랍니다.

 

* 참고: https://www.lastic.co/guide/en/elasticsearch/reference/current/important-settings.html

 

또한 JVM이 동작할 때 메모리가 부족할 때, 메모리 swap을 하면서 Performance가 저하될 수 있는데, 아예 처음부터 서비스가 시작할 때, Heap 메모리를 고정으로 할당하여 처리하게 할 수 있습니다. 메모리를 lock을 하기 위해 아래와 같이 설정합니다. 

 

bootstrap.memory_lock: true

 

서비스가 시작할 때, Heap 메모리를 강제로 할당하기 때문에, 실제 메모리가 부족하면 서비스가 실행이 안될 수 있습니다.

이럴 때에는 Elasticsearch 폴더 내에 있는 jvm.options파일을 열어, JVM Heap Size를 조정합니다. 보통 전체 메모리에 반정도를 설정합니다.

 

-Xms2g -Xmx2g

 

* 참고: https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html#bootstrap.memory_lock

* 참고: https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration-memory.html#mlockall

* 참고: https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html

 

또한 shard 및 replica 개수의 경우 _template을 이용하여 미리 설정할 수 있습니다. Logstash에서 index pattern이 logstash-*로 input filter가 동작할 때, 해당 template이 적용되어 index가 생성됩니다.

 

 

PUT _template/logstash {   "template": "logstash-*",   "settings": {       "number_of_shards": 3,       "number_of_replicas": 1   } }

 

 

 

* 참고: https://www.elastic.co/guide/en/elasticsearch/reference/5.1/indices-templates.html

 

이제 최종적으로 구축해본 서버에 대해 정리한 내용입니다. 아래 내용 참조 하시기 바랍니다.

 

- 서버 fail-over 처리 및 Search/Indexing Load 분산을 위해 서버 3대에 Master, Data, Load Balancer Node를 분산하여 관리.

 
- 서버 성능이 가장 우수한 서버에 Data Node, Logstash를 배치함.

- LB Node에만 HTTP 기능 enable함. 나머지는 내부적으로 서로 통신을 위한 TCP Transport만 enable함. 따라서 Kibana,Logstash 또는 REST API 사용을 위해서는 해당 LB Node가 실행중인 서버주소로 접속해야함.

- Node 간의 통신은 Unicast로 통신하여 broadcast로 인한 Network 부하를 줄임.

- VM이 메모리 swap하는 것을 방지 하기 위해, 고정된 Heap Memoy를 사용하도록 설정.

 
아래의 그림 및 표는 서버 PC 3대를 가지고 구성한 구성도입니다.

 

 

 

 

<GitHub>

https://github.com/asyncbridge/analytics/tree/master/ELK/ClusterSetting