バックアップ統合（図3）
データの重要性がますます高まる中、そのバックアップは重要なオペレーションである。一方でデータのバックアップは、日常のシステム管理では負荷の高い作業でもある。ストレージネットワークの登場以前は、サーバごとにバックアップ用テープドライブを接続し、サーバ個別にバックアップ作業を行うのが一般的な形態であった。
しかし、すべてのサーバで同時にバックアップ作業を行うことはまれであり、システム全体としてみるとバックアップ装置の稼働率は低いものであった。さらに、バックアップ手法がシステム全体で一元化されていないことも、作業負荷を高める要因となっていた。
ストレージネットワークが登場してバックアップテープやディスクを共有することで、バックアップデバイスを集約することが可能となる。これは単にバックアップ“デバイス”を集約するだけでなく、バックアップ“オペレーション”を統合することも意味しており、結果としてシステム運用における負荷を大きく減らすことができる。
図3：バックアップ統合※画像をクリックすると拡大して表示されます
DRサイト構築には“棚卸し”が必要
一方で“統合”を進めるということは、“集中化”にもつながる。企業活動でITが決定的に重要となっている現在、先述のようにアプリケーションを提供するサーバやデータを格納しているストレージを統合、すなわち集中化するということは、見方を変えると大きな“リスク”を抱え込むことにもなる。
集中化されたサーバやストレージ、さらにその中に格納されるデータに障害、損失が発生すると、企業活動そのものの停止にもつながりかねないからである。したがって“統合”したサーバやストレージ、そしてデータを“分散”して保持することで、企業活動の停止を防ぐことが求められる。
一見すると“統合”と“分散”は矛盾するように思われるかもしれないが、そうではない。統合してサーバやストレージを効率よく使用することと、企業活動継続のための分散は強い関係性があり、両方を検討すべきである。
ストレージネットワークは統合だけでなく、分散のためのインフラとしても使用される。事業継続性（Business Continuity）のための災害復旧（Disaster Recovery：DR、図4）は典型例であるが、これは単に「データを分散してバックアップする」というものではない。DRサイトにサーバやストレージ、データを分散して保持するには、まず「どのシステム、アプリケーション、あるいはデータをDRの対象とするか」を定義する必要がある。
図4：災害復旧
すべてのシステム、データをDRの対象とすることは、コスト面や運用面から考えても非現実的である。実際にDR環境を構築しているユーザー企業の多くは、まずシステムやデータの“棚卸し”を行ったうえでDR対象となるデータを特定し、それを特定のバックアップデバイスに一元化して保存している。これはまさに先述の「バックアップ統合」であり、DRはバックアップ統合の延長線上で実現されるのである。
このように、サーバやストレージ、データの統合と分散の中心に位置するものとして、ストレージネットワークは存在している。
（後編は2月17日掲載予定です）
