JP2012048546A - 計算機システム、i/oデバイス制御方法、及びi/oドロワ - Google Patents
計算機システム、i/oデバイス制御方法、及びi/oドロワ Download PDFInfo
- Publication number
- JP2012048546A JP2012048546A JP2010190765A JP2010190765A JP2012048546A JP 2012048546 A JP2012048546 A JP 2012048546A JP 2010190765 A JP2010190765 A JP 2010190765A JP 2010190765 A JP2010190765 A JP 2010190765A JP 2012048546 A JP2012048546 A JP 2012048546A
- Authority
- JP
- Japan
- Prior art keywords
- driver
- master
- slave
- server
- servers
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/382—Information transfer, e.g. on bus using universal interface adapter
- G06F13/387—Information transfer, e.g. on bus using universal interface adapter for adaptation of different data processing systems to different peripheral devices, e.g. protocol converters for incompatible systems, open system
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Hardware Redundancy (AREA)
Abstract
【課題】ハイパーバイザがPFとの間で必要な情報取得や設定を行える形で、SR−IOVデバイスを複数ブレードから共有可能とする。
【解決手段】複数のサーバ150A〜Cと、I/Oデバイス130と、これらサーバとI/Oデバイスを接続するI/Oスイッチ110と、I/Oスイッチの管理を行うI/Oコントローラ120で構成され、I/Oデバイスは、1つ以上のPF131を有し、I/Oコントローラは、I/OデバイスのPFにアクセスするマスターPFドライバ122を有し、各サーバはスレーブPFドライバ162A〜Cを有し、これらスレーブPFドライバは、I/OデバイスのPFを利用するために、マスターPFドライバに要求を転送し、マスターPFドライバがスレーブPFドライバの代理としてI/OデバイスのPFにアクセスする。
【選択図】図1
【解決手段】複数のサーバ150A〜Cと、I/Oデバイス130と、これらサーバとI/Oデバイスを接続するI/Oスイッチ110と、I/Oスイッチの管理を行うI/Oコントローラ120で構成され、I/Oデバイスは、1つ以上のPF131を有し、I/Oコントローラは、I/OデバイスのPFにアクセスするマスターPFドライバ122を有し、各サーバはスレーブPFドライバ162A〜Cを有し、これらスレーブPFドライバは、I/OデバイスのPFを利用するために、マスターPFドライバに要求を転送し、マスターPFドライバがスレーブPFドライバの代理としてI/OデバイスのPFにアクセスする。
【選択図】図1
Description
本発明は、複数の計算機を備えたブレードサーバ、ないしは計算機システムに関し、特に単一のI/Oデバイスを複数の計算機で共有する技術に関する。
計算機システムの集約性を高めるために、ブレードサーバや仮想化技術が用いられている。計算機システムの集約性を高めることは、消費電力削減、占有スペース削減、ないしは、管理の省力化につながり、計算機システムの導入コストと運用コストの削減に寄与する。
ブレードサーバは、プロセッサ(CPU、Central Processing Unit)、主記憶装置(メモリ)、及び、ネットワークインタフェースカード(NIC、Network Interface Card)を搭載した複数のブレードと、ネットワークスイッチ、電源、及び、拡張用入出力(I/O、Input/Output)スロットを搭載したI/Oドロワが同一の筺体に格納された構成をとる。ブレードサーバでは、複数のブレードがネットワークスイッチ、電源、及び、I/Oドロワを共有することができるため、集約性が高まる。
仮想化技術は、サーバ上で仮想計算機モニタ(VMM、Virtual Machine Monitor)やハイパーバイザを動作させることで、1台のサーバを論理的に分割して仮想計算機(VM、Virtual Machine)として運用するものである。なお、以降の説明では、VMMないしはハイパーバイザのことを、単にハイパーバイザと呼称する。仮想化技術により、1台のサーバ、ブレードを複数台のサーバとして使うことができるため、集約性が高まる。なお、VM上で動作するオペレーティングシステム(OS、Operating System)のことを、ゲストOSと称する。
仮想化技術を適用したサーバでは、1台のサーバ上で複数のVMが稼働する。VMが他のサーバと通信を行うためには、NICを使う必要がある。複数のVMは各々別個にNICを使おうとするため、VMの数と同数以上のNICをサーバに搭載する必要が生じる。このように、NICをVMに直接割当てる方式を、直接I/O方式と称する。しかし、直接I/O方式では、サーバに搭載するNICの数が増加するため、コストや占有スペースの面で不利になる。
そこで、ハイパーバイザがVMに対して仮想NICを提供する方式が用いられている(これ以降、仮想NIC方式と呼称する)。仮想NIC方式では、ソフトウェアによるエミュレーションでVMに対して仮想NICを提供する。VMは仮想NICを用いて通信を行う。ハイパーバイザはサーバに装着されているNICを用いて、VMから仮想NICに要求された通信を実現する。この方式であれば、サーバが有するNICが1枚でも、複数のVMからの通信要求を処理することができる。そのため、直接I/O方式で問題となったコストや占有スペースの増大は回避できる。しかし、仮想NICを提供するためのエミュレーションにCPU資源を消費してしまうことや、10 ギガビット イーサネット(10GbE、Gigabit Ethernet(登録商標))のように高速なネットワークではエミュレーションが追いつかなくなる等の問題が新たに生じる。
このような背景から、直接I/O方式で問題となっていたコストや占有スペースの問題を回避しつつ、仮想NIC方式で問題となっていたCPU資源の消費も回避できる技術が望まれていた。この要求を実現する技術として、PCI−SIG(Peripheral Component Interconect−Special Interest Group)で標準化が行われたSR−IOV(Single Root I/O Virtualization)やMR−IOV(Multi Root I/O Virtualization)がある(例えば、特許文献1−3、非特許文献1等)。
Single Root I/O Virtualization and Sharing Specification Revision 1.1、Chapter 1、Architectural Overview、第11頁〜第24頁、2009年9月PCI−SIG発行
上述したSR−IOVでは単一のサーバ上で動作する複数のVMが、単一のデバイスを共有するための技術を提供している。また、MR−IOVではSR−IOVを拡張して、複数のサーバ上で動作する複数のVMが単一のデバイスを共有するための技術を提供している。
SR−IOVを適用することで、仮想NIC方式のように性能を犠牲にすることなく、直接I/O方式よりサーバの集約性を高めることができる。MR−IOVを適用することで、SR−IOVよりもさらにサーバの集約性を高めることが出来る。しかし、MR−IOVに対応したデバイスが少ない、ないしは、高価であるといった問題があり、今日のサーバでは利用が広まっていない。
そこで、特許文献2、3に見るような、SR−IOVに対応したデバイス(以降、SR−IOVデバイス)を、MR−IOVの様に複数のサーバから共有するための技術が、これまでに提案されてきた。
特許文献2に記載の技術では、SR−IOVデバイスと複数のサーバの間をI/Oスイッチで接続することで、SR−IOVデバイスの共有を実現している。SR−IOVデバイスは単一のPF(Physical Function)と複数のVF(Virtual Function)を有しており、VFをVMに割当てることで、複数のVMが単一のSR−IOV共有デバイスを用いる。特許文献2に記載の技術では、VFのブレードへの割当てを指定するVF割当情報に従って、スイッチ内でルーティングを行うことで、VFを単一ブレード上の複数VMからのみならず、複数サーバ上の複数VMから利用することを実現している。
ところで、SR−IOVデバイスはVFを複数個有しているため、VFは複数VMに直接割当てることができる。具体的には、SR−IOVデバイスを共用しようとするサーバ数と同数以上のVFをSR−IOVデバイスが有している。しかし、PFは通常1個、ないしは、サーバ数より少ない数しか存在しないことが多い。
SR−IOVではPFはハイパーバイザが利用することが想定されている。ハイパーバイザは、自身が生成するVM数を元に必要となるVF数を算出して、PFが有するSR−IOV Capabilityに設定を行う。また、VFを利用する際に必要となる識別子である、Bus番号、Device番号、及び、Function番号も、PFが有するSR−IOV Capabilityに格納されている情報を読み出すことで算出する。このように、ハイパーバイザはPFを制御することで、SR−IOVデバイスのVFをVMに割当てるために必要な情報を取得する。
しかし、特許文献2に記載のように、VFを複数サーバに割当てても、PFはサーバ台数分存在しないため、VFを割当てたサーバ全てにPFを割当てることが出来ない場合がある。特許文献の図2では、PFを制御できるのはPFドライバを有するPCI−管理HWのみである。このような場合、ハイパーバイザは、PFを制御してVMへのVFの割当てに必要な情報取得や設定を行うことができない。そのため、ハイパーバイザとPFに対して、別途設定を行う必要が出てくる。そのためには、ハイパーバイザに外部から設定を行うためのインタフェースを用意するなど、ハイパーバイザの改造が必要となる。また、外部から設定の行う手間がかかり、管理コストを引き上げてしまう。
一方、特許文献3では、ハイパーバイザがPFと通信することを実現しつつ、SR−IOVデバイスを複数サーバで共有する技術について述べている。一般的に、サーバ上で動作するソフトウェアがデバイスにアクセスするためには、ドライバと呼ばれるソフトウェアを用いる。VM上で動作しているゲストOSには、VFにアクセスするためのVFドライバが組み込まれる。同様に、ハイパーバイザはPFと通信するためにPFドライバを有している。
しかしながら、特許文献3記載の技術では、複数ブレードのうち1台をマスターブレード、残りをスレーブブレードとする。スレーブブレード上のPFドライバがデバイスにアクセスしようとすると、スレーブブレード上のハイパーバイザは、そのアクセスをトラップする。そして、スレーブブレード上のハイパーバイザはマスターブレード上のハイパーバイザに、トラップした内容を通知する。これにより、単一のPFを複数ブレードで共有することができる。しかし、この方法では、ハイパーバイザの改造が必要になってしまうという問題が依然として残る。さらに、ハイパーバイザがPFドライバの動作をトラップする必要があるため、性能低下を引き起こすという懸念が生じる。
また、特許文献3の図1に示されるように、マスターブレードとスレーブブレードが通信するためにネットワークを必要とするため、システムの構成が複雑化し、導入コストと運用コストを引き上げるという問題もある。
上記従来例のように、SR−IOVデバイスを複数ブレードで共有する技術はこれまでに提案されてきた。しかし、管理が煩雑になる、ないしは、ハイパーバイザの改造が必要になるなどの副作用が生じてきた。
本発明では、ハイパーバイザを改造することなく、かつ、ハイパーバイザがPFとの間で必要な情報取得や設定を行える形で、SR−IOVデバイスを複数ブレードから共有する手段を提供することを目的とする。
上記の目的を達成するため、本発明においては、I/Oドロワを介して1台以上のI/Oデバイスを利用する複数のサーバを備えた計算機システムであって、I/Oドロワは、複数のサーバとI/Oデバイスを接続するI/Oスイッチと、I/Oスイッチの管理を行うI/Oコントローラとを有し、I/Oデバイスは、少なくとも1つ以上の物理的な機能(以下、PF)を有し、複数のサーバのうちいずれか一つ、或いはI/Oコントローラは、PFにアクセスするマスターPFドライバを有し、マスターPFドライバを有するサーバ以外の複数のサーバは、スレーブPFドライバを有し、スレーブPFドライバは、PFを利用するためにマスターPFドライバに要求を転送し、要求を受けたマスターPFドライバがPFにアクセスする構成の計算機システムを提供する。
また、上記の目的を達成するため、本発明においては、I/Oデバイスを利用する複数のサーバと、複数のサーバとI/Oデバイスを接続するI/Oスイッチと、I/Oスイッチの管理を行うI/Oコントローラとを有する計算機システムのI/Oデバイス制御方法であって、I/Oデバイスに少なくとも1つ以上のPFを備え、複数のサーバのうちいずれか一つ、或いはI/Oコントローラに、PFにアクセスするマスターPFドライバを備え、マスターPFドライバを有するサーバ以外の複数のサーバは、スレーブPFドライバを備え、スレーブPFドライバは、PFを利用するためにマスターPFドライバに要求を転送し、要求を受けたマスターPFドライバはPFにアクセスする構成のI/Oデバイス制御方法を提供する。
更に、上記の目的を達成するため、本発明においては、複数のサーバが1台以上のI/Oデバイスを利用可能とするI/Oドロワであって、
複数のサーバとI/Oデバイスを接続するI/Oスイッチと記I/Oスイッチの管理を行うI/Oコントローラとを備え、I/Oスイッチは、複数のサーバとI/Oスイッチからアクセス可能なメールボックスを有する構成のI/Oドロワを提供する。
複数のサーバとI/Oデバイスを接続するI/Oスイッチと記I/Oスイッチの管理を行うI/Oコントローラとを備え、I/Oスイッチは、複数のサーバとI/Oスイッチからアクセス可能なメールボックスを有する構成のI/Oドロワを提供する。
本発明は、少なくとも1つのPFを有するI/Oデバイスを複数のサーバで共用することが可能になる。特に、既存のハイパーバイザを利用して共有を実現できるという効果がある。
以下、本発明の一実施形態を添付図面に基づいて説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、同一の符号の繰り返しの説明は省略する。なお、本明細書において、PF(Physical Function)、VF(Virtual Function)は、上述したPCI-SIGが公開したデバイスでの仮想化支援機能であるSR−IOVにおけるものに対応する。
図1は、第1の実施例に係る計算機システムの全体構成を示す図である。図1の計算機システムは複数台のサーバ150A〜C、I/Oドロワ100、I/Oデバイス130から構成されている。ここで、I/Oデバイス130を、サーバ150A〜Cで共用する。I/Oドロワ100は、複数台のサーバ150A〜CとI/Oデバイス130とを接続するI/Oスイッチ110と、I/Oスイッチ110を制御するI/Oコントローラ120を備えている。
I/Oデバイス130は例えばNICのような入出力を担う装置である。I/Oデバイス130は1個のPF131、4個を例示した複数個のVF132〜135、及び、I/Oデバイス内メールボックス(DMB、Device MailBox)136で構成されている。DMB136は、PF131を操作するPFドライバと、VF132〜135を操作するVFドライバ間が通信するための領域として使用される共用レジスタである。本実施例においては、後で詳述するように、PFドライバには、マスターPFドライバとスレーブPFドライバがある。
サーバ150A〜Cは、少なくとも一個の中央処理部からなるCPU151A〜C、メモリ152A〜C、入出力ハブ(IOH、I/O Hub)154A〜Cを有している。また、これらの構成部材は内部インターコネクト153A〜Cで接続されている。内部インターコネクト153A〜Cは、例えばハイパートランスポート(HT、HyperTrasport)のようなインタフェースが用いられる。よって、各々のサーバは通常の計算機構成を有していることになる。
サーバ150A〜C上では、ハイパーバイザ161A〜Cが動作しており、VMを生成する。そのVM上でゲストOS160A〜Cが動作する。ハイパーバイザ161A〜Cは、本実施例で開示するスレーブPFドライバ162A〜Cを有している。ゲストOSはVFドライバ163A〜Cを有している。なお、ハイパーバイザ161A〜C、ゲストOS160A〜C、スレーブPFドライバ162A〜C、及び、VFドライバ163A〜CはいずれもCPUで実行されるソフトウェアであるため、メモリ152A〜C上に存在する。
I/Oデバイス130とI/Oスイッチ110間、及び、I/Oスイッチ110とIOH154A〜Cの間は、PCI−SIGが策定したPCI Expressの規格に準拠したインタフェースで接続される。IOH154A〜Cは、CPU151A〜Cが発するI/Oデバイス130宛のメモリライト、ないしは、メモリリードを、PCI Expressのパケットに変換する。また、IOH154A〜Cは、I/Oデバイス130から発せられたパケットを受け取り、メモリ152A〜Cを読書きする。
上述の通り、I/Oドロワ100は、サーバ150A〜CにI/Oデバイス130を接続するための装置である。I/OドロワはI/Oスイッチ110とI/Oコントローラ120から構成される。
I/Oスイッチ110は、I/Oサーバ150A〜CとI/Oデバイス130の間でパケットを転送するスイッチである。また、I/Oスイッチ110は本実施例で開示するマスター−スレーブ間通信用の記憶領域として使用されるマスター−スレーブ間通信用メールボックス(MSMB、Master−Slave Communication MailBox)111を有する。
なお、I/Oドロワ100内でI/Oスイッチ110を制御するI/Oコントローラ120は、サーバ150A〜Cと同様に、図示を省略したCPUやメモリで構成される。一般的には、CPUやメモリが1チップに集積されたマイクロコントローラが用いられる。同図に示すように、I/Oコントローラ120上では、I/Oスイッチ110を制御するためのソフトウェアであるI/Oスイッチ制御ソフトウェア121、及び、本実施例で開示するマスターPFドライバ122が動作する。
I/Oコントローラ120とI/Oスイッチ110間の接続も、PCI Express規格に準拠したインタフェースで接続される。なお、I/Oスイッチ110とI/Oコントローラ120を同一のLSIや基板上に構成する場合には、独自規格のインタフェースを用いることもできる。
図2は、第1の実施例の計算機システムにおいて、サーバ150A〜C及びI/Oコントローラ120上で動作しているソフトウェアと、I/Oデバイス130の間でのインタラクションを示した概念図である。同図において、破線P201〜P206は、破線の両端にある二者間でインタラクションがあることを示している。
VFドライバ163A〜Cは、ゲストOS160A〜Cの要求に応じて通信を行うために、VF132〜134にアクセスする(破線P201A〜C)。これにより、仮想NIC方式のようにエミュレーションのためのオーバヘッドを生じることなく、複数サーバ上の複数VMから単一のSR−IOVデバイスを共有することができる。
I/Oコントローラ120で動作するマスターPFドライバ122は、I/Oデバイス130の全体制御を行うために、PF131にアクセスする。PF131にアクセスすることが出来るのは、図1及び図2に示されている第1の実施例に係る計算機システムの中で、唯一マスターPFドライバ122のみである。
VFドライバ163A〜Cは、VF132〜134にアクセスすることで通信に必要な動作を実現するが、I/Oデバイス130全体に関わる一部の動作や設定は、PF131にアクセスしなければならない場合がある。例えば、NICではメディアアクセスコントロール(MAC、Media Access Control)アドレスの設定などがPF131の所管となっている場合がある。そこで、本実施例の計算機システムにおいては、VFドライバ163A〜Cは、DMB136を経由してマスターPFドライバ122に設定を要求する(P202A〜C、P203)。マスターPFドライバ122は、VFドライバ163A〜Cから要求された動作や設定を実現するために、PF131にアクセスする(P204)。
VFドライバとPFドライバ間の通信手段はSR−IOVの規格で定められているわけではないが、DMB136のようなデバイス内の共有レジスタで構成されるメールボックスを用いている場合が多い。本実施の形態では、マスターPFドライバ122とVFドライバ163A〜Cの間の通信手段として、DMB136を流用している。
スレーブPFドライバ162A〜Cは、ハイパーバイザ161A〜Cに組み込まれるPFドライバである。ハイパーバイザ161A〜Cから見ると、スレーブPFドライバ162A〜Cは、従来のPFドライバと区別がつかない。ハイパーバイザ161A〜Cは、PFに対する設定、例えばSR−IOV Capabilityの設定などを行う時、スレーブPFドライバ162A〜Cに依頼する。スレーブPFドライバ162A〜Cは、ハイパーバイザ161A〜Cからの要求を満たすために必要な操作を、直接PF131に対して行うことはしない。その代りに、MSMB111を経由してマスターPFドライバ122に設定を要求する(P205A〜C、P206)。マスターPFドライバ122は、スレーブPFドライバ162A〜Cに要求された動作や設定を実現するために、PF131にアクセスする(P204)。なお、マスターPFドライバ122とスレーブPFドライバ162A〜Cの具体的構成の一例を、後で図9、図10を用いて説明する。
図3は、第1の実施例に係る、I/Oスイッチ110内のMSMB111の一例の詳細な構成を示すブロック図である。MSMB111は、マスターPFドライバ122がアクセス可能な記憶領域であるレジスタ(これ以降、マスター側レジスタと呼称する)310、スレーブPFドライバ162A〜Cがアクセス可能な記憶領域であるレジスタ(これ以降、スレーブ側レジスタと呼称する)320A〜D、利用権調停部340A〜D、割込み発生部330から構成される。
マスター側レジスタ310は、マスターPFドライバ122がアクセスするものなので、その個数は1個である。一方、スレーブ側レジスタ320A〜Dは、システム全体に含まれるスレーブPFドライバ162A〜Cの個数と同数以上必要となる。図1の計算機システムの例では、サーバ150A〜Cの3台でそれぞれハイパーバイザ161A〜Cが動作しているために、スレーブPFドライバ162A〜Cは3個である。そのため、スレーブ側レジスタは最低3個必要である。
図1の計算機システムではI/Oデバイス130は4個のVF132〜135を有しているため、最大で4台のサーバがI/Oデバイス130を共有することができる。その場合には、スレーブPFドライバはシステム全体で4個存在することになるため、この値に合わせて図3のMSMB111では4個のスレーブ側レジスタ320A〜Dを有している。そのため、図1に示した第1の実施例に係る計算機システムでは、スレーブ側レジスタ320Dは使われることなく余る。
本実施例においてMSMB111は、マスターPFドライバ122がスレーブPFドライバ162A〜Cに要求を送る、もしくは逆にスレーブPFドライバ162A〜CがマスターPFドライバ122に要求を送るために用いられる。そのため、要求を伝えるためのメッセージバッファ314A〜D、324A〜Dを備えている。マスター側レジスタのメッセージバッファ314A〜Dと、スレーブ側レジスタのメッセージバッファ324A〜Dは、それぞれ同じ記憶領域を共有している。例えば、メッセージバッファ314Aに書いた内容は、メッセージバッファ324Aから読み出せる。また、メッセージバッファ314Bに書いた内容を、メッセージバッファ314Bから読み出すこともできる。このような共有領域で、マスターPFドライバ122とスレーブPFドライバ162A〜Cは要求を互いに送受する。
メッセージバッファ314A〜C、324A〜Dを用いて要求の送受を行うためには、当該メッセージバッファに書込む権利(利用権)をマスター側とスレーブ側で調停しなければならない。そのために、MSMB111は、マスター利用権フラグ311A〜D、スレーブ利用権フラグ321A〜321D、及び、利用権調停部340A〜Dを有する。
マスター利用権フラグ311A〜Dは、その内容が1であるときに、マスター側のマスターPFドライバ122がメッセージバッファに書込む権利を有している事を示す。なお、初期値は利用権を有しないことを示す0とする。また、スレーブ利用権フラグ321A〜Dも同様に、その内容が1であるときに、スレーブ側のスレーブPFドライバ162A〜Cがメッセージバッファを書込む権利を有していることを示す。こちらも、その初期値は利用権を有しないことを示す0である。また、マスター側とスレーブ側の利用権は排他的でなければならない。すなわち、マスター利用権フラグ311Aが1であるときには、スレーブ利用権フラグ321Aは必ず0である。
利用権調停部340A〜Dは、マスター利用権フラグ311A〜D、ないしは、スレーブ利用権フラグ321A〜Dに対して、マスターPFドライバ122、ないしは、スレーブPFドライバ162A〜Cが1を書込もうとした時に、前述した利用権の排他性が保たれる時に限って1の書込みを許し、そうでない場合には1を書込ませない。例えば、マスターPFドライバ122がマスター利用権フラグ311Aに1を書込む時に、スレーブ利用権フラグ321Aの内容が0であれば書込むことができる。スレーブ利用権フラグ321Aの内容が1の時には、マスター利用権フラグ311Aへの書込みは無視され、マスター利用権フラグ311Aの内容は初期値の0のままである。
マスターPFドライバ122、ないしは、スレーブPFドライバ162A〜Dは、メッセージバッファの利用権を得てメッセージバッファに要求を書き込んだ後、相手に対して要求を書込んだことを伝える必要がある。そのために、MSMB111は要求ドアベル312A〜D、322A〜Dと、割込み発生部330を有する。
要求ドアベル312A〜D、322A〜DがマスターPFドライバ122、ないしは、スレーブPFドライバ162A〜Dによって読み出されると、割込み発生部は対応する相手に割込みを発生させる(以降、要求割込みと呼称する)。割込みはPCI Expressではメモリへの書込みと同様にパケットで表現される。例えば、スレーブPFドライバ162AがマスターPFドライバ122に要求を発したい場合、要求ドアベル322Aを読み出す。割込み発生部330は要求ドアベル322Aが読みだされると、マスターPFドライバ122に対して割込みを発生させる。なお、要求ドアベル322Aの読出し結果としては、割込み発生成功を示す1、ないしは、割込み発生失敗を示す0が得られる。
割込み要求を受けたマスターPFドライバ122、ないしは、スレーブPFドライバ162A〜Dは、メッセージバッファ314A〜D、324A〜Dの内容を読み出して要求を受け付ける。その後、要求を完了した旨を要求元に伝えるための手段として、MSMB111は応答ドアベル313A〜D、323A〜Dを有する。応答ドアベル313A〜D、323A〜Dは、要求ドアベル312A〜D、322A〜Dと同様に、相手に対して割込みを発生させるためのドアベルである。割込み発生部330は、要求ドアベルに起因する割込みと応答ドアベルに起因する割込みで異なる割込み要因を使って割込みをかける(以降、応答ドアベルに起因する割込みを、応答割込みと呼称する)。これにより、マスターPFドライバ122、ないしは、スレーブPFドライバ162A〜Dは自分に対して相手から要求が来たのか、自分が発した要求に対する応答が来たのかを区別することができる。
図7を用いて、第1の実施例に係る計算機システムにおいて、マスターPFドライバ122、ないしは、スレーブPFドライバ162A〜Dが要求を相手に送信する手順を示す。なお、図7はマスターPFドライバ122がスレーブPFドライバ162A〜Dに要求を送信する手順(以降、マスター発要求と呼称する)であるが、スレーブPFドライバ162A〜DがマスターPFドライバ122に要求を送信する手順(以降、スレーブ発要求と呼称する)も基本的な手順は同じなので、図7に補足する形で説明する。
図7のステップS701では、マスター側レジスタ310のメッセージバッファ314A〜Dの利用権を得るために、マスター利用権フラグ311A〜Dに1を書込む。スレーブ発要求の場合には、メッセージバッファ324A〜Dの利用権を得るために、スレーブ利用権フラグ321A〜Dに1を書込む。
ステップS702では、利用権を得られたかどうかを確認するためにマスター利用権フラグ311A〜Dを読み出す。1が読みだせれば利用権が得られたものとして、ステップS703に進む。0が読みだされた場合、利用権を得られていないので、利用権が得られるまでS701を繰り返す。なお、スレーブ発要求の場合には、スレーブ利用権フラグ321A〜Dを読み出す。
ステップS703では、メッセージバッファ314A〜Dに要求を示すメッセージを書込む。なお、スレーブ発要求の場合には、メッセージバッファ324A〜Dに書込む。
ステップS704では、ステップS703で要求を書込んだことをスレーブPFドライバ162A〜Dに通知するために、要求ドアベル312A〜Dで要求割込みを発生させる。なお、スレーブ発要求の場合にはマスターPFドライバ122に通知するために、要求ドアベル322A〜Dで要求割込みを発生させる。
ステップS705では、自身が発した要求に対して、相手からの応答を示す応答割込みを待つ。すなわち、スレーブPFドライバ162A〜Dが、応答ドアベル323A〜Dで発生させる応答割込みを待つ。なお、スレーブ発要求の場合には、マスターPFドライバ122が、応答ドアベル313A〜Dで発生させる応答割込みを待つ。
ステップS706では、メッセージバッファ314A〜Dの利用権を解放するために、マスター利用権フラグ311A〜Dに0を書込む。なお、スレーブ発要求の場合にはメッセージバッファ324A〜Dの利用権を解放するために、スレーブ利用権フラグ321A〜Dに0を書込む。
以上、本実施例の計算機システムにおいて、ステップS701〜S706で、マスターPFドライバ122がスレーブPFドライバ162A〜Dに要求を送信すること、ないしは、スレーブPFドライバ162A〜DがマスターPFドライバ122に要求を送信することが出来る。
続いて、本実施例に利用されるマスターPFドライバ122とスレーブPFドライバ162A〜Cの一具体例について説明する。上述したとおり、マスターPFドライバ122は、I/Oコントローラ120を構成するCPUで実行されるプログラムで実現され、スレーブPFドライバ162A〜Cは各サーバ150A〜Cのハイパーバイザ161A〜Cに組み込まれる、言い換えるならハイパーバイザ161A〜C上で動作するプログラムとして実現される。
図9のフローチャートに基づき、本実施例のマスターPFドライバ122の具体的動作の一例を説明する。マスターPFドライバ122は,I/Oコントローラ120上で起動する際に,図9に示す動作を行う。
ステップS901では,マスターPFドライバ122はI/Oデバイス130上のPF131からデバイスに関する情報を読み出す。デバイスに関する情報とは,例えばI/Oデバイス130が有するVF132〜135の個数や,デバイス全体に共通するパラメータである。
次に,ステップS902では,ステップS901で得られたI/Oデバイス130に関する情報と,計算機システム全体の構成情報を元に,I/Oデバイス130に対する初期設定を,PF131に書込む。初期設定の内容としては,例えば使用するVFの個数や,NICであればMACアドレスの設定などがある。
ステップS901〜ステップS902までの段階で,I/Oデバイス130のPF131及びVF132〜135の使用が可能となるので,これ以降,サーバ150A〜Cを順次起動して,各々のサーバがI/Oデバイス130のVF132〜135を使い始める。各々のサーバ上では、以降で説明するスレーブPFドライバ162A〜Cや,VFドライバ163A〜Cが動作する。
マスターPFドライバ122は,自身が動作しているI/Oコントローラ120,スレーブPFドライバ162A〜C,ないしは,VFドライバ163A〜Cの何れかから要求を受けて,I/Oデバイス130に対して設定を行ったり,情報を読み出したりする。そのために,ステップS903でマスターPFドライバ122はこれらの要求を待っている。
これらの要求は割込みとしてマスターPFドライバ122に伝達されるため,割込み要因を分析して要求元を割り出す必要がある。ステップS904でVFドライバ163A〜Cからの要求であることが分かると,要求の委細を知るために,ステップS908でI/Oデバイス130内のDMB136を読み出す。ステップS905でスレーブPFドライバ162A〜Cからの要求であると判定された場合も同様に,要求の委細を知るために,ステップS907でI/Oスイッチ110内のMSMB111を読み出す。
なお,VFドライバ163A〜C,ないしは,スレーブPFドライバ162A〜Cのどちらからの要求でもない場合には,I/Oコントローラ120からの要求であるため,ステップS906でI/Oコントローラ120とマスターPFドライバ122の間で定められたAPIを用いて要求の委細を得る。例えば,I/Oコントローラ120がオペレーティングシステムLinux(Linuxは登録商標)で動作している場合には,このAPIはLinuxのドライバ向けに提供されているAPIとなる。
ステップS906〜S908のいずれかで要求の委細をマスターPFドライバ122は知ることが出来たので,マスターPFドライバ122は、ステップS909で当該要求を実現するための処理を行う。この処理は先に説明したように、本実施例においては、I/Oデバイス130のPF131に対する設定や情報読出し,MSMB111,DMB136,ないしは,前記のAPIを用いた通信によって実現できる。
次に、図10のフローチャートに基づき、本実施例のスレーブPFドライバ162A〜Cの具体的動作の一例を説明する。前述した通り,マスターPFドライバ122が起動した後に,スレーブPFドライバ162A〜Cは起動する。
まず,同図において、ステップS1001で既に起動済みのマスターPFドライバ122から,I/Oデバイス130に関する情報を取得する。スレーブPFドライバ162A〜Cは取得した情報のうち,ハイパーバイザ161A〜Cが必要とするものに関しては,ハイパーバイザ161A〜CとスレーブPFドライバ162A〜Cの間で定められたAPIを用いて,ハイパーバイザ161A〜Cに渡す。
その後,マスターPFドライバ122の場合と同様に,ステップS1002で要求待ちに入る。なお,スレーブPFドライバ162A〜Cは,ハイパーバイザ161A〜C,ないしは,マスターPFドライバ122から要求を受ける可能性がある。スレーブPFドライバ162A〜C間で直接的に要求が行われることは無く,必ずマスターPFドライバ122を介在する。また,VFドライバ163A〜CからスレーブPFドライバ162A〜Cに直接的に要求が行われることも無く,必ずマスターPFドライバ122を介在する。
よって,ステップS1003でマスターPFドライバ122からの要求であると判定できたら,ステップS1005で図3のMSMB111を読み出して,マスターPFドライバ122からの要求内容を得る。そうでなければ,ハイパーバイザ161A〜Cからの要求であるため,上述したAPIで要求内容を得る。
ステップS1006では,これらの要求内容を実現するための処理を行う。スレーブPFドライバ162A〜Cは,直接I/Oデバイス130のPF131,ないしは,VF132〜135にアクセスすることはしない。その代りに,ハイパーバイザ161A〜CへAPIで要求すること,ないしは,マスターPFドライバ122にMSMB111を経由して要求することで,前記の処理を実現する。
すなわち,本実施例のスレーブPFドライバ162A〜Cは,ハイパーバイザ161A〜Cからの要求をMSMB111経由でマスターPFドライバ122に転送すること,ないしは,マスターPFドライバ122からの要求を前記API経由でハイパーバイザ161A〜Cに転送することを行う。
以上説明した通り、本実施例では、PFドライバとI/Oスイッチに新規な構成を導入することにより課題の解決を図る。PFドライバはハイパーバイザに組み込んで利用するものであり、デバイス毎に開発が必要であることから、PFドライバを開発するために必要な環境は既に整えられており、本実施例における新規な処理をPFドライバに組み込むことは容易であり、ハイパーバイザの改造必要性や、導入コスト、ないしは、運用管理コストの増大を抑えることが出来る。
図4は、第2の実施例に係る計算機システムの全体構成を示す図である。図4に示す第2の実施例の計算機システムでは、I/Oコントローラ120にマスターPFドライバ122を搭載する代わりに、全てのサーバ150A〜Cに本実施例で開示するMaster/Slave兼用PFドライバ(これ以降、MS−PFドライバと呼称する)462A〜Cを搭載する。
MS−PFドライバ462A〜Cは、マスターPFドライバとスレーブPFドライバを兼ねるドライバであり、起動時にマスターPFドライバないしは、スレーブPFドライバのどちらとして動作するかを決定する。なお、本明細書において、MS−PFドライバがマスターPFドライバとして動作していることをマスターモードと、MS−PFドライバがスレーブPFドライバとして動作していることをスレーブモードと呼称する。このMS−PFドライバの具体的構成の一例は後で詳述する。
第1の実施例では、I/Oコントローラ120上でマスターPFドライバ122を動作させていた。しかし、マスターPFドライバ122は一点故障の要因となりうる。そのため、高信頼化を図るためには、I/Oコントローラ120を冗長構成にする必要がある。それに対して、本実施例では、マスターPFドライバとスレーブPFドライバの両方として機能し得るMS−PFドライバをサーバ150A〜C上で動作させることにより冗長構成を実現する。
すなわち、図4の計算機システム上のサーバ150A〜Cのうち、1台のサーバでマスターPFドライバ、すなわちマスターモードのMS−PFドライバを動作させ、その他のサーバではスレーブPFドライバ、すなわち、スレーブモードのMS−PFドライバを動作させる。そして、マスターPFドライバを動作させているサーバが故障した時は、スレーブPFドライバが動作しているその他のサーバのうち1台がマスターPFドライバとしての役割を引継ぐ。そのために、本実施例の計算機システムにあっては、マスターPFドライバとしても、スレーブPFドライバとしても動作することのできるMS−PFドライバ462A〜Cを新規に導入する構成としている。
本実施例において、図4中のMS−PFドライバ462A〜Cのうち、どのMS−PFドライバがマスターモードになるかの割当て方針の一例を以下に示す。マスターモードのサーバが不在になった時には、稼働中のサーバの中で、サーバの番号が一番若いサーバ上のMS−PFドライバがマスターモードとなり、それ以外のサーバ上のMS−PFドライバはスレーブモードとして動作することとする。
マスターモードとスレーブモードの切替えは、マスターモードのサーバが不在になった時に行われるので、稼働中のサーバのうち一番若いサーバ番号のサーバが常にマスターモードだとは限らない。例えば、サーバ150A(サーバ番号#0)がマスターモードで稼働し、サーバ150B(サーバ番号#1)がスレーブモードで稼働している時に、サーバ150Aに障害が発生すると、マスターモードのサーバが不在となるため、前述した切替えによりサーバ150Bがマスターモードに切り替わる。その後、サーバ150Aの障害を復旧して立ち上げると、一番サーバ番号が若いサーバはサーバ150Aとなるが、マスターモードのサーバは不在ではないので、言いかえるならサーバ150Bがマスターモードとして動き続けているので、マスターモードとスレーブモードの切替えは発生しない。
マスターモードとなるサーバの決定、及び、マスターモードとなっているサーバに障害が発生した時に、次なるマスター役のサーバに処理を引き継ぐための機構として、本実施例ではI/Oスイッチ110内にマスター役決定領域として機能するマスター役決定レジスタ(MIR、Master Identify Register)412を導入する構成とする。
図5に本実施例おいて用いられるMIRの一具体例を示した。同図に見るように、本実施例におけるMIR412は、サーバ可用性フラグ510〜513、マスター役サーバ番号レジスタ520、マスタースナップショットレジスタ530、マスター役交替要求ドアベル540から構成される記憶領域であり、I/Oスイッチ110内に形成される。
サーバ可用性フラグ510〜513は、各サーバが利用可能であるかどうかを示す。例えば、サーバ可用性フラグ510はサーバ150A(サーバ番号#0)の可用性を示す。なお、サーバ可用性フラグ510が1の時は当該サーバが利用可能であることを示し、フラグが0の時は当該サーバが利用不可能であることを示す。電源投入直後の初期値は0である。サーバ150A〜Cは起動後に各々に対応するサーバ可用性フラグ510〜513を1にセットする。また、シャットダウン等サーバが利用不可能になる前には、サーバ可用性フラグ510〜513を0にクリアする。サーバ150A〜Cに障害が発生して利用不可能になった場合には、障害を検出したサーバ、ないしは、図示していない管理系システムがサーバ可用性フラグ510〜513を0にクリアする。
例えば、スレーブモードで動いているMS−PFドライバが、マスターモードで動作しているMS−PFドライバに対してMSMB111経由で設定等の要求を出した後、一定時間以内に応答が返ってこない場合には、タイムアウトとしてマスターモードで動作しているMS−PFドライバに対応するサーバに障害が発生したものと見做す。その時は、タイムアウトを検出したMS−PFドライバが、当該サーバに対応するサーバ可用性フラグ510〜513を0にクリアする。その後、マスター役が不在になったため、マスター役の交替が必要であることをMS−PFドライバが動作している全サーバに知らせる。
図5のMIR412中のマスター役サーバ番号レジスタ520は、MS−PFドライバがマスターモードで動作しているサーバのサーバ番号を示すレジスタである。上述した通り、図2で説明したように、MSMB111のマスター側レジスタ310を使うことができるのは、マスター役サーバ番号レジスタ520で示されているサーバだけである。また、マスター役の切替えによって、新たにマスター役となったサーバは、自らのサーバ番号をマスター役番号レジスタ520に書込む。また、マスター役サーバ番号レジスタ520に値が書込まれると、マスター役が交替したことを示す割込みを全てのサーバ150A〜Cに対してかける(以降、この割込みをマスター役交替完了割込みと呼称する)。
マスタースナップショット記憶領域であるマスタースナップショットレジスタ530は、サーバ障害時にマスター役を切り替えるために、マスターモードで動作しているMS−PFドライバの内部状態を保存するためのレジスタである。マスターモードで動作しているMS−PFドライバは、内部状態を随時マスタースナップショットレジスタ530に保存するよう動作する。保存頻度が高いとシステムのパフォーマンスを低下させる要因となるが、その反面、障害発生時の復旧可能性は高まる。
マスター交替要求通知ドアベル540は、読出しによって全てのサーバ150A〜Cに対して、マスター役の交替が必要であることを示す割込み(以降、この割込みをマスター役交替要求割込みと呼称する)をかけるために利用される。
図6に、第2の実施例の計算機システムにおいて、マスター役のサーバが故障した際に、残ったサーバ各々が行うべき処理手順をフローチャートとして示す。図6のフローチャートに示す手順は、マスター役のサーバが故障したことを検出したこと、ないしは、マスター役交替要求割込みを契機として開始される。
ステップS601では、サーバ可用性フラグ510〜513を読み出す。ステップS602では、ステップS601で読みだした結果を元に、可用性のあるサーバのうち、自サーバが一番若いサーバ番号を有するサーバであるかとうかを判定する。
ステップS602での判定の結果、自サーバが一番若いサーバ番号を有するサーバである場合、自サーバのMS−PFドライバをマスターモードにすることで、マスター役を引き継ぐ。そのための手順はステップS610〜S612である。
一方、自サーバが一番若いサーバ番号を有するサーバでは無い場合にはスレーブモードで動作し続ける。しかし、マスター役の交替が完了するまでMSMB111を用いてマスター役のMS−PFドライバに要求を発することは控えるべきなので、交替が完了するまで待つ必要がある。そのための手順はステップS620〜S621である。
ステップS610では、マスタースナップショットレジスタ530の内容を読み出して、これまでマスター役だったMS−PFドライバ、すなわち障害発生のサーバ上のMS−PFドライバの内部状態を取得する。
ステップS611では、自サーバのMS−PFドライバをマスターモードに切り替える。その際に、ステップS610で得た内部状態を用いて、仕掛中の処理を引き継ぐ。
ステップS612では、マスター役サーバ番号レジスタ520に自サーバのサーバ番号を書込む。これに伴って、他のサーバにはマスター役交替完了割込みがかかる。他のサーバは後述するように、ステップS620でマスター役交替完了割込みを待っている。
スレーブモードを継続するサーバは、ステップS620において、新しいマスター役からのマスター役交替完了割込みを待つ。そして、マスター役交替完了割込みを受けた後に、ステップS621でマスター役サーバ番号レジスタ520を読み出して、どのサーバがマスター役であるかを認識する。
図11のフローチャートに基づき、各サーバ内のMS−PFドライバ462A〜Cの具体的動作の一例を説明する。MS−PFドライバ462A〜Cは起動すると,ステップS1101において,MIR412のマスター役サーバ番号レジスタ520を読出し,マスター役となるべきサーバのサーバ番号を知る。
次に,ステップS1102において,自分が動作しているサーバのサーバ番号(自サーバ番号)と,ステップS1101で読み出したマスター役サーバ番号を比較する。比較結果がYesであれば,ステップS1103で図9に示したマスターPFドライバ122と同様の動作を行う。但し,MS−PFドライバ462A〜Cは,マスターPFドライバとして動く場合でも,サーバ150A〜Cのハイパーバイザ161A〜C上で動作する。そのため,ステップS906では,I/Oコントローラ120からではなく,自分が動作しているサーバのハイパーバイザ161A〜Cからの要求をAPIで受け付ける。このAPIはスレーブPFドライバ162A〜Cとハイパーバイザ161A〜Cの間で使われるものと同じである。
もし,ステップS1102において,自サーバ番号とマスター役サーバ番号が一致しなければ,自分はスレーブPFドライバ162A〜Cとして動作するべきである。そのために,まずステップS1104において,マスター役となるMS−PFドライバが既に起動して,マスターPFドライバとしの動作を開始していることを確認する。この確認は,マスター役サーバ番号レジスタ520で示されているサーバに対応するサーバ可用性フラグ510〜513を検査することで行うことができる。又,MSMB111を用いて,マスターPFドライバに対して擬似的な要求を行い,それに対する応答があるかどうかをもって判定しても良い。
ステップS1104において,マスター役が動作していることを確認した後に,ステップS1105において,図10と同様にスレーブPFドライバとしての動作を行う。
以上説明した第2の実施例においても、PFドライバとI/Oスイッチに新規な構成を導入することにより、ハイパーバイザの改造必要性や、導入コスト、ないしは、運用管理コストの増大を抑えることが出来ると共に、冗長構成により高信頼化を図ることができる。
図8は、第3の実施例に係る計算機システムの全体構成を示す図である。本実施例の計算機システムでは、図1の第1の実施例の構成や図4の第2の実施例の構成に対して、I/Oスイッチ110内のMSMB111、及びMIR412の異なる実施例を示すものである。
一般にI/Oスイッチは、SR−IOVデバイスの複数サーバからの共有のみならず、計算機システムにおいて広範に利用されるものであるため、I/OスイッチのLSIは既に多くの品種が市販されている。しかし、上述した実施例の構成では、I/Oスイッチ110内にMSMB111、更にはMIR412を設けるため、市販されている既存のI/Oスイッチをそのまま流用できない。
そこで第3の実施例では、MSMB111、更にはMIR412をI/Oスイッチ110内に設けるのではなく、メールボックスデバイス810として、I/Oスイッチ110の外部に設ける構成とした。このメールボックスデバイス810内のMSMB111、MIR412は、I/Oスイッチ110経由でアクセスされる。なお、図8の計算機システムおいては、MSMB111とMIR412を内蔵するメールボックスデバイス810を、I/Oドロワ100の外部に設ける構成として図示したが、I/Oスイッチ110の外部に設ければよいので、I/Oドロワ100の内部に設置しても良いことはいうまでもない。
本実施例の構成により、I/Oスイッチ110は既存品を流用することが可能となり、メールボックスデバイス810のみを新規開発すれば良い。また、メールボックスデバイス810は、MSMB111とMIR412の少なくとも一方を含む、フラグやレジスタなどの記憶領域を有するだけの簡単なデバイスであるため、FPGA等を利用して実現することができる。
以上、本発明を、種々の実施例に基づき具体的に説明したが、本発明は上述した実施例の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
本発明は、複数の計算機を備えたブレードサーバ、ないしは計算機システムに関し、特に単一のI/Oデバイスを複数の計算機で共有する技術として有用である。
100…I/Oドロワ
110…I/Oスイッチ
111…MSMB(マスター−スレーブ間通信用メールボックス)
120…I/Oコントローラ
121…I/Oスイッチ制御ソフトウェア
122…マスターPFドライバ
130…I/Oデバイス
131…PF(Physical Function、物理機能)
132、133、134、135…VF(Virtual Function、仮想機能)
136…DMB(I/Oデバイス内メールボックス)
150A、150B、150C…サーバ(サーバ番号#0、1、2)
151A、151B、151C…CPU(プロセッサ)
152A、152B、152C…メモリ(主記憶装置)
153A、153B、153C…内部インターコネクト
154A、154B、154C…IOH(I/Oハブ)
160A、160B、160C…ゲストOS
161A、161B、161C…ハイパーバイザ
162A、162B、162C…スレーブPFドライバ
163A、163B、163C…VFドライバ
310…マスター側レジスタ
311A、311B、311C、311D…マスター利用権フラグ
312A、312B、312C、312D…要求ドアベル
313A、313B、313C、313D…応答ドアベル
314A、314B、314C、314D…メッセージバッファ
320A、320B、320C、320D…スレーブ側レジスタ(#0、1、2、3)(サーバ番号#0、1、2、3のサーバ用)
321A、321B、321C、321D…スレーブ利用権フラグ
322A、322B、322C、322D…要求ドアベル
323A、323B、323C、323D…応答ドアベル
324A、324B、324C、324D…メッセージバッファ
330…割込み発生部
340A、340B、340C、340D…利用権調停部
412…MIR(マスター役決定レジスタ)
462A、462B、462C…MS−PFドライバ(マスター/スレーブ兼用PFドライバ)
510、511、512、513、…サーバ可用性フラグ(#0〜3)520…マスター役サーバ番号レジスタ
530…マスタースナップショットレジスタ
540…マスター役交替要求ドアベル
810…メールボックスデバイス。
110…I/Oスイッチ
111…MSMB(マスター−スレーブ間通信用メールボックス)
120…I/Oコントローラ
121…I/Oスイッチ制御ソフトウェア
122…マスターPFドライバ
130…I/Oデバイス
131…PF(Physical Function、物理機能)
132、133、134、135…VF(Virtual Function、仮想機能)
136…DMB(I/Oデバイス内メールボックス)
150A、150B、150C…サーバ(サーバ番号#0、1、2)
151A、151B、151C…CPU(プロセッサ)
152A、152B、152C…メモリ(主記憶装置)
153A、153B、153C…内部インターコネクト
154A、154B、154C…IOH(I/Oハブ)
160A、160B、160C…ゲストOS
161A、161B、161C…ハイパーバイザ
162A、162B、162C…スレーブPFドライバ
163A、163B、163C…VFドライバ
310…マスター側レジスタ
311A、311B、311C、311D…マスター利用権フラグ
312A、312B、312C、312D…要求ドアベル
313A、313B、313C、313D…応答ドアベル
314A、314B、314C、314D…メッセージバッファ
320A、320B、320C、320D…スレーブ側レジスタ(#0、1、2、3)(サーバ番号#0、1、2、3のサーバ用)
321A、321B、321C、321D…スレーブ利用権フラグ
322A、322B、322C、322D…要求ドアベル
323A、323B、323C、323D…応答ドアベル
324A、324B、324C、324D…メッセージバッファ
330…割込み発生部
340A、340B、340C、340D…利用権調停部
412…MIR(マスター役決定レジスタ)
462A、462B、462C…MS−PFドライバ(マスター/スレーブ兼用PFドライバ)
510、511、512、513、…サーバ可用性フラグ(#0〜3)520…マスター役サーバ番号レジスタ
530…マスタースナップショットレジスタ
540…マスター役交替要求ドアベル
810…メールボックスデバイス。
Claims (15)
- I/Oドロワを介して、1台以上のI/Oデバイスを利用する複数のサーバを備えた計算機システムであって、
前記I/Oドロワは、複数の前記サーバと前記I/Oデバイスを接続するI/Oスイッチと、前記I/Oスイッチの管理を行うI/Oコントローラとを有し、
前記I/Oデバイスは、少なくとも1つ以上の物理的な機能(以下、PF)を有し、
複数の前記サーバのうちいずれか一つ、或いは前記I/Oコントローラは、前記PFにアクセスするマスターPFドライバを有し、
前記マスターPFドライバを有する前記サーバ以外の複数の前記サーバは、スレーブPFドライバを有し、
前記スレーブPFドライバは、前記PFを利用するために前記マスターPFドライバに要求を転送し、要求を受けた前記マスターPFドライバが前記PFにアクセスする、
ことを特徴とする計算機システム。 - 請求項1記載の計算機システムであって、
前記I/Oスイッチは、前記マスターPFドライバ及び前記スレーブPFドライバからアクセス可能なメールボックスを有し、
前記スレーブPFドライバは、前記メールボックスに前記マスターPFドライバへの前記要求を書込み、
前記マスターPFドライバは、前記メールボックスから前記スレーブPFドライバが書込んだ要求を読出し、前記I/Oデバイスの前記PFにアクセスする、
ことを特徴とする計算機システム。 - 請求項1記載の計算機システムであって、
前記マスターPFドライバと前記スレーブPFドライバは、それぞれマスター/スレーブ兼用PFドライバ(以下、MS−PFドライバ)で構成され、前記MF−PFドライバは、前記マスターPFドライバとして動作するマスターモード、あるいは前記スレーブPFドライバとして動作するスレーブモードで動作し、
前記I/Oスイッチは、複数の前記MS−PFドライバからアクセス可能なメールボックスを有し、
前記スレーブモードで動作している前記MS−PFドライバは、前記メールボックスに前記マスターモードで動作している前記MS−PFドライバへの要求を書込み、
前記マスターモードで動作して前記MS−PFドライバは、前記メールボックスに書き込まれた前記要求を読出し、読み出した前記要求に従い前記I/Oデバイスの前記PFにアクセスする、
ことを特徴とする計算機システム。 - 請求項3に記載の計算機システムであって、
前記I/Oスイッチは、前記マスターモードで動作している前記MS−PFドライバを有する前記サーバの識別子を保持するマスター役決定領域を有し、
前記スレーブモードでの動作中の前記MS−PFドライバは、前記マスター役サーバ決定領域を読み出して、前記マスターモードで動作している前記MS−PFドライバを有する前記サーバを認識する、
ことを特徴とする計算機システム。 - 請求項4に記載の計算機システムであって、
前記I/Oスイッチ内の前記マスター役サーバ決定領域は、前記複数のサーバの可用性を保持するサーバ可用性フラグを記憶し、
前記スレーブモードで動作している前記MS−PFドライバは、前記マスターモードで動作している前記MS−PFドライバを有する前記サーバに障害が発生したことを検出した場合、前記サーバ可用性フラグを読み出して、利用可能な前記サーバのサーバ識別子を認識する、
ことを特徴とする計算機システム。 - 請求項1に記載の計算機システムであって、
前記マスターPFドライバ及び前記スレーブPFドライバからアクセス可能なメールボックスを備えたメールボックスデバイスを更に有し、
前記スレーブPFドライバは、前記メールボックスに前記マスターPFドライバへの前記要求を書込み、
前記マスターPFドライバは、前記メールボックスから前記スレーブPFドライバが書込んだ要求を読出し、前記I/Oデバイスの前記PFにアクセスする、
ことを特徴とする計算機システム。 - I/Oデバイスを利用する複数のサーバと、複数の前記サーバと前記I/Oデバイスを接続するI/Oスイッチと、前記I/Oスイッチの管理を行うI/Oコントローラとを有する計算機システムのI/Oデバイス制御方法であって、
前記I/Oデバイスに少なくとも1つ以上の物理的な機能(以下、PF)を備え、
複数の前記サーバのうちいずれか一つ、或いは前記I/Oコントローラに、前記PFにアクセスするマスターPFドライバを備え、
前記マスターPFドライバを有する前記サーバ以外の複数の前記サーバは、スレーブPFドライバを備え、
前記スレーブPFドライバは、前記PFを利用するために前記マスターPFドライバに要求を転送し、
前記要求を受けた前記マスターPFドライバは前記PFにアクセスする、
ことを特徴とするI/Oデバイス制御方法。 - 請求項7記載のI/Oデバイス制御方法であって、
前記マスターPFドライバと前記スレーブPFドライバを、それぞれマスター/スレーブ兼用PFドライバ(以下、MS−PFドライバ)で構成し、
前記MF−PFドライバは、前記マスターPFドライバとして動作するマスターモード、または前記スレーブPFドライバとして動作するスレーブモードで動作し、
前記I/Oスイッチは、複数の前記MS−PFドライバからアクセス可能なメールボックスを備え、
前記スレーブモードで動作している前記MS−PFドライバは、前記メールボックスに前記マスターモードで動作している前記MS−PFドライバへの要求を書込み、
前記マスターモードで動作して前記MS−PFドライバは、前記メールボックスに書き込まれた前記要求を読出し、前記I/Oデバイスの前記PFにアクセスする、
ことを特徴とするI/Oデバイス制御方法。 - 請求項8に記載のI/Oデバイス制御方法であって、
前記I/Oスイッチは、前記マスターモードで動作している前記MS−PFドライバを有する前記サーバの識別子を保持するマスター役決定領域を有し、
前記スレーブモードでの動作中の前記MS−PFドライバは、前記マスター役サーバ決定領域を読み出して、前記マスターモードで動作している前記MS−PFドライバを有する前記サーバを認識する、
ことを特徴とするI/Oデバイス制御方法。 - 請求項9に記載のI/Oデバイス制御方法であって、
前記I/Oスイッチ内の前記マスター役サーバ決定領域に、前記複数のサーバの可用性を保持するサーバ可用性フラグを記憶し、
前記スレーブモードで動作している前記MS−PFドライバは、前記マスターモードで動作している前記MS−PFドライバを有する前記サーバに障害が発生したことを検出した場合、前記サーバ可用性フラグを読み出して、利用可能な前記サーバのサーバ識別子を認識する、
ことを特徴としたI/Oデバイス制御方法。 - 請求項9に記載のI/Oデバイス制御方法であって、
前記マスター/スレーブ兼用ドライバは、利用可能な前記サーバのサーバ識別子に基づいて、前記MS−PFドライバをマスターモードに切り替えるか否かを判断する、
ことを特徴とするI/Oデバイス制御方法。 - 請求項11に記載のI/Oデバイス制御方法であって、
前記I/Oスイッチは、前記マスターモードで動作している前記MS−PFドライバの内部状態を保存するためのマスタースナップショット記憶領域を備え、
前記マスターモードで動作している前記MS−PFドライバは、その内部状態を定期的、又は障害発生時に前記マスタースナップショット記憶領域に書込む、
ことを特徴とするI/Oデバイス制御方法。 - 複数のサーバが1台以上のI/Oデバイスを利用可能とするI/Oドロワであって、
複数の前記サーバと前記I/Oデバイスを接続するI/Oスイッチと、前記I/Oスイッチの管理を行うI/Oコントローラとを備え、
前記I/Oスイッチは、複数の前記サーバと前記I/Oコントローラからアクセス可能なメールボックスを有する、
ことを特徴とするI/Oドロワ。 - 請求項13に記載のI/Oドロワであって、
前記I/Oデバイスは、少なくとも1つ以上の物理的な機能(以下、PF)を有し、
前記PFをアクセスするためのPFドライバが、複数の前記サーバのうちいずれか一つ、或いは前記I/Oコントローラに備えられるマスターPFドライバと、前記マスターPFドライバを備えた前記サーバ以外の複数の前記サーバに備えられるスレーブPFドライバとからなり、
前記メールボックスには、前記マスターPFドライバによって前記要求が読み出される、前記PFを利用するための前記スレーブドライバからの要求が書き込まれ、
ことを特徴とするI/Oドロワ。 - 請求項13に記載のI/Oドロワであって、
前記メールボックスは、前記I/Oスイッチの外部に設置されたメールボックスデバイスに形成され、複数の前記サーバと前記I/Oコントローラは、前記メールボックスデバイスに形成された前記メールボックスをアクセスする、
ことを特徴とするI/Oドロワ。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010190765A JP2012048546A (ja) | 2010-08-27 | 2010-08-27 | 計算機システム、i/oデバイス制御方法、及びi/oドロワ |
US13/180,633 US20120054393A1 (en) | 2010-08-27 | 2011-07-12 | Computer system, i/o device control method, and i/o drawer |
EP11177661A EP2423826A2 (en) | 2010-08-27 | 2011-08-16 | Computer system, i/o device control method, and i/o drawer |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010190765A JP2012048546A (ja) | 2010-08-27 | 2010-08-27 | 計算機システム、i/oデバイス制御方法、及びi/oドロワ |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2012048546A true JP2012048546A (ja) | 2012-03-08 |
Family
ID=44719260
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010190765A Pending JP2012048546A (ja) | 2010-08-27 | 2010-08-27 | 計算機システム、i/oデバイス制御方法、及びi/oドロワ |
Country Status (3)
Country | Link |
---|---|
US (1) | US20120054393A1 (ja) |
EP (1) | EP2423826A2 (ja) |
JP (1) | JP2012048546A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013150792A1 (ja) * | 2012-04-06 | 2013-10-10 | 日本電気株式会社 | I/oデバイス共有システムおよびi/oデバイス共有方法 |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102932174B (zh) * | 2012-10-25 | 2015-07-29 | 华为技术有限公司 | 一种物理网卡管理方法、装置及物理主机 |
US9244877B2 (en) * | 2013-03-14 | 2016-01-26 | Intel Corporation | Link layer virtualization in SATA controller |
CN103609077B (zh) * | 2013-06-18 | 2017-02-22 | 华为技术有限公司 | 用于数据传输的方法、装置和***以及物理网卡 |
US10089129B2 (en) * | 2014-06-30 | 2018-10-02 | International Business Machines Corporation | Supporting flexible deployment and migration of virtual servers via unique function identifiers |
US10223159B2 (en) | 2015-02-18 | 2019-03-05 | Red Hat Israel, Ltd. | Configuring virtual machine interfaces to provide access to a requested logical network based on virtual function availability and a virtual function capability option |
US9792138B2 (en) | 2015-02-18 | 2017-10-17 | Red Hat Israel, Ltd. | Virtual machine migration to hyper visors with virtual function capability |
US9720720B2 (en) | 2015-02-25 | 2017-08-01 | Red Hat Israel, Ltd. | Dynamic management of assignment and number of virtual functions on SR-IOV capable hypervisors |
CN106982133B (zh) * | 2016-01-18 | 2020-12-29 | 中兴通讯股份有限公司 | 一种更改虚拟网卡配置信息的方法、设备及*** |
CN111562897B (zh) * | 2020-05-12 | 2022-05-27 | 超越科技股份有限公司 | 刀片式服务器的显示切换方法和*** |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08249254A (ja) * | 1995-03-15 | 1996-09-27 | Mitsubishi Electric Corp | マルチコンピュータシステム |
JP2003345730A (ja) * | 2002-05-29 | 2003-12-05 | Fujitsu Component Ltd | インタフェース装置、インタフェース装置におけるファームウェアの更新方法、及びそのプログラム |
JP2009301162A (ja) * | 2008-06-11 | 2009-12-24 | Hitachi Ltd | 計算機システム、デバイス共有方法及びそのプログラム |
JP2010092336A (ja) * | 2008-10-09 | 2010-04-22 | Hitachi Ltd | ストレージシステム及び通信方法 |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7383555B2 (en) * | 2004-03-11 | 2008-06-03 | International Business Machines Corporation | Apparatus and method for sharing a network I/O adapter between logical partitions |
US7058738B2 (en) | 2004-04-28 | 2006-06-06 | Microsoft Corporation | Configurable PCI express switch which allows multiple CPUs to be connected to multiple I/O devices |
US7979592B1 (en) * | 2007-02-09 | 2011-07-12 | Emulex Design And Manufacturing Corporation | Virtualization bridge device |
JP5272265B2 (ja) | 2008-09-29 | 2013-08-28 | 株式会社日立製作所 | Pciデバイス共有方法 |
US8032660B2 (en) * | 2008-12-30 | 2011-10-04 | Intel Corporation | Apparatus and method for managing subscription requests for a network interface component |
US8146082B2 (en) * | 2009-03-25 | 2012-03-27 | Vmware, Inc. | Migrating virtual machines configured with pass-through devices |
US20100275219A1 (en) * | 2009-04-23 | 2010-10-28 | International Business Machines Corporation | Scsi persistent reserve management |
US8341749B2 (en) * | 2009-06-26 | 2012-12-25 | Vmware, Inc. | Preventing malware attacks in virtualized mobile devices |
US8340120B2 (en) * | 2009-09-04 | 2012-12-25 | Brocade Communications Systems, Inc. | User selectable multiple protocol network interface device |
US8473947B2 (en) * | 2010-01-18 | 2013-06-25 | Vmware, Inc. | Method for configuring a physical adapter with virtual function (VF) and physical function (PF) for controlling address translation between virtual disks and physical storage regions |
US8239655B2 (en) * | 2010-01-18 | 2012-08-07 | Vmware, Inc. | Virtual target addressing during direct data access via VF of IO storage adapter |
US9213567B2 (en) * | 2010-10-01 | 2015-12-15 | Futurewei Technologies, Inc. | System and method for controlling the input/output of a virtualized network |
JP5585844B2 (ja) * | 2011-03-25 | 2014-09-10 | 株式会社日立製作所 | 仮想計算機の制御方法及び計算機 |
-
2010
- 2010-08-27 JP JP2010190765A patent/JP2012048546A/ja active Pending
-
2011
- 2011-07-12 US US13/180,633 patent/US20120054393A1/en not_active Abandoned
- 2011-08-16 EP EP11177661A patent/EP2423826A2/en not_active Withdrawn
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08249254A (ja) * | 1995-03-15 | 1996-09-27 | Mitsubishi Electric Corp | マルチコンピュータシステム |
JP2003345730A (ja) * | 2002-05-29 | 2003-12-05 | Fujitsu Component Ltd | インタフェース装置、インタフェース装置におけるファームウェアの更新方法、及びそのプログラム |
JP2009301162A (ja) * | 2008-06-11 | 2009-12-24 | Hitachi Ltd | 計算機システム、デバイス共有方法及びそのプログラム |
JP2010092336A (ja) * | 2008-10-09 | 2010-04-22 | Hitachi Ltd | ストレージシステム及び通信方法 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013150792A1 (ja) * | 2012-04-06 | 2013-10-10 | 日本電気株式会社 | I/oデバイス共有システムおよびi/oデバイス共有方法 |
JPWO2013150792A1 (ja) * | 2012-04-06 | 2015-12-17 | 日本電気株式会社 | I/oデバイス共有システムおよびi/oデバイス共有方法 |
US9639489B2 (en) | 2012-04-06 | 2017-05-02 | Nec Corporation | I/O device sharing system and I/O device sharing method |
Also Published As
Publication number | Publication date |
---|---|
EP2423826A2 (en) | 2012-02-29 |
US20120054393A1 (en) | 2012-03-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2012048546A (ja) | 計算機システム、i/oデバイス制御方法、及びi/oドロワ | |
EP3798835B1 (en) | Method, device, and system for implementing hardware acceleration processing | |
JP5315209B2 (ja) | 冗長構成を生成するための周辺機器相互接続入出力仮想化デバイスの使用 | |
US8645974B2 (en) | Multiple partition adjunct instances interfacing multiple logical partitions to a self-virtualizing input/output device | |
US20050015430A1 (en) | OS agnostic resource sharing across multiple computing platforms | |
TW457437B (en) | Interconnected processing nodes configurable as at least one non-uniform memory access (NUMA) data processing system | |
US20220206969A1 (en) | Data forwarding chip and server | |
JP2016541072A (ja) | リソース処理方法、オペレーティング・システム、およびデバイス | |
US20220191153A1 (en) | Packet Forwarding Method, Computer Device, and Intermediate Device | |
AU2021269201B2 (en) | Utilizing coherently attached interfaces in a network stack framework | |
JP2015022553A (ja) | 計算機の制御方法及び計算機 | |
US11983136B2 (en) | PCIe device and operating method thereof | |
US11995019B2 (en) | PCIe device with changeable function types and operating method thereof | |
US10255203B2 (en) | Technologies for zero-copy inter-virtual-machine data movement | |
KR20220130518A (ko) | PCIe 디바이스 및 그 동작 방법 | |
EP4407952A1 (en) | Network storage method, storage system, data processing unit, and computer system | |
WO2020219810A1 (en) | Intra-device notational data movement system | |
EP2845110A1 (en) | Reflective memory bridge for external computing nodes | |
WO2021244500A1 (zh) | 一种备份状态确定方法、装置及*** | |
US10936219B2 (en) | Controller-based inter-device notational data movement system | |
US10853293B2 (en) | Switch-based inter-device notational data movement system | |
US20220124164A1 (en) | System and method to offload point to multipoint transmissions | |
US10762011B2 (en) | Reflective memory bridge for external computing nodes |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20130304 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20140325 |