Ubuntu에서 mdadm 어레이의 실패한 드라이브 교체

이 게시물의 정보는 Ubuntu 18.04와 해당 저장소에 포함된 mdadm 버전을 기반으로 합니다. 작성 당시 v4.1-rc1입니다. 다른 버전에는 유효할 수도 있고 그렇지 않을 수도 있습니다.

저는 최근에 mdadm RAID-6 배열에 9개의 드라이브가 있는 홈 파일 서버에서 갑자기 드라이브가 고장났습니다. 항상 무섭지만 다행히도 다음 날 이미 배달된 교체 드라이브를 재빨리 구할 수 있어서 재구축을 시작할 수 있었습니다.

파일 서버를 처음 설정할 때 제가 인정하건대 약간 인색했습니다. 드라이브 중 두 개만 실제 NAS 드라이브(Seagate IronWolf)이고 나머지는 데스크톱 드라이브(Seagate Barracuda)입니다. 놀랍지 않게도, 그것은 포기한 데스크톱 드라이브 중 하나였습니다(거의 3년 동안 사용한 후에 말입니다). 완전히 죽어 있었습니다. 데스크톱 USB 인클로저로 옮긴 후에는 불안한 클릭 소리만 들렸고 Ubuntu 20.04도 Windows 10도 그것을 감지하지 못했습니다.

음, 교체 부품으로 넘어가겠습니다(그리고 네, 제가 새로 산 드라이브는 IronWolf였습니다. 교훈을 얻었죠). 실행 중인 배열에서 드라이브를 잃는 것은 무섭지만, 올바른 교체 절차를 모른다면 더 무섭습니다. mdadm 배열에서 고장난 드라이브를 교체해야 했던 건 처음은 아니지만, 다행히도 이런 일은 매우 드물어서 보통은 적절한 명령을 찾아야 합니다. 이번에는 나중에 참고할 수 있도록 제 작은 가이드를 직접 만들기로 했습니다.

그러니 우선, mdadm에서 두려운 실패 이벤트 이메일을 받으면 어떤 드라이브가 실패했는지 알아내야 합니다. 물론 장치 이름(제 경우 /dev/sdf)은 알려 주겠지만, 실제로 어떤 물리적 드라이브인지는 아마 명확하지 않을 겁니다. 그 이름은 머신이 부팅될 때 바뀔 수 있기 때문입니다.

어떤 장치 이름이 실패했는지 확실하지 않은 경우 다음 명령을 사용하여 확인할 수 있습니다(/dev/md0을 해당 RAID 장치로 바꾸세요).

앞서 언급했듯이 제 경우에는 /dev/sdf였으므로 그걸로 계속 진행하겠습니다.

그런 다음 다음 명령을 실행하여 오류가 발생한 드라이브의 일련 번호를 찾아보세요.

(smartctl이 발견되지 않으면 Ubuntu에 smartmontools 패키지를 설치해야 합니다)

그런 다음 일련 번호를 드라이브의 실제 라벨에 있는 일련 번호와 비교하여 어느 드라이브가 고장났는지 알아낼 수 있습니다.

하지만 이번에는 운이 좋지 않았습니다. 드라이브가 완전히 죽어 있었고 일련 번호를 포함한 SMART나 다른 데이터를 제공하기도 거부했습니다.

서버에 물리적으로 접근할 수 있었기 때문에(물리적 드라이브를 직접 교체하려는 경우 정말 필요할 것 같아요 ;-)) 디스크가 고장났을 때 서버 가 실제로 실행 중이었고(RAID-6 중복성 덕분에 계속 정상적으로 실행됨) 정말 원시적이지만 실제로 매우 효과적이고 명확한 방법을 선택했습니다. 간단히 큰 파일을 서버에 복사하고 어느 HDD 표시등이 깜빡이지 않는지 지켜보는 것입니다. 몇 초 안에 원인을 파악했습니다.

이제 실제 드라이브를 빼내기 전에 다음 명령을 실행하여 mdadm에 이 의도를 공식적으로 알리는 것이 좋습니다(장치 이름은 적절한 대로 사용자 이름으로 바꾸세요).

성공하면 mdadm은 드라이브를 "핫 제거"했다는 메시지와 함께 응답합니다. 그 이유는 가상 RAID 장치가 실제로 실행 중이었기 때문입니다.

"장치 또는 리소스가 사용 중"과 유사한 오류 메시지와 함께 실패하는 경우, 실제로 mdadm이 드라이브를 완전히 실패한 것으로 등록하지 않았을 수 있습니다. 그렇게 하려면 다음 명령을 실행하세요(다시 말하지만, 장치 이름을 적절한 대로 사용자 이름으로 바꾸는 것을 잊지 마세요):

그 후에는 이전 명령을 사용해서 어레이에서 장치를 제거할 수 있어야 합니다.

이제 실제로 드라이브를 교체할 때입니다. 머신과 컨트롤러가 핫 스와핑을 지원한다고 정말, 정말, 정말 확신한다면 머신을 끄지 않고도 이 작업을 수행할 수 있습니다. 이는 실제로 이를 처리할 수 있다는 것을 확실히 알고 있는 실제 적절한 서버 하드웨어에서 실행되는 중요한 프로덕션 시스템에서 사용할 수 있는 방법입니다. 하지만 제 홈 파일 서버는 소비자 등급 데스크탑 마더보드를 기반으로 하며 PCIe 슬롯에 몇 개의 세미노네임 SATA 컨트롤러를 추가하여 더 많은 SATA 포트를 제공합니다.

SATA는 일반적으로 핫 스와핑을 지원 하지만, 이 설정에서는 아무것도 위험을 감수하고 싶지 않았기 때문에 드라이브를 교체하는 동안 시스템을 끄기로 했습니다.

그렇게 하기 전에 /etc/fstab 파일에서 RAID 장치를 주석 처리하는 것이 좋습니다. 그러면 Ubuntu가 다음 부팅 시 자동으로 마운트하려고 하지 않습니다. RAID 배열이 저하되어 중단되고 복구 모드로 강제로 전환될 수 있기 때문입니다. 데스크톱 시스템이라면 큰 문제가 아닐 수 있지만, 저는 모니터나 키보드를 연결하지 않고 이 서버를 헤드리스로 실행하므로 약간 번거로울 수 있습니다.

반짝반짝 빛나는 새 드라이브가 설치된 머신을 부팅한 후 lsblk 또는 다른 수단을 사용하여 식별합니다. 다른 것을 변경하지 않았다면 아마도 ( 반드시 그런 것은 아니지만) 교체한 드라이브와 같은 이름을 갖게 될 것입니다. 제 경우에는 그랬으므로 새 드라이브도 /dev/sdf라고 합니다.

제 배열은 물리적 장치가 아닌 파티션에 기반을 두고 있기 때문에 작동하는 드라이브에서 새 드라이브로 파티션 테이블을 복사하여 정확히 동일한지 확인해야 했습니다. 대신 물리적 장치에서 배열을 실행하는 경우 이 단계를 건너뛸 수 있습니다.

이 목적을 위해 sgdisk를 사용하여 파티션 테이블을 /dev/sdc에서 /dev/sdf로 복사했습니다. 필요에 따라 장치 이름을 자신의 이름과 일치하도록 바꾸세요.

여기서 순서를 주의하세요 : "to" 드라이브를 먼저 나열하세요! 이건 제게는 약간 반직관적이지만, 배열에서 다른 드라이브 오류가 발생하지 않도록 올바르게 하세요 ;-)

그런 다음 UUID 충돌을 피하기 위해 새 드라이브에 대한 새 UUID를 생성합니다.

그리고 마침내 새로운 드라이브를 어레이에 추가하고 재구축 파티를 시작할 때가 왔습니다!(좋아요, 사실 파티는 아니고, 사실 꽤 느리고 불안한 과정입니다. 이 시점에서 또 다른 드라이브가 고장나는 것을 정말로 원하지 않기 때문입니다. 하지만 맥주가 도움이 될 수도 있습니다.)

어쨌든, 어레이에 새로운 드라이브를 추가하려면 이 명령을 실행하세요(다시 한번 말하지만, 적절하게 장치 이름을 사용자 이름으로 바꿔야 합니다).

모든 것이 잘 진행되면 드라이브가 문제 없이 어레이에 추가됩니다. 기본적으로 "핫 스페어"로 추가된다고 생각하지만, 이 어레이에는 디스크(고장난 디스크)가 없으므로 즉시 사용되고 재구축 프로세스가 시작됩니다.

다음과 같이 확인할 수 있습니다.

아마 시간이 좀 걸릴 겁니다. 저의 초라한 서버(대부분 소비자 등급 하드웨어와 데스크톱 드라이브 기반)에서는 100MB/초에 약간 못 미치는 속도까지 도달할 수 있었습니다. RAID-6이므로 재구축에는 많은 패리티 계산이 필요하다는 점을 명심하세요. RAID-10이라면 훨씬 더 빨랐을 겁니다. 이 특정 머신은 AMD A10 9700E 쿼드 코어 CPU("E"는 클럭이 낮은 에너지 효율적 모델, 즉 초고속이 아님을 의미)를 탑재하고 있습니다. 제 설정에 8TB 드라이브 9개가 있는 경우 전체 재구축에 24시간 조금 넘게 걸렸습니다.

재구축하는 동안, 원한다면 파일 시스템을 어레이에 마운트하고 평소처럼 사용할 수 있지만, 나는 완료될 때까지 재구축에 맡기는 것을 선호합니다. 한 드라이브가 고장나면 다른 드라이브도 곧 고장날 수 있으므로, 재구축은 가능한 한 빨리 완료해야 합니다. 그 동안 다른 드라이브가 고장나는 것을 원하지 않기 때문입니다. 따라서 엄격히 필요하지 않은 다른 IO로 부담을 주지 마세요.

완료되면 /etc/fstab 파일에 다시 추가하고 재부팅하여 파일을 즐기세요 :-)