SyntaxHighlighter.all();

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

+ Recent posts