하드디스크 물리적인 장애발생과 서버관리자의 의무(badblocks)

제목 : 하드디스크 물리적인 장애발생과 서버관리자의 의무(badblocks)

리눅스 서버관리자에게 가장 큰 문제 가운데 한가지는 디스크 배드블록에 의한 시스템장애일 것입니다. 이번 절에서는 하드디스크의 배드블록에 대해서 다루어 보도록 하겠습니다. 서버관리자는 주기적으로 하드디스크의 배드블록을 점검해야하며 점검결과 배드블록이 존재한다면 해당 디스크를 교체하거나 또는 배드블록부분을 사용하지 못하도록 마킹하여 사용하지 못하도록 해야합니다. 즉, 서버관리자는 배드블록에 대한 다음 두가지 작업을 할 수 있어야합니다.

- 주기적인 배드블록 점검
- 배드블록 발생시 디스크교체(권장) 또는 마킹하여 사용하기(권장안함)

이번 절에서 설명드릴 내용이 위의 두가지 방법에 대한 내용입니다. 즉, 주기적으로 배드블록 점검을 너무 자주하는 것은 오히려 시간낭비이므로 약 2개월에 한번정도 하는 것을 권해드립니다. 실제로 배드블록점검을 하면 시간이 꽤 오래 걸리며 시스템 부하를 많이 유발하기 때문에 주로 새벽시간대에 작업합니다. 그리고 점검한 후에 배드블록이 존재한다면 가능한 디스크 교체작업을 하는 것이 좋습니다. 어떤 분들은 배드난 부분을 마킹하여 사용하시는 분도 계시지만 절대로 바람직하다고는 할 수 없습니다. 가능한 배드난 디스크는 깨끗한 새디스크로 교체하여 사용하시기 바랍니다. 

하드디스크의 물리적인 장애발생과 서버관리자의 책무

우리 같은 서버관리자들에게 있어서 가장 무서운 것이 무엇일까요?  필자는 이 질문에 아주 명확하고 간단하게 답할 수 있습니다.  “디스크의 물리적인 문제로 인한 시스템다운”이라고 말입니다.  가끔씩 필자는 서버다운문제로 인하여 복구의뢰를 받곤합니다. 이런 경우 대부분 복구하지 못하는 경우의 가장 흔한 원인은 디스크의 물리적인 문제가 발생하였을 경우입니다.  다행히 백업을 해두었다면 다른 디스크로 대체하여 복구를 할 수는 있겠지요.  물론 백업이 되어있는 경우라 하더라도 대략 3~4시간의 복구시간동안 시스템이 정지되어야 합니다.  이런 경우는 그나마 다행입니다.  백업되어있지 않을 경우가 가장 큰 문제가 됩니다.  즉, 이런 경우에 할 수 있는 유일한 방법은 디스크복구센타로 찾아가는 것이겠지요.

물론 이런 상황은 최악의 시나리오라고 할 수 있습니다.  즉, 디스크의 물리적인 문제를 해결하기 위하여 RAID로 구성하기도 하고, 디스크동기화를 하기도 합니다.  하지만, 이런 방법이 궁극적인 해결책이 될 수는 없을 것입니다.  어차피 하드디스크는 소모품에 불과하니까요.   그렇다고 우리 같은 서버관리자들이 디스크장애가 발생하지 않기만을 바랄 수는 없을 것입니다.

즉, 디스크의 물리적인 문제라고 한다면 거의 대부분은 “배드블록(BadBlock)”에 있다고 할 수 있습니다. 디스크에 배드블록이 존재하면 언제 서버가 다운될런지 알 수 없습니다. 즉, 배드블록이 존재하는 위치에 데이터를 ACCESS(읽기, 쓰기)를 하게 되면 시스템장애가 발생하게되는 것이니까요. 필자는 서버관리실무를 하면서 가장 조심하고 민감했던 부분이 백업과 디스크장애대비라고 할 수 있습니다.

즉, 디스크의 물리적인 문제가 발생하지 않기만을 기다릴 것이 아니라 주기적으로 점검을 하는 것이죠.  디스크의 물리적인 장애의 대부분이 배드블록(badblock)이므로 디스크 배드블록을 주기적으로 점검하는 작업이 꼭 필요할 것입니다.

하드디스크에 배드블록의 존재유무 점검하는 방법

배드블록이 존재하는 하드디스크를 사용하게 되면 정상적인 운용중에도 갑자기 서버가 다운되는 등의 심각한 장애를 초래할 수 있습니다. 따라서 배드블록은 서버설치시 또는 설치 직후에 반드시 점검을 해야하며 배드블록이 존재할 경우에는 깨끗한 디스크로 반드시 교체해야합니다.  아래는 실제 배드블록을 검사하는 예입니다.

위의 예는 배드블록이 존재하지 않았을 경우의 예입니다. 이상이 없는 깨끗한 디스크이므로 정상적인 사용이 가능하다고 할 수 있습니다.

위의 경우에는 3개의 배드블록이 존재하는 경우입니다. 배드블록이 존재할 경우에는 몇개의 배드블록이 존재하는지 결과에서 알려줍니다. 이 경우처럼 -o옵션을 주게 되면 지정된 파일(badblock.txt)에 결과를 저장하며 그 파일을 확인(cat badblock.txt)함으로서 배드블록의 번호를 확인할 수 있습니다.

플로피디스크의 배드블록 존재유무 점검하기

앞의 예에서는 하드디스크의 배드블록 존재여부와 배드블록번호를 확인하는 방법에 대해서 알아보았습니다.  디스크에는 하드디스크외에도 플로피디스크가 있으므로 badblocks라는 명령어로 플로피디스크의 배드블록의 점검도 가능합니다. 즉, 아래 예와같이 플로피디스크의 배드블록의 존재유무를 점검하시기 바랍니다.

위의 예에서 /dev/fd0H1440은 플로피디스크의 용량별 장치명이며 뒤에 나오는 1440은 플로피디스크의 전체용량을 kbyte단위로 지정한 것입니다.

이번 장에서는 badblocks명령어로 디스크의 배드블록의 존재유무와 배드블록이 존재할 경우에는 그 위치 배드블록번호를 확인하는 방법에 대해서 알아보았습니다.

거듭 당부드리지만 디스크 배드블록은 우리 같은 서버관리자들에게 있어서는 적(enemy)이나 마찬가지입니다. 따라서 우리는 이와 같은 적(enemy)을 늘 감시하고 조사하면서 적(enemy)발견시에는 가치없이 도려내고 교체하는 엄벌에 처해야 할 것입니다.

디스크의 배드블록 마크하기

e2fsck의 옵션에는 badblocks을 실행하여 배드블록을 찾은 후에 디스크의 배드블록 아이노드에 추가하여 마크함으로써 마크되어있는 배드블록을 사용하지 못하도록 하는 방법이 있습니다.

-c 옵션으로 배드블록표시가 가능하며 최소 1년에 2회이상은 배드블록을 점검하여 배드블록이 존재할 경우에는 이를 마크하여 사용하지 못하도록 설정해야 합니다.

다음은 e2fsck를 이용하여 /dev/hda1파일시스템내에 배드블록이 있는가를 찾아서 만약 존재한다면 배드블록 아이노드에 마크하는 작업입니다.

참고로 주의하실 것은 현재 마운트(mount)가 되어있는 상태에서 e2fsck로 배드블록마킹작업을 하게 되면 다음 예와 같이 WARNING!!메시지를 출력하면서 파일시스템이 손상될 수 있다는 것을 알려주고 있습니다. 따라서 e2fsck사용시에는 반드시 마운트해제된 상태에서 작업하시기 바랍니다. 

만약 위의 점검에서 배드블록을 찾아서 마크하게 된다면 이후부터는 마크된 위치의 블록에는 데이터를 저장하지 못합니다. 즉, 배드블록위치에 데이터가 저장되지 못하도록하여 배드블록의 ACCESS로 인한 디스크장애를 예방하기 위한 조치입니다.  하지만 상용서비스를 하는 서버내에서 사용되고 있는 하드디스크에 배드블록이 존재한다면 가능한 배드블록이 없는 새디스크로 교체하여 깨끗하게 사용하시는 것이 보다 안전할 것입니다.

이번 작업에서 주의할 점은 현재 사용중인 디스크를 대상으로 배드블록 마킹작업을 해서는 절대로 안된다는 것입니다.

그리고 가능한 디스크 배드블록을 주기적으로 점검할 때에는 cron을 이용하여 자동화시켜두는 것도 좋은 방법이기는 하지만 필자는 개인적으로 직접 콘솔앞에서 하시기를 권해드립니다. 배드블록점검작업 자체가 서버에게는 꽤 무거운 작업이며 시간을 요하는 작업이기 때문이기도하지만 배드블록점검 작업시 발생할 수 있는 응급작업에 긴급한 대처를 해야하기 때문입니다.