Hadoop 2 ) 네임노드 HA(High Availability)

하둡 1 VS 하둡 2 


  • 하둡은 에코시스템 환경이 중요한데(하둡 하나만으로는 부족) 하둡클러스터에서 하둡 에코시스템이 적절하게 시스템 자원을 분배받고, 할당된 자원이 모니터링 되고 해제 되어야했음 
  • SPOF(Single Point Of Failure, 단일 고장점) : 네임노드 서버 하나에서 모든 데이터노드들의 메타데이터를 관리하고 스케줄링하는데 만약 이 하나의 서버가 장애가 오면 그 네임노드가 구성하는 하둡 클러스터는 고장이남. 네임노드의 이중화가 필요



네임노드 HA(High Availability)

-> 즉, 잘 고장나지 않고 오래오래 사용할 수 있는 네임노드


  • 왜 필요한가?
    • 네임노드가 정상적으로 작동하지 않으면 모든 클라이언트가 HDFS에 접근 불가   
    • 네임노드 파일 시스템 이미지에 문제가 생겨도 HDFS에 저장된 데이터에 조회 불가
      • 파일 시스템 이미지에 HDFS의 디렉토리 구조와 파일 위치가 저장되어 있음. 그러니까 블록에 접근할 수 있는 통로(라거나.. 음 지도?)가 사라지니까 접근을 못하지 
    • 네임노드의 에디트로그에 문제가 생겨도 데이터 유실이 될 수 있음
      • 에디트 로그( editslog): HDFS의 모든 변경이력이 담겨 있음, HDFS에 저장된 파일을 수정한다? 그러면 에디트 로그 만들어짐
      • 에디트 로그는 파일시스템이미지에 반영이 되기 때문에 문제가 생기면 HDFS가 변경된 이력이 FsImage에 적용이 안될 수 있음 
      • 네임노드가 HDFS에 대한 데이터 갱신 기록을 에디트로그에 저장 -> 메모리에서 관리 
      • 보조네임노드는 체크포인팅 작업을 통해 에디트로그를 파일시스템이미지에 갱신하는데 체크포인트가 만들어지기 전에 에디트로그가 손상되고 네임노드가 재시작되면 손상된 에디트로그는 이미지에 반영이 안된 채 네임노드 구동
   

네임노드 HA 주요 컴포넌트 

  • 저널노드 
    • 하둡 1에서 문제 : 네임노드에서만 에디트 로그 저장 -> 하둡2: 여러 서버에 에디트 로그를 복제해서 저장 
    • 저널노드(데몬)는 에디트로그를 자신이 실행되는 서버의 로컬디스크에 저장
    • 네임노드는 클라이언트가 돼서 저널노드에 접근해 저장을 요청
      • 단 액티브 네임노드만 에디듵로그 저장할 권한이 있음 
      • 스탠바이 네임노드는 조회만 요청가능 함 
    • 저널노드는 반드시 3대 이상의 서버에 실행되어야하고 홀수 단위로만 실행가능
    • 네임노드가 저널노드 장애에 영향을 받지 않으려면  "(전체 저널노드 설치대수/2) / +1" 만큼 실행
      • 5대에 저널 노드를 설치했으면 최소 3대 이상의 저널노드가 실행 
    • 리소스를 적게 사용해서 "네임노드", "잡트래커", "리소스매니저"와 같은 데몬이 돌아가는 서버에서 함께 실행가능 
  • 주키퍼 
    • 네임노드 HA 상태 정보를 저장하는 저장소 
      • 어떤 서버가 액티브 네임노드인지 스탠바이 네임노드인지 저장
    • 분산시스템 코디네이터 
      • 애플리케이션들이 잘 돌아가도록 중재 
      • 분산된 서버 간의 정보 공유 
      • 새로운 서버를 열거나 제거했을 때 다른 노드들에게 알려주기 
      • 서버 모니터링 -> 연결이 끊어진(장애가 발생했을) 노드 삭제 
      • 시스템관리, 분산 락(Lock) 처리, 네이밍서비스 등등 
    • 주키퍼 마스터는 홀수 단위로 실행해서 주키퍼 클라이언트는 주키퍼 마스터가 응답을 안할 경우 다른 주키퍼 마스터에게 요청
      • 과반 정족수 이상이 서버 다운시, 서비스 중지 (예, 2대 중 1대가 다운되면 바로 서비스 중지. 그래서 3대 이상으로 홀수로 서버수를 맞춤)
    • ZNode: 주키퍼에서 저장되는 파일 하나하나를 ZNode라고 한다 (자세한건 https://blog.seulgi.kim/2014/05/zookeeper-1-znode-zookeeper-data.html)
        • 주키퍼는 ZNode라는 트리 계층을 갖고 있다.(파일 시스템 구조 같음)
        • 각 ZNode의 각 노드에는 1MB만 저장할 수 있음(어차피 메타데이터 저장하는 거라)
    • ZKFC(ZookeeperFailoverController)
      • 로컬 네임노드의 상태를 모니터링 
      • 주키퍼 세션관리 
        • 액티브 네임노드의 상태가 정상이면 주키퍼 마스터에 대한 세션 유지 
    • 자동 장애 처리(failover)
      • 액티브 네임 노드에 장애가 발생하면 감지해서 자동으로 zkfc와 주키퍼 마스터 간의 세션 종료 -> 스탠바이 네임 노드를 액티브 네임 노드로 전환 -> 기존의 액티브 네임 노드 제거 (그럼 또다른 스탠바이 네임노드는 새로 만들어야 하나?)

  • 네임노드
    • 네임노드 내부에 있는 QJM(QuorumJournalManager)이 저널노드에 에디트로그 출력
      • 이때 반드시 절반 이상의 저널노드가 실행되고 있어야 에디트로그를 FsImage에 반영함
      • 액티브 네임노드만 저널노드에 에디트로글 쓸 수 있음 
      • 스탠바이 네임노드는 저널노드에서 에디트로그 조회하고 FsImage를 갱신 -> 그래서 보조네임노드를 실행할 필요가 없음 

  • 데이터노드
    • 액티브 네임노드, 스탠바이 네임노드 모두 블록 리포트 전송
      • 그래서 액티브 네임노드가 장애가 생겨서 중지되도 바로 스탠바이 네임노드 투입해서 사용가능함 






























    댓글