Web Analytics

Technically Impossible

Lets look at the weak link in your statement. Anything "Technically Impossible" basically means we haven't figured out how yet.

ファイル・サーバーの運用

1月7日、旧ブログに40件超のアクセスがあった。参照先投稿は2005年のもので、Windowsファイル・サーバーの運用に関する投稿だ。

当時のWindows serverと言えば、Windows 2000 serverか、Windows server 2003で、ストレージ装置に採用されている技術も、現在とは大きく異なっている。ストレージ装置編成からサーバー自身のチューニングに気を配る必要があった時代だ。
例えば、SSDは存在しないため、一次アクセス層にSSDを配置し、その背後にHDDを配置することで、HDD RAIDのIOPSを気にせず運用する、ということはできない。

とはいえ、まだそのような時代の情報にも需要があるのかもしれない、と移行することにした。


念のため、もう一度触れておく。これは2005年に投稿されたもので、その内容を再編して移行したものだ。

次のブログ*1にて、ファイル・サーバーでのトラブルと、その対応策について触れている。業務で利用されるITインフラとして考えたとき、その対応に最も影響するのは、次の事柄だろう。

  • 経営陣のインフラに対する理解
  • 経営陣のインフラに対するリスク認識
  • 組織の懐具合

導入危機から、対応可能な事柄についての制約は、これらに起因している。その事情は組織によって異なるとはいえ、まずセオリーを知っておくことは大切だ。

件のブログでは、次のことに触れている。

  1. ATA HDDは利用しない。
  2. 普通のPCを利用しない。
  3. RAID5 + HotSpare, RAIO1 + HotSpare構成を推奨。
  4. サーバーの冗長化
  5. バックアップと遠隔地への分散。

ゼロ年代の.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とは、ファイルをひとまとまりに書き戻すのと同時に、断片化した空き領域を、単一の大きな空き領域に戻す作業、とも表現できる。

3~4年間、Defragしないまま運用されていたサーバーがあった。このような運用を継続すると、データだけでなく、空き領域までも断片化される。断片化され過ぎると、まとまった空き領域は皆無な状態となる。こうなると、ストレージ全体のIOパフォーマンスが極端に低下し、数値上は空き領域がありながらも、実態は空き領域として十分に機能しない状態となる。

Defragは、データの断片化を解消するというよりも、空き領域をまとまった状態で維持するために必要とされる。

利用領域制限、破損snapshotと空き領域確保

Quotaを課す目的は、ユーザーの使用領域を制限することにある。しかし、運用上の本質的な目的は、ストレージの一定容量を、常に空き領域として確保しておくことにある。Quota制限の合計値を、ストレージ最大容量の70~80%に維持しておく。

盲点になりやすいのが、バックアップ時に作成されるsnapshotだ。特にバックアップ失敗時に生成されたsnapshotが、削除されないまま残されているときがある。snapshotのサイズは大きく、無駄に記録領域を占有し続けることになる。
snapshot領域を調整すると同時に、バックアップ失敗時に残されたsnapshotの削除を忘れないこと。

利用領域制限と単位容量あたりの課金

例えば100円/GBのように、単位容量当たりのコストを定め、利用領域制限と合わせて運用する。実際にユーザーから代金を徴収するかは別として、これを定期的に評価することで、経営陣を含めたユーザーに、次のコストを具体的に意識させることができる。

  • ユーザーごとの使用量→使用料→コスト意識
  • 応分のコスト負担→ストレージ、サーバー増設、消費メディア

基本的にITインフラは社内共有が前提であるとはいえ、その管理をIT部門が100%請け負うとしても、そのコストまでも100%請け負う必要はない。組織のプール資金に加えて、ユーザーの使用量に基づいた応分負担を加味した上で、ITインフラのライフ・サイクルを決定する。そのようにすれば、空き容量がが少なくなったから増設、といった後手の対応は減少するはずだ。