管理者を悩ませるファイルストレージの増大

容量が増えると管理の手間が増えるってどういうこと？

2009年09月29日 13時00分更新

文● 大谷イビサ／TECH.ASCII.jp

昨今、企業のシステム管理者の頭を悩ませている問題の1つが、増え続けるファイルストレージの管理である。ユーザーの要求に応じてストレージを増強したあげく、多くの会社ではとんでもない管理の手間と無駄が発生している。これは悪夢だ。

エンドユーザーに合わせた
ストレージ拡張に問題あり

　ファイルストレージの容量は増大の一途をたどっており、企業のファイルデータの増大が年々50％以上に上るという調査結果もある。この結果には、紙からのオンラインへのシステム移行やアプリケーションデータの肥大化、長期保存を行なうデータの増大、あるいは災害対策のためのデータ複製などが背景にある。エンドユーザーは決して無尽蔵というわけではないファイルストレージに対して、ファイルを作成し、コピーし、残り容量をどんどん消費していく。

　しかし、このように増えたファイルやフォルダを整理するのは並大抵の作業ではない。管理者がファイルを作成したわけではないため、通常はまずエンドユーザーに容量不足に陥る前に整理するようお願いすることもあるだろう。しかし、エンドユーザーはほとんど使わないようなファイルしか削除しない。管理者が勝手にユーザーのファイルを消せないということを見越しているのだ。

　その結果、管理者はユーザーの要求に応じて、ファイルサーバやNASなどのファイルストレージを増強し続けることになる。しかもストレージがシステム単位でバラバラに構築され、地理的な場所も散在する。だが、幸か不幸か、単位容量あたりのストレージの価格は今も下がり続けているため、ファイルストレージを増やすのはそれほど面倒ではない。こうしているうちに今度は重要データを長期保存しておきたい、あるいは災害対策という観点から、別の拠点のデータも複製しておきたいといった用途が次々と出てくる。この結果、ますますファイルサーバやNASの台数は増え、容量は増大してくる。

クライアントとストレージとの
物理的なマッピングが問題を生む

　こうしたファイルストレージの増大は、非効率な投資と管理負荷の増大を生むことになる。

　たとえば、下図のように営業部門と開発部門にそれぞれファイルストレージを用意し、それぞれに共有フォルダを用意するとする。この状態で、開発部門でディスクが足りなくなってしまった場合は、どう対応するだろうか？


ファイルストレージの増大が生み出す非効率な投資と管理負荷の増大とは？

　この場合、開発部用サーバにHDDを追加したり、より大型のファイルストレージに切り替えたりするだろう。しかし、共有フォルダを増やすとクライアントでの設定変更が面倒になり、新しいファイルサーバやNASを導入したら、データの移行作業が発生する。より大きなストレージへのリプレースやディスクの増設を行なうと、面倒なデータマイグレーション（移行）が発生する。作業中はサービスを止めなければならないため、業務時間内には難しく、しかも各部署と停止時間を調整する必要もある。

　サービスが止められればよいが、ユーザーのデータを預かるサービスプロバイダなどではノンストップでのデータ移行が必要になる。この場合はストレージベンダーに無停止でのデータ移行作業を依頼しなければならない。当然、マイグレーションのたびにお金がかかることになるし、そもそも製品の選定が同一ベンダーの製品に制限される。もちろん、これが一度だけの作業であれば、管理者も仕事と割り切れるが、今後も同じことがないと言い切れるだろうか？

　一方で営業部は営業部用のサーバが割り当てられているため、いくら空き容量があっても、開発部に割り当てられることはない。仮に割り当てられても、開発部門が間借りするデータ置き場が1つ増え、管理が面倒になるだけだ。社内にあるファイルストレージ全体を俯瞰すれば空き容量があるのに、必要なところにはその容量を割り当てられないという、投資面で非効率な状況に陥ってしまう。

　しかも重要なデータも、些末なデータやキャッシュなども乱雑に各サーバに分散し、もはや収集がつかなくなる。ある調査では一般の企業では6ヶ月間アクセスのない「非アクティブ」なデータが全体の8割を占めるという。だが、管理者からはどれが重要で、どれが捨ててよいデータなのか、まったく把握できない。それにも関わらず1年～2年使わないデータも含め、週次や月次で何回もフルバックアップを行なわなければならず、時間やコスト面での無駄が生じる。もちろんバックアップ作業も業務時間内にはできないので、夜間や休日にやるか、面倒な停止調整を必要とする。