[정보 🌐] raid 5/6 와 쓰기캐시

[k91b(cope0331)]

일단 이 해놀은 백업 + cctv 전용임

특정 시간에 대용량의 쓰기 트래픽이 들어오고

평상시에 지속적인 작은 chunk 의 쓰기 요청이 들어옴

문제는 대부분의 쓰기 chunk 크기가 6 hdd raid5 의 stripe 크기보다 작음

이말인즉슨 

raid5 의 read-merge-write 패턴이 상시 발동중이란 것임

용량이 10tb 를 늘어나는 동안 읽기 34tb 쓰기 23tb 가 늘어난걸 보고 이걸 추진하게 되었음

---- 

골수 젖붕이들은 다 알겠지만

raid5/6 계열은 하드들이 패리티 때문에 통나무를 지고 있는 상태고, 하나의 풀에 참여한 하드들의 수가 늘어날수록 통나무의 길이가 길어짐

통나무의 길이 = 1바이트를 읽거나 쓰기를 하더라도 풀에 참여한 모든 하드들이 협력해서 읽고/써야 하는 최소 크기

즉 hdd 위의 모든 저장 공간이 서버랙처럼 규격화된 슬롯이 되었다고 생각하면 됨. 문제는 여기에 참여한 하드들의 숫자가 늘어날수록 그 최소 슬롯 크기는 커지는데, 모든 쓰기 요청이 그 슬롯 크기와 딱 맞거나 혹은 그보다 크지 않음.

결국 실제 저장공간의 활용이란 면에 있어서, 새로운 작은 쓰기를 수행한다면 기존에 '일부' 사용된 슬롯을 찾아내서 그것의 기존 데이터를 읽고(read) 새로 추가될 데이터를 거기에 합류시키고 (merge) 그것을 다시 쓰기 (write) 를 하는 과정이 반복된다.

이것을 '쓰기 증폭' 이라고 부르는데

이쯤되면 의문이 생길 것이다

1. 걍 바로 찍싸지 말고 ram 에서 모아서 크기에 맞게 쓰기를 하면 안됨?

-> 당연히 이게 답이다. 정전 같은게 절대 일어나지 않는다는 전제하에

2. raid 5/6 에 참여하는 hdd 가 늘어날수록 통나무가 길어진다 했는데, hdd 하나당 늘어나는 길이를 줄이면 안됨?

-> 모든 저장 장치는 최소 접근 단위가 있음. 이것은 물리적인 구조에서 기인할수도 혹은 논리적인 정의에 의해 크기가 달라질 수 있음. 그렇다는 것은 최소로 줄일 수 있는 크기는 매체에 따라 정해져 있다는 뜻이고 늘리려고 하면 왕창 키울 수도 있다는 말이다. 그럼에도 불구하고 항상 최소 크기로 유지하지 않는 이유는 성능 문제 때문이다. 일단 한 구역/단위에 접근하기 위한 비용은 대강 비슷한데, 그 비용을 지불하고 접근할 수 있는 데이터의 크기가 작으면 당연히 성능에 불리하다.

의문을 해결했으니 다시 본론으로 가보자면

위의 1번이 답이라는 것을 아는데 왜 못하는가? 언제 전기가 나갈지 모르기 때문이다. ups 가 백업중이라는걸 서버가 알고 있어도 그 ups 의 배터리가 사용연한을 넘겼는지 고장났는지 알 수 없으므로 스토리지를 업으로 삼는 벤더들은 이걸 참고만 하는 식으로 구현할 수밖에 없다.

그렇다면 답은 뻔한 것이다.

'전기를 끊어도 데이터가 날아가지 않음이 보장되며 기민하고 접근 단위가 작은 저장장치' 에서 일단 데이터를 버퍼링 해서 적당한 조건을 충족할때만 실제 flush 를 깔끔하게 수행시키면 raid5/6 rmw 패턴을 트리거링 하지 않을 것이다.

truenas 같이 zfs 를 기반으로 하는 시스템은 slog 라고 아예 선제 쓰기 캐시를 지원한다. 물론 저걸로 사용할 수 있는 미디어의 조건은 다음과 같다.

1. 전원이 나가도 데이터를 잃지 않음이 보장

2. 엄청난 쓰기 용량을 버틸 수 있는 내구성을 갖춤

3. 자잘하고 비주기적인 쓰기/읽기에도 고성능

4. hdd 풀의 최대 선형 입출력 대역폭을 아득히 상회하는 성능

당연히 요구사항이 개빡셀 수밖에 없고 비싸다

요즘 널려있는 최신 m2 ssd 를 쓴다면 얼추 4는 만족하고 3은 그럴수도 아닐수도 있다라고 보면 된다.

이제 홈랩 수준에서 최선의 대용품을 찾는다면 ...

인텔이 야심차게 추진하다 망해서 철수한 재고가 떨이중인 m2 optane 정도가 보일 수밖에 없다.

대강 2,3,4 정도는 충족하니 말이다. (3,4 는 사실 그럴수도 아닐수도)

문제는 용량이다. 

16g 는 알리에서 7천원이지만 32g 는 3.7만 64g 는 8.4만 정도가 최소 가격이다.

나는 이것을 해놀에서 쓸 예정이고

btrfs 메타데이터 고정을 사용하려면 최소 2개의 미디어에서 raid1/5/6/10 이어야만 기능을 사용할 수 있다.

문제는 내 볼륨의 btrfs 메타데이터가 현재 42g 정도 된다는 것이고

나는 이것들을 위해 pcie 1슬롯만을 사용할 예정이다.

즉 ssd 풀을 구성하기 위해 최대 4개만 사용 가능하다는 의미이다

(bifurcation x4x4x4x4)

그러니 32g * 4 를 raid5 로 묶어서 구성하는게 최선이다

(실효 용량은 약 81g)

그 와중에 optane 이 nvme format --ses 를 안먹어서 hang 걸리는 찐빠도 겪었지만 아무튼 극복하고 장착시켰다.

그래서 적당히 부하를 줘본결과

120g 용량이 늘어난 동안 실제 hdd raid5 풀의 쓰기는 131g 읽기는 21g 로 억제됨을 확인할 수 있었다.

여기서 아마 태클이 하나 들어올텐데

"그럼 optane 캐시의 raid5 rmw 는 어찌 되는거죠?"

몰루 그놈들은 튼튼하고 젊으니껜 어찌 되것제

노파심에 얘기하지만 ..

앵간하면 따라하지 마시죠?

암템을 늘리고 싶지 않다면

- dc official App

[АSМL(asml877543)]

[무기를ㅡ접자(kkb1970)]

소비자용 pSLC의 보급화.....는 이미 글렀군!

[k91b(cope0331)]

늙은 hdd 들을 위한 최고의 복지 젊고 튼튼한 것들을 갈아서 무병장수를 꿈꾼다 - dc App

[익명(211.36)]

레이드 10도 저 통나무 문제가 있음?

[k91b(cope0331)]

일단 패리티가 없으니 없거나 적다고 보면 됨. - dc App

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[k91b(cope0331)]

일반 ssd 쓰면 안됨, 그리고 optane m10 캐시는 용량땜에 일반 워크로드 nas 에는 부적합 - dc App

[고닉임?(wtd01)]

이 사람은 걍 M10이 쓰고싶었음

[k91b(cope0331)]

[테라의유죄(rhemddj2akfl)]

mlc ssd로도 수명 감당 안되겠지...? - dc App