md의 bcache 또는 bcache의 md

bcache를 사용하면 플래시 기반 SSD (Solid State Drive)와 같은 하나 이상의 고속 디스크 드라이브가 하나 이상의 느린 하드 디스크 드라이브에 대한 캐시 역할을 할 수 있습니다 .

올바르게 이해하면

여러 개의 백업 HDD를 캐시 하도록 SSD ^*를 할당 한 다음 결과 캐시 된 장치를 mdadm
또는
여러 개의 HDD를 단일 백업 md 장치로 RAID 할 수 있으며 SSD는

나는 어느 것이 더 순수한 접근인지 궁금합니다. 하나 또는 다른 기술로 RAID5 / 6을 늘리는 것이 더 간단 할 수 있지만 어느 것이 확실하지 않습니다!

VM 백업 파일을 포함하는 큰 루트가 아닌 파일 시스템의 경우 다른 방법을 선택하는 데 적절한 이유 (예 : 백업 스토리지 또는 기타 확장)가 있습니까?

_{^* "SSD"란 일종의 중복 SSD 장치를 의미합니다 (예 : 두 개의 물리적 SSD의 RAID1).}

두 경우 모두 bcache백업 된 모든 디스크를 포맷해야합니다. bcache따라서 md어레이 를 생성 하고 단일 결과 디스크를 bcache백업 된 파티션 으로 완전히 포맷하거나 캐시 드라이브에 연결 한 후 여러 디스크를 포맷해야합니다. 디스크 bcache를 사용하여 캐시 드라이브에 연결 한 다음 여러 디스크를 하나의 배열로 포맷합니다. 두 경우 모두 가능한 실패 지점이 여러 개 있는데,이 모두는 최종 fs는 말할 것도없고 두 파일 시스템 간의 상호 운용성에 따라 달라집니다. 여기를보십시오 : 아래로 스크롤 하십시오 .

— mikeserv 2016 년

github.com/g2p/blocks 덕분에 일부 제한이 있지만 그 자리에서 변환 할 수 있습니다.

— Adam Ryczkowski 2016 년

@ mikeserv 나는 모든 것을 이해합니다. 이것은 목적에 맞는 서버이므로 모든 것이 좋습니다. "두 파일 시스템"이란 무엇입니까? bcache는 파일 시스템이 아닙니다. 내가 선택하는 유일한 파일 시스템은 최종 bcache 또는 mdadm 장치에서 XFS가됩니다 (선택한 옵션에 따라 다름).

@Adam에게 감사합니다. 내부 변환은 문제가되지 않습니다.

@ mikeserv 아닙니다. 파일 시스템 (예 : btrfs, xfs, extN 등)은 블록 장치 위에 있습니다. mdadm과 bcache는 파일 시스템 수준이 아닌 블록 장치 수준에서 작동합니다 (btrfs는 문제를 계층화 위반과 혼동하지만 완전히 별개의 대화입니다).

답변:

전체 md 장치를 캐싱하는 것이 가장 적합하다고 생각합니다.

bcache를 사용하여 전체 md 장치를 캐시하면 다른 단일 장애 지점이 발생하기 때문에 습격에 대한 전체 아이디어가 희생됩니다.

SSD 디스크의 OTH 실패자는 비교적 드물며, bcache를 writethrough/ writearound모드 (모드와 대조적 으로)에 넣을 수 있습니다 writeback. 여기서 모드는 캐시 장치에만 저장된 데이터가 없으며 캐시 실패는 정보를 죽이지 않습니다. 습격은 비교적 안전한 옵션입니다.
다른 사실은 소프트 RAID-5에 상당한 계산 오버 헤드가 있다는 것입니다. 각 회전하는 공격 대원을 개별적으로 캐싱 할 때 컴퓨터는 여전히 캐시 적중시에도 모든 패리티를 다시 계산해야합니다.
~~각각의 회전 드라이브를 개별적으로 캐시하면 고가의 ssd 공간을 희생해야합니다.~~ -RAID ssd 캐시를 사용하지 않을 경우
회전하는 드라이브를 별도로 캐시하는 옵션은 더 많은 버스 트래픽으로 인해 속도 가 느릴 수 있지만 두 옵션 모두 프로세스 증가 시간에 영향을 미치지 않습니다 .

ssd 드라이브를 교체해야 할 때 ssd 드라이브를 제거하도록 bcache를 구성하는 것은 빠르고 비교적 간단한 프로세스입니다. 블록 덕분에 레이드 설정을 두 가지 방식으로 마이그레이션 할 수 있습니다.

또한 순간에 대부분의 (? 모두) 라이브 CD 배포판이 있음을 기억해야 지원하지 않습니다bcache 당신은 단순히 관계없이 같은 도구를 사용하여 데이터에 액세스 할 수 있도록 bcache- mdraid선택한 레이아웃 옵션을 선택합니다.

— 아담 리치 코프 스키
소스

비 중복 SSD 캐시를 사용 하지 않을 계획 임을 분명히하기 위해 질문을 업데이트했습니다 . 두 번째 글 머리표는 훌륭한 점입니다. 덕분입니다. 공간에 대한 세 번째 글 머리 기호 : SSD에 패리티를 저장한다는 의미입니까? 마지막 단락에서, 나는 F20을 사용하고 있지만 결국 RHEL / CentOS7 또는 Debian Jessie를 사용할 것입니다 (bcache-tools가 잘린 경우).

@JackDouglas Ad 세 번째 글 머리 기호 : 예, 정확히 그렇습니다. 그러나 raid ssd 드라이브를 사용할 계획이므로 해당 사항이 적용되지 않습니다.

— Adam Ryczkowski 2016 년

미러링 될뿐 아니라 백업 드라이브의 RAID 패리티도 저장해야하기 때문에 여전히 작동합니다. 내가 생각했던

ssd 매트릭스는 전체 mdraid 드라이브에 공급되는 회전 디스크의 패리티를 저장할 필요가 없습니다.

— Adam Ryczkowski 2016 년

예, 그것이 바로 제가 의미하는 바입니다!

제정신의 접근 방식은 결과 MD 장치를 캐시하는 것입니다.

bcache는 순차적 읽기 및 쓰기를 통과하도록 설계되었습니다.

논리적으로 각 장치를 개별적으로 bcache하는 경우, 여러 장치가 습하거나 제거 된 MD로 스트라이핑하는 경우 bcache 관점에서 지속적으로 임의 블록이 작성됩니다.

bcached MD 볼륨은 정상적인 것처럼 보이지만 파일을 볼륨에 쓰는 것이 아니라 임의의 블록을 여러 장치에 쓰는 것입니다.

하드 및 소프트웨어 공격의 전체 요점은 백엔드에서 데이터 스트라이핑을 수행하여 결과 파일 시스템이 일반 볼륨처럼 보이도록하는 것입니다.

bcache 개발자가 영리하고 그러한 상황을 설명하기 때문에 이것은 정확하지 않을 수 있지만 논리적으로 최적의 방법은 볼륨을 캐시하는 것이 아니라 장치를 차단하는 것입니다.

— 깨달음
소스

또한 아주 좋은 점

RAID5 / 6에 큰 순차적 쓰기는 모든 구성 요소 장치에 순차적 쓰기를 생성합니다. 각 구성 요소 장치는 모든 N-1 데이터 블록 (또는 패리티)을 가져 오지만 가져 오는 데이터는 순차적입니다. 그러나 당신은 그것이 일을 왜곡 할 것이 맞습니다. 빈번한 부분 스트라이프 쓰기가 발생하는 일부 청크가 있으면 패리티 스트라이프의 (일부) 읽기-수정-쓰기가 발생하여 bcache에 의해 캐시 될 수 있습니다. 그래도 부분 스트라이핑 쓰기가 MD 디바이스에 도달하기 전에 더 높은 수준으로 캐싱하는 것이 더 좋습니다.

— Peter Cordes