Azure Stack HCI および Windows Server クラスターでのフォールト トレランスと記憶域の効率性
適用対象: Azure Stack HCI バージョン 22H2 および 21H2。Windows Server 2022、Windows Server 2019
重要
Azure Stack HCI が Azure Local の一部になりました。 製品ドキュメントの名前変更が進行中です。 ただし、古いバージョンの Azure Stack HCI (22H2 など) は引き続き Azure Stack HCI を参照し、名前の変更は反映されません。 詳細情報。
この記事では、使用できる回復性オプションについて説明し、スケール要件、記憶域の効率性、それぞれの一般的な利点とトレードオフについて説明します。
概要
記憶域スペース ダイレクトは、一般に "回復性" と呼ばれる、データのフォールト トレランスを提供します。 その実装は、複数のサーバーに分散してソフトウェアで実装される点を除いて、RAID に似ています。
RAID と同様に、記憶域スペースでこれを実現する方法がいくつかあり、フォールト トレランス、記憶域の効率性、コンピューティングの複雑さの間でさまざまなトレードオフを行います。 これらは、"ミラーリング" と "パリティ" の 2 つのカテゴリに大別されます。後者は "イレージャー コーディング" と呼ばれることもあります。
ミラーリング
ミラーリングを使ってあらゆるデータのコピーを複数保持することによって、フォールト トレランスが実現します。 これは、RAID-1 と最もよく似ています。 データのストライピングと配置の方法は簡単ではありません (詳細については、このブログ を参照 )。ただし、ミラーリングを使用して格納されたデータは、全体として複数回書き込まれると言えます。 コピーはそれぞれ、障害の発生が個別にとどまることが想定される別々の物理ハードウェア (別のサーバーの別のドライブ) に書き込まれます。
ミラーリングには、"双方向" と "3 方向" の 2 種類があります。
双方向ミラー
双方向のミラーリングでは、すべてのコピーが 2 つ書き込まれます。 そのストレージ効率性は 50% です。1 TB のデータを書き込むには、少なくとも 2 TB の物理記憶領域容量が必要です。 同様に、少なくとも 2 つのハードウェア "障害ドメイン" が必要です。記憶域スペース ダイレクトでは、これは 2 台のサーバーを意味します。
警告
3 台以上のサーバーがある場合は、代わりに 3 方向のミラーリングを使用することをお勧めします。
3 方向ミラー
3 方向のミラーリングでは、すべてのコピーが 3 つ書き込まれます。 そのストレージ効率性は 33.3% です。1 TB のデータを書き込むには、少なくとも 3 TB の物理記憶領域容量が必要です。 同様に、少なくとも 3 つのハードウェア障害ドメインが必要です。記憶域スペース ダイレクトでは、これは 3 台のサーバーを意味します。
3 方向ミラーリングでは、少なくとも 2 つのハードウェア (ドライブまたはサーバー) に問題が発生した場合でも、安全に耐えることができます。 たとえば、あるサーバーの再起動中に別のドライブまたはサーバーに突然障害が発生した場合でも、あらゆるデータが安全かつアクセス可能な状態に保たれます。
パリティ
パリティ エンコード ("イレージャー コーディング" と呼ばれることもあります) では、ビットごとの算術演算を使用してフォールト トレランスを実現します。これは、非常に複雑になる可能性があります。 このしくみは、ミラーリングほど明確ではありませんが、理解に役立つ多くの優れたオンラインリソースがあります (たとえば、このサードパーティの「Dummies Guide to Erasure Coding」など)。 これは、フォールト トレランスを損なうことなく、より高いストレージ効率を実現します。
記憶域スペースは、"シングル" パリティと "デュアル" パリティの 2 種類のパリティを提供します。後者では、大規模なスケールで "ローカル再構築コード" と呼ばれる高度な手法が採用されています。
重要
ほとんどのパフォーマンスを重視するワークロードにはミラーリングを使用することをお勧めします。 ワークロードに応じてパフォーマンスと容量のバランスを取る方法の詳細については、「ボリュームの計画」を参照してください。
シングル パリティ
シングル パリティではビットごとのパリティ符号が 1 つだけ保持されるため、一度に 1 つの障害に対してのみフォールト トレランスが提供されます。 これは、RAID-5 と最もよく似ています。 シングル パリティを使用するには、少なくとも 3 つのハードウェア障害ドメインが必要です。記憶域スペース ダイレクトでは、これは 3 台のサーバーを意味します。 3 方向のミラーリングでは、同じスケールでより高いフォールト トレランスが実現するため、単一パリティの使用はお勧めできません。 ただし、使用を主張する場合はそこにあり、完全にサポートされています。
警告
シングル パリティの使用をお勧めしない理由は、一度に 1 つのハードウェア障害に対してのみ、安全に耐えることができるためです。あるサーバーを再起動しているときに、突然別のドライブまたはサーバーで障害が発生した場合、ダウンタイムが発生します。 サーバーが 3 台のみある場合は、3 方向のミラーリングを使用することをお勧めします。 4 台以上の場合は、次のセクションを参照してください。
デュアル パリティ
デュアル パリティでは、リードソロモンの誤り訂正符号を実装してビットごとの 2 つのパリティ符号を保持します。これにより、3 方向のミラーリングと同じフォールト トレランス (最大で一度に 2 つの障害) が実現されますが、ストレージの効率性が向上します。 これは、RAID-6 と最もよく似ています。 デュアル パリティを使用するには、少なくとも 4 つのハードウェア障害ドメインが必要です。記憶域スペース ダイレクトでは、これは 4 台のサーバーを意味します。 そのスケールでは、ストレージ効率性は 50% です。2 TB のデータを格納するには、4 TB の物理記憶領域容量が必要です。
デュアル パリティのストレージの効率性によって、ハードウェア障害ドメインが 50% から最大 80% に増加します。 たとえば、7 (記憶域スペース ダイレクトでは 7 台のサーバー) では、効率性は 66.7% に上昇します。4 TB のデータを格納するために、6 TB の物理記憶領域容量のみが必要です。
すべてのスケールでのデュアル パリティおよびローカル再構築コードの効率性については、「まとめ」セクションを参照してください。
ローカル再構築コード
記憶域スペースには、Microsoft Research によって開発された、"ローカル再構築コード" または LRC と呼ばれる高度な手法が導入されています。 大規模なデュアル パリティでは、LRC を使用してエンコード/デコードをいくつかの小さなグループに分割し、書き込みまたは障害からの復旧に必要なオーバーヘッドを軽減します。
ハード ディスク ドライブ (HDD) では、グループのサイズは 4 つの符号です。ソリッドステート ドライブ (SSD) では、グループのサイズは 6 つの符号になります。 たとえば、ハード ディスク ドライブと 12 個のハードウェア障害ドメイン (12 台のサーバー) のレイアウトは次のようになります。4 つのデータ符号のグループが 2 つあります。 これは 72.7% のストレージ効率性を達成します。
Claus Joergensen による、非常に詳細でありながら読みやすいチュートリアルである、「ローカル再構築コードによるさまざまな障害シナリオへの対応とその優位性」を参照することをお勧めします。
ミラー高速パリティ
記憶域スペース ダイレクトのボリュームは、一部をミラーにし、一部をパリティにすることができます。 書き込みは、最初はミラー化された部分で処理され、その後パリティ部分に徐々に移動します。 事実上、これは、ミラーリングを使用してイレージャー コーディングを高速化しています。
3 方向ミラーとデュアル パリティを混在させるには、少なくとも 4 つの障害ドメイン (つまり 4 台のサーバー) が必要です。
ミラー高速パリティのストレージ効率性は、すべてミラーまたはすべてパリティを使用する場合の間になり、選択する比率によって異なります。
重要
ほとんどのパフォーマンスを重視するワークロードにはミラーリングを使用することをお勧めします。 ワークロードに応じてパフォーマンスと容量のバランスを取る方法の詳細については、「ボリュームの計画」を参照してください。
まとめ
このセクションでは、記憶域スペース ダイレクトで使用できる回復性の種類、各種類を使用するための最小スケール要件、各種類で許容される障害の数、および対応するストレージ効率性についてまとめます。
回復性の種類
| 回復性 | 障害の許容値 | ストレージ効率性 |
|---|---|---|
| 双方向ミラー | 1 | 50.0% |
| 3 方向ミラー | 2 | 33.3% |
| デュアル パリティ | 2 | 50.0% から 80.0% |
| 混在 | 2 | 33.3% から 80.0% |
最小スケール要件
| 回復性 | 最低限必要な障害ドメイン |
|---|---|
| 双方向ミラー | 2 |
| 3 方向ミラー | 3 |
| デュアル パリティ | 4 |
| 混在 | 4 |
ヒント
シャーシまたはラック フォールト トレランスを使用している場合を除き、障害ドメインの数はサーバーの数を示します。 各サーバーのドライブ数は、記憶域スペース ダイレクトの最小要件を満たしている限り、使用できる回復性の種類には影響しません。
ハイブリッド デプロイのデュアル パリティ効率性
次の表は、ハード ディスク ドライブ (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% |
例
サーバーが 2 台しかない場合を除き、フォールト トレランスの向上を実現するため、3 方向のミラーリングとデュアル パリティ (またはそのいずれか) を使用することをお勧めします。 具体的には、2 つの障害ドメイン (記憶域スペース ダイレクトでは 2 台のサーバー) が同時障害の影響を受ける場合でも、すべてのデータが安全に維持され、継続的にアクセス可能であることが保証されます。
すべてがオンラインを維持する例
これらの 6 つの例では、3 方向のミラーリングやデュアル パリティが何を許容できるかを示しています。
- 1. 1 つのドライブの障害 (キャッシュ ドライブを含む)
- 2. 1 台のサーバーの障害
- 3. 1 台のサーバーと 1 つのドライブの障害
- 4. 異なるサーバーの 2 つのドライブの障害
- 5. 3 つ以上のドライブの障害 (影響を受けるサーバーが最大で 2 台)
- 6. 2 台のサーバーの障害
...どの場合も、すべてのボリュームはオンラインのままです。 (クラスターがクォーラムを維持していることを確認してください)。
すべてがオフラインになる例
その有効期間にわたって、記憶域スペースは、各障害の後に十分な時間があれば完全な回復性を復元するため、何回もの障害を許容できます。 ただし、特定の時点で障害の影響を問題なく受けることができるのは、最大で 2 つの障害ドメインです。 したがって以下に示すのは、3 方向のミラーリングやデュアル パリティが許容できない例です。
- 7. 一度に 3 台以上のサーバーでドライブの障害が発生する
- 8. 3 台以上のサーバーで同時に障害が発生する
使用方法
ボリュームの作成に関する記事を確認してください。
次のステップ
この記事で説明されている項目の詳細については、以下を参照してください。