내 경력 중 여러 번 다양한 환경(예: CentOS/Debian 박스, Synology/QNAP NAS)에서 mdadm RAID 세트(RAID1+0, 5, 6 등)를 발견했는데, 이는 단순히 장애가 발생한 디스크를 처리할 수 없는 것처럼 보입니다. 이는 완전히 죽은 디스크는 아니지만 수만 개의 불량 섹터가 있고 I/O를 처리할 수 없는 디스크입니다. 하지만 완전히 죽은 것은 아니며 여전히 작동하고 있습니다. 커널 로그는 일반적으로 UNC 오류로 가득 차 있습니다.
때때로 SMART는 디스크에 오류가 있는 것으로 식별하지만, 다른 경우에는 느린 I/O 외에 다른 증상이 없습니다.
느린 I/O로 인해 실제로 전체 시스템이 정지됩니다. SSH를 통해 연결하는 데 시간이 오래 걸리고 webGUI(NAS인 경우)는 일반적으로 작동을 멈춥니다. SSH를 통해 명령을 실행하는 데에도 시간이 오래 걸립니다. 이는 어레이에서 디스크의 연결을 끊거나 의도적으로 "실패"할 때까지 모든 것이 "정상"으로 돌아갑니다. 이는 성능이 저하된 어레이에서 가능한 한 정상적인 것입니다.
디스크를 읽고 쓰는 데 너무 오랜 시간이 걸리면 그냥 어레이에서 꺼내어 로그에 메시지를 추가하고 계속 진행하는 것이 어떨까요? 하나의 디스크가 좀 이상해서 RAID 사용의 주요 이점 중 하나(내결함성 - 디스크에 오류가 발생해도 계속 실행되는 기능)가 완전히 무효화되기 때문에 전체 시스템이 정지되는 것처럼 보입니다. 단일 디스크 시나리오(예: 시스템에 단일 SATA 디스크가 연결되어 있고 읽기/쓰기를 제대로 실행할 수 없음)에서는 이것이 재앙이지만 RAID 세트(특히 내결함성 "개성")에서는 이것이 재앙이라는 것을 이해합니다. 짜증날 뿐만 아니라 상식에도 어긋나는 것 같습니다.
mdadm의 기본 동작이 누군가가 원격으로 접속하여 수동으로 고칠 때까지 기본적으로 상자를 손상시키는 것인 아주 좋은 이유가 있습니까?
답변1
일반적으로 A의 목적은RAID, 선택한 Raid 레벨에 따라 주요 목표 간에 서로 다른 균형을 제공합니다. 데이터 중복, 유효성, 성능그리고용량.
특정 요구 사항을 기반으로 하는 것은저장소 소유자의 책임다양한 요소의 균형이 주어진 목적에 적합한지 결정하고,믿을 수 있는해결책.
선택한 Raid 솔루션(여기서는 소프트웨어에 대해 설명 mdadm)의 임무는 무엇보다도 데이터 보호를 보장하는 것입니다. 이를 염두에 두고 데이터 무결성보다 비즈니스 연속성에 더 높은 비중을 두는 것이 RAID 솔루션의 역할이 아니라는 것이 분명해졌습니다.
즉, mdadm의 임무는 실패한 공격을 피하는 것입니다. "이상하게 행동하는 디스크"가 완전히 깨지지 않는 한, 여전히 공격대에 기여합니다.
그렇다면 이상하게 동작하는 디스크를 어레이에서 제거하고 로그에 메시지를 추가한 후 계속 진행하면 어떨까요?그렇게 하면 데이터가 손실될 위험이 높아지기 때문입니다.
내 말은, 당신 말이 맞습니다. 주어진 순간에는 비즈니스 관점에서 계속하는 것이 더 나은 솔루션인 것 같습니다. 그러나 실제로는 로그에 삭제된 메시지가 감지되지 않은 채 남아 있을 수 있으므로 공격대의 저하된 상태는 감지되지 않은 채 남아 있습니다. 얼마 후 결국 동일한 RAID의 다른 디스크에 오류가 발생하고 그 결과 실패한 RAID에 저장된 데이터가 결국 사라집니다.
게다가 "이상하게 동작하는 디스크"가 무엇인지 정확히 정의하기는 어렵습니다. 다른 방식으로 표현하면, 디스크 어레이 내에서 작동되는 단일 디스크의 허용 가능한 작동 동작은 무엇입니까?
우리 중 일부는 "디스크에 일부 오류가 표시됩니다"라고 대답할 수 있습니다. 다른 사람들은 "오류가 수정될 수 있는 한 모든 것이 괜찮습니다"라고 대답할 수 있습니다. 다른 사람들은 "디스크가 주어진 시간에 모든 명령에 응답하는 한 모든 것이 괜찮습니다"라고 대답할 수 있습니다. 다른 사람들은 "동일 어레이 내의 모든 디스크의 평균 온도와 비교하여 디스크 온도가 5°C 이상 차이가 나는 경우"라고 말합니다. 또 다른 대답은 "스크럽에서 오류가 표시되지 않는 한" 또는 "SMART가 오류를 표시하지 않는 한"일 수 있습니다.
쓰여진 내용은 길지도 않고 완전한 목록도 아닙니다.
요점은 "허용되는 디스크 동작"의 정의는 해석의 문제이므로 저장소 소유자의 책임이기도 하며 mdadm이 자체적으로 결정해야 하는 것이 아니라는 것입니다.
답변2
중요한 문제는 오류가 발생한 SATA 디스크 드라이브로 인해 내부 오류 복구 절차가 진행되는 동안 전체 버스가 때때로 정지될 수 있다는 것입니다. 이러한 이유로 다음을 사용해야 합니다.TLER 지원RAID 어레이(그리고 엔터프라이즈급 모델이 바람직함)에서만 드라이브합니다.
SAS 드라이브는 이 문제의 영향을 덜 받지만 완전히 자유롭지는 않습니다.
답변3
말씀드린 것 외에도 한 푼도 추가하고 싶지만 이것은 중요한 고려 사항입니다.
무엇드라이브섹터를 읽는 속도가 느린 경우는 무엇입니까?
단독으로 작동하도록 설계된 드라이브(예: 일반적인 "데스크탑" 드라이브)는 해당 불량 섹터에 저장된 데이터를 검색할 수 있는 다른 방법이 없다고 가정합니다. 그들은 어떤 희생을 치르더라도 데이터를 검색하려고 시도하며 오랜 시간 동안 반복해서 반복합니다. 물론 해당 섹터를 실패로 표시하므로 다음에 쓸 때 다시 매핑할 것이지만 이에 대해서는 작성해야 합니다. 다시 쓸 때까지 그 부분을 읽을 때마다 질식할 것입니다. RAID 설정에서 이는 RAID의 경우 드라이브가 여전히 작동하고 이를 쫓아낼 이유가 없다는 것을 의미하지만, 응용 프로그램의 경우 어레이가 크롤링 속도로 느려집니다.
반면에 "엔터프라이즈" 드라이브, 특히 "브랜드" 드라이브는 항상 RAID 설정에 사용된다고 가정하는 경우가 많습니다. "브랜드" 드라이브를 보는 "브랜드" 컨트롤러는 실제로통지하다RAID 존재 여부에 대한 펌웨어입니다. 따라서 여러 번 더 시도하여 해당 섹터를 읽을 수 있더라도 드라이브가 일찍 중지되고 I/O 오류를 보고합니다. 그런 다음 컨트롤러는 읽기 명령을 형제 드라이브에 미러링하여 더 빠르게 응답할 수 있습니다(그리고 잘못된 드라이브를 어레이에서 추방). 드라이브를 꺼내서 철저하게 탐색/테스트하면 뚜렷한 문제가 발견되지 않습니다. 컨트롤러 로직에 따르면 드라이브가 잠시 느려졌을 뿐이고 사용을 중단하기에 충분했습니다.
나는 이것이 아마도유일한"데스크탑" 드라이브와 "브랜드"/"엔터프라이즈" NL-SAS 및 SATA 드라이브의 차이점. 이것이 아마도 "Toshiba" 브랜드 드라이브를 구입하는 것에 비해 실제로 Toshiba에서 만든 "HPE" 드라이브를 구입할 때 3배 더 많은 비용을 지불하는 이유일 것입니다.
그러나 일부 드라이브는 이에 대한 몇 가지 일반적인 제어를 지원합니다. 이를 SCT ERC라고 합니다.SMART 명령 전송 오류 복구 제어. 이것이 어떻게 보이는지입니다 smartctl:
지원되지 않는
# smartctl --all /dev/sda
=== START OF READ SMART DATA SECTION ===
SCT capabilities: (0x3037) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
지원됨
=== START OF READ SMART DATA SECTION ===
...
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
운이 좋으면 로 이 기능을 제어할 수 있습니다 smartctl. 다시 읽기를 시도하는 데 걸리는 시간과 다시 쓰기를 시도하는 데 걸리는 시간 등 두 가지 시간 제한을 검색하거나 설정할 수 있습니다.
# smartctl -l scterc /dev/sda
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
# smartctl -l scterc /dev/sde
SCT Error Recovery Control:
Read: Disabled
Write: Disabled
# smartctl -l scterc /dev/sdd
Warning: device does not support SCT Error Recovery Control command
smartctl -l scterc,120,60 /dev/sde
즉, 읽기를 다시 시도하는 데 1/120초가 걸립니다. 쓰기를 재시도하는 데 60분의 1초가 소요됩니다. 0은 "죽을 때까지 재시도"를 의미합니다. 드라이브마다 이에 대한 기본 설정이 다릅니다.
따라서 "RAID 에디션" 드라이브만 사용하는 경우 ERC 시간 초과를 0으로 설정하는 것이 좋습니다. 그렇지 않으면 데이터가 손실될 수 있습니다. 반면에 RAID에서 드라이브를 사용하는 경우 0이 아닌 합리적인 낮은 설정을 설정하는 것이 좋습니다.
PS 그리고 SAS에 대한 참고사항입니다. 를 사용하면 sdparm이에 대한 더 많은 제어를 지원합니다.
답변4
디스크가 작동하지 않지만 어떤 방식으로든 컨트롤러를 꺼낸 상황이 있었습니다.
역사적으로 이는 마스터 드라이브와 슬레이브 드라이브가 동일한 케이블에 있고 하나의 드라이브에 장애가 발생하면 여전히 양호한 다른 드라이브에 대한 액세스를 방해할 수 있는 PATA를 통해 가능했습니다. 불량 드라이브를 제거하면 나머지 드라이브에 다시 액세스할 수 있거나 전원을 껐다 켜야 할 수도 있지만 RAID 성능이 저하되어 복구가 시작될 수 있습니다.
SATA는 이에 덜 취약하지만 컨트롤러가 영향을 받을 가능성은 여전히 있습니다. 소프트웨어 공격에 대한 내 경험으로 볼 때 더 멋진 전용 공격 컨트롤러에 의해 숨겨져 있을 피투성이의 내부가 더 많이 노출되었습니다.
SAS나 NVME에서는 이런 경험을 해본 적이 없지만 SAS는 내부적으로 더 많은 디스크 처리 기능을 갖춘 하드웨어 RAID 컨트롤러를 의미하는 경우가 많습니다.