원문 링크

Elasticsearch 5.x 버전의 냉열 노드 구조

Elasticsearch가 대량의 실시간 데이터 분석 장면에 사용될 때, 우리는 시간 기반의 색인을 사용한 다음에 세 가지 서로 다른 유형의 노드(Master, Hot-Node와 Warm-Node)를 사용하여 구조 층을 나누는 것을 추천합니다. 이것이 바로 이른바'Hot-Warm'구조입니다.각 노드는 자신의 임무가 있으니 아래에서 소개할 것이다.

마스터 노드

우리는 모든 집단이 세 개의 전용 마스터 노드를 운행하여 가장 좋은 탄력을 제공할 것을 추천한다.사용할 때, 당신은 디스커버리를 더 필요로 합니다.zen.minimum_master_nodes setting 매개 변수는 뇌분열이 발생하지 않도록 2로 설정합니다.세 개의 전용 마스터 노드를 사용하여 집단의 관리를 처리하고 상태의 전체적인 안정성을 강화한다.이 세 개의 Master 노드는 데이터를 포함하지 않고 검색과 색인 작업에 실제로 참여하지 않기 때문에 JVM에서 같은 일을 하지 않아도 된다. 예를 들어 복잡한 색인이나 시간 소모, 자원 소모가 매우 큰 검색이다.이 때문에 쓰레기 수거로 인해 멈출 수는 없다.따라서 Master 노드의 CPU, 메모리 및 디스크 구성은 Data 노드보다 훨씬 적을 수 있습니다.

핫 노드

지정된 Data 노드는 클러스터 내의 모든 색인 작업을 완료합니다.이 노드들은 최근의 자주 검색되는 색인도 저장할 것이다.인덱싱을 수행하는 데 CPU와 IO가 많이 소요되므로 이러한 노드의 서버는 강력한 SSD 스토리지를 사용해야 합니다.우리는 고가용성을 보장하기 위해 최소화된 세 개의 핫 노드를 배치하는 것을 추천합니다.최근 수집 및 조회가 필요한 데이터량에 따라 서버 수를 늘려 원하는 성능을 얻을 수 있다.

Warm 노드

이런 유형의 노드는 대량이고 자주 방문하지 않는 읽기 전용 색인을 처리하기 위해 설계되었다.이러한 인덱스는 읽기 전용이기 때문에 Warm 노드는 SSD를 대체하기 위해 대량의 디스크 (일반 디스크) 를 마운트하는 경향이 있습니다.핫 노드와 마찬가지로 우리는 고가용성을 확보하기 위해 최소화된 세 개의 Warn 노드를 배치할 것을 건의합니다.그리고 이전과 마찬가지로 데이터량이 많으면 성능 요구에 도달하기 위해 추가 노드가 필요하다.그리고 주의해야 할 것은 CPU와 메모리 구성이 핫 노드와 일치한다는 것이다.유사한 생산 환경에서 비용이 많이 드는 조회를 통해 이 물건들을 확인할 수 있다.
Elasticsearch 집단은 어떤 서버에 Hot 노드가 있고 어떤 서버에 Warm 노드가 있는지 알아야 한다.이것은 필요한 속성을 서버에 분배함으로써 실현할 수 있다.
예를 들어, 당신은 엘라스틱 검색에 있을 수 있습니다.yml 이 프로필에서 node를 통과합니다.attr.box_type: hot는 노드를 hot로 설정하거나 노드를 시작할 때 사용할 수 있습니다./bin/elasticsearch -Enode.attr.box_type=hot 매개 변수를 지정합니다.
box_type 이 속성 필드는 당신이 원하는 대로 사용자 정의할 수 있습니다.이 사용자 정의 값은 Elasticsearch가 색인을 어디서 할당하는지 알려주는 데 사용됩니다.
다음 구성을 통해 색인을 만들면 SSD를 사용하는 핫 노드에 오늘의 색인이 있는지 확인할 수 있습니다.

PUT /logs_2016-12-26
{
  "settings": {
    "index.routing.allocation.require.box_type": "hot"
  }
}

며칠 후에 색인이 더 이상 성능이 좋은 하드웨어를 필요로 하지 않을 때, 우리는 이 노드들을 Warm 속성으로 표시하고, 색인 설정을 다음과 같이 업데이트할 수 있다.

PUT /logs_2016-12-26/_settings 
{ 
  "settings": { 
    "index.routing.allocation.require.box_type": "warm"
  } 
}

그러면 현재 우리는logstash나beats를 사용하여 실현할 수 있습니다. 만약에 색인 템플릿이logstash나beats에서 관리된다면, 색인 템플릿은 필터를 포함하여 업데이트를 해야 합니다."index.routing.allocation.require.box_type": "hot"이 설정은 새로운 인덱스를 핫 노드에 생성합니다.예:

{
  "template" : "indexname-*",
  "version" : 50001,
  "settings" : {
             "index.routing.allocation.require.box_type": "hot"
 ...

또 다른 정책은 그룹의 모든 인덱스에 일반 템플릿을 추가하는 것입니다. 핫 노드에 "template": "*"템플릿은 새로운 인덱스를 생성할 수 있습니다.예:

{
  "template" : "*",
  "version" : 50001,
  "settings" : {
           "index.routing.allocation.require.box_type": "hot"
 ...

쓰기 부담과 빈번한 검색이 필요하지 않은 것을 확인하면 Hot 노드에서 Warm 노드로 통합할 수 있습니다.이것은 색인 설정을 업데이트할 수 있습니다. "index.routing.allocation.require.box_type": "warm"을 통해 쉽게 할 수 있습니다.Elasticsearch는 자동으로 Warm 노드에 인덱스를 결합합니다.
마지막으로, 우리는 모든Warm 데이터 노드에서 더 좋은 압축 설정을 열 수 있습니다.elasticsearch.yml 프로필의 index.codec: best_compression의 이 설정 항목은 설정할 수 있습니다.데이터가 Warm 노드로 이동하면 _forcemerge API로 세그먼트 통합: 메모리, 디스크 공간, 더 적은 파일 핸들을 절약할 수 있지만 새로운 best_compression 인코딩이 색인 재작성으로 인한 부작용 
강한 상자에 할당해야 할 때 인덱스를 강제로 통합하는 것은 좋은 방법이 아닙니다. 이 노드의 프로세스는 I/O 작업을 우선적으로 하고 인덱스가 진행 중인 당일 로그에 영향을 줍니다.그러나mediumboxes는 조작이 많지 않기 때문에 안전합니다.인덱스의 분할 분배를 수동으로 수정하는 방법을 보았습니다. 다음은 Curator라는 도구를 사용하여 이 일을 자동으로 처리하는 방법을 보여 드리겠습니다.다음 예에서 우리는 curator 4.2를 사용하여 Hot 노드에서 3일 전의 인덱스를 Warm 노드로 이동합니다.

actions:
  1:
    action: allocation
    description: "Apply shard allocation filtering rules to the specified indices"
    options:
      key: box_type
      value: warm
      allocation_type: require
      wait_for_completion: true
      timeout_override:
      continue_if_exception: false
      disable_action: false
    filters:
    - filtertype: pattern
      kind: prefix
      value: logstash-
    - filtertype: age
      source: name
      direction: older
      timestring: '%Y.%m.%d'
      unit: days
      unit_count: 3

마지막으로 우리는 curator를 사용하여 색인을 강제로 합병할 수 있다.최적화를 실행하기 전에 색인 재분배에 충분한 시간을 기다려야 합니다.너는 조작 1중wait_를 설정할 수 있다for_completion, 또는 작업 2의 unit_ 수정count에서 4일 전의 색인을 선택하십시오.이렇게 하면 강제 합병 전에 완전히 합병할 기회가 있다.

2:
    action: forcemerge
    description: "Perform a forceMerge on selected indices to 'max_num_segments' per shard"
    options:
      max_num_segments: 1
      delay:
      timeout_override: 21600 
      continue_if_exception: false
      disable_action: false
    filters:
    - filtertype: pattern
      kind: prefix
      value: logstash-
    - filtertype: age
      source: name
      direction: older
      timestring: '%Y.%m.%d'
      unit: days
      unit_count: 3

주의timeout_override는 기본값 21600초보다 크지만, 설정에 따라 더 빠르거나 느릴 수 있습니다.Elasticsearch 5.0부터 우리는 Rollover와shrinkapi를 사용하여 분할 수량을 줄일 수 있으며, 더욱 간단하고 효율적인 방식으로 시간 기반 인덱스를 관리할 수 있다.너는 이 블로그에서 더 많은 세부 사항을 찾을 수 있다.