전주곡:
저는 소규모 회사에서 SysAdmin 업무를 점점 더 많이 맡고 있는 코드 원숭이입니다. 내 코드는 우리의 제품이며 점점 더 SaaS와 동일한 앱을 제공하고 있습니다.
약 18개월 전에 저는 프리미엄 호스팅 중심 공급업체에서 Tier IV 데이터 센터의 베어본 랙 푸셔로 서버를 옮겼습니다. (문자 그대로 길 건너편입니다.) 네트워킹, 저장, 모니터링 등 훨씬 더 많은 일을 직접 수행하고 있습니다.
큰 움직임의 일환으로 호스팅 회사에서 임대한 직접 연결 스토리지를 교체하기 위해 저는 SuperMicro 섀시, 3ware RAID 카드, Ubuntu 10.04, 24개의 SATA 디스크, DRBD 및 . 세 가지 블로그 게시물에 모두 친절하게 설명되어 있습니다.새로운 9TB SATA RAID10 NFSv4 NAS 구축 및 테스트:1부,2부그리고3부.
우리는 또한 Cacti 모니터링 시스템을 설정했습니다. 최근 우리는 SMART 값과 같은 데이터 포인트를 점점 더 많이 추가하고 있습니다.
이 모든 일을 이 일이 없었다면 할 수 없었을 것입니다.엄청난 보핀 ~에 서버 오류. 재미있고 교육적인 경험이었습니다. 우리 상사는 행복해요(우리는 $$$의 버킷 로드를 절약했습니다), 우리 고객은 행복합니다(스토리지 비용이 절감됩니다), 나는 행복하다(재미있어요, 재밌어요, 재밌어요).
어제까지.
중단 및 복구:
점심 식사 후 얼마 지나지 않아 우리는 주문형 스트리밍 미디어 CMS 애플리케이션에서 성능 저하에 대한 보고를 받기 시작했습니다. 거의 동시에 Cacti 모니터링 시스템에서 엄청난 양의 이메일을 보냈습니다. 가장 확실한 경고 중 하나는 iostat 대기 그래프였습니다.
성능이 너무 저하되어 Pingdom이 "서버 다운" 알림을 보내기 시작했습니다. 전체 로드는 보통이었고 트래픽 급증은 없었습니다.
NAS의 NFS 클라이언트인 애플리케이션 서버에 로그인한 후 거의 모든 항목에서 매우 간헐적이고 엄청나게 긴 IO 대기 시간이 발생하고 있음을 확인했습니다. 그리고 기본 NAS 노드 자체로 이동한 후 문제 어레이의 파일 시스템을 탐색하려고 할 때 동일한 지연이 나타났습니다.
장애 조치를 취할 시간입니다. 잘 진행되었습니다. 20분 이내에 모든 것이 완벽하게 백업되어 실행되는 것으로 확인되었습니다.
검시:
모든 시스템 오류가 발생한 후에는 사후 분석을 수행하여 오류의 원인을 파악합니다. 내가 한 첫 번째 일은 SSH를 통해 다시 상자로 돌아가서 로그 검토를 시작하는 것이었습니다. 완전히 오프라인이었습니다. 데이터 센터로 이동할 시간입니다. 하드웨어 재설정, 백업 및 실행 중입니다.
나는 /var/syslog다음과 같은 무서운 항목을 발견했습니다.
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1 Short offline Completed: read failure 90% 6576 3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2 Short offline Completed: read failure 90% 6087 3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3 Short offline Completed: read failure 10% 5901 656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4 Short offline Completed: read failure 90% 5818 651637856
Nov 15 06:49:45 umbilo smartd[2827]:
그래서 어레이의 디스크에 대한 Cacti 그래프를 확인하러갔습니다. 여기서 우리는 syslog에서 말하는 것처럼 디스크 7이 사라지고 있음을 알 수 있습니다. 그러나 디스크 8의 SMART 읽기 오류가 변동하고 있음도 알 수 있습니다.
syslog에는 디스크 8에 대한 메시지가 없습니다. 더 흥미로운 점은디스크 8의 변동하는 값은 높은 IO 대기 시간과 직접적인 관련이 있습니다! 내 해석은 이렇습니다.
- 디스크 8에 간헐적으로 긴 작동 시간을 초래하는 이상한 하드웨어 오류가 발생했습니다.
- 어떻게든 디스크의 이 결함 상태가 전체 어레이를 잠그고 있습니다.
더 정확하거나 정확한 설명이 있을 수 있지만 결과적으로 하나의 디스크가 전체 어레이의 성능에 영향을 미치는 것으로 나타났습니다.
질문
- 하드웨어 SATA RAID-10 어레이의 단일 디스크가 어떻게 전체 어레이를 갑자기 정지시킬 수 있습니까?
- RAID 카드가 이 문제를 처리해야 한다고 생각하는 것이 순진한 생각인가요?
- 오작동하는 단일 디스크가 전체 어레이에 영향을 미치는 것을 어떻게 방지할 수 있습니까?
- 뭔가 빠졌나요?
답변1
중요한 프로덕션 환경에서는 "SATA를 사용하지 마십시오"라고 말하기는 싫지만 이런 상황을 자주 목격했습니다. SATA 드라이브는 일반적으로 귀하가 설명하는 듀티 사이클에 적합하지 않습니다.24x7 작동에 특화된 드라이브귀하의 설정에서. 내 경험에 따르면 SATA 드라이브는 예측할 수 없는 방식으로 오류가 발생할 수 있으며, 이전처럼 RAID 1+0을 사용하는 경우에도 종종 전체 스토리지 배열에 영향을 미칠 수 있습니다. 때때로 전체 버스를 멈출 수 있는 방식으로 드라이브가 실패합니다. 한 가지 주목할 점은 설정에서 SAS 확장기를 사용하고 있는지 여부입니다. 이는 나머지 디스크가 드라이브 오류로 인해 영향을 받는 방식에 차이를 만들 수 있습니다.
하지만 함께 가는 것이 더 합리적이었을 수도 있습니다.미드라인/니어라인(7200RPM) SAS 드라이브대 SATA. SATA에 비해 약간의 가격 프리미엄이 있지만 드라이브는 더 예측 가능하게 작동/고장됩니다. SAS 인터페이스/프로토콜의 오류 수정 및 보고 기능은 SATA 세트보다 더 강력합니다. 그래서 드라이브를 사용해도메카닉이 똑같은 사람, SAS 프로토콜의 차이로 인해 드라이브 오류 시 경험했던 고통이 방지되었을 수 있습니다.
답변2
단일 디스크가 어떻게 어레이를 다운시킬 수 있습니까? 대답은 그렇지 않아야 한다는 것입니다. 그러나 중단의 원인이 무엇인지에 따라 다릅니다. 디스크가 정상적인 방식으로 작동하지 않는다면 디스크를 내려서는 안 됩니다. 그러나 컨트롤러가 처리할 수 없는 "극단적인 경우" 방식으로 실패할 가능성이 있습니다.
이런 일이 일어나서는 안 된다고 생각하는 게 순진한 겁니까? 아니요, 그렇게 생각하지 않습니다. 이와 같은 하드웨어 RAID 카드는 대부분의 문제를 처리했어야 합니다.
그것을 방지하는 방법? 이와 같은 이상한 극단적인 경우는 예상할 수 없습니다. 이는 시스템 관리자의 일부입니다. 하지만 비즈니스에 영향을 미치지 않도록 복구 절차를 수행할 수 있습니다. 지금 이 문제를 해결하는 유일한 방법은 다른 하드웨어 카드를 사용하거나(아마도 원하는 작업이 아닐 수도 있음) 드라이브를 SATA 대신 SAS 드라이브로 변경하여 SAS가 더 강력한지 확인하는 것입니다. 또한 RAID 카드 공급업체에 연락하여 무슨 일이 일어났는지 알려주고 그들이 말하는 내용을 확인할 수도 있습니다. 결국 그들은 불안정한 드라이브 전자 장치의 모든 것을 전문적으로 아는 회사입니다. 적절한 사람과 대화할 수 있다면 드라이브 작동 방식과 안정성에 대한 더 많은 기술적 조언을 얻을 수 있습니다.
뭔가 놓친 게 있나요? 드라이브에 극단적인 오류가 발생했는지 확인하려면 어레이에서 드라이브를 꺼내십시오. 어레이 성능이 저하되지만 (성능 저하된 어레이 상태를 제외하고) 이상한 속도 저하 및 오류가 더 이상 있어서는 안 됩니다. 지금은 제대로 작동하는 것 같지만 디스크 읽기 오류가 있는 경우 가능한 한 드라이브를 교체해야 한다고 말씀하신 것입니다. 고용량 드라이브에는 때때로 다른 드라이브에 장애가 발생할 때까지 표시되지 않는 URE 오류(RAID 5를 실행하지 않는 가장 좋은 이유, 참고 사항)가 있을 수 있습니다. 그리고 해당 드라이브에서 극단적인 동작이 발생하는 경우 손상된 데이터가 어레이의 다른 드라이브로 마이그레이션되는 것을 원하지 않습니다.
답변3
저는 전문가는 아니지만 RAID 컨트롤러와 스토리지 어레이에 대한 경험을 바탕으로 어둠 속에서 거친 촬영을 해보겠습니다.
디스크는 다양한 방식으로 실패합니다. 불행하게도 디스크는 성능에 심각한 영향을 주지만 RAID 컨트롤러는 오류로 간주하지 않는 방식으로 오류가 발생하거나 결함이 있을 수 있습니다.
디스크에 명백한 오류가 발생하는 경우 모든 RAID 컨트롤러 소프트웨어는 디스크의 응답 부족을 감지하고 풀에서 디스크를 제거하고 알림을 보내는 데 능숙해야 합니다. 그러나 여기서 무슨 일이 일어나고 있는지에 대한 내 추측은 디스크가 어떤 이유로 컨트롤러 측에서 오류를 유발하지 않는 비정상적인 오류를 겪고 있다는 것입니다. 따라서 컨트롤러가 영향을 받은 디스크에서 쓰기 플러시 또는 읽기를 수행할 때 다시 돌아오는 데 오랜 시간이 걸리고 결과적으로 전체 IO 작동이 중단되어 어레이가 중단됩니다. 어떤 이유로든 RAID 컨트롤러가 "아, 디스크 오류"가 발생하는 것만으로는 충분하지 않습니다. 아마도 데이터가 결국 다시 돌아오기 때문일 것입니다.
내 조언은 고장난 디스크를 즉시 교체하는 것입니다. 그 후, 귀하의 RAID 카드 구성을 살펴보고(3ware입니다. 꽤 좋다고 생각했습니다) 고장난 디스크가 무엇인지 알아봅니다.
추신: SMART를 선인장으로 가져오는 좋은 아이디어입니다.
답변4
어둠 속에서의 내 샷 :
드라이브 7에 오류가 발생했습니다. 사용할 수 없는 실패 창이 있습니다.
드라이브 8에도 '가벼운' 오류가 있습니다. 재시도해서 수정했습니다.
RAID10은 일반적으로 "여러 RAID1 쌍의 RAID0"입니다. 드라이브 7과 8은 동일한 쌍의 구성원입니까?
그렇다면 동일한 쌍에서 두 개의 디스크 오류가 발생하는 "일어나서는 안 되는" 사례에 도달한 것 같습니다. RAID10을 죽일 수 있는 거의 유일한 것입니다. 안타깝게도 모든 드라이브가 동일한 배송 로트에서 나온 경우 이런 일이 발생할 수 있으므로 동시에 수명이 다할 가능성이 약간 더 높습니다.
드라이브 7에 오류가 발생하는 동안 컨트롤러는 모든 읽기를 드라이브 8로 리디렉션했기 때문에 오류 재시도가 발생하면 엄청난 지연이 발생하여 작업이 눈에 띄게 중단되어 잠시 동안 성능이 저하되었습니다.
8번 드라이브가 아직 죽지 않은 것 같아 다행입니다. 따라서 데이터 손실 없이 문제를 해결할 수 있을 것입니다.
두 드라이브를 모두 변경하는 것부터 시작하고 케이블 연결을 확인하는 것을 잊지 마십시오. 느슨한 연결로 인해 이 문제가 발생할 수 있으며, 단단히 연결되지 않은 경우 인접한 드라이브에서 발생할 가능성이 더 높습니다. 또한 일부 멀티포트 카드에는 여러 개의 2포트 커넥터가 있습니다. 드라이브 7과 드라이브 8이 동일한 드라이브에 있는 경우 문제의 원인이 될 수 있습니다.