JP5267544B2 - ディスク引き継ぎによるフェイルオーバ方法 - Google Patents

Description

本発明は、外部ディスク装置からブートするサーバから成る計算機システムにおけるフェイルオーバ方法に関する。

一般に、サーバは内蔵のディスク装置にインストールされたOSをブートする。この構成では、故障したサーバの業務を引き継ぐ場合、従来の方法として、サーバに内蔵するディスク装置に同じOSや業務アプリケーションを複数のサーバのディスクにインストールする冗長化構成を取っていた。この方法では、業務を実行中のサーバ（現用サーバ）が故障した場合、同じOSや業務アプリケーションがインストールされた別のサーバ（予備サーバ）が起動することで業務を引き継ぐことができる。しかし、この方法では、１台の現用サーバに対して、ペアとなる予備サーバが必要となるため、初期導入コストや初期構築工数が増大する。

上記に対して、サーバがディスク装置として外部のディスクアレイ装置を利用してブートする形態がある。この場合、ディスクアレイ装置は、ファイバチャネルやファイバチャネルスイッチを介して複数のサーバと接続することができため、ディスクアレイ装置に接続されたあるサーバのブートディスクは、別のサーバから参照可能である。この構成では、業務を実行中の現用サーバで障害が発生した場合、そのサーバのブートディスクを利用して予備サーバが起動することで業務を引き継ぐことができる。この方法では、ブートディスクの内容はそのまま予備サーバに引き継ぐため、OSや業務アプリケーションをそのまま引き継ぐことができる。さらに、現用サーバに対してペアとなる予備サーバを準備する必要が無いため、任意の現用サーバから任意の予備サーバへの業務引き継ぎが可能である。しかし、現用サーバと予備サーバとでハードウェア構成が異なる場合、ブートディスク内のOSや業務アプリケーションが正常に動作できない場合がある。

この課題に対して、従来の方法では、均質なハードウェア構成をもつシステムを想定し、ユーザはあるハードウェア構成の現用サーバに対して、同じハードウェア構成の予備サーバを設定する方法を取っていた。しかしこの方法では、ユーザの初期構築工数が増大してしまう。さらに、CPUの速度やメモリ容量など、ハードウェア構成が多少異なっても業務の引き継ぎが可能な場合があるため、必ずしも同じハードウェア構成のサーバを準備する必要は無い場合がある。

さらに、複数のサーバを仮想的に１台の論理サーバを構成するパーティション機能を利用している場合、現用の論理サーバと、予備の論理サーバのパーティション構成を一致させる必要がある。しかし、ある現用の論理サーバに対して、予備の論理サーバのパーティション構成を一致させておくと、その予備の論理サーバは構成が一致していない他の現用の論理サーバからの業務は引き継ぐことは出来ない。このため、現用の論理サーバに対して必ずペアとなる予備の論理サーバを準備しておく必要があるため、初期導入コストと初期構築コストが増大してしまう。

本発明が解決しようとする課題は、外部のディスク装置を利用してブートするサーバにおいて障害が発生した場合に、ブートディスクの引き継ぎによる業務引き継ぎを実現する方法において、不均質なハードウェア構成を持つシステムの中から業務の引き継ぎ先となるサーバの選択作業やパーティション構成作業を不要とすることで、システムの初期構築の工数と導入コストとを削減することである。

予備サーバの設定作業を人手により行う場合、ハードウェア構成が均質なシステムの場合はどのサーバを予備サーバとして設定しても問題はない。しかし、不均質なハードウェア構成をもつシステムの場合、予備サーバとして設定する際に、ユーザは現用サーバのハードウェア構成情報を調べ、さらに予備サーバの候補となるサーバのハードウェア構成を調べて、一致するサーバを選択しなければならないため、手間がかかる。

また、一般に業務引き継ぎでは、複数の現用サーバに対して１台の予備サーバを設定する。このため、パーティション機能を利用している場合、予備の論理サーバの構成は、現用の論理サーバで障害が発生した時点で決定する。このため、ユーザが障害発生を監視し、発生時に人手によるパーティション構成作業を実施しなければならず、運用コストが大幅に増大してしまう。さらに、予備サーバの台数が不足するなど、予備サーバ群の構成によっては、現用の論理サーバと同じ構成を持つ予備の論理サーバを構成できない場合がある。

複数のサーバがネットワーク上の外部ディスク装置に接続され、サーバは外部ディスク装置からオペレーションシステムをブートする計算機システムにおいて、業務を稼動である現用サーバの障害発生時に、計算機システム内の業務を稼動中でないサーバへと業務処理を引き継ぐ際に、現用サーバの障害発生を検知し、計算機システム内において現用サーバと同じハードウェア構成を持つ業務を稼動中でないサーバを検索し、検索の結果発見したサーバから外部ディスク装置へのアクセスを可能として、そのサーバを外部ディスク装置からブートすることで業務の引き継ぎを行う。

本発明は外部のディスク装置を利用してブートするサーバにおいて障害が発生した場合に、ブートディスクの引き継ぎによる業務引き継ぎを実現する方法において、不均質なハードウェア構成を持つシステムの中から業務の引き継ぎ先となるサーバの選択作業やパーティション構成作業を不要とすることで、システムの初期構築の工数と導入コストの削減を可能とするフェイルオーバ方法を実現する。

本発明の実施例１の全体構成を示すブロック図である。 上記実施例のサーバの構成を示すブロック図である。 上記実施例の管理サーバの構成を示す機能ブロック図である。 上記実施例のサーバ管理テーブルを示すフォーマット図である。 上記実施例のサーバ管理モジュールの構成を示す機能ブロック図である。 上記実施例のディスクマッピング変更モジュールを示す機能ブロック図である。 上記実施例のディスクマッピング機構を示す機能ブロック図である。 上記実施例のサーバへのディスクマッピング構成を示す概念図である。 上記実施例の動作を示すシーケンス図である。 サーバ管理モジュールの処理フローを示すフローチャートである。 サーバ検索モジュールの処理フローを示すフローチャートである。 ディスクマッピング変更モジュールとディスクマッピング機構のシーケンス図である。 本発明の実施例２の全体構成を示すブロック図である。 上記実施例の管理サーバの構成を示す機能ブロック図である。 上記実施例のパーティション構成可能テーブルを示すフォーマット図である。 上記実施例のパーティション管理テーブルを示すフォーマット図である。 上記実施例の動作を示すシーケンス図である。 上記実施例のサーバ検索モジュールの処理フローを示すフローチャートである。 上記実施例のパーティション構成変更モジュールとパーティション管理機構のシーケンス図である。 本発明の実施例３のサーバ検索モジュールの構成を示す機能ブロック図である。 上記実施例のサーバ検索モジュールの処理フローを示すフローチャートである。 本発明の実施例４のサーバ管理テーブルを示すフォーマット図である。 上記実施例のサーバ検索モジュールの処理フローを示すフローチャートである。 本発明の実施例５の全体構成を示すブロック図である。 上記実施例の管理サーバの構成を示す機能ブロック図である。 上記実施例のサーバ管理テーブルを示すフォーマット図である。

図１は、本発明における実施例の全体図を示している。本実施例のシステムは複数のサーバ１０２を備える。各サーバは、ネットワークインターフェースカード（ＮＩＣ）１２１を介してネットワークスイッチ（ＮＷ ＳＷ）１０５に接続され、ファイバチャネルのホストバスアダプタ（HBA）１２０を介してファイバチャネルスイッチ１０４に接続されている。また、ファイバチャネルスイッチ１０４はディスクアレイ装置１０３にも接続されサーバ１０２からアクセスできる。ネットワークスイッチ１０５は、システムを管理する管理サーバ１０１にも接続されている。また、サーバ１０２の各々にはＢＭＣ（Baseboard Management Controller）１２２が内蔵されておいる。ＢＣＭ１２２はネットワークを介して管理サーバ１０１に接続される。これにより各サーバのハードウェアの状態監視や、電源制御が可能となる。さらにサーバ１０２にはパーティション機構１４０が設けられている。図示した実施例ではパーティション機構１４０は２台のサーバを１つの論理サーバとするか、それぞれ個別の論理サーバとするかの切り換えを行う。具体的には、前者の場合には同一パーティション内の各々のサーバは互いに他のサーバが搭載するメモリを自身が搭載するメモリと同様にアクセス可能とする。

なお、同一パーティションにまとめられるサーバの最大数を、２台でなくより多数にすると、論理サーバ構成のより多彩な切り換えが可能となる。管理サーバ１０１は、サーバ１０２，ディスクアレイ装置１０３、ネットワークスイッチ１０４，ファイバチャネルスイッチ１０５に対し、ネットワークを経由して状態の監視や必要に応じて制御を行う。管理サーバ１０１にはフェイルオーバ機構１１０が設けられている。フェイルオーバ機構１１０は、サーバの障害発生時にBMC１２２からの障害通知の受信やBMC１２２への電源制御、ディスクアレイ装置１０３のディスクマッピング機構１３０の制御などを行う機構であり、本発明の特徴の一つである。ディスクアレイ装置１０３内のディスクマッピング機構１３０は、サーバ１０２に搭載のHBA１２０とディスク１３１との関係づけを行う。具体的にはディスク１３１にアクセス可能なサーバを制限することによりセキュリティ機能を実現する。本実施例１では、サーバ１０２はブートディスクとしてディスクアレイ装置１０３内のディスク１３１を利用し、ディスク１３１にはOSおよび業務アプリケーションが格納されている。

図２は、本実施例におけるサーバ１０２の詳細な構成を示している。サーバ１０２にはプログラムやデータを格納するメモリ２０１と、メモリ内のプログラムを実行するCPU２０２と、HBA１２０と、NIC１２１と、ＢＭＣ１２２から構成されている。HBA１２０にはファイバチャネル通信において通信相手を特定するために必要となるＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）２０４と呼ばれるユニークなデバイス識別子がメモリに格納されている。ＢＭＣ１２２は、主にサーバ１０２のハードウェアの監視や制御を行う。サーバ１０２のハードウェアに異常が発生した場合は障害検出機構２０５が検知して外部に通知可能である。また、BMC１２２を通じて遠隔からサーバ１０２の電源のＯＮ／ＯＦＦが可能である。

図３はフェイルオーバ機構１１０のプログラムモジュール構成を示している。フェイルオーバ機構１１０は、サーバのハードウェアやパーティションの構成状況およびサーバの利用状態を格納するサーバ管理テーブル３０１と、サーバの状態監視を行って障害発生時のフェイルオーバ動作の起動やサーバの電源制御を行うサーバ管理モジュールと、フェイルオーバ時に業務の引き継ぎ先となる予備サーバを検索するサーバ検索機能と、フェイルオーバ時に現用サーバから予備サーバへディスクマッピングを変更するディスクマッピング変更モジュールから構成される。

図４は、図３におけるサーバ管理テーブル３０１の詳細を示している。サーバ管理テーブル３０１は、フェイルオーバ機構１１０が管理対象としているサーバの一覧と、各サーバの構成情報および状態が格納されている。テーブルのカラム４０１は、サーバの識別子が格納されている。サーバ識別子４０１は、サーバが特定できる情報であれば良い。サーバのシリアル番号や、ブレードサーバであれば、ブレード番号などである。カラム４０２は、カラム４０２はサーバのCPU種別を示している。製品名が同じCPUであっても、ステッピングなどが異なれば区別可能な情報を含んでいる。カラム４０３はサーバのCPU周波数を示している。カラム４０４はサーバが搭載しているメモリ容量を示している。カラム４０５はサーバのパーティション構成を示している。カラムの数字はそのサーバが属するパーティションを構成するサーバ数を示しており、括弧内はそのサーバが属すパーティションの識別子を示す。パーティション識別子は論理サーバに対応して付与される。

たとえば、サーバ識別子S2とS3のサーバが１つの論理サーバを構成しているのであれば、S2とS3は共にパーティション構成サーバ数は２となり、同じパーティション識別子であるP2に所属していることになる。また、サーバ１台のみで論理サーバが構成されている場合もある。この場合は、パーティション機能を持たないサーバと同等である。本実施例では、現用サーバや予備サーバは全て論理サーバとして示している。ただし、パーティション機能を持たないシステムでは、物理サーバが現用サーバや予備サーバであっても良い。カラム４０６はサーバの状態を示している。使用中の場合は業務を実行中である。未使用の場合は直ぐに別の業務に利用可能である。また、障害が発生して利用できない場合は障害発生中であることを示す情報が格納される。

図５は、図３におけるサーバ管理モジュール３０２の詳細を示している。サーバ管理モジュールは、サーバの状態監視を行い、サーバの稼動状況や障害監視、および電源の制御を行う。サーバの障害発生時、図１に示すBMC１２２や、サーバ上で稼動するエージェントプログラムなどがサーバの障害を検出すると、サーバ管理モジュール３０２へ障害の発生を通知される。このとき通知される障害情報には障害の種類が含まれている。この障害の種類によってフェイルオーバ実行の是非を判断するため、サーバ管理モジュール３０２は障害動作テーブルを持つ。カラム５０１は発生した障害の種類を示し、カラム５０２はその障害発生時のフェイルオーバ実行の是非を示す。障害動作テーブルの格納情報は、システムのユーザが任意に設定可能とすることも出来る。

図６は、図３におけるディスクマッピング変更モジュール３０４の詳細を示している。ディスクマッピング変更モジュール３０４は、障害が発生した現用サーバのマッピングされているディスクを全てマッピング解除して、業務引き継ぎ先となる予備サーバへそのディスクをマッピングするように要求する。このディスクマッピングの変更は、図１に示すディスクアレイ装置１０３内のディスクマッピング機構１３０に対して要求する。ディスクマッピング機構１３０は、サーバ搭載のHBAの識別子であるWWNに対してディスクを割り当てる。このため、ディスクマッピング変更には、現用サーバのWWNとマッピングされているディスクの情報、予備サーバのWWNが必要となる。これらの情報をディスクマッピング変更モジュール３０４はサーバディスクマッピングテーブルに格納する。カラム６０１はサーバの識別子を示す。カラム６０２はサーバ搭載のHBAのWWNを示している。カラム６０３はWWNに割り当てられているディスクの仮想ディスク番号を示す。カラム６０４はそのディスクの物理ディスク番号を示している。仮想ディスク番号は、サーバに見せる仮想的なディスク番号であり、物理ディスク番号に関わらず設定することが出来る。また、サーバディスクマッピングテーブルはディスクがマッピングされていないサーバの情報も記録する。この場合、カラム６０３およびカラム６０４の情報は空白となる。

図７は、図１におけるディスクアレイ装置１０３内のディスクマッピング機構１３０の詳細を示している。ディスクマッピング機構１３０はディスクアレイ装置内１０３のディスク１３１と、ディスクアレイ装置１０３にファイバチャネル経由で接続されているサーバ搭載のHBA１２０のWWNとのマッピングを実施する。このマッピング関係にないWWNを持つサーバからはディスクを参照できない。これにより、あるディスクをあるサーバからのみアクセス可能とするセキュリティ設定が可能である。このセキュリティ設定のため、本実施例ではディスクマッピング機構１３０は図７に示すディスクマッピングテーブルを持つ。カラム７０１はサーバ搭載のHBAのWWNを示す。カラム７０２はWWNにマッピングされた仮想ディスク番号を示す。カラム７０３はWWNにマッピングされた論理ディスク番号を示す。

図８は、本実施例におけるディスクマッピング変更例を示している。現用サーバ８０１に搭載のHBA８１０はWWN１（８１１）を持ち、予備サーバ８０２に搭載のHBA８２０はWWN２（８２１）を持つ。これらはファイバチャネルスイッチ１０４を経由してディスクアレイ装置１０３に接続されている。ディスクのマッピングはディスクマッピング機構１３０によって制御されており、仮想ディスク８３１、８３２，８３３を含む仮想ディスクのグループ８０３が現用サーバ８０１のWWN１（８１１）にマッピングされている。仮想ディスク８３１、８３２、８３３の実体は論理ディスク８０４、８０５、８０６であり、OSや業務アプリケーションがインストールされているブートディスクを含んでいる。現用サーバ８０１で障害が発生した場合は、予備サーバ８０２へとディスクマッピングを変更する。このとき、現用サーバ８０１のWWN１（８１１）と仮想ディスクのグループ８０３とのマッピングを解除し、予備サーバ８０２のWWN２（８２１）へマッピングする。これにより、予備サーバ８０２は現用サーバ８０１が利用していたOSや業務アプリケーションを含むディスクを引き継ぐことができる。この状態で予備サーバ８０２を起動することで、現用サーバ８０１からの業務のフェイルオーバを実現する。

図９は、本実施例のフェイルオーバ動作のシーケンス図である。図示するシーケンス図は、現用サーバ８０１、管理サーバ１０１のフェイルオーバ機構１１０、ディスクマッピング機構１３０、及び予備サーバ８０２の連携動作を示す。ステップ９１０は現用サーバでの障害発生を示す。現用サーバ８０１に搭載のBMCや現用サーバ上で稼動中のエージェントプログラムが障害の発生を検出し、フェイルオーバ機構１１０に通知する。ステップ９２０でフェイルオーバ機構１１０は通知された障害を検知する。するとフェイルオーバ機構１１０はステップ９２１で現用サーバのハードウェア構成やパーティション構成などの情報を取得する。この情報は図４に示したサーバ管理テーブルから取得する。ステップ９２２では、現用サーバをシャットダウンする。もし現用サーバが稼動したままであれば、OSや業務アプリケーションが不安定な状態で稼動している場合があり、これらが不正なI/Oを発行する場合がある。

さらに、予備サーバが業務を引き継いだ時点で現用サーバが未だ稼動中であれば、同じIPアドレスを持つサーバが並存することになる。これを防ぐため、現用サーバのシャットダウンが必要である。ただし、現用サーバがダンプ処理中である場合は、ダンプ処理が終了までシャットダウンを実行しない。また、フェイルオーバ機構１１０が現用サーバ８０１にダンプ処理の起動を要求する場合もある。ステップ９１１では、現用サーバ８０１がシャットダウンの要求を受けてシャットダウン処理を実行する。もしシャットダウン処理が不可能な場合は、フェイルオーバ機構１１０が現用サーバ８０１の強制電源OFFを実行する。強制電源OFFはサーバ搭載のBMCに対して指示することで実行する。フェイルオーバ機構１１０はステップ９２３では、ステップ９２１で取得した現用サーバの情報をもとに、業務引き継ぎが可能な予備サーバを検索する。この検索は図４に示したサーバ管理テーブルの情報が現用サーバと一致するサーバを検索することで実行する。検索の結果、発見したサーバを予備サーバ９０４とする。ステップ９２４では現用サーバ９０１にマッピングされたディスクのマッピングを解除して、予備サーバ８０２にマッピングするためのディスクマッピング変更要求をディスクマッピング機構１３０に要求する。ステップ９３０では、ディスクアレイ装置のディスクマッピング機構１３０が要求されたディスクマッピング変更を実行する。ステップ９２５では予備サーバ８０２の起動を要求する。ステップ９４０では予備サーバ８０２が起動する。これによりOSや業務アプリケーションが起動するため、ステップ９４１で業務が再開される。

以下では、図９におけるシーケンスをより詳細に説明する。図１０は、サーバ管理モジュール３０２の動作フローを示している。ステップ１００１では、障害が発生したサーバから障害情報を受信する。ステップ１００２では、受信した障害の情報から障害の種類を特定する。ステップ１００３では、障害動作テーブルを参照し、該当する障害の種類に対してフェイルオーバ動作の実行の是非となる情報を参照する。ステップ１００４は、障害動作テーブルの内容より、フェイルオーバの実行の是非を判定する。フェイルオーバ動作が必要であればステップ１００５に移り、不要であれば何もせずに終了する。ステップ１００５では、現用サーバのシャットダウンを実行する。ステップ１００６では、サーバ検索モジュール３０３を起動する。サーバ検索モジュールの動作が終了するとステップ１００７に移る。ステップ１００７では予備サーバを起動する。

図１１はサーバ検索モジュール３０３の処理フローを示している。ステップ１１０１では、サーバ管理テーブルから現用サーバの情報を取得する。このとき、現用サーバのサーバ識別子と、そのサーバか属するパーティション識別子を元に情報を取り出す。ステップ１１０２では、サーバ管理テーブルから、取り出した現用サーバの情報とハードウェア構成が同じであり、かつ同じパーティション構成を持つ未使用状態のサーバを検索する。ここでハードウェア構成とは、図４に示すサーバ管理テーブルのCPU種別（カラム４０２）とCPU周波数（カラム４０３）とメモリ容量（カラム４０４）のことである。また、パーティション構成はカラム４０５であるが、ここではパーティションを構成するサーバ数のみを条件として参照し、どのパーティションに所属するかは関係ない。ステップ１１０３では、検索の結果、サーバが発見できたかどうかを判定する。発見したならば次のステップ１１０４に進む。発見できなかった場合は終了する。ただし、一般的にサーバが発見できなかった場合には、その旨を示す情報をユーザに通知するため、メッセージの表示やログへの出力を行う。ステップ１１０４では発見したサーバを予備サーバに指定する。ステップ１１０５ではディスクマッピング変更モジュールを起動する。

図１２はディスクマッピング変更モジュール３０３およびディスクアレイ装置のディスクマッピング機構１３０１０３の詳細シーケンスを示す。ステップ１２０１、１２０２、１２０３、１２０５はディスクマッピング変更モジュール３０３の処理フロー、ステップ１２０４、１２０６はディスクマッピング機構１３０１０３の処理フローである。ステップ１２０１では、サーバマッピングテーブルを参照して、現用サーバ搭載のWWNと、そこへマッピングされているディスクの状態を取得する。ステップ１２０２では、サーバディスクマッピングテーブルを参照して予備サーバ搭載のWWNを取得する。これらの情報はディスクマッピング機構１３０へマッピング変更要求を指示する際に引数として必要となる。ステップ１２０３で、現用サーバのWWNにマッピングされているディスクのマッピングを解除するように、ディスクマッピング機構１３０に要求を出す。ステップ１２０４では、現用サーバのWWNに対するディスクのマッピングを全て解除する。ステップ１２０５では、ディスクマッピング機構１３０に対して、現用サーバにマッピングされていたディスクを、予備サーバのWWNにディスクにマッピングするように要求する。ステップ１２０６では、予備サーバのWWNに対して要求されたディスクマッピングを実施する。

図１３は、本発明における実施例２の全体図を示している。実施例２では、現用の論理サーバのパーティション構成に合わせて、予備の論理サーバを構成する実施例を示す。実施例１と異なるのは、管理サーバ１０１′にパーティション管理機構１１１が追加されたことと、フェイルオーバ機構の構造である。パーティション管理機構１１１は、論理サーバの作成、構成変更、および削除といったパーティションの制御を行う機構である。フェイルオーバ機構１１０′は、パーティション管理機構１１１と連携して、予備の論理サーバのパーティションを自動構成する機能を実現する。

図１４は、実施例２の管理サーバ１０１′の構成を示している。実施例１の管理サーバ１０１に加えて、パーティション管理機構１１１が追加される。フェイルオーバ機構１１０′の構造は、実施例１のフェイルオーバ機構１１０に加えて、パーティション構成変更モジュール３０５と、パーティション構成可能テーブル３０６が追加される。パーティション構成変更モジュール３０５は、現用の論理サーバと予備の論理サーバのパーティション構成が一致するように、パーティション管理機構１１１に対して、予備となる論理サーバの構成変更を要求する機能モジュールである。ここでパーティション構成を一致させるとは、現用の論理サーバを構成するサーバ台数と、予備の論理サーバを構成するサーバ台数を一致させることである。たとえば、現用サーバがサーバ２台で構成される論理サーバであった場合、予備サーバも同様にサーバ２台で構成される論理サーバとする。パーティション構成可能テーブル３０６は、システムで論理サーバが構成できるサーバの組み合わせを列挙するテーブルである。パーティション構成変更モジュール３０５は、パーティション構成可能テーブル３０６を参照して、現用の論理サーバと同じパーティション構成となる論理サーバを構成できるサーバの組み合わせを検索する。パーティション管理機構１１１はパーティション管理テーブル３１１を含んでいる。パーティション管理機構１１１は、パーティション管理テーブル３１１を参照して、現在のパーティション構成を管理している。

図１５は、図１４のパーティション構成可能テーブル３０６の詳細を示している。カラム１５０１は論理サーバを構成するサーバの台数を示す。カラム１５０２は、論理サーバを構成することが可能なサーバの組み合わせを示す。図１５に示す例では、サーバ２台で構成する論理サーバは、S2とS3の組み合わせ、S6とS7の組み合わせ、S11とS12の組み合わせで可能ということである。また、本実施例では、サーバ１台で構成する論理サーバのサーバ識別子は記述していないが、本テーブルに含まれていても問題ない。

図１６は、図１４のパーティション管理テーブル３１１の詳細を示している。カラム１６０１はパーティション識別子を示している。この識別子は論理サーバに対応して付与される。カラム１６０２は論理サーバを構成するサーバを示す。

図１７は、実施例２のフェイルオーバ動作のシーケンス図である。図示するシーケンス図は、現用サーバ、フェイルオーバ機構１１０′、パーティション管理機構１１１、ディスクマッピング機構１３０、及び予備サーバの連携動作を示す。実施例１と異なるのは、ステップ１７２４のパーティション構成要求と、ステップ１７３０のパーティション構成変更が追加されたことである。また、ステップ１７２３の予備サーバの検索における詳細も異なる。ステップ１７２３では、まず現用の論理サーバのパーティション構成と同じパーティション構成を持つ未使用のサーバの組を検索する。見つかった場合は現用サーバへのディスクのマッピングを解除し、見つかった未使用サーバにそのディスクをマッピングすることを要求するステップ１７２５に進む。一方、現用の論理サーバのパーティション構成と同じパーティション構成を持つ未使用のサーバの組が見つからない場合は、現用の論理サーバと同じパーティション構成の論理サーバを構成可能なサーバの組み合わせを検索する。たとえば、現用サーバが２台のサーバから構成される論理サーバであった場合、その２台と同じハードウェア構成を持つサーバであり、かつ論理サーバが構成可能なサーバ２台を検索する。これが見つかれば、ステップ１７２４に進み、発見したサーバを利用して、論理サーバを構成するようにパーティション管理機構１７０３に要求する。ステップ１７３０は、パーティション管理機構１７０３がステップ１７２４の要求を受けて、パーティションの構成変更を実施する。

図１８は、実施例２におけるサーバ検索機能３０３の処理フローを示している。ステップ１８０１では、サーバ管理テーブルから現用サーバの情報を取得する。このとき、現用サーバのサーバ識別子と、そのサーバか属するパーティション識別子を元に情報を取り出す。ステップ１８０２では、サーバ管理テーブルから、現用サーバを構成するサーバとハードウェア構成が同じで、かつパーティション構成も同じである未使用サーバの組み合わせ（予備の論理サーバ）を検索する。もしそのサーバの組が無ければ、次にステップ１８０３に進む。ステップ１８０３では現用サーバを構成するサーバとハードウェア構成が同じサーバであり、論理サーバを構成可能なサーバの組み合わせを検索する。たとえば、現用サーバがサーバ２台で構成される論理サーバである場合、まずそれぞれのサーバと同じハードウェア構成を持つサーバをサーバ管理テーブル３０１を利用して検索し、次にそれらのサーバの中から２台で論理サーバが構成できるサーバの組みをパーティション構成可能テーブル３０６を利用して検索する。発見したならば次のステップ１８０４に進み、パーティション構成変更モジュールを起動する。次にステップ１８０５でディスクマッピング変更のためにディスクマッピング機構を起動する。先のステップ１８０２で予備の論理サーバをお発見できた場合は、ステップ１８０４のパーティション構成変更モジュールの起動を行わずにステップ１８０５に進む。

ここでステップ１８０２でもステップ１８０３でも該当するサーバの組を発見できなかった場合はフェイルオーバの動作を終了する。ただし、一般的にサーバが発見できなかった場合には、その旨を示す情報をユーザに通知するため、メッセージの表示やログへの出力を行う。

図１９は、パーティション構成変更モジュール３０５およびパーティション管理機構１１１の詳細シーケンスを示す。ステップ１９０１、１９０３はパーティション構成変更モジュール３０５の処理フロー、ステップ１９０２はパーティション管理機構１１１の処理フローである。ステップ１９０１でパーティション構成変更モジュール３０５は、サーバの組みを利用して、現用の論理サーバと同じパーティション構成を持つ論理サーバの構成をパーティション管理機構１１１に要求する。ステップ１９０２では、パーティション管理機構１１１が論理サーバの構成を実施する。ステップ１９０３では、パーティション構成変更モジュール３０５は構成した論理サーバを予備サーバとして設定する。

本発明における実施例３では、予備サーバの検索の際に、検索ポリシーを用いる例を示している。検索ポリシーによって、現用サーバと必ずしも予備サーバのハードウェア構成やパーティション構成が完全一致しない場合であっても業務の引き継ぎが可能な場合に対処できる。たとえば、CPU周波数やメモリ容量などは、多少の変化があってもソフトウェアは対応可能であるため、一致しなくても業務の引き継ぎは可能である。

図２０は、本発明における実施例３のサーバ検索モジュール３０３′を示す。実施例１および実施例２におけるサーバ検索モジュール３０３に対して、実施例３のサーバ検索モジュール３０３′は検索ポリシーテーブルを追加している。検索ポリシーテーブルは現用サーバに対して、予備サーバとして満たすべきポリシーが列挙される。このポリシーを満たすサーバであれば、現用サーバ対してハードウェア構成やパーティション構成が完全一致しない場合であっても、予備サーバとして利用することができる。カラム２００１は現用サーバのサーバ識別子を示している。カラム２００２は検索のポリシーを示している。ポリシーとしては、図２０に示すように、CPU周波数やメモリがある一定値以上である条件や、パーティション構成が不一致の場合でも業務に引き継ぎが可能とするなどの条件を設定可能である。サーバ検索モジュール３０３′では、予備サーバとするサーバの検索の際に、この検索ポリシーテーブルを参照する。検索ポリシーテーブルは、ユーザによって書き換えを可能とする。たとえば、GUIやコマンド、設定ファイルを提供し、検索ポリシーの指定を可能とする。

図２１は、本発明における実施例３のサーバ検索モジュール３０３′の処理フローを示す。実施例１および実施例２と異なるのは、ステップ２１０２において検索ポリシーを利用することである。ステップ２１０２では、サーバ検索モジュール３０３′は検索ポリシーテーブルの該当する現用サーバのポリシーを参照し、予備サーバの候補となるサーバをサーバ管理テーブル３０１から検索する。

本発明における実施例４では、システムに未使用のサーバが存在しない場合であっても、障害が発生した業務よりも優先度の低い業務から、サーバを融通することで業務を引き継ぐ方法を示す。
図２２は、本発明における実施例４のサーバ管理テーブルである。他の実施例と異なるのは、カラム４０７とカラム４０８である。カラム４０７では、サーバが稼動する業務の種類を示している。この例以外にも、業務の種類を示すものとして業務IDを利用しても良い。カラム４０８はカラム４０７の業務の優先度を示す。ここでは例として、高、中、低となっている。高であれば業務の優先度は高く、低であれば業務の優先度が低いことを示す。業務の優先度はユーザが指定する。指定方法としては、ユーザへのGUIやコマンドの提供や、設定ファイルなどである。

図２３は、本発明における実施例４のサーバ検索モジュールの処理フローである。他の実施例と異なるのは、ステップ２３０２である。ステップ２３０２では、未使用のサーバだけでなく、現用サーバが稼動していた業務より低い優先度の業務が稼動するサーバを含めて検索する。他の業務が稼動するサーバを予備サーバとする場合は、該当する業務からサーバを融通する。たとえば、図２３の例では、サーバ識別子S5で障害が発生した場合、S5の業務より優先度が低いS4のサーバを融通する。また、サーバを融通する業務が他のサーバを利用している場合は、その業務に対するスケールインまたはスケールダウンを実行しても良い。さらに、サーバが不足して予備の論理サーバが構成できない場合にも、他の業務から融通したサーバを利用して、論理サーバを構成可能である。また、サーバを融通する前に、融通するサーバで稼動していた業務を他のサーバへと引き継ぐ方法もある。たとえば、図２３においてS5の予備サーバをS4とする場合、先にS4の業務を未使用のS12に引き継ぎ、その後S5の業務をS4へと引き継ぐ。ここで、S4とS12はハードウェア構成が異なるが、実施例３で示した検索ポリシーによって業務の引き継ぎが可能であるものとしている。この動作は、本発明で記述しているフェイルオーバ処理を２回行ったことに等しい。

本発明における実施例５の全体図を図２４に示す。実施例１と異なるのは、ＦＣＳＷ１０４にＦＣＳＷ管理機構１４０とＮＷＳＷ１０５にＮＷＳＷ管理機構１５０が追加されていることである。ＦＣＳＷ管理機構１４０は、ＦＣＳＷの接続ポートごとやサーバ搭載のHBAのWWNごとにゾーンを分けることで、あるゾーンの属するサーバからは別のゾーンのディスクにアクセスできないようにするセキュリティ機能を制御する。ＮＷＳＷ管理機構１５０は、ＮＷＳＷの接続ポートやサーバ搭載のNICごとにVLAN IDを付与し、VLAN IDごとにネットワークを分離するセキュリティ機能を制御する。実施例５では、現用サーバと接続先のNWＳＷ１０４やディスクアレイ装置１０３が異なる場合や、サーバ間でＦＣＳＷ１０４のゾーンやＮＷＳＷ１０５のVLAN IDが異なる場合を考慮して、予備サーバの検索を可能とする。

図２５は、本発明における実施例５の管理サーバ１０１″の構成を示している。他の実施例と異なるのは、管理サーバ１０１″のフェイルオーバ機構１１０″にはＦＣＳＷ設定変更モジュール３０７とＮＷＳＷ設定変更モジュール３０８が追加されていることである。ＦＣＳＷ設定変更モジュール３０７は、予備サーバが現用サーバとゾーンが異なる場合に、ゾーンが一致するようにＦＣＳＷ管理機構１４０に対して設定変更を要求する機能モジュールである。ＮＷＳＷ設定変更モジュール３０８は、予備サーバが現用サーバとVLAN IDが異なる場合に、VLAN IDが一致するようにＮＷＳＷ管理機構１５０に対して設定変更を要求する機能モジュールである。ＦＣＳＷ設定変更モジュール３０７およびＮＷＳＷ設定変更モジュール３０８の動作タイミングは、サーバ検索モジュール３０３が予備サーバを発見した時点である。

図２６は、本発明における実施例５のサーバ管理テーブル３０１である。カラム４０９はサーバのチップセットの種類を示す。チップセットが一意に決まるのであれば、サーバのモデル名でも良い。現用サーバと予備サーバでチップセットが一致しない場合、業務の引き継ぎができない可能性があるため、このカラムによりチップセットの種類が一致するサーバを検索する。カラム４０９はサーバ搭載ＮＩＣのポート数を示す。カラム４１０はサーバ搭載のＨＢＡポート数を示す。カラム４０９およびカラム４１０は、現用サーバと予備サーバでI/Oポート数が一致しなければ業務の引き継ぎができない場合があるため、予備サーバの検索に利用する。カラム４１２はサーバが属するＶＬＡＮ ＩＤである。現用サーバと予備サーバでＶＬＡＮ ＩＤが一致しない場合であっても、予備サーバのＶＬＡＮ ＩＤをＮＷＳＷ設定変更モジュール３０８によって現用サーバと一致させることで、業務に引き継ぎが可能である。カラム４１３はサーバが属するゾーンの識別子である。現用サーバと予備サーバでゾーンが異なる場合であっても、予備サーバのゾーンをＦＣＳＷ設定変更モジュール３０７によって現用サーバと一致させることで、業務に引き継ぎが可能である。カラム４１４はサーバの接続先ＮＷＳＷを示す。現用サーバと予備サーバで接続先ＮＷＳＷが異なる場合は、業務の引き継ぎができない場合があるため、予備サーバの検索に本カラムを利用する。カラム４１５はサーバの接続先ディスクアレイ装置を示す。現用サーバと予備サーバで接続先ディスクアレイ装置が異なる場合は、現用サーバのブ
ートディスクが予備サーバからアクセスできないため、業務の引き継ぎができない。そこで、本カラムを予備サーバの検索に利用する。他にもサーバとディスクアレイ装置の接続先ポートの情報や、のディスクアレイ装置の接続先コントローラの情報をサーバ管理テーブル３０１に追加しても良い。

本特許のサーバ検索方法は、フェイルオーバだけでなく、負荷分散システムにおける業務のスケールアウトやスケールアップの対象とするサーバの検索にも適用できる。

１０１ 管理サーバ
１０２ サーバ
１０３ ディスクアレイ装置
１０４ ＦＣＳＷ
１０５ ＮＷＳＷ
１１０ フェイルオーバ機構
１２０ ＨＢＡ
１２１ ＮＩＣ
１２２ ＢＭＣ
１３０ ディスクマッピング機構
１３１ ディスク
１４０ パーティション機構。

Claims (9)

1. 複数のサーバがファイバチャネルスイッチを介してストレージに接続され、
   該サーバ間はネットワークスイッチを介して接続され、
   該サーバの各々は該ストレージからＯＳをブートすることで起動可能となる複数のサーバと、該複数のサーバを管理する管理サーバを有する計算機システムであって、
   該計算機システム内の他のサーバへと業務処理を引き継ぐ業務引き継ぎ方法において、
   前記管理サーバは、
   前記複数のサーバの接続先ネットワークスイッチ、および接続先ストレージを含むネットワーク構成情報と、前記サーバがブートに利用する仮想ディスクの識別子を含むディスク構成情報を保持し、
   複数のサーバのうちのあるサーバである第一サーバの利用するブート用の仮想ディスクの識別子を特定するステップと、
   前記ネットワーク構成情報に基づき、前記第一サーバに接続した前記ネットワークスイッチと同じネットワークスイッチに接続され、かつ第一のサーバに接続したストレージと同じストレージに接続された第二のサーバを特定するステップと、
   前記第一のサーバをシャットダウンするステップと、
   前記第一サーバのブートに利用する仮想ディスクの識別子に基づき、前記第二サーバの接続先ストレージに対して前記第二サーバから前記仮想ディスクへのアクセス許可を要求するステップと、
   前記第二のサーバを前記仮想ディスクからブートするように要求するステップを有することを特徴とする業務引き継ぎ方法。
2. 前記ネットワーク構成情報は、さらに前記サーバが接続されるネットワークスイッチのVLAN IDおよび/またはゾーニングの識別子を保持し、
   前記第二のサーバを特定するステップでは、前記第一のサーバと接続されるネットワークスイッチのVLAN IDおよび/またはゾーニングの識別子が同じである前記第二のサーバを特定することを特徴とする請求項１記載の業務引き継ぎ方法。
3. 前記ディスク構成情報は、前記第一サーバの備えるＷＷＮと、前記第一サーバの接続先ストレージにおいて前記ＷＷＮからのアクセスが許可された１つ以上の仮想ディスクの識別子を保持することを特徴とする請求項１記載の業務引き継ぎ方法。
4. 複数のサーバがファイバチャネルスイッチを介してストレージに接続され、
   該サーバ間はネットワークスイッチを介して接続され、
   該サーバの各々は該ストレージからＯＳをブートすることで起動可能となる複数のサーバと、
   該複数のサーバを管理する管理サーバを有する計算機システムにおいて、
   前記管理サーバは、
   前記複数のサーバの接続先ネットワークスイッチ、および接続先ストレージを含むネットワーク構成情報と、前記サーバがブートに利用する仮想ディスクの識別子を含むディスク構成情報を保持し、
   複数のサーバのうちのあるサーバである第一サーバの利用するブート用の仮想ディスクの識別子を特定する手段と、
   前記ネットワーク構成情報に基づき、前記第一サーバに接続した前記ネットワークスイッチと同じネットワークスイッチに接続され、かつ前記第一のサーバに接続したストレージと同じストレージに接続された第二のサーバを特定する手段と、
   前記第一のサーバをシャットダウンする手段と、
   前記第一サーバのブートに利用する仮想ディスクの識別子に基づき、前記第二サーバの接続先ストレージに対して前記第二サーバから前記仮想ディスクへのアクセス許可を要求する手段と、
   前記第二のサーバを前記仮想ディスクからブートするように要求する手段を有することを特徴とする計算機システム。
5. 前記ネットワーク構成情報は、さらに前記サーバが接続されるネットワークスイッチのVLAN IDおよび/またはゾーニングの識別子を保持し、
   前記第二のサーバを特定する手段では、前記第一のサーバと接続されるネットワークスイッチのVLAN IDおよび/またはゾーニングの識別子が同じである前記第二のサーバを特定することを特徴とする請求項４記載の計算機システム。
6. 前記ディスク構成情報は、前記第一サーバの備えるＷＷＮと、前記第一サーバの接続先ストレージにおいて前記ＷＷＮからのアクセスが許可された１つ以上の仮想ディスクの識別子を保持することを特徴とする請求項４記載の計算機システム。
7. 複数のサーバがファイバチャネルスイッチを介してストレージに接続され、
   該サーバ間はネットワークスイッチを介して接続され、
   該サーバの各々は該ストレージからＯＳをブートすることで起動可能となる複数のサーバを管理する管理サーバであって、
   他のサーバへ業務処理を引き継ぐ際に、
   前記管理サーバは、
   前記複数のサーバの接続先ネットワークスイッチ、および接続先ストレージを含むネットワーク構成情報と、前記サーバがブートに利用する仮想ディスクの識別子を含むディスク構成情報を保持し、
   複数のサーバのうちのあるサーバである第一サーバの利用するブート用の仮想ディスクの識別子を特定する手段と、
   前記ネットワーク構成情報に基づき、前記第一サーバに接続した前記ネットワークスイッチと同じネットワークスイッチに接続され、かつ前記第一サーバに接続したストレージと同じストレージに接続された第二のサーバを特定する手段と、
   前記第一のサーバをシャットダウンする手段と、
   前記第一サーバのブートに利用する仮想ディスクの識別子に基づき、前記第二サーバの接続先ストレージに対して前記第二サーバから前記仮想ディスクへのアクセス許可を要求する手段と、
   前記第二のサーバを前記仮想ディスクからブートするように要求する手段を有することを特徴とする管理サーバ。
8. 前記ネットワーク構成情報は、さらに前記サーバが接続されるネットワークスイッチのVLAN IDおよび/またはゾーニングの識別子を保持し、
   前記第二のサーバを特定する手段では、前記第一のサーバと接続されるネットワークスイッチのVLAN IDおよび/またはゾーニングの識別子が同じである前記第二のサーバを特定することを特徴とする請求項７記載の管理サーバ。
9. 前記ディスク構成情報は、前記第一サーバの備えるＷＷＮと、前記第一サーバの接続先ストレージにおいて前記ＷＷＮからのアクセスが許可された１つ以上の仮想ディスクの識別子を保持することを特徴とする請求項７記載の管理サーバ。

Images