쓰기 캐싱을 올바르게 처리하는 SATA 디스크?

데이터베이스에 사용되는 개별 디스크에서 쓰기 캐시를 비활성화하는 조언을 보는 것이 일반적입니다. 그렇지 않으면 일부 디스크는 아직 디스크 표면에 기록하지 않은 쓰기를 승인하기 때문입니다.

이것은 디스크가 디스크 표면에 기록 될 때까지 일부 디스크가 쓰기를 승인하지 않음을 의미합니다 (업데이트 : 또는 캐시를 플러시하라는 요청이있을 때 정확하게보고합니다. 이러한 디스크를 찾을 수있는 곳 또는 신뢰할 수있는 정보를 찾을 수있는 곳은 어디입니까? 그런 디스크를 어디에서 찾을 수 있습니까?

쓰기 캐시를 사용하면 실제로 이점이있는 일부 DB 서버를 설정하고 있지만 응용 프로그램은 가격에 민감하며 정보가 충분하지 않기 때문에 일부 캐싱 RAID 컨트롤러의 디스크 하위 시스템 비용을 두 배로 늘리지 않습니다. 각 드라이브에서 캐시를 신뢰할 수 있는지 알고 있습니다.

일반적으로, 귀하의 질문에 대한 직접적인 대답으로, 쓰기 캐싱이 활성화 된 올바른 드라이브와 관련하여 드라이브 자체에 버그가 있음을 나타내는 주요 SATA 드라이브 브랜드를 알지 못합니다. 즉, 드라이브 관점에서만 드라이브는 캐싱 관점에서 수행해야하는 작업을 수행합니다. 또한 쓰기 캐싱 이 활성화 된 경우에도 SATA 케이블의 디스크 쓰기에서 물리적으로 업데이트되는 회전 미디어로의 지연이 여전히 매우 짧습니다 (일반적으로 ~ 50 ~ 100ms). 더티 캐시 데이터가 한 번에 몇 초 동안 그대로있는 것과 같지 않습니다. 드라이브가 계속 캐시 에서 더티 데이터를 가져 오려고 합니다.가능한 빨리 물리적 매체에. 이는 데이터 안전 문제 일뿐 아니라 지연없이 향후 쓰기를 수용 할 준비가되어있는 것 중 하나입니다 (예 : 쓰기 게시).

캐싱이 활성화 될 때 발생하는 문제는 SATA 케이블을 통한 드라이브의 쓰기 순서와 회전하는 미디어의 쓰기 순서가 동일하지 않다는 것입니다. 캐시의 모든 내용이 디스크에 저장되기 전에 전원이 꺼 지거나 시스템이 충돌하지 않는 한 이로 인해 문제가 발생하지 않습니다. 왜? ->

여기서 발생할 수있는 문제는 파일 시스템 및 / 또는 데이터베이스 파일 내용의 트랜잭션 견고성과 순서가 잘못된 쓰기 손실과 관련이 있습니다. 실제로, 비 순차적 쓰기 손실이 발생하면 이론적으로 미디어에 대한 매우 특정한 순서로 발생하는 디스크 쓰기에 의해 보장되었던 트랜잭션 논리의 무결성을 이론적으로 손상시킬 수 있습니다.

물론, 파일 시스템, 데이터베이스, RAID 컨트롤러 등의 디자이너는 쓰기 캐싱과 관련하여이 현상을 알고 있거나 반드시 알고 있어야합니다. 쓰기 캐싱은 대부분의 임의 액세스 유형 I / O 시나리오의 성능 관점에서 매우 바람직합니다. 실제로 쓰기 캐싱을 사용할 수있게하는 것은 고급 기본 명령 큐 ( NCQ)는 최신 SATA 및 마지막 몇 세대의 PATA 구현에서 지원됩니다. 따라서, 이러한 특정 중요 시간에 물리 매체에 대한 순서를 보장하기 위해, 파일 시스템 및 / 또는 애플리케이션 등은 매체에 대한 쓰기 캐시의 플러시를 구체적으로 요청할 수있다. 이 동기화 요청이 완료되면 (잠재적으로) 파일 버퍼, OS 디스크 캐싱, 물리 디스크 캐싱 등에서 보류중인 모든 것이 올바른 중요 작업에서 트랜잭션 시스템 설계에 따라 실제로 미디어에 표시됩니다. 즉, 프로그래머가 맨 위에 올바른 전화를 걸고이 소프트웨어 및 하드웨어 계층의 모든 요소가 올바르게 작업 한 경우에 올바르게 발생합니다. 즉, 드라이브, RAID 컨트롤러, 디스크 드라이버, OS 캐시, 파일 시스템, 데이터베이스 엔진 등에는 이와 관련된 버그가 없습니다. 이것은 모두 정확하게 작동해야하는 많은 소프트웨어입니다. 또한 거의 모든 상황에서 일반적으로 쓰기 순서는 전혀 중요하지 않으며 정전 및 충돌 시나리오는 테스트하기 어려운 테스트이기 때문에 이와 관련하여 정확성을 확인하는 것은 매우 어렵습니다. 따라서 결국이 용어의 다양한 계층 및 / 또는 의미 중 하나 이상에서 "쓰기 캐싱 해제"는 특정 종류의 문제를 "고정"하는 것으로 유명합니다. 실제로, RAID 컨트롤러, OS 디스크 캐시 또는 드라이브 등의 쓰기 캐싱 동작을 종료하면 시스템 및 버그의 원인이되는 하나 이상의 버그가 발생하지 않습니다. 정전 및 충돌 시나리오는 테스트하기 어려운 테스트입니다. 따라서 결국이 용어의 다양한 계층 및 / 또는 의미 중 하나 이상에서 "쓰기 캐싱 해제"는 특정 종류의 문제를 "고정"하는 것으로 유명합니다. 실제로, RAID 컨트롤러, OS 디스크 캐시 또는 드라이브 등의 쓰기 캐싱 동작을 종료하면 시스템 및 버그의 원인이되는 하나 이상의 버그가 발생하지 않습니다. 정전 및 충돌 시나리오는 테스트하기 어려운 테스트입니다. 따라서 결국이 용어의 다양한 계층 및 / 또는 의미 중 하나 이상에서 "쓰기 캐싱 해제"는 특정 종류의 문제를 "고정"하는 것으로 유명합니다. 실제로, RAID 컨트롤러, OS 디스크 캐시 또는 드라이브 등의 쓰기 캐싱 동작을 종료하면 시스템 및 버그의 원인이되는 하나 이상의 버그가 발생하지 않습니다.

어쨌든, 문제의 핵심으로 돌아 가기 : SATA에서는 모든 디스크 읽기 / 쓰기 명령과 플러시 캐시 명령의 특정 처리가 SATA 사양에 의해 잘 정의되어 있습니다. 또한 드라이브 제조업체는 Seagate Barracuda 드라이브에 대한이 예와 같이 이러한 규칙의 구현 및 준수를 설명하는 각 드라이브 모델 또는 드라이브 제품군에 대한 자세한 문서를 가지고 있어야 합니다. 특히 SATA 세트 기능에 대한 자세한 내용을 참조하십시오드라이브 작동 모드를 제어하는 ​​명령과 특히 옵션 82h를 사용하면 드라이브 수준에서 디스크 캐싱을 비활성화 할 수 있습니다. 기본값은 내가 알고있는 모든 드라이브에서 쓰기 캐싱이 가능하기 때문입니다. 캐시를 실제로 비활성화하려면이 명령은 각 드라이브 재설정 또는 전원을 시작할 때 수행해야하며 일반적으로 운영 체제의 디스크 드라이버에서 제어합니다. OS 드라이버가 IOCTL 및 / 또는 레지스트리 설정 유형을 통해이 모드를 설정하도록 권장 할 수 있지만 이는 매우 다양합니다.

배터리 백업 캐싱 디스크 컨트롤러가 드라이브 내 캐시를 비활성화하는 경험이 있습니다. 그렇지 않으면 온 디스크 캐시를 비활성화하는 방법을 모르겠습니다. 온 디스크 캐시를 비활성화 할 수 있더라도 성능이 크게 저하됩니다.

저렴한 옵토 인의 경우 시스템을 순차적으로 종료하라는 신호를 줄 수있는 저렴한 UPS를 사용할 수 있습니다.

캐시를 유지하기 위해 배터리 대신 수퍼 커패시터 가 있는 RAID 시스템을 사용 합니다. 배터리 마모, 모니터링, 교체 및 이러한 점에서 잠재적 인 오류 지점을 나타내야합니다. 시동시 커패시터가 충전되고 UPS의 전원 공급이 중단 될 때 캐시가 플러시되고 사실상 영구적으로 지속되며 모니터링이 필요하지 않습니다. 그리고 고장시 시스템을 깨끗하게 종료시키는 소프트웨어-나는 보통 전원이 다시 켜질 때 종료하기 전에 5-15 분 (UPS 부하에 따라 배터리 사용 가능 여부에 따라 다름)을 제공합니다.

뇌우 중에는 때때로 전원이 꺼지기 직전에 표시등이 깜박이는 것을 볼 수 있습니다. 이것은 리 클로저 (recloser)라고하는 장치입니다. 과부하가 과도 상태 인 경우 트립 할 때 열린 스위치를 닫으려고 시도하는 회로 차단기입니다. 세 번의 시도 후에도 닫히지 않으면 열린 상태로 유지됩니다. 불쌍한 녀석은 빗속에서 나가서 처리해야합니다. 그에게 미안하지 말고, 당신과 내가하는 일을 두 번, 초과 근무하는 경우 두 번만하면 위험한 일입니다.

디스크 쓰기 캐시의 오해 중 하나는 정전시 데이터 만 손실된다는 것입니다. 특히 sATA 장치에서 항상 그런 것은 아닙니다. sATA 장치에 오류가있는 경우 (예 : 코너 케이스 FW 버그 또는 컨트롤러 버그) 외부에서 재설정 또는 재설정 된 경우, 정지 후에도 후기 입 캐시의 데이터를 계속 사용할 수 있다는 보장이 없습니다.

이로 인해 장치에 일시적 오류가 발생하고 재설정되고 더티 캐시 손실로 인해 데이터가 손실되는 시나리오가 발생할 수 있으며 이는 드라이버의 블록 레벨 이상으로 자동입니다.

더구나, OS 도구를 통해 드라이브 캐시를 비활성화하면 장치를 재설정 할 때 손실되기 때문에 장치가 시작시 캐시를 비활성화하더라도 장치를 재설정하면 후기 입 캐싱을 다시 활성화 할 수 있습니다. 다시 재설정하면 장치에서 데이터가 손실됩니다.

SCSI / SAS 드라이브 및 일부 sATA 드라이브는 재설정시 속성이 손실되지 않도록하기 위해 후기 입 프로파일의 상태를 저장할 수 있지만 실제로는 거의 사용되지 않습니다.

블록 계층을 상위 계층에 통합하는 RAID 컨트롤러는 드라이브 재설정을 감지하고 다시 쓰기 캐시를 다시 비활성화 할 수 있지만 표준 sATA 및 SAS 컨트롤러는이를 수행하지 않습니다.

이 제한은 성능 및 안정성을 위해 구성된 다른 SET FEATURE 및 유사한 매개 변수에도 적용됩니다.

알다시피, 적절한 배터리 백업 RAID 컨트롤러는 비싸지 만 eBay에서 £ 100 ($ 150)에 Dell Perc5 / i 컨트롤러를 찾을 수 있으며 특히 RAID5에서는 Perc5 / i와 같은 컨트롤러의 속도가 놀라 울 것입니다. Perc5 / is 및 6 개의 디스크 RAID5 어레이가있는 서버가 여러 대 있는데, 내가 본 것 중 가장 빠른 디스크 중 하나입니다. 특히 데이터베이스 응용 프로그램의 경우 빠른 디스크는 실제로 성능을 향상시킵니다.

총알을 물고 RAID 컨트롤러를 구입합니다.

JR

내가 이해하는 한, fsync () faking은 드라이브가 아닌 배터리 지원 RAID 컨트롤러의 속성입니다. RAID 컨트롤러에는 전원이 드라이브에 복원되고 쓰기가 디스크에 안전하게 커밋 될 때까지 쓰기 캐시에 전원을 공급할 수있는 배터리가 포함되어 있습니다. 이렇게하면 쓰기가 디스크에 쓰여지도록 어느 정도 보장 할 수 있으므로 컨트롤러가 즉시 OS로 돌아갈 수 있습니다.

드라이브 쓰기 저장 캐시가 가득 차면 캐시가 드라이브에 다시 쓰여질 때까지 쓰기가 차단됩니다. 이것은 캐시가 일반적으로 지속적인 쓰기에서 효과적이지 않음을 의미합니다.

애플리케이션에 몇 개의 IOPS가 필요합니까? 드라이브 쓰기 캐시에 의해 제한을 받거나 드라이브의 작은 (서버의 메모리와 비교하여) 이점이 있습니까?