☰

mdadm RAID 문제에 대한 알림을 받는 방법은 무엇입니까?

tag-icon • tag-icon linux raid software-raid mdadm
mdadm RAID 문제에 대한 알림을 받는 방법은 무엇입니까?

저는 우분투 12.04 LTS를 실행하고 있습니다. 어제 내 메일함에서 내 서버가 종료되었다는 메시지를 발견했습니다. 시스템 재부팅을 진행했지만 몇 분이 지나도 나타나지 않았고, 커널이 터미널에 무엇을 인쇄하고 있는지 확인할 수 있는 하드웨어 KVM 시스템도 없었습니다. 그래서 Linux 복구 이미지로 시스템을 재부팅했는데 소프트웨어 RAID 1 어레이가 동기화되지 않은 것을 확인했습니다. 구조 시스템도 RAID 어레이를 재구성하기 시작했습니다.

지금까지 디스크에 하드웨어 오류가 있다는 증거는 없습니다. SMART 상태는 지금까지 좋아 보입니다.

/etc/mdadm/mdadm.conf에서 이메일 알림이 켜져 있음에도 불구하고 mdadm으로부터 이메일 알림을 받지 못했습니다.

이 서버는 모든 syslog 메시지를 로그 호스트로 전달하도록 구성되었으므로 로그 호스트를 확인했습니다. 관련 부분은 다음과 같습니다.

5월 20일 15:38:40 커널: [ 1.869825] md0: 0에서 536858624로 용량 변경이 감지되었습니다.
5월 20일 15:38:40 커널: [ 1.870687] md0: 알 수 없는 파티션 테이블
5월 20일 15:38:40 커널: [ 1.877412] md: 바인딩
5월 20일 15:38:40 커널: [ 1.878337] md/raid1:md1: 깨끗하지 않음 - 배경 재구성 시작
5월 20일 15:38:40 커널: [ 1.878376] md/raid1:md1: 미러 2개 중 2개로 활성
5월 20일 15:38:40 커널: [ 1.878418] md1: 0에서 3000052808704로 용량 변경이 감지되었습니다.
5월 20일 15:38:40 커널: [ 1.878575] md: RAID 어레이 md1 재동기화
[한조각]
5월 20일 15:52:33 커널: 커널 로깅(proc)이 중지되었습니다.
5월 20일 15:52:33 rsyslogd: [origin Software="rsyslogd" swVersion="5.8.6" x-pid="845" x-info="http://www.rsyslog.com"] 신호 15에서 종료 중 .

보시다시피 시스템(복구 시스템이 아닌 일반 시스템)은 시스템 부팅 중에 RAID 어레이에 문제가 있음을 이미 감지했습니다. 그러다가 얼마 지나지 않아 (내가 아닌) 무언가가 시스템을 중단시켰습니다.

그래서 내 질문은 다음과 같습니다

  1. 디스크가 갑자기 동기화되지 않는 원인은 무엇입니까?
  2. 이메일로 알림을 받지 못한 이유는 무엇입니까?
  3. 시스템을 정지하기 전에 오류가 syslog에 제대로 기록되지 않은 이유는 무엇입니까? 시스템이 syslog에 로그인을 시도했지만 syslog 데몬을 중지한 후에 로그인했을 수 있습니까? 그렇다면 이를 방지하려면 어떻게 해야 할까요?
  4. 무슨 일이 일어났는지 알아보려면 어떻게 해야 하나요? 또는 지금 무슨 일이 일어났는지 알아낼 방법이 없다면 다음 번에 더 나은 사후 분석을 수행할 수 있도록 로깅 및 알림을 어떻게 개선할 수 있습니까?

내 질문은~ 아니다올바른 백업 방법에 대해 알아보세요. 나는 RAID가 백업 등이 아니라는 것을 이미 알고 있습니다. 내 질문은 알림 및 진단에 관한 것입니다.

답변1

디스크가 갑자기 동기화되지 않는 원인은 무엇입니까?

드라이브 플래터와 메모리의 데이터 사이의 경로에 하드웨어 또는 소프트웨어 결함이 있을 수 있습니다. 이는 드라이브 헤드, 드라이브 컨트롤러, 케이블의 연결 헤드, 케이블 자체(내부 단선), 케이블이 드라이브에 연결되는 포트, 마더보드 또는 도터 카드의 포트를 의미할 수 있지만 이에 국한되지는 않습니다. , 마더보드나 보조 카드의 컨트롤러 칩, 심지어 소프트웨어 오류(어딘가)일 수도 있습니다.

실화: 한때 RAID 미러가 불안정해서 아무 이유 없이 드라이브를 떨어뜨린 적이 있었습니다. 드라이브는 문제 없이 점검되었고 플래터는 깨끗했으며(SMART 패스를 반복해도 아무 것도 나오지 않음) 모든 것이 잘 작동했습니다. 다시 벗겨질 때까지 계속해서 그랬습니다. 3달러짜리 SATA 케이블을 교체했는데 문제가 발생했습니다.곧떠났다. 이야기의 교훈: 잘못될 수 있는 일이 많이 있으며, 데이터 경로의 모든 구성 요소를 확인하지 않으면 항상 "모든 것이 괜찮다"고 가정할 수는 없습니다.

이메일로 알림을 받지 못한 이유는 무엇입니까?

이메일 알림은 (a) 어레이를 적극적으로 모니터링하거나 (b) 어레이를 조사할 때만 발생합니다.

내 조언은: mdadm이 드라이브 배열을 프로세스로 적극적으로 모니터링하도록 해야 한다는 것입니다. 이는 다음과 유사하지만 정확히 같지는 않은 방법으로 수행할 수 있습니다.

mdadm --monitor --scan --syslog

특정 설치에 맞게 위 줄을 조정해야 합니다.

시스템을 정지하기 전에 오류가 syslog에 제대로 기록되지 않은 이유는 무엇입니까? 시스템이 syslog에 로그인을 시도했지만 syslog 데몬을 중지한 후에 로그인했을 수 있습니까? 그렇다면 이를 방지하려면 어떻게 해야 할까요?

로깅이 중단되는 원인이 되는 다양한 문제가 있을 수 있습니다.

첫째, syslog가 일반적으로 작동하는 방식에 대한 전체적인 문제가 있습니다. 강력하고 안정적으로 만드는 데 수년이 걸렸지만 데이터가 디스크에 저장되지 않는 특정한 경우가 있습니다. 이는 잘 알려진 설계 문제이며 감독 스타일의 서비스 관리(daemontools 및 그와 유사한 제품이라고도 함)를 통해 적극적으로 해결된 문제입니다. 해결책은 syslog를 완전히 우회하고 항상 열려 있는 파일 설명자가 있는 로거에 출력을 기록하여 아무것도 삭제되지 않고 로거가 가능한 한 빨리 출력을 디스크에 덤프하는 것이었습니다. 100% 효과적인 솔루션은 아니지만 커널 패닉이 발생하거나 종료되기 전에 이벤트가 드라이브에 기록될 확률이 크게 향상됩니다.

둘째, 커널에 완전한 패닉이 발생했거나 시스템을 궁지로 몰아넣는 다른 이벤트가 발생했을 가능성이 있습니다. 하드웨어에 결함이 있어도 문제가 발생할 수 있습니다. 전원이 부족한 PSU를 사용하는 컴퓨터에서 Windows 8이 갑자기 종료되는 것을 본 적이 있습니다. PSU를 교체하면 종료 문제가 영구적으로 해결되었습니다. 확실히,아무것도 아님커널이 할 수 있는 일은 방금 "이건 질렸다"고 결정하고 재부팅을 시작하는 머신을 보호하는 것입니다.

무슨 일이 일어났는지 알아보려면 어떻게 해야 하나요? 또는 지금 무슨 일이 일어났는지 알아낼 방법이 없다면 다음 번에 더 나은 사후 분석을 수행할 수 있도록 로깅 및 알림을 어떻게 개선할 수 있습니까?

몇 가지 접근 방식이 있습니다.

  • 별도의 파티션에 로깅을 배치합니다. 이것이 로그를 그대로 얻는다는 보장은 아니지만 디스크가 가득 차서 쓸 수 없음, 읽기 전용으로 다시 마운트하게 만드는 손상 등과 같은 파일 시스템 문제를 격리하는 데 도움이 됩니다. 그런 경우에는 확실히 도움이 됩니다. 특정 사례.

  • 원격 로깅 필수 시스템 정보를 살펴보세요. 다시 말하지만 이것이 보장되는 것은 아니지만 재부팅이 발생하기 전에 마지막 패킷이 "밖으로 나갈 수" 있고 해당 패킷이 재부팅이 발생한 이유에 대한 중요한 단서를 갖고 있다면 도움이 될 것입니다.

  • 구체적이고 중요한 서비스의 경우 syslog에 대한 출력을 전용 로거가 출력을 가로채서 가능한 한 빨리 디스크에 기록하는 감독 스타일 로깅과 같은 다른 것으로 바꾸는 방법을 살펴보십시오. 이는 저장 장치로 전달되는 출력의 신뢰성을 높입니다. 약간의 작업만 하면 다른 서비스 관리 계획과 나란히 공존할 수 있습니다.

답변2

디스크가 갑자기 동기화되지 않는 원인은 무엇입니까?

드라이브 오류, 컨트롤러 오류, 기타 하드웨어 오류. 일부 모호한 소프트웨어 문제.

이메일로 알림을 받지 못한 이유는 무엇입니까?

/etc/cron.d/mdadmUbuntu에는 하루에 한 번 00:57에 RAID 볼륨을 확인하는 cronjob이 있습니다 . 당시 시스템에 문제가 없었거나 이미 장애가 발생한 경우에는 메시지를 보낼 방법이 없었습니다.

시스템을 정지하기 전에 오류가 syslog에 제대로 기록되지 않은 이유는 무엇입니까?

글쎄요, 드라이브에 오류가 발생하는 경우 추가로 쓰기를 하면 남은 내용이 모두 삭제될 수 있으므로 드라이브에 쓰기를 시도하는 것은 실제로 의미가 없습니다. 오류의 정확한 성격을 알지 못하면 볼륨이나 파일 시스템이 읽기 전용으로 전환되었을 수 있습니다. 기본적으로 Ubuntu는 루트 볼륨에 오류가 있는 경우 읽기 전용 파일 시스템으로 전환하도록 설정되어 있습니다.

다음에 더 나은 사후 분석을 수행할 수 있도록 로깅 및 알림을 어떻게 개선할 수 있습니까?

원격 syslog 호스트에 대한 로깅을 설정합니다. 이렇게 하면 저장소 오류가 아무것도 기록될 수 없다는 의미는 아닙니다.

관련 정보