서버에 어떤 RAID 수준을 선택해야 합니까?

01

복구 요구 사항을 먼저 작성하십시오.

장애 모델을 평이한 언어로 정의하십시오: 장치 하나, 장치 두 개, 컨트롤러, 우발적 삭제 또는 전체 서버. RAID는 일부 장치 장애만 해결합니다. 서비스 복원을 위한 복구 시간 목표와 데이터 손실을 위한 복구 지점 목표를 설정한 다음 로컬 어레이가 충족할 수 있는 요구 사항과 다른 곳에서 복제 또는 백업이 필요한 요구 사항을 식별하십시오.

성능 저하 상태에서도 시스템이 쓰기를 계속 수용해야 하는지 기록하십시오. 읽기 위주 아카이브, 쓰기 집약적 데이터베이스, 일회용 스크래치 공간은 동일한 수의 드라이브를 사용하더라도 서로 다른 레이아웃이 필요할 수 있습니다. 따라서 용량 효율성은 하나의 제약 조건일 뿐 최종 판단은 아닙니다.

02

레이아웃을 워크로드와 장치 수에 맞추세요

미러는 2개 장치 부팅 또는 데이터 세트에 간단하며 독립 미러 그룹이 유용한 랜덤 I/O에 적합할 수 있습니다. 패리티 레이아웃은 더 많은 용량을 위해 쓰기 작업과 재구성 복잡성을 교환합니다. 이중 패리티는 넓은 HDD 세트에서 추가 장애 여유를 보존할 수 있는 반면 RAID 10은(는) 미러 쌍을 위해 원시 용량의 절반을 교환합니다. 이는 성능 보장이 아닌 설계 경향입니다. 컨트롤러, 파일 시스템, 큐 깊이, 레코드 크기 및 애플리케이션 패턴이 모두 중요합니다.

실제 카탈로그 토폴로지를 사용하십시오. 12-드라이브 및 24-드라이브 스토리지 서버는 두 개의 NVMe 컴퓨트 서버에서는 사용할 수 없는 선택지를 제공합니다. 별도의 NVMe 부트 쌍을 데이터 배열 계산에 포함하지 말고, 장애 도메인과 I/O 동작을 모델링하지 않은 채 하나의 매우 넓은 그룹이 여러 그룹보다 낫다고 가정하지 마십시오.

03

중복성을 소유할 계층 하나 선택

하드웨어 컨트롤러, Linux MD 또는 ZFS와 같은 파일 시스템 중 어느 것이 레이아웃을 소유할지 결정하십시오. 문서화된 이유 없이 독립적인 RAID 계층을 쌓지 마십시오. 상태 및 교체 상태가 모호해질 수 있습니다. ZFS 중복성은 미러 또는 RAIDZ vdev를 통해 표현되며 체크섬에 의존합니다. 최상위 vdev가 손실되면 풀이 손실될 수 있으므로, 기존 중복 풀에 단일 비중복 장치를 추가하면 장애 모델이 변경됩니다.

배열을 만들기 전에 드라이브 ID, 교체 절차, 부팅 동작 및 운영 체제가 관찰할 수 있는 내용을 확인하세요. 나중에 토폴로지를 변경하는 것은 특히 패리티 레이아웃의 경우 제한적이거나 중단될 수 있습니다.

• OpenZFS vdev 구조 ↗

04

성능 저하 및 재구성 기간 계획

모니터링은 정상, 저하, 재구성 및 일관성 검사 상태를 구별해야 합니다. Linux MD는 resync, recover, check, repair와 같은 작업을 노출합니다. 볼륨이 마운트되었다고만 보고하지 말고 진행 상황과 불일치를 수집하십시오. 더럽고 저하된 RAID 5 또는 6는 손상 위험을 초래할 수 있으므로 강제 조립은 일상적인 복구 지름길이 되어서는 안 됩니다.

알림 라우팅, 스페어 확보, 교체 식별, 워크로드 제한, 복원이 계속하는 것보다 안전한 시점을 문서화하세요. 제공된 장치, 어레이 부하 및 컨트롤러를 측정하지 않고 재구축 기간을 약속하지 마세요.

05

선택과 한계 기록

완성된 설계에는 레이아웃, 동일 드라이브 가정, 사용 가능한 용량 추정, 허용되는 장애, 모니터링 소스, 복원 위치가 명시되어야 합니다. 버전 관리된 데이터를 다른 장애 도메인에 보관하고 복원을 테스트하세요. 예상 결과는 RAID가 손실을 방지한다는 주장이 아니라 프로덕션 데이터가 도착하기 전에 장애 동작과 복구 책임을 이해한 배열입니다.