RAID cache 관련 확인 시 default가 Write Back 으로 되어있는데 BBU Fail로 인해 현재는 Write Through로 변경된 것으로 보입니다.
해당 RAID 그룹의 Disk Cache Poicy가 Disk's Default 로 되어있는데 그럼 Cache 정책이 어떻게 적용되었다고 인지하면 될까요?
raid cache 정책 관련
RAID cache 관련 확인 시 default가 Write Back 으로 되어있는데 BBU Fail로 인해 현재는 Write Through로 변경된 것으로 보입니다.
해당 RAID 그룹의 Disk Cache Poicy가 Disk's Default 로 되어있는데 그럼 Cache 정책이 어떻게 적용되었다고 인지하면 될까요?
4개의 답변이 있습니다.
현재 Cache policy는 WriteThrough이고,
Disk cache Policy는 Disk의 기본으로 되어 있다는 글자 그대로 보면 될 것 같네요.
Disk Cache Policy는 각 디스크의 Cache를 사용할지(Enable), 사용하지 않을지(Disable)를 선택하는 옵션에 해당하겠고요.
일반적으로 SATA는 Enable, SAS는 Disable이 Default가 되겠고요.
Disk Cache Policy 기본값에 의해 Enable이 되거나 Disable가 된다는 의미로 Disk Cache Policy가 Disk's Default 라고 표시되어 있다고 보면 될 것 같네요.
●WT(Write-Through) - 쓰기는 대상 디스크에서 쓰기가 완료되었다고 보고한 후에만 완료됩니다.
●WB(Write-Back) - 데이터가 아직 대상 디스크에 기록되지 않은 경우에도 컨트롤러의 캐시에 기록되면 쓰기가 완료됩니다.
○시스템의 전원이 꺼지면 디스크에 저장되지 않은 모든 데이터가 손실될 수 있으므로 이 정책은 추가적인 데이터 손실 위험이 수반됩니다. 배터리 지원 캐시를 사용하면 이러한 위험을 줄일 수 있습니다.
○배터리 전원이 부족하여 캐시에 데이터를 보관할 수 없으면 WB 정책이 WT로 돌아갑니다.
●강제 나중 쓰기 - 쓰기 정책은 배터리의 상태에 상관없이 나중 쓰기로 유지됩니다.
Genghis Khan | 일 년 이상 전
쓰기 정책(Write Policy)에서 동작유형을 설정할 수가 있는데 보통 3가지로 나뉘어 집니다.
Write Through, Write Back, Always Write Back 이 3가지 정도로 나뉩니다.
Write Through 는 데이터가 디스크에 기록된 후에 I/O 가 완료됩니다.
Write Back 은 데이터가 캐시에 기록된 후에 I/O 가 완료됩니다.
Through 방식은 Inconsistency를 해소해주며 안정성이 좋지만 디스크 기록때까지 대기해야 하므로 성능이 낮아집니다.
Back 방식은 캐시에 기록되자마자 I/O 가 끝났다고 알려주고 실제 디스크에 기록되는 것은 캐시 내부적 활동에 의해 수행되므로 성능상의 이점이 있습니다 (빠릅니다). 하지만 갑작스런 전원차단 등으로 아직 디스크에 기록되지 못하고 캐시에 남아있는 데이터들은 소멸되어질 수 있기에 Write Back 모드를 사용할 땐 BBU, 즉 캐시배터리가 필요합니다.
Always Write Back 은 BBU 에 관한 체크를 아무것도 하지 않고 매번 Write-Back 모드로 쓰기방식을 사용하는 것 입니다.
(보통 Write Back 방식은 BBU Health Check 후 이상이 있다면 Write Through 로 가게 됩니다)
성능을 포기하더라도 데이터 안정성이 우선이라면 Write Through 방식을 사용하고
데이터 안정성 보다 성능을 중요시 하게 된다면 Write Back 방식을 사용하면 될 듯 합니다.
차바라기님이 자세하게 설명을 해 놓으셔서 크게 말씀드릴것은 없지만,
일반적으로 Disk의 Cache 정책은 RAID Card의 정책과 디스크 자체의 Cache 정책으로 나뉘어 집니다.
요즘은 HDD 자체에도 Cache 가 있기 때문에 두가지의 Cache 정책이 모두 적용 된다고 봅니다.
도움이 되었으면 합니다.
Read Policy: 읽기 정책
No Read Ahead: 어플리케이션(프로세서)이 읽기 요청한 부분만 읽습니다.
그러니깐 앞으로 요청할 거 같은 데이터 캐시에 미리 올려논다든지 그러지 않는다는겁니다.
데이터 읽기가 예측하기 힘들정도로 다양한 위치(위치가 중요합니다)에서 무작위로 이루어지는 경우 이 정책이 좋습니다. 레이드카드의 뻘짓이 줄겁니다.
Always Read Ahead: 프로세서에서 요청한 읽기외에 그 주변까지 미리 읽어놓습니다.
대개 동일한 시점에 동일한 폴더내에 작성된 파일들은 주변 블록에 몰려있습니다. 이런 파일들이 같이 엑세스 되는 경우가 많은 경우, 주변을 미리 읽어놓으면 성능이 좋아질 수 있다는거죠.
하드디스크의 스트라이프 시퀸셜 읽기 성능이 뛰어나다는걸 이용한 정책입니다. 주로 어플리케이션 기동같은 행위에 강합니다.
파일단위로 보지 않더라도, 대개의 어플리케이션은 하나의 파일 내에서 랜덤억세스를 하는 경우 주로 주변 블럭을 왔다갔다하며 탐색하니 나름 여려 경우에 그럭저럭 적용되는 정책이라고 볼 수 있습니다.
Adaptive Read Ahead: 사용자의 읽기 패턴을 파악해서 자주 접근하는 파일들을 미리 읽어드립니다. (한국어로 번역하면 적응형 미리읽기?)
이건 OSX가 잘 하는 짓인데, 최근 발매된 윈도즈10에도 포함된 기능입니다(파일케싱에 대해: 어플리케이션 프리패칭 등의 기술은 예전부터 존재함).
여기서는 컨트롤러가 사용자의 행동패턴을 파악해서 자주 접근하는 데이터를 미리 캐시에 올려놓겠다는겁니다.
참고로 아이폰과 안드로이드는 거지같은 eMMC 성능과, 지루한 어플리케이션 로딩속도 때문에 필수적으로 들어간 기능이기도 합니다.
(메모리 클리닝을 해도 자꾸 메모리 사용량이 도로 늘어나는 이유)
서버시스템 스토라지에서는 캐시가 사용자가 주로 접근하는 데이터들의 합보다 크다면야 효과가 매우 크겠지만, 그렇지 않다면 글쎄요?
(물론 제조사들 설명서에는 패턴이 일정하다면 캐시 크기가 작아도 잘 동작한다고 기대하게끔 설명합니다만....)
Write Policy: 기록정책(기록 작업을 어떻게 진행할 것인지를 설정하는 겁니다):
Write Back: (쓰기작업을 백그라운드로 합니다)
Process -----[쓰기명령 > Controller-] [------- 짧은 대기 ----------] [다른일 하기 ------------------------------------
Controller --------------------------- [(캐시에) 쓰기완료 > Process -] [백그라운드 쓰기작업 -----] [미디어에 쓰기 완료 --]
쓰기명령을 컨트롤러에 보내면 컨트롤러가 데이터를 캐시에 로드하고, 바로 쓰기 완료했음 이라고 프로세스에 신호를 보냅니다. 프로세스는 계속 다른 작업을 합니다.
컨트롤러는 남는 시간에 캐시에 있는 데이터를 실제로 미디어(하드디스크)에 기록할겁니다. 전원이 끊겼을 때 문제가 발생할 소지가 높지만, 인터럽트 오버헤드를 크게 줄일 수 있습니다.
Write Through: (즉시기록모드)
Process ----- [쓰기명령 > Controller][----- (오랜 기다리기) ----------------------------------] [다른일 하기 ---
Controller ------------------------- [쓰기작업 ------------------][미디어에 쓰기완료 > Process] --------------
쓰기명령을 컨트롤러에 보내면 컨트롤러는 미디어에 기록을 마칠때까지 프로세서에 인터럽트를 걸어버립니다.
프로세서는 컨트롤러가 쓰기작업을 마치기 전까지 다른 작업을 할 수 없습니다.
인터럽트 오버헤드가 있지만, 전원차단 등에 Write Back에 비해 매우 튼튼합니다.
부가옵션(만약 컨트롤러 세팅옵션에 있다면)
Disk Cache Policy:
실제 미디어의 캐시 정책을 설정합니다. Write Through 모드에서는 이 정책이 실제 스토라지의 기록성능을 결정짓습니다.
Write Back 모드에서는 백그라운드 쓰기 작업의 퍼포먼스를 결정합니다. (프로세서에 영향을 주지 않습니다: 캐시가 널널하다면)
별거 아니고 대개 실제 하드디스크에 있는 캐시(보통 하드디스크 Cache 스펙에 표시되는거...) 쓸건지 말건지 이정도 설정하는 겁니다.
적어도 레이드카드의 캐시보다는 전원차단 등의 사고에 어느정도 내성이 높다고 볼 수 있습니다(기업용 하드는 이런 경우를 대비해서 내부에 대용량 캐퍼시티를 포함하는 경우가 많습니다).
I/O Policy: 입출력 정책(이건 개인적으로 이 이름보다는 I/O Cache Policy가 더 낮다고 생각합니다)
Direct I/O: 직접 입출력
입출력 작업에 컨트롤러의 캐시따위 쓰지 않습니다. 캐시를 사용하는 경우에 비해 안정적으로 동작합니다. (대신 성능이...)
Cached I/O: 캐시된 입출력
입출력 작업에 컨트롤러 캐시를 사용합니다. 만약 캐시에 있는 데이터를 요청하면 하드디스크 긁어댈거 없이 바로 캐시에서 보내줄 수 있을겁니다.
제가 가장 해메던게 I/O Policy랑 다른 정책이랑 겹치는 내용이 있다는겁니다. 제가 알기로는 컨트롤러에 두 옵션이 다 있는 경우 다른 정책들이 I/O 정책에 의해 무효화 되기도 하는 것으로 알고 있습니다(정확한 내용은 역시 컨트롤러 제조사에 문의하는게 낮겠지요). 읽기 정책의 Adaptive Read Ahead는 제가 설명하고 있는 형태로 동작하는지에 대해 확실치 않습니다. 대개 중저가 레이드 컨트롤러 캐시는 제가 해당 항목에 설명한 형태의 작업을 수행하기에는 매우 부족합니다. (안드로이드만 하더라도 앱이 많이 안 깔려있어도 대개 500MB ~ 1GB정도의 메모리를 어플리케이션 캐싱에만 소모합니다)
참고로 레이드컨트롤러 뿐 아니라, ZFS에도 동일한 내용이 나옵니다. 다들 비슷비슷한 내용 가지고 건들기 때문에 비슷한 내용을 다룹니다만, 그래도 역시 컨트롤러 메뉴얼을 보는게 좋습니다. 스펙과 작동 환경이 다들 다르기 때문에 세부적인 동작은 상이할 수 있습니다.
캐시는 레이드카드 자체의 캐시도 있지만, 별도 SSD로 구성하는 경우도 있습니다. 비휘발성 캐시의 경우 전원차단에 좀더 내성이 있습니다.
낭만생선 | 일 년 이상 전
좋은 내용 감사합니다.