当記事では、インフラエンジニア向けにサーバーのディスク容量設計について解説します。
ディスク認識に伴うオーバーヘッドによる実効容量の減少については、下記の記事を参照ください。
Contents
システム領域とデータ領域の容量設計
インフラエンジニアとして、サーバーを導入する場合、ディスク領域の設計が不可欠です。
OSやミドルウェアをインストールするシステム領域と、業務データを格納するデータベースなどのデータ領域についてそれぞれ設計のポイントを解説します。
システムディスクの容量見積もり
OSをインストールするシステムディスクは、下記の領域に細分化し設計する必要があります。
- ブート領域：Linuxの/boot、WindowsのEFIシステムパーティション
- システムファイル領域：OS本体の格納先
- ミドルウェアインストール領域：ミドルウェアのデータ格納先
- ログ領域：OS、ミドルウェアが出力するログファイルの出力先
- ユーザ領域：/homeなど一般ユーザがデータを格納する領域。自由に使える領域。
- swap領域：スワップアウト領域、またはページングファイルの格納先
- メモリダンプ領域：OSクラッシュ時のメモリダンプ出力先。
システムディスクの各領域は以下の要領を必要とします。
ブート領域
UEFIモードの場合、/bootは1GB、/boot/efiは256GBが推奨です。
システムファイル領域
OS単体の容量に、ミドルウェアのインストール容量を加えます。
また、OSと、ミドルウェアの修正パッチの適用による増加を見込んだ容量を設計します。各OS、各ミドルウェアの修正パッチの容量を概算で加えるようにします。
ログ領域
ログの最大サイズ x ログの保存世代数 で見積もります。
OS、ミドルウェアが出力する容量をマニュアルから見積もります。
ユーザ領域
一般ユーザが格納するデータ容量を見積もります。
サーバのユーザ領域はアプリケーションによってコントロールされることが多いため、導入するアプリケーションの仕様を確認します。
swap領域
RHEL7（RedHat Enterprise Linux 7）OSの場合、RehHat社の推奨は下記のとおりです。
しかし、大容量メモリを搭載しており、アプリケーションがswapを期待していない場合は、最低限の容量で見積もって良いものとします。これは、サーバーハードウェアベンダーの推奨値がある場合がありますので、まずは公式ドキュメントを確認し、情報が見当たらなければ、サポートセンターに問い合わせを行いましょう。
個人的な構築事例を紹介すると、1TB以上の物理メモリを搭載している場合に、搭載メモリ容量の12%程度の128GBのswap領域としました。
Windows OSの場合は、ページングファイルが該当します。下記のメモリダンプの見積もりに詳細を記載しますが、搭載メモリ容量と同等の容量設計となります。
メモリダンプ領域
メモリダンプの見積もりが非常に重要です。
しかし、ここ数年でメモリの大容量化が進み、サーバに搭載するメモリ容量は過去と比較して増大しています。
搭載メモリ容量が大きいと、その分出力されるメモリダンプも大容量になります。1TB以上のメモリダンプを1ファイルとして出力するなんていうことも珍しいサーバ構成ではなくなりつつあります。
大容量のメモリダンプは、OSサポートに解析を依頼する際に注意が必要です。メモリダンプを送る際にネットワーク転送を行うことが考えられますが、そのままの容量ではネットワーク側で転送容量が制限され、送信出来ない場合があります。転送できたとしても、1TBを超える場合には相当時間を要します。
大容量メモリダンプの送信には、まず圧縮を行うようにします。私の環境で1.2TBを圧縮したところ22GBになりました。メモリの使われ方によってこのサイズは異なります。
また、この圧縮処理にも数時間要する場合があります。この時、3時間ほど要していますが、サーバーの性能によって異なります。数十GBの転送もネットワークの制限で難しい場合は、圧縮したメモリダンプをsplitコマンドで分割し、転送後に結合するよう手順を添えてサポートに依頼すると良いかと思います。
Windows Serverの場合、メモリダンプの容量見積もりには更に注意が必要です。メモリをすべてダンプするか、カーネルのみダンプするなどの方式を選定できます。フルダンプの場合、ページングファイルの配置先によって、出力される際の一時ファイルの生成が発生するため、最大でメモリ容量の3倍もの容量が必要になるケースがあります。
ページングファイルがメモリダンプ領域と同じドライブに設計されている場合は、最大で搭載メモリ容量の約2倍ですが、別のドライブにメモリダンプ出力用のディスクを分けて設計している場合は、約3倍必要です。
詳細は下記の技術情報が参考になります。
https://jp.fujitsu.com/platform/server/primergy/technical/construct/pdf/win2008-memory-dump.pdf
業務データ領域の容量見積もり
業務データの容量見積もりも、システム開発において必要な観点です。
サンプルデータ量がある場合は、運用期間中の増減も含めて容量を設計する必要があります。運用開始時点は100GBだけど、システムのユーザ数から想定のデータ増加量を計算し、5年間運用したら200GBになる、といったような設計が必要になります。
そしてその想定を超える可能性も検討しておく必要があります。もしも想定以上のユーザ増加があったり、次節の出来事などで想定以上のシステム負荷が発生することも大いにあり得ます。
5年持つとおもったけど、3年経った時点で200GBに達しちゃいました、となると大問題です。今年はオリンピックイヤーですので、関連システムの開発担当者はこの辺りも意識して去年設計していたようです。
といっても読み切れないケースは多々ありますので、最終的には容量が余るよう多めに設計します。何らかの根拠をつけて、1.2倍程度に設計することが多く、この設計をバッファを積むという表現をします。
しきい値監視を意識する
全ての設計は運用を考慮して行わなければいけません。容量に関しても例外ではありません。
ディスクに関しては、実際の運用中にシステム監視運用担当者によって容量が、一定の値を超えていないか監視することが一般的です。これをしきい値監視といいます。漢字だと「閾値」です。
システムの要件によって異なりますが、「容量が80%を超えた場合に警告メッセージを出力する」などという定義を監視用のミドルウェアにて設定することになります。容量が満タンにならないように、見守る仕組みを作るということです。
ざっくり数字を出して、例を挙げます。
そのディスクに保存したいデータの総量が75GBであったとします。業務データのバッファも込みの容量です。
そしてそのディスクの監視しきい値を80％とします。
この場合にストレージのボリューム容量を75GBになるように設計したらどうなるでしょうか。
ファイルシステム作成までの過程で75GBの容量より小さくなります。ファイルシステムを作成すると、約70GB程度になりますので、欲しい容量を満たすことができません。
そのため、75GBの80％（未満にしなければならない点に注意）を計算すると約90GB以上のファイルシステム容量があれば、ディスク使用率は78％となるので問題なさそうです。
90GBのファイルシステムを作成するためには約10%のオーバーヘッドがあるとし多めに見積もって、ストレージで100GBのボリュームがあれば良いことになります。まとめると下記のとおりです。
設計条件
必要な容量 ： 75GB
監視しきい値： 80%
設計内容
ボリューム容量：100GB
実効容量 ： 90GB （75GBのデータ格納で使用率78%）
意外とこのしきい値を考慮した見積もりをを忘れがちなので要注意です。
しきい値が80％なのに、いざデータを入れてみると87%になってしまった、など、冗談ではなくよく発生します。その度に設計や構築作業の手戻りが発生し、プロジェクト進行の大きな妨げとなります。
まとめ
ディスク容量の設計は、インフラエンジニアにとって基本であり、後戻りのできない重要な設計ポイントです。
設計が甘く、容量が足りないとなった場合にはディスクの追加作業が必要になります。作業だけではなく、当然ディスク装置の追加費用が発生します。上流のプロジェクトマネージャやエンドユーザにも説明や調整のアクションを求めなければならないことになります。
さらに、各ミドルウェアの設計に大きく変更を要求する必要性も発生します。バックアップソフトウェアなどを導入し、構築している場合は、定義変更と実機の設定変更にも影響が及び可能性があり、担当SEは追加でそれらの作業を行わなければならないこととなります。
影響範囲はディスクを単純に追加するだけではないということを念頭に、注意深く設計するようにしましょう。
