본 포스팅은 2023년 01월 01일을 기준으로 작성되었습니다.
Full Cluster Restart : 모든 클러스터 재시작 (서비스 중단발생)
Cluster Re-index : 서비스 중단 없이 업그레이드 (이중클러스터 사용 시-Logstash 이용)
Rolling Upgrade: 서비스 중단 없이 업그레이드 (단일 클러스터에서 가능)
<노드 역할(role)에 따른 업그레이드 순서>
데이터 노드 → 마스터 후보 노드(master eligible node)가 아닌 모든 노드 → 마스터 후보 노드(master eligible node) → 마스터 노드
<데이터 노드에서 티어(tier)에 따른 업그레이드 순서>
Frozen → Cold → Warm → Hot
업그레이드 또는 재색인 전에 반드시 백업용 데이터(스냅샷) 생성 (엘라스틱서치 롤백 불가능)
사용 중지 로그 (deprecation log) 확인
주요 변경 사항 체크 및 점검 (https://www.elastic.co/guide/en/elasticsearch/reference/8.0/migrating-8.0.html)
사용자 정의 플러그인을 사용 중인 경우, 맞는 버전으로 호환성 체크
운영 클러스터 업그레이드 전에 개발/테스트 환경에서 업그레이드 테스트
도큐먼트 타입(Type) API 제거
- 6.7 버전부터 매핑에 타입 제거하고 사용가능
- 7.x에서 타입 API 호출시 사용 종료 경고 (deprecation warning) 발생
- include_type_name
Elastic Common Schema (ECS) 적용
- 색인되는 데이터에 대한 공통 매핑
- 다양한 데이터 소스 간의 통합 분석을 용이하게 함
- Beats & APM 7.0에 적용
- 기존 Ingest pipelines 및 Logstash filters에서 이상 발생 가능
- saved searches 및 visualizations의 업데이트 필요
RPM으로 설치
Rolling Upgrade
기존 7.X 버전의 클러스터는 모두 보안 설정이 되어있다고 가정합니다.
7.17 -> 8.12버전으로의 업그레이드 예시입니다.
백업 데이터 생성을 위해 Snapshot을 만듭니다. 노드 3대의 스냅샷을 공유하기 위해 nfs 서버를 생성합니다.
<NFS 설정 Process>
각 노드에 nfs-utils를 설치
sudo dnf install nfs-utils
1번 노드에서만 nfs-server를 실행
sudo systemctl start nfs-server.service
- 자동 실행 설정: systemctl enable nfs-server.service
- nfs 서버 파일 구성:
/etc/nfs.conf – NFS 데몬 및 도구의 기본 구성 파일
/etc/nfsmount.conf – NFS 마운트 구성 파일
3개 노드의 snapshot 공유 폴더로 활용할 폴더를 지정
예: /mnt/backup
1번 노드에 다른 노드들에 대한 접근 권한 추가
sudo vi /etc/exports
/mnt/backup {2번 노드 IP}(rw,sync,no_all_squash,root_squash) {3번 노드 IP}(rw,sync,no_all_squash,root_squash)
- rw : 읽기/쓰기 허용
- sync : 동기화, rw등의 작업 요청 시 nfc에 지시
- all_squash : 클라이언트 요청의 모든 UID 및 GID를 익명 사용자에게 매핑
- no_all_squash : 클라이언트 요청의 모든 UID 및 GID를 NFS 서버의 동일한 UID 및 GID에 매핑
- root_squash : 클라이언트의 루트 사용자 또는 UID/GID 0의 요청을 익명의 UID/GID로 매핑
1번 노드에서 위 exportfs 파일시스템 반출
sudo exportfs -arv
현재 내보낸 목록 표시: exportfs -s
NFS 서비스(mountd, nfs , rpc-bind) 방화벽 설정 (노드 3개 모두 설정)
sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=rpc-bind
sudo firewall-cmd --permanent --add-service=mountd
sudo firewall-cmd --reload
각각 노드에서 NFS 클라이언트 설정 설치
sudo dnf install nfs4-acl-tools
이제 노드 2,3번을 client로 설정하고, 1번 노드에 연결시킵니다.
2,3번 노드에서 1번 노드에 공유할 폴더 마운트
sudo mount -t nfs {1번 노드 IP주소}:/mnt/backup /mnt/backup
각 노드 마운트 되었는지 확인
sudo mount | grep nfs
시스템 재부팅 후에도 자동으로 마운트 되도록 설정 (모든 노드에서 수행)
sudo vi /etc/fstab
{각 노드 IP주소}:/mnt/backup /mnt/backup nfs defaults 0 0
클라이언트 측에서 원격 파일 시스템 마운트 해제 방법: umount /mnt/backup
Elaticsearch의 업그레이드 과정에서 예기치 못한 문제가 발생하거나 데이터가 손실될 경우를 대비하여 Snapshot을 통해 기존 데이터를 안전하게 백업해 둘 수 있습니다. 이를 통해 문제가 발생하거나 업그레이드 완료시 Snapshot에 저장된 데이터를 복원할 수 있습니다.
즉, Elasticsearch 클러스터 업그레이드 시 Snapshot을 만드는 것은 데이터 보호, 롤백 가능성 확보, 중요 데이터 보존 등을 위한 필수적인 백업 조치입니다. Snapshot이 있으면 예기치 못한 상황에서도 데이터 복구가 가능해집니다.
Snapshot 생성에 대한 절차는 Snapshot 가이드를 참고하시길 바랍니다.
샤드 할당 비활성화 (shard allocation)
롤링 업그레이드 시 종료시킨 노드의 샤드가 다른 노드로 복제 하기 위해 많은 I/O가 발생합니다. 그러나 바로 재시작 될 것이기 때문에 이런 I/O는 불필요합니다. 그러므로 데이터 노드를 종료하기 전에 샤드 복제 할당을 비활성화시킵니다.
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": none
}
}
플러시 수행 / 비필수 인덱스 중지
업그레이드 중에도 인덱싱을 계속 할 수 있지만, 비필수 인덱싱을 일시적으로 중지하고 플러시를 수행하면 샤드 복구 속도가 훨씬 빨라집니다.
POST /_flush
머신러닝 및 데이터 피드 작업 일시중지
업그레이드 동안 머신러닝 작업 수행이 가능하나 부하가 높아집니다. (종료되도 업그레이드 후 이어서 작업 가능)
# 머신러닝 전부 중지
POST _ml/set_upgrade_mode?enabled=false
# datafeed 전부 중지
POST _ml/datafeeds/_all/_stop
# 이상 징후 탐지 작업 전부 중지
POST _ml/anomaly_detectors/_all/_close
마스터 후보(master eligible)가 아닌 노드 업그레이드
마스터 후보(master eligible) 노드 업그레이드
마스터(master) 노드 업그레이드
Rolling Upgrade를 수행할 때는 cluster.initial_master_nodes를 설정하지 않은 상태를 유지합니다. (주석처리 유지) 또한, discovery.seed_hosts에 master node가 포함되어 있어야 합니다.
repo파일을 수정
sudo vi /etc/yum.repos.d/elasticsearch.repo 열고 8.x버전으로 수정합니다.
[elasticsearch]
name=Elasticsearch repository for 8.x packages
baseurl=https://artifacts.elastic.co/packages/8.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=0
autorefresh=1
type=rpm-md
elasticsearch 8.12.0 다운로드
rpm으로 설치 시 모든 파일은 운영 체제의 적절한 위치에 설치되므로 Elasticsearch 구성 파일을 덮어쓰지 않습니다. 설치 중 업그레이드 과정을 볼 수 있으며, elasticsearch.yml와 jvm.options가 .rpmnew을 붙인 백업 파일을 생성함을 확인 가능합니다.
sudo dnf install --enablerepo=elasticsearch elasticsearch-8.12.0
elasticsearch 실행
높은 버전의 노드는 낮은 버전의 클러스트에 붙을 수 있기에 문제 없이 연결됩니다.
업그레이드 후 노드 클러스터링 확인
GET _cat/nodes
샤드 재할당
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": all
}
}
클러스터 상태가 green인지 확인
GET _cat/health?v=true
샤드 복구 상태 확인
GET _cat/recovery
샤드 할당 비활성화
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": none
}
}
나머지 노드도 같은 과정을 반복합니다. 마지막 노드까지 업그레이드가 완료되면 클러스터도 8.12.0로 업그레이드 됩니다.
노드 상태 및 버전 확인
GET _cat/nodes?h=ip,name,version&v=true
노드 3개 모두 8.12.0임을 확인합니다.
샤드 재할당
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": all
}
}
ML 재시작
POST _ml/set_upgrade_mode?enabled=true
키바나 인스턴스를 종료
yum repo 수정
sudo vi /etc/yum.repos.d/kibana.repo 로 열고 8.x버전으로 수정
[kibana-8.x]
name=Kibana repository for 8.x packages
baseurl=https://artifacts.elastic.co/packages/8.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
Kibana 최신버전 다운로드
sudo dnf install kibana-8.12.0
(설치 중 업그레이드 과정을 볼 수 있으며, kibana.yml가 .rpmnew을 붙인 백업 파일을 생성함을 확인 가능)
Kibana 재시작
업그레이드 결과, elasticsearch와 kibana 모두 인증서, snapshot폴더, nfs서버 등의 모든 기존 설정이 유지되었음을 확인됩니다. 그러나 yml파일은 당장에는 수정 안해줘도 버전에 안맞아서 충돌되는 부분은 없으나, 추가적인 기능에 따라 직접 yml파일을 수정해줘야 합니다.
업그레이드 전 생성했던 snapshot 확인
GET _snapshot
GET _snapshot/backup/*?verbose=false
Snapshot 복원
POST /_snapshot/backup/backup_test/_restore
이미 해당 인덱스가 있기 때문에 오류가 발생할 수 있습니다. Delete and restore로 해결 가능할 수 있습니다.
Delete and restore 방식 복원: 기존 snapshot에 포함시킨 index들을 삭제시킵니다.
Snapshot 내 저장된 모든 indicies를 복구
POST /_snapshot/backup/backup_test/_restore
{
"indices": "*"
}