JP2012048546A - 計算機システム、ｉ／ｏデバイス制御方法、及びｉ／ｏドロワ - Google Patents

Abstract

【課題】ハイパーバイザがＰＦとの間で必要な情報取得や設定を行える形で、ＳＲ−ＩＯＶデバイスを複数ブレードから共有可能とする。
【解決手段】複数のサーバ１５０Ａ〜Ｃと、Ｉ／Ｏデバイス１３０と、これらサーバとＩ／Ｏデバイスを接続するＩ／Ｏスイッチ１１０と、Ｉ／Ｏスイッチの管理を行うＩ／Ｏコントローラ１２０で構成され、Ｉ／Ｏデバイスは、１つ以上のＰＦ１３１を有し、Ｉ／Ｏコントローラは、Ｉ／ＯデバイスのＰＦにアクセスするマスターＰＦドライバ１２２を有し、各サーバはスレーブＰＦドライバ１６２Ａ〜Ｃを有し、これらスレーブＰＦドライバは、Ｉ／ＯデバイスのＰＦを利用するために、マスターＰＦドライバに要求を転送し、マスターＰＦドライバがスレーブＰＦドライバの代理としてＩ／ＯデバイスのＰＦにアクセスする。
【選択図】図１

Description

本発明は、複数の計算機を備えたブレードサーバ、ないしは計算機システムに関し、特に単一のＩ／Ｏデバイスを複数の計算機で共有する技術に関する。

計算機システムの集約性を高めるために、ブレードサーバや仮想化技術が用いられている。計算機システムの集約性を高めることは、消費電力削減、占有スペース削減、ないしは、管理の省力化につながり、計算機システムの導入コストと運用コストの削減に寄与する。

ブレードサーバは、プロセッサ(ＣＰＵ、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、主記憶装置（メモリ）、及び、ネットワークインタフェースカード（ＮＩＣ、Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）を搭載した複数のブレードと、ネットワークスイッチ、電源、及び、拡張用入出力（Ｉ／Ｏ、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）スロットを搭載したＩ／Ｏドロワが同一の筺体に格納された構成をとる。ブレードサーバでは、複数のブレードがネットワークスイッチ、電源、及び、Ｉ／Ｏドロワを共有することができるため、集約性が高まる。

仮想化技術は、サーバ上で仮想計算機モニタ（ＶＭＭ、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）やハイパーバイザを動作させることで、１台のサーバを論理的に分割して仮想計算機（ＶＭ、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）として運用するものである。なお、以降の説明では、ＶＭＭないしはハイパーバイザのことを、単にハイパーバイザと呼称する。仮想化技術により、１台のサーバ、ブレードを複数台のサーバとして使うことができるため、集約性が高まる。なお、ＶＭ上で動作するオペレーティングシステム（ＯＳ、Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のことを、ゲストＯＳと称する。

仮想化技術を適用したサーバでは、１台のサーバ上で複数のＶＭが稼働する。ＶＭが他のサーバと通信を行うためには、ＮＩＣを使う必要がある。複数のＶＭは各々別個にＮＩＣを使おうとするため、ＶＭの数と同数以上のＮＩＣをサーバに搭載する必要が生じる。このように、ＮＩＣをＶＭに直接割当てる方式を、直接Ｉ／Ｏ方式と称する。しかし、直接Ｉ／Ｏ方式では、サーバに搭載するＮＩＣの数が増加するため、コストや占有スペースの面で不利になる。

そこで、ハイパーバイザがＶＭに対して仮想ＮＩＣを提供する方式が用いられている（これ以降、仮想ＮＩＣ方式と呼称する）。仮想ＮＩＣ方式では、ソフトウェアによるエミュレーションでＶＭに対して仮想ＮＩＣを提供する。ＶＭは仮想ＮＩＣを用いて通信を行う。ハイパーバイザはサーバに装着されているＮＩＣを用いて、ＶＭから仮想ＮＩＣに要求された通信を実現する。この方式であれば、サーバが有するＮＩＣが１枚でも、複数のＶＭからの通信要求を処理することができる。そのため、直接Ｉ／Ｏ方式で問題となったコストや占有スペースの増大は回避できる。しかし、仮想ＮＩＣを提供するためのエミュレーションにＣＰＵ資源を消費してしまうことや、１０ ギガビット イーサネット（１０ＧｂＥ、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標））のように高速なネットワークではエミュレーションが追いつかなくなる等の問題が新たに生じる。

このような背景から、直接Ｉ／Ｏ方式で問題となっていたコストや占有スペースの問題を回避しつつ、仮想ＮＩＣ方式で問題となっていたＣＰＵ資源の消費も回避できる技術が望まれていた。この要求を実現する技術として、ＰＣＩ−ＳＩＧ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｅｃｔ−Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐ）で標準化が行われたＳＲ−ＩＯＶ（Ｓｉｎｇｌｅ Ｒｏｏｔ Ｉ／Ｏ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）やＭＲ−ＩＯＶ（Ｍｕｌｔｉ Ｒｏｏｔ Ｉ／Ｏ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）がある（例えば、特許文献１−３、非特許文献１等）。

特開２００５−３１７０２１号公報 特開２０１０−０７９８１６号公報 特開２００９−３０１１６２号公報

Ｓｉｎｇｌｅ Ｒｏｏｔ Ｉ／Ｏ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ ａｎｄ Ｓｈａｒｉｎｇ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｒｅｖｉｓｉｏｎ １．１、Ｃｈａｐｔｅｒ １、Ａｒｃｈｉｔｅｃｔｕｒａｌ Ｏｖｅｒｖｉｅｗ、第１１頁〜第２４頁、２００９年９月ＰＣＩ−ＳＩＧ発行

上述したＳＲ−ＩＯＶでは単一のサーバ上で動作する複数のＶＭが、単一のデバイスを共有するための技術を提供している。また、ＭＲ−ＩＯＶではＳＲ−ＩＯＶを拡張して、複数のサーバ上で動作する複数のＶＭが単一のデバイスを共有するための技術を提供している。

ＳＲ−ＩＯＶを適用することで、仮想ＮＩＣ方式のように性能を犠牲にすることなく、直接Ｉ／Ｏ方式よりサーバの集約性を高めることができる。ＭＲ−ＩＯＶを適用することで、ＳＲ−ＩＯＶよりもさらにサーバの集約性を高めることが出来る。しかし、ＭＲ−ＩＯＶに対応したデバイスが少ない、ないしは、高価であるといった問題があり、今日のサーバでは利用が広まっていない。

そこで、特許文献２、３に見るような、ＳＲ−ＩＯＶに対応したデバイス（以降、ＳＲ−ＩＯＶデバイス）を、ＭＲ−ＩＯＶの様に複数のサーバから共有するための技術が、これまでに提案されてきた。

特許文献２に記載の技術では、ＳＲ−ＩＯＶデバイスと複数のサーバの間をＩ／Ｏスイッチで接続することで、ＳＲ−ＩＯＶデバイスの共有を実現している。ＳＲ−ＩＯＶデバイスは単一のＰＦ（Ｐｈｙｓｉｃａｌ Ｆｕｎｃｔｉｏｎ）と複数のＶＦ（Ｖｉｒｔｕａｌ Ｆｕｎｃｔｉｏｎ）を有しており、ＶＦをＶＭに割当てることで、複数のＶＭが単一のＳＲ−ＩＯＶ共有デバイスを用いる。特許文献２に記載の技術では、ＶＦのブレードへの割当てを指定するＶＦ割当情報に従って、スイッチ内でルーティングを行うことで、ＶＦを単一ブレード上の複数ＶＭからのみならず、複数サーバ上の複数ＶＭから利用することを実現している。

ところで、ＳＲ−ＩＯＶデバイスはＶＦを複数個有しているため、ＶＦは複数ＶＭに直接割当てることができる。具体的には、ＳＲ−ＩＯＶデバイスを共用しようとするサーバ数と同数以上のＶＦをＳＲ−ＩＯＶデバイスが有している。しかし、ＰＦは通常１個、ないしは、サーバ数より少ない数しか存在しないことが多い。

ＳＲ−ＩＯＶではＰＦはハイパーバイザが利用することが想定されている。ハイパーバイザは、自身が生成するＶＭ数を元に必要となるＶＦ数を算出して、ＰＦが有するＳＲ−ＩＯＶ Ｃａｐａｂｉｌｉｔｙに設定を行う。また、ＶＦを利用する際に必要となる識別子である、Ｂｕｓ番号、Ｄｅｖｉｃｅ番号、及び、Ｆｕｎｃｔｉｏｎ番号も、ＰＦが有するＳＲ−ＩＯＶ Ｃａｐａｂｉｌｉｔｙに格納されている情報を読み出すことで算出する。このように、ハイパーバイザはＰＦを制御することで、ＳＲ−ＩＯＶデバイスのＶＦをＶＭに割当てるために必要な情報を取得する。

しかし、特許文献２に記載のように、ＶＦを複数サーバに割当てても、ＰＦはサーバ台数分存在しないため、ＶＦを割当てたサーバ全てにＰＦを割当てることが出来ない場合がある。特許文献の図２では、ＰＦを制御できるのはＰＦドライバを有するＰＣＩ−管理ＨＷのみである。このような場合、ハイパーバイザは、ＰＦを制御してＶＭへのＶＦの割当てに必要な情報取得や設定を行うことができない。そのため、ハイパーバイザとＰＦに対して、別途設定を行う必要が出てくる。そのためには、ハイパーバイザに外部から設定を行うためのインタフェースを用意するなど、ハイパーバイザの改造が必要となる。また、外部から設定の行う手間がかかり、管理コストを引き上げてしまう。

一方、特許文献３では、ハイパーバイザがＰＦと通信することを実現しつつ、ＳＲ−ＩＯＶデバイスを複数サーバで共有する技術について述べている。一般的に、サーバ上で動作するソフトウェアがデバイスにアクセスするためには、ドライバと呼ばれるソフトウェアを用いる。ＶＭ上で動作しているゲストＯＳには、ＶＦにアクセスするためのＶＦドライバが組み込まれる。同様に、ハイパーバイザはＰＦと通信するためにＰＦドライバを有している。

しかしながら、特許文献３記載の技術では、複数ブレードのうち１台をマスターブレード、残りをスレーブブレードとする。スレーブブレード上のＰＦドライバがデバイスにアクセスしようとすると、スレーブブレード上のハイパーバイザは、そのアクセスをトラップする。そして、スレーブブレード上のハイパーバイザはマスターブレード上のハイパーバイザに、トラップした内容を通知する。これにより、単一のＰＦを複数ブレードで共有することができる。しかし、この方法では、ハイパーバイザの改造が必要になってしまうという問題が依然として残る。さらに、ハイパーバイザがＰＦドライバの動作をトラップする必要があるため、性能低下を引き起こすという懸念が生じる。

また、特許文献３の図１に示されるように、マスターブレードとスレーブブレードが通信するためにネットワークを必要とするため、システムの構成が複雑化し、導入コストと運用コストを引き上げるという問題もある。

上記従来例のように、ＳＲ−ＩＯＶデバイスを複数ブレードで共有する技術はこれまでに提案されてきた。しかし、管理が煩雑になる、ないしは、ハイパーバイザの改造が必要になるなどの副作用が生じてきた。

本発明では、ハイパーバイザを改造することなく、かつ、ハイパーバイザがＰＦとの間で必要な情報取得や設定を行える形で、ＳＲ−ＩＯＶデバイスを複数ブレードから共有する手段を提供することを目的とする。

上記の目的を達成するため、本発明においては、Ｉ／Ｏドロワを介して１台以上のＩ／Ｏデバイスを利用する複数のサーバを備えた計算機システムであって、Ｉ／Ｏドロワは、複数のサーバとＩ／Ｏデバイスを接続するＩ／Ｏスイッチと、Ｉ／Ｏスイッチの管理を行うＩ／Ｏコントローラとを有し、Ｉ／Ｏデバイスは、少なくとも１つ以上の物理的な機能（以下、ＰＦ）を有し、複数のサーバのうちいずれか一つ、或いはＩ／Ｏコントローラは、ＰＦにアクセスするマスターＰＦドライバを有し、マスターＰＦドライバを有するサーバ以外の複数のサーバは、スレーブＰＦドライバを有し、スレーブＰＦドライバは、ＰＦを利用するためにマスターＰＦドライバに要求を転送し、要求を受けたマスターＰＦドライバがＰＦにアクセスする構成の計算機システムを提供する。

また、上記の目的を達成するため、本発明においては、Ｉ／Ｏデバイスを利用する複数のサーバと、複数のサーバとＩ／Ｏデバイスを接続するＩ／Ｏスイッチと、Ｉ／Ｏスイッチの管理を行うＩ／Ｏコントローラとを有する計算機システムのＩ／Ｏデバイス制御方法であって、Ｉ／Ｏデバイスに少なくとも１つ以上のＰＦを備え、複数のサーバのうちいずれか一つ、或いはＩ／Ｏコントローラに、ＰＦにアクセスするマスターＰＦドライバを備え、マスターＰＦドライバを有するサーバ以外の複数のサーバは、スレーブＰＦドライバを備え、スレーブＰＦドライバは、ＰＦを利用するためにマスターＰＦドライバに要求を転送し、要求を受けたマスターＰＦドライバはＰＦにアクセスする構成のＩ／Ｏデバイス制御方法を提供する。

更に、上記の目的を達成するため、本発明においては、複数のサーバが１台以上のＩ／Ｏデバイスを利用可能とするＩ／Ｏドロワであって、
複数のサーバとＩ／Ｏデバイスを接続するＩ／Ｏスイッチと記Ｉ／Ｏスイッチの管理を行うＩ／Ｏコントローラとを備え、Ｉ／Ｏスイッチは、複数のサーバとＩ／Ｏスイッチからアクセス可能なメールボックスを有する構成のＩ／Ｏドロワを提供する。

本発明は、少なくとも１つのＰＦを有するＩ／Ｏデバイスを複数のサーバで共用することが可能になる。特に、既存のハイパーバイザを利用して共有を実現できるという効果がある。

第１の実施例に係る計算機システムの全体構成を示すブロック図である。 第１の実施例に係る計算機システムにおいて、構成要素間のインタラクションを示す概念図である。 第１の実施例に係るＭＳＭＢの構成の一例を示すブロック図である。 第２の実施例に係る、計算機システムの全体構成を示すブロック図である。 第２の実施例に係るＭＩＲ（マスター役決定レジスタ）の構成の一例を示すブロック図である。 第２の実施例に係る、ＭＳ−ＰＦドライバ（マスター−スレーブ兼用ＰＦドライバ）が、マスター役サーバの障害を検出した際に、障害から回復するための動作手順を示したフローチャートである。 第１の実施例に係る、マスターＰＦドライバが、ＭＳＭＢ経由でスレーブＰＦドライバに要求を送信するための動作手順を示したフローチャートである。 第３の実施例に係る計算機システムの全体構成を示すブロック図である。 第１の実施例に係るマスターＰＦドライバの動作を説明するフローチャート図である。 第１の実施例に係るスレーブＰＦドライバの動作を説明するフローチャート図である。 第２の実施例に係るＭＳ−ＰＦドライバの動作を説明するフローチャート図である。

以下、本発明の一実施形態を添付図面に基づいて説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、同一の符号の繰り返しの説明は省略する。なお、本明細書において、ＰＦ（Ｐｈｙｓｉｃａｌ Ｆｕｎｃｔｉｏｎ）、ＶＦ（Ｖｉｒｔｕａｌ Ｆｕｎｃｔｉｏｎ）は、上述したＰＣＩ-ＳＩＧが公開したデバイスでの仮想化支援機能であるＳＲ−ＩＯＶにおけるものに対応する。

図１は、第１の実施例に係る計算機システムの全体構成を示す図である。図１の計算機システムは複数台のサーバ１５０Ａ〜Ｃ、Ｉ／Ｏドロワ１００、Ｉ／Ｏデバイス１３０から構成されている。ここで、Ｉ／Ｏデバイス１３０を、サーバ１５０Ａ〜Ｃで共用する。Ｉ／Ｏドロワ１００は、複数台のサーバ１５０Ａ〜ＣとＩ／Ｏデバイス１３０とを接続するＩ／Ｏスイッチ１１０と、Ｉ／Ｏスイッチ１１０を制御するＩ／Ｏコントローラ１２０を備えている。

Ｉ／Ｏデバイス１３０は例えばＮＩＣのような入出力を担う装置である。Ｉ／Ｏデバイス１３０は１個のＰＦ１３１、４個を例示した複数個のＶＦ１３２〜１３５、及び、Ｉ／Ｏデバイス内メールボックス（ＤＭＢ、Ｄｅｖｉｃｅ ＭａｉｌＢｏｘ）１３６で構成されている。ＤＭＢ１３６は、ＰＦ１３１を操作するＰＦドライバと、ＶＦ１３２〜１３５を操作するＶＦドライバ間が通信するための領域として使用される共用レジスタである。本実施例においては、後で詳述するように、ＰＦドライバには、マスターＰＦドライバとスレーブＰＦドライバがある。

サーバ１５０Ａ〜Ｃは、少なくとも一個の中央処理部からなるＣＰＵ１５１Ａ〜Ｃ、メモリ１５２Ａ〜Ｃ、入出力ハブ(ＩＯＨ、Ｉ／Ｏ Ｈｕｂ)１５４Ａ〜Ｃを有している。また、これらの構成部材は内部インターコネクト１５３Ａ〜Ｃで接続されている。内部インターコネクト１５３Ａ〜Ｃは、例えばハイパートランスポート（ＨＴ、ＨｙｐｅｒＴｒａｓｐｏｒｔ）のようなインタフェースが用いられる。よって、各々のサーバは通常の計算機構成を有していることになる。

サーバ１５０Ａ〜Ｃ上では、ハイパーバイザ１６１Ａ〜Ｃが動作しており、ＶＭを生成する。そのＶＭ上でゲストＯＳ１６０Ａ〜Ｃが動作する。ハイパーバイザ１６１Ａ〜Ｃは、本実施例で開示するスレーブＰＦドライバ１６２Ａ〜Ｃを有している。ゲストＯＳはＶＦドライバ１６３Ａ〜Ｃを有している。なお、ハイパーバイザ１６１Ａ〜Ｃ、ゲストＯＳ１６０Ａ〜Ｃ、スレーブＰＦドライバ１６２Ａ〜Ｃ、及び、ＶＦドライバ１６３Ａ〜ＣはいずれもＣＰＵで実行されるソフトウェアであるため、メモリ１５２Ａ〜Ｃ上に存在する。

Ｉ／Ｏデバイス１３０とＩ／Ｏスイッチ１１０間、及び、Ｉ／Ｏスイッチ１１０とＩＯＨ１５４Ａ〜Ｃの間は、ＰＣＩ−ＳＩＧが策定したＰＣＩ Ｅｘｐｒｅｓｓの規格に準拠したインタフェースで接続される。ＩＯＨ１５４Ａ〜Ｃは、ＣＰＵ１５１Ａ〜Ｃが発するＩ／Ｏデバイス１３０宛のメモリライト、ないしは、メモリリードを、ＰＣＩ Ｅｘｐｒｅｓｓのパケットに変換する。また、ＩＯＨ１５４Ａ〜Ｃは、Ｉ／Ｏデバイス１３０から発せられたパケットを受け取り、メモリ１５２Ａ〜Ｃを読書きする。

上述の通り、Ｉ／Ｏドロワ１００は、サーバ１５０Ａ〜ＣにＩ／Ｏデバイス１３０を接続するための装置である。Ｉ／ＯドロワはＩ／Ｏスイッチ１１０とＩ／Ｏコントローラ１２０から構成される。

Ｉ／Ｏスイッチ１１０は、Ｉ／Ｏサーバ１５０Ａ〜ＣとＩ／Ｏデバイス１３０の間でパケットを転送するスイッチである。また、Ｉ／Ｏスイッチ１１０は本実施例で開示するマスター−スレーブ間通信用の記憶領域として使用されるマスター−スレーブ間通信用メールボックス（ＭＳＭＢ、Ｍａｓｔｅｒ−Ｓｌａｖｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＭａｉｌＢｏｘ）１１１を有する。

なお、Ｉ／Ｏドロワ１００内でＩ／Ｏスイッチ１１０を制御するＩ／Ｏコントローラ１２０は、サーバ１５０Ａ〜Ｃと同様に、図示を省略したＣＰＵやメモリで構成される。一般的には、ＣＰＵやメモリが１チップに集積されたマイクロコントローラが用いられる。同図に示すように、Ｉ／Ｏコントローラ１２０上では、Ｉ／Ｏスイッチ１１０を制御するためのソフトウェアであるＩ／Ｏスイッチ制御ソフトウェア１２１、及び、本実施例で開示するマスターＰＦドライバ１２２が動作する。

Ｉ／Ｏコントローラ１２０とＩ／Ｏスイッチ１１０間の接続も、ＰＣＩ Ｅｘｐｒｅｓｓ規格に準拠したインタフェースで接続される。なお、Ｉ／Ｏスイッチ１１０とＩ／Ｏコントローラ１２０を同一のＬＳＩや基板上に構成する場合には、独自規格のインタフェースを用いることもできる。

図２は、第１の実施例の計算機システムにおいて、サーバ１５０Ａ〜Ｃ及びＩ／Ｏコントローラ１２０上で動作しているソフトウェアと、Ｉ／Ｏデバイス１３０の間でのインタラクションを示した概念図である。同図において、破線Ｐ２０１〜Ｐ２０６は、破線の両端にある二者間でインタラクションがあることを示している。

ＶＦドライバ１６３Ａ〜Ｃは、ゲストＯＳ１６０Ａ〜Ｃの要求に応じて通信を行うために、ＶＦ１３２〜１３４にアクセスする（破線Ｐ２０１Ａ〜Ｃ）。これにより、仮想ＮＩＣ方式のようにエミュレーションのためのオーバヘッドを生じることなく、複数サーバ上の複数ＶＭから単一のＳＲ−ＩＯＶデバイスを共有することができる。

Ｉ／Ｏコントローラ１２０で動作するマスターＰＦドライバ１２２は、Ｉ／Ｏデバイス１３０の全体制御を行うために、ＰＦ１３１にアクセスする。ＰＦ１３１にアクセスすることが出来るのは、図１及び図２に示されている第１の実施例に係る計算機システムの中で、唯一マスターＰＦドライバ１２２のみである。

ＶＦドライバ１６３Ａ〜Ｃは、ＶＦ１３２〜１３４にアクセスすることで通信に必要な動作を実現するが、Ｉ／Ｏデバイス１３０全体に関わる一部の動作や設定は、ＰＦ１３１にアクセスしなければならない場合がある。例えば、ＮＩＣではメディアアクセスコントロール(ＭＡＣ、Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスの設定などがＰＦ１３１の所管となっている場合がある。そこで、本実施例の計算機システムにおいては、ＶＦドライバ１６３Ａ〜Ｃは、ＤＭＢ１３６を経由してマスターＰＦドライバ１２２に設定を要求する（Ｐ２０２Ａ〜Ｃ、Ｐ２０３）。マスターＰＦドライバ１２２は、ＶＦドライバ１６３Ａ〜Ｃから要求された動作や設定を実現するために、ＰＦ１３１にアクセスする（Ｐ２０４）。

ＶＦドライバとＰＦドライバ間の通信手段はＳＲ−ＩＯＶの規格で定められているわけではないが、ＤＭＢ１３６のようなデバイス内の共有レジスタで構成されるメールボックスを用いている場合が多い。本実施の形態では、マスターＰＦドライバ１２２とＶＦドライバ１６３Ａ〜Ｃの間の通信手段として、ＤＭＢ１３６を流用している。

スレーブＰＦドライバ１６２Ａ〜Ｃは、ハイパーバイザ１６１Ａ〜Ｃに組み込まれるＰＦドライバである。ハイパーバイザ１６１Ａ〜Ｃから見ると、スレーブＰＦドライバ１６２Ａ〜Ｃは、従来のＰＦドライバと区別がつかない。ハイパーバイザ１６１Ａ〜Ｃは、ＰＦに対する設定、例えばＳＲ−ＩＯＶ Ｃａｐａｂｉｌｉｔｙの設定などを行う時、スレーブＰＦドライバ１６２Ａ〜Ｃに依頼する。スレーブＰＦドライバ１６２Ａ〜Ｃは、ハイパーバイザ１６１Ａ〜Ｃからの要求を満たすために必要な操作を、直接ＰＦ１３１に対して行うことはしない。その代りに、ＭＳＭＢ１１１を経由してマスターＰＦドライバ１２２に設定を要求する（Ｐ２０５Ａ〜Ｃ、Ｐ２０６）。マスターＰＦドライバ１２２は、スレーブＰＦドライバ１６２Ａ〜Ｃに要求された動作や設定を実現するために、ＰＦ１３１にアクセスする（Ｐ２０４）。なお、マスターＰＦドライバ１２２とスレーブＰＦドライバ１６２Ａ〜Ｃの具体的構成の一例を、後で図９、図１０を用いて説明する。

図３は、第１の実施例に係る、Ｉ／Ｏスイッチ１１０内のＭＳＭＢ１１１の一例の詳細な構成を示すブロック図である。ＭＳＭＢ１１１は、マスターＰＦドライバ１２２がアクセス可能な記憶領域であるレジスタ（これ以降、マスター側レジスタと呼称する）３１０、スレーブＰＦドライバ１６２Ａ〜Ｃがアクセス可能な記憶領域であるレジスタ（これ以降、スレーブ側レジスタと呼称する）３２０Ａ〜Ｄ、利用権調停部３４０Ａ〜Ｄ、割込み発生部３３０から構成される。

マスター側レジスタ３１０は、マスターＰＦドライバ１２２がアクセスするものなので、その個数は１個である。一方、スレーブ側レジスタ３２０Ａ〜Ｄは、システム全体に含まれるスレーブＰＦドライバ１６２Ａ〜Ｃの個数と同数以上必要となる。図１の計算機システムの例では、サーバ１５０Ａ〜Ｃの３台でそれぞれハイパーバイザ１６１Ａ〜Ｃが動作しているために、スレーブＰＦドライバ１６２Ａ〜Ｃは３個である。そのため、スレーブ側レジスタは最低３個必要である。

図１の計算機システムではＩ／Ｏデバイス１３０は４個のＶＦ１３２〜１３５を有しているため、最大で４台のサーバがＩ／Ｏデバイス１３０を共有することができる。その場合には、スレーブＰＦドライバはシステム全体で４個存在することになるため、この値に合わせて図３のＭＳＭＢ１１１では４個のスレーブ側レジスタ３２０Ａ〜Ｄを有している。そのため、図１に示した第１の実施例に係る計算機システムでは、スレーブ側レジスタ３２０Ｄは使われることなく余る。

本実施例においてＭＳＭＢ１１１は、マスターＰＦドライバ１２２がスレーブＰＦドライバ１６２Ａ〜Ｃに要求を送る、もしくは逆にスレーブＰＦドライバ１６２Ａ〜ＣがマスターＰＦドライバ１２２に要求を送るために用いられる。そのため、要求を伝えるためのメッセージバッファ３１４Ａ〜Ｄ、３２４Ａ〜Ｄを備えている。マスター側レジスタのメッセージバッファ３１４Ａ〜Ｄと、スレーブ側レジスタのメッセージバッファ３２４Ａ〜Ｄは、それぞれ同じ記憶領域を共有している。例えば、メッセージバッファ３１４Ａに書いた内容は、メッセージバッファ３２４Ａから読み出せる。また、メッセージバッファ３１４Ｂに書いた内容を、メッセージバッファ３１４Ｂから読み出すこともできる。このような共有領域で、マスターＰＦドライバ１２２とスレーブＰＦドライバ１６２Ａ〜Ｃは要求を互いに送受する。

メッセージバッファ３１４Ａ〜Ｃ、３２４Ａ〜Ｄを用いて要求の送受を行うためには、当該メッセージバッファに書込む権利（利用権）をマスター側とスレーブ側で調停しなければならない。そのために、ＭＳＭＢ１１１は、マスター利用権フラグ３１１Ａ〜Ｄ、スレーブ利用権フラグ３２１Ａ〜３２１Ｄ、及び、利用権調停部３４０Ａ〜Ｄを有する。

マスター利用権フラグ３１１Ａ〜Ｄは、その内容が１であるときに、マスター側のマスターＰＦドライバ１２２がメッセージバッファに書込む権利を有している事を示す。なお、初期値は利用権を有しないことを示す０とする。また、スレーブ利用権フラグ３２１Ａ〜Ｄも同様に、その内容が１であるときに、スレーブ側のスレーブＰＦドライバ１６２Ａ〜Ｃがメッセージバッファを書込む権利を有していることを示す。こちらも、その初期値は利用権を有しないことを示す０である。また、マスター側とスレーブ側の利用権は排他的でなければならない。すなわち、マスター利用権フラグ３１１Ａが１であるときには、スレーブ利用権フラグ３２１Ａは必ず０である。

利用権調停部３４０Ａ〜Ｄは、マスター利用権フラグ３１１Ａ〜Ｄ、ないしは、スレーブ利用権フラグ３２１Ａ〜Ｄに対して、マスターＰＦドライバ１２２、ないしは、スレーブＰＦドライバ１６２Ａ〜Ｃが１を書込もうとした時に、前述した利用権の排他性が保たれる時に限って１の書込みを許し、そうでない場合には１を書込ませない。例えば、マスターＰＦドライバ１２２がマスター利用権フラグ３１１Ａに１を書込む時に、スレーブ利用権フラグ３２１Ａの内容が０であれば書込むことができる。スレーブ利用権フラグ３２１Ａの内容が１の時には、マスター利用権フラグ３１１Ａへの書込みは無視され、マスター利用権フラグ３１１Ａの内容は初期値の０のままである。

マスターＰＦドライバ１２２、ないしは、スレーブＰＦドライバ１６２Ａ〜Ｄは、メッセージバッファの利用権を得てメッセージバッファに要求を書き込んだ後、相手に対して要求を書込んだことを伝える必要がある。そのために、ＭＳＭＢ１１１は要求ドアベル３１２Ａ〜Ｄ、３２２Ａ〜Ｄと、割込み発生部３３０を有する。

要求ドアベル３１２Ａ〜Ｄ、３２２Ａ〜ＤがマスターＰＦドライバ１２２、ないしは、スレーブＰＦドライバ１６２Ａ〜Ｄによって読み出されると、割込み発生部は対応する相手に割込みを発生させる（以降、要求割込みと呼称する）。割込みはＰＣＩ Ｅｘｐｒｅｓｓではメモリへの書込みと同様にパケットで表現される。例えば、スレーブＰＦドライバ１６２ＡがマスターＰＦドライバ１２２に要求を発したい場合、要求ドアベル３２２Ａを読み出す。割込み発生部３３０は要求ドアベル３２２Ａが読みだされると、マスターＰＦドライバ１２２に対して割込みを発生させる。なお、要求ドアベル３２２Ａの読出し結果としては、割込み発生成功を示す１、ないしは、割込み発生失敗を示す０が得られる。

割込み要求を受けたマスターＰＦドライバ１２２、ないしは、スレーブＰＦドライバ１６２Ａ〜Ｄは、メッセージバッファ３１４Ａ〜Ｄ、３２４Ａ〜Ｄの内容を読み出して要求を受け付ける。その後、要求を完了した旨を要求元に伝えるための手段として、ＭＳＭＢ１１１は応答ドアベル３１３Ａ〜Ｄ、３２３Ａ〜Ｄを有する。応答ドアベル３１３Ａ〜Ｄ、３２３Ａ〜Ｄは、要求ドアベル３１２Ａ〜Ｄ、３２２Ａ〜Ｄと同様に、相手に対して割込みを発生させるためのドアベルである。割込み発生部３３０は、要求ドアベルに起因する割込みと応答ドアベルに起因する割込みで異なる割込み要因を使って割込みをかける（以降、応答ドアベルに起因する割込みを、応答割込みと呼称する）。これにより、マスターＰＦドライバ１２２、ないしは、スレーブＰＦドライバ１６２Ａ〜Ｄは自分に対して相手から要求が来たのか、自分が発した要求に対する応答が来たのかを区別することができる。

図７を用いて、第１の実施例に係る計算機システムにおいて、マスターＰＦドライバ１２２、ないしは、スレーブＰＦドライバ１６２Ａ〜Ｄが要求を相手に送信する手順を示す。なお、図７はマスターＰＦドライバ１２２がスレーブＰＦドライバ１６２Ａ〜Ｄに要求を送信する手順（以降、マスター発要求と呼称する）であるが、スレーブＰＦドライバ１６２Ａ〜ＤがマスターＰＦドライバ１２２に要求を送信する手順（以降、スレーブ発要求と呼称する）も基本的な手順は同じなので、図７に補足する形で説明する。

図７のステップＳ７０１では、マスター側レジスタ３１０のメッセージバッファ３１４Ａ〜Ｄの利用権を得るために、マスター利用権フラグ３１１Ａ〜Ｄに１を書込む。スレーブ発要求の場合には、メッセージバッファ３２４Ａ〜Ｄの利用権を得るために、スレーブ利用権フラグ３２１Ａ〜Ｄに１を書込む。

ステップＳ７０２では、利用権を得られたかどうかを確認するためにマスター利用権フラグ３１１Ａ〜Ｄを読み出す。１が読みだせれば利用権が得られたものとして、ステップＳ７０３に進む。０が読みだされた場合、利用権を得られていないので、利用権が得られるまでＳ７０１を繰り返す。なお、スレーブ発要求の場合には、スレーブ利用権フラグ３２１Ａ〜Ｄを読み出す。

ステップＳ７０３では、メッセージバッファ３１４Ａ〜Ｄに要求を示すメッセージを書込む。なお、スレーブ発要求の場合には、メッセージバッファ３２４Ａ〜Ｄに書込む。

ステップＳ７０４では、ステップＳ７０３で要求を書込んだことをスレーブＰＦドライバ１６２Ａ〜Ｄに通知するために、要求ドアベル３１２Ａ〜Ｄで要求割込みを発生させる。なお、スレーブ発要求の場合にはマスターＰＦドライバ１２２に通知するために、要求ドアベル３２２Ａ〜Ｄで要求割込みを発生させる。

ステップＳ７０５では、自身が発した要求に対して、相手からの応答を示す応答割込みを待つ。すなわち、スレーブＰＦドライバ１６２Ａ〜Ｄが、応答ドアベル３２３Ａ〜Ｄで発生させる応答割込みを待つ。なお、スレーブ発要求の場合には、マスターＰＦドライバ１２２が、応答ドアベル３１３Ａ〜Ｄで発生させる応答割込みを待つ。

ステップＳ７０６では、メッセージバッファ３１４Ａ〜Ｄの利用権を解放するために、マスター利用権フラグ３１１Ａ〜Ｄに０を書込む。なお、スレーブ発要求の場合にはメッセージバッファ３２４Ａ〜Ｄの利用権を解放するために、スレーブ利用権フラグ３２１Ａ〜Ｄに０を書込む。

以上、本実施例の計算機システムにおいて、ステップＳ７０１〜Ｓ７０６で、マスターＰＦドライバ１２２がスレーブＰＦドライバ１６２Ａ〜Ｄに要求を送信すること、ないしは、スレーブＰＦドライバ１６２Ａ〜ＤがマスターＰＦドライバ１２２に要求を送信することが出来る。

続いて、本実施例に利用されるマスターＰＦドライバ１２２とスレーブＰＦドライバ１６２Ａ〜Ｃの一具体例について説明する。上述したとおり、マスターＰＦドライバ１２２は、Ｉ／Ｏコントローラ１２０を構成するＣＰＵで実行されるプログラムで実現され、スレーブＰＦドライバ１６２Ａ〜Ｃは各サーバ１５０Ａ〜Ｃのハイパーバイザ１６１Ａ〜Ｃに組み込まれる、言い換えるならハイパーバイザ１６１Ａ〜Ｃ上で動作するプログラムとして実現される。

図９のフローチャートに基づき、本実施例のマスターＰＦドライバ１２２の具体的動作の一例を説明する。マスターＰＦドライバ１２２は，Ｉ／Ｏコントローラ１２０上で起動する際に，図９に示す動作を行う。

ステップＳ９０１では，マスターＰＦドライバ１２２はＩ／Ｏデバイス１３０上のＰＦ１３１からデバイスに関する情報を読み出す。デバイスに関する情報とは，例えばＩ／Ｏデバイス１３０が有するＶＦ１３２〜１３５の個数や，デバイス全体に共通するパラメータである。

次に，ステップＳ９０２では，ステップＳ９０１で得られたＩ／Ｏデバイス１３０に関する情報と，計算機システム全体の構成情報を元に，Ｉ／Ｏデバイス１３０に対する初期設定を，ＰＦ１３１に書込む。初期設定の内容としては，例えば使用するＶＦの個数や，ＮＩＣであればＭＡＣアドレスの設定などがある。

ステップＳ９０１〜ステップＳ９０２までの段階で，Ｉ／Ｏデバイス１３０のＰＦ１３１及びＶＦ１３２〜１３５の使用が可能となるので，これ以降，サーバ１５０Ａ〜Ｃを順次起動して，各々のサーバがＩ／Ｏデバイス１３０のＶＦ１３２〜１３５を使い始める。各々のサーバ上では、以降で説明するスレーブＰＦドライバ１６２Ａ〜Ｃや，ＶＦドライバ１６３Ａ〜Ｃが動作する。

マスターＰＦドライバ１２２は，自身が動作しているＩ／Ｏコントローラ１２０，スレーブＰＦドライバ１６２Ａ〜Ｃ，ないしは，ＶＦドライバ１６３Ａ〜Ｃの何れかから要求を受けて，Ｉ／Ｏデバイス１３０に対して設定を行ったり，情報を読み出したりする。そのために，ステップＳ９０３でマスターＰＦドライバ１２２はこれらの要求を待っている。

これらの要求は割込みとしてマスターＰＦドライバ１２２に伝達されるため，割込み要因を分析して要求元を割り出す必要がある。ステップＳ９０４でＶＦドライバ１６３Ａ〜Ｃからの要求であることが分かると，要求の委細を知るために，ステップＳ９０８でＩ／Ｏデバイス１３０内のＤＭＢ１３６を読み出す。ステップＳ９０５でスレーブＰＦドライバ１６２Ａ〜Ｃからの要求であると判定された場合も同様に，要求の委細を知るために，ステップＳ９０７でＩ／Ｏスイッチ１１０内のＭＳＭＢ１１１を読み出す。

なお，ＶＦドライバ１６３Ａ〜Ｃ，ないしは，スレーブＰＦドライバ１６２Ａ〜Ｃのどちらからの要求でもない場合には，Ｉ／Ｏコントローラ１２０からの要求であるため，ステップＳ９０６でＩ／Ｏコントローラ１２０とマスターＰＦドライバ１２２の間で定められたＡＰＩを用いて要求の委細を得る。例えば，Ｉ／Ｏコントローラ１２０がオペレーティングシステムＬｉｎｕｘ（Ｌｉｎｕｘは登録商標）で動作している場合には，このＡＰＩはＬｉｎｕｘのドライバ向けに提供されているＡＰＩとなる。

ステップＳ９０６〜Ｓ９０８のいずれかで要求の委細をマスターＰＦドライバ１２２は知ることが出来たので，マスターＰＦドライバ１２２は、ステップＳ９０９で当該要求を実現するための処理を行う。この処理は先に説明したように、本実施例においては、Ｉ／Ｏデバイス１３０のＰＦ１３１に対する設定や情報読出し，ＭＳＭＢ１１１，ＤＭＢ１３６，ないしは，前記のＡＰＩを用いた通信によって実現できる。

次に、図１０のフローチャートに基づき、本実施例のスレーブＰＦドライバ１６２Ａ〜Ｃの具体的動作の一例を説明する。前述した通り，マスターＰＦドライバ１２２が起動した後に，スレーブＰＦドライバ１６２Ａ〜Ｃは起動する。

まず，同図において、ステップＳ１００１で既に起動済みのマスターＰＦドライバ１２２から，Ｉ／Ｏデバイス１３０に関する情報を取得する。スレーブＰＦドライバ１６２Ａ〜Ｃは取得した情報のうち，ハイパーバイザ１６１Ａ〜Ｃが必要とするものに関しては，ハイパーバイザ１６１Ａ〜ＣとスレーブＰＦドライバ１６２Ａ〜Ｃの間で定められたＡＰＩを用いて，ハイパーバイザ１６１Ａ〜Ｃに渡す。

その後，マスターＰＦドライバ１２２の場合と同様に，ステップＳ１００２で要求待ちに入る。なお，スレーブＰＦドライバ１６２Ａ〜Ｃは，ハイパーバイザ１６１Ａ〜Ｃ，ないしは，マスターＰＦドライバ１２２から要求を受ける可能性がある。スレーブＰＦドライバ１６２Ａ〜Ｃ間で直接的に要求が行われることは無く，必ずマスターＰＦドライバ１２２を介在する。また，ＶＦドライバ１６３Ａ〜ＣからスレーブＰＦドライバ１６２Ａ〜Ｃに直接的に要求が行われることも無く，必ずマスターＰＦドライバ１２２を介在する。

よって，ステップＳ１００３でマスターＰＦドライバ１２２からの要求であると判定できたら，ステップＳ１００５で図３のＭＳＭＢ１１１を読み出して，マスターＰＦドライバ１２２からの要求内容を得る。そうでなければ，ハイパーバイザ１６１Ａ〜Ｃからの要求であるため，上述したＡＰＩで要求内容を得る。

ステップＳ１００６では，これらの要求内容を実現するための処理を行う。スレーブＰＦドライバ１６２Ａ〜Ｃは，直接Ｉ／Ｏデバイス１３０のＰＦ１３１，ないしは，ＶＦ１３２〜１３５にアクセスすることはしない。その代りに，ハイパーバイザ１６１Ａ〜ＣへＡＰＩで要求すること，ないしは，マスターＰＦドライバ１２２にＭＳＭＢ１１１を経由して要求することで，前記の処理を実現する。

すなわち，本実施例のスレーブＰＦドライバ１６２Ａ〜Ｃは，ハイパーバイザ１６１Ａ〜Ｃからの要求をＭＳＭＢ１１１経由でマスターＰＦドライバ１２２に転送すること，ないしは，マスターＰＦドライバ１２２からの要求を前記ＡＰＩ経由でハイパーバイザ１６１Ａ〜Ｃに転送することを行う。

以上説明した通り、本実施例では、ＰＦドライバとＩ／Ｏスイッチに新規な構成を導入することにより課題の解決を図る。ＰＦドライバはハイパーバイザに組み込んで利用するものであり、デバイス毎に開発が必要であることから、ＰＦドライバを開発するために必要な環境は既に整えられており、本実施例における新規な処理をＰＦドライバに組み込むことは容易であり、ハイパーバイザの改造必要性や、導入コスト、ないしは、運用管理コストの増大を抑えることが出来る。

図４は、第２の実施例に係る計算機システムの全体構成を示す図である。図４に示す第２の実施例の計算機システムでは、Ｉ／Ｏコントローラ１２０にマスターＰＦドライバ１２２を搭載する代わりに、全てのサーバ１５０Ａ〜Ｃに本実施例で開示するＭａｓｔｅｒ／Ｓｌａｖｅ兼用ＰＦドライバ（これ以降、ＭＳ−ＰＦドライバと呼称する）４６２Ａ〜Ｃを搭載する。

ＭＳ−ＰＦドライバ４６２Ａ〜Ｃは、マスターＰＦドライバとスレーブＰＦドライバを兼ねるドライバであり、起動時にマスターＰＦドライバないしは、スレーブＰＦドライバのどちらとして動作するかを決定する。なお、本明細書において、ＭＳ−ＰＦドライバがマスターＰＦドライバとして動作していることをマスターモードと、ＭＳ−ＰＦドライバがスレーブＰＦドライバとして動作していることをスレーブモードと呼称する。このＭＳ−ＰＦドライバの具体的構成の一例は後で詳述する。

第１の実施例では、Ｉ／Ｏコントローラ１２０上でマスターＰＦドライバ１２２を動作させていた。しかし、マスターＰＦドライバ１２２は一点故障の要因となりうる。そのため、高信頼化を図るためには、Ｉ／Ｏコントローラ１２０を冗長構成にする必要がある。それに対して、本実施例では、マスターＰＦドライバとスレーブＰＦドライバの両方として機能し得るＭＳ−ＰＦドライバをサーバ１５０Ａ〜Ｃ上で動作させることにより冗長構成を実現する。

すなわち、図４の計算機システム上のサーバ１５０Ａ〜Ｃのうち、１台のサーバでマスターＰＦドライバ、すなわちマスターモードのＭＳ−ＰＦドライバを動作させ、その他のサーバではスレーブＰＦドライバ、すなわち、スレーブモードのＭＳ−ＰＦドライバを動作させる。そして、マスターＰＦドライバを動作させているサーバが故障した時は、スレーブＰＦドライバが動作しているその他のサーバのうち１台がマスターＰＦドライバとしての役割を引継ぐ。そのために、本実施例の計算機システムにあっては、マスターＰＦドライバとしても、スレーブＰＦドライバとしても動作することのできるＭＳ−ＰＦドライバ４６２Ａ〜Ｃを新規に導入する構成としている。

本実施例において、図４中のＭＳ−ＰＦドライバ４６２Ａ〜Ｃのうち、どのＭＳ−ＰＦドライバがマスターモードになるかの割当て方針の一例を以下に示す。マスターモードのサーバが不在になった時には、稼働中のサーバの中で、サーバの番号が一番若いサーバ上のＭＳ−ＰＦドライバがマスターモードとなり、それ以外のサーバ上のＭＳ−ＰＦドライバはスレーブモードとして動作することとする。

マスターモードとスレーブモードの切替えは、マスターモードのサーバが不在になった時に行われるので、稼働中のサーバのうち一番若いサーバ番号のサーバが常にマスターモードだとは限らない。例えば、サーバ１５０Ａ（サーバ番号＃０）がマスターモードで稼働し、サーバ１５０Ｂ（サーバ番号＃１）がスレーブモードで稼働している時に、サーバ１５０Ａに障害が発生すると、マスターモードのサーバが不在となるため、前述した切替えによりサーバ１５０Ｂがマスターモードに切り替わる。その後、サーバ１５０Ａの障害を復旧して立ち上げると、一番サーバ番号が若いサーバはサーバ１５０Ａとなるが、マスターモードのサーバは不在ではないので、言いかえるならサーバ１５０Ｂがマスターモードとして動き続けているので、マスターモードとスレーブモードの切替えは発生しない。

マスターモードとなるサーバの決定、及び、マスターモードとなっているサーバに障害が発生した時に、次なるマスター役のサーバに処理を引き継ぐための機構として、本実施例ではＩ／Ｏスイッチ１１０内にマスター役決定領域として機能するマスター役決定レジスタ（ＭＩＲ、Ｍａｓｔｅｒ Ｉｄｅｎｔｉｆｙ Ｒｅｇｉｓｔｅｒ）４１２を導入する構成とする。

図５に本実施例おいて用いられるＭＩＲの一具体例を示した。同図に見るように、本実施例におけるＭＩＲ４１２は、サーバ可用性フラグ５１０〜５１３、マスター役サーバ番号レジスタ５２０、マスタースナップショットレジスタ５３０、マスター役交替要求ドアベル５４０から構成される記憶領域であり、Ｉ／Ｏスイッチ１１０内に形成される。

サーバ可用性フラグ５１０〜５１３は、各サーバが利用可能であるかどうかを示す。例えば、サーバ可用性フラグ５１０はサーバ１５０Ａ（サーバ番号＃０）の可用性を示す。なお、サーバ可用性フラグ５１０が１の時は当該サーバが利用可能であることを示し、フラグが０の時は当該サーバが利用不可能であることを示す。電源投入直後の初期値は０である。サーバ１５０Ａ〜Ｃは起動後に各々に対応するサーバ可用性フラグ５１０〜５１３を１にセットする。また、シャットダウン等サーバが利用不可能になる前には、サーバ可用性フラグ５１０〜５１３を０にクリアする。サーバ１５０Ａ〜Ｃに障害が発生して利用不可能になった場合には、障害を検出したサーバ、ないしは、図示していない管理系システムがサーバ可用性フラグ５１０〜５１３を０にクリアする。

例えば、スレーブモードで動いているＭＳ−ＰＦドライバが、マスターモードで動作しているＭＳ−ＰＦドライバに対してＭＳＭＢ１１１経由で設定等の要求を出した後、一定時間以内に応答が返ってこない場合には、タイムアウトとしてマスターモードで動作しているＭＳ−ＰＦドライバに対応するサーバに障害が発生したものと見做す。その時は、タイムアウトを検出したＭＳ−ＰＦドライバが、当該サーバに対応するサーバ可用性フラグ５１０〜５１３を０にクリアする。その後、マスター役が不在になったため、マスター役の交替が必要であることをＭＳ−ＰＦドライバが動作している全サーバに知らせる。

図５のＭＩＲ４１２中のマスター役サーバ番号レジスタ５２０は、ＭＳ−ＰＦドライバがマスターモードで動作しているサーバのサーバ番号を示すレジスタである。上述した通り、図２で説明したように、ＭＳＭＢ１１１のマスター側レジスタ３１０を使うことができるのは、マスター役サーバ番号レジスタ５２０で示されているサーバだけである。また、マスター役の切替えによって、新たにマスター役となったサーバは、自らのサーバ番号をマスター役番号レジスタ５２０に書込む。また、マスター役サーバ番号レジスタ５２０に値が書込まれると、マスター役が交替したことを示す割込みを全てのサーバ１５０Ａ〜Ｃに対してかける（以降、この割込みをマスター役交替完了割込みと呼称する）。

マスタースナップショット記憶領域であるマスタースナップショットレジスタ５３０は、サーバ障害時にマスター役を切り替えるために、マスターモードで動作しているＭＳ−ＰＦドライバの内部状態を保存するためのレジスタである。マスターモードで動作しているＭＳ−ＰＦドライバは、内部状態を随時マスタースナップショットレジスタ５３０に保存するよう動作する。保存頻度が高いとシステムのパフォーマンスを低下させる要因となるが、その反面、障害発生時の復旧可能性は高まる。

マスター交替要求通知ドアベル５４０は、読出しによって全てのサーバ１５０Ａ〜Ｃに対して、マスター役の交替が必要であることを示す割込み（以降、この割込みをマスター役交替要求割込みと呼称する）をかけるために利用される。

図６に、第２の実施例の計算機システムにおいて、マスター役のサーバが故障した際に、残ったサーバ各々が行うべき処理手順をフローチャートとして示す。図６のフローチャートに示す手順は、マスター役のサーバが故障したことを検出したこと、ないしは、マスター役交替要求割込みを契機として開始される。

ステップＳ６０１では、サーバ可用性フラグ５１０〜５１３を読み出す。ステップＳ６０２では、ステップＳ６０１で読みだした結果を元に、可用性のあるサーバのうち、自サーバが一番若いサーバ番号を有するサーバであるかとうかを判定する。

ステップＳ６０２での判定の結果、自サーバが一番若いサーバ番号を有するサーバである場合、自サーバのＭＳ−ＰＦドライバをマスターモードにすることで、マスター役を引き継ぐ。そのための手順はステップＳ６１０〜Ｓ６１２である。

一方、自サーバが一番若いサーバ番号を有するサーバでは無い場合にはスレーブモードで動作し続ける。しかし、マスター役の交替が完了するまでＭＳＭＢ１１１を用いてマスター役のＭＳ−ＰＦドライバに要求を発することは控えるべきなので、交替が完了するまで待つ必要がある。そのための手順はステップＳ６２０〜Ｓ６２１である。

ステップＳ６１０では、マスタースナップショットレジスタ５３０の内容を読み出して、これまでマスター役だったＭＳ−ＰＦドライバ、すなわち障害発生のサーバ上のＭＳ−ＰＦドライバの内部状態を取得する。

ステップＳ６１１では、自サーバのＭＳ−ＰＦドライバをマスターモードに切り替える。その際に、ステップＳ６１０で得た内部状態を用いて、仕掛中の処理を引き継ぐ。

ステップＳ６１２では、マスター役サーバ番号レジスタ５２０に自サーバのサーバ番号を書込む。これに伴って、他のサーバにはマスター役交替完了割込みがかかる。他のサーバは後述するように、ステップＳ６２０でマスター役交替完了割込みを待っている。

スレーブモードを継続するサーバは、ステップＳ６２０において、新しいマスター役からのマスター役交替完了割込みを待つ。そして、マスター役交替完了割込みを受けた後に、ステップＳ６２１でマスター役サーバ番号レジスタ５２０を読み出して、どのサーバがマスター役であるかを認識する。

図１１のフローチャートに基づき、各サーバ内のＭＳ−ＰＦドライバ４６２Ａ〜Ｃの具体的動作の一例を説明する。ＭＳ−ＰＦドライバ４６２Ａ〜Ｃは起動すると，ステップＳ１１０１において，ＭＩＲ４１２のマスター役サーバ番号レジスタ５２０を読出し，マスター役となるべきサーバのサーバ番号を知る。

次に，ステップＳ１１０２において，自分が動作しているサーバのサーバ番号（自サーバ番号）と，ステップＳ１１０１で読み出したマスター役サーバ番号を比較する。比較結果がＹｅｓであれば，ステップＳ１１０３で図９に示したマスターＰＦドライバ１２２と同様の動作を行う。但し，ＭＳ−ＰＦドライバ４６２Ａ〜Ｃは，マスターＰＦドライバとして動く場合でも，サーバ１５０Ａ〜Ｃのハイパーバイザ１６１Ａ〜Ｃ上で動作する。そのため，ステップＳ９０６では，Ｉ／Ｏコントローラ１２０からではなく，自分が動作しているサーバのハイパーバイザ１６１Ａ〜Ｃからの要求をＡＰＩで受け付ける。このＡＰＩはスレーブＰＦドライバ１６２Ａ〜Ｃとハイパーバイザ１６１Ａ〜Ｃの間で使われるものと同じである。

もし，ステップＳ１１０２において，自サーバ番号とマスター役サーバ番号が一致しなければ，自分はスレーブＰＦドライバ１６２Ａ〜Ｃとして動作するべきである。そのために，まずステップＳ１１０４において，マスター役となるＭＳ−ＰＦドライバが既に起動して，マスターＰＦドライバとしの動作を開始していることを確認する。この確認は，マスター役サーバ番号レジスタ５２０で示されているサーバに対応するサーバ可用性フラグ５１０〜５１３を検査することで行うことができる。又，ＭＳＭＢ１１１を用いて，マスターＰＦドライバに対して擬似的な要求を行い，それに対する応答があるかどうかをもって判定しても良い。

ステップＳ１１０４において，マスター役が動作していることを確認した後に，ステップＳ１１０５において，図１０と同様にスレーブＰＦドライバとしての動作を行う。

以上説明した第２の実施例においても、ＰＦドライバとＩ／Ｏスイッチに新規な構成を導入することにより、ハイパーバイザの改造必要性や、導入コスト、ないしは、運用管理コストの増大を抑えることが出来ると共に、冗長構成により高信頼化を図ることができる。

図８は、第３の実施例に係る計算機システムの全体構成を示す図である。本実施例の計算機システムでは、図１の第１の実施例の構成や図４の第２の実施例の構成に対して、Ｉ／Ｏスイッチ１１０内のＭＳＭＢ１１１、及びＭＩＲ４１２の異なる実施例を示すものである。

一般にＩ／Ｏスイッチは、ＳＲ−ＩＯＶデバイスの複数サーバからの共有のみならず、計算機システムにおいて広範に利用されるものであるため、Ｉ／ＯスイッチのＬＳＩは既に多くの品種が市販されている。しかし、上述した実施例の構成では、Ｉ／Ｏスイッチ１１０内にＭＳＭＢ１１１、更にはＭＩＲ４１２を設けるため、市販されている既存のＩ／Ｏスイッチをそのまま流用できない。

そこで第３の実施例では、ＭＳＭＢ１１１、更にはＭＩＲ４１２をＩ／Ｏスイッチ１１０内に設けるのではなく、メールボックスデバイス８１０として、Ｉ／Ｏスイッチ１１０の外部に設ける構成とした。このメールボックスデバイス８１０内のＭＳＭＢ１１１、ＭＩＲ４１２は、Ｉ／Ｏスイッチ１１０経由でアクセスされる。なお、図８の計算機システムおいては、ＭＳＭＢ１１１とＭＩＲ４１２を内蔵するメールボックスデバイス８１０を、Ｉ／Ｏドロワ１００の外部に設ける構成として図示したが、Ｉ／Ｏスイッチ１１０の外部に設ければよいので、Ｉ／Ｏドロワ１００の内部に設置しても良いことはいうまでもない。

本実施例の構成により、Ｉ／Ｏスイッチ１１０は既存品を流用することが可能となり、メールボックスデバイス８１０のみを新規開発すれば良い。また、メールボックスデバイス８１０は、ＭＳＭＢ１１１とＭＩＲ４１２の少なくとも一方を含む、フラグやレジスタなどの記憶領域を有するだけの簡単なデバイスであるため、ＦＰＧＡ等を利用して実現することができる。

以上、本発明を、種々の実施例に基づき具体的に説明したが、本発明は上述した実施例の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

本発明は、複数の計算機を備えたブレードサーバ、ないしは計算機システムに関し、特に単一のＩ／Ｏデバイスを複数の計算機で共有する技術として有用である。

１００…Ｉ／Ｏドロワ
１１０…Ｉ／Ｏスイッチ
１１１…ＭＳＭＢ（マスター−スレーブ間通信用メールボックス）
１２０…Ｉ／Ｏコントローラ
１２１…Ｉ／Ｏスイッチ制御ソフトウェア
１２２…マスターＰＦドライバ
１３０…Ｉ／Ｏデバイス
１３１…ＰＦ（Ｐｈｙｓｉｃａｌ Ｆｕｎｃｔｉｏｎ、物理機能）
１３２、１３３、１３４、１３５…ＶＦ（Ｖｉｒｔｕａｌ Ｆｕｎｃｔｉｏｎ、仮想機能）
１３６…ＤＭＢ（Ｉ／Ｏデバイス内メールボックス）
１５０Ａ、１５０Ｂ、１５０Ｃ…サーバ（サーバ番号＃０、１、２）
１５１Ａ、１５１Ｂ、１５１Ｃ…ＣＰＵ（プロセッサ）
１５２Ａ、１５２Ｂ、１５２Ｃ…メモリ（主記憶装置）
１５３Ａ、１５３Ｂ、１５３Ｃ…内部インターコネクト
１５４Ａ、１５４Ｂ、１５４Ｃ…ＩＯＨ（Ｉ／Ｏハブ）
１６０Ａ、１６０Ｂ、１６０Ｃ…ゲストＯＳ
１６１Ａ、１６１Ｂ、１６１Ｃ…ハイパーバイザ
１６２Ａ、１６２Ｂ、１６２Ｃ…スレーブＰＦドライバ
１６３Ａ、１６３Ｂ、１６３Ｃ…ＶＦドライバ
３１０…マスター側レジスタ
３１１Ａ、３１１Ｂ、３１１Ｃ、３１１Ｄ…マスター利用権フラグ
３１２Ａ、３１２Ｂ、３１２Ｃ、３１２Ｄ…要求ドアベル
３１３Ａ、３１３Ｂ、３１３Ｃ、３１３Ｄ…応答ドアベル
３１４Ａ、３１４Ｂ、３１４Ｃ、３１４Ｄ…メッセージバッファ
３２０Ａ、３２０Ｂ、３２０Ｃ、３２０Ｄ…スレーブ側レジスタ（＃０、１、２、３）（サーバ番号＃０、１、２、３のサーバ用）
３２１Ａ、３２１Ｂ、３２１Ｃ、３２１Ｄ…スレーブ利用権フラグ
３２２Ａ、３２２Ｂ、３２２Ｃ、３２２Ｄ…要求ドアベル
３２３Ａ、３２３Ｂ、３２３Ｃ、３２３Ｄ…応答ドアベル
３２４Ａ、３２４Ｂ、３２４Ｃ、３２４Ｄ…メッセージバッファ
３３０…割込み発生部
３４０Ａ、３４０Ｂ、３４０Ｃ、３４０Ｄ…利用権調停部
４１２…ＭＩＲ（マスター役決定レジスタ）
４６２Ａ、４６２Ｂ、４６２Ｃ…ＭＳ−ＰＦドライバ（マスター／スレーブ兼用ＰＦドライバ）
５１０、５１１、５１２、５１３、…サーバ可用性フラグ（＃０〜３）５２０…マスター役サーバ番号レジスタ
５３０…マスタースナップショットレジスタ
５４０…マスター役交替要求ドアベル
８１０…メールボックスデバイス。

Claims (15)

1. Ｉ／Ｏドロワを介して、１台以上のＩ／Ｏデバイスを利用する複数のサーバを備えた計算機システムであって、
   前記Ｉ／Ｏドロワは、複数の前記サーバと前記Ｉ／Ｏデバイスを接続するＩ／Ｏスイッチと、前記Ｉ／Ｏスイッチの管理を行うＩ／Ｏコントローラとを有し、
   前記Ｉ／Ｏデバイスは、少なくとも１つ以上の物理的な機能（以下、ＰＦ）を有し、
   複数の前記サーバのうちいずれか一つ、或いは前記Ｉ／Ｏコントローラは、前記ＰＦにアクセスするマスターＰＦドライバを有し、
   前記マスターＰＦドライバを有する前記サーバ以外の複数の前記サーバは、スレーブＰＦドライバを有し、
   前記スレーブＰＦドライバは、前記ＰＦを利用するために前記マスターＰＦドライバに要求を転送し、要求を受けた前記マスターＰＦドライバが前記ＰＦにアクセスする、
   ことを特徴とする計算機システム。
2. 請求項１記載の計算機システムであって、
   前記Ｉ／Ｏスイッチは、前記マスターＰＦドライバ及び前記スレーブＰＦドライバからアクセス可能なメールボックスを有し、
   前記スレーブＰＦドライバは、前記メールボックスに前記マスターＰＦドライバへの前記要求を書込み、
   前記マスターＰＦドライバは、前記メールボックスから前記スレーブＰＦドライバが書込んだ要求を読出し、前記Ｉ／Ｏデバイスの前記ＰＦにアクセスする、
   ことを特徴とする計算機システム。
3. 請求項１記載の計算機システムであって、
   前記マスターＰＦドライバと前記スレーブＰＦドライバは、それぞれマスター／スレーブ兼用ＰＦドライバ（以下、ＭＳ−ＰＦドライバ）で構成され、前記ＭＦ−ＰＦドライバは、前記マスターＰＦドライバとして動作するマスターモード、あるいは前記スレーブＰＦドライバとして動作するスレーブモードで動作し、
   前記Ｉ／Ｏスイッチは、複数の前記ＭＳ−ＰＦドライバからアクセス可能なメールボックスを有し、
   前記スレーブモードで動作している前記ＭＳ−ＰＦドライバは、前記メールボックスに前記マスターモードで動作している前記ＭＳ−ＰＦドライバへの要求を書込み、
   前記マスターモードで動作して前記ＭＳ−ＰＦドライバは、前記メールボックスに書き込まれた前記要求を読出し、読み出した前記要求に従い前記Ｉ／Ｏデバイスの前記ＰＦにアクセスする、
   ことを特徴とする計算機システム。
4. 請求項３に記載の計算機システムであって、
   前記Ｉ／Ｏスイッチは、前記マスターモードで動作している前記ＭＳ−ＰＦドライバを有する前記サーバの識別子を保持するマスター役決定領域を有し、
   前記スレーブモードでの動作中の前記ＭＳ−ＰＦドライバは、前記マスター役サーバ決定領域を読み出して、前記マスターモードで動作している前記ＭＳ−ＰＦドライバを有する前記サーバを認識する、
   ことを特徴とする計算機システム。
5. 請求項４に記載の計算機システムであって、
   前記Ｉ／Ｏスイッチ内の前記マスター役サーバ決定領域は、前記複数のサーバの可用性を保持するサーバ可用性フラグを記憶し、
   前記スレーブモードで動作している前記ＭＳ−ＰＦドライバは、前記マスターモードで動作している前記ＭＳ−ＰＦドライバを有する前記サーバに障害が発生したことを検出した場合、前記サーバ可用性フラグを読み出して、利用可能な前記サーバのサーバ識別子を認識する、
   ことを特徴とする計算機システム。
6. 請求項１に記載の計算機システムであって、
   前記マスターＰＦドライバ及び前記スレーブＰＦドライバからアクセス可能なメールボックスを備えたメールボックスデバイスを更に有し、
   前記スレーブＰＦドライバは、前記メールボックスに前記マスターＰＦドライバへの前記要求を書込み、
   前記マスターＰＦドライバは、前記メールボックスから前記スレーブＰＦドライバが書込んだ要求を読出し、前記Ｉ／Ｏデバイスの前記ＰＦにアクセスする、
   ことを特徴とする計算機システム。
7. Ｉ／Ｏデバイスを利用する複数のサーバと、複数の前記サーバと前記Ｉ／Ｏデバイスを接続するＩ／Ｏスイッチと、前記Ｉ／Ｏスイッチの管理を行うＩ／Ｏコントローラとを有する計算機システムのＩ／Ｏデバイス制御方法であって、
   前記Ｉ／Ｏデバイスに少なくとも１つ以上の物理的な機能（以下、ＰＦ）を備え、
   複数の前記サーバのうちいずれか一つ、或いは前記Ｉ／Ｏコントローラに、前記ＰＦにアクセスするマスターＰＦドライバを備え、
   前記マスターＰＦドライバを有する前記サーバ以外の複数の前記サーバは、スレーブＰＦドライバを備え、
   前記スレーブＰＦドライバは、前記ＰＦを利用するために前記マスターＰＦドライバに要求を転送し、
   前記要求を受けた前記マスターＰＦドライバは前記ＰＦにアクセスする、
   ことを特徴とするＩ／Ｏデバイス制御方法。
8. 請求項７記載のＩ／Ｏデバイス制御方法であって、
   前記マスターＰＦドライバと前記スレーブＰＦドライバを、それぞれマスター／スレーブ兼用ＰＦドライバ（以下、ＭＳ−ＰＦドライバ）で構成し、
   前記ＭＦ−ＰＦドライバは、前記マスターＰＦドライバとして動作するマスターモード、または前記スレーブＰＦドライバとして動作するスレーブモードで動作し、
   前記Ｉ／Ｏスイッチは、複数の前記ＭＳ−ＰＦドライバからアクセス可能なメールボックスを備え、
   前記スレーブモードで動作している前記ＭＳ−ＰＦドライバは、前記メールボックスに前記マスターモードで動作している前記ＭＳ−ＰＦドライバへの要求を書込み、
   前記マスターモードで動作して前記ＭＳ−ＰＦドライバは、前記メールボックスに書き込まれた前記要求を読出し、前記Ｉ／Ｏデバイスの前記ＰＦにアクセスする、
   ことを特徴とするＩ／Ｏデバイス制御方法。
9. 請求項８に記載のＩ／Ｏデバイス制御方法であって、
   前記Ｉ／Ｏスイッチは、前記マスターモードで動作している前記ＭＳ−ＰＦドライバを有する前記サーバの識別子を保持するマスター役決定領域を有し、
   前記スレーブモードでの動作中の前記ＭＳ−ＰＦドライバは、前記マスター役サーバ決定領域を読み出して、前記マスターモードで動作している前記ＭＳ−ＰＦドライバを有する前記サーバを認識する、
   ことを特徴とするＩ／Ｏデバイス制御方法。
10. 請求項９に記載のＩ／Ｏデバイス制御方法であって、
    前記Ｉ／Ｏスイッチ内の前記マスター役サーバ決定領域に、前記複数のサーバの可用性を保持するサーバ可用性フラグを記憶し、
    前記スレーブモードで動作している前記ＭＳ−ＰＦドライバは、前記マスターモードで動作している前記ＭＳ−ＰＦドライバを有する前記サーバに障害が発生したことを検出した場合、前記サーバ可用性フラグを読み出して、利用可能な前記サーバのサーバ識別子を認識する、
    ことを特徴としたＩ／Ｏデバイス制御方法。
11. 請求項９に記載のＩ／Ｏデバイス制御方法であって、
    前記マスター／スレーブ兼用ドライバは、利用可能な前記サーバのサーバ識別子に基づいて、前記ＭＳ−ＰＦドライバをマスターモードに切り替えるか否かを判断する、
    ことを特徴とするＩ／Ｏデバイス制御方法。
12. 請求項１１に記載のＩ／Ｏデバイス制御方法であって、
    前記Ｉ／Ｏスイッチは、前記マスターモードで動作している前記ＭＳ−ＰＦドライバの内部状態を保存するためのマスタースナップショット記憶領域を備え、
    前記マスターモードで動作している前記ＭＳ−ＰＦドライバは、その内部状態を定期的、又は障害発生時に前記マスタースナップショット記憶領域に書込む、
    ことを特徴とするＩ／Ｏデバイス制御方法。
13. 複数のサーバが１台以上のＩ／Ｏデバイスを利用可能とするＩ／Ｏドロワであって、
    複数の前記サーバと前記Ｉ／Ｏデバイスを接続するＩ／Ｏスイッチと、前記Ｉ／Ｏスイッチの管理を行うＩ／Ｏコントローラとを備え、
    前記Ｉ／Ｏスイッチは、複数の前記サーバと前記Ｉ／Ｏコントローラからアクセス可能なメールボックスを有する、
    ことを特徴とするＩ／Ｏドロワ。
14. 請求項１３に記載のＩ／Ｏドロワであって、
    前記Ｉ／Ｏデバイスは、少なくとも１つ以上の物理的な機能（以下、ＰＦ）を有し、
    前記ＰＦをアクセスするためのＰＦドライバが、複数の前記サーバのうちいずれか一つ、或いは前記Ｉ／Ｏコントローラに備えられるマスターＰＦドライバと、前記マスターＰＦドライバを備えた前記サーバ以外の複数の前記サーバに備えられるスレーブＰＦドライバとからなり、
    前記メールボックスには、前記マスターＰＦドライバによって前記要求が読み出される、前記ＰＦを利用するための前記スレーブドライバからの要求が書き込まれ、
    ことを特徴とするＩ／Ｏドロワ。
15. 請求項１３に記載のＩ／Ｏドロワであって、
    前記メールボックスは、前記Ｉ／Ｏスイッチの外部に設置されたメールボックスデバイスに形成され、複数の前記サーバと前記Ｉ／Ｏコントローラは、前記メールボックスデバイスに形成された前記メールボックスをアクセスする、
    ことを特徴とするＩ／Ｏドロワ。

Images