캐시 보호 기능이없는 RAID 1-ZMCP / 백업 배터리

Adaptec 6405에서 RAID 1을 실행하고 있습니다. 캐시 보호 기능을 제공하기 위해 카드에 ZMCP를 설치해야하는지 결정하려고합니다. Adaptec의 ZMCP는 캐시에 대한 BBU-배터리 백업과 동일합니다.

시스템이 제대로 작동하도록 컨트롤러 BIOS에서 쓰기 캐싱을 활성화했습니다.

스트리핑에 필요한 캐시 보호를 이해할 수 있습니다. 그러나 미러링에 필요합니까?

캐시 보호 (BBU 또는 Adaptec의 ZMCP)없이 RAID 1을 실행하는 위험이 일반적인 SATA 컨트롤러로 시스템을 실행하는 것보다 더 큰가?

AFM 600 도터 보드와 함께 Adaptec 6405를 사용하는 사람이 있다면 AFM 600이 카드 측면에서 튀어 나오는지, 얼마나되는지 알려줄 수 있습니까?

마더 보드에는 Adaptec 6405 카드에 맞는 PCI Gen2 슬롯이 하나만 있으며이 슬롯에서 ZMCP가가는 쪽은 케이스 측면에서 불과 1 센티미터 정도입니다.

캐시 보호는 디스크에 기록되기 전에 컨트롤러 캐시에있는 것을 보호하기위한 것입니다. 따라서 어레이에서 쓰기 캐시를 활성화 한 경우 데이터는 컨트롤러의 DDR 메모리에 기록됩니다. 그런 다음 디스크가 사용 중이 아닌 경우 디스크에 기록됩니다. 이 원칙은 어떤 RAID 수준을 사용하든 관계없이 유지됩니다. 따라서 OS가 디스크에 기록한 데이터를 보호하려고하지만 컨트롤러가 아직 디스크에 실제로 기록하지 않은 경우 캐시 보호가 필요합니다. BTW : 쓰기 캐시없이 회전 디스크를 실행하는 것은 젖은 주만큼 느립니다. 엔

스트리핑에 필요한 캐시 보호를 이해할 수 있습니다. 그러나 미러링에 필요합니까?

기술적으로도 필요하지 않습니다. 성능과 위험을 증가시킵니다. 100 % 확신하고 싶다면 다음을 수행하십시오.

1. RAID 카드에서 쓰기 캐싱을 사용하거나 BBU / flashbackups / ZMCP를 사용하지 마십시오.
2. 드라이브 자체에서 쓰기 캐싱을 해제하십시오.

그러나 RAID는 100 % 안전하지 않습니다. RAID는 두 가지 가능성이 있습니다.

1. 디스크가 고장 나더라도 데이터를 그대로 유지하고 액세스 할 수 있습니다. (적어도 긴급 유지 보수를 수행 할 수있을 때까지 (예 : 업무 시간 직후)).
2. 때로는 성능이 향상되는 경우가 있습니다 (예 : 스트라이프 또는 RAID10, 50, 60, ... RAID5 / 6에서 읽기).

요약하면 : 아니요, 미러가 필요 하지 않습니다 .

캐시 보호 (BBU 또는 Adaptec의 ZMCP)없이 RAID 1을 실행하는 위험이 일반적인 SATA 컨트롤러로 시스템을 실행하는 것보다 더 큰가?

아니. 나는 그것이 거의 같다고 생각합니다.
(RAID 카드의 고장 위험을 배제합니다).

쓰기 캐시는 OS와 디스크가 쓰기 작업을 통합하고 캐시하는 데 사용 하는 휘발성 메모리 (일반적으로 RAM)입니다. 일반적으로 캐시에있는 모든 내용은 아직 디스크에 기록되지 않았습니다. 이 캐시의 전원이 꺼지면 내용 이 손실 되고 확장하면 일부 데이터가 손실됩니다.

컨트롤러에 백업 배터리가있는 경우 다음 부팅 때까지 정전이 발생한 경우 쓰기 캐시가 유지 된 다음 디스크에 기록됩니다. RAID 레벨은 이와 관련이 없습니다.

백업 배터리가 없으면 여전히 캐시에 있던 데이터 덩어리가 손실됩니다. 파일 시스템이나 RAID 모두 캐시에 무엇이 있는지 정확히 알지 못하므로 데이터를 잃게됩니다. 이는 RAID1 또는 RAID5에서도 모든 RAID 레벨에서 발생하는 문제입니다. 이 문제는보다 일반적으로 RAID 쓰기 구멍이라고 합니다.

한마디로 : 쓰기 캐시를 사용하는 경우 해당 캐시에 대한 백업 배터리가 필요합니다. 쓰기 캐시를 사용하지 않으면 사용하지 않습니다. RAID 수준은 관련이 없습니다.

RAID1에서 전원이 꺼지고 쓰기 캐시의 일부 데이터가 한 하드 드라이브에 기록되었지만 다른 하드 드라이브에는 기록되지 않은 경우 드라이브는 일부 블록에 대해 데이터가 일치하지 않습니다. 어떤 정확한 RAID 시스템을 사용 하느냐에 따라 시스템이 두 드라이브 간의 읽기 균형을 맞출 수 있다고 생각합니다. 시스템이 더티 종료 후 데이터를 판독기로 반환하기 전에 어레이를 "스크럽"하지 않으면 후속 읽기에서 동일한 블록에 대해 다른 데이터를 반환 할 수 있습니다. 즉, 파일을 읽고 한 디스크에서 데이터를보고, 읽기 캐시를 플러시 한 다음 동일한 파일을 다시 읽고 다른 디스크에서 다른 데이터를 가져올 수 있습니다.

재부팅 후 Linux의 MD (소프트웨어 RAID)를 보았을 때 자동으로 스크럽을 실행하는 것으로 보이며 실제로 각 블록이 스크러빙되었음을 확인할 때까지 특정 블록을 반환하지 않는 것으로 생각합니다. 그러나 그것이 실제로하고 있는지 확실하지 않습니다. 또한 하드웨어 RAID 컨트롤러가이 상황을 처리하는 방법을 모르겠습니다.

이 제거가 발생하더라도 쓰기 캐시가 각 디스크에 대한 쓰기 순서를 유지하지 않으면 파일 시스템이 저널링 되더라도 손상 될 수 있습니다. 필자가 언급 한 쓰기 캐시는 실제로 완료되는 쓰기에 대해 OS에 있다고 가정합니다. 즉, 파일 시스템이 지속성에 대해 가정하는 것은 의도적으로 성능상의 이유로 위반되고 있음을 의미합니다. 배터리 백업은 파일 시스템이 실제로 완료되었다고 생각하는 쓰기가 실제로 어레이가 재 조립 될 때 파일 시스템이 작성되었다고 생각한 데이터를 읽을 때 반환하는 방식으로 완료되도록하기위한 것 같습니다.

죄송합니다. 답변이 없습니다.이 시나리오에서 걱정할만한 우려 / 질문을 제기합니다.