EC2 Windows Serverのボリューム設計について
しばたです。
たまに同僚から質問されるので自分なりの考えをブログにまとめておくことにしました。
はじめに
Windowsのボリュームとドライブ
Windows OSにおけるディスク構成は、(OSから見た物理ディスクである)ディスクを起点としてディスク内にパーティションとボリュームを構成、ボリュームにドライブレターを割り当ててファイルシステムからアクセスするのが基本になります。
1つのディスク内に複数のボリュームを割り当てることが可能です。
本記事ではこの点についてざっくり、
- 一つのディスク内にすべてのボリューム(≒ドライブ)を構成すべきか
- ディスクごとにボリューム(≒ドライブ)を分けるべきか
(1つのディスクに複数のボリュームを構成する例)
(ディスクごとにボリュームを構成する例)
を考えていきます。
また、Windows EC2においてディスクとなるのはEBSおよびインスタンスストアとなりますが、本記事ではEBSについてのみ考えます。
IOPSから見たディスク設計
2020年6月現在、デフォルトであり、一番利用されるであろうボリュームタイプの汎用SSD(gp2)ではボリュームの容量が大きいほどベースラインとなるIOPSが上がり、IOPSをバーストさせた際のクレジットを再補充させる時間が減る特性があります。
極めて雑に言ってしまうとボリュームのサイズが多いほどパフォーマンスが上がるという話であります。
私の基本設計
私はこの特性を重視し、特段の事情が無い場合はできるだけEBSを1つにまとめる設計をする様にしています。
このためWindowsのボリューム設計も「一つのディスクにすべてのボリュームを構成する」のを基本とし、明確な理由がある場合に「ディスクおよびボリュームを分割する」というのを基本にしています。
ディスク(EBS)を分割すべき場合
ではどの様な場合にディスクを分割するべきかについて私が重視する点を記述します。
容量拡張の観点から
最初に例示した1つのディスクに複数のボリュームを構成する場合を例にとると、この場合
- ボリューム1(Cドライブ) : 50GB
- ボリューム2(Dドライブ) : 50GB
で構成されていますが、ここからさらにEBSを拡張するとDドライブの後に未割り当ての領域が増えることになりCドライブはこれ以上拡張することができません。
Cドライブの初期サイズを抑え目にしつつ拡張の余地も欲しいといった場合はCドライブとその他のドライブをボリューム分割しておくと良いでしょう。
バックアップの観点から
AWSの標準機能でバックアップとして利用可能な機能はEBSスナップショットになります。
クラッシュ整合性のあるスナップショットも利用できますが、単純に一つのEBSを管理する方が運用はしやすいと思います。
ただ、明確にライフサイクルの違うデータを扱う場合はEBSを分割して個別にバックアップを管理した方が良い場合もあります。
簡単な例としては、ファイルサーバーとしてWindows Serverを運用する際に別のEBSボリュームにDドライブを用意し共有フォルダを設定しておけば、OS(Cドライブ)のバックアップと共有フォルダ(Dドライブ)のバックアップを分離することができリストアの幅も広がります。
この他にもWindows Server Backupなどのバックアップソフトがバックアップ先に個別のドライブやボリュームを要求する場合は必然的にEBSを分割する必要があります。
耐障害性の観点から
EBSの物理構成は公開されてないためEBSボリュームを分割することが物理障害に対してどの様な効果があるのかは正直わかりません。
EBSボリュームを分割すればデータの物理的な配置がよしなに分散されるということも無いでしょうし、恐らくはボリュームを分割しようがしまいが物理障害に対する耐性は変わらないと思っています。
代わりにファイルシステム上のブロック破損や書き込みエラーによる論理障害についてはEBSボリュームを分割することにより影響範囲を明確に分離することができます。
論理障害による影響範囲を最小化したい場合はEBSボリュームを分割すると良いでしょう。
記憶域スペースの利用
そこまで利用するケースは多くないかもしれませんが、EC2 Windows Serverで記憶域プールや記憶域スペースダイレクトといった機能を利用する場合はEBSボリュームの分割が必要です。
- チュートリアル: Amazon EC2 で記憶域スペースダイレクト (Storage Spaces Direct: S2D) を展開する
- 無停止でストレージ容量を拡張を行えるWindows Server 2012の記憶域プールを使ってみた
単純に拡張可能なボリュームが必要なだけならEBSの標準機能で賄えますので、求められる要件をきちんと検討した上でこれらの機能を採用すると良いでしょう。
用途の観点から
ここまでの内容を踏まえつつも単純に用途別にEBSボリュームを分割してドライブを分けることも有ります。
私の場合は容量拡張の観点と併せて考えることが多く、容量の予測がつかない用途の場合にEBSボリュームを分割するといった判断をすることが多いです。
最後に
思うがままに書きましたがざっとこんな感じです。
自分で記事を書いておいておきながらまとまりがないなぁと思っているのですが、これまで述べた観点をどう判断するかは結局は要件次第であり都度個別に判断するしかありませんので仕方ないとも思ってます。
最初にお断りしている様に本記事の内容は私個人の考えですので参考程度に捉えていただければ幸いです。
