MS_RAID - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki
ハードウェア RAID レベルの選択。
- RAID レベルと SQL Server
https://learn.microsoft.com/ja-jp/previous-versions/sql/sql-server-2008-r2/ms190764(v=sql.105)
DB サーバにとって、以下の RAID レベルが有用である。
- ストライプ化（RAID 0）
- ミラー化（RAID 1）
- パリティ付きストライプセット（RAID 5）
- ストライプ化、ミラー化（RAID 0 + 1）
RAID レベルの選択時は、
- 「コスト」
- 「性能」
- 「可用性と信頼性」
に関する要求事項を考慮する必要がある。
補足（RAID レベルの整理）: 前提として各レベルの性質を整理しておく。
レベル 構成 冗長性 書き込みペナルティ 容量効率 RAID 0 ストライピングのみ なし 1 100% RAID 1 ミラーリング 1 台まで 2 50% RAID 5 パリティ分散 1 台まで 4 (n-1)/n RAID 6 パリティ二重化 2 台まで 6 (n-2)/n RAID 10 (1+0) ミラー化したものをストライプ 構成による 2 50% 書き込みペナルティとは、1 回の論理書き込みに対して
実際に発生する物理 I/O 回数のこと。
RAID 5 が 4 なのは「旧データ読み + 旧パリティ読み +
新データ書き + 新パリティ書き」が必要なため（read-modify-write）。
これが本ページの比較表で RAID 5 の書き込みが△になっている理由である。
移行メモ（RAID 0 + 1 と RAID 1 + 0）: 元ページの「RAID 0 + 1」は、
厳密には
**「ストライプしたものをミラーする」（RAID 0+1）**と
**「ミラーしたものをストライプする」（RAID 1+0 / RAID 10）**の
2 通りがあり、耐障害性は RAID 10 のほうが高い。
実務で使われるのはほぼ RAID 10 である。
DB サーバは、ソフトウェア RAID ではなく、ハードウェア RAID を選択する。
通常、ソフトウェア RAID の負荷は低いが、CPU を使うため、
ハードウェア RAID が望ましい。
補足: ハードウェア RAID を選ぶもう一つの理由は
バッテリ／フラッシュ バックアップ付きライト キャッシュ（BBWC / FBWC）である。
これがあると書き込みをキャッシュに載せた時点で完了を返せるため、
トランザクション ログの書き込みレイテンシが大幅に改善する
（SQL Server のファイルの配置の
WRITELOGの話を参照）。
ただし、電源喪失時にキャッシュ内容が失われない構成であることが前提で、
ライトバック キャッシュをバッテリ無しで有効にしてはならない。
「データ ファイル」が壊れた場合、最新のデータにまで復旧するには、
最新の「トランザクション ログ バックアップ」が必要になる。
-
「データ ファイル」、「トランザクション ログ ファイル」の保存先ドライブを
別々に設定しておけば、「データ ファイル」を格納してあるドライブが
クラッシュした場合も、最新のデータ変更分を
「トランザクション ログ バックアップ」として取得でき、データの損失が減少する。 -
このため、一般的に「信頼性」の高いディスクに保存する必要があるのは、
「トランザクション ログ ファイル」の方である。
ただし、ドライブの冗長化では、物理的でない論理的な破壊
（例えば、間違ってデータを消してしまった場合など）には対応できないので、
「データ ファイル」、「トランザクション ログ ファイル」のバックアップは必要である。
補足（末尾ログ バックアップ）: ここで述べられているのは、
障害発生後に**末尾のログ バックアップ（tail-log backup）**を
取得できるかどうか、という話である。
ログ ファイルが生きていれば、
- 末尾のログ バックアップを取得
- 直近の完全バックアップを復元
- 以降のログ バックアップを順に適用
- 末尾のログを適用
という手順で障害直前まで復旧できる（データ損失ゼロ）。
詳細はSQL Server の障害復旧、
SQL Server のバックアップを参照。「RAID はバックアップの代わりにならない」という後半の指摘も重要で、
RAID が守るのはハードウェア障害のみである。
誤操作・論理破損・ランサムウェアには無力なので、
バックアップは別途必要になる。
-
一般的に「信頼性」の高いディスクに保存する必要があるのは、
「トランザクション ログ ファイル」の方であるため、- RAID 0 のドライブに「データ ファイル」を格納し、
- RAID 1 のドライブに「トランザクション ログ ファイル」を格納する。
-
これにより、DB に対する最良の I/O 処理速度が得られ、
- 「データ ファイル」のバックアップさえ取って置けば、
- 「データ ファイル」に障害が発生した場合も、データの損失が減少する。
補足（RAID 0 は実務では選ばない）: この構成は
「性能を最優先し、データ ファイルの障害はバックアップ + ログで復旧する」
という割り切りである。理屈は通っているが、
- 復旧に時間がかかる（完全バックアップの復元 + ログの適用）
- ディスクが 1 台でも壊れれば必ず停止する（RAID 0 に冗長性は無い）
ため、本番環境で採用されることはまずない。
実務では、データ ファイルも RAID 10 または RAID 5/6 に置く。
RAID 0 が許容されるのは、失っても再作成できる領域
（tempdb など）に限られる。
RAID 0, 1 以上の信頼性を必要とする場合は、
- RAID 5 のドライブに「データ ファイル」を格納し、
- RAID 1 のドライブに「トランザクション ログ ファイル」を格納する。
移行メモ（図の説明）: 元ページの図の代替テキストは
「RAID 0, 1 のボリューム レイアウト」となっていたが、
本節の内容から「RAID 1, 5 のボリューム レイアウト」の誤記と判断し修正した。
「性能」、「可用性と信頼性」を考慮した、
「RAID 5」、「RAID 0 + 1」の選択には、次を参考にする。
| 項番 | 比較項目 | RAID 5 | RAID 0 + 1 | |
|---|---|---|---|---|
| 1-1 | 性能 | シーケンシャル読み出し | ◎ | ◎ |
| 1-2 | 〃 | シーケンシャル書き込み | △ | ◎ |
| 1-3 | 〃 | ランダム読み出し | ◎ | ◎ |
| 1-4 | 〃 | ランダム書き込み | △ | ○ |
| 1-5 | 〃 | リビルド | △ | ◎ |
| 2 | 耐障害性 | ○ | ◎ |
- 「RAID 5」は、書き込み処理よりも読み取り処理を得意とし、
「RAID 0 + 1」よりも負荷が低いシステムに向く。 - 「RAID 0 + 1」は、書き込みが中心となる処理および tempdb へのアクセスを得意とし、
「RAID 5」より負荷が大きいシステムに向く。
補足（リビルドが
△である重み）: RAID 5 のリビルドは
残り全ディスクを読んでパリティから復元するため、
大容量ディスクでは数十時間かかることがある。
その間は性能が落ちるうえ、冗長性がゼロの状態が続くため、
2 台目が壊れると全データを失う。このリスクから、現在の大容量 HDD 構成では
RAID 5 は避け、RAID 6 または RAID 10 を選ぶのが定石になっている。
補足（最新化：SSD / クラウド時代の考え方）: 本ページは
HDD のシーク時間が支配的だった時代の設計論である。
現在は前提が変わっている。
論点 当時 現在 分離の目的 ヘッド移動の削減 I/O 帯域と IOPS の確保 ボトルネック シーク時間 スループット上限・レイテンシ RAID の担い手 サーバ内蔵コントローラ SAN / ストレージ装置 / クラウドのマネージド ディスク 書き込みペナルティ 支配的 SSD でも RAID 5/6 では残る（加えて書き込み寿命の問題） クラウド（Azureのストレージ、
Azureのディスク ストレージ）では、
RAID レベルを選ぶのではなく
ディスクの SKU（Premium SSD / Ultra Disk）と
IOPS・スループットの上限を選ぶ設計になる。
複数ディスクをストライプ（記憶域スペース）して
上限を積み上げる手法は現在も有効である。ただし、「ログとデータを分ける」「tempdb を分ける」という原則自体は
現在も有効である。理由がシーク時間から
I/O 上限の分離に変わっただけで、結論は変わらない。
Tags: 移行, データアクセス, SQL Server, 障害対応