Azure Stack HCI 및 Windows Server 클러스터의 내결함성 및 스토리지 효율성
적용 대상: Azure Stack HCI, 버전 22H2 및 21H2; Windows Server 2022, Windows Server 2019
이 문서에서는 사용 가능한 복원력 옵션에 대해 설명하고 크기 조정 요구 사항, 스토리지 효율성 및 각 항목의 일반적인 이점 및 장단점을 간략하게 설명합니다.
개요
저장소 공간 Direct는 데이터에 대해 "복원력"이라고도 하는 내결함성을 제공합니다. 해당 구현은 서버 간에 분산되고 소프트웨어에서 구현되는 것을 제외하고 RAID와 유사합니다.
RAID와 마찬가지로 저장소 공간 내결함성, 스토리지 효율성 및 컴퓨팅 복잡성 간에 서로 다른 절충을 수행할 수 있는 몇 가지 방법이 있습니다. 이들은 광범위하게 두 가지 범주로 속합니다: "미러링"과 "패리티", 후자는 때때로 "지우기 코딩"이라고도 합니다.
미러링
미러링에서는 모든 데이터의 여러 복사본을 유지하여 내결함성을 제공합니다. 이는 RAID-1과 가장 유사합니다. 데이터가 스트라이프되고 배치되는 방식은 간단하지 않지만(자세한 내용은 이 블로그 참조), 미러링을 사용하여 저장된 모든 데이터가 전체적으로 여러 번 작성되었다고 말하는 것은 절대적으로 사실입니다. 각 복사본은 독립적으로 실패하는 것으로 간주되는 서로 다른 물리적 하드웨어(서로 다른 서버의 다른 드라이브)에 기록됩니다.
미러링의 두 가지 버전인 "양방향"과 "3방향" 중에서 선택할 수 있습니다.
양방향 미러
양방향 미러링에서 모든 항목의 두 복사본을 씁니다. 스토리지 효율성은 50%입니다. 1TB의 데이터를 쓰려면 2TB 이상의 물리적 스토리지 용량이 필요합니다. 마찬가지로 저장소 공간 Direct를 사용하는 두 개 이상의 하드웨어 '장애 도메인'이 필요합니다. 즉, 두 개의 서버를 의미합니다.
Warning
둘 이상의 서버가 있는 경우 대신 3방향 미러링을 사용하는 것이 좋습니다.
3방향 미러
3방향 미러링에서 모든 항목의 복사본 3개를 씁니다. 스토리지 효율성은 33.3%이며, 1TB의 데이터를 작성하려면 3TB 이상의 물리적 스토리지 용량이 필요합니다. 마찬가지로 저장소 공간 Direct를 사용하는 세 개 이상의 하드웨어 장애 도메인이 필요합니다. 즉, 3개의 서버를 의미합니다.
3방향 미러링을 사용하면 한 번에 두 개 이상의 하드웨어 문제(드라이브 또는 서버)를 안전하게 허용할 수 있습니다. 예를 들어 갑자기 다른 드라이브 또는 서버가 실패할 때 한 서버를 다시 부팅하는 경우 모든 데이터는 안전하고 지속적으로 액세스할 수 있습니다.
Parity
"지우기 코딩"이라고도 하는 패리티 인코딩은 비트 산술 연산을 사용하여 내결함성을 제공하므로 매우 복잡해질 수 있습니다. 이 작동 방식은 미러링보다 덜 분명하며, 아이디어를 얻는 데 도움이 되는 많은 훌륭한 온라인 리소스(예: 이 타사 인형 코딩 가이드)가 있습니다. 내결함성을 손상시키지 않으면서 더 나은 스토리지 효율성을 제공한다고 말하기에 충분합니다.
저장소 공간 패리티의 두 가지 맛을 제공합니다 - "단일"패리티와 "이중"패리티, 후자는 더 큰 규모에서 "로컬 재건 코드"라는 고급 기술을 사용.
Important
대부분의 성능에 민감한 워크로드에 미러링을 사용하는 것이 좋습니다. 워크로드에 따라 성능과 용량의 균형을 맞추는 방법에 대한 자세한 내용은 볼륨 계획을 참조 하세요.
단일 패리티
단일 패리티는 한 번에 하나의 오류에 대해서만 내결함성을 제공하는 비트 패리티 기호를 하나만 유지합니다. RAID-5와 가장 유사합니다. 단일 패리티를 사용하려면 3개 이상의 하드웨어 장애 도메인(저장소 공간 Direct 사용)이 필요합니다. 즉, 3개의 서버를 의미합니다. 3방향 미러링이 동일한 규모에서 더 많은 내결함성을 제공하므로 단일 패리티를 사용하지 않습니다. 하지만, 그것은 당신이 그것을 사용 하 여 주장 하는 경우 거기, 그리고 그것은 완전히 지원.
Warning
한 번에 하나의 하드웨어 오류만 안전하게 허용할 수 있으므로 단일 패리티를 사용하지 않는 것이 좋습니다. 갑자기 다른 드라이브 또는 서버가 실패할 때 한 서버를 다시 부팅하면 가동 중지 시간이 발생합니다. 서버가 3개뿐인 경우 3방향 미러링을 사용하는 것이 좋습니다. 4개 이상이 있는 경우 다음 섹션을 참조하세요.
이중 패리티
이중 패리티는 Reed-Solomon 오류 수정 코드를 구현하여 두 비트 패리티 기호를 유지하므로 3방향 미러링(즉, 한 번에 최대 두 번의 오류)과 동일한 내결함성을 제공하지만 스토리지 효율성은 향상됩니다. RAID-6과 가장 유사합니다. 이중 패리티를 사용하려면 4개 이상의 하드웨어 장애 도메인이 필요합니다. 즉, 저장소 공간 Direct는 4개의 서버를 의미합니다. 이 규모에서 스토리지 효율성은 50%입니다. 2TB의 데이터를 저장하려면 4TB의 물리적 스토리지 용량이 필요합니다.
이중 패리티의 스토리지 효율성은 하드웨어 장애 도메인을 50%에서 80%까지 증가합니다. 예를 들어 7개(저장소 공간 Direct를 사용하는 경우 7개의 서버)에서 효율성이 66.7%로 뛰어올라 4TB의 데이터를 저장하려면 6TB의 물리적 스토리지 용량만 필요합니다.
모든 규모의 이중 당사자 및 지역 재구성 코드의 효율성은 요약 섹션을 참조하세요.
로컬 재구성 코드
저장소 공간 "지역 재건 코드" 또는 LRC라는 Microsoft Research에서 개발한 고급 기술을 소개합니다. 대규모로 이중 패리티는 LRC를 사용하여 인코딩/디코딩을 몇 개의 작은 그룹으로 분할하여 쓰기를 하거나 실패에서 복구하는 데 필요한 오버헤드를 줄입니다.
HDD(하드 디스크 드라이브)의 경우 그룹 크기는 4개의 기호입니다. SSD(반도체 드라이브)가 있는 그룹 크기는 6개의 기호입니다. 예를 들어 하드 디스크 드라이브와 12개의 하드웨어 장애 도메인(서버 12개 의미)의 레이아웃은 다음과 같습니다. 4개의 데이터 기호로 구성된 두 개의 그룹이 있습니다. 72.7%의 스토리지 효율성을 달성합니다.
클라우스 조르겐센(Claus Joergensen)은 지역 재건 코드가 다양한 오류 시나리오를 처리하는 방법과 이러한 시나리오가 왜 매력적인지에 대한 심층적이면서도 읽기 쉬운 연습을 권장합니다.
미러 가속 패리티
저장소 공간 직접 볼륨은 부분 미러 및 부분 패리티일 수 있습니다. 미러된 부분에 먼저 토지를 쓰고 나중에 패리티 부분으로 점차 이동합니다. 실제로 미러 링을 사용하여 지우기 코딩을 가속화합니다.
3방향 미러와 이중 패리티를 혼합하려면 서버 4개를 의미하는 4개 이상의 장애 도메인이 필요합니다.
미러 가속 패리티의 스토리지 효율성은 모든 미러 또는 모든 패리티를 사용하여 얻을 수 있는 것 사이에 있으며 선택한 비율에 따라 달라집니다.
Important
대부분의 성능에 민감한 워크로드에 미러링을 사용하는 것이 좋습니다. 워크로드에 따라 성능과 용량의 균형을 맞추는 방법에 대한 자세한 내용은 볼륨 계획을 참조 하세요.
요약
이 섹션에서는 저장소 공간 Direct에서 사용할 수 있는 복원력 유형, 각 형식을 사용하기 위한 최소 크기 조정 요구 사항, 각 형식이 허용할 수 있는 오류 수 및 해당 스토리지 효율성을 요약합니다.
복원력 유형
| 복원력 | 오류 허용 오차 | 스토리지 효율성 |
|---|---|---|
| 양방향 미러 | 1 | 50.0% |
| 3방향 미러 | 2 | 33.3% |
| 이중 패리티 | 2 | 50.0% - 80.0% |
| 혼합 | 2 | 33.3% - 80.0% |
최소 크기 조정 요구 사항
| 복원력 | 필요한 최소 장애 도메인 |
|---|---|
| 양방향 미러 | 2 |
| 3방향 미러 | 3 |
| 이중 패리티 | 4 |
| 혼합 | 4 |
팁
섀시 또는 랙 내결함성을 사용하지 않는 한 장애 도메인 수는 서버 수를 나타냅니다. 저장소 공간 Direct에 대한 최소 요구 사항을 충족하는 한 각 서버의 드라이브 수는 사용할 수 있는 복원력 유형에 영향을 주지 않습니다.
하이브리드 배포의 이중 패리티 효율성
이 표에서는 HDD(하드 디스크 드라이브)와 SSD(반도체 드라이브)를 모두 포함하는 하이브리드 배포를 위해 각 규모에서 이중 패리티 및 로컬 재구성 코드의 스토리지 효율성을 보여 줍니다.
| 장애 도메인 | 레이아웃 | 효율성 |
|---|---|---|
| 2 | – | – |
| 3 | – | – |
| 4 | RS 2+2 | 50.0% |
| 5 | RS 2+2 | 50.0% |
| 6 | RS 2+2 | 50.0% |
| 7 | RS 4+2 | 66.7% |
| 8 | RS 4+2 | 66.7% |
| 9 | RS 4+2 | 66.7% |
| 10 | RS 4+2 | 66.7% |
| 11 | RS 4+2 | 66.7% |
| 12 | LRC (8, 2, 1) | 72.7% |
| 13 | LRC (8, 2, 1) | 72.7% |
| 14 | LRC (8, 2, 1) | 72.7% |
| 15 | LRC (8, 2, 1) | 72.7% |
| 16 | LRC (8, 2, 1) | 72.7% |
모든 플래시 배포에 대한 이중 패리티 효율성
이 표에서는 SSD(반도체 드라이브)만 포함하는 모든 플래시 배포의 각 규모에서 이중 패리티 및 로컬 재구성 코드의 스토리지 효율성을 보여 줍니다. 패리티 레이아웃은 더 큰 그룹 크기를 사용하고 전체 플래시 구성에서 스토리지 효율성을 높일 수 있습니다.
| 장애 도메인 | 레이아웃 | 효율성 |
|---|---|---|
| 2 | – | – |
| 3 | – | – |
| 4 | RS 2+2 | 50.0% |
| 5 | RS 2+2 | 50.0% |
| 6 | RS 2+2 | 50.0% |
| 7 | RS 4+2 | 66.7% |
| 8 | RS 4+2 | 66.7% |
| 9 | RS 6+2 | 75.0% |
| 10 | RS 6+2 | 75.0% |
| 11 | RS 6+2 | 75.0% |
| 12 | RS 6+2 | 75.0% |
| 13 | RS 6+2 | 75.0% |
| 14 | RS 6+2 | 75.0% |
| 15 | RS 6+2 | 75.0% |
| 16 | LRC(12, 2, 1) | 80.0% |
예제
서버가 두 개만 없는 경우 더 나은 내결함성을 제공하기 때문에 3방향 미러링 및/또는 이중 패리티를 사용하는 것이 좋습니다. 특히 저장소 공간 Direct를 사용하는 두 개의 장애 도메인이 동시 오류의 영향을 받는 경우에도 모든 데이터가 안전하고 지속적으로 액세스할 수 있도록 합니다.
모든 항목이 온라인 상태로 유지되는 예제
이 여섯 가지 예는 3방향 미러링 및/또는 이중 패리티 가 허용할 수 있는 것을 보여줍니다.
- 1. 드라이브 하나 손실(캐시 드라이브 포함)
- 2. 서버 1개 손실
- 3. 서버 1대와 드라이브 1대 손실
- 4. 서로 다른 서버에서 두 개의 드라이브가 손실됨
- 5. 최대 두 대의 서버가 영향을 받는 한 두 개 이상의 드라이브가 손실되었습니다.
- 6. 서버 2대 손실
... 모든 경우에 모든 볼륨은 온라인 상태로 유지됩니다. (클러스터가 쿼럼을 유지 관리해야 합니다.)
모든 항목이 오프라인으로 전환되는 예제
수명 동안 저장소 공간 충분한 시간이 주어지면 각 복원력으로 복원되기 때문에 많은 실패를 허용할 수 있습니다. 그러나 최대 두 개의 장애 도메인은 지정된 순간에 오류의 영향을 안전하게 받을 수 있습니다. 따라서 3방향 미러링 및/또는 이중 패리티 가 허용할 수 없는 예는 다음과 같습니다.
- 7. 한 번에 세 개 이상의 서버에서 드라이브 분실
- 8. 한 번에 3개 이상의 서버가 손실됨
사용
볼륨 만들기를 확인하세요.
다음 단계
이 문서에 언급된 주제에 대한 자세한 내용은 다음을 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기