일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- slack
- LDAP
- airflow
- python
- docker
- Example DAG
- MapReduce
- SlackWebhookOperator
- 빅데이터
- NoSQL
- Lambda architecture
- HDP
- Kafka
- Windows
- Scala
- 람다 아키텍처
- Namenode
- HIVE
- ambari
- java
- HDFS
- re
- HBase
- hadoop
- execution_date
- jupyter
- slack app
- 정규표현식
- yarn
- Service
- Today
- Total
IT 삽질기
Hadoop namenode.FSEditLog Error 본문
문제 발생
최근 운영중인 클러스터에서 너무 잦은 NameNode(NN) 전환 작업이 일어났다
기존에는 약 2주에 한번씩 전환되던 NN의 전환이 하루에 한번 정도씩 반복되었는데 이를 해결한 과정이다
먼저 문제가 발생한 NN의 log를 살펴보았다
log를 확인한 결과 NN이 종료되기 전 JournalNode로 edit 내용을 쓰는 과정에서 timeout이 걸려 NN이 중단되는 것으로 보였다.
정상적으로 edit 내용을 전달하는 경우의 log는 아래와 같다
warn은 발생하지만 20000ms(20초)를 넘지 않는 경우에는 error이 발생하지 않고 NN이 내려가지 않았다
원인 파악
1. 네트워크 문제
2. 서버 노후화와 부하 증가로 인한 문제
1. 네트워크 문제에 대한 부분은 데이터의 양이 많아지고 많은 요청으로 인한 일시적인 문제일 수도 있다 라는 생각이였다. 그러나 해당 문제가 부하가 많은 시점에만 발생하지 않았다는 점과 즉각적인 대응이 어려워 다른 방향을 먼저 생각해보기로 했다
2. 서버 노후화와 부하 증가로 인한 문제
NN으로 사용하는 서버들은 8년 이상을 사용한 오래된 서버들이였고 hive, ResourceManager, Oozie 등 다양한 서비스들이 올라가 있는 서버로 많이 부하가 심하다는 것을 생각해 일부 서비스들을 다른 서버로 옮겨 상황을 지켜보았지만, 역시 동일한 문제가 계속해서 발생했다.
리서치
설정 변경을 통해 문제를 해결할 수 있는지에 대한 리서치를 진행했다
먼저 core-site.xml과 hdfs-site.xml에 존재하는 timeout 값에 대한 리서치를 진행
hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-common/core-default.xml
hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml
두 파일의 설정값을 찾아본 결과 journal timeout에 대한 설정값을 찾지 못했다
추가 리서치를 진행하던 중
issues.apache.org/jira/browse/HDFS-8298
해당 내용을 확인한 결과 코드상에는 존재하지만 권장하지 않고 필요성을 느끼지 못해 표시되지는 않은 상태
실제 코드를 확인
해당 설정값이 존재하는 것을 확인
설정 변경
해당 설정뿐만 아니라 리서치를 진행하며 같이 변경했다고 하는 값까지 함께 변경하여 추가된 내용은 아래와 같음
Ambari를 사용하는 경우 custom 값으로 넣어주어야 함
hdfs-site.xml
dfs.qjournal.start-segment.timeout.ms=90000
dfs.qjournal.select-input-streams.timeout.ms=90000
dfs.qjournal.write-txns.timeout.ms=90000
core-site.xml
ipc.client.connect.timeout=90000
설정 값 변경을 진행하며 이로 인해 발생할 수 있는 다른 문제점에 대해서 생각
해당 설정값 변경으로 journalnode에 write하는 시간이 길어질 수 있지만, NN 장애 상황으로 발생하는 것보다 조금의 지연시간이 발생하는 것이 더욱 이득이라고 판단
실제로 NN이 내려갔다 올라오는데 걸리는 시간은 현재 운영중인 클러스터 기준 약 40분 ~ 1시간정도의 시간이 걸렸고, NN1이 올라오는 동안 NN2에서도 동일한 문제가 발생하는 경우 시스템 장애 상황이 발생
설정 변경으로 이를 최소화 할 수 있다면 timeout값을 늘리고 발생할 수 있는 다른 상황보다 득이 되는 점이 많다고 판단해 위와 같이 설정값을 변경
확인
설정값을 변경한 이후 journalNode edit까지 20000ms(20초)이 걸리는 log를 확인
전과 같이 NN이 중지되는 문제는 발생하지 않음
설정값 변경 이후 실제로 NN이 중지되는 일이 없어지고 너무 전환되지 않아 수동작업을 진행
'BigData > Hadoop' 카테고리의 다른 글
Apache Hadoop 관련 폐기 프로젝트(2021.04) (0) | 2021.04.15 |
---|---|
Hadoop3 변경점 (0) | 2021.04.12 |
Hadoop ZKFC(Zookeeper Failover Controller) (0) | 2021.04.10 |
Hadoop2 NameNode HA QJM(Quorum Journal Manager) (0) | 2021.04.08 |
Hive 테이블 복사하기 (0) | 2021.04.07 |