하드웨어 RAID 6의 ZFS 스트라이프. 무엇이 잘못 될 수 있습니까?

9

36 * 4TB HDD SAN 랙이 있습니다. RAID 컨트롤러는 하나의 RAID 그룹에서 RAID60 및 16 개 이하의 HDD를 지원하지 않았습니다. 그래서 16HDD의 2 개의 RAID6 그룹 또는 8 개의 HDD 중 4 개를 만들기로 결정했습니다. 모든 스토리지를 하나의 파티션으로 가져오고 싶습니다.

그렇다면 하드웨어 RAID6 위에서 zfs 풀을 사용한다면 무엇이 잘못 될 수 있습니까? 예, 기본 HDD 또는 통과 모드를 사용하는 것이 좋습니다. 그러나 나는이 옵션이 없습니다.

아니면이 상황에서 ZFS 및 소프트웨어 공격을 피해야합니까? (주로 압축 및 스냅 샷에 관심이 있습니다)

— 세버 건
소스

2

ZFS를 사용하려는 경우 모든 디스크를 개별적으로 노출하고 (때로는 HBA 모드라고 함) ZFS가 처리하도록하는 것이 가장 좋습니다. 우리는 이것에 당신을 도울 많은 진정한 전문가가 있습니다 (처음에는 ewwhite)-어떤 정확한 디스크 컨트롤러를 사용하고 있습니까?

— Chopper3

1

이 방법을 사용하여 많은 ZFS 기능을 파괴 할 수 있지만 전반적으로 이러한 방식으로 아무 것도 해치지 않습니다. RAID 컨트롤러가 모든 디스크 세부 정보를 추상화하므로 체크섬은이 구성에서 조금 더 쓸모가 없습니다. JBOD를 사용할 수 없다고 말하는 이유에 더 관심이 있습니다. assuredsan 3530은 JBOD 가능 장치입니다.

— 스풀러

2

나는 ewwhite를 기다릴 것이다-그는 미국 중부에있다. 그래서 자고있다. 그러나 그는 내가 알고있는 사람보다 ZFS를 더 잘 안다

— Chopper3

1

@Severgun 또한 4 개의 HDD가 무용지물입니다. 핫 스페어가 필요하지 않습니다. 드라이브가 고장난 RAID 어레이가 자동으로 핫 스페어를 집어 들고 재 구축하여 완전히 복귀하는 것보다 성능이 저하 된 모드에서 삐걱 거리는 것이 더 낫다고 생각하십니까? 기능 상태?

— Andrew Henle

1

@ Chopper3 나는 대답 할게 ... 마지 못해.

— ewwhite

5

그래서 16HDD의 2 개의 RAID6 그룹 또는 8 개의 HDD 중 4 개를 만들기로 결정했습니다.

이것이 최선의 방법은 아닙니다. 제대로 작동하지만 성능 요구 사항에 따라 그렇지 않을 수 있습니다.

RAID5 / 6 어레이의 이상적인 크기는 어레이를 "스팬"하는 데이터 양의 정확한 배수가 그 위에 구축 된 파일 시스템의 블록 크기와 일치하는 것입니다.

RAID5 / 6 어레이는 블록 장치로 작동합니다. 단일 데이터 블록이 어레이의 디스크에 걸쳐 있으며 해당 블록에도 패리티 데이터가 포함됩니다. 대부분의 RAID 컨트롤러는 어레이의 각 디스크에 2의 제곱 크기의 데이터를 기록 합니다. 정확한 값은 더 나은 RAID 시스템에서 구성 할 수 있습니다. Dot Hill 장치는 "더 나은 RAID 시스템"중 하나입니다. 중요합니다.

따라서 배열에 걸치려면 N x (디스크 청크 당 저장된 데이터 양)가 필요합니다. 여기서 N은 데이터 디스크 수입니다. 5 디스크 RAID5 어레이에는 4 개의 "데이터"디스크가 있고 10 드라이브 RAID6 어레이에는 8 개의 데이터 디스크가 있습니다.

데이터가 RAID5 / 6 어레이에 기록 될 때, 데이터 블록이 전체 어레이를 확장 할 수있을 정도로 큰 경우 일반적으로 컨트롤러의 메모리에서 해당 데이터에 대해 패리티가 계산되고 전체 스트라이프가 디스크. 간단하고 빠릅니다.

그러나 작성중인 데이터 청크가 전체 배열에 걸쳐서 충분하지 않은 경우 새 패리티 데이터를 계산하기 위해 RAID 컨트롤러는 무엇을해야합니까? 새로운 패리티 데이터 를 다시 계산하려면 전체 스트라이프 의 모든 데이터가 필요합니다 .

따라서 디스크 당 기본 청크가 512kb 인 16 드라이브 RAID6 어레이를 만들 경우 어레이를 "스팬"하는 데 7MB가 필요합니다.

ZFS는 일반적으로 128kb 블록으로 작동합니다.

따라서 ZFS는 128 드라이브 블록을 16 드라이브 RAID6 어레이에 씁니다. 제안하는 구성에서 RAID 컨트롤러 는 어레이에서 거의 7MB 를 읽고 7MB에서 패리티를 다시 계산해야합니다. 그런 다음 전체 7MB를 디스크에 다시 씁니다.

운이 좋으면 캐시에 모두 포함되어 있으며 성능이 크게 저하되지 않습니다. (이것은 "RAID5 / 6을 사용하지 마십시오"위치가 다음과 같은 주요한 이유입니다. RAID1 [0]은이 문제를 겪지 않습니다.

운이 좋지 않고 파일 시스템 파티션을 올바르게 정렬하지 않은 경우 128kB 블록은 캐시에없는 두 개의 RAID 스트라이프에 걸쳐 있으며 컨트롤러는 14MB를 읽고 패리티를 다시 계산 한 다음 14MB를 써야합니다. 하나의 128kB 블록을 작성합니다.

이제 그것이 논리적으로 일어나야하는 것 입니다. 좋은 RAID 컨트롤러가 있으므로, 이러한 IO 패턴의 IO 및 계산 부하를 줄이기 위해 취할 수있는 최적화가 많이 있습니다 수도 나쁜되지는.

그러나 임의의 위치에 128kB 블록을 쓰면 7MB 스트라이프 크기의 16 드라이브 RAID6 어레이의 성능이 절대적으로 끔찍할 가능성이 매우 높습니다.

ZFS의 경우, 대부분의 액세스가 사실상 무작위 인 범용 파일 시스템에 대한 "이상적인"기본 RAID5 / 6 LUN 은 32kB, 64kB 또는 128kB와 같은 128kB의 제수 인 스트라이프 크기를 갖습니다 . 이 경우 RAID5 / 6 어레이의 데이터 디스크 수를 1로 제한합니다 (무의미한 구성-구성이 가능하더라도 RAID1 [0], 2, 4 또는 8을 사용하는 것이 좋습니다). 가장 좋은 시나리오는 RAID5 / 6 어레이에 128kB 스트라이프 크기를 사용하는 것이지만, 일반적인 경우는 파일 시스템이 메타 데이터를 동일하게 저장하지 않기 때문에 범용 파일 시스템에서는 종종 발생하지 않습니다. 파일 데이터를 저장하십시오.

디스크 당 청크 크기가 전체 어레이 스트라이프에 걸쳐있는 데이터 양이 64kB가되도록 충분히 작게 설정된 5 디스크 RAID5 배열 또는 10 디스크 RAID6 배열을 설정하는 것이 좋습니다 (예,이 작업을 완료했습니다) ZFS 이전-여러 번). 즉, 데이터 디스크가 4 개인 RAID 어레이의 경우 디스크 당 청크 크기는 16kB 여야하고, 8 데이터 디스크 RAID 어레이의 경우 디스크 당 청크 크기는 8kB 여야합니다.

그런 다음 ZFS가 전체 배열 을 사용하도록 허용 하십시오. 분할 하지 마십시오 . ZFS는 드라이브가 단순한 단일 디스크이든 RAID 컨트롤러가 제공하는 RAID 배열이든 전체 드라이브에 올바르게 정렬됩니다.

이 경우 정확한 공간 및 성능 요구 사항을 모르는 경우 64kB 스트라이프 크기의 3 개의 10 드라이브 RAID6 어레이 또는 6 개의 5 드라이브 RAID5 어레이를 설정하고 2 개의 핫 스페어를 구성하고 4 개를 저장하는 것이 좋습니다. 앞으로 나올 모든 것을위한 디스크. 뭔가가 있기 때문입니다.

JBOD 모드에서는 디스크 시스템을 사용하지 않을 것입니다 . 하드웨어에 내장 된 상당한 안정성과 가용성 보호 기능을 제공하는 NEBS 레벨 3 호환 장치 입니다. 그냥 "ZFS !!!!"때문에 버리지 마십시오. 저렴한 상용 하드웨어라면 부품으로 구성 할 수 있습니까? 예, ZFS가 RAID를 처리하는 JBOD 모드가 가장 좋습니다. 그러나 이것이 여러분이 가진 하드웨어는 아닙니다 . 하드웨어가 제공하는 기능을 사용 하십시오.

— 앤드류 헨리
소스

즉, 4 개의 데이터 디스크가있는 RAID 어레이의 경우 디스크 당 청크 크기는 16kB 여야하고, 8 개의 데이터 디스크 RAID 어레이의 경우 디스크 당 청크 크기는 32kB 여야합니다. 나는이 수학과 약간 혼동된다. 왜 8 개의 디스크-32kB 청크? 내가 틀렸다면 정정하십시오 : 128kB (ZFS 블록) / 3 (RAID 배열) = 43kB-RAID 배열. 10 개 디스크의 RAID6 43kB / 8 = 5kB (사용 가능한 청크 크기) 가장 가까운 8kB 청크 크기는 하드웨어에서도 사용할 수 없습니다. 최고의 성능에 접근 할 수 없습니까?

— Severgun

@Severgun 청크 크기를 거꾸로했습니다. RAID5 / 6에서 최고의 성능을 목표로하는 문제는 거의 모든 IO 작업이 RAID 어레이 스트라이프 크기와 완벽하게 일치 할 때만 발생한다는 것입니다. 스트라이프 크기보다 적은 수의 IO 작업은 성능을 크게 저하시킬 수 있습니다. 더 작은 블록 크기를 사용하면 임의의 작은 블록 쓰기의 영향을 제한 할 수 있습니다. 내 경험에 의하면, 그것은의 1 ~ 2 % 포기하는 것이 낫다 가능한 최악의 경우가 내려 제한하는 대가로 최대의 성능을. 범용 파일 시스템은 적은 수의 작은 쓰기를하는 경향이 있습니다.

— Andrew Henle

(계속) 디스크 당 16kB 청크 크기를 가진 RAID5 / 6 어레이의 8 개 데이터 디스크는 어레이 전체에서 128kB 스트라이프 크기를 만듭니다. 4- 데이터 디스크 어레이의 경우 32kB 청크도 마찬가지입니다. ZFS는 128kB 파일 데이터 블록을 단일 장치에 씁니다. 모든 zdev에서 분할되지는 않습니다. 다시 말하지만, 범용 파일 시스템의 경우 128kB 이하의 쓰기가 많이 발생하므로 스트라이프 크기가 작을수록 (64kB) 쓰기로드가 많을 때 성능 저하를 피할 수 있지만 적은 비용으로 최상의 케이스 성능.

— Andrew Henle

4

알았어 ..

응용 프로그램에 잘못된 하드웨어입니다. DotHill 설정은 단일 스토리지 그룹에 16 개의 드라이브 만 사용할 수 있다는 점에서 HP StorageWorks MSA2000 / P2000과 동일한 제한 사항이 있습니다.

하드웨어 RAID 또는 내 보낸 SAN LUN 위에 ZFS 가 반드시 문제가되지는 않습니다.

그러나 확장 섀시에서 알 수없는 상호 연결을 통해 ZFS LUN을 스트라이핑하면 위험이 발생할 수 있습니다.

예를 들어, 이중 컨트롤러가있는 링 토폴로지에서 다중 경로 SAS를 실행하고 있습니까?
서버에 중복 케이블을 다시 연결 했습니까?
단일 섀시 / 케이블 / 컨트롤러의 장애를 완화하고 RAID0 스트라이프의 일부를 파괴하지 못하게하는 방식으로 인클로저에 수직으로 드라이브를 분배 했습니까?

진지하게, 단일 네임 스페이스에이 스토리지가 모두 필요한지 여부를 평가할 가치가 있습니다 ...

단일 마운트에서 이러한 유형의 용량이 필요한 경우 전용 HBA 연결 JBOD 인클로저 와 탄력적 인 케이블 연결 및보다 스마트 한 레이아웃을 가진 다중 헤드 장치 를 사용해야합니다 .

— ewwhite
소스

1

모든 드라이브를 ZFS를 실행하는 상자에 직접 연결해야합니다. SAS HBA를 가져 와서 드라이브를 ZFS 가능 상자에 연결하십시오 (예 : OmniOS 또는 SmartOS 실행). 그런 다음 NFS, SMB, iScsi를 통해 공간을 공유 할 수 있습니다 ...

— 토비 오에 티커
소스

모든 드라이브를 ZFS를 실행하는 상자에 직접 연결해야합니다. 반드시 그럴 필요는 없습니다- 일부 컨트롤러 의 하드웨어 배열 에서 고장난 드라이브를 교체 하는 것은 쉽습니다 . 고장 표시등이 켜진 상태에서 하드 드라이브를 빼낸 다음 새 드라이브를 넣으십시오. 시스템 관리자는 드라이브를 교체하기 위해 ZFS 명령을 실행할 필요가 없습니다. 수백 또는 수천 대의 서버와 수만 개의 하드 드라이브가있는 엔터프라이즈 환경에서는 여러 데이터 센터에 분산 될 수 있습니다. 비트 부패가 발생하는 것보다 드라이브가 완전히 고장납니다.

— Andrew Henle

@Tobi Oetiker, 2U 케이스에 36 개의 3.5 인치 HDD를 배치하는 방법을 알려주세요

— Severgun

우리는 그것들을 여분의 상자에 넣었습니다 ... sas extender를 사용하십시오 ... 대규모 배포의 경우, 기쁨이 그것을 처리하는 방법을 묻습니다.

— Tobi Oetiker

@AndrewHenle 공정하게, ZFS와 올바른 HBA를 사용하여 동일한 교체 절차 및 상태 LED를 쉽게 얻을 수 있습니다 (사전 패키지 된 솔루션을 사용하지 않으면 약간의 스크립팅이 필요할 수 있음).

— user121391

0

HW RAID 논리 볼륨 위에 ZFS가 매우 나쁜 이유는 ZFS가 실제로 제대로 작동하려면 블록 수준 액세스가 필요하기 때문입니다. 예, 사용할 수는 있지만 HBA 또는 직접 SATA 연결을 통해 드라이브를 OS에 직접 연결할 때까지 기능이 완료되지 않습니다. 한 가지 예는 ZFS를 제안하는 구성에서 아래의 데이터 변경 (HW RAID 컨트롤러의 다른 쪽)으로부터 데이터를 합리적으로 보호 할 수 없으므로 데이터의 안전성을 보장 할 수 없다는 것 입니다. 이것이 ZFS가 사용되는 주된 이유 중 하나이며 초 듀퍼 속도입니다.

ZFS는 멋진 기술이므로 강력히 추천합니다. 그러나 올바르게 사용하려면 구조를 다시 방문해야합니다. 즉, ZFS가 디스크에서 논리 볼륨 (vdev)을 직접 작성하게합니다.

ZFS의 작동 방식에 대해 더 많은 독서가 필요하다고 생각합니다. ZFS가 제안한 것을 정확하게 이해하기 전에 실제로 수행해야하는 것과 대조를 이룹니다.

— 블러디 철
소스

예, 그렇습니다. ZFS가 가능한 한 잘 작동하는지 이해합니다. 그러나 몇 가지 복잡한 문제가 있습니다. 1) SAN 인클로저가 이미 있고 이를 사용해야합니다. 스토리지를 처음부터 구축하지 않습니다. 2) 이것은 물건을 사고 버릴 수있는 가정용 NAS가 아닙니다. 3) 스토리지 구성 재구성을위한 예산은 0과 같습니다 . 스토리지에서 나는 100Tb 정도의 공간으로 가능한 최대 쓰기 속도가 필요합니다. 압축 및 스냅 샷으로 인해 ZFS를 주로 찾고 있습니다. btrfs를 사용해 볼 수는 있지만 실험적입니다. 흠 너무 ZoL 불안정 할 수 있습니까? 나는 지금 없다.

— Severgun

@Severgun 단점이 무엇인지 아는 한 내 의견으로는 괜찮을 것입니다. ZFS에는 다른 기능과 독립적으로 작동하는 많은 멋진 기능 (예 : 스냅 샷)이 있습니다. 인터넷에 대한 대부분의 조언은 모든 분야에서 모범 사례의 중요성을 강조하지만 엄격한 요구 사항이 아닌 권장 사항입니다. 점점 더 많은 LInux 배포판이 ZFS로 변경되고 대부분의 Linux 시스템이 가상화되어 실행되므로 정확한 시점을 가지게되므로이 시점에서 향후 중요도가 떨어질 것입니다.

— user121391

1

HW RAID 논리 볼륨 위에 ZFS가 매우 나쁜 이유는 ZFS가 실제로 제대로 작동하려면 블록 수준 액세스가 필요하기 때문입니다. 너무 나쁘기 때문에 잘못 부를 정도로 충분하지 않습니다. NEBS 3 호환 하드웨어가 무엇을 의미하는지 전혀 모릅니다. 뿐만 아니라 슈퍼 듀퍼 빠른 것입니다. ZFS는 많은 좋은 것들입니다. "슈퍼 듀퍼 패스트"는 그중 하나 가 아닙니다 . 이것은 빠른 파일 시스템입니다. 이것도 마찬가지입니다 . 파일 시스템이 진행됨에 따라 ZFS는 빠르지 않습니다 .

— Andrew Henle