JP2002007304A - ストレージエリアネットワークを用いた計算機システム及びそのデータ取り扱い方法 - Google Patents

Abstract

(57)【要約】 【課題】 ＳＡＮを用いたストレージシステムにおける
構成要素又は機能の連携を強化することで統合ストレー
ジシステムを構築すること。 【解決手段】 複数のクライアントコンピュータ、複数
の各種サーバ、データを保存する複数の各種ストレー
ジ、コンピュータとサーバを接続するローカルエリアネ
ットワーク（ＬＡＮ）、サーバと前記ストレージの間に
介在するストレージエリアネットワーク（ＳＡＮ）、を
備えた計算機システムであって、ＳＡＮは、ファイバチ
ャネルスイッチ（ＦＣスイッチ）によってサーバとスト
レージを任意に相互接続し得る回線網を形成し、各種ス
トレージの論理ボリューム、データ配置、障害監視を含
むストレージ管理と、前記ＦＣスイッチの設定管理と、
前記ストレージのデータのバックアップ運用と、を行う
管理運用ソフトウエアを備えた端末を有する計算機シス
テム。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データを記憶する
ストレージシステムに関し、特に、取り扱うデータのデ
ータプロテクション、データ共用、ストレージリソース
管理、並びにデータの取り扱い方法等に関する技術であ
る。

【０００２】

【従来の技術】現在、情報処理の扱う環境は、インター
ネット及びイントラネットの進展、データウェアハウ
ス、電子商取引、情報サービス等のアプリケーションの
拡大により、急激に変化してきており、それにともない
取り扱われるデータ量は急激に増大している。

【０００３】例えば、過去５年間でＣＰＵ性能が１００
倍向上しているのに対して、ディスク入出力性能の向上
は１０倍程度に留まっている。すなわち、急増するトラ
ヒックに対する入出力性能の限界が危惧されるようにな
ってきている。また、膨大なデータを処理するＥＲＰ
（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎ
ｎｉｎｇ）、データウェアハウスなどのアプリケーショ
ンの普及、扱う情報（文書、図面、ビジュアルコンテン
ツ等）の多様化・マルチメディア化に伴い、年平均２倍
の伸びで企業でのディスク容量が必要とされてきてい
る。更に、企業等で使用されるストレージ容量の増大
や、使われ方の多様化にともない、そのストレージ運用
コストも増大している。更にまた、メインフレーム基幹
データを各部署で共用し、活用されるようになってきて
いる。

【０００４】取り扱うデータ量の増大に伴う情報処理環
境の状況を図２を用いて説明すると、サーバとストレー
ジの関係は、例えば、大型コンピュータ用のサーバとし
てＭＦ（メインフレーム）、中型コンピュータ用のサー
バとしてＵＮＩＸ（登録商標）サ−バ、小型コンピュー
タ用のサーバとしてＰＣサーバ、がそれぞれに専用のス
トレージ、例えばＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒ
ｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋ
ｓ）、ＭＴ（Ｍａｇｎｅｔｉｃ Ｔａｐｅ）等と接続さ
れており、クライアントコンピュータはＬＡＮを通して
それぞれのサーバに指示を与えて、当該サーバに専用の
ストレージを用いてデータ処理を実行していた。

【０００５】最近では、上述した各種サーバとストレー
ジの間にＳＡＮ（ＳｔｏｒａｇｅＡｒｅａ Ｎｅｔｗｏ
ｒｋ）を構築して、各種サーバはいずれのストレージに
もアクセスでき得るＳＡＮ環境が提案されている。ここ
で、ＳＡＮとは複数のサーバとストレージをファイバチ
ャネルで接続したストレージ入出力専用ネットワークを
意味しており、このネットワークの採用によって、各種
ストレージを共用化でき、サーバとストレージ間を高速
でデータ処理でき、更に長距離化できるようになってい
る。

【０００６】

【発明が解決しようとする課題】上述したように、情報
処理を扱う環境では、入出力性能の向上、ディスク容
量、ストレージ運用、データ共用を進めるためにＳＡＮ
の導入が進められている。ＳＡＮとは、図２に示すよう
に、複数のサーバとストレージを高速のネットワーク
（例えばファイバチャネル）で接続した新しいネットワ
ークである。この環境においては、サーバ毎に接続され
て各サーバに従属していたストレージを独立化させ、ス
トレージ専用のＳＡＮネットワークがまず構築される。
また、ＳＡＮネットワーク上のストレージ情報をアクセ
ス権のあるすべてのユーザから共有させることができ
る。

【０００７】また、複数のストレージを接続するためス
トレージ入出力性能を大幅に向上することができる。即
ち、メリットとして、ストレージ入出力性能の大幅向上
（パフォーマンス向上）、サーバ環境とは独立した柔軟
なストレージ環境の設定・拡張（スケーラビリティの向
上）、ストレージの一元運用（ストレージ管理機能の向
上）、接続距離を飛躍的に延ばす事による災害対策（デ
ータ保護機能の向上）等を図ることができるようになっ
た。

【０００８】しかしながら、提案されているＳＡＮネッ
トワークでは、これらを実現するための具体的な構成、
又は実施方法等は必ずしも明確に開示されていなかっ
た。

【０００９】本発明の目的は、ＳＡＮの採用による種々
の利点並びに有用性を確保できるように、ストレージシ
ステムの具体的機能並びにこれらの機能に対応する具体
的構成を工夫してストレージシステム全体の連携を強化
した統合ストレージシステムを提供するとともに、イン
ターネットに接続して大容量のデータ保存とその利用を
図るインターネットデータセンタ（「ｉＤＣ」と以下称
する）へ統合ストレージシステムを適用し、ｉＤＣでの
より有用なデータ取り扱い方法を提供することにある。

【００１０】

【課題を解決するための手段】前記課題を解決するため
に、本発明は主として次のような構成を採用する。

【００１１】複数のクライアントコンピュータ、複数の
各種サーバ、データを保存する複数の各種ストレージ、
前記コンピュータと前記サーバを接続するローカルエリ
アネットワーク（ＬＡＮ）、前記サーバと前記ストレー
ジの間に介在するストレージエリアネットワーク（ＳＡ
Ｎ）、を備えた計算機システムであって、前記ＳＡＮ
は、ファイバチャネルスイッチ（ＦＣスイッチ）によっ
て前記サーバと前記ストレージを任意に相互接続し得る
回線網を形成し、前記各種ストレージの論理ボリュー
ム、データ配置、障害監視を含むストレージ管理と、前
記ＦＣスイッチの設定管理と、前記ストレージのデータ
のバックアップ運用と、を行う管理運用ソフトウエアを
備えた端末を有する計算機システム。

【００１２】また、サーバ、前記サーバのデータを記録
するストレージ、前記サーバと前記ストレージを接続す
るネットワーク、前記ネットワークに接続されて前記デ
ータのバックアップを取るバックアップ装置、から構成
されるシステムの管理方法であって、処理対象であるデ
ータを識別する情報を入手する第１ステップ、前記情報
が示すデータの処理内容を入手する第２ステップ、前記
情報が示すデータを保持する前記ストレージに対して、
前記処理内容を指示する第３ステップ、および前記情報
が示すデータが処理された結果を前記ストレージから受
ける第４ステップを有するシステムの管理方法。

【００１３】

【発明の実施の形態】本発明の実施形態に係る、ストレ
ージエリアネットワーク（ＳＡＮ）を用いた計算機シス
テム及びそのデータ取り扱い方法について、図面を用い
て以下説明する。図１は、本発明の実施形態に係る前記
計算機システムの基本的な全体構成を示した概略図であ
る。

【００１４】図１において、ＳＡＮを用いた計算機シス
テムは、メインサイトとリモートサイトとから成り立っ
ていてこれらのサイトはＷＡＮ（Ｗｉｄｅ Ａｒｅａ
Ｎｅｔｗｏｒｋ）で接続されている。メインサイトにお
いては、複数のクライアントコンピュータと各種サー
バ、例えば、大型コンピュータ用サーバのＭＦ（メイン
フレーム）、中型コンピュータ用サーバのＵＮＩＸサー
バ、小型用コンピュータ用サーバのＰＣサーバ（パソコ
ン用サーバ）がＬＡＮで接続されている。また、ＬＡＮ
には統合ストレージシステムの運用管理ソフトを搭載し
た専用端末が接続されていてこの総合ストレージシステ
ム全体が運用・管理・監視されるようになっていいる。
なお、この運用管理ソフトは専用端末ではなくてどれか
１つのクライアント端末に搭載されていて、当該クライ
アント端末が統合ストレージシステムの運用管理を行っ
ても良い。

【００１５】更に、ＲＡＩＤ、テープライブラリ、ＤＶ
Ｄ−ＲＡＭライブラリ／ライブラリアレイ等のストレー
ジは、メインフレーム（ＭＦ）サーバ、ＵＮＩＸサー
バ、ＰＣサーバ等のサーバと、ファイバーチャネルスイ
ッチ（ＦＣ−Ｓｗｉｔｃｈ）、不図示のファイバチャネ
ルハブ（ＦＣ−Ｈｕｂ）等のネットワークスイッチで構
成されるＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗ
ｏｒｋ）で接続される。また、メインサイトはＷＡＮ等
の広域通信網により、メインサイトと同様な構成を持つ
リモートサイトに接続される。

【００１６】ここで、サーバとストレージはＳＡＮにお
けるチャネルスイッチにより接続されるので、チャネル
スイッチに接続されるサーバやストレージを自由に追
加、削除、変更することが可能となる。このため、ま
ず、ストレージ容量や、記憶するデータの種類や目的
（アクセススピード、コスト等）に合致したストレージ
を自由に追加、削除等が可能となる。また、サーバ側で
も、チャネルスイッチを介して自由にこれらのストレー
ジにアクセス可能となる。

【００１７】また、ＷＡＮを介して、リモートサイトと
接続されているので、サイト間でデータの共用が可能と
なり、世界的規模で大量データの共用が可能となる。ま
た、メインサイト及びリモートサイト間でデータのコピ
ーを保持すれば、災害等で片方のサイトが障害になった
場合でも他方のサイトのデータを用いて、業務を継続で
きることが可能となる。この場合、リモート側のサイト
でのバックアップは必ずしも同一形態の記憶装置、例え
ば メイン側のＲＡＩＤからリモート側のＲＡＩＤへの
コピーに限定されず、メイン側のＲＡＩＤからリモート
側のＤＶＤ−ＲＡＭやテープライブラリ等へコピーする
ことで、コストや管理を簡単にすることも考えられる。
この場合、ＳＡＮの管理用端末の運用管理ソフトがこれ
らデータのコピー元、コピー先等を管理する。

【００１８】また、図２に示す従来技術では、クライア
ントは、その用途別に例えばメインフレーム、ＵＮＩＸ
サーバ、ＰＣサーバとＬＡＮ等の通信回線を介して、ま
た、各サーバ間もＬＡＮを介して接続されていた。そし
て、それぞれのストレージは各々のサーバに接続されて
いた。このため、ストレージに格納されているデータは
各サーバ経由でしかアクセスできなかった。

【００１９】一方、本発明の実施形態では、各サーバに
接続されるストレージに格納されるデータをＳＡＮによ
り統合的に管理する。まず、複数の各サーバからＳＡＮ
を構成するファイバチャネルスイッチ（ＦＣ−Ｓｗｉｔ
ｃｈ）を介して、各種ストレージ（ＲＡＩＤディスク、
テープライブラリ、ＤＶＤ−ＲＡＭライブラリ／ライブ
ラリアレイ等）と接続する。これにより、各ストレージ
が有するデータはＬＡＮを経由せずに、各サーバから直
接アクセス可能となり、例えば、大量データ等のアクセ
スが容易となる。また、データ用のストレージが統合ス
トレージシステムに整理統合されるので、データや機器
の管理が容易となる。

【００２０】また、従来技術では、災害に対するデータ
のバックアップやリモートコピー等は各サーバ毎に対応
するストレージを設置しＬＡＮ経由で実行することが必
要であったが、本発明の実施形態ではＳＡＮ並びに各種
ストレージからなる統合ストレージシステムを設けるの
で、この統合ストレージシステムでデータのバックアッ
プが可能となり、より効率的なデータのリモートバック
アップが可能となる。

【００２１】以上、概略的に説明したＳＡＮ適用による
計算機システムは、取り扱うデータについて、いつで
も、誰でも、どこからでも、どんな情報でも安全に利用
できることを主眼とした情報システムであることが求め
られるのである。

【００２２】そして、本発明の実施形態に係る統合スト
レージシステムは、図３に開示するように、ディスクの
障害に対する対策としてのバックアップや地震・火災等
の災害に対する対策としてのディザスタリカバリを内容
とするデータプロテクションを基本的機能の一つとして
持ち、また、メインフレーム、ＵＮＩＸサーバ、ＰＣサ
−バからのデータ交換・共用やＤＢ（データベース）、
文書、図面、マルチメディアコンテンツ等の多種情報の
扱うデータシェアリング（Ｄａｔａ Ｓｈａｒｉｇ：デ
ータ共用）を基本的機能の一つとして持ち、更に、サー
バ毎に管理運用していたストレージの一元管理や統一的
操作による環境設定並びにストレージ運用管理を内容と
するストレージマネージメント（ストレージリソース管
理）を基本的機能の一つとして持つ。

【００２３】以下、順に本発明であるそれぞれの基本的
機能の詳細な具体的内容について説明する。これら機能
は、これら機能を記述したプログラム（ソフトウエア）
や必要なデータを、ストレージ、スイッチ、サーバ（コ
ンピュータ）、及び管理装置（コンピュータ等で実現さ
れる）等のハード装置が有するメモリにインストール
し、各ハード装置が有するＣＰＵ（中央演算装置）で実
行することによって実現される。なお、ＳＡＮを適用し
た大容量のストレージシステム群と各種サーバとからな
る計算機システムをインターネットに接続してデータ保
存サービス機能を具備させたデータセンタ、即ちインタ
ーネットデータセンタ（以下、「ｉＤＣ」と略称する）
を構築し、ｉＤＣにおける膨大なデータの取り扱い方法
に関する工夫も本発明の特徴の一つである。

【００２４】まず、データプロテクションについてであ
るが、その機能は、オンライン稼働中のＤＢバックアッ
プ、ストレージ資源共用による管理費節減、ディザスタ
リカバリ等によるシステム可用性の向上、及びデータの
安全性確保を狙ったものであり、今後増加が予想される
２４時間３６５日の営業に対してでも、業務を停止する
こと無くデータのバックアップ（無停止バックアップ）
が可能となると共に、バックアップに際してテープライ
ブラリを共用可能とすること（テープ共用バックアッ
プ）でコスト削減が可能となり、更に、遠距離リモート
コピーにおけるデータ安全性を確保して災害時にシステ
ムを迅速に復旧すること（リモートコピー）が可能とな
る。具体的には、データプロテクションの内容は、前述
したように、無停止バックアップとテープ共用バックア
ップと非同期リモートコピーの３つの技術である。

【００２５】まず、無停止バックアップの機能乃至作用
は、データのレプリカからのバックアップによりバック
アップ中のアプリケーションの動作を可能とするととも
に、バックアップ専用サーバにより業務用サーバに影響
を与えないようにすることである。

【００２６】無停止バックアップの構成と機能につい
て、図４と図５にその詳細を示す。この機能の概要は、
ストレージ内に存する内部機能とアプリケーションサー
バ内のＤＢＭＳ（データベースマネージメントシステ
ム）との連携により、オンライン業務に影響を与えず
に、ＬＡＮ非経由且つＳＡＮ経由でＤＢをバックアップ
することである。

【００２７】図４では無停止バックアップの一連の流れ
を示している。まず、前記ストレージ内の内部機能によ
って、ストレージ装置内でバックアップ対象ボリューム
（正ボリューム）と同一あるいはそれよりも大きい容量
を持つ副ボリュームに対してコピーを実行して正ボリュ
ームのコピーを作成する。続いてアプリケーション実行
中に、アプリケーションサーバ内のＤＢＭＳ（データベ
ースマネジメントシステム）をバックアップ可能な状態
に変更してオンライン業務に影響を与えないようにして
おき、副ボリュームの内容をバックアップサーバにより
テープにバックアップする。

【００２８】図５には図４の無停止バックアップにおけ
る、ストレージ装置の内部機能であるボリュームコピー
機能の処理槻要を示している。もともと、不図示の従来
のバックアップ技術ではＤＢ（データベース）へのサー
バからの業務を停止したあとに、ＤＢを他のストレージ
にバックアップして、当該バックアップ完了後に前記Ｄ
Ｂへのオンライン業務を再開するというものであった。
この従来技術によると、バックアップ中はＤＢへのオン
ライン業務は停止せざるを得なかった。

【００２９】これに対して、図５の左側に図示した本実
施形態の一構成例では、ストレージ内にバックアップ用
のレブリカ、すなわち論理ボリュームＢ（論理ＶＯＬ
Ｂ）を確保して事前にコピーを作成しておくものであ
る。論理ボリュームＡ（論理ＶＯＬＡ）のデータバック
アップの場合、事前に論理ＶＯＬＡの内容を論理ＶＯＬ
Ｂの方にもコピーしておく。具体的には、論理ＶＯＬＡ
がバックアップ対象である場合には、あらかじめ論理Ｖ
ＯＬＡと論理ＶＯＬＢの２つのボリュームを用意し、二
重化を指示する。

【００３０】ストレージ装置では、論理ＶＯＬＡの内容
を論理ＶＯＬＢに順次コピーしていき、それと並行して
オンライン業務（図中ＪＯＢＡ）からの書き込みがある
と、ストレージ装置内で自動的に論理ＶＯＬＡ、論理Ｖ
ＯＬＢの双方に二重書きする。論理ＶＯＬＡから論理Ｖ
ＯＬＢへの順次コピーが完了した後も、ＪＯＢＡからの
書き込みがあれば二重書き込みは実施し、論理ＶＯＬＡ
と論理ＶＯＬＢの内容を常に同一に保つ。

【００３１】バックアップを実施する際には、バックア
ップサーバはディスク制御手段を用いてストレージ装置
にペア分割（スブリツト）を指示する。ストレージ装置
ではスブリット指示のあとは、ＪＯＢＡからの書き込み
があっても論理ＶＯＬＡのみに書き込みし、論理ＶＯＬ
Ｂには書き込みを実施しない。これにより論理ＶＯＬＢ
にはスブリット指示のあった時点の論理ＶＯＬＡの内容
がそのまま残される。スブリツト指示の後、バックアッ
プサーバのバックアップソフトウェアは副ボリュームで
ある論理ＶＯＬＢからデータを読み出し、テープ装置な
どのバックアップデバイスにデータのバックアップを行
う。

【００３２】ただし、図５の左側の図によるボリューム
二重化の方式では、バックアップを実施するよりも前の
時点で二重化ボリュームを用意しておく必要がある。そ
のため、バックアップを実施するには、事前にボリュー
ム二重化にかかる時間を見越して、それより前に二重化
を行う必要がある。図５の右側に図示されたストレージ
装置の機能では、この問題を解決する。

【００３３】図５の右側の事例でも論理ＶＯＬＡのコピ
ーを置くための論理ＶＯＬＢを用意する点は図５左側の
図と同様である。バックアップサーバは、図５左側の例
と同様、バックアップを開始する前にディスク制御手段
を用いてストレージ装置にペア分割（スブリツト）を指
示する。ただし、この時点で論理ＶＯＬＢには論理ＶＯ
ＬＡのデータがコピーされている必要はない。スブリツ
ト指示の後、バックアップサーバのバックアップソフト
ウェアは、副ボリュームである論理ＶＯＬＢからデータ
の読み出しを開始する。ストレージ装置では論理ＶＯＬ
Ａから論理ＶＯＬＢに対して、順次データのコピーが行
われるが、バックアップサーバが論理ＶＯＬＢからデー
タを読み出そうとしたときにボリュームＢにデータが存
在しない場合には、ディスク装置は論理ＶＯＬＡからデ
ータを読み出してバックアップサーバに渡す、あるいは
論理ＶＯＬＡから一旦データを論理ＶＯＬＢにコピー
し、それをバックアップサーバに渡す。この処理によ
り、スブリツト時点で論理ＶＯＬＢにデータが存在して
いなくとも、バックアップサーバからはあたかも論理Ｖ
ＯＬＢに論理ＶＯＬＡのコピーが存在するように見え
る。

【００３４】ただし、バックアップ処理の間、アプリケ
ーションサーバから論理ＶＯＬＡのある領域にデータが
書き込まれることもあり得る。ストレージ装置では論理
ＶＯＬＡから論理ＶＯＬＢに対して、データを順次コピ
ーしているので、もしもこのデータがこのコピー処理に
よって論理ＶＯＬＢに書き込まれてしまうと、論理ＶＯ
ＬＢにはスブリツト以降のデータが書き込まれてしまう
ことになる。これを防ぐため、ストレージ装置は論理Ｖ
ＯＬＡの書き込み要求のあった領域に現在書かれている
データを読み出し、論理ＶＯＬＢへと書き出す。しかる
後に、アプリケーションサーバから書き込み要求のあっ
たデータを論理ＶＯＬＡに書き込む。この処理により、
論理ＶＯＬＢにはスブリツト指示のあった時点の論理Ｖ
ＯＬＡのデータ内容だけがコピーされることになる。こ
の方法では、バックアップ開始時点で副ボリューム（論
理ＶＯＬＢ）に正ボリューム（論理ＶＯＬＡ）の内容が
コピーされている必要がない、すなわち事前にコピーボ
リュームを用意するという運用が不要になるので、運用
性が向上する。

【００３５】図７は、図４と図５に示す無停止バックア
ップの際のシステム構築のインストール事例を示す。ア
プリケーションサーバにはＤＢＭＳとディスク制御手段
が備えられ、バックアップサーバにはバックアップソフ
トとディスク制御手段が備えられている。事前準備とし
て、ディスク制御手段をインストールしてその構成を設
定し動作確認を行う。その後、無停止バックアップシス
テムの構築に際しては、まず、ＤＢＭＳのスクリプトを
作成し（ログイン、バックアップモード設定、バックア
ップモード解除、ログアウト）、アプリケーションサー
バにおけるディスク制御手段のスクリプトを作成し（ペ
アスプリット、ペアイベント待機、再同期）、バックア
ップソフトとの連携動作を確認し、Ｌｏｇｉｃａｌ Ｕ
ｎｉｔの配置とディスク制御手段のパラメータ設定をす
る。

【００３６】また、図６に示す無停止バックアップの他
の構成例によると、ミラーリングソフトウエアにより形
成されたプライマリ（正）とセカンダリ（副）のボリュ
ームを、アプリケーションサーバの連携ツールの指示に
よりミラースプリットし、一方（副ボリューム）でバッ
クアップを行うとともに、他方（正ボリューム）で業務
を継続可能とするものである。そして、バックアップ終
了後には再同期を行う。具体的には、アプリケーション
サーバ内のミラーリングソフトにより正と副のボリュー
ムに二重書きを行い、サーバ内の連携ツール（ソフトウ
エア）でＤＢアクセスを停止し、ミラースプリットを指
示した後にＤＢアクセスを再開する。次いで、バックア
ップサーバ内の連携ツール（ソフトウエア）で副ボリュ
ームのデータをバックアップサーバに接続されたテープ
等のバックアップ装置にバックアップを開始する。その
後、バックアップサーバ内の連携ツール（ソフトウエ
ア）からのバックアップ完了を受けたアプリケーション
サーバ内の連携ツールは、ミラーの再同期を指示して再
び二重書きする。

【００３７】次に、テープ共用バックアップの構成と機
能について、図８と図９にその詳細を示す。この機能の
概要は、多数のサーバに点在するデータの管理にかかる
管理コストを低減するとともに、ＬＡＮへの負荷を低減
した高速のバックアップを図るものである。そして、テ
ープライブラリを複数サーバ側から共用可能とすること
で高価なライブブラリを有効に使用可能とし（個々のデ
ィスク毎にバックアップテープを設けるものに比べ
て）、単一のテープライブラリを複数のサーバで共同、
共有することでＬＡＮ経由ではなくてＳＡＮ経由で直接
にテープ装置に出力できてバックアップを高速化でき
る。

【００３８】図８の左図は従来のテープバックアップを
示したものであり、サーバ毎のディスクからＬＡＮを経
由してバックアップサーバを通ってテープにデータをバ
ックアップしていて、バックアップ毎にＬＡＮを経由す
るためＬＡＮへの負荷が掛かるものであり、更に、バッ
クアップサーバにもバックアップ毎に負荷がかかるもの
であった。

【００３９】本発明の実施形態は、図８の中央図のＬＡ
Ｎフリーバックアップによると、ＳＡＮ経由でディスク
からテープへコピーし高速化することができ、ＬＡＮを
経由することなくサーバを用いてバックアップするもの
である。バックアップに際してサーバは単一のものを使
用することもできるので、サーバへの負荷も低減する。
本発明の他の実施形態は、図８の右図のサーバレスバッ
クアップによると、ディスクから直接にテープにコピー
することができるのでバックアップの高速化とサーバの
負荷低減ができる。図８の右図の実施形態では、ディス
クにテープへの書き込み機能を具備させる必要があり、
又はテープにディスク内のデータ読み出し機能を具備さ
せる必要があり、又はＦＣスイッチにディスクからテー
プへの書き込み機能を具備させる必要があり、又はテー
プがＦＣ−ＳＣＳＩマルチプレクサ（図９の説明で後述
する）に接続される場合にＦＣ−ＳＣＳＩマルチプレク
サがディスクからテープへの書き込み機能を具備させる
必要がある。

【００４０】テープ共用バックアップの他の構成例を図
９に示す。図９の構成は図８の中央図に示すＬＡＮフリ
ーバックアップに対応するものである。この構成例では
２ノード以上で同時にテープライブラリを共有して各々
のサーバがバックアップするものである。図９による
と、サーバＣはサーバＡ及びＢとその機能を異にしてお
り、バックアップを実際に執行するに必要なバックアッ
プエージェントの外に、バックアップを統合管理するバ
ックアップマネージャを保持していて、バックアップド
ライブを割り当てる機能等を備えている。ここで、バッ
クアップドライブは、例えば、ドライブを３個有してい
てサーバＡにはドライブ１を割り当て、サーバＡからバ
ックアップしたいという要求がくれば保存用テープをド
ライブＡにローディングするように制御される。また、
サーバに対するドライブの割り当ては、バックアップマ
ネージャがドライブの使用状況を管理し、未使用のドラ
イブを選定してその内の適宜のドライブを割り当てても
良い。図９に示す構造において、ＦＣ−ＳＣＳＩマルチ
プレクサとバックアップドライブとが図８に示すテープ
ライブラリに相当する。

【００４１】図９に示すテープ共用バックアップの具体
的動作を説明する。まず、サーバＡのエージェントがバ
ックアップマネージャに対してテープマウントの要求を
行う。次に、マネージャが当該要求を受けてテープライ
ブラリのドライブのどれか１つにテープをマウントす
る。続いて、マネージャがサーボＡのエージェントに対
してマウント完了とマウントしたドライブ名を教える。
次に、サーバＡのエージェントが実際にバックアップを
実行する。具体的には、サーバＡがストレージからデー
タを読み出して、ＦＣスイッチ、ＦＣ−ＳＣＳＩマルチ
プレクサを介してマウントしたテープに書き込む。続い
て、バックアップ完了後にサーバＡのエージェントはマ
ネージャに対してテープのアンマウント要求を行い、マ
ネージャはテープアンマウントを指示して、全てを終了
する。

【００４２】次に、データプロテクションの１つとして
のディザスタリカバリにおける非同期リモートコピーに
ついてその構成と機能について説明する。これは、遠距
離リモートコピーによってデータ保全性を確保して地震
などの災害時にシステムを迅速に復旧させるものであ
り、メインサイトの性能への影響を無くしてリモートサ
イトへデータベースを複製し、災害時にリモートサイト
で業務を続行しようとするものである。

【００４３】図１０は非同期リモートコピーのシステム
構成を示しており、メインサイトとリモートサイトとは
災害時に同時に被災しないだけの遠距離を通信回線を介
して接続され、メインサイトで情報が更新されそれが完
了すると（リモートサイトへの情報の反映するのを待た
ずに、即ち非同期で）、更新完了をサーバに報告する。
次に、適宜のタイミングで更新データをメインサイトか
らリモートサイトへコピーするのであるが、メインサイ
トへの更新データの順序通りにデータ転送されない場合
には、リモートサイトのシステムで更新データを時系列
にソートして更新の順序性を保証してコピーしている
（例えば、入金と出金の更新データが順序を逆にしてデ
ータ保存されると残高処理で不都合な取り扱いをせざる
を得ないという事態が発生し得る）。

【００４４】次に、データシェアリングにおけるサーバ
間高速レプリケーションの構成と機能について説明す
る。図１１に示すように、メインフレームのＤＢ（基幹
データベースで高信頼性を確保できるもの）とＵＮＩＸ
／ＮＴサーバのＤＢ（例えば、データの信頼性よりもデ
ータの統計処理を実行する上でデータの取り扱い易さを
重視してメインフレームＤＢから統計処理の必要原デー
タをロードするためのもの）間でデータをロードする際
に、メインフレームベースのファイルである中間ファイ
ルを設けて、一旦この中間ファイルに基幹ＤＢからデー
タを落とし込む（ＵＮＩＸサーバのデータローダーが基
幹ＤＢから直接にデータを読み込むような仕様とはなっ
ていないので）。中間ファイルのデータはＵＮＩＸサー
バのデータローダーで読み込みが可能なようなレベルに
変換されているのでパイプを通してＵＮＩＸサーバのＤ
Ｂにレプリケーションを作成して所要の処理のためのＤ
Ｂとする。この際に、基幹ＤＢからＵＮＩＸサーバのＤ
ＢへのデータレプリケーションにおいてＬＡＮを経由し
ていないためにサーバ間ＤＢの高速レプリケーションが
可能となる。ここで、中間ファイルは、磁気ディスクの
外に半導体メモリ、即ちキャッシュメモリ上に一時的に
形成された仮想ボリュームであっても良い。キャッシュ
メモリを用いる方が高速にデータを転送できる。

【００４５】更に、ＵＮＩＸサーバ又はＰＣサーバのデ
ータウエアハウス構築のし易さのために、基幹ＤＢ等の
各種ソースＤＢからのデータ抽出、データの変換・集
約、ロードの一連の処理をＧＵＩベースに簡単・迅速に
実行するソフトウエアをＵＮＩＸサーバ内に又はそれに
付属させて設けることで、データウエアハウス構築時の
データ転送処理時間を短縮する事が可能となる。

【００４６】次に、ストレージを含むシステム統合運用
管理の構成と機能について以下説明する。大規模でかつ
２４時間連続運用を要求される計算機システムになる
と、システムの管理、とくにストレージの管理が重要に
なる。

【００４７】ストレージの管理としては、装置障害、と
くに装置内のどの部品が壊れたかを障害監視する機能が
代表として挙げられる。また、システムクラッシュに備
えて各サイトのデータを定期的にバックアップするなど
の保守作業、ボリュームの追加を行った場合にシステム
設定の変更作業、さらに、特定のボリュームに負荷が集
中して性能が低下した場合にはあるボリュームのデータ
を別ボリュームに移動させるなどの措置が必要になり、
その際の負荷状況の監視も重要な管理作業である。従来
のシステムでは、各ストレージ装置ごとに１つの保守端
末が存在し、各ストレージの管理をそれぞれ別の端末か
ら行う必要があった。

【００４８】本発明の実施形態に係るストレージ統合運
用管理手段では、すべての装置を１箇所の端末から管理
することができる。

【００４９】図１２は、大規模なオフィスシステムにお
ける、バックアップ運用・障害監視の事例を示してい
る。一般のオフィス環境では各部門で共通に使用するデ
ータ、全部門で共通に使用するデータとが存在する。本
事例では各フロアＡ，Ｂ，Ｃごとに複数のクライアント
計算機、複数のサーバ計算機が存在し、全社システムと
して全部門で共通に使用されるメールサーバ、ＷＷＷ
（Ｗｏｒｌｄ ＷｉｄｅＷｅｂ）サーバを用意し、各部
門に提供する。

【００５０】部門ごとで使われるような小規模なデータ
の場合には、各部門内でバックアップを取れば済むケー
スも多いため、テープなどのバックアップデバイスは各
部門に存在する。また、大規模なデータを格納するため
に複数の大規模ストレージとテープライブラリ等のバッ
クアップ装置を計算機センタなどに用意し、センタの各
デバイスと各フロア、全社システムとをストレージエリ
アネットワークにより相互結合する。

【００５１】集中監視コンソールでは、各フロア、全社
システム、計算機センタのすべての装置を監視し、装置
障害の報告はすべて集中監視コンソールに集められる。
保守員がコンソールを見てどの装置に障害が発生した
か、容易に知ることができ、障害によりデータが壊れた
場合には、バックアップ装置からデータを回復（リスト
ア）することができる。このリストア処理も集中監視コ
ンソールから可能である。また、保守員が端末から離れ
ている場合もあるため、そういった場合には集中監視コ
ンソールから保守員の持つ携帯電話などにメールを送信
して保守員に知らせるなどの機能も存在する。

【００５２】集中監視コンソールはバックアップの運用
方法の指示・管理も行う。バックアップの頻度、バック
アップ先の要求はそれぞれのデータの種類によって異な
る。たとえば、ほとんどバックアップする必要のないデ
ータ（例えばほとんど更新されないようなデータ）や特
定の部門・個人しかアクセスしないようなデータを頻繁
にバックアップする必要はない。あるいはすべてのデー
タを同じ時間帯にバックアップを取ろうとしても、バッ
クアップデバイスの数には限りがある。集中監視コンソ
ールでは、ユーザの必要に応じてそれぞれのデータある
いはボリュームによって、バックアップの頻度、時間
帯、バックアップ先などを変え、それぞれのバックアッ
プ処理を自動的に実施する。

【００５３】図１４は、ボリュームの設定を行う処理を
模式的に示している。大規模なストレージ装置の場合、
複数のディスクをまとめて１つないし複数の論理デバイ
ス（ＬＤＥＶ）に見せかける。また、ホストまたはファ
イバチャネルスイッチに接続するための複数のポートを
持ち、各ＬＤＥＶがどのポートからアクセスされるよう
になるか設定変更が可能である。ホストからＬＤＥＶを
参照する場合、ストレージ装置のポート識別子とＬＵＮ
（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）により一
意に認識できる。以下、これをホストアドレスと呼ぶ。
ストレージ装置では、各ＬＤＥＶにこのホストアドレス
を割り付けてホストに見せる。

【００５４】集中監視コンソールからは、ＬＤＥＶのホ
ストアドレス割付、そして、各ＬＤＥＶにアクセスでき
るホストの種類を設定する。ストレージエリアネットワ
ークではすべてのホストがすべてのストレージに接続さ
れるため、本来アクセスしてはいけないホストが不当に
ストレージにアクセスする危険性があり、それを防ぐた
めにストレージ装置には、アクセス可能なホストの種類
を登録することができる。

【００５５】図１３はストレージの性能監視の事例を示
す。集中監視コンソールからは、各ボリュームの負荷状
況を観測することができる。具体的には１秒間に何回の
Ｉ／Ｏ処理を受け付けたか、リード・ライトの比率、キ
ャッシュヒット率などである。一般にすべてのボリュー
ムに均等に負荷がかかることは少なく、極端に負荷が高
いボリュームやほとんど負荷がかからないボリュームと
が存在することがある。集中監視コンソールでは複数の
ボリュームの負荷の偏りを一度にモニタできるので、こ
れをみて、負荷の高い論理ボリュームのデータを一部低
負荷のボリュームに再配置させるなど、システム全体の
性能が落ちないように計画を立てることが容易になる。

【００５６】また、図１５は、ボリュームの再配置の機
能をストレージ装置が持っている場合の事例を示したも
のである。ストレージ装置によっては、容量は少ないが
比較的高速なボリューム、そして容量は大きいものの性
能があまり高くないボリュームとが存在する。この場
合、アクセス頻度の低いデータは容量の大きいボリュー
ムに移動し、アクセス頻度の高いデータは高速なボリュ
ームに移動することが望ましい。本事例のディスク装置
では論理デバイス（ＬＤＥＶ）ごとに別の領域に移動す
ることができる。

【００５７】また、論理デバイスの移動中、移動後も、
ホストからはボリューム配置が変わったことは見えず、
移動前とまったく同じように扱うことができる。ディス
ク装置は論理デバイスの利用率などを統計情報として取
得し、その情報を統合監視コンソールに送る。統合監視
コンソールではその情報を元に、ある論理デバイスを移
動したときの、各論理デバイスの利用率がどう変化する
かを予測し、保守員に提示する。保守員はその情報を元
に、前図の例よりもより容易にボリューム再配置の計画
を立てることができる。また、統合監視コンソールから
は、実際に移動を実施するか否かを指示、あるいは、各
ボリュームがある状態になったら自動的にボリュームを
移動する、など細かい設定を事前に行うことなどが可能
である。

【００５８】また、システム統合運用管理の１つとして
ＦＣスイッチの管理があり、ＦＣスイッチの各種設定や
ゾーニング等の状態管理が可能となる。具体的には、ｆ
ａｂｒｉｃトポロジの表示、スイッチのソーニングの設
定、スイッチ内の各種パラメータの設定／表示等の管理
があり、これらは総合監視コンソールで監視できるよう
になっている。サーバとストレージに介在するｆａｂｒ
ｉｃ ｓｗｉｔｃｈ（ＦＣ）を３つのゾーニングに分割
した構成例を図１６に示す。

【００５９】次に、以上説明した本発明の実施形態に係
る計算機システムの全体構成の上で、図１に示した運用
管理ソフトを搭載した端末である管理装置が計算機シス
テム全体構成を管理制御する場合の具体的な例を示す。

【００６０】バックアップ（図４）を行うには、ストレ
ージ内のどのボリュームのデータをバックアップするか
を決定する必要がある。通常、サーバはアプリケーショ
ンがストレージ内に記録したデータをファイル単位で管
理しており、一方、ストレージはボリューム単位でデー
タを管理している。

【００６１】従って、バックアップを開始するにあた
り、ＳＡＮ管理装置（図１に示す運用管理ソフト搭載の
端末）は、サーバからあるファイルに関するバックアッ
プを依頼されると、サーバからファイルを識別する情報
や、バックアップ装置に関する情報（ＳＡＮ上のアドレ
ス、等）や、バックアップ時刻、等を入手する。ＳＡＮ
管理装置は、更に、当該ファイルを格納したボリューム
を識別する情報をストレージから入手する。次に、ＳＡ
Ｎ管理装置は、入手したこれら２つの情報を用いて、該
ファイルを格納しているストレージに、バックアップの
対象となるボリュームに関して、レプリカ（副ボリュー
ム）を作成するよう指示する。

【００６２】具体的には、該ファイルを格納しているボ
リュームを有するストレージに、当該ボリューム（正ボ
リューム）のレプリカを作成するための別ボリューム
（副ボリューム）の割り当てとレプリカの作成を指示す
る。副ボリュームの割り当ては、少なくとも正ボリュー
ムと同容量のボリュームを割り当てる等の配慮が必要で
あり、ＳＡＮ管理装置は各ストレージがどういった容
量、構成のボリュームを有しているかなどを把握してい
る必要がある。副ボリュームの作成が終了すると、この
報告を受けたＳＡＮ管理装置は、ストレージに対してボ
リュームペア分離を指示し、正ボリュームに関してはサ
ーバからの通常の処理を続けさせたまま、副ボリューム
からバックアップ装置へのデータのバックアップをバッ
クアップサーバへ指示する。

【００６３】バックアップサーバは、副ボリュームのデ
ータをＳＡＮ経由で読み出し、読み出したデータをバッ
クアップ装置へ転送する。バックアップが終了すると、
これがＳＡＮ管理装置へバックアップサーバから報告さ
れ、更に、ＳＡＮ管理装置は、バックアップを依頼した
アプリケーションへバックアップ終了を報告する。な
お、ボリュームペアを分離する時間は、先のバックアッ
プ時刻となる。また、バックアップデータのＳＡＮ上で
の転送先は、先のバックアップ装置のＳＡＮ上でのアド
レスとなる。ここで、ＳＡＮ管理装置とストレージとの
間の制御情報の通信は、図１に示すＳＡＮ管理装置か
ら、ＬＡＮ、サーバ、ＳＡＮを経由してストレージに通
信することも可能であるが、図示しないＳＡＮ管理装置
とストレージをＬＡＮ経由で直接接続して、この接続に
より先の制御情報を通信するようにしても良い。

【００６４】上記説明では、ＳＡＮ管理装置が中心とな
りバックアップの受付け、レプリカ作成・分離、バック
アップ処理、バックアップの終了報告を制御したが、ア
プリケーションサーバ内のソフトとバックアップサーバ
のソフトが直接ＬＡＮを経由して制御情報を交換するこ
とにより、ＳＡＮ管理装置を利用せずに実現することも
可能である（図６）。この場合、ＳＡＮ管理装置を使用
する場合と比較して、２つのサーバ内のソフトが相手の
ソフトとの連携が必要となるが、ここで説明したような
ＳＡＮ管理装置を必要としなくて良く、比較的小規模な
システム向けと言える。

【００６５】前述のバックアップでは、バックアップサ
ーバを介してバックアップ装置へデータをバックアップ
したが、バックアップサーバを経由せずに、ストレージ
内の副ボリュームからＳＡＮ経由で直接バックアップ装
置へデータを転送することでバックアップするように制
御することも可能である（ダイレクトバックアップ）。
これは、ＳＡＮ管理装置を用いる場合は、ＳＡＮ管理装
置がレプリカ作成・分離を認識した後、ストレージに対
して、副ボリュームのデータをバックアップ装置へ転送
することを指示することで実現できる。この指示にはバ
ックアップ装置のＳＡＮ上でのアドレス等が含まれるこ
とになる。

【００６６】なお、上記バックアップでは、アプリケー
ションが主体となってバックアップファイル、ボリュー
ムを指定する形にしているが、更新が頻繁に行われ、毎
日や数時間毎のバックアップが必要なファイルやボリュ
ームに対しては、管理装置やバックアップソフトウェア
に定期的にバックアップすることを予め指定しておくこ
とによって、アプリケーションへの負荷を減らすことが
可能である。

【００６７】次に、テープ共用バックアップ（図８）に
おけるＳＡＮ管理装置の働きの例を示す。ＬＡＮフリー
バックアップの場合、個々のサーバに関するデータのバ
ックアップに関しては、上記のバックアップ動作とほぼ
同じである。違いは、複数のサーバに関するデータのバ
ックアップを行う必要が有るので、これら複数のサーバ
からのバックアップ処理による競合を制御する必要が有
り、この競合を制御する機能がＳＡＮ管理装置に求めら
れる。例えば、ＳＡＮ管理装置は、予め定められたスケ
ジュール等に従って複数のサーバにバックアップ指示を
指示することによって、テープライブラリへのアクセス
の集中を避ける機能等が必要となる。

【００６８】ＳＡＮ管理装置の動作例として図１６に示
すゾーニング（Ｚｏｎｉｎｇ）機能を制御する例を示
す。図１６において、クラスタサーバは、ファブリック
・スイッチ（Ｆａｂｒｉｃ Ｓｗｉｔｃｈ）を経由して
ストレージに接続される。ここで、ファブリックスイッ
チは、論理的に分割されており、即ち、複数のスイッチ
としてみなされる。従って、ゾーニング１のスイッチの
ストレージ側出力先と、ゾーニング２またはゾーニング
３のスイッチのストレージ側出力先を分離しておけば、
ゾーニング１のスイッチに属しているクラスタサーバか
らは、ゾーニング２またはゾーニング３のスイッチをア
クセスすることはできず、ゾーニング１に属するクラス
タサーバからゾーニング２またはゾーニング３のスイッ
チのストレージ側出力先への不正アクセスを防ぐことが
できる。

【００６９】この様な、スイッチへのゾーニングの設定
は、ファブリック・スイッチと図示しないＳＡＮ管理装
置を図示しないＬＡＮ等で接続し、ＳＡＮ管理装置等か
らの指示でファブリックスイッチへ前述のようなゾーニ
ングを設定することで行うことができる。ＳＡＮ管理装
置を用いない場合、ファブリックスイッチへ専用コンソ
ール等を用いて設定することもできるが、クラスタサー
バやストレージを追加・変更・削除する毎に前記専用コ
ンソール等のところへ行きゾーニング用制御情報を設定
する必要が有り、非効率となる。ＳＡＮ管理装置を用
い、これから通信を用いて設定することで、その使い勝
手が改善される。

【００７０】以上、ＳＡＮ管理装置の２〜３の動作例を
示したが、基本的には、色々なデータ処理機能を提供す
る際にＳＡＮ管理装置は、サーバやストレージから操作
対象となるファイルやボリューム情報、操作タイミン
グ、データ移動先、等を取得し、その情報に基づいて必
要な装置にファイルやボリュームの処理（レプリカの作
成、データコピー、レプリカの分離、バックアップコピ
ー、リモートコピー、等）を、操作タイミング等の情報
に基づいて指示する。各装置はその指示に基づき、処理
を行い、処理結果をＳＡＮ管理装置へ返答する。それを
サーバやストレージに必要に応じて報告する。必要に応
じて、これら処理を依頼したクライアントへＳＡＮ管理
装置から報告を返しても良い。

【００７１】整理すると、ＳＡＮ管理装置（図１の運用
管理ソフトの端末）は、各アプリケーションサーバ上で
動作しているアプリケーションから、統合ストレージシ
ステム内のデータに関する処理の依頼を受け付ける第１
ステップ（このステップは別途事前に定められたスケジ
ュールに基づいてＳＡＮ管理装置が自発的にデータに関
する要求を生成するステップに置き換えることができ
る）、当該データに関する処理に必要な情報（処理対象
データを特定する情報、操作時間、データ移動先、等）
を得る第２ステップ、前記得た情報を元に、ストレー
ジ、ネットワークスイッチ、サーバ等に存在する各種機
能ソフト（レプリカの作成、データコピー、レプリカの
分離、バックアップコピー、リモートコピー、等の実行
ソフト）の起動順序や起動タイミング等の機能ソフト実
行スケジュールを決定する第３ステップ（本ステップは
各機能ソフトを連携させるステップとも云える）、決定
した実行スケジュールに基づいて実際に機能ソフトを起
動する第４ステップ、実行結果を各装置の機能ソフトか
ら結果を得る第５ステップ（この第４ステップの結果は
第３ステップの成果であるスケジュールに影響を与える
場合もある）、第５ステップの結果を、データ処理を依
頼したアプリケーションに報告する第６ステップを有す
るとも云える。なお、本ステップは便宜的に分けたステ
ップであり、２つのステップを統合したり、一方、更に
細かく分割して別ステップとしても問題ない。

【００７２】以上説明したように、ＳＡＮ管理装置は、
複数の機能ソフトを連携させ運用する機能を持つので、
個々の機能ソフトでは実現できなかった複雑な機能を容
易に実現でき、統合ストレージシステムにおいてより的
確にデータ処理を行うことが可能になる。尚、複数の機
能ソフトを連携させずに１つの大きなソフトを準備する
ことで複雑な機能を実現することも可能であろうが、デ
ータ処理の種類毎に一々ソフトを開発する必要が発生
し、融通の利かないシステムになる。

【００７３】次に、大規模な計算機システムにおいて、
ストレージシステム、ストレージエリアネットワーク技
術がどのように使われるかを具体例を用いて以下説明す
る。図１７は、最近拡大しつつあるインターネット・デ
ータセンタ（「ｉＤＣ」とも略称する）の構成例を示し
ている。インターネット・データセンタは、ＩＳＰ（イ
ンターネット・サービス・プロバイダ）や各企業のＷＷ
Ｗサーバを預かり（ハウジングという）、ネットワーク
管理やサーバ運用管理を提供する。さらにウエブ・デザ
インやＥＣ（エレクトリック・コマース）システムの構
築、高度なセキュリティの追加など付加価値サービスの
提供も行う。インターネット・データセンタは、インタ
ーネットビジネスを行いたい企業が抱えるシステム要員
やスキルの不足、サーバ設置場所やネットワーク網の整
備などの問題を解決するソリューションを一括して提供
している。

【００７４】インターネット・データセンタの特徴とし
て、高速ネットワーク回線などの高価な機器が共有され
るため、データセンタの提供者からすれば低コストで多
くの企業にサービスを提供できる。また、データセンタ
の利用者・利用企業からしても、バックアップ・保守な
どのわずらわしい作業から解放され、単独で運用するよ
りも低コストで済む。ただし、各企業が使うインターネ
ット環境、アプリケーションソフトウェアを数多く稼動
させるため、高速なインターネットバックボーン回線、
多くの高性能サーバが必要となる。また、それらには当
然のことながら、高信頼性、高セキュリティが必要とさ
れる。これら環境では高速かつ高機能なストレージシス
テムの存在が必要不可欠である。

【００７５】以下、インターネット・データセンタなど
の大規模システムへのストレージエリアネットワーク技
術の適用例を示していく。

【００７６】図１８は、インターネット・データセンタ
に大規模ストレージ・ストレージエリアネットワーク
（ＳＡＮ）を適用した場合の構成図の概略を示してい
る。企業ごとに複数のサーバ計算機が存在するが、ディ
スク・テープなどのストレージは１台ないし２〜３台の
わずかな台数に集約され、サーバとディスク・テープ装
置はファイバチャネルスイッチで相互結合される。ＳＡ
Ｎが存在しない環境では、個々のサーバ計算機に個々の
ストレージ装置を接続する必要があるが、ＳＡＮによ
り、ストレージ装置をすべての計算機から共有できるた
め、ストレージ装置を集約し、管理することが出来る。
また、ストレージ装置の増設においても、ホスト計算機
がオンラインの状態のまま増設が可能で、業務に影響を
与えない。

【００７７】また、バックアップの観点においても、Ｓ
ＡＮによるストレージの集約化は有効な役割を果たす。
ここで、図１９はインターネット・データセンタ内ＳＡ
Ｎ環境下での無停止バックアップの事例を示す構成図の
概略である。ここでは複数企業のそれぞれのサーバ計算
機、ストレージ、バックアップライブラリがストレージ
エリアネットワークにて相互結合される。そして、ＳＡ
Ｎ上ストレージ・デバイスの管理、バックアップの運用
を行うための管理ホストが存在する。各サーバ計算機の
データ、たとえばＷＷＷサーバにおけるＷｅｂコンテン
ツ、アプリケーションサーバで使われるデータはＳＡＮ
上のストレージに集約・格納されている。

【００７８】バックアップは各ホスト計算機の都合によ
りさまざまな要求が考えられる。例えばホスト計算機へ
のアクセス負荷が低くなる時点で、すなわち深夜など、
ディスクアクセス数が減る時間帯に毎日バックアップを
取る、あるいは更新系トランザクション処理の多いホス
ト計算機の場合には、トランザクションの切れ目など、
ホスト計算機がその時々の応じて任意のバックアップ開
始時間を決定したいなどの場合が存在する。管理ホスト
では、ホスト計算機のそれら要求を受けて適切にバック
アップ処理のマネジメントを行う。また、インターネッ
ト・データセンタは２４時間連続運用が重要であるた
め、ホスト計算機の処理を中断することは避けなければ
ならず、無停止バックアップが必須である。以下、バッ
クアップ処理の一例を簡単に説明する。

【００７９】例えば、各サーバ計算機が１日１回、ある
タイミングでバックアップをとりたいという場合、管理
ホストではそれぞれのサーバ計算機のバックアップ開始
・終了のスケジューリングを行う。例えばＡ社のＷＷＷ
サーバのバックアップを深夜０時から実行し、１時から
はＢ社のアプリケーションサーバのバックアップ、１時
半からはＡ社のアプリケーションサーバのバックアップ
を行い、３時からはＢ社のＷＷＷサーバのバックアップ
を行うなどである。バックアップ処理に要する時間は各
サーバの保有するデータ量などに依存するため、管理ホ
ストは各サーバ計算機がどのくらいのデータをストレー
ジに保有しているかなども管理し、その上でバックアッ
プ所要時間を算出、スケジュールする。また、テープラ
イブラリが複数のテープドライブを有していれば、複数
のバックアップジョブを同時実行することも可能であ
る。

【００８０】Ａ社のバックアップを深夜０時から実行す
る場合を例にとって処理の流れを説明する。深夜０時に
なったら、管理ホストはディスク装置内にあるＡ社ＷＷ
Ｗサーバのデータのレプリカを作成する。そのために、
ディスク装置内にある空きディスク（論理ボリューム）
を探しだし、それをＡ社ＷＷＷサーバのレプリカボリュ
ームとして割り当て、レプリカ作成をディスク装置に指
示する。レプリカ作成の処理の流れについては、図５の
図示記載にて詳述されているとおりである。

【００８１】引き続き、テープライブラリのテープドラ
イブに、テープカートリッジを装填する。その後、レプ
リカボリュームからテープライブラリにデータをバック
アップし始める。データのバックアップを実際に行うの
は、Ａ社サーバ計算機で行っても良いが、管理ホスト、
あるいはディスク装置からテープライブラリにデータを
直接転送するダイレクトバックアップ機能がサポートさ
れている場合（ディスク装置、テープライブラリ、ＦＣ
スイッチのどれかがサポートしていれば良い）、それを
用いることも出来る。

【００８２】そうした場合、サーバ計算機はバックアッ
プが行われているかどうかについてまったく意識するこ
となく、自動的にバックアップが取れていることにな
る。バックアップ処理が完了すれば、テープカートリッ
ジをテープドライブから取り出し、ディスク装置のレプ
リカボリュームの使用を中止し、再び空きボリュームと
し、次のバックアップ処理に移る。

【００８３】この場合、ＳＡＮによって、テープライブ
ラリを共有、相互接続しているため、管理ホストなどの
役割によってテープライブラリの利用スケジュールを適
切に管理すれば、ホストが複数台あっても１台のテープ
ライブラリですべてのバックアップをまかなうことが出
来る。また、管理ホストのボリューム割り当てを適切に
行うことにより、バックアップ処理の必要があるときだ
けレプリカボリュームを用意すればよくなり、常時各ボ
リュームにレプリカボリュームを用意しておく必要もな
くなり、テープライブラリの台数、ボリュームの個数な
どを節約することが出来ている。

【００８４】次に、ＳＡＮによるストレージ装置の共有
はコスト削減のメリットが大きいが、一方で複数企業の
サーバが混在する環境下においては注意しなければなら
ない点もある。その１つがセキュリティである。ＳＡＮ
によりすべてのサーバ計算機がＳＡＮ上のすべてのスト
レージ装置にアクセスできてしまうため、Ａ社のデータ
を、同じＳＡＮ上にあるＣ社のサーバ計算機から覗けて
しまう。次に、これらの問題を解決する手段の事例を説
明していく。

【００８５】図２０はインターネット・データセンタに
おいて複数企業のサーバ計算機・ストレージがＳＡＮ上
に混在している環境を示している。図のように、Ａ，
Ｂ，Ｃ社がストレージを共有する環境下では、まずＦＣ
スイッチのゾーニング設定を行い、各社のサーバ計算機
が、ストレージ装置の特定のパスのみしかアクセスでき
ないように設定する。続いてディスク装置で、各パスに
各社のサーバ計算機が使用するＬＵを割り当てる。例え
ば図のように、Ｂ社でＬＵ１，ＬＵ２の２つの論理ユニ
ットを使用する場合には、中央のパスにＬＵ１，２をわ
りあて、Ｃ社でＬＵ０を使う場合には、右側のパスにＬ
Ｕ０を割り当てる。

【００８６】さらに、同一パス上に複数のＬＵがあり、
それを複数のサーバから共有する形になっているが、各
サーバが共有したくない場合もあり得る。例えば、図２
０では、Ｂ社がＬＵ１，２をアクセスできるバスを確保
しているが、ＬＵ１はＢ社サーバの中でもある特定のサ
ーバのみにアクセスを許可したい、という要求も有り得
る。そういった場合には、ＬＵＮによるアクセス制限を
実施する。Ｂ社の特定のサーバのＷＷＮをディスク装置
に登録し、ＬＵ１はこのＷＷＮが登録されたサーバだけ
がアクセスできるように設定することが出来る。

【００８７】これらゾーニング、パス割り当て、ＬＵＮ
単位のアクセス制限の設定は集中管理コンソールにて行
う。管理コンソールにてＦＣスイッチのトポロジーを確
認し、それをもとにゾーニングの設定をし、さらに各パ
スに必要なだけのＬＵをマップさせて、各社が使用でき
るＬＵを登録する。さらに同一パス内で相互アクセスを
許可したくないＬＵについては、集中管理コンソールは
アクセスを許可するホスト計算機のＷＷＮを取得し、そ
れをディスク装置に設定、ＬＵＮ単位のアクセス制限を
実施する。

【００８８】次に、ＳＡＮと各種ストレージからなる統
合ストレージシステムを用いた計算機システムについて
の応用例を説明する。近年企業の合併・統合が増えてい
る。それにより、企業間の計算機システムも統合する必
要性が出てくる。

【００８９】図２１は複数の企業の計算機システムが相
互結合された大規模計算機システムの事例を示す。企業
間のホスト計算機はインターネットで接続され、データ
の相互利用などが図られる。また、ストレージエリアネ
ットワークの導入により、ストレージについても各企業
内のストレージ同士が公衆回線網、あるいは専用線で相
互接続される構成がとれる。

【００９０】計算機システムの運用の観点において重要
な点は、データの統合にある。通常、各企業で用いられ
るアプリケーション・データベースは異なっており、装
置が単純に相互接続されただけではデータを直接相互利
用することはできない。そこで、一般には複数のデータ
ベースからのデータを集約・統合した、新規のデータベ
ースを構築していく作業が必要となる。

【００９１】図２１において、企業Ａ、Ｂとでそれぞれ
勘定処理などのトランザクション処理を行う基幹系デー
タベース、基幹系データベースのデータを利用しオフラ
インでの解析処理を行う情報系データベースとを持つ。
この事例では、企業Ａ、企業Ｂの基幹系データベースの
データを統合し、各種業務用のデータマートを作る。場
合によっては、一旦単一の大規模なデータウェアハウス
を作成し、そこから各種業務アプリケーション向けの小
規模なデータマートを作る流れもある。ストレージエリ
アネットワークによるストレージ同士が接続された環境
が存在しない場合には、データベースの統合の際、ホス
トコンピュータ・ネットワーク経由でデータを移動する
必要がある。通常、企業間で共有したいデータベースは
大容量のものが多いため、データ転送に大変時間がかか
る。

【００９２】図２１の事例では、ストレージのリモート
コピー機能を用い、企業Ｂのレプリカを作成する。１日
１回、あるいは１週間に１回などの周期で、一旦レプリ
カボリュームをスプリットし、スプリットされたレプリ
カボリュームの内容をレプリケーションサーバが読み出
し、各種データマートを作成していく。レプリケーショ
ンサーバはデータマートを利用する各種情報系ＤＢＭＳ
とは別に存在する。ストレージエリアネットワークでス
トレージが相互結合され、ストレージのリモートコピー
機能を用いることにより、ホストに一切負荷をかけるこ
となくデータベースのレプリカが作成できる。またデー
タマートを作成するレプリケーションサーバと、情報系
ＤＢＭＳとがそれぞれ別のホスト計算機で実現できるこ
とから、データマート作成の処理が、基幹系ＤＢ，情報
系ＤＢの業務に影響を与えずにすむ。

【００９３】

【発明の効果】本発明によれば、ＳＡＮを用いたストレ
ージシステムにおける構成要素又は機能の連携を強化す
ることで統合ストレージシステムを構築でき、図３に示
す種々の機能を全て奏させることができる。

【００９４】さらに、統合ストレージシステムを、イン
ターネットに接続して大容量のデータ保存とその利用を
図るインターネットデータセンタに適用することによっ
て、インターネット情報サービスをコスト並びに量と質
の両面で効率良く且つタイムリーに提供することができ
る。

【図面の簡単な説明】

【図１】本発明の実施形態に係る統合ストレージシステ
ムの基本的な全体構成を示した概略図である。

【図２】従来技術のストレージシステムの全体構成を示
した概略図である。

【図３】本発明の実施形態に係る統合ストレージシステ
ムの主たる機能を説明する図である。

【図４】本実施形態の無停止バックアップについての基
本的なシステム構成を示す図である。

【図５】本実施形態の無停止バックアップについての機
能乃至作用を説明する図である。

【図６】本実施形態の無停止バックアップについてのミ
ラーリングソフトを用いたシステム構成を示す図であ
る。

【図７】バックアップシステムにおける事前準備とシス
テム構築の例を示す図である。

【図８】本発明の実施形態に係るテープを共用するバッ
クアップの種々のシステム構成例を示す図である。

【図９】複数サーバが１台のテープライブラリを共有す
るテープ共用バックアップの構成を示す図である。

【図１０】本発明の実施形態に係るディザスタリカバリ
での非同期リモートコピーのシステム構成を示す図であ
る。

【図１１】本発明の実施形態に係るデータシェアリング
でのサーバ間ＤＢ高速レプリケーションのシステム構成
を示す図である。

【図１２】本発明の実施形態に係るシステム統合運用管
理の内の障害監視とバックアップ運用を示す図である。

【図１３】本発明の実施形態に係るシステム統合運用管
理の内のストレージ性能の集中管理を示す図である。

【図１４】本発明の実施形態に係るシステム統合運用管
理の内のストレージ管理、特にＬＵＮマネージャとＬＵ
Ｎセキュリティを示す図である。

【図１５】本発明の実施形態に係るシステム統合運用管
理の内のストレージ管理、特にサブシステム内の階層制
御を示す図である。

【図１６】本発明の実施形態に係るシステム統合運用管
理の内のスイッチ管理、特にゾーニング設定を示す図で
ある。

【図１７】本発明の実施形態に係る統合ストレージシス
テムを用いたインターネットデータセンタのシステム構
成の概要を示す図である。

【図１８】本実施形態のインターネットデータセンタに
おけるストレージ統合を示す図である。

【図１９】本実施形態のインターネットデータセンタに
おける無停止バックアップのシステム構成を示す図であ
る。

【図２０】本実施形態のインターネットデータセンタに
おけるセキュリティ確保のシステム構成を示す図であ
る。

【図２１】複数の企業の計算機システムが相互結合され
た大規模計算機システムの構成例を示す図である。

フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 12/16 ３１０ Ｇ０６Ｆ 12/16 ３１０Ｊ ５Ｂ０８３ 13/00 ３０１ 13/00 ３０１Ａ 13/10 ３４０ 13/10 ３４０Ａ 15/16 ６２０ 15/16 ６２０Ｈ 15/177 ６７８ 15/177 ６７８Ｂ (72)発明者 本間 繁雄 神奈川県小田原市国府津2880番地 株式会 社日立製作所ストレージシステム事業部内 (72)発明者 守島 浩 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウエア事業部内 (72)発明者 大枝 高 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 伴野 洋二 東京都品川区南大井六丁目27番18号 株式 会社日立製作所情報コンピュータグループ 内 Ｆターム(参考） 5B014 EA04 EB04 FA02 FB04 HA09 HC03 5B018 GA10 HA04 HA05 MA01 5B045 BB07 BB15 DD16 JJ43 5B065 BA01 BA03 CA19 CE24 EA35 EK01 ZA01 ZA02 5B082 DE05 HA01 5B083 AA08 BB01 CC04 CD11 DD01 EF08 GG04

Claims (9)

【特許請求の範囲】
1. 【請求項１】 複数のクライアントコンピュータ、複数
   の各種サーバ、データを保存する複数の各種ストレー
   ジ、前記コンピュータと前記サーバを接続するローカル
   エリアネットワーク（ＬＡＮ）、前記サーバと前記スト
   レージの間に介在するストレージエリアネットワーク
   （ＳＡＮ）、を備えた計算機システムであって、 前記ＳＡＮは、ファイバチャネルスイッチ（ＦＣスイッ
   チ）によって前記サーバと前記ストレージを任意に相互
   接続し得る回線網を形成し、 前記各種ストレージの論理ボリューム、データ配置、障
   害監視を含むストレージ管理と、前記ＦＣスイッチの設
   定管理と、前記ストレージのデータのバックアップ運用
   と、を行う管理運用ソフトウエアを備えた端末を有する
   ことを特徴とする計算機システム。
2. 【請求項２】 請求項１に記載の計算機システムにおい
   て、 前記ＳＡＮは他の計算機システム内のＳＡＮとワイドエ
   リアネットワーク（ＷＡＮ）を通して接続されることを
   特徴とする計算機システム。
3. 【請求項３】 請求項１に記載の計算機システムにおい
   て、 ストレージの正ボリューム内のデータをバックアップ装
   置に無停止バックアップする場合、当該ストレージの内
   部機能よって正ボリュームに対応する副ボリュームを作
   成して前記正ボリュームから副ボリュームにコピーを作
   成し、作成されたコピーを前記ＬＡＮを経由することな
   く前記ＳＡＮ経由で前記バックアップ装置に転送してバ
   ックアップすることを特徴とする計算機システム。
4. 【請求項４】 複数のクライアントコンピュータ、複数
   の各種サーバ、データを保存する複数の各種ストレー
   ジ、前記コンピュータと前記サーバを接続するローカル
   エリアネットワーク（ＬＡＮ）、前記サーバと前記スト
   レージの間に介在するストレージエリアネットワーク
   （ＳＡＮ）、を備えた計算機システムであって、 前記ＳＡＮは、ファイバチャネルスイッチ（ＦＣスイッ
   チ）によって前記サーバと前記ストレージを任意に相互
   接続し得る回線網を形成し、 ストレージ内のデータをバックアップ装置に無停止バッ
   クアップする場合、当該ストレージは、サーバからのボ
   リューム分割の指示を受ける機能を有し、当該指示時点
   で正ボリュームのデータがそのまま副ボリュームに保存
   されているように見せかける機能を有すると共に、前記
   副ボリュームからバックアップ装置にバックアップする
   機能を有することを特徴とする計算機システム。
5. 【請求項５】 サーバ、前記サーバのデータを記録する
   ストレージ、前記サーバと前記ストレージを接続するネ
   ットワーク、前記ネットワークに接続されて前記データ
   のバックアップを取るバックアップ装置、から構成され
   るシステムの管理方法であって、 処理対象であるデータを識別する情報を入手する第１ス
   テップ、 前記情報が示すデータの処理内容を入手する第２ステッ
   プ、 前記情報が示すデータを保持する前記ストレージに対し
   て、前記処理内容を指示する第３ステップ、および前記
   情報が示すデータが処理された結果を前記ストレージか
   ら受ける第４ステップを有することを特徴とするシステ
   ムの管理方法。
6. 【請求項６】 請求項５に記載のシステムの管理方法に
   おいて、 前記処理内容は、前記ストレージから前記バックアップ
   装置へ前記データを転送することであることを特徴とす
   るシステムの管理方法。
7. 【請求項７】 請求項５に記載のシステムの管理方法に
   おいて、 前記処理内容は、前記情報で指示されるデータの複製を
   作成することと、前記作成した複製データを前記バック
   アップ装置へ転送することであることを特徴とするシス
   テムの管理方法。
8. 【請求項８】 請求項５に記載のシステムの管理方法に
   おいて、 更に、当該処理内容を実行するタイミングを入手する第
   ５ステップと、前記タイミングに従い前記第３ステップ
   の実行タイミングを制御する第６ステップとを有するこ
   とを特徴とするシステムの管理方法。
9. 【請求項９】 請求項５ないし８のいずれか１つの請求
   項に記載のシステムの管理方法において、 前記システムの前記サーバはインターネットに接続さ
   れ、前記データを前記インターネットへ送出するもので
   あることを特徴とするシステムの管理方法。