1月7日、旧ブログに40件超のアクセスがあった。参照先投稿は2005年のもので、Windowsファイル・サーバーの運用に関する投稿だ。
当時のWindows serverと言えば、Windows 2000 serverか、Windows server 2003で、ストレージ装置に採用されている技術も、現在とは大きく異なっている。ストレージ装置編成からサーバー自身のチューニングに気を配る必要があった時代だ。
例えば、SSDは存在しないため、一次アクセス層にSSDを配置し、その背後にHDDを配置することで、HDD RAIDのIOPSを気にせず運用する、ということはできない。
とはいえ、まだそのような時代の情報にも需要があるのかもしれない、と移行することにした。
- RAID
- 冗長化
- 遠隔地バックアップ
- ストレージ機器のチューニング
- Windows serverのチューニング
- Defrag
- 利用領域制限、破損snapshotと空き領域確保
- 利用領域制限と単位容量あたりの課金
- 参照
念のため、もう一度触れておく。これは2005年に投稿されたもので、その内容を再編して移行したものだ。
次のブログ*1にて、ファイル・サーバーでのトラブルと、その対応策について触れている。業務で利用されるITインフラとして考えたとき、その対応に最も影響するのは、次の事柄だろう。
- 経営陣のインフラに対する理解
- 経営陣のインフラに対するリスク認識
- 組織の懐具合
導入危機から、対応可能な事柄についての制約は、これらに起因している。その事情は組織によって異なるとはいえ、まずセオリーを知っておくことは大切だ。
件のブログでは、次のことに触れている。
ゼロ年代の.comバブル時代、日本のスタートアップ企業の中には、1～2のような運用からスタートし、それを継続していた企業が存在した。そのような例外的な場合を除き、普通のIT企業、IT部門にとって、これらは定石だ。
RAID
金融機関のIT部門のように、比較的資金に余裕があり、特にパフォーマンスについて理解のある組織の場合、冗長化と高速化を兼ね備えた、RAID10 + HotSpareを標準としている組織もある。
冗長化
冗長化は、最も導入が難しい要素だ。単純にコストは倍になる。しかも、そのコストは「使われることのない余剰」への投資だからだ。例えるならば、スペア・タイヤへの投資、のようなものだ。経営陣が「保険」的な投資を理解していなければ、まず導入は成功しない。
障害復旧（リストア）時間⇔導入コスト⇔ダウン・タイム＝0
このトレードオフ関係を前提に、組織的な検討を始める。組織によっては、冗長化構成はオーバー・スペックで、D2Dバックアップによるリストア時間の軽減でも十分な場合もある。
いきなり冗長化を採用しようとするのではなく、必要とされる事柄を前提に、それに対応し得る最低限の構成提案からアプローチを始めるべきだろう。
遠隔地バックアップ
データセンターを活用するような組織であれば、バックアップ・メディアを現場と遠隔地でローテーション運用する業務は、既に日常業務に組み込まれていることだろう。
これはバックアップの世代管理だけでなく、バックアップ配置のリスク分散、DR (Disaster Recovery)対策にも関連する事柄だ。ただバックアップについての事柄にのみに思考、理解を限定するのではなく、組織として「どのようにあるべきか」を前提に検討する必要のある領域だ。
ストレージ機器のチューニング
ストレージ機器にもチューニングの要素がある。
- キャッシュの有効化
- ページ・ファイルの単位サイズ
特に後者は、利用用途に応じた適正サイズがある。端的には、対象データ（ファイル）の特性に関連している。
- 更新頻度
- サイズ
- 参照頻度
| 用途 | キャッシュ・サイズ |
|---|---|
| DB | 少な目 |
| ファイル・サーバー | 頻繁に利用されるファイル・サイズに応じたサイズ |
| CAD 映像データ |
大きめ～最大値 |
Windows serverのチューニング
Windows serverを、ファイル・サーバーのOSに採用している場合、そこにもチューニングの余地がある。次のレジストリ・キーを操作する。特に「IrpStackSize」、「MaxWorkItems」の適切な値は、環境によって異なることに注意。
| Key | 値（10進数） |
|---|---|
| IrpStackSize*2 | 18 |
| MaxFreeConnections | 最大値 |
| MinFreeConnections | 最大値 |
| MaxRowWorkItems | 最大値 |
| MaxWorkItems | 16384 |
Defrag
元々は単一のまとまった領域に記録されていたファイルが、参照、更新を繰り返すごとに、記録領域が部分的に複数の領域へ分散していく。このような分散は「fragment」（フラグメント＝断片）と呼ばれる。この断片化を解消し、単一のまとまった領域に書き戻すのがDefragだ。
データの記録領域が断片化するということは、相対的に見れば空いている記録面も断片化するということだ。つまりDefragとは、ファイルをひとまとまりに書き戻すのと同時に、断片化した空き領域を、単一の大きな空き領域に戻す作業、とも表現できる。
３～４年間、Defragしないまま運用されていたサーバーがあった。このような運用を継続すると、データだけでなく、空き領域までも断片化される。断片化され過ぎると、まとまった空き領域は皆無な状態となる。こうなると、ストレージ全体のIOパフォーマンスが極端に低下し、数値上は空き領域がありながらも、実態は空き領域として十分に機能しない状態となる。
Defragは、データの断片化を解消するというよりも、空き領域をまとまった状態で維持するために必要とされる。
利用領域制限、破損snapshotと空き領域確保
Quotaを課す目的は、ユーザーの使用領域を制限することにある。しかし、運用上の本質的な目的は、ストレージの一定容量を、常に空き領域として確保しておくことにある。Quota制限の合計値を、ストレージ最大容量の70～80%に維持しておく。
盲点になりやすいのが、バックアップ時に作成されるsnapshotだ。特にバックアップ失敗時に生成されたsnapshotが、削除されないまま残されているときがある。snapshotのサイズは大きく、無駄に記録領域を占有し続けることになる。
snapshot領域を調整すると同時に、バックアップ失敗時に残されたsnapshotの削除を忘れないこと。
利用領域制限と単位容量あたりの課金
例えば100円/GBのように、単位容量当たりのコストを定め、利用領域制限と合わせて運用する。実際にユーザーから代金を徴収するかは別として、これを定期的に評価することで、経営陣を含めたユーザーに、次のコストを具体的に意識させることができる。
- ユーザーごとの使用量→使用料→コスト意識
- 応分のコスト負担→ストレージ、サーバー増設、消費メディア
基本的にITインフラは社内共有が前提であるとはいえ、その管理をIT部門が100%請け負うとしても、そのコストまでも100%請け負う必要はない。組織のプール資金に加えて、ユーザーの使用量に基づいた応分負担を加味した上で、ITインフラのライフ・サイクルを決定する。そのようにすれば、空き容量がが少なくなったから増設、といった後手の対応は減少するはずだ。
