대규모 스토리지에서 HDFS Erasure Coding을 사용할 때의 기술적 과제
- DAY1 15:20-15:40 KST
- Youtube link
배경
- HDFS 는 Hadoop 하위 프로젝트로 분산형 파일시스템.
- 서버가 다운되어도 데이터가 사라지지 않도록 하고 높은 처리 능력으로 RW 가능
- Master 인 NameNode 와 Slave 인 DataNode 로 구성
- NameNode 는 메타데이터 관리, 데이터는 복수 DataNode에 분산 저장
- 데이터가 어디 있는지 NameNode 에 문의하여 DataNode 에 직접 접근.
- DataNode끼리 복제를 통해 장애 내성을 실현.
Erasure Coding
-
매월 10PB 가량 데이터가 증가하고 있는데, 인프라스트럭처 비용 감소를 꾀하기 위해 오래된 데이터에 대해선 HDFS Erasure Coding 적용
-
파일이 블록 단위로 분할되는데, Replication 3x일 경우 3개의 DataNode 3개에 각각 copy
-
Erasure Coding 에서는 더 작은 cell 단위로 분할되고, 3개의 데이터 블록과 2개의 패리티 쉘을 분산 저장하여 장애 발생하여도 복구 가능.
- 3개의 데이터블록은 복제가 아닌 서로 다른 데이터
- 5/3 약 1.7배의 저장용량 이득을 가져갈 수 있음.
-
데이터 복구시 ErasureCoding 은 살아있는 데이터 블록과 패리티 쉘에서 복구 가능.
-
높은 장애 내성을 가지면서도 저장용량 이점이 있음
- 단, 작은 파일이 많을 경우 네블록수가 많아지므로 네임노드 부하가 커짐
-
-> 파일 사이즈가 큰 경우에 대해서만 Erasure Coding 을 적용하고 있음.
Data Corruption
- Erasure Coded file 을 읽을 수 없는 문제가 생겼었는데, HDFS 상에서 오픈 이슈가 있었음.
- 어떤 리더가 타임아웃되고 다른 리더가 선출 -> 타임아웃으로 캔슬된 리더로 인해 NPE 발생 -> reconstruct 취소 -> 버퍼풀로 되돌리도록 함 -> 버퍼에선 close 할 때 까지 읽으려하고 버퍼풀 오염이 발생함. -> 오염된 버퍼풀로 reconstruct -> 결과적으로 파손된 블록이 생성됨.
- spark 를 통해 daily 로 파일 체크섬을 기록하여 탐지 시도. -> 잘못된 체크섬 값이 돌아온다는 문제.
- 데이터 노드의 블록에 대한 체크섬을 계산하는데, 리더 타임아웃으로 인해 블록의 체크섬을 취득 못하고 이를 reconstruction 하여 생성함 -> 파일 디스크립터가 close 하지 않아 문제 발생 -> 체크섬 계산이 3개 블록이 아닌 2개 블록으로 패리티를 생성 -> 문제 발생
해결방법
-
d1 d3 p1 으로 d2' 복구 , d2', de, p1 으로 d1' 복구하여 d1'과 d1 이 같은지 비교 -> 다르면 reconstruction 실패 처리시킴 -> 파손된 블록 생성 방지.
-
해당 내용은 Line 에서 오픈소스 기여하여 패치되었음.
-
Erasure Coding 사용 검토시 반드시 최신 버전을 사용할 것을 권장.
