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