http://www.jaso.co.kr/352

hadoop을 구성하는 데몬 서버 중에 Secondary NameNode 라는 것이 있습니다. 최근 이놈 때문에 고생을 좀 했습니다. ㅋㅋㅋ
Secondary라는 이름만 보면 NameNode의 stand-by 역할을 수행하거나 백업 역할을 수행하는 것입니다. 하지만 실제로는 Stand-by 역할을 수행하지 않고 NameNode에서 관리하는 파일시스템의 이미지 정보를 백업하는 기능을 수행합니다.

하지만 또 다른 기능을 수행하는데 이것이 아주 중요한 기능입니다. NameNode의 Hadoop 파일시스템의 이미지 정보를 저장하고 있는 파일과 파일생성, 디렉토리 생성 등과 같은 작업을 수행한 edit log를 머지하는 작업을 Secondary NameNode 가 수행합니다. 이 작업을 하지 않아도 Hadoop 시스템에 큰 문제는 발생하지 않습니다.

따라서 Secondary NameNode 설정이 잘못되어서 운영되지 않아도 당장은 큰 문제가 없습니다(물론 Secondary NameNode가 동작하지 않거나 실행하지 않은 경우라면 NameNode의 hadoop 파일시스템 이미지 파일은 rsync 등을 통해 주기적으로 백업을 받아야 겠죠.)

문제는 Hadoop을 오랜 기간동안 stop 시키지 않았거나 파일 시스템에 많은 작업(수십만 번의 파일생성, 삭제, 디렉토리 생성 등)을 수행한 경우 Hadoop을 중지 했다가 다시 실행할 경우에 발생합니다. Secondary NameNode에서 수행해야 할 edit log 파일과 머지하는 작업이 수행되지 않았기 때문에 edit log 파일에 엄청나게 많은 로그가 쌓여 있게 됩니다. hadoop이 시작될때 처리는 먼저 이미지 파일을 읽어 메모리에 기본 파일시스템의 inode 정보를 구성한 다음에 edit log 파일을 읽어 순차적으로 실행합니다. 이 과정이 모두 완료되어야만 클러스터가 ready 상태가 됩니다. 하지만 수행해야할 edit log 레코드가 많은 경우라면 수행 속도도 느리고 메모리도 그 만큼 많이 차지하게 됩니다.

제 경우에 기존에 4GB 메모리에서도 잘 운영되는 클러스터가 restart 할 경우 16GB로 늘려야지만 겨우 다시 정상적으로 구동이 되었습니다. 그것도 몇 시간 클러스터 startup 과정을 거친 후에 말입니다.

따라서 Secondary NameNode는 단순 백업용이 아니라 아주 중요한 역할을 수행하고 있기 때문에 반드시 정상적으로 운영되고 있는지 모니터링 되어야 합니다. 주기적으로 edit log 파일이 과도하게 증가하지 않는지 점검해보는 것도 클러스터를 안정적으로 운영하는 방법중 하나입니다.