HDFS : 범용 하드웨어로 구성된 클러스터에서 실행되고
스트리밍 방식의 데이터 접근 패턴으로 대용량 파일을 다룰 수 있도록 설계된 파일 시스템
특징 - 매우 큰 파일
- 스트리밍 방식의 데이터 접근
- 범용 하드웨어
1. HDFS 개념 - 블록
1) HDFS의 블록
- 블록 크기 : 한번에 읽고 쓸 수 있는 데이터의 최대량 (HDFS의 블록의 크기 = 128MB)
- HDFS의 파일은 특정 블록 크기의 청크로 쪼개지고, 각 청크는 독립적으로 저장됨
2) HDFS 블록의 특징
- HDFS의 블록은 데이터가 블록크기보다 작은 데이터일 경우 전체 블록크기에 해당하는 하위 디스크 모두 점유X
(보통은 모두 점유)
-> ex) 블록 128MB, 데이터 1MB인 경우 1MB의 디스크만 사용
- 블록은 내고장성, 가용성을 제공하는 데 필요한 복제 구현시 편함
- 블록 추상화의 장점 : > 파일 하나의 크기가 단일 디스크의 용량보다 더 커질 수 있음
> 파일단위보다는 블록단위로 추상화를 하면 스토리지의 서브시스템을 단순하게 만들 수 있음
1. HDFS 개념 - 네임노드와 데이터노드
HDFS 클러스터는 네임노드-데이터노드로 구성되어 있음
1) 네임노드
- 파일시스템의 네임스페이스를 관리
- 파일시스템 트리와 그 트리에 포함된 모든 파일과 디렉터리에 대한 메타데이터 유지
- 파일에 속한 모든 블록이 어느 데이터노드에 있는지 파악
- 파일시스템의 모든 파일과 각 블록에 대한 참조 정보를 메모리에서 관리
2) HDFS 클라이언트
- 사용자를 대신해서 네임노드와 데이터노드 사이에서 통신하고 파일시스템에 접근
3) 데이터노드 (실질적 일꾼)
- 디스크에 저장된 블록을 읽음
- 클라이언트나 네임노드의 요청이 있을 때 블록을 저장하고 탐색하며,
저장하고 있는 블록의 목록을 주기적으로 네임노드에 보고함
4) 네임노드의 장애복구 기능 (두가지 방법)
첫번째, 파일 시스템의 메타데이터를 지속적인 상태로 보존하기 위해 파일로 백업
두번째, 보조 네임노드 운영 ( 보조 네임노드는 주 네임노드와 조금 다르게 동작함 )
* 보조 네임노드
역할 - 에디트 로그가 너무 커지지 않도록 주기적으로 네임스페이스 이미지를 에디트 로그와 병합하여
새로운 네임스페이스 이미지를 만드는 것
- 주 네임노드에 장애가 발생할 것을 대비하여 네임스페이스 이미지의 복제본을 보관함
( 복제본에 대한 시간차 문제는 추후에 다룰 예정)
필요 스펙 : 병합작업 수행을 위해 보조네임노드는 충분한 CPU, 큰 메모리(네임노드와 비슷한 용량)
2. HDFS 개념 - 블록캐싱
블록캐시 : 빈번하게 접근하는 블록파일을 '오프-힙 블록캐시'라는 데이터 노드 메모리에 캐싱할 수 있음
캐시 풀- 캐시지시자 : 이것을 추가하면 특정파일을 캐싱하도록 명령할 수 있음
캐시풀 - 캐시 권한이나 자원의 용도를 관리하는 관리 그룹의 역할을 함
3. HDFS 개념 - HDFS 페더레이션(연합체)
- 네임노드의 메모리 확장성을 위해 HDFS 페더레이션을 활용
- 각각의 네임노드가 파일시스템의 네임스페이스 일부를 나누어 관리하는 방식, 새로운 네임노드 추가 가능
ex) A네임노드는 '/user' 하위 디렉터리 관리, B네임노드는 '/share' 하위 디렉터리 관리
- 각 네임노드는 네임스페이스 불륨과 블록 풀을 관리
네임스페이스 볼륨 | 블록 풀 | |
역할 | 네임스페이스의 메타데이터 구성 | 네임스페이스에 포함된 파일의 전체 블록을 보관 |
특징 | 서로 독립적 -> 네임노드는 서로 통신할 필요 X -> 특정 네임노드에 장애 발생시 다른 네임노드의 다른 네임스페이스 가용성에 영향X |
저장소 독립적이지 않음 -> 모든 데이터노드는 클러스터의 각 네임노드마다 등록됨 -> 여러 블록 풀로부터 블록을 저장 |
4. HDFS 개념 - HDFS 고가용성
1) 고가용성
활성대기 상태로 설정된 한 쌍의 네임노드로 구현됨, 활성 네임노드에 장애 발생시 대기 네임노드가 역할을 대신함
고가용성을 위한 HDFS 변경 사항 |
1. 네임노드는 에디트 로그를 공유하기 위해 고가용성 공유 스토리지를 반드시 사용해야 함 - 대기 네임노드가 활성화 시 1) 기존활성 네임노드의 상태를 동기화하기 위해 공유 에디트 로그를 읽음 2) 활성 네임 노드에 새로 추가된 항목을 읽음 2. 데이터노드는 블록 리포트를 두 개의 네임노드에 보내야됨 - 블록 매핑 정보는 디스크가 아닌 네임노드의 메모리에 보관되기 때문 3. 클라이언트는 네임노드 장애를 사용자에게 투명한 방식으로 처리할 수 있도록 구성해야함 4. 대기 네임노드는 보조 네임노드의 역할을 포함, 활성 네임노드 네임스페이스의 체크포인트 작업을 주기적으로 수행 |
2) 고가용성이 필요한 이유
'1-4 네임노드의 장애복구 기능'에서 말한 두 가지 방법에도 문제점이 있음
새로운 네임노드 재구동까지는 총 3단계를 거쳐야함
(1) 네임스페이스 이미지 메모리에 로드
(2) 에디트 로그 갱신
(3) 전체 데이터노드에서 충분한 블록 리포트를 받아 안전모드 벗어나기
위의 3단계는 시간이 30분 이상 걸릴 수 있음 -> 그동안은 시스템 먹통됨 -> 큰일!!!!!!!!
추가) 고가용성을 사용한다해도 1분정도 걸림
-> 이유 ? 시스템이 활성 네임노드에 장애가 발생했다고 판단하는 시간 ( 매우 신중해야됨)
3) NFS, QJM
고가용성 공유 스토리지를 위해 NFS필러 or QJM 을 선택
- QJM : HDFS 전용 구현체, 고가용성 에디트 로그를 지원하기 위한 목적으로 설계 (HDFS의 권장 옵션)
저널노드 그룹에서 동작, 각 에디트 로그는 전체 저널 노드에 동시에 쓰여짐
(일반적으로 저널노드는 3개)
주키퍼와 유사
4) 장애복구와 펜싱
장애복구 컨트롤러 : 대기 네임노드를 활성화시키는 전환 작업을 관리
- 우아한 장애복구 vs 우아하지 못한 장애복구
우아한 장애복구 : 정기적인 유지관리를 위해 관리자가 수동으로 초기화 (두개의 네임노드가 서로 역할을 바꿈)
우아하지 못한 장애복구 : 장애가 발생한 네임노드가 자신이 아직도 활성 네임노드라고 착각함
-> 이때 펜싱을 사용하여 활성 네임노드 죽임! (시스템 손상시키면 안되니까..)
'빅데이터 > 하둡' 카테고리의 다른 글
[하둡] 7. YARN- 맵리듀스 1과의 차이 (0) | 2020.07.01 |
---|---|
[하둡] 6. YARN (0) | 2020.06.29 |
[하둡] 5. HDFS (하둡 분산 파일시스템) - 데이터 흐름 (1) | 2020.06.19 |
[하둡] 2. 맵리듀스 (1) | 2020.06.18 |
[하둡] 1. 하둡 (1) | 2020.05.25 |