반응형 hadoop4 NameNode Federation NameNode Federation HDFS의 네임노드가 모든 메타 데이터를 메모리에 저장해야 한다는 사실에 기반함. 네임노드를 단일 서버의 물리 메모리 용량 이상으로 확장하려면 Scale-Up 보다 Scale-Out 에 더 포커스를 두어야 함. HDFS의 블록 쓰기 처럼 파일 시스템의 메타 데이터를 다수의 머신에 분산 저장할 수 있음. 다수의 독립 시스템을 페더링하여 하나의 논리 네임스페이스를 구성하는 방법. ( ex. 리눅스 파일 시스템 ) 네임노드 페더레이션과 다른 분할 클러스터 ( discreet cluster )의 가장 큰 차이점은 각각의 데이터 노드는 여러 네임 노드의 블록 데이터를 저장 함. 각 데이터 노드는 각 네임스페이스의 블록 풀을 포함하고 있음. 서로 다른 풀의 여러 블록은 동일 디스.. 2022. 6. 2. Name Node의 고가용성(High Availability) 네임노드의 고가용성(HA : High Availability) 네임노드 고가용성은 active/passive 한쌍의 네임노드로 구성이 됨. active 네임노드가 변경된 내용을 edits 로그에 쓰면, Stand-by 네임노드는 트랜잭션을 계속 반영하여 최신정보를 유지함. 실패하면 active NameNode를 즉시 대체할 수 있도록 준비를 함. 데이터 노드들은 HA 설정 정보로 두 네임노드(active/passive)를 알고 있고, 두 네임노드에 모두 블록 리포트를 보냄. 네임노드의 고가용성은 수동과 자동 장애 복구(Failover)를 지원함. 수동 장애 복구 직접 명령어를 입력하여 다른 네임노드로 상태 전환을 하는 방법. 자동 장애 복구 네임노드들은 프로세스의 상태를 모니터링 및 상태 전환을 관리하는.. 2022. 5. 31. Secondary Name Node 네임노드는 Local File System에 파일 시스템 메타 데이터를 저장을 함. 저장하는 메타 데이터 중 가장 중요한 두가지 fsimage ( Hadoop File System 메타데이터의 완전한 Snapshot ) edits ( 메타데이터의 누적된 변경 내용 ) Edits 파일은 WAL(Write Ahead Log)로 지속적인 파일을 추가 조작을 하므로 I/O 작업의 부하가 적고, 성능을 낮추는 탐색 동작도 줄일 수 있음. 네임 노드가 재시작 하게되면, fsimage 파일을 메모리에 로드하고 edits 파일의 변경 내용을 반영하므로 파일 시스템의 최근 이미지를 메모리에서 볼 수 있음. Secondary Name Node의 필요 이유. 시간이 지날 수록 edits파일은 로그기반 시스템 처럼 점점 늘어.. 2022. 5. 28. HDFS의 파일 시스템 특징 파일 시스템 일반적인 파일 시스템의 블록 크기는 보통 4KB or 8KB이다. 그에 비하여, 하둡 파일시스템의 기본 블록 크기는 64MB 이다. 추가로 하둡 에코시스템을 관리하는 관리자는 이 블록의 크기를 128MB, 256MB, 1GB 정도로 늘릴수 있다. 하둡 블록의 크기를 조절 할 수 있으면 뭐가 좋을까? 블록의 크기가 증가하면 데이터를 더 큰 청크 단위로 저장 할 수 있게 된다. => 더 큰 단위로 데이터를 읽고 쓰기를 할 수 있으므로 성능 또한 좋아지게 된다. 드라이브의 탐색 조작을 최소화 할 수 있으며, 대규모 I/O의 성능을 향상 시킬수 있다. *Replication HDFS( Hadoop File System )은 데이터 보호를 스토리지의 의존하지 않으며, 클러스터내의 다른 머신에 데이터 .. 2022. 5. 15. 이전 1 다음 반응형