Filesystems

[Hadoop Distributed File System]
HDFS는 Hadoop Framework을 위해 JAVA로 작성된 distributed, scalable, potable한 filesystem이다.
Hadoop instance의 각 노드들은 하나의 datanode를 가지고 있다. datanode들의 cluster는 HDFS의 cluster를 형성한다.
각 노드가 하나로 정의된 datanode를 필요로 하지 않기 때문이다.(?) 각 datanode는 네트워크상에서 HDFS가 정한 block protocol을 이용해서 데이터를 서비스한다. 이러한 파일시스템은 TCP/IP 래이어를 사용하며 클라이언트는 RPC를 이용해서 서로 통신한다.

[데이터 복제]
HDFS는 대용량 파일들을 여러개의 머신에 걸쳐서 저장하는데 이상적으로는 여러개의 64MB 크기의 파일들이다. 이것은 결국 여러대의 호스트에 데이터를 복사하여 신뢰성을 확보하고 있다. 그렇기 때문에 각 호스트에 RAID 스토리지가 필요하지 않게된다.
기본값은 3이며 이것은 곧 3대의 호스트에 데이터가 복사된다는 뜻이다. 그 중 2개는 동일한 RACK에 존재하며 나머지 하나는 다른 RACK에 존재한다.

HDFS는 대용량 파일을 다루기 위해 디자인되었으며 성능 향상을 위해 POSIX Filesystem의 호환성을 완벽히 만족하진 않는다. 또한 High Availability를 보장하지 않는다.

[Namenode]
HDFS는 하나의 유일한 서버로 name node라는 것이 필요하다. 이것이 결국 Single point of failure가 된다. 만약 이것이 다운되면 전체 filesystem은 offline이 된다.
다시 복구되었을 때, name node는 모든 outstanding operations를 재수행해야 한다. 대용량 클러스터의 경우 30분이 소요될 수도 있다.
Filesystem은 또한 Secondary Namenode를 구성하고 있는데 사람들은 가끔 Primary namenode가 죽었을 때 secondary namenode가 그 역할을 이어 받을 것이라 착각한다. 하지만 secondary namenode는 primary namenode의 directory 정보의 snapshot을 떠 놓고 이것을 local과 remote directory들에 저장하고 있을 뿐이다. 이것으로 결국 Primary Namenode가 장애로 부터 복구되었을 때 전체 filesystem action들을 다시 수행하지 않아도 복구할 수 있도록 도와준다.

[Jobtracker & Tasktracker]
HDFS를 사용하는 장점은 jobtracker와 tasktracker 사이에서의 data awareness 이다.
jobtracker는 tasktracker에게 데이터의 위치 정보를 이용해서 map/reduce의 스케줄링을 담당한다.
(여기서 부터는 번역 아님)
결과적으로 jobtracker는 MAP/REDUCE job을 tasktracker들에게 할당하고 모니터링 및 failover를 처리하는 master이다.
tasktracker는 작업을 수행하는 worker이고 보통 datanode하고 함께 동작한다. 이유는 보통 HDFS 자체도 network으로 1 hop이 떨어져 있는 것이 대부분인데 실제로 파일을 읽고 연산하는 tasktracker가 datanode와 떨어져 있어서 좋을 것이 하나 없기 때문이다.
일반적으로 datanode는 disk I/O 가 대부분이기 때문에 남아도는 CPU를 tasktracker가 활용하는 것이 효과적인 방법이다.