JP4113352B2 - ストレージ・ネットワークにおけるストレージ・リソース運用管理方法 - Google Patents
ストレージ・ネットワークにおけるストレージ・リソース運用管理方法 Download PDFInfo
- Publication number
- JP4113352B2 JP4113352B2 JP2001333673A JP2001333673A JP4113352B2 JP 4113352 B2 JP4113352 B2 JP 4113352B2 JP 2001333673 A JP2001333673 A JP 2001333673A JP 2001333673 A JP2001333673 A JP 2001333673A JP 4113352 B2 JP4113352 B2 JP 4113352B2
- Authority
- JP
- Japan
- Prior art keywords
- storage
- storage resource
- resource
- distance
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/912—Applications of a database
- Y10S707/918—Location
- Y10S707/919—Geographic
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/953—Organization of data
- Y10S707/959—Network
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Description
【０００１】
【発明の属する技術分野】
本発明は、複数のストレージと複数のサーバを高速に繋いだストレージ・ネットワーク、すなわち、ＳＡＮ（Storage Area Network）や複数のＮＡＳ（Network Attached Storage）を保有して、ストレージ内の領域（ストレージ・リソース）を顧客に提供するＳＳＰ(Storage Service Provider)の運用管理技術に関し、特に、顧客の要求に合致した最適なストレージ・リソース選択技術、ディザスタ・リカバリ(disaster recovery)技術、及びコスト削減技術に関する。
【０００２】
【従来の技術】
従来、ストレージは、ディスク装置やテープ装置などのサーバの外部記憶装置という付属物として使用されていた。しかし、情報の重要性や蓄積量の拡大に伴い、複数のシステム間でのデータ交換や共有が必要となり、大容量ストレージを持つＮＡＳ(Network Attached Storage)や、ストレージ群とサーバ群を高速に接続する専用のネットワーク、ＳＡＮ（Storage Area Network）が普及してきた。ＳＡＮではサーバ群とストレージ群とによって、ストレージ統合を実現したことにより、システム運用の効率化を実現する。
【０００３】
企業内のストレージ管理者は、ＳＡＮのトポロジ管理や、ＮＡＳ機器とサーバ間の接続を運用管理するために、一般的に管理ツールを使用する。
【０００４】
管理ツールでは、ストレージやサーバに関する容量、空き容量、接続形態等の情報を収集し、ＳＡＮに接続されたサーバやストレージ、ネットワーク機器を画面上に表示する。画面上では、各機器に関連づけられたアイコンをクリックすることにより、各ストレージの容量やサーバへの割り当て状況などのより詳細な情報を表示できる。そして、管理情報の収集、表示のみでなく、サーバへの、ストレージやストレージ内の論理的な領域（以下、ストレージと、ストレージ内の論理的な領域を総称して、ストレージ・リソースと呼ぶ）割り当てや、削除、変更を行っている。また、上記ツールに、バックアップ設定・ツール等を組み合わせることにより、効率よく、システムの可用性を高めている。
【０００５】
しかし、企業内のストレージ運用管理者は、近年の予測不可能なストレージの増量に対するコスト増、多岐に渡る管理ツールの複雑化、設置スペースの省スペース化等の問題に直面している。これらの問題は、企業内情報リソースを、ストレージ運用管理を専門に行う企業へとアウトソーシングし、ストレージの運用管理を全て外部企業に委託することによって、解決可能である。ストレージを運用管理し、顧客へとストレージ・リソースを貸し出す企業として、ＳＳＰ（Storage Service Provider）がある(月刊コンピュートピア データストレージ・レポート２０００：P36-P37)。
【０００６】
図１はＳＳＰ103の運用形態を示すネットワーク構成図である。
【０００７】
企業内情報リソースをアウトソーシングしたい顧客は、ＳＳＰ103内に、自社のサーバである顧客サーバ108を設置し、自社内に設置する顧客コンソール100から自社の顧客サーバ108にアクセスする。ＳＳＰ103は、管理サーバ104、ストレージ装置(106、107)、ＳＡＮ105、顧客サーバ群（108、109、110）から構成し、管理サーバ104によって、ＳＡＮ105に接続している全てのノードを管理する。ＳＡＮ105は、ファイバーチャネルや、イーサネット等で構成する。顧客コンソール100と顧客の自社サーバである顧客サーバ108は、インターネット上でＶＰＮ（Virtual Private Network）を使用し（101）、ＮＦＳ(Network File System)か、ＣＩＦＳ（Common Internet File System）によって接続する。もしくは、専用線で接続する。顧客コンソール100と管理サーバ104は、インターネット102を経由して接続する。
【０００８】
ＳＳＰ103では、顧客から顧客コンソール100を通じてストレージの領域割り当ての要求があった場合、顧客コンソール100から、顧客のストレージに対する要求である、アクセス性能、信頼性、用途等を聞き、要求に合致するストレージ・リソースを選択する。ストレージ・リソース選択には、管理ツールを使用する。管理ツールは、ストレージ・リソースの稼働状況、使用状況、スループットといったストレージ・リソースの状態を表す値（以下、ストレージ・リソースの状態を示す値を、リソース状態情報と呼ぶ）を、ストレージから常に取得している。ＳＳＰ103では、上記リソース状態情報を選択因子として、リソース状態情報から、顧客100の要求に合致するストレージ・リソースを選択する。
【０００９】
次に、ＳＳＰ103は、選択したストレージ・リソースを顧客サーバ108に割り当てる。ストレージ・リソースを顧客サーバ108に割り当てるには、既存のＳＡＮトポロジ管理ツールや、ストレージ内のボリューム管理ツールを使用する。上記ストレージ・リソースの割り当てにより、顧客は性能要求を満たすストレージ・リソースを、顧客サーバ108において使用可能になる。また、顧客サーバ108内の情報を顧客コンソール100から閲覧、設定、変更可能となる。
【００１０】
図２は、顧客サーバ108へのストレージ・リソース割り当て処理のフロー図である。
【００１１】
ＳＳＰ103は、常にストレージの稼働率、負荷率、空き容量、ＲＡＩＤレベル、ＤＩＳＫ性能等といった、ストレージ内のリソース状態情報（200）を取得している（ステップ201）。この状態において、顧客コンソール100からストレージ領域の貸し出し要求と共に、ストレージ・リソースに対する容量と性能に関する要求(202)を受けた場合（ステップ203）、取得済みのリソース状態情報(200)を選択因子として、顧客の要求に合致するストレージ・リソースを選択する（ステップ204）。選択したストレージ・リソースを顧客サーバ108に割り当てる（ステップ205）。割り当てには、既存のＳＡＮトポロジ管理ツールや、ストレージ内ボリュームの割り当てツール等を使用する。ＳＳＰ103は、ストレージ・リソースが使用可能になったことを、管理サーバ104を通じて、顧客コンソール100に通知する(ステップ206)。
【００１２】
また、ＳＳＰ103では、顧客サーバ108が使用するストレージ・リソースに対して、障害発生時のリカバリ用にバックアップを取る。その際、バックアップしたデータが、障害によって同時に失われないようにするため、クライアントの使用しているストレージ装置とは異なるストレージ装置を確保し、ストレージ・リソース内のデータをコピーする。
【００１３】
上記従来技術では、ＳＳＰ103が、ＳＳＰ103内に顧客のサーバ（108、109、110）を保有し、ＳＡＮ105を使用させる形態を示した。しかし、ＳＳＰ103では、ＳＳＰ103内のＳＡＮ105から直接顧客社内へと、ネットワークを接続し、ストレージ・サービスを行う形態もある。この場合、図１に示した顧客サーバ108が、図１に示した顧客コンソールの場所に位置するネットワーク構成となる。
【００１４】
以上により、従来技術では、管理ツールもしくはストレージ管理者が、ストレージ・リソースのリソース状態情報をもとに、顧客の要求する容量や性能に合致するストレージ・リソースを選択し、顧客サーバへの割り当てを実現している。また、ストレージ・リソース内のバックアップを取ることによりＳＳＰの高可用性を維持している。
【００１５】
【発明が解決しようとする課題】
従来の技術では、管理ツールから得られる、各ストレージ内のリソース状態情報（ストレージ・リソースの稼働状況、容量、使用状況、スループット等）を選択因子として使用することにより、顧客の要求するストレージの容量とアクセス性能を満たすストレージ・リソースを選択し、割り当てた。
【００１６】
しかし、広域網を使用し、遠距離に散在するＳＡＮ上のリソースやＮＡＳを顧客に統合的に提供するようなＳＳＰでは、ＳＳＰ内において多数の複合的なネットワークを使用することになる。このようなネットワーク上では、ストレージ・リソースと顧客サーバ間のネットワーク・アクセス時間が、ストレージへのアクセス性能に影響する。よって、単純にストレージ・リソース内のアクセス性能を決定する要因であるリソース状態情報（稼働率、ディスク性能等）だけでは、顧客の要求するトータル的なアクセス性能を満たすことが困難となる。
【００１７】
さらに、広域化して遠距離に渡り散在するストレージを有効に活用し、地震などの災害対策用のバックアップを実施しようとした場合、現在の管理ツールでは、ストレージ装置の設置地域等の位置情報を取得していないため、指定した距離以上離れたストレージ装置を意図的に選択する手段がない。
【００１８】
また、ＳＳＰを利用する顧客が引越しした場合、引越し先からのストレージ・リソースへのネットワーク・アクセス時間を考慮することがないため、顧客サーバの引越し先近くのストレージへと、データを移動する場合がある。そのため、顧客の引越し毎にデータを移動するための作業コストを必要としている。
【００１９】
本発明の目的は、以下の３つである。
（１）顧客にストレージ・リソースを提供するストレージ管理システムにおいて、顧客の要求に対して、ストレージ・リソース性能だけでなく、顧客の使用するノードからストレージ・リソースまでのネットワーク・アクセス性能についても満たしているストレージ・リソースを選択する。そして、顧客の要求に合致する最適なストレージ・リソースを、顧客に提供可能なストレージ・リソース運用管理方法を提供することである（以下、ノードからストレージ・リソースまで、もしくは、ストレージ・リソース間、ノード間のネットワーク・アクセス性能に関わる、ホップ数（通信の途中で何段のルータを介するかを示す数）やパケット応答時間、ネットワークスループット等の情報を、ネットワーク的な距離と呼ぶ）。
（２）広域に散在するストレージ・リソースの中から、意図的に設定した距離以上離れた複数のストレージ・リソースを選択してバックアップし、地震などの地域的な災害発生時における耐災害性向上方法を提供することである。
（３）ストレージ・リソースにアクセスするノードとストレージ・リソース間の地理的な距離が変化した場合に、変化後のノードからストレージ・リソースまでのネットワーク的な距離が、顧客のアクセス性能に対する要求を満たしていれば、ストレージ・リソースの移動や、ストレージ・リソース内データの移動を行わないといった、移動に関わる作業コストの削減方法を提供することである。
【００２０】
【課題を解決するための手段】
上記３つの目的を達成するために、本発明では、ストレージ・リソースを利用するノードからストレージ・リソースまでのネットワーク・アクセス性能に関わる情報（以下、ネットワーク・アクセス性能に関わる情報をネットワーク的な距離と呼ぶ）と、上記ノードとストレージ・リソース間、各ストレージ・リソース間の物理的な位置関係に関わる情報（以下、物理的な位置関係に関わる情報を、物理的な距離と呼ぶ）を使用することによって、ストレージ・リソースを運用管理する方法を提供する。また、本方法を使用した耐災害性向上方法、および、作業コスト削減方法を提供する。
【００２１】
具体的には、以下の（１）から（７）の方法を提供する。
（１）ストレージ・リソース運用管理方法
ネットワークを介してストレージへアクセス要求を送信するノードと、アクセス要求を受信して実行する複数のストレージ群からネットワークを構成する。本構成において、前記ノードとストレージ群内のストレージ・リソース間もしくはストレージ・リソース群内の各ストレージ・リソース間のネットワーク的な距離と、ノードとストレージ・リソース間もしくはストレージ・リソース群内のストレージ・リソース間の物理的な距離との、両方または一方を取得する。さらに取得した距離に対する要求を取得し、要求の範囲を、ストレージ・リソースを選択する際の選択因子とする。
【００２２】
本方法により、広域に散在するストレージ・ネットワークから、ストレージ・リソース自体の性能のみでなく、ストレージにアクセスするノードからストレージ・リソースまでのネットワーク的な距離や、ストレージ間の物理的な距離などを加味して選択することができる。よって、ストレージを利用する顧客にとって、最適なストレージ・リソースを提供可能な、ストレージ・リソース運用管理方法を提供することができる。
（２）最適ストレージ・リソース選択方法
上記（１）の方法において、ネットワーク的な距離と物理的な距離のどちらか一方、もしくは両方を取得する。さらに、取得した距離に対する要求を取得し、要求の範囲をストレージ・リソースの選択条件とする。そして、ネットワーク的な距離が要求の範囲内であるストレージ・リソースを、もしくは、物理的な距離が要求の範囲内であるストレージ・リソースを、もしくはその両方に合致するストレージ・リソースを選択する。
（３）最適ストレージ・リソース選択方法
上記（２）に示した方法によって、上記（２）で示した要求の範囲内に設置されているストレージ・リソースが複数存在した場合、要求の範囲内にあるストレージ・リソースの中で、最もネットワーク的な距離が近いか、最も物理的な距離が近いか、最も物理的な距離が遠いかの、いずれかの組み合わせ、もしくは、１個の条件を使用して、さらに最適なストレージ・リソースを選択する。
（４）最適ストレージ・リソース選択方法
上記（２）に示した方法によって、上記（２）で示した要求の範囲内に設置されているストレージ・リソースが見つからなかった場合、全ストレージ・リソース中で、上記（２）のネットワーク的な距離が最も近いか、上記（２）の物理的な距離が最も近いか、上記（２）の物理的な距離が最も遠いかの、いずれかの組み合わせ、もしくは、１個の条件を使用して、ストレージ・リソースを選択する。
（５）最適ストレージ・リソース作成方法
上記（２）に示した方法によって、上記（２）で示した要求の範囲内に設置されているストレージ・リソースが見つからなかった場合、上記（２）で示したネットワーク的な距離が要求の範囲内にあるか、もしくは、上記（２）で示した物理的な距離が要求の範囲内にあるか、もしくは両方を満たすストレージ・リソースを新たに追加する。
【００２３】
上記（２）から（５）の方法により、（１）と同様に、ストレージ・リソースに対する要求を示すノードにとって、最適なストレージ・リソースを提供可能な、ストレージ・リソース運用管理方法を提供することができる。
（６）耐災害性向上方法
上記（１）に示したネットワークに存在するストレージ・リソースに対して、上記（２）で示した方法によって、物理的な距離に対する要求の範囲を取得する（以下前記ストレージ・リソースをプライマリ・リソースと呼ぶ）。設定した要求の範囲内に設置された、プライマリ・リソースとは異なるストレージ・リソースを選択し（以下、セカンダリ・リソースと呼ぶ）、プライマリ・リソース内に格納されているデータの一部もしくは全部を複製し、セカンダリ・リソースに格納する。そして、プライマリ・リソースが何らかの障害により使用できない場合に、アクセス要求を送信するノードからのプライマリ・リソースに対するアクセス要求を、セカンダリ・リソースにおいて実行する。
【００２４】
本方法により、意図的に遠く離れた位置にストレージ・リソース内のデータをバックアップすることが可能である。よって、局所的に発生する災害等に対して、ストレージ・リソース内のデータを保全でき、ディザスタ・リカバリ(disaster recovery)することができる。
（７）コスト削減方法
上記（１）に示したネットワークに存在するノードとストレージ・リソースに対して、上記（２）で示した方法によって、ネットワーク的な距離に対する要求を取得する。前記ノードの物理的な位置が移動した場合、移動後にもノードからストレージ・リソースまでのネットワーク的な距離が、取得した要求の範囲内であるか判断する。ネットワーク的な距離が要求の範囲内であれば、ストレージ・リソース内データの格納位置の移動を行わない。
【００２５】
本方法により、ストレージを使用する顧客のサーバが引越し等によって移動した場合において、移動後のサーバからストレージ・リソースまでのネットワーク・アクセス性能が、移動前と変化するか調べることができる。そして、アクセス性能が、顧客の要求する性能の範囲内であれば、データの移動を行う必要がないと判断することができる。よって、ストレージ・リソース運用管理において、移動にかかるコストを削減することができる。
【００２６】
【発明の実施の形態】
以下に、本発明の第一の実施形態について説明する。
【００２７】
図３は、本発明の第一の実施形態が適用されたＳＳＰ302の運用形態を示すネットワーク構成図である。
【００２８】
コンソール300は、企業内情報リソースをアウトソーシングしたい顧客のコンソール・ノードを示す。顧客は、自社のサーバである顧客サーバ304をＳＳＰ302内に設置し、コンソール300から顧客サーバ304内のアプリケーションの設定や、変更、情報取得を行う。顧客社内に設置されたコンソール300と、ＳＳＰ302内に接続された顧客サーバ304は、インターネット301を介してＶＰＮ接続したネットワーク上でＮＦＳによってアクセスする。
ＳＳＰ302は、管理サーバ303、顧客サーバ304とストレージ装置（306、307）、ルータ305とから構成する。管理サーバ303、顧客サーバ304、ストレージ装置306、ルータ305間はEthernet308でＬＡＮ接続する。また、ストレージ装置307、ルータ305間はEthernet309でＬＡＮ接続する。ＬＡＮ308とＬＡＮ309間は、ルータ305によって、ルーティングする。図３の構成では、ストレージ装置(306、307)および管理サーバ303、顧客サーバ304間の接続にEthernetとルータを用いているが、本方法はこの構成に限定するものではない。ストレージ装置と顧客サーバ間をファイバーチャネル等によって接続し、ファイバーチャネル間をファイバーチャネル・スイッチ等で接続しても構わない。また、コンソール、顧客サーバ、管理サーバ、ルータ、ストレージ装置の全てにおいて、台数、ルータ段数を限定しない。また、コンソール300とＳＳＰ302内のノードとの接続形態は、インターネットのみに限定せず、専用線やＡＴＭなどであっても構わない。
【００２９】
上記ネットワーク構成において、顧客がコンソール300を使用してＳＳＰ302の管理サーバ303にストレージ装置内の論理的な領域の割り当て要求を出すと、管理サーバ303は領域に対する顧客の要求に合致する論理的な領域を選択し、顧客サーバ304に割り当てる。本実施の形態では、上記ストレージ装置、上記ストレージ装置内の物理的な単位領域、装置内の論理的な単位領域、複数のストレージ装置にまたがって作成された論理的な単位領域を総称して、ストレージ・リソースと呼ぶ。管理サーバ303では、ストレージ・リソースの割り当て後、顧客サーバ304のアドレスをコンソール300に通知し、コンソール300から顧客サーバ304へのアクセスと、顧客サーバからストレージ・リソースへのアクセスを可能とする。
【００３０】
以下、コンソール300、顧客サーバ304、管理サーバ303について、図４、図５、図６を用いて、順に説明する。
【００３１】
図４は、コンソール300と顧客サーバ304の構成図である。コンソール300は、要求送信プログラム（Webブラウザ）400 が起動し、インターネット上のWWWサーバにアクセスする。また、コンソール300は、ＮＦＳを使用して顧客サーバ304にアクセス可能である。要求送信プログラム（Webブラウザ）400では、管理サーバ303上のクライアント位置情報入力ページと、ストレージ・リソース選択条件入力ページにアクセスし、それぞれ入力設定を行う。また、ストレージ状態表示ページにアクセスし、顧客サーバ304に割り当てられたストレージ・リソースの容量、使用率、スループット等のリソース状態情報を閲覧可能である。また、パケットの応答時間や、経由するルータの段数を示すホップ数といったネットワーク的な距離や、設置場所の緯度と経度によって表すことが可能な物理的な位置関係に関する情報を閲覧することができる。
【００３２】
顧客サーバ304では、ネットワーク的距離取得プログラム401が稼動し、定期的に全ストレージ装置に対して、ネットワーク診断プログラムであるPingプログラムを実行し、返答パケットからストレージ・リソースへのパケット応答時間を測定する。その際、顧客サーバ304 とストレージ間のホップ数を取得し、両値をネットワーク的な距離として管理サーバに通知する。
【００３３】
図５は、管理サーバ303の概略図である。管理サーバ303は、クライアント要求受信プログラム（WWWサーバ）500、データ・ベース501、ストレージ管理プログラム502とから構成する。
【００３４】
クライアント要求受信プログラム500はWWWサーバであり、クライアント位置情報入力ページと、ストレージ・リソース選択条件入力ページ、および、ストレージ状態表示ページをWebブラウザに送信する。クライアント要求受信プログラム500では、コンソール300からのWebページ入力によって、ストレージ・リソース選択条件とクライアント位置情報（緯度、経度）を取得する。
【００３５】
ストレージ管理プログラム502は、ネットワーク構成検索・取得部503、バックアップ設定部504、ストレージ・リソース割り当て部505、ノード位置情報取得部506、ストレージ・リソース選択部507、ＧＵＩ部508とから構成する。バックアップ設定部504と、ストレージ・リソース割り当て部505は既存技術で動作する。
【００３６】
ネットワーク構成検索・取得部503では、ＳＳＰ302内のストレージ・ネットワーク（308、309）に接続されている機器の情報を収集し、データベース501に格納する。さらに、顧客サーバ304上のネットワーク的距離取得プログラム401によって取得した情報もデータベース501に格納する。ノード位置情報取得部506では、検出したストレージのそれぞれの設置位置（緯度、経度）を、GUI部508経由で取得し、物理的な距離を算出する。算出した距離は、データベース501に格納する。ストレージ・リソース選択部507では、ストレージ・リソースに対する顧客の要求性能や要求容量に合致するストレージ・リソースをデータベース中から検索して選択する。ＧＵＩ部508では、ネットワーク構成検索・取得部503で取得したストレージ・サーバや顧客サーバを画面上に表示し、ＳＳＰ302の管理者から手入力で、各ノードの設置位置、緯度および経度を入力する。
【００３７】
図６は、データベース501内のストレージ・リソースに関するストレージ・リソース情報テーブル600を示す図である。ストレージ・リソース情報テーブル600は、ストレージ名とＬＵＮ601、平均稼働率（％）602、容量（ＧＢ）603、ディスク性能を表す回転数(ｒｐｍ)604、ディスク内のアクセス時間(ｍｓｅｃ)605、顧客サーバからのパケット応答時間（ｍｓｅｃ）606、ストレージ装置の設置場所（北緯・東経・地名）607、顧客サーバからの物理的距離（ｋｍ）608、顧客サーバとストレージ装置間のホップ数（段）609を格納する。ストレージ・リソース情報テーブルは、顧客サーバ毎に１テーブル作成する。情報テーブル600は、ストレージ・リソースを選択する際の選択因子として使用する。
【００３８】
以下、図７、図９、図１０を用いて、図４で示した管理サーバ303内のストレージ管理プログラム502のストレージ・リソース割り当て動作フローを説明する。図８を用いて、顧客サーバからストレージ・リソースまでのネットワーク的な距離の取得動作フローを説明する。図１１では、ストレージ・リソースに障害が発生した際の、ストレージ管理プログラム502の動作フローを説明する。
【００３９】
図７は、ストレージ管理プログラム502のストレージ・リソース割り当て動作フローである。ストレージ管理プログラム502は、ネットワーク構成検索・取得部503を使用して、ＳＳＰ302のストレージ・ネットワーク内について、ネットワーク・トポロジ（700）を検索し、ネットワーク構成に関する情報をデータベース501に格納する。また、見つかったストレージ・リソースに対して、稼働率、容量、ディスク回転数、ディスク内アクセス時間等のリソース状態情報（700）を取得し、データベース501内の情報テーブル600内に格納する（ステップ701）。
【００４０】
次に、ノード位置情報取得部506において、ストレージ・リソースの物理的な設置場所を示す緯度、経度（物理的な距離）を取得する。緯度、経度は、GUI部508を用いてＳＳＰ302の管理者が入力する。取得した緯度と経度から、全ストレージ・リソース間の物理的な距離を算出し、ストレージ・リソース情報テーブル600に格納する。さらに、顧客サーバ304とストレージ・リソースまでのパケット応答時間とホップ数（ネットワーク的な距離）（702）を、顧客サーバ304上で稼動するネットワーク的距離取得プログラム401から取得して、ストレージ・リソース情報テーブル600へ格納する（ステップ703）。
【００４１】
そして、ステップ703を一定間隔毎に繰り返し行う。顧客サーバ304でのネットワーク的距離取得の動作フローは、図８を用いて後述する。上記状態において、クライアント要求受信プログラム500を通じて、顧客からのストレージ・リソース割り当ての要求通知（704）と共に、顧客サーバ304からストレージ・リソースまでのネットワーク的な距離（パケット応答時間、ホップ数、ネットワーク・スループット等）に対する要求と要求ストレージ容量（705）を受信する（ステップ706）。
【００４２】
本実施の形態では、上記データ・アクセス性能に関する情報をネットワーク的な距離と呼ぶ。ネットワーク距離が近いということは、パケット応答時間が早く、ホップ数が少なく、ネットワーク・スループットが高いといった、データ・アクセスに要する時間が短い状態を示す。本第一の実施形態での、要求の範囲 (705)は、ホップ数が最も小さいこととする。ストレージ・リソース選択部507によって、要求の範囲と要求容量（705）に合致するストレージ・リソースを、データベース501に格納済みのリソース状態情報と、ネットワーク的な距離および物理的な距離情報とから検索して選択する（ステップ707）。本実施の形態では、地理的な位置関係から得られる実際の距離を物理的な距離と呼ぶ。さらに、ステップ707で選択したストレージ・リソースをプライマリ・リソースと呼ぶ。ステップ707における選択フローは、図９を用いて詳細を後述する。
【００４３】
次に、プライマリ・リソースを、従来方式同様に、ストレージ・リソース割り当て部505を用いて、顧客サーバ304に割り当てる（ステップ708）。管理サーバ303は、ストレージ・リソースのディザスタ・リカバリ用にストレージ・リソースを選択し、バックアップ設定部504によって、プライマリ・リソースのバックアップとして設定する（ステップ709）。以下、バックアップ用のストレージ・リソースを、バックアップ・リソースと呼ぶ。バックアップ・リソースを選択するステップについては、図１０を用いて後述する。バックアップの設定後、ストレージ・リソース割り当てが終了した通知（710）を、クライアント要求受信プログラム500を通じてコンソール300に対して送信する（ステップ711）。
【００４４】
図８は、顧客サーバ304上で稼働するネットワーク的距離取得プログラム401の、ネットワーク的距離情報取得の動作フローである。ネットワーク的距離取得プログラム401は、図７のステップ703におけるネットワーク的な距離の取得の際に、パケット応答時間とホップ数を取得し、ストレージ管理プログラム502に提供する。
【００４５】
顧客サーバ304上のネットワーク距離取得プログラム402では、顧客サーバから各ストレージ・リソースに対してPingプログラムを実行し、パケット応答時間とセグメントを渡る回数であるホップ数を取得する。Pingプログラムは本来ネットワーク診断プログラムであり、一定値のバイトのデータを指定ノードに対して複数回送信し、送信先のノードから返信があるかどうかでネットワークを診断する。
【００４６】
ネットワーク上のパケットが送信されつづけることを避けるために、ネットワーク上のパケットに有効期限を表すTTL（Time To Live）がある。TTLは送信時に設定し、パケットがルータを通過する毎に１減算され、0になるとパケットが破棄されるしくみである。これを使用して、TTL値を0から順に増加しながら目的ノードに対してPingプログラムを実行することにより、返答が初めて得られた際のTTL値が、目的ノードまでのルータ段数、すなわちホップ数を示す。またPingプログラムでは、複数回のデータ送信により、各パケットのパケット応答時間の平均も取得することができる。最初に、ストレージ・リソースのTTL値を0にしてPingプログラムを実行する（ステップ800）。
【００４７】
Pingプログラムによる応答が得られるか検証し（ステップ801）、応答が得られなければTTL値を１増加させて、再びPingプログラムを実行する（ステップ802）。これを全ストレージ・リソースに対して実行する。Pingプログラムにより応答が得られれば、TTL値から顧客サーバとストレージ・リソース間のホップ数を取得する（ステップ803）。同時にパケット応答時間を取得し（ステップ804）、ホップ数と共に管理サーバ303に通知する（ステップ805）。
【００４８】
図９は、図７内のプライマリ・リソース選択ステップ707の動作フローである。本実施形態では、コンソール300の要求が、ホップ数が一番小さいストレージ・リソースを選択することである（図７中ステップ705）。そのため、まず、データベース501内を検索し、ホップ数０段、すなわち、顧客サーバ404と同セグメントにあるストレージ・リソースを検索する（ステップ900）。ストレージ・リソースが見つからない場合（ステップ901）、ホップ数を一段増加し（ステップ904）、増加したホップ数以上遠くにストレージ・リソースがあるかどうか判断する（ステップ905）。
【００４９】
ストレージ・リソースが、指定したホップ数経由した先のセグメントか、それ以上先に存在する場合（ステップ905）、再び、ステップ901において、指定段数先のセグメントにストレージ・リソースがあるか検索する。ステップ901において、指定セグメント内にストレージ・リソースが存在する場合には、選択しているホップ数のセグメントにクライアント400の要求する容量以上の容量を持つストレージ・リソースが存在するか検索する（ステップ902）。ストレージ・リソースが見つからなければ、ホップ数を増加して再び検索する。（ステップ904）。ステップ902において、要求容量以上の容量を持つストレージ・リソースが見つかった場合、見つかったストレージ・リソース中、ディスク内平均アクセス時間と、Pingプログラムのパケット応答時間の合算が一番早いストレージ・リソースを、クライアント400用のストレージ・リソース、すなわち、プライマリ・リソースとして選択する（ステップ903）。
【００５０】
ステップ905において、目的容量以上持つストレージ・リソースがＳＳＰ302内で見つからなかった場合、顧客サーバからのホップ数0段のセグメント内に、顧客の要求容量以上のストレージ・リソースを作成する（ステップ906）。作成したストレージ・リソースを、プライマリ・リソースとして選択する（ステップ907）。
【００５１】
図１０は、図７内のバックアップ・リソース選択、および、定期バックアップ設定ステップ709の動作フローである。本動作フローでは、プライマリ・リソースが、地震などの災害により故障した際に、リソース内データをリカバリ可能にするための、バックアップの設定を行う。
【００５２】
本動作フローでは、まず、バックアップ・リソースとプライマリ・リソースを災害が波及しないと考えられるに十分な距離（以下、災害が波及しないと考えられるに十分な距離を安全距離と呼ぶ）を物理的な距離の要求の範囲として取得する（ステップ1000）。次に、プライマリ・リソース以外のストレージ・リソースから、プライマリ・リソース以上の容量を持つストレージ・リソースを検索する（ステップ1001）。上記ストレージ・リソースが存在しなければ（ステップ1002）、プライマリ・ストレージから安全距離以上離れた場所に、プライマリ・リソースと同じ容量を持つストレージ・リソースを作成し、設置する（ステップ1008）。
【００５３】
ステップ1002において、プライマリ・リソース以上の容量を持つストレージ・リソースが見つかった場合、見つかったストレージ・リソースのうち、安全距離以上離れた箇所にあるストレージ・リソースが存在するか、ストレージ・リソース情報テーブル600から検索する（ステップ1003）。上記ストレージ・リソースが見つからない場合、プライマリ・ストレージと同容量のストレージ・リソースが見つからなかった場合と同様に、新しいストレージ・リソースを作成し、プライマリ・リソースから安全距離以上離れた位置に設置する（ステップ1008）。
【００５４】
そして次に、ステップ1004において、安全距離以上離れた箇所にストレージ・リソースが存在する場合、もしくは、ステップ1008において、新たにストレージ・リソースを作成した場合、顧客サーバ304からのPingプログラムのパケット応答時間とストレージのディスク・アクセス時間の合算が一番早いストレージ・リソースをバックアップ・リソースとして選択する（ステップ1005）。選択したバックアップ・リソースを、バックアップ設定部504において、バックアップ用ストレージとして設定する（ステップ1006）。そして、プライマリ・リソース内データを、定刻（例えば毎日午前0時）にバックアップ・リソース内にコピーする設定を行う（ステップ1007）。
【００５５】
図１１は、ストレージ・リソースに障害が発生した際の、ストレージ管理プログラム502の動作フローである。ストレージ管理プログラム502は、図７に示した一連のストレージ・リソース割り当て処理終了後も、図７に示すネットワーク構成検索とリソース状態情報取得のステップ701を定期的に全ストレージ・リソースに対して行う（ステップ1100）。その際、ネットワーク構成検索やリソース状態情報取得要求に対して、返答の無いストレージ・リソースが存在するかチェックし（ステップ1101）、なければ、すなわち全ストレージ・リソースから返答があれば、ステップ1100を繰り返し実行する。
【００５６】
ステップ1101において、何らかの障害により、返答のないストレージ・リソースがあった場合、それがプライマリ・リソースであるか判断する（ステップ1102）。ステップ1102による判断がプライマリ・リソースでなければ、さらにいずれかのプライマリ・リソースのバックアップ・リソースでないか判断し、バックアップ・リソースであれば図１０に示したバックアップ・リソース選択およびバックアップ設定の動作フローを実行する（ステップ1111）。
【００５７】
ステップ1102において、返答の無いストレージ・リソースがプライマリ・リソースであった場合、プライマリ・リソースのバックアップ・リソースからの返答があるか確認する（ステップ1103）。バックアップ・リソースから返答がなければ（ステップ1103）、クライアントに対して、ストレージ・リソースがダウンしている通知（1109）を送信する（ステップ1110）。プライマリ・リソースからの返答がなくても、バックアップ・リソースからの返答がある場合（ステップ1103）、プライマリ・リソースを使用する顧客に対して、コンソール300を通じて、ストレージ装置がダウンしたことと、ストレージ・リソースをリカバリすることの通知（1104）を送信する（ステップ1105）。
【００５８】
次に、プライマリ・リソースにおいて、顧客サーバ304が使用していたデータを、再び使用可能とするために、バックアップ・リソースを顧客サーバ304に割り当てる（ステップ1106）。割り当て後、リカバリ通知(1107)を、クライアント要求受信プログラム（WWWサーバ）500を使用して、顧客の使用するコンソール300に送信する（ステップ1108）。
【００５９】
以上、本発明の第一の実施形態について説明した。
【００６０】
上記第一の実施形態では、顧客のストレ−ジ・リソースに対する要求に対して、ストレージ・リソースのリソース状態情報のみでなく、ネットワーク的な距離を選択条件に加えてストレージ・リソース選択している。これにより、ストレージ・リソース自体の性能が悪くても、トータルとして顧客サーバからのアクセス性能が良いストレージ・リソースが選択可能になった。また、今まで物理的な距離が遠いために選択候補に入らなかったストレージ・リソースが、ネットワーク的な距離が近いことで新たに選択候補に入れることができた。よって、広域に散在するストレージ・リソースの中から、顧客に最適なストレージ・リソースを提供するストレージ・リソース運用管理を実現した。
【００６１】
また、使用中のストレージ・リソースに対して、災害波及範囲として安全範囲を設定し、安全距離以上遠くにあるストレージ・リソースにバックアップを作成できた。よって、地震等の災害に対して、耐災害性能の高いストレージ・リソース運用管理を実現した。
【００６２】
以下に、上記第一の実施形態の変形例について、説明する。
（１）上記第一の実施形態では、顧客からのストレージ・リソース選択条件が、ストレージ・リソースまでのネットワークが、最もホップ数の少ないことであった。また、バックアップ・リソースの選択条件が、安全距離以上遠くであることであった。しかし、本発明は、要求の内容、および、範囲を限定するものではない。要求の範囲が、データ・アクセスに要する時間が1秒以内であることや、ストレージ・リソースとノード間のホップ数は３段以下であること、スループットが50Mbps以上であること、1キロ以内に設置してあること等であっても構わない。
（２）上記第一の実施形態では、バックアップ・リソースとして安全距離外に合致するストレージ・リソースが発見されない場合、新たに選択条件に合致するストレージ・リソースを作成している（ステップ1008）。しかしながら、新たにストレージ・リソースを作成せず、ＳＳＰ内に存在しているストレージ・リソースの中から、安全距離より近いが、最も安全距離に近い距離離れた箇所に設置されたストレージ・リソースを選択する方法であっても良い。
（３）上記第一の実施形態では、顧客がストレージ・リソースを使用する際、ＳＳＰ302内に顧客サーバ304を設置し、顧客サーバ304経由で使用する形態であった。しかしながら、顧客社内に顧客サーバを設置したまま、ＳＳＰ内のＳＡＮと直接接続してストレージ・リソースを使用する形態であっても構わない。
（４）上記第一の実施形態では、管理サーバ303上に、クライアント要求受信プログラム500、ストレージ管理プログラム502が起動し、データベース501が構築されている。しかしながら、顧客サーバ402上にクライアント要求受信プログラム500と、ストレージ・管理プログラム502が稼働し、データベース501が構築されるといった、顧客サーバ402が管理サーバ403を兼ねる構成でも構わない。
（５）上記第一の実施形態では、顧客サーバ304上のネットワーク的距離取得プログラム401がストレージに対してPingプログラムを実施し、顧客サーバとストレージ・リソース間のパケット応答時間とホップ数を測定している。しかしながら、ネットワーク的距離取得プログラムが、ストレージ・リソースのみでなく、顧客のコンソール300に対してPingプログラムを実行し、コンソール300とストレージ・リソース間のパケット応答時間を測定しても良い。ネットワーク的な距離や、物理的な距離は、ノードとストレージ・リソース間やストレージ・リソース間の間に複数のノードやネットワークが介在しても構わない。上記の場合、ネットワーク的な距離は、コンソールから顧客サーバを経て、ストレージ・リソースまでのトータルのネットワーク的な距離を表すことになる。
（６）上記第一の実施形態では、ネットワーク的な距離を取得する際、Pingプログラムを使用している。しかしながら、本発明はネットワーク的な距離を取得する方法を限定するものではない。ストレージ・リソースへ、実際のデータ書き込みやデータ読み込みを行って、データ・アクセスに要する時間を取得する方法や、ストレージ・リソースまでのホップ数や、途中経路に存在するスイッチ等のスループットを使用する方法でも構わない。
（７）上記第一の実施形態では、ストレージ・リソース間の物理的な距離を取得する際、管理サーバ403上に稼動するストレージ管理プログラム502のＧＵＩ部508からＳＳＰ302の管理者が手入力により、各ストレージの緯度および経度を入力している。しかしながら、物理的な位置関係を表すための情報（物理的な距離）は、緯度や経度、高度を使用せず、住所指定や、共通に持つ地図上のポイントを選択するといった方法でも構わない。また、物理的な距離取得に緯度と経度と高度を使用した場合であっても、各ストレージ・リソースにＧＰＳ（Global Positioning System）受信機を付加し、衛星からストレージ・リソースの緯度や経度や高度を取得する方法であっても構わない。この場合、管理サーバ303は、全ストレージ・リソースからそれぞれの緯度、経度、高度を取得する必要がある。
（８）上記第一の実施形態では、顧客の新規ストレージ・リソース割り当て要求に対して、管理サーバ303が、顧客の要求を満たす最適なストレージ・リソースを選択し、顧客サーバ304に割り当てている。しかしながら、本発明は、ストレージ・リソースの選択や割り当て方法にのみ使用を限定するものではない。既に顧客サーバに対してストレージ・リソースが決定している状態でネットワーク構成が変更した場合において、変更後にも顧客サーバのストレージ・リソースに対する要求を満たすか判断する方法に使用しても良い。
【００６３】
図１２は、上記（８）のように要求の範囲を満たしているか判断する方法に修正し、上記（３）のように形態を修正した、本発明の第二の実施形態におけるネットワーク構成図である。
【００６４】
図１２は、顧客サーバ1200とＳＳＰ（Ａ）1201と、ＳＳＰ（Ｂ）1202とから構成する。ＳＳＰ（Ａ）1201と、ＳＳＰ（Ｂ）1202は、共に１つのＳＳＰの中の（Ａ）支店と（Ｂ）支店を表す。ＳＳＰ（Ａ）1201とＳＳＰ（Ｂ）1202は、インターネット1203上にＶＰＮを作成して接続し、設置地域が異なっているが、両方のＳＡＮ（1205、1206）の管理は、ＳＳＰ（Ｂ）1202の管理サーバ1204が、一括して行っている。ＳＳＰ（Ｂ）1202は、ＳＳＰ全体のストレージ管理を行う管理サーバ1204と、ＳＡＮ1205、ストレージ1206から構成する。ＳＳＰ（Ａ）1201は、ＳＡＮ1207とストレージ1208から構成し、ＳＡＮ1207に直接顧客サーバ1200を接続している。
【００６５】
顧客サーバ1200は、顧客が自社内に設置し、自社内からＳＳＰ（Ｂ）1202のストレージ・リソースにアクセスするためのノードである。コンソールも兼ねる。矢印1209は、クライアント1200とストレージ装置1206内のストレージ・リソース1207とのネットワーク的な距離を示す。管理サーバ1204は、上記第一の実施形態の図４に示すクライアント要求受信プログラム500と、ストレージ管理プログラム502が稼動し、データベース501を保有している。ストレージ管理プログラム502内には、図５で示した処理部に加えて、移動必要／不必要判定部を持つ。
【００６６】
顧客サーバ1200では、図６に示したデータ・アクセス時間取得プログラム600が稼動している。
【００６７】
顧客サーバ1200は、上記第一の実施形態において図７に示した、ストレージ・リソース割り当ての動作フローに従い、ストレージ1208内のリソースを割り当てられて使用している。
【００６８】
本実施形態では、ネットワーク的な距離情報を、顧客サーバ1200とストレージ・リソース間のホップ数（ルータの段数）で計測する。そして、顧客の要求の範囲を、ネットワーク的な距離に対して、ホップ数２段以内とする。
【００６９】
図１３は、上記図１２のネットワーク構成において、顧客が引越しをして、顧客サーバ1200が顧客サーバ1300へと移動した場合のネットワーク構成である。顧客サーバ1300は、図１２上の顧客サーバ1200が移動した後の状態を示す。ＳＳＰ（Ａ）1201とＳＳＰ（Ｂ）1202は、図１２に示すＳＳＰ（Ａ）1201、ＳＳＰ（Ｂ）1202と同じである。顧客サーバ1300は、引越しをして、新たにＳＳＰ（Ｂ）1202内のＳＡＮ1205に直接接続する。矢印1301は、顧客サーバ1300とストレージ装置1208内のストレージ・リソースとのネットワーク的な距離（ホップ数）を示す。矢印1302は、顧客サーバ1300とストレージ装置1206とのネットワーク的な距離（ホップ数）を示す。
【００７０】
図１４は、ストレージ管理プログラム502における、顧客サーバ移動時のストレージ・リソース移動必要／不必要判定の動作フローである。
ストレージ管理プログラム502では、コンソールを兼ねている顧客サーバ1300 から移動の通知を受信した場合、移動後の顧客サーバ1300から、全ストレージ・リソースまでのホップ数を取得する（ステップ1400）。次に、移動前の顧客サーバ1200がストレージ管理プログラムに対して設定し、データベースに格納している要求の範囲、すなわち、ストレージ・リソース選択条件（ホップ数２段以内）を取得する（ステップ1401）。次に移動後の顧客サーバ1300と、移動前に使用していたストレージ・リソース1208間のホップ数（1302）を比較する。
【００７１】
移動後も、ホップ数が２段以内であれば(ステップ1402)、顧客のストレージ・リソースに対する要求性能を満たしているため、ストレージ・リソース内データの移動が必要ないと判断し、移動後の顧客サーバ1300に通知する（ステップ1403）。ステップ1402において、ホップ数が選択条件の範囲にでなかった場合、顧客サーバ1200が使用していたストレージ装置1208以外のストレージ・リソースの中から、一番ホップ数の少ないストレージ装置を選択する（ステップ1404）。そして、移動後の顧客サーバ1300にストレージ・リソース内データを移動することを通知し（ステップ1405）、ストレージ・リソース内データを、実際に移動する（ステップ1406）。
【００７２】
以上、本発明の第二の実施形態について説明した。
【００７３】
上記第二の実施形態では、顧客サーバの物理的な位置が移動した際に、顧客サーバとストレージ・リソース間のホップ数が、顧客の要求の範囲（ホップ数２段以内）であれば、ストレージ・リソース内のデータ移動は必要ないと判断している。よって、ストレージ・リソース運用管理において、移動のための作業コストの削減を実現した。
【００７４】
【発明の効果】
以上説明したように、本発明によれば、広域に散在するストレージ・リソース群から、ストレージ・リソースを選択し、ストレージ・リソースを使用するノードに割り当てる際、空き容量や使用率といったストレージ内 のリソース状態情報に、ネットワーク的な距離、すなわち、データ・アクセス性能に関わる情報、と物理的な距離を加えて選択することが可能である。よって、リソース状態情報が他のストレージ・リソースに劣るストレージ・リソースであっても、ネットワークを介してのデータ・アクセス性能が優るため、結果としてストレージ・リソースを使用するノードにとって一番アクセス性能の良いストレージ・リソースを選択することができる。よって、ストレージ・リソースに対する要求の範囲に合致し、要求に対して最適なストレージ・リソースを選択し提供する、ストレージ・ネットワーク運用を実現することができる。
【００７５】
また、顧客のサーバが使用するストレージ・リソースに対して、地震等の災害が波及しないと考えら得る距離、すなわち、安全距離を設定し、設定した安全距離以上離れた場所に設置されているストレージ・リソースを選択し、バックアップ用に設定することができる。この状態において、プライマリ・ストレージ・リソースが地震や水害など局所的な災害に見舞われた場合、災害に見舞われなかったバックアップ用のストレージ・リソースを顧客のサーバに割り当てて、データを保全することが可能である。よって、ディザスタ・リカバリ可能なストレージ・ネットワーク管理方法を実現することができる。
【００７６】
さらに、ストレージ・リソースまでのネットワーク的な距離を取得し、要求の範囲を取得することができる。よって、ストレージ・リソースを使用する顧客のサーバの物理的な設置位置が移動し、ストレージ・リソースとサーバ間の距離が大きくなった場合においても、ネットワーク的な距離の変化を測定することができる。よって、サーバの物理的な設置位置が移動後に、ストレージ・リソースまでのネットワーク的な距離が、要求の範囲にあるか否か判断することができる。そして、ネットワーク的な距離が変化しないならば、ストレージ・リソースの移動は必要ないと判断することができる。よって、ストレージ・ネットワーク運用管理コストから、不必要な移動にかかる作業コストを削減することができる。
【図面の簡単な説明】
【図１】従来のＳＳＰ102の運用形態を示すネットワーク構成図である。
【図２】ストレージ管理プログラムにおける、ストレージ・リソース割り当ての動作フロー図である。
【図３】本発明の第一の実施形態が適用されたＳＳＰ302の運用形態を示すネットワーク構成図である。
【図４】コンソール300と顧客サーバ304の概略を示す図である。
【図５】管理サーバ303の概略を示す図である。
【図６】管理サーバ303に作成したデータベース501内のストレージ・リソース情報テーブルを示す図である。
【図７】ストレージ管理プログラム502による、ストレージ・リソース割り当て時の動作を説明するフロー図である。
【図８】ネットワーク距離取得プログラム402のネットワーク距離取得の動作を説明するためのフロー図である。
【図９】ストレージ管理プログラム502のストレージ・リソース選択動作を説明するためのフロー図である。
【図１０】ストレージ管理プログラム502のバックアップ・リソース選択動作およびバックアップ設定動作を説明するためのフロー図である。
【図１１】ストレージ管理プログラム502による、障害発生時の動作を説明するためのフロー図である。
【図１２】本発明の第二の実施形態が適用されたＳＳＰ（Ａ、Ｂ）と、顧客サーバ1300との関係を示すネットワーク構成図である。
【図１３】本発明の第二の実施携帯が適用された図１２のネットワーク構成から、顧客サーバが移動した際の、ネットワーク構成図である。
【図１４】ストレージ管理プログラム502のストレージ・リソース移動必要・不必要判定の動作を説明するフロー図である。
【符号の説明】
100 クライアント・コンソール
103、302、1201、1202 ＳＳＰ
104、303、1204 管理サーバ
105、308、309、1205、1207 ＳＡＮ
106、107、306、307、1206、1208 ストレージ
108、109、110、304、1200、1300 顧客サーバ
305 ルータ
500 クライアント要求受信プログラム（ＷＷＷサーバ）
501 データベース
502 ストレージ管理プログラム
503 ネットワーク構成検索・取得部
504 バックアップ設定部
505 ストレージ・リソース割り当て部
506 ノード位置情報取得部
507 ストレージ・リソース選択部
508 ＧＵＩ部
600 ストレージ・リソース情報テーブル
1201 ＳＳＰ（Ａ）
1202 ＳＳＰ（Ｂ）
【発明の属する技術分野】
本発明は、複数のストレージと複数のサーバを高速に繋いだストレージ・ネットワーク、すなわち、ＳＡＮ（Storage Area Network）や複数のＮＡＳ（Network Attached Storage）を保有して、ストレージ内の領域（ストレージ・リソース）を顧客に提供するＳＳＰ(Storage Service Provider)の運用管理技術に関し、特に、顧客の要求に合致した最適なストレージ・リソース選択技術、ディザスタ・リカバリ(disaster recovery)技術、及びコスト削減技術に関する。
【０００２】
【従来の技術】
従来、ストレージは、ディスク装置やテープ装置などのサーバの外部記憶装置という付属物として使用されていた。しかし、情報の重要性や蓄積量の拡大に伴い、複数のシステム間でのデータ交換や共有が必要となり、大容量ストレージを持つＮＡＳ(Network Attached Storage)や、ストレージ群とサーバ群を高速に接続する専用のネットワーク、ＳＡＮ（Storage Area Network）が普及してきた。ＳＡＮではサーバ群とストレージ群とによって、ストレージ統合を実現したことにより、システム運用の効率化を実現する。
【０００３】
企業内のストレージ管理者は、ＳＡＮのトポロジ管理や、ＮＡＳ機器とサーバ間の接続を運用管理するために、一般的に管理ツールを使用する。
【０００４】
管理ツールでは、ストレージやサーバに関する容量、空き容量、接続形態等の情報を収集し、ＳＡＮに接続されたサーバやストレージ、ネットワーク機器を画面上に表示する。画面上では、各機器に関連づけられたアイコンをクリックすることにより、各ストレージの容量やサーバへの割り当て状況などのより詳細な情報を表示できる。そして、管理情報の収集、表示のみでなく、サーバへの、ストレージやストレージ内の論理的な領域（以下、ストレージと、ストレージ内の論理的な領域を総称して、ストレージ・リソースと呼ぶ）割り当てや、削除、変更を行っている。また、上記ツールに、バックアップ設定・ツール等を組み合わせることにより、効率よく、システムの可用性を高めている。
【０００５】
しかし、企業内のストレージ運用管理者は、近年の予測不可能なストレージの増量に対するコスト増、多岐に渡る管理ツールの複雑化、設置スペースの省スペース化等の問題に直面している。これらの問題は、企業内情報リソースを、ストレージ運用管理を専門に行う企業へとアウトソーシングし、ストレージの運用管理を全て外部企業に委託することによって、解決可能である。ストレージを運用管理し、顧客へとストレージ・リソースを貸し出す企業として、ＳＳＰ（Storage Service Provider）がある(月刊コンピュートピア データストレージ・レポート２０００：P36-P37)。
【０００６】
図１はＳＳＰ103の運用形態を示すネットワーク構成図である。
【０００７】
企業内情報リソースをアウトソーシングしたい顧客は、ＳＳＰ103内に、自社のサーバである顧客サーバ108を設置し、自社内に設置する顧客コンソール100から自社の顧客サーバ108にアクセスする。ＳＳＰ103は、管理サーバ104、ストレージ装置(106、107)、ＳＡＮ105、顧客サーバ群（108、109、110）から構成し、管理サーバ104によって、ＳＡＮ105に接続している全てのノードを管理する。ＳＡＮ105は、ファイバーチャネルや、イーサネット等で構成する。顧客コンソール100と顧客の自社サーバである顧客サーバ108は、インターネット上でＶＰＮ（Virtual Private Network）を使用し（101）、ＮＦＳ(Network File System)か、ＣＩＦＳ（Common Internet File System）によって接続する。もしくは、専用線で接続する。顧客コンソール100と管理サーバ104は、インターネット102を経由して接続する。
【０００８】
ＳＳＰ103では、顧客から顧客コンソール100を通じてストレージの領域割り当ての要求があった場合、顧客コンソール100から、顧客のストレージに対する要求である、アクセス性能、信頼性、用途等を聞き、要求に合致するストレージ・リソースを選択する。ストレージ・リソース選択には、管理ツールを使用する。管理ツールは、ストレージ・リソースの稼働状況、使用状況、スループットといったストレージ・リソースの状態を表す値（以下、ストレージ・リソースの状態を示す値を、リソース状態情報と呼ぶ）を、ストレージから常に取得している。ＳＳＰ103では、上記リソース状態情報を選択因子として、リソース状態情報から、顧客100の要求に合致するストレージ・リソースを選択する。
【０００９】
次に、ＳＳＰ103は、選択したストレージ・リソースを顧客サーバ108に割り当てる。ストレージ・リソースを顧客サーバ108に割り当てるには、既存のＳＡＮトポロジ管理ツールや、ストレージ内のボリューム管理ツールを使用する。上記ストレージ・リソースの割り当てにより、顧客は性能要求を満たすストレージ・リソースを、顧客サーバ108において使用可能になる。また、顧客サーバ108内の情報を顧客コンソール100から閲覧、設定、変更可能となる。
【００１０】
図２は、顧客サーバ108へのストレージ・リソース割り当て処理のフロー図である。
【００１１】
ＳＳＰ103は、常にストレージの稼働率、負荷率、空き容量、ＲＡＩＤレベル、ＤＩＳＫ性能等といった、ストレージ内のリソース状態情報（200）を取得している（ステップ201）。この状態において、顧客コンソール100からストレージ領域の貸し出し要求と共に、ストレージ・リソースに対する容量と性能に関する要求(202)を受けた場合（ステップ203）、取得済みのリソース状態情報(200)を選択因子として、顧客の要求に合致するストレージ・リソースを選択する（ステップ204）。選択したストレージ・リソースを顧客サーバ108に割り当てる（ステップ205）。割り当てには、既存のＳＡＮトポロジ管理ツールや、ストレージ内ボリュームの割り当てツール等を使用する。ＳＳＰ103は、ストレージ・リソースが使用可能になったことを、管理サーバ104を通じて、顧客コンソール100に通知する(ステップ206)。
【００１２】
また、ＳＳＰ103では、顧客サーバ108が使用するストレージ・リソースに対して、障害発生時のリカバリ用にバックアップを取る。その際、バックアップしたデータが、障害によって同時に失われないようにするため、クライアントの使用しているストレージ装置とは異なるストレージ装置を確保し、ストレージ・リソース内のデータをコピーする。
【００１３】
上記従来技術では、ＳＳＰ103が、ＳＳＰ103内に顧客のサーバ（108、109、110）を保有し、ＳＡＮ105を使用させる形態を示した。しかし、ＳＳＰ103では、ＳＳＰ103内のＳＡＮ105から直接顧客社内へと、ネットワークを接続し、ストレージ・サービスを行う形態もある。この場合、図１に示した顧客サーバ108が、図１に示した顧客コンソールの場所に位置するネットワーク構成となる。
【００１４】
以上により、従来技術では、管理ツールもしくはストレージ管理者が、ストレージ・リソースのリソース状態情報をもとに、顧客の要求する容量や性能に合致するストレージ・リソースを選択し、顧客サーバへの割り当てを実現している。また、ストレージ・リソース内のバックアップを取ることによりＳＳＰの高可用性を維持している。
【００１５】
【発明が解決しようとする課題】
従来の技術では、管理ツールから得られる、各ストレージ内のリソース状態情報（ストレージ・リソースの稼働状況、容量、使用状況、スループット等）を選択因子として使用することにより、顧客の要求するストレージの容量とアクセス性能を満たすストレージ・リソースを選択し、割り当てた。
【００１６】
しかし、広域網を使用し、遠距離に散在するＳＡＮ上のリソースやＮＡＳを顧客に統合的に提供するようなＳＳＰでは、ＳＳＰ内において多数の複合的なネットワークを使用することになる。このようなネットワーク上では、ストレージ・リソースと顧客サーバ間のネットワーク・アクセス時間が、ストレージへのアクセス性能に影響する。よって、単純にストレージ・リソース内のアクセス性能を決定する要因であるリソース状態情報（稼働率、ディスク性能等）だけでは、顧客の要求するトータル的なアクセス性能を満たすことが困難となる。
【００１７】
さらに、広域化して遠距離に渡り散在するストレージを有効に活用し、地震などの災害対策用のバックアップを実施しようとした場合、現在の管理ツールでは、ストレージ装置の設置地域等の位置情報を取得していないため、指定した距離以上離れたストレージ装置を意図的に選択する手段がない。
【００１８】
また、ＳＳＰを利用する顧客が引越しした場合、引越し先からのストレージ・リソースへのネットワーク・アクセス時間を考慮することがないため、顧客サーバの引越し先近くのストレージへと、データを移動する場合がある。そのため、顧客の引越し毎にデータを移動するための作業コストを必要としている。
【００１９】
本発明の目的は、以下の３つである。
（１）顧客にストレージ・リソースを提供するストレージ管理システムにおいて、顧客の要求に対して、ストレージ・リソース性能だけでなく、顧客の使用するノードからストレージ・リソースまでのネットワーク・アクセス性能についても満たしているストレージ・リソースを選択する。そして、顧客の要求に合致する最適なストレージ・リソースを、顧客に提供可能なストレージ・リソース運用管理方法を提供することである（以下、ノードからストレージ・リソースまで、もしくは、ストレージ・リソース間、ノード間のネットワーク・アクセス性能に関わる、ホップ数（通信の途中で何段のルータを介するかを示す数）やパケット応答時間、ネットワークスループット等の情報を、ネットワーク的な距離と呼ぶ）。
（２）広域に散在するストレージ・リソースの中から、意図的に設定した距離以上離れた複数のストレージ・リソースを選択してバックアップし、地震などの地域的な災害発生時における耐災害性向上方法を提供することである。
（３）ストレージ・リソースにアクセスするノードとストレージ・リソース間の地理的な距離が変化した場合に、変化後のノードからストレージ・リソースまでのネットワーク的な距離が、顧客のアクセス性能に対する要求を満たしていれば、ストレージ・リソースの移動や、ストレージ・リソース内データの移動を行わないといった、移動に関わる作業コストの削減方法を提供することである。
【００２０】
【課題を解決するための手段】
上記３つの目的を達成するために、本発明では、ストレージ・リソースを利用するノードからストレージ・リソースまでのネットワーク・アクセス性能に関わる情報（以下、ネットワーク・アクセス性能に関わる情報をネットワーク的な距離と呼ぶ）と、上記ノードとストレージ・リソース間、各ストレージ・リソース間の物理的な位置関係に関わる情報（以下、物理的な位置関係に関わる情報を、物理的な距離と呼ぶ）を使用することによって、ストレージ・リソースを運用管理する方法を提供する。また、本方法を使用した耐災害性向上方法、および、作業コスト削減方法を提供する。
【００２１】
具体的には、以下の（１）から（７）の方法を提供する。
（１）ストレージ・リソース運用管理方法
ネットワークを介してストレージへアクセス要求を送信するノードと、アクセス要求を受信して実行する複数のストレージ群からネットワークを構成する。本構成において、前記ノードとストレージ群内のストレージ・リソース間もしくはストレージ・リソース群内の各ストレージ・リソース間のネットワーク的な距離と、ノードとストレージ・リソース間もしくはストレージ・リソース群内のストレージ・リソース間の物理的な距離との、両方または一方を取得する。さらに取得した距離に対する要求を取得し、要求の範囲を、ストレージ・リソースを選択する際の選択因子とする。
【００２２】
本方法により、広域に散在するストレージ・ネットワークから、ストレージ・リソース自体の性能のみでなく、ストレージにアクセスするノードからストレージ・リソースまでのネットワーク的な距離や、ストレージ間の物理的な距離などを加味して選択することができる。よって、ストレージを利用する顧客にとって、最適なストレージ・リソースを提供可能な、ストレージ・リソース運用管理方法を提供することができる。
（２）最適ストレージ・リソース選択方法
上記（１）の方法において、ネットワーク的な距離と物理的な距離のどちらか一方、もしくは両方を取得する。さらに、取得した距離に対する要求を取得し、要求の範囲をストレージ・リソースの選択条件とする。そして、ネットワーク的な距離が要求の範囲内であるストレージ・リソースを、もしくは、物理的な距離が要求の範囲内であるストレージ・リソースを、もしくはその両方に合致するストレージ・リソースを選択する。
（３）最適ストレージ・リソース選択方法
上記（２）に示した方法によって、上記（２）で示した要求の範囲内に設置されているストレージ・リソースが複数存在した場合、要求の範囲内にあるストレージ・リソースの中で、最もネットワーク的な距離が近いか、最も物理的な距離が近いか、最も物理的な距離が遠いかの、いずれかの組み合わせ、もしくは、１個の条件を使用して、さらに最適なストレージ・リソースを選択する。
（４）最適ストレージ・リソース選択方法
上記（２）に示した方法によって、上記（２）で示した要求の範囲内に設置されているストレージ・リソースが見つからなかった場合、全ストレージ・リソース中で、上記（２）のネットワーク的な距離が最も近いか、上記（２）の物理的な距離が最も近いか、上記（２）の物理的な距離が最も遠いかの、いずれかの組み合わせ、もしくは、１個の条件を使用して、ストレージ・リソースを選択する。
（５）最適ストレージ・リソース作成方法
上記（２）に示した方法によって、上記（２）で示した要求の範囲内に設置されているストレージ・リソースが見つからなかった場合、上記（２）で示したネットワーク的な距離が要求の範囲内にあるか、もしくは、上記（２）で示した物理的な距離が要求の範囲内にあるか、もしくは両方を満たすストレージ・リソースを新たに追加する。
【００２３】
上記（２）から（５）の方法により、（１）と同様に、ストレージ・リソースに対する要求を示すノードにとって、最適なストレージ・リソースを提供可能な、ストレージ・リソース運用管理方法を提供することができる。
（６）耐災害性向上方法
上記（１）に示したネットワークに存在するストレージ・リソースに対して、上記（２）で示した方法によって、物理的な距離に対する要求の範囲を取得する（以下前記ストレージ・リソースをプライマリ・リソースと呼ぶ）。設定した要求の範囲内に設置された、プライマリ・リソースとは異なるストレージ・リソースを選択し（以下、セカンダリ・リソースと呼ぶ）、プライマリ・リソース内に格納されているデータの一部もしくは全部を複製し、セカンダリ・リソースに格納する。そして、プライマリ・リソースが何らかの障害により使用できない場合に、アクセス要求を送信するノードからのプライマリ・リソースに対するアクセス要求を、セカンダリ・リソースにおいて実行する。
【００２４】
本方法により、意図的に遠く離れた位置にストレージ・リソース内のデータをバックアップすることが可能である。よって、局所的に発生する災害等に対して、ストレージ・リソース内のデータを保全でき、ディザスタ・リカバリ(disaster recovery)することができる。
（７）コスト削減方法
上記（１）に示したネットワークに存在するノードとストレージ・リソースに対して、上記（２）で示した方法によって、ネットワーク的な距離に対する要求を取得する。前記ノードの物理的な位置が移動した場合、移動後にもノードからストレージ・リソースまでのネットワーク的な距離が、取得した要求の範囲内であるか判断する。ネットワーク的な距離が要求の範囲内であれば、ストレージ・リソース内データの格納位置の移動を行わない。
【００２５】
本方法により、ストレージを使用する顧客のサーバが引越し等によって移動した場合において、移動後のサーバからストレージ・リソースまでのネットワーク・アクセス性能が、移動前と変化するか調べることができる。そして、アクセス性能が、顧客の要求する性能の範囲内であれば、データの移動を行う必要がないと判断することができる。よって、ストレージ・リソース運用管理において、移動にかかるコストを削減することができる。
【００２６】
【発明の実施の形態】
以下に、本発明の第一の実施形態について説明する。
【００２７】
図３は、本発明の第一の実施形態が適用されたＳＳＰ302の運用形態を示すネットワーク構成図である。
【００２８】
コンソール300は、企業内情報リソースをアウトソーシングしたい顧客のコンソール・ノードを示す。顧客は、自社のサーバである顧客サーバ304をＳＳＰ302内に設置し、コンソール300から顧客サーバ304内のアプリケーションの設定や、変更、情報取得を行う。顧客社内に設置されたコンソール300と、ＳＳＰ302内に接続された顧客サーバ304は、インターネット301を介してＶＰＮ接続したネットワーク上でＮＦＳによってアクセスする。
ＳＳＰ302は、管理サーバ303、顧客サーバ304とストレージ装置（306、307）、ルータ305とから構成する。管理サーバ303、顧客サーバ304、ストレージ装置306、ルータ305間はEthernet308でＬＡＮ接続する。また、ストレージ装置307、ルータ305間はEthernet309でＬＡＮ接続する。ＬＡＮ308とＬＡＮ309間は、ルータ305によって、ルーティングする。図３の構成では、ストレージ装置(306、307)および管理サーバ303、顧客サーバ304間の接続にEthernetとルータを用いているが、本方法はこの構成に限定するものではない。ストレージ装置と顧客サーバ間をファイバーチャネル等によって接続し、ファイバーチャネル間をファイバーチャネル・スイッチ等で接続しても構わない。また、コンソール、顧客サーバ、管理サーバ、ルータ、ストレージ装置の全てにおいて、台数、ルータ段数を限定しない。また、コンソール300とＳＳＰ302内のノードとの接続形態は、インターネットのみに限定せず、専用線やＡＴＭなどであっても構わない。
【００２９】
上記ネットワーク構成において、顧客がコンソール300を使用してＳＳＰ302の管理サーバ303にストレージ装置内の論理的な領域の割り当て要求を出すと、管理サーバ303は領域に対する顧客の要求に合致する論理的な領域を選択し、顧客サーバ304に割り当てる。本実施の形態では、上記ストレージ装置、上記ストレージ装置内の物理的な単位領域、装置内の論理的な単位領域、複数のストレージ装置にまたがって作成された論理的な単位領域を総称して、ストレージ・リソースと呼ぶ。管理サーバ303では、ストレージ・リソースの割り当て後、顧客サーバ304のアドレスをコンソール300に通知し、コンソール300から顧客サーバ304へのアクセスと、顧客サーバからストレージ・リソースへのアクセスを可能とする。
【００３０】
以下、コンソール300、顧客サーバ304、管理サーバ303について、図４、図５、図６を用いて、順に説明する。
【００３１】
図４は、コンソール300と顧客サーバ304の構成図である。コンソール300は、要求送信プログラム（Webブラウザ）400 が起動し、インターネット上のWWWサーバにアクセスする。また、コンソール300は、ＮＦＳを使用して顧客サーバ304にアクセス可能である。要求送信プログラム（Webブラウザ）400では、管理サーバ303上のクライアント位置情報入力ページと、ストレージ・リソース選択条件入力ページにアクセスし、それぞれ入力設定を行う。また、ストレージ状態表示ページにアクセスし、顧客サーバ304に割り当てられたストレージ・リソースの容量、使用率、スループット等のリソース状態情報を閲覧可能である。また、パケットの応答時間や、経由するルータの段数を示すホップ数といったネットワーク的な距離や、設置場所の緯度と経度によって表すことが可能な物理的な位置関係に関する情報を閲覧することができる。
【００３２】
顧客サーバ304では、ネットワーク的距離取得プログラム401が稼動し、定期的に全ストレージ装置に対して、ネットワーク診断プログラムであるPingプログラムを実行し、返答パケットからストレージ・リソースへのパケット応答時間を測定する。その際、顧客サーバ304 とストレージ間のホップ数を取得し、両値をネットワーク的な距離として管理サーバに通知する。
【００３３】
図５は、管理サーバ303の概略図である。管理サーバ303は、クライアント要求受信プログラム（WWWサーバ）500、データ・ベース501、ストレージ管理プログラム502とから構成する。
【００３４】
クライアント要求受信プログラム500はWWWサーバであり、クライアント位置情報入力ページと、ストレージ・リソース選択条件入力ページ、および、ストレージ状態表示ページをWebブラウザに送信する。クライアント要求受信プログラム500では、コンソール300からのWebページ入力によって、ストレージ・リソース選択条件とクライアント位置情報（緯度、経度）を取得する。
【００３５】
ストレージ管理プログラム502は、ネットワーク構成検索・取得部503、バックアップ設定部504、ストレージ・リソース割り当て部505、ノード位置情報取得部506、ストレージ・リソース選択部507、ＧＵＩ部508とから構成する。バックアップ設定部504と、ストレージ・リソース割り当て部505は既存技術で動作する。
【００３６】
ネットワーク構成検索・取得部503では、ＳＳＰ302内のストレージ・ネットワーク（308、309）に接続されている機器の情報を収集し、データベース501に格納する。さらに、顧客サーバ304上のネットワーク的距離取得プログラム401によって取得した情報もデータベース501に格納する。ノード位置情報取得部506では、検出したストレージのそれぞれの設置位置（緯度、経度）を、GUI部508経由で取得し、物理的な距離を算出する。算出した距離は、データベース501に格納する。ストレージ・リソース選択部507では、ストレージ・リソースに対する顧客の要求性能や要求容量に合致するストレージ・リソースをデータベース中から検索して選択する。ＧＵＩ部508では、ネットワーク構成検索・取得部503で取得したストレージ・サーバや顧客サーバを画面上に表示し、ＳＳＰ302の管理者から手入力で、各ノードの設置位置、緯度および経度を入力する。
【００３７】
図６は、データベース501内のストレージ・リソースに関するストレージ・リソース情報テーブル600を示す図である。ストレージ・リソース情報テーブル600は、ストレージ名とＬＵＮ601、平均稼働率（％）602、容量（ＧＢ）603、ディスク性能を表す回転数(ｒｐｍ)604、ディスク内のアクセス時間(ｍｓｅｃ)605、顧客サーバからのパケット応答時間（ｍｓｅｃ）606、ストレージ装置の設置場所（北緯・東経・地名）607、顧客サーバからの物理的距離（ｋｍ）608、顧客サーバとストレージ装置間のホップ数（段）609を格納する。ストレージ・リソース情報テーブルは、顧客サーバ毎に１テーブル作成する。情報テーブル600は、ストレージ・リソースを選択する際の選択因子として使用する。
【００３８】
以下、図７、図９、図１０を用いて、図４で示した管理サーバ303内のストレージ管理プログラム502のストレージ・リソース割り当て動作フローを説明する。図８を用いて、顧客サーバからストレージ・リソースまでのネットワーク的な距離の取得動作フローを説明する。図１１では、ストレージ・リソースに障害が発生した際の、ストレージ管理プログラム502の動作フローを説明する。
【００３９】
図７は、ストレージ管理プログラム502のストレージ・リソース割り当て動作フローである。ストレージ管理プログラム502は、ネットワーク構成検索・取得部503を使用して、ＳＳＰ302のストレージ・ネットワーク内について、ネットワーク・トポロジ（700）を検索し、ネットワーク構成に関する情報をデータベース501に格納する。また、見つかったストレージ・リソースに対して、稼働率、容量、ディスク回転数、ディスク内アクセス時間等のリソース状態情報（700）を取得し、データベース501内の情報テーブル600内に格納する（ステップ701）。
【００４０】
次に、ノード位置情報取得部506において、ストレージ・リソースの物理的な設置場所を示す緯度、経度（物理的な距離）を取得する。緯度、経度は、GUI部508を用いてＳＳＰ302の管理者が入力する。取得した緯度と経度から、全ストレージ・リソース間の物理的な距離を算出し、ストレージ・リソース情報テーブル600に格納する。さらに、顧客サーバ304とストレージ・リソースまでのパケット応答時間とホップ数（ネットワーク的な距離）（702）を、顧客サーバ304上で稼動するネットワーク的距離取得プログラム401から取得して、ストレージ・リソース情報テーブル600へ格納する（ステップ703）。
【００４１】
そして、ステップ703を一定間隔毎に繰り返し行う。顧客サーバ304でのネットワーク的距離取得の動作フローは、図８を用いて後述する。上記状態において、クライアント要求受信プログラム500を通じて、顧客からのストレージ・リソース割り当ての要求通知（704）と共に、顧客サーバ304からストレージ・リソースまでのネットワーク的な距離（パケット応答時間、ホップ数、ネットワーク・スループット等）に対する要求と要求ストレージ容量（705）を受信する（ステップ706）。
【００４２】
本実施の形態では、上記データ・アクセス性能に関する情報をネットワーク的な距離と呼ぶ。ネットワーク距離が近いということは、パケット応答時間が早く、ホップ数が少なく、ネットワーク・スループットが高いといった、データ・アクセスに要する時間が短い状態を示す。本第一の実施形態での、要求の範囲 (705)は、ホップ数が最も小さいこととする。ストレージ・リソース選択部507によって、要求の範囲と要求容量（705）に合致するストレージ・リソースを、データベース501に格納済みのリソース状態情報と、ネットワーク的な距離および物理的な距離情報とから検索して選択する（ステップ707）。本実施の形態では、地理的な位置関係から得られる実際の距離を物理的な距離と呼ぶ。さらに、ステップ707で選択したストレージ・リソースをプライマリ・リソースと呼ぶ。ステップ707における選択フローは、図９を用いて詳細を後述する。
【００４３】
次に、プライマリ・リソースを、従来方式同様に、ストレージ・リソース割り当て部505を用いて、顧客サーバ304に割り当てる（ステップ708）。管理サーバ303は、ストレージ・リソースのディザスタ・リカバリ用にストレージ・リソースを選択し、バックアップ設定部504によって、プライマリ・リソースのバックアップとして設定する（ステップ709）。以下、バックアップ用のストレージ・リソースを、バックアップ・リソースと呼ぶ。バックアップ・リソースを選択するステップについては、図１０を用いて後述する。バックアップの設定後、ストレージ・リソース割り当てが終了した通知（710）を、クライアント要求受信プログラム500を通じてコンソール300に対して送信する（ステップ711）。
【００４４】
図８は、顧客サーバ304上で稼働するネットワーク的距離取得プログラム401の、ネットワーク的距離情報取得の動作フローである。ネットワーク的距離取得プログラム401は、図７のステップ703におけるネットワーク的な距離の取得の際に、パケット応答時間とホップ数を取得し、ストレージ管理プログラム502に提供する。
【００４５】
顧客サーバ304上のネットワーク距離取得プログラム402では、顧客サーバから各ストレージ・リソースに対してPingプログラムを実行し、パケット応答時間とセグメントを渡る回数であるホップ数を取得する。Pingプログラムは本来ネットワーク診断プログラムであり、一定値のバイトのデータを指定ノードに対して複数回送信し、送信先のノードから返信があるかどうかでネットワークを診断する。
【００４６】
ネットワーク上のパケットが送信されつづけることを避けるために、ネットワーク上のパケットに有効期限を表すTTL（Time To Live）がある。TTLは送信時に設定し、パケットがルータを通過する毎に１減算され、0になるとパケットが破棄されるしくみである。これを使用して、TTL値を0から順に増加しながら目的ノードに対してPingプログラムを実行することにより、返答が初めて得られた際のTTL値が、目的ノードまでのルータ段数、すなわちホップ数を示す。またPingプログラムでは、複数回のデータ送信により、各パケットのパケット応答時間の平均も取得することができる。最初に、ストレージ・リソースのTTL値を0にしてPingプログラムを実行する（ステップ800）。
【００４７】
Pingプログラムによる応答が得られるか検証し（ステップ801）、応答が得られなければTTL値を１増加させて、再びPingプログラムを実行する（ステップ802）。これを全ストレージ・リソースに対して実行する。Pingプログラムにより応答が得られれば、TTL値から顧客サーバとストレージ・リソース間のホップ数を取得する（ステップ803）。同時にパケット応答時間を取得し（ステップ804）、ホップ数と共に管理サーバ303に通知する（ステップ805）。
【００４８】
図９は、図７内のプライマリ・リソース選択ステップ707の動作フローである。本実施形態では、コンソール300の要求が、ホップ数が一番小さいストレージ・リソースを選択することである（図７中ステップ705）。そのため、まず、データベース501内を検索し、ホップ数０段、すなわち、顧客サーバ404と同セグメントにあるストレージ・リソースを検索する（ステップ900）。ストレージ・リソースが見つからない場合（ステップ901）、ホップ数を一段増加し（ステップ904）、増加したホップ数以上遠くにストレージ・リソースがあるかどうか判断する（ステップ905）。
【００４９】
ストレージ・リソースが、指定したホップ数経由した先のセグメントか、それ以上先に存在する場合（ステップ905）、再び、ステップ901において、指定段数先のセグメントにストレージ・リソースがあるか検索する。ステップ901において、指定セグメント内にストレージ・リソースが存在する場合には、選択しているホップ数のセグメントにクライアント400の要求する容量以上の容量を持つストレージ・リソースが存在するか検索する（ステップ902）。ストレージ・リソースが見つからなければ、ホップ数を増加して再び検索する。（ステップ904）。ステップ902において、要求容量以上の容量を持つストレージ・リソースが見つかった場合、見つかったストレージ・リソース中、ディスク内平均アクセス時間と、Pingプログラムのパケット応答時間の合算が一番早いストレージ・リソースを、クライアント400用のストレージ・リソース、すなわち、プライマリ・リソースとして選択する（ステップ903）。
【００５０】
ステップ905において、目的容量以上持つストレージ・リソースがＳＳＰ302内で見つからなかった場合、顧客サーバからのホップ数0段のセグメント内に、顧客の要求容量以上のストレージ・リソースを作成する（ステップ906）。作成したストレージ・リソースを、プライマリ・リソースとして選択する（ステップ907）。
【００５１】
図１０は、図７内のバックアップ・リソース選択、および、定期バックアップ設定ステップ709の動作フローである。本動作フローでは、プライマリ・リソースが、地震などの災害により故障した際に、リソース内データをリカバリ可能にするための、バックアップの設定を行う。
【００５２】
本動作フローでは、まず、バックアップ・リソースとプライマリ・リソースを災害が波及しないと考えられるに十分な距離（以下、災害が波及しないと考えられるに十分な距離を安全距離と呼ぶ）を物理的な距離の要求の範囲として取得する（ステップ1000）。次に、プライマリ・リソース以外のストレージ・リソースから、プライマリ・リソース以上の容量を持つストレージ・リソースを検索する（ステップ1001）。上記ストレージ・リソースが存在しなければ（ステップ1002）、プライマリ・ストレージから安全距離以上離れた場所に、プライマリ・リソースと同じ容量を持つストレージ・リソースを作成し、設置する（ステップ1008）。
【００５３】
ステップ1002において、プライマリ・リソース以上の容量を持つストレージ・リソースが見つかった場合、見つかったストレージ・リソースのうち、安全距離以上離れた箇所にあるストレージ・リソースが存在するか、ストレージ・リソース情報テーブル600から検索する（ステップ1003）。上記ストレージ・リソースが見つからない場合、プライマリ・ストレージと同容量のストレージ・リソースが見つからなかった場合と同様に、新しいストレージ・リソースを作成し、プライマリ・リソースから安全距離以上離れた位置に設置する（ステップ1008）。
【００５４】
そして次に、ステップ1004において、安全距離以上離れた箇所にストレージ・リソースが存在する場合、もしくは、ステップ1008において、新たにストレージ・リソースを作成した場合、顧客サーバ304からのPingプログラムのパケット応答時間とストレージのディスク・アクセス時間の合算が一番早いストレージ・リソースをバックアップ・リソースとして選択する（ステップ1005）。選択したバックアップ・リソースを、バックアップ設定部504において、バックアップ用ストレージとして設定する（ステップ1006）。そして、プライマリ・リソース内データを、定刻（例えば毎日午前0時）にバックアップ・リソース内にコピーする設定を行う（ステップ1007）。
【００５５】
図１１は、ストレージ・リソースに障害が発生した際の、ストレージ管理プログラム502の動作フローである。ストレージ管理プログラム502は、図７に示した一連のストレージ・リソース割り当て処理終了後も、図７に示すネットワーク構成検索とリソース状態情報取得のステップ701を定期的に全ストレージ・リソースに対して行う（ステップ1100）。その際、ネットワーク構成検索やリソース状態情報取得要求に対して、返答の無いストレージ・リソースが存在するかチェックし（ステップ1101）、なければ、すなわち全ストレージ・リソースから返答があれば、ステップ1100を繰り返し実行する。
【００５６】
ステップ1101において、何らかの障害により、返答のないストレージ・リソースがあった場合、それがプライマリ・リソースであるか判断する（ステップ1102）。ステップ1102による判断がプライマリ・リソースでなければ、さらにいずれかのプライマリ・リソースのバックアップ・リソースでないか判断し、バックアップ・リソースであれば図１０に示したバックアップ・リソース選択およびバックアップ設定の動作フローを実行する（ステップ1111）。
【００５７】
ステップ1102において、返答の無いストレージ・リソースがプライマリ・リソースであった場合、プライマリ・リソースのバックアップ・リソースからの返答があるか確認する（ステップ1103）。バックアップ・リソースから返答がなければ（ステップ1103）、クライアントに対して、ストレージ・リソースがダウンしている通知（1109）を送信する（ステップ1110）。プライマリ・リソースからの返答がなくても、バックアップ・リソースからの返答がある場合（ステップ1103）、プライマリ・リソースを使用する顧客に対して、コンソール300を通じて、ストレージ装置がダウンしたことと、ストレージ・リソースをリカバリすることの通知（1104）を送信する（ステップ1105）。
【００５８】
次に、プライマリ・リソースにおいて、顧客サーバ304が使用していたデータを、再び使用可能とするために、バックアップ・リソースを顧客サーバ304に割り当てる（ステップ1106）。割り当て後、リカバリ通知(1107)を、クライアント要求受信プログラム（WWWサーバ）500を使用して、顧客の使用するコンソール300に送信する（ステップ1108）。
【００５９】
以上、本発明の第一の実施形態について説明した。
【００６０】
上記第一の実施形態では、顧客のストレ−ジ・リソースに対する要求に対して、ストレージ・リソースのリソース状態情報のみでなく、ネットワーク的な距離を選択条件に加えてストレージ・リソース選択している。これにより、ストレージ・リソース自体の性能が悪くても、トータルとして顧客サーバからのアクセス性能が良いストレージ・リソースが選択可能になった。また、今まで物理的な距離が遠いために選択候補に入らなかったストレージ・リソースが、ネットワーク的な距離が近いことで新たに選択候補に入れることができた。よって、広域に散在するストレージ・リソースの中から、顧客に最適なストレージ・リソースを提供するストレージ・リソース運用管理を実現した。
【００６１】
また、使用中のストレージ・リソースに対して、災害波及範囲として安全範囲を設定し、安全距離以上遠くにあるストレージ・リソースにバックアップを作成できた。よって、地震等の災害に対して、耐災害性能の高いストレージ・リソース運用管理を実現した。
【００６２】
以下に、上記第一の実施形態の変形例について、説明する。
（１）上記第一の実施形態では、顧客からのストレージ・リソース選択条件が、ストレージ・リソースまでのネットワークが、最もホップ数の少ないことであった。また、バックアップ・リソースの選択条件が、安全距離以上遠くであることであった。しかし、本発明は、要求の内容、および、範囲を限定するものではない。要求の範囲が、データ・アクセスに要する時間が1秒以内であることや、ストレージ・リソースとノード間のホップ数は３段以下であること、スループットが50Mbps以上であること、1キロ以内に設置してあること等であっても構わない。
（２）上記第一の実施形態では、バックアップ・リソースとして安全距離外に合致するストレージ・リソースが発見されない場合、新たに選択条件に合致するストレージ・リソースを作成している（ステップ1008）。しかしながら、新たにストレージ・リソースを作成せず、ＳＳＰ内に存在しているストレージ・リソースの中から、安全距離より近いが、最も安全距離に近い距離離れた箇所に設置されたストレージ・リソースを選択する方法であっても良い。
（３）上記第一の実施形態では、顧客がストレージ・リソースを使用する際、ＳＳＰ302内に顧客サーバ304を設置し、顧客サーバ304経由で使用する形態であった。しかしながら、顧客社内に顧客サーバを設置したまま、ＳＳＰ内のＳＡＮと直接接続してストレージ・リソースを使用する形態であっても構わない。
（４）上記第一の実施形態では、管理サーバ303上に、クライアント要求受信プログラム500、ストレージ管理プログラム502が起動し、データベース501が構築されている。しかしながら、顧客サーバ402上にクライアント要求受信プログラム500と、ストレージ・管理プログラム502が稼働し、データベース501が構築されるといった、顧客サーバ402が管理サーバ403を兼ねる構成でも構わない。
（５）上記第一の実施形態では、顧客サーバ304上のネットワーク的距離取得プログラム401がストレージに対してPingプログラムを実施し、顧客サーバとストレージ・リソース間のパケット応答時間とホップ数を測定している。しかしながら、ネットワーク的距離取得プログラムが、ストレージ・リソースのみでなく、顧客のコンソール300に対してPingプログラムを実行し、コンソール300とストレージ・リソース間のパケット応答時間を測定しても良い。ネットワーク的な距離や、物理的な距離は、ノードとストレージ・リソース間やストレージ・リソース間の間に複数のノードやネットワークが介在しても構わない。上記の場合、ネットワーク的な距離は、コンソールから顧客サーバを経て、ストレージ・リソースまでのトータルのネットワーク的な距離を表すことになる。
（６）上記第一の実施形態では、ネットワーク的な距離を取得する際、Pingプログラムを使用している。しかしながら、本発明はネットワーク的な距離を取得する方法を限定するものではない。ストレージ・リソースへ、実際のデータ書き込みやデータ読み込みを行って、データ・アクセスに要する時間を取得する方法や、ストレージ・リソースまでのホップ数や、途中経路に存在するスイッチ等のスループットを使用する方法でも構わない。
（７）上記第一の実施形態では、ストレージ・リソース間の物理的な距離を取得する際、管理サーバ403上に稼動するストレージ管理プログラム502のＧＵＩ部508からＳＳＰ302の管理者が手入力により、各ストレージの緯度および経度を入力している。しかしながら、物理的な位置関係を表すための情報（物理的な距離）は、緯度や経度、高度を使用せず、住所指定や、共通に持つ地図上のポイントを選択するといった方法でも構わない。また、物理的な距離取得に緯度と経度と高度を使用した場合であっても、各ストレージ・リソースにＧＰＳ（Global Positioning System）受信機を付加し、衛星からストレージ・リソースの緯度や経度や高度を取得する方法であっても構わない。この場合、管理サーバ303は、全ストレージ・リソースからそれぞれの緯度、経度、高度を取得する必要がある。
（８）上記第一の実施形態では、顧客の新規ストレージ・リソース割り当て要求に対して、管理サーバ303が、顧客の要求を満たす最適なストレージ・リソースを選択し、顧客サーバ304に割り当てている。しかしながら、本発明は、ストレージ・リソースの選択や割り当て方法にのみ使用を限定するものではない。既に顧客サーバに対してストレージ・リソースが決定している状態でネットワーク構成が変更した場合において、変更後にも顧客サーバのストレージ・リソースに対する要求を満たすか判断する方法に使用しても良い。
【００６３】
図１２は、上記（８）のように要求の範囲を満たしているか判断する方法に修正し、上記（３）のように形態を修正した、本発明の第二の実施形態におけるネットワーク構成図である。
【００６４】
図１２は、顧客サーバ1200とＳＳＰ（Ａ）1201と、ＳＳＰ（Ｂ）1202とから構成する。ＳＳＰ（Ａ）1201と、ＳＳＰ（Ｂ）1202は、共に１つのＳＳＰの中の（Ａ）支店と（Ｂ）支店を表す。ＳＳＰ（Ａ）1201とＳＳＰ（Ｂ）1202は、インターネット1203上にＶＰＮを作成して接続し、設置地域が異なっているが、両方のＳＡＮ（1205、1206）の管理は、ＳＳＰ（Ｂ）1202の管理サーバ1204が、一括して行っている。ＳＳＰ（Ｂ）1202は、ＳＳＰ全体のストレージ管理を行う管理サーバ1204と、ＳＡＮ1205、ストレージ1206から構成する。ＳＳＰ（Ａ）1201は、ＳＡＮ1207とストレージ1208から構成し、ＳＡＮ1207に直接顧客サーバ1200を接続している。
【００６５】
顧客サーバ1200は、顧客が自社内に設置し、自社内からＳＳＰ（Ｂ）1202のストレージ・リソースにアクセスするためのノードである。コンソールも兼ねる。矢印1209は、クライアント1200とストレージ装置1206内のストレージ・リソース1207とのネットワーク的な距離を示す。管理サーバ1204は、上記第一の実施形態の図４に示すクライアント要求受信プログラム500と、ストレージ管理プログラム502が稼動し、データベース501を保有している。ストレージ管理プログラム502内には、図５で示した処理部に加えて、移動必要／不必要判定部を持つ。
【００６６】
顧客サーバ1200では、図６に示したデータ・アクセス時間取得プログラム600が稼動している。
【００６７】
顧客サーバ1200は、上記第一の実施形態において図７に示した、ストレージ・リソース割り当ての動作フローに従い、ストレージ1208内のリソースを割り当てられて使用している。
【００６８】
本実施形態では、ネットワーク的な距離情報を、顧客サーバ1200とストレージ・リソース間のホップ数（ルータの段数）で計測する。そして、顧客の要求の範囲を、ネットワーク的な距離に対して、ホップ数２段以内とする。
【００６９】
図１３は、上記図１２のネットワーク構成において、顧客が引越しをして、顧客サーバ1200が顧客サーバ1300へと移動した場合のネットワーク構成である。顧客サーバ1300は、図１２上の顧客サーバ1200が移動した後の状態を示す。ＳＳＰ（Ａ）1201とＳＳＰ（Ｂ）1202は、図１２に示すＳＳＰ（Ａ）1201、ＳＳＰ（Ｂ）1202と同じである。顧客サーバ1300は、引越しをして、新たにＳＳＰ（Ｂ）1202内のＳＡＮ1205に直接接続する。矢印1301は、顧客サーバ1300とストレージ装置1208内のストレージ・リソースとのネットワーク的な距離（ホップ数）を示す。矢印1302は、顧客サーバ1300とストレージ装置1206とのネットワーク的な距離（ホップ数）を示す。
【００７０】
図１４は、ストレージ管理プログラム502における、顧客サーバ移動時のストレージ・リソース移動必要／不必要判定の動作フローである。
ストレージ管理プログラム502では、コンソールを兼ねている顧客サーバ1300 から移動の通知を受信した場合、移動後の顧客サーバ1300から、全ストレージ・リソースまでのホップ数を取得する（ステップ1400）。次に、移動前の顧客サーバ1200がストレージ管理プログラムに対して設定し、データベースに格納している要求の範囲、すなわち、ストレージ・リソース選択条件（ホップ数２段以内）を取得する（ステップ1401）。次に移動後の顧客サーバ1300と、移動前に使用していたストレージ・リソース1208間のホップ数（1302）を比較する。
【００７１】
移動後も、ホップ数が２段以内であれば(ステップ1402)、顧客のストレージ・リソースに対する要求性能を満たしているため、ストレージ・リソース内データの移動が必要ないと判断し、移動後の顧客サーバ1300に通知する（ステップ1403）。ステップ1402において、ホップ数が選択条件の範囲にでなかった場合、顧客サーバ1200が使用していたストレージ装置1208以外のストレージ・リソースの中から、一番ホップ数の少ないストレージ装置を選択する（ステップ1404）。そして、移動後の顧客サーバ1300にストレージ・リソース内データを移動することを通知し（ステップ1405）、ストレージ・リソース内データを、実際に移動する（ステップ1406）。
【００７２】
以上、本発明の第二の実施形態について説明した。
【００７３】
上記第二の実施形態では、顧客サーバの物理的な位置が移動した際に、顧客サーバとストレージ・リソース間のホップ数が、顧客の要求の範囲（ホップ数２段以内）であれば、ストレージ・リソース内のデータ移動は必要ないと判断している。よって、ストレージ・リソース運用管理において、移動のための作業コストの削減を実現した。
【００７４】
【発明の効果】
以上説明したように、本発明によれば、広域に散在するストレージ・リソース群から、ストレージ・リソースを選択し、ストレージ・リソースを使用するノードに割り当てる際、空き容量や使用率といったストレージ内 のリソース状態情報に、ネットワーク的な距離、すなわち、データ・アクセス性能に関わる情報、と物理的な距離を加えて選択することが可能である。よって、リソース状態情報が他のストレージ・リソースに劣るストレージ・リソースであっても、ネットワークを介してのデータ・アクセス性能が優るため、結果としてストレージ・リソースを使用するノードにとって一番アクセス性能の良いストレージ・リソースを選択することができる。よって、ストレージ・リソースに対する要求の範囲に合致し、要求に対して最適なストレージ・リソースを選択し提供する、ストレージ・ネットワーク運用を実現することができる。
【００７５】
また、顧客のサーバが使用するストレージ・リソースに対して、地震等の災害が波及しないと考えら得る距離、すなわち、安全距離を設定し、設定した安全距離以上離れた場所に設置されているストレージ・リソースを選択し、バックアップ用に設定することができる。この状態において、プライマリ・ストレージ・リソースが地震や水害など局所的な災害に見舞われた場合、災害に見舞われなかったバックアップ用のストレージ・リソースを顧客のサーバに割り当てて、データを保全することが可能である。よって、ディザスタ・リカバリ可能なストレージ・ネットワーク管理方法を実現することができる。
【００７６】
さらに、ストレージ・リソースまでのネットワーク的な距離を取得し、要求の範囲を取得することができる。よって、ストレージ・リソースを使用する顧客のサーバの物理的な設置位置が移動し、ストレージ・リソースとサーバ間の距離が大きくなった場合においても、ネットワーク的な距離の変化を測定することができる。よって、サーバの物理的な設置位置が移動後に、ストレージ・リソースまでのネットワーク的な距離が、要求の範囲にあるか否か判断することができる。そして、ネットワーク的な距離が変化しないならば、ストレージ・リソースの移動は必要ないと判断することができる。よって、ストレージ・ネットワーク運用管理コストから、不必要な移動にかかる作業コストを削減することができる。
【図面の簡単な説明】
【図１】従来のＳＳＰ102の運用形態を示すネットワーク構成図である。
【図２】ストレージ管理プログラムにおける、ストレージ・リソース割り当ての動作フロー図である。
【図３】本発明の第一の実施形態が適用されたＳＳＰ302の運用形態を示すネットワーク構成図である。
【図４】コンソール300と顧客サーバ304の概略を示す図である。
【図５】管理サーバ303の概略を示す図である。
【図６】管理サーバ303に作成したデータベース501内のストレージ・リソース情報テーブルを示す図である。
【図７】ストレージ管理プログラム502による、ストレージ・リソース割り当て時の動作を説明するフロー図である。
【図８】ネットワーク距離取得プログラム402のネットワーク距離取得の動作を説明するためのフロー図である。
【図９】ストレージ管理プログラム502のストレージ・リソース選択動作を説明するためのフロー図である。
【図１０】ストレージ管理プログラム502のバックアップ・リソース選択動作およびバックアップ設定動作を説明するためのフロー図である。
【図１１】ストレージ管理プログラム502による、障害発生時の動作を説明するためのフロー図である。
【図１２】本発明の第二の実施形態が適用されたＳＳＰ（Ａ、Ｂ）と、顧客サーバ1300との関係を示すネットワーク構成図である。
【図１３】本発明の第二の実施携帯が適用された図１２のネットワーク構成から、顧客サーバが移動した際の、ネットワーク構成図である。
【図１４】ストレージ管理プログラム502のストレージ・リソース移動必要・不必要判定の動作を説明するフロー図である。
【符号の説明】
100 クライアント・コンソール
103、302、1201、1202 ＳＳＰ
104、303、1204 管理サーバ
105、308、309、1205、1207 ＳＡＮ
106、107、306、307、1206、1208 ストレージ
108、109、110、304、1200、1300 顧客サーバ
305 ルータ
500 クライアント要求受信プログラム（ＷＷＷサーバ）
501 データベース
502 ストレージ管理プログラム
503 ネットワーク構成検索・取得部
504 バックアップ設定部
505 ストレージ・リソース割り当て部
506 ノード位置情報取得部
507 ストレージ・リソース選択部
508 ＧＵＩ部
600 ストレージ・リソース情報テーブル
1201 ＳＳＰ（Ａ）
1202 ＳＳＰ（Ｂ）
Claims (6)
- ネットワークを介してノードからのアクセス要求を受信して要求内容を実行するストレージ・リソースを少なくとも１つ有するストレージ群を有するストレージ管理システムで、前記ストレージ・リソースを管理するストレージ・リソース運用管理方法であって、
前記ノードと前記ストレージ群中のストレージ・リソースの間、および前記ストレージ群中の各ストレージ・リソース間の少なくとも一方のネットワーク的な距離及び物理的な距離の少なくとも一方を取得し、
前記ネットワーク的な距離、および前記物理的な距離の少なくとも一方に対する要求の範囲を前記ノードから取得し、
前記ネットワーク的な距離に対する前記要求の範囲、および前記物理的な距離に対する前記要求の範囲の少なくとも一方を選択の条件として、前記ネットワーク的な距離、および前記物理的な距離の少なくとも一方が前記要求の範囲内にある、前記ノードからのアクセス要求を実行する少なくとも1つのストレージ・リソースを、前記ストレージ群から選択し、
前記ノードの物理的な設置位置が、第１の設置位置から第２の設置位置に変更した場合、前記第２の設置位置に設置した前記ノードから、前記ノードが送信するアクセス要求を実行するストレージ・リソースまでのネットワーク的な距離が前記要求の範囲内であるかを判断し、
前記第２の設置位置からの前記ネットワーク的な距離が前記要求の範囲内でなければ、ストレージ・リソース内のデータを前記ネットワーク的な距離が一番近いストレージ装置へと移動し、前記第２の設置位置からの前記ネットワーク的な距離が前記要求の範囲内であれば、前記ストレージ・リソース内のデータを他のストレージ・リソース内へと移動しないことを特徴とするストレージ・リソース運用管理方法。 - 前記要求の範囲内にある少なくとも１つのストレージ・リソースの中で、前記ネットワーク的な距離、および前記物理的な距離の少なくとも一方が他に比べて近い少なくとも１つのストレージ・リソースを選択することを特徴とする請求項１記載のストレージ・リソース運用管理方法。
- 前記要求の範囲内にある少なくとも１つのストレージ・リソースの中で、前記物理的な距離が他に比べて遠い少なくとも１つのストレージ・リソースを選択することを特徴とする請求項１記載のストレージ・リソース運用管理方法。
- 前記ストレージ群の中に、前記要求の範囲内にあるストレージ・リソースが存在しない場合、前記ストレージ群の中から、前記ネットワーク的な距離、および前記物理的な距離の少なくとも一方が他に比べて近いストレージ・リソースを選択することを特徴とする請求項１記載のストレージ・リソース運用管理方法。
- 前記ストレージ群の中に、前記要求の範囲内にあるストレージ・リソースが存在しない場合、前記ネットワーク的な距離、および前記物理的な距離の少なくとも一方が前記要求の範囲内にある、少なくとも 1 つのストレージ・リソースを新たに追加することを特徴とする請求項１記載のストレージ・リソース運用管理方法。
- ネットワークを介してストレージへアクセス要求を送信するノードと、前記アクセス要求を受信して要求内容を実行する少なくとも１つのストレージ・リソースからなるストレージ群とに接続する管理サーバであって、
前記ノードと前記ストレージ群中のストレージ・リソースの間、および前記ストレージ群中の各ストレージ・リソース間の少なくとも一方のネットワーク的な距離及び物理的な距離の少なくとも一方を取得する手段と、
前記ネットワーク的な距離、および前記物理的な距離の少なくとも一方に対する要求の範囲を前記ノードから取得する手段と、
前記ネットワーク的な距離に対する前記要求の範囲、および前記物理的な距離に対する前記要求の範囲の少なくとも一方を選択の条件として、前記ネットワーク的な距離、および前記物理的な距離の少なくとも一方が前記要求の範囲内にある、前記ノードからのアクセス要求を実行する少なくとも 1 つのストレージ・リソースを、前記ストレージ群から選択する手段と、
前記ノードの物理的な設置位置が、第１の設置位置から第２の設置位置に変更した場合、前記第２の設置位置に設置した前記ノードから、前記ノードが送信するアクセス要求を実行するストレージ・リソースまでのネットワーク的な距離が前記要求の範囲内であるかを判断する手段と、
前記第２の設置位置からの前記ネットワーク的な距離が前記要求の範囲内でなければ、ストレージ・リソース内のデータを前記ネットワーク的な距離が一番近いストレージ装置へと移動し、前記第２の設置位置からの前記ネットワーク的な距離が前記要求の範囲内であれば、前記ストレージ・リソース内のデータを他のストレージ・リソース内へと移動しないデータ移動制御手段と、を有することを特徴とする管理サーバ。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001333673A JP4113352B2 (ja) | 2001-10-31 | 2001-10-31 | ストレージ・ネットワークにおけるストレージ・リソース運用管理方法 |
| US10/066,660 US7107274B2 (en) | 2001-10-31 | 2002-02-06 | Method for storage management of storage resource on a storage network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001333673A JP4113352B2 (ja) | 2001-10-31 | 2001-10-31 | ストレージ・ネットワークにおけるストレージ・リソース運用管理方法 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003140930A JP2003140930A (ja) | 2003-05-16 |
| JP2003140930A5 JP2003140930A5 (ja) | 2005-02-03 |
| JP4113352B2 true JP4113352B2 (ja) | 2008-07-09 |
Family
ID=19148900
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001333673A Expired - Fee Related JP4113352B2 (ja) | 2001-10-31 | 2001-10-31 | ストレージ・ネットワークにおけるストレージ・リソース運用管理方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7107274B2 (ja) |
| JP (1) | JP4113352B2 (ja) |
Families Citing this family (79)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7814162B2 (en) * | 2000-08-22 | 2010-10-12 | International Business Machines Corporation | Self-protecting e-mail |
| US7403987B1 (en) | 2001-06-29 | 2008-07-22 | Symantec Operating Corporation | Transactional SAN management |
| JP4434543B2 (ja) * | 2002-01-10 | 2010-03-17 | 株式会社日立製作所 | 分散ストレージシステム、ストレージ装置、およびデータのコピー方法 |
| AU2003218037A1 (en) * | 2002-03-12 | 2003-09-29 | Koninklijke Philips Electronics, N.V. | Using timing signals to determine proximity between two nodes |
| US7194538B1 (en) | 2002-06-04 | 2007-03-20 | Veritas Operating Corporation | Storage area network (SAN) management system for discovering SAN components using a SAN management server |
| US7886031B1 (en) | 2002-06-04 | 2011-02-08 | Symantec Operating Corporation | SAN configuration utility |
| US8019849B1 (en) * | 2002-09-13 | 2011-09-13 | Symantec Operating Corporation | Server-side storage area network management interface |
| US7401338B1 (en) | 2002-09-27 | 2008-07-15 | Symantec Operating Corporation | System and method for an access layer application programming interface for managing heterogeneous components of a storage area network |
| US7240096B1 (en) * | 2002-09-30 | 2007-07-03 | Bell South Intellectual Property Corp. | System and method for providing service technicians access to dispatch information |
| JP4235177B2 (ja) * | 2002-12-11 | 2009-03-11 | 富士通株式会社 | バックアップシステム，バックアップ制御装置，バックアップデータ管理方法，バックアップ制御プログラムおよび同プログラムを記録したコンピュータ読取可能な記録媒体 |
| JP4237515B2 (ja) * | 2003-02-07 | 2009-03-11 | 株式会社日立グローバルストレージテクノロジーズ | ネットワークストレージ仮想化方法およびネットワークストレージシステム |
| US20040233857A1 (en) * | 2003-05-21 | 2004-11-25 | Alcatel | Node topology placement based on geographical information |
| US7885256B1 (en) * | 2003-05-30 | 2011-02-08 | Symantec Operating Corporation | SAN fabric discovery |
| JP4141937B2 (ja) * | 2003-11-10 | 2008-08-27 | 株式会社日立製作所 | データ保管方法、データ保管プログラム、およびコンピュータ読取り可能な記録媒体 |
| US7234032B2 (en) * | 2003-11-20 | 2007-06-19 | International Business Machines Corporation | Computerized system, method and program product for managing an enterprise storage system |
| US8825194B2 (en) | 2003-12-18 | 2014-09-02 | International Business Machines Corporation | Global positioning system location information for an automated data storage library |
| US20050138625A1 (en) * | 2003-12-23 | 2005-06-23 | Carroll Timothy J. | Configuration management resource specification database design |
| US7249283B2 (en) * | 2004-03-22 | 2007-07-24 | Xerox Corporation | Dynamic control system diagnostics for modular architectures |
| JP2005352844A (ja) * | 2004-06-11 | 2005-12-22 | Nippon Telegr & Teleph Corp <Ntt> | ストレージ接続方法およびストレージシステム |
| JPWO2006038286A1 (ja) * | 2004-10-06 | 2008-05-15 | 富士通株式会社 | システム環境設定支援プログラム、システム環境設定支援方法、およびシステム環境設定支援装置 |
| US8024355B2 (en) * | 2004-12-29 | 2011-09-20 | Sap Ag | Dynamic capacity demand profile construction with a persisted capacity demand profile and a collision buffer |
| JP4671738B2 (ja) * | 2005-04-01 | 2011-04-20 | 株式会社日立製作所 | ストレージシステム及び記憶領域割当て方法 |
| US20060288014A1 (en) * | 2005-06-15 | 2006-12-21 | Edwards David M | Method and software for mobile data collection having managed workflow |
| JP4544072B2 (ja) * | 2005-07-20 | 2010-09-15 | ブラザー工業株式会社 | ノード装置、コンピュータプログラム、情報配信システム、及びネットワーク参加方法 |
| US7480817B2 (en) * | 2006-03-31 | 2009-01-20 | International Business Machines Corporation | Method for replicating data based on probability of concurrent failure |
| US8150946B2 (en) * | 2006-04-21 | 2012-04-03 | Oracle America, Inc. | Proximity-based memory allocation in a distributed memory system |
| US20080086609A1 (en) * | 2006-10-06 | 2008-04-10 | Richard Lesser | Method and Apparatus for Generating a Backup Strategy for a Client |
| US7925758B1 (en) | 2006-11-09 | 2011-04-12 | Symantec Operating Corporation | Fibre accelerated pipe data transport |
| US20080140944A1 (en) * | 2006-12-12 | 2008-06-12 | Hitachi, Ltd. | Method and apparatus for storage resource management in plural data centers |
| US9185160B2 (en) * | 2007-02-12 | 2015-11-10 | Oracle America, Inc. | Resource reservation protocol over unreliable packet transport |
| US8341623B2 (en) * | 2007-05-22 | 2012-12-25 | International Business Machines Corporation | Integrated placement planning for heterogenous storage area network data centers |
| US20080291204A1 (en) * | 2007-05-22 | 2008-11-27 | International Business Machines Corporation | Coupled placement of items using stable marriage techniques |
| WO2009065318A1 (fr) * | 2007-11-22 | 2009-05-28 | China Mobile Communications Corporation | Procédé de stockage de données, serveur de gestion, équipement et système de stockage |
| US20090271564A1 (en) * | 2008-04-25 | 2009-10-29 | Hitachi, Ltd. | Storage system |
| US8484162B2 (en) | 2008-06-24 | 2013-07-09 | Commvault Systems, Inc. | De-duplication systems and methods for application-specific data |
| US8214842B2 (en) * | 2009-02-27 | 2012-07-03 | International Business Machines Corporation | Visualization-centric performance-based volume allocation |
| JP2010250477A (ja) * | 2009-04-14 | 2010-11-04 | Fujitsu Ltd | ストレージ制御プログラム、ストレージシステム、ストレージ制御装置、およびストレージ制御方法 |
| US8930306B1 (en) | 2009-07-08 | 2015-01-06 | Commvault Systems, Inc. | Synchronized data deduplication |
| JP5507136B2 (ja) * | 2009-07-09 | 2014-05-28 | 株式会社日立製作所 | 管理装置及び方法並びに計算機システム |
| US8717869B2 (en) * | 2009-12-22 | 2014-05-06 | At&T Intellectual Property I, L.P. | Methods and apparatus to detect and restore flapping circuits in IP aggregation network environments |
| US8711864B1 (en) | 2010-03-30 | 2014-04-29 | Chengdu Huawei Symantec Technologies Co., Ltd. | System and method for supporting fibre channel over ethernet communication |
| US8412899B2 (en) * | 2010-04-01 | 2013-04-02 | Autonomy, Inc. | Real time backup storage node assignment |
| US11449394B2 (en) | 2010-06-04 | 2022-09-20 | Commvault Systems, Inc. | Failover systems and methods for performing backup operations, including heterogeneous indexing and load balancing of backup and indexing resources |
| US9020900B2 (en) | 2010-12-14 | 2015-04-28 | Commvault Systems, Inc. | Distributed deduplicated storage system |
| US20120150818A1 (en) | 2010-12-14 | 2012-06-14 | Commvault Systems, Inc. | Client-side repository in a networked deduplicated storage system |
| JP5969515B2 (ja) | 2011-02-22 | 2016-08-17 | フェデックス コーポレイト サービシズ，インコーポレイティド | 分散型グローバル（クラウド）アーキテクチャを通じたセンサーデータのジオステージングのためのシステム及び方法 |
| JP5696891B2 (ja) * | 2011-03-31 | 2015-04-08 | 日本電気株式会社 | Ｉｏ構成によるジョブスケジューリング方法 |
| JP5963135B2 (ja) * | 2011-08-23 | 2016-08-03 | パナソニックＩｐマネジメント株式会社 | 通信システム、通信システムにおいて利用される通信装置およびサーバ |
| JP2013045443A (ja) * | 2012-01-17 | 2013-03-04 | Otsuka Shokai Co Ltd | 仮想データセンタシステム |
| WO2013145222A1 (ja) * | 2012-03-29 | 2013-10-03 | 富士通株式会社 | 情報処理装置およびデータ保存処理プログラム |
| JP5909760B2 (ja) * | 2012-05-22 | 2016-04-27 | 西日本電信電話株式会社 | 配置先決定システム、配置先決定方法及びコンピュータプログラム |
| US9218376B2 (en) | 2012-06-13 | 2015-12-22 | Commvault Systems, Inc. | Intelligent data sourcing in a networked storage system |
| JP5965781B2 (ja) * | 2012-08-27 | 2016-08-10 | 株式会社エヌ・ティ・ティ・データ | リソース管理装置、リソース管理方法およびプログラム |
| US9152506B2 (en) * | 2012-09-20 | 2015-10-06 | Hitachi, Ltd. | Management apparatus and management method |
| US9069482B1 (en) * | 2012-12-14 | 2015-06-30 | Emc Corporation | Method and system for dynamic snapshot based backup and recovery operations |
| US9633033B2 (en) | 2013-01-11 | 2017-04-25 | Commvault Systems, Inc. | High availability distributed deduplicated storage system |
| US20150169609A1 (en) * | 2013-12-06 | 2015-06-18 | Zaius, Inc. | System and method for load balancing in a data storage system |
| US10380072B2 (en) | 2014-03-17 | 2019-08-13 | Commvault Systems, Inc. | Managing deletions from a deduplication database |
| US9563518B2 (en) | 2014-04-02 | 2017-02-07 | Commvault Systems, Inc. | Information management by a media agent in the absence of communications with a storage manager |
| US9575673B2 (en) | 2014-10-29 | 2017-02-21 | Commvault Systems, Inc. | Accessing a file system using tiered deduplication |
| US9697083B2 (en) * | 2014-11-21 | 2017-07-04 | International Business Machines Corporation | Using geographical location information to provision multiple target storages for a source device |
| US10353595B2 (en) * | 2014-11-21 | 2019-07-16 | International Business Machines Corporation | Using geographical location information and at least one distance requirement to determine a target storage to provision to backup data for a source device |
| US10339106B2 (en) | 2015-04-09 | 2019-07-02 | Commvault Systems, Inc. | Highly reusable deduplication database after disaster recovery |
| US20170193003A1 (en) * | 2015-12-30 | 2017-07-06 | Commvault Systems, Inc. | Redundant and robust distributed deduplication data storage system |
| WO2017158824A1 (ja) * | 2016-03-18 | 2017-09-21 | 株式会社日立製作所 | リソース貸出システム及びリソース管理方法 |
| US9686357B1 (en) | 2016-08-02 | 2017-06-20 | Palantir Technologies Inc. | Mapping content delivery |
| US10747630B2 (en) | 2016-09-30 | 2020-08-18 | Commvault Systems, Inc. | Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, including operations by a master monitor node |
| US10454754B1 (en) * | 2016-12-16 | 2019-10-22 | Amazon Technologies, Inc. | Hybrid cluster recovery techniques |
| US10505813B2 (en) * | 2017-05-18 | 2019-12-10 | Datera, Inc. | System and method for an improved placement of storage nodes in network |
| US11016696B2 (en) | 2018-09-14 | 2021-05-25 | Commvault Systems, Inc. | Redundant distributed data storage system |
| US11200124B2 (en) | 2018-12-06 | 2021-12-14 | Commvault Systems, Inc. | Assigning backup resources based on failover of partnered data storage servers in a data storage management system |
| US11698727B2 (en) | 2018-12-14 | 2023-07-11 | Commvault Systems, Inc. | Performing secondary copy operations based on deduplication performance |
| US20200327017A1 (en) | 2019-04-10 | 2020-10-15 | Commvault Systems, Inc. | Restore using deduplicated secondary copy data |
| US11463264B2 (en) | 2019-05-08 | 2022-10-04 | Commvault Systems, Inc. | Use of data block signatures for monitoring in an information management system |
| CN111399761B (zh) * | 2019-11-19 | 2023-06-30 | 杭州海康威视系统技术有限公司 | 存储资源分配方法、装置及设备、存储介质 |
| US20210173811A1 (en) | 2019-12-04 | 2021-06-10 | Commvault Systems, Inc. | Optimizing the restoration of deduplicated data stored in multi-node replicated file systems |
| US11099956B1 (en) | 2020-03-26 | 2021-08-24 | Commvault Systems, Inc. | Snapshot-based disaster recovery orchestration of virtual machine failover and failback operations |
| US11687424B2 (en) | 2020-05-28 | 2023-06-27 | Commvault Systems, Inc. | Automated media agent state management |
| US11645175B2 (en) | 2021-02-12 | 2023-05-09 | Commvault Systems, Inc. | Automatic failover of a storage manager |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5544347A (en) * | 1990-09-24 | 1996-08-06 | Emc Corporation | Data storage system controlled remote data mirroring with respectively maintained data indices |
| US6792463B1 (en) * | 1999-10-21 | 2004-09-14 | International Business Machines Corporation | System, method and program product for providing invisibility to a proxy-server |
| US7162539B2 (en) * | 2000-03-16 | 2007-01-09 | Adara Networks, Inc. | System and method for discovering information objects and information object repositories in computer networks |
-
2001
- 2001-10-31 JP JP2001333673A patent/JP4113352B2/ja not_active Expired - Fee Related
-
2002
- 2002-02-06 US US10/066,660 patent/US7107274B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20030084076A1 (en) | 2003-05-01 |
| JP2003140930A (ja) | 2003-05-16 |
| US7107274B2 (en) | 2006-09-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4113352B2 (ja) | ストレージ・ネットワークにおけるストレージ・リソース運用管理方法 | |
| US9104741B2 (en) | Method and apparatus for seamless management for disaster recovery | |
| US6839815B2 (en) | System and method for storage on demand service in a global SAN environment | |
| US7451289B2 (en) | Storage device and system for providing communications buffer reservation function | |
| US7971089B2 (en) | Switching connection of a boot disk to a substitute server and moving the failed server to a server domain pool | |
| JP4068473B2 (ja) | ストレージ装置、分担範囲決定方法及びプログラム | |
| US7599941B2 (en) | Transparent redirection and load-balancing in a storage network | |
| US8682955B1 (en) | Fully automated cloud tiering controlled by an orchestration layer based on dynamic information | |
| US20150347246A1 (en) | Automatic-fault-handling cache system, fault-handling processing method for cache server, and cache manager | |
| US10320905B2 (en) | Highly available network filer super cluster | |
| US20130198476A1 (en) | Management system of information memory system and management method thereof | |
| JP2008542887A (ja) | 仮想化ネットワークストレージシステム、ネットワークストレージ装置及びその仮想化方法 | |
| EP1354448A2 (en) | Distribution processing and criteria-based dynamic modification of data-flow map | |
| JP2008146627A (ja) | 複数のデータセンタにおけるストレージリソース管理のための方法および装置 | |
| JP5037644B2 (ja) | 計算機システム及びその制御方法 | |
| US9544371B1 (en) | Method to discover multiple paths to disk devices cluster wide | |
| EP1109413B1 (en) | Summary building block, system and method for network management |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040301 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040301 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060419 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071001 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071009 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071129 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20071129 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20071212 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080107 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080222 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080404 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080411 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110418 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120418 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120418 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130418 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |