JP5210730B2 - 仮想マシンモニタ及びマルチプロセッサシステム - Google Patents
仮想マシンモニタ及びマルチプロセッサシステム Download PDFInfo
- Publication number
- JP5210730B2 JP5210730B2 JP2008169803A JP2008169803A JP5210730B2 JP 5210730 B2 JP5210730 B2 JP 5210730B2 JP 2008169803 A JP2008169803 A JP 2008169803A JP 2008169803 A JP2008169803 A JP 2008169803A JP 5210730 B2 JP5210730 B2 JP 5210730B2
- Authority
- JP
- Japan
- Prior art keywords
- memory
- virtual server
- processor
- policy
- allocation
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Multi Processors (AREA)
Description
く見られる。このようなサーバの集約に際して有効となる手段が、サーバ分割により、複
数のオペレーティングシステムを1台のサーバ上で稼動させる方法である。サーバ分割に
は、ノード単位、あるいはプロセッサ(コア)やI/Oデバイスなどのコンポーネント単
位でハードウェアによる分割をサポートする物理分割方式と、ハイパバイザや仮想マシン
モニタと呼ばれるファームウェアによって実現される論理分割方式とがある。
提供する論理プロセッサ上で実行され、仮想マシンモニタにより複数の論理プロセッサが
物理プロセッサへマッピングされることにより、ノードよりも細かい単位に区画を分割で
きる。さらにプロセッサ(コア)に関しては複数の論理区画間で1つの物理プロセッサ(
コア)を時分割で切り替えながら実行することもできる。これにより、物理プロセッサ(
コア)の数よりも多くの論理区画を生成して同時に実行することが可能になる。論理分割
を目的とした仮想マシンモニタソフトウェアとしては特許文献1に記載されるような技術
が代表的である。
つ必要があるため本質的に集積しにくいI/Oデバイスに関しては数が減らせず、従来の
CPUとI/Oデバイスとのバランスが崩れていく傾向が見られる。I/Oデバイスの数
を増やすためには、I/Oスイッチを用いてスロットを増設するといった対策が考えられ
る。しかしI/OスイッチによってプロセッサやメモリとI/Oデバイスとの距離が離れ
ることでI/O性能を十分に引き出せないケースが出てきた。
専有させ、十分なI/O性能を確保するというアプローチが採られるようになってきてい
る。このような仮想サーバによるI/Oデバイスの専有をサポートする機能として、非特
許文献1に開示されるように、Intel社の制定しているVT−dなどが知られている。
プロセッサ・メモリ・I/Oデバイスといったリソースの配置が不均衡となる傾向にある
。このような不均衡なシステム上で性能や信頼性を確保するためには、物理位置情報を用
いたリソース配分が必要である。従来のOSでは、特定のプロセッサとメモリを対応付け
るAffinity制御という仕組みがあり、これをサポートするために物理位置情報を取得する
標準インタフェースとしてACPI(Advanced Configuration and Power Interface)が規
定されている(非特許文献2)。このaffinity制御では、OSあるいはアプリケーションが
どのCPUとメモリを使用するかという関係付けにより、リソースの割り当てを行う。
Iの仕組みを使って制御することができる。しかしI/Oデバイスは全アプリケーション
から共通的に参照されるリソースであるため、I/Oデバイスの物理位置情報を使ったAf
finity制御という概念は存在しなかった。実際、ACPIの中で規定されているSystem R
esource Affinity Table(SRAT)やSystem Locality Distance Information Table(
SLIT)では、プロセッサとメモリの物理的な位置情報のみが対象であり、I/Oデバ
イスの物理位置情報は管理の対象外である。
に割り付けようとすると、I/Oデバイスの物理位置情報は、仮想サーバの性能や信頼性
を確保する上で重要なパラメータとなる。しかし従来のACPIベースのインタフェース
では、I/Oの物理位置情報を取得する手段がなかった。
も、仮想サーバ上のゲストOSがその物理位置情報を正しく利用できない場合、ゲストO
SのAffinity制御が正しく働かず、結果として物理サーバと同等の性能や信頼性を確保で
きない、という問題点があった。
イスの物理位置情報を取得するインタフェースを持ち、取得した物理位置情報を使って仮
想サーバに対するリソースの割付を、指定されたポリシーに従って最適化することを目的
とする。さらに仮想マシンモニタが取得した物理位置情報を仮想サーバへと適切に変換し
て通知するインタフェースを持ち、ゲストOSを物理サーバ上で実行した時と同様のAffi
nity制御を仮想サーバ上のゲストOSに対しても実行可能にすることを目的とする。
を内部ネットワークで接続し、前記プロセッサとメモリ及びI/Oデバイスを仮想サーバ
に割り当てる仮想マシンモニタを備えたマルチプロセッサシステムであって、前記仮想マ
シンモニタは、前記マルチプロセッサシステムの前記プロセッサとメモリとI/Oデバイ
ス及びネットワークを含むハードウェアの物理的な位置情報を含むハードウェアの構成情
報を取得する物理ハードウェア情報取得部と、生成する仮想サーバのプロセッサの数とメ
モリ量とI/Oデバイス及びリソースの割り当てポリシーとを含む生成要求を受け付ける
受付部と、前記受け付けた生成要求に基づいてI/Oデバイスを前記仮想サーバに割り当
ててから、前記割り当てポリシーを満たすように前記プロセッサとメモリを前記仮想サー
バに割り当てる割り当て処理部と、を備える。
モリ及びI/Oデバイスの物理的な位置情報を前記仮想サーバに通知する通知部をさらに
備える。
情報を用いて仮想サーバに対するリソースの割り当てを、生成要求で指定されたリソース
の割当ポリシーに従って最適化することが可能となる。
ることで、物理サーバ上と同様の制御を仮想サーバ上で実現することができる。
、およびその上で動作する仮想マシンモニタとゲストOSとの関係を示したブロック図で
ある。
ジ)110、メモリコントローラ130、I/Oハブ160a、160bをモジュール間
接続I/F(インターフェース)200にて接続した構成を採る。なお、モジュール間接
続I/F200は、マルチプロセッサシステム100の内部ネットワークを構成する。こ
こでCPUソケット110とメモリコントローラ130間、CPUソケット110とI/
Oハブ160a、160b間、メモリコントローラ130とI/Oハブ160a、160
b間のモジュール間接続I/F200が必ずしも同じI/Fである必要はない。それらが
異なるI/Fであったとしても以下の説明には差異を生じない。なお、I/Oハブ160
a、160bの総称をI/Oハブ160とする。また、メモリコントローラ130やI/
Oハブ160の機能を搭載したチップセットが存在していても良い。さらに、図1に示す
ように、メモリコントローラ130がCPUソケット110上に搭載されたような構成で
あっても良い。CPUソケット110は1つ以上のCPUコア(プロセッサコア)120
を含む。メモリコントローラ130はメモリI/F140を介して1つ以上のDIMM(
Dual Inline Memory Module)150と接続する。I/Oハブ160はI/O接続I/F
170を介して1つ以上のI/Oアダプタ180a〜180fを搭載し、I/Oアダプタ
180a〜180fの先にはI/Oデバイス190dが接続される。さらにI/O接続I
/F170の先にI/OブリッジやI/Oスイッチがあり、多段のI/Oを構成していて
も良い。なお、I/Oアダプタ180a〜180fは、NICやHBA(Host Bus Ada
pter)などで構成され、これらの総称をI/Oアダプタ180とする。
上記各モジュール(物理的構成要素)の物理位置情報や接続情報をモジュール情報取得I
/F210を介して収集する。サービスプロセッサ220はマルチプロセッサシステム1
00のオプションとして外付けされる形で搭載されても良いし、I/Oデバイスの一つと
して搭載される形態でも良い。また、LANなどで接続された別のコンピュータ上にサー
ビスプロセッサ220の機能があっても良い。また、I/Oデバイスは、データの入出力
を行う装置で構成される。
プロセッサシステム100上のリソースを1つ以上の仮想サーバへと分割してゲストOS
360a〜360cに対して提供する。仮想マシンモニタ300はサービスプロセッサ2
20が収集したモジュールの物理構成情報と接続情報を、物理ハードウェア構成情報取得
インタフェース320を介して受け取る。なお、ゲストOS360a〜360cの総称を
ゲストOS360とする。
350によって仮想マシンモニタ300へと通知する。なお、ゲストOS360の起動時
(すなわち、仮想サーバの起動時)では、マルチプロセッサシステム100の管理者がコ
ンソール230で設定した論理ハードウェア要求I/F310を仮想マシンモニタ300
へ通知する。仮想マシンモニタ300は、仮想マシンモニタ300上にある物理−論理ハ
ードウェア割当表310などを参照し、論理ハードウェア要求I/F350に含まれるリ
ソース割当ポリシーを考慮した上で、必要な物理リソースの情報を物理−論理ハードウェ
ア割当インタフェース330を通じて取得する。仮想マシンモニタ300は、取得した物
理リソースの情報と、論理ハードウェア要求I/F310に基づいて物理リソースを論理
ハードウェアとして割り当てる論理ハードウェア割当処理部801を備える。仮想マシン
モニタ300が割り当てた物理リソースの情報は、仮想マシンモニタ300によって論理
ハードウェア構成情報へと変換され、論理ハードウェア構成情報通知I/F340を介し
てゲストOS360へと通知される。
用するコンソール230が接続され、仮想マシンモニタ300やサービスプロセッサ22
0に指令を与えたり、仮想マシンモニタ300やサービスプロセッサ220から処理の結
果を受信して出力装置に表示を行う。
さらに本第1実施形態におけるマルチプロセッサシステム100の構成をより詳細に説
明する。110a〜110dの4つのCPUソケットがモジュール間接続I/F200に
よってリング状に接続されている。それぞれのCPUソケット110はCPUコア120
を2つずつ持ち、マルチプロセッサシステム100全体では、8つのCPUコア120が
ある。以下の説明において、この8つのCPUコアを図中左からCPUコアの通し番号を
#0〜#7と呼ぶ場合がある。
リI/F140を有し、それぞれ4つのDIMM(メモリ)150が接続されている。こ
こでは後の説明を簡単にするために、各DIMM150は1GBで、1CPUソケット当
たり4GB、マルチプロセッサシステム全体では16GBのメモリを搭載しているとする
。以下の説明において、この16枚のDIMM150の通し番号を図中左からDIMM#
0〜#15と呼ぶ場合がある。
ずつのモジュール間接続I/F200を持ち、I/Oハブ160aはCPUソケット11
0aと110b、I/Oハブ160bはCPUソケット110cと110dとそれぞれ接
続している。I/Oハブ160はI/O接続I/F170をそれぞれ4つずつ持ち、I/
O接続I/F170の先にI/Oスロット175を備え、I/Oアダプタ180が接続さ
れている。
ット175の通し番号を図中左から番号を#0〜7とすると、I/Oスロット#0にはI
/Oアダプタ180aが、I/Oスロット#2にはI/Oアダプタ180bが、I/Oス
ロット#3にはI/Oアダプタ180cが、I/Oスロット#4にはI/Oアダプタ18
0dが、I/Oスロット#5にはI/Oアダプタ180eが、I/Oスロット#7にはI
/Oアダプタ180fがそれぞれ接続されている。この例ではI/Oスロット#1および
I/Oスロット#6には何も接続されていない。
ゲストOS 360は,仮想マシンモニタ300によって分割された論理サーバ370に割り当てられたI/Oデバイス190のいずれかの上にプログラムが存在し,論理サーバ370の起動時に370に割り当てられたメモリ150の上に展開され, 370に割り当てられたCPUコア300によって実行される。図64の例では,ゲストOS1 360aはメモリ150#5上に,ゲストOS2 360bはメモリ150#10上に,ゲストOS3 360cはメモリ150#13へと展開され,実行されている。なお,本例ではわかりやすいように一つのメモリモジュール上にゲストOS 360を配置した例を示したが,ゲストOSのサイズやメモリインタリーブの設定によっては複数のメモリモジュール上に分散配置されることもあり得る。
ロセッサシステム100の物理ハードウェア構成情報取得I/F320について示す。図
2は物理ハードウェア構成情報取得I/F320の内訳を示す。物理ハードウェア構成情
報取得I/F320は、物理コンポーネント構成表400、I/Oアダプタ構成表450
、コンポーネント間距離対応表500、物理ネットワーク構成表550の4種類の表(テ
ーブル)で構成される。これらのテーブルは、仮想マシンモニタ300が所定の周期また
は所定のタイミングで、サービスプロセッサ220がモジュール情報取得I/F210を
介して収集したハードウェアリソースの情報を問い合わせて生成(または更新)するもの
である。仮想マシンモニタ300が設定した物理ハードウェア構成情報取得I/F320
は、図1に示すI/Oハブ160の物理位置情報格納メモリ165またはメモリ150に
格納される。
の構成を示す。物理コンポーネント構成表400は、リソースの通し番号を示すリソース
#405、リソースの種類を示すリソース種別410、通し番号に対応するリソースの範
囲を示す範囲415、コンポーネント毎の通し番号を示すコンポーネント#420、コン
ポーネントの種類を示すコンポーネント種別425、通し番号で特定されたリソースの消
費電力430、このリソースを動作させるためのコンポーネントの消費電力435、から
構成される。
Oハブ160のように物理的に挿抜あるいは電源のon/offの対象となるオブジェク
トを指しており、複数のリソースが1つのコンポーネント#420上に接続され得る。本
実施形態の例では、CPUコア120やDIMM150はCPUソケット110というコ
ンポーネントに接続され、I/Oアダプタ180はI/Oハブ160というコンポーネン
トに接続される。メモリコントローラ130がCPUソケット110とは別の場合や、チ
ップセットが存在する場合などは、それらもまた独立したコンポーネントになり得る。物
理コンポーネント構成表400は、このようなリソースとコンポーネントとの包含関係を
示す表である。範囲415で示されるリソースがコンポーネント#420に含まれること
を示している。リソース種別410がメモリの場合は、対応するDIMM150の番号に
加えて、物理アドレスの範囲も示される。この例では1DIMM当たり1GBずつである
ため、0x0_0000_0000から0x0_3_FFFF_FFFFまでの16GB
が属するCPUソケットに応じて4分割されている。各リソースが稼動状態となった場合
の消費電力[W]が430に、リソースの土台となっているコンポーネントが稼動状態とな
った場合の消費電力が435に示される。例えばコア#0が稼動していてコア#1は稼動
していないとする。この場合リソースの消費電力はコア当たり20であるため20だが、
土台となるコンポーネントのCPUソケットの消費電力は物理コンポーネント構成表40
0によると80であるため、合計20+80=100がコア#0のみが稼動している場合
の消費電力となる。なお、ここでは物理コンポーネント構成表400のサイズを小さくす
るために範囲415で同じコンポーネントに属する複数のリソースをまとめて1エントリ
で示しているが、リソースごとに異なるエントリを使っても構わない。
セッサ220のROM221に予め設定したデータを用いる。なお、このROMにはI/
Oアダプタ180の消費電力や各コンポーネント間の帯域やレイテンシなどコンポーネン
トの性能に係る情報を格納しておく。
ルチプロセッサシステム100上の全てのI/Oアダプタ180分のエントリが存在し、
I/Oアダプタ180の通し番号を示すI/Oアダプタ#455、I/Oアダプタの識別
子を示すI/Oアダプタ460、このI/Oアダプタが装着されたI/Oスロット#46
5、I/Oアダプタの種類を示すアダプタ種別470、このI/Oアダプタの消費電力4
75の各項目から構成される。アダプタ種別470は、ネットワークインタフェースカー
ド(NIC)やホストバスアダプタ(HBA)といったアダプタの種類が記述される。
500は、マルチプロセッサシステム100上の全てのコンポーネントに対応するエント
リが存在し、コンポーネントの識別子を示すコンポーネント#420と、コンポーネント
の種類を示すコンポーネント種別425と、このコンポーネントと他のコンポーネントの
距離を示す対コンポーネント間距離510から構成される。対コンポーネント間距離51
0はまた全てのコンポーネント分だけ分けられており、コンポーネント#420のコンポ
ーネントから対コンポーネント間距離510のコンポーネントに到達するまでの距離を示
している。システム全体でN個のコンポーネントがある時、対コンポーネント間距離51
0はN×Nのマトリックスを構成する。通常、自分自身に到達する距離は0であると考え
られるので、このマトリックスの対角線部分には0が並ぶのが普通である。本実施形態で
はモジュール間接続I/F200の性能は全て等価であると仮定したため、何回モジュー
ル間接続I/F200を渡れば目的のコンポーネントまで辿り着くかという回数を距離と
している。この距離を、コンポーネントの物理的な位置情報として扱う。例えば、CPU
ソケット110aからI/Oハブ160bまでの距離は、図1において、CPUソケット
110aからCPUソケット110dまでの距離がモジュール間接続I/F200を1回
経由し、CPUソケット110dからI/Oハブ160bまででモジュール間接続I/F
200を1回経由するのでコンポーネント間の距離は合計2となる。
0にあるレイテンシ570の合計値を使って距離を示す、といった方法が考えられる。
CPUソケット110とメモリ150の距離は0であるためコンポーネント間距離対応表
500に含まれないが、メモリ150が内部ネットワーク(モジュール間接続I/F20
0)に接続されている場合では、メモリ150をコンポーネント#420に加え、各コン
ポーネント間の距離をコンポーネント間距離対応表500に設定すればよい。
ウェア構成情報取得I/F320の情報に基づいて生成することができる。なお、サービ
スプロセッサ220が物理ハードウェア構成情報取得I/F320の情報に基づいてコン
ポーネント間距離対応表500を生成し、仮想マシンモニタ300へ通知するようにして
もよい。
50は、マルチプロセッサシステム100上の全てのモジュール間接続I/F200に対
して、モジュール間接続I/F200の接続の通し番号を示すネットワーク#555と、
どのコンポーネント420aからどのコンポーネント420bをつないでいるのか、そし
てコンポーネント420aと420b間の帯域560とレイテンシ570を示す項目から
なる。本実施形態では、CPUソケット110間をつなぐネットワークの帯域560は6
なのに対して、CPUソケット110とI/Oハブ160の間をつなぐネットワーク帯域
560は半分の3であるとした。なお、帯域560の単位は、例えば[Gbps]であり、
レイテンシ570の単位は、例えば、[nsec]である。
ービスプロセッサ220は、モジュール情報取得I/F210を介して各リソース・コン
ポーネントから収集する。そして、仮想マシンモニタ300はサービスプロセッサ220
から物理ハードウェア構成情報取得I/F320を取得する。物理ネットワーク構成表5
50やコンポーネント間距離対応表500のように、サービスプロセッサ220がモジュ
ール単体に問い合わせただけでは得られない情報に関しては、マルチプロセッサシステム
100の初期化時やあるいは構成変更時に、モジュール情報取得I/F210およびモジ
ュール間接続I/F200を介する問合せプロトコルを使って接続関係を自動的に検出す
る方法や、構成変更時に管理者が用いるシステム管理ツール(マルチプロセッサシステム
100の外に存在)の情報をサービスプロセッサ220等が不揮発性メモリ等に保存して
おき、その情報を元に構成する、といった方法が考えられる。
図7〜図9で、第一の実施形態における仮想サーバ1_370aの論理ハードウェア要
求I/F350と、それに対応する仮想サーバの構成を示す。
バ1_370a(図9、図16参照)の起動に必要なリソースを要求する論理ハードウェ
ア要求I/F350aの構成を示す。この論理ハードウェア要求I/F350aは、コン
ソール230で管理者が設定したものである。
サーバで稼動するゲストOS360の識別子を示すゲスト名352、仮想サーバに割り当
てるI/Oアダプタ353、仮想サーバに割り当てるCPUコア数354、仮想サーバに
割り当てるメモリ量355、仮想サーバに割り当てるリソースのポリシーを示すリソース
割当ポリシー356、仮想サーバの優先度357から構成される。仮想サーバ#351は
システム上の仮想サーバを識別するための識別子であり、必ずしも要求するゲスト側が設
定する必要はない。ゲスト名352は各ゲストOS360を識別するための情報で、例え
ばゲストOS360の種類(Windows(登録商標)/Linux等)もここに含ま
れる。I/Oアダプタ353は当該ゲストOSが要求するI/Oアダプタ180のリスト
である。ここではI/Oアダプタ180aと180cを要求している。CPUコア数35
4はゲストOS360aが必要なCPUコアの数である。ここでは4コア必要としている
。メモリ量355はゲストOS360aが必要とするメモリ量である。ここでは4GB分
必要としている。リソース割当ポリシー356はリソースを割り当てる際のポリシーを示
しており、本発明におけるキーとなるパラメータである。リソース割当ポリシー356と
しては、例えば、次のようなポリシーが考えられる。
・性能優先:コンポーネント間の距離を短くするような配置を選ぶ
*CPU−メモリ優先:CPUとメモリ間の距離が短くなるようにする(CPUのメモ
リアクセスが多い場合に有効)
*CPU−I/O優先:CPUとI/Oデバイス間の距離が短くなるようにする(I/
O割り込みが多い場合などに有効)
*I/Oデバイス−メモリ優先:I/Oデバイスとメモリ間の距離が短くなるようにす
る(I/OデバイスからのDMA転送が多い場合などに有効)
*CPU−I/Oデバイス−メモリ優先:各リソースを近くに配置するようにする(仮
想サーバの全体の性能をバランスさせる場合)
・信頼性優先:仮想サーバ間の共通のコンポーネント・ネットワークが少なくなるように
する
・帯域優先:ネットワークの実効帯域が大きくなるようにする
・省電力優先:システム全体の消費電力が小さくなるようにする
本実施形態の以下の説明では、設定するポリシーの一例を性能優先のうちCPU−I/
O優先としている。ただし、仮想サーバ1(360a)はマルチプロセッサシステム10
0上の最初の仮想サーバであるため、基本的に要求したリソースは獲得できる可能性が高
い。優先度357は、仮想サーバ間で要求したリソースが競合した場合にどの仮想サーバ
を優先するかを決めるために使うパラメータである。優先度を示す一例としては、ここで
は整数で値が大きいほど優先度が高いことを示すとした。ただし、第一の実施形態では全
ての仮想サーバは等しい優先度を持つとする。
高いプライマリーポリシーと優先度の低いセカンダリーポリシーを与え、プライマリーポ
リシーを満たす構成の中でさらにセカンダリーポリシーをなるべく満たすような構成を選
択してもよい。さらに複数のポリシーに数値で重み付けを与えるようなインタフェースも
考えられる。ここでは説明の簡略化のために、ポリシーは一つだけとした。
基づいて仮想マシンモニタ300の論理ハードウェア割当処理部801が物理リソースの
割り当てを行った結果に対応した物理−論理ハードウェア割当表310の構成と内容を示
している。なお、仮想マシンモニタ300がハードウェアリソースを割り当てる処理につ
いては、後述の図55〜図63で詳述する。
ーバ#351、当該仮想サーバの起動状態を示すon/off311、当該仮想サーバが
使用するリソースを示す使用リソース#としてI/Oアダプタ312、CPUコア313
、メモリ314、使用コンポーネント#315、使用ネットワーク#316から構成され
る。本実施形態では、論理ハードウェア要求I/F350aに従い、I/Oアダプタ#1
、3、CPUコア#0、1、2、3、DIMM#4、5、6、7を仮想サーバ1_370
aに割り当てている。また、使用リソース#のメモリ314には対応する物理アドレスが
0x1_0000_0000から4GB分となっている(この0x1_0000_000
0を仮想サーバ1のベースアドレスと呼ぶことがある)。また、これらのリソースが搭載
されたコンポーネントの識別子として110a、110b、160aが使用コンポーネン
ト#315に設定され、接続に使用するネットワーク#として#1、5、6が使用ネット
ワーク#316に設定された例を示している。
310を生成する具体的な手順については、後述する。
割当表310に基づいて、仮想マシンモニタ300の論理ハードウェア割当処理部801
がマルチプロセッサシステム100上に割り当てた仮想サーバ1_370aを示す。図中
点線で囲まれた部分は図1のリソースのうち仮想サーバ1_370aに割り当てられたリ
ソースを示す。
以下、図10〜17で、本第1実施形態の動作について説明する。
って上記図9で示したように仮想サーバ1_370aが割り当てられた後で、次の仮想サ
ーバ2に対する論理ハードウェア要求I/F350bおよび350cを示している。論理
ハードウェア要求I/F350bと350cは、どちらも同じI/Oアダプタ353、C
PUコア数354、メモリ量355を要求している。違いはリソース割当ポリシー356
のみで、論理ハードウェア要求I/F350bにおいては「CPU−メモリ優先」となっ
ているのに対して、論理ハードウェア要求I/F350cにおいては「I/O−メモリ優
先」となっている。以下の例では、これらのポリシーの違いにより、異なるリソースが割
り当てられる様子を示す。
I/F350に対して、仮想マシンモニタ300の論理ハードウェア割当処理部801が
割り当てを行った結果の2通りの物理−論理ハードウェア割当表310を示している。ど
ちらもI/Oアダプタ312は#2で同じだが、使用CPUコア313とメモリ314が
異なっている。図12の物理−論理ハードウェア割当表310bの方ではCPUコア#4
、5とDIMM#8、9、10、11を割り当てているのに対して、図13の物理−論理
ハードウェア割当表310cではCPUコア#6、7とDIMM#0、1、2、3を割り
当てている。この2通り以外にもリソースの割り当て方は考えられるが、本質的に変わら
ない割り当て方は排除する等として、いくつか割り当て方の候補を絞り込む。
要求しているため、CPUソケット110cのCPUコア#4,#5と、CPUソケット
110cに接続されるメモリ#8〜11を仮想サーバ2へ割り当てて、リソースの距離を
0とすることでCPUとメモリの距離が短いものを選択している。一方、図11の論理ハ
ードウェア要求I/F350cでは、I/O−メモリ優先のポリシーを要求しているため
、I/Oデバイスとメモリの距離が最も短くなるように、I/Oアダプタ#2に最も近い
メモリ#0〜#3を選択している。このように、仮想マシンモニタ300の論理ハードウ
ェア割当処理部801は、要求されたポリシーに応じて、仮想サーバに割り当てるハード
ウェアリソースを最適化することができる。
ソース間の距離を計算したリソース間距離計算表600bを示している。リソース間距離
計算表600bは、仮想サーバの識別子(または連番)を示す仮想サーバの番号#351
と、各仮想サーバ番号#351ごとに、仮想サーバ内のリソース間の距離を計算するため
の表である。カテゴリ601には、リソース割当ポリシーに対応したCPU−メモリ、I
/O−メモリ、CPU−I/Oの3種類のカテゴリが存在する。それぞれのカテゴリ60
1ごとにリソースfrom602からリソースto603までのコンポーネント間距離6
04を、所属するコンポーネント#と、コンポーネント間距離対応表500に従って仮想
マシンモニタ300が計算する。この例では、CPUコア#4、#5とDIMM#8、9
、10、11はいずれも同一のコンポーネント110c上に搭載されているので、コンポ
ーネント間距離604は0となる。一方、I/Oアダプタ#2が搭載されたコンポーネン
ト160aと、DIMM#8、9、10、11が搭載されたコンポーネント110cとの
距離は、コンポーネント間距離対応表500に従うと2であるため、コンポーネント間距
離604は2となる。CPUコア#4、5とI/Oアダプタ#2との間の距離も同様に2
となる。最後にカテゴリ601ごとにコンポーネント間距離の総和605を計算する。こ
の例では、CPU−メモリは0、I/O−メモリは2、CPU−I/Oは4、となる。
間距離計算表600cを示している。CPUコア#6、#7の搭載されたコンポーネント
110dと、DIMM#0、1、2、3の搭載されたコンポーネント110aとの間の距
離は1なので、コンポーネント間距離604は1となる。一方I/Oアダプタ#2の搭載
されたコンポーネント160aとDIMM#0、1、2、3の搭載されたコンポーネント
110aとの間の距離は1なので、コンポーネント間距離604は1となる。最後にCP
Uコア#6、7の搭載されたコンポーネント110dとI/Oアダプタ#2の搭載された
コンポーネント160aとの距離は2なので、コンポーネント間距離604は2となる。
コンポーネント間距離の総和605は、CPU−メモリが2、I/O−メモリが1、CP
U−I/Oが4となる。
リソース割当ポリシーを最も満たす候補を選択する。350bにおける「CPU−メモリ
優先」の場合は、コンポーネント間距離の総和605のCPU−メモリの値が小さくなる
リソース割当を選ぶ。それに対して「I/O−メモリ優先」の場合は、コンポーネント間
距離の総和605のI/O−メモリの値が小さくなるリソース割当を選ぶ。物理−論理ハ
ードウェア割当表310bと310cを比べた場合、「CPU−メモリ優先」の場合は3
10b、「I/O−メモリ優先」の場合は310cのリソース割当がそれぞれ選択される
。
2_370bの構成図である。仮想サーバ2_370bは図中一点鎖線で示すように、C
PUソケット110cとそれに接続されたメモリ、およびI/Oアダプタ180bとから
構成される。
の構成図である。仮想サーバ2_370bは図中一点鎖線で示すように、CPUソケット
110d上のCPUコア#6、7と、CPUソケット110a上のDIMM#0、1、2
、3と、I/Oアダプタ180bとから構成される。
より、同じI/Oアダプタ・CPUコア数・メモリ量を要求した場合でも、異なるリソー
スが割り当てることができ、管理者の希望する仮想サーバを、自動的に構成することが可
能となる。
続いて第一の実施形態の第一の変形例を示す。図18〜図20に、本変形例1における
仮想サーバ1_370aの論理ハードウェア要求I/F350dを図18に示し、この論
理ハードウェア要求I/F350dから仮想マシンモニタ300の論理ハードウェア割当
処理部801が割り当てを行った結果の物理−論理ハードウェア割当表310dを図19
に示し、および仮想サーバ1_370aの構成を図20に示す。I/Oアダプタとして1
80aと180cを要求しているのは前記第1実施形態と同じだが、上述の第一の実施形
態と違い、仮想サーバ1は2つのCPUコアと8GBのメモリを要求している。この要求
に対して仮想マシンモニタ300の論理ハードウェア割当処理部801は要求ポリシーで
あるCPU−I/O優先のポリシーから図19、20に示すようなリソースの割当を行っ
た。
理ハードウェア要求I/F350eによる仮想サーバ2のリソース要求を行い、図22に
示す論理ハードウェア要求I/F350fによる仮想サーバ2のリソース要求を行った場
合を示す。仮想サーバ2は、前記第一の実施形態と同じく、I/Oアダプタ180bとC
PUコア数2、4GBのメモリを要求している。それに対して、図21の論理ハードウェ
ア要求I/F350eではリソース割当ポリシー356として「CPU−メモリ優先」を
、350fではリソース割当ポリシー356として「CPU−I/O優先」を指定してい
る。
0e、310fの仮想サーバ2に対する異なるリソース割当の例で、仮想マシンモニタ3
00の論理ハードウェア割当処理部801が割り当てを行った結果である。物理−論理ハ
ードウェア割当表310eではCPUコアとメモリが同一のCPUソケット110c上に
割り当てられているのに対して、物理−論理ハードウェア割当表310fではCPUコア
はCPUソケット110a上に、DIMMはCPUソケット110d上に割り当てられて
いる。
に従ってリソース間距離計算表600e、600fを計算した結果である。図25のリソ
ース間距離計算表600eではコンポーネント間距離の総和605はCPU−メモリが0
、I/O−メモリが2、CPU−I/Oが4となる。一方、図26のリソース間距離計算
表600fではコンポーネント間距離の総和605はCPU−メモリが2、I/O−メモ
リが2、CPU−I/Oが2、となる。この結果、「CPU−メモリ優先」の場合にはC
PU−メモリのコンポーネント間距離の総和605が小さい310eの割当が、「CPU
−I/O優先」の場合には、CPU−I/Oのコンポーネント間距離の総和605が小さ
い310fの割当が選択される。
構成図である。仮想サーバ2_370bはCPUソケット110c上のCPUコア#4、
5とDIMM#8、9、10、11と、I/Oアダプタ180bとから構成される。
構成図である。仮想サーバ2_370bはCPUソケット110a上のCPUコア#0、
1と、CPUソケット110d上のDIMM#12、13、14、15と、I/Oアダプ
タ180bとから構成される。
続いて第一の実施形態の第二の変形例を示す。図29〜図31に、本変形例2における
仮想サーバ1_370aの論理ハードウェア要求I/F350gを図29に示し、物理−
論理ハードウェア割当表310gを図30に示し、および仮想サーバ1_370aの構成
を図31に示す。I/Oアダプタとしては180aと180cを要求しているのは前述の
第1実施形態と同じであるが、CPUコアは1つ、メモリも2GBしか要求していない。
また、ポリシーとしてはCPU−メモリ−I/O優先ということで、なるべく各コンポー
ネント間の距離が近くなるような配置を選ぶことになる。この場合は最初の仮想サーバで
あるため、まず必要なI/Oアダプタ180a、180cが接続されたI/Oハブ160
aに近いCPUソケット110aを選択し、110a上のCPUコアとDIMMを割り当
てることでこのポリシーは満足させることができる。
3つの論理ハードウェア要求I/F350を示している。全てに共通して、要求I/Oア
ダプタ353は180b、要求CPUコア数354は1、要求メモリ量355は2GB、
優先度は5で共通である。図32の論理ハードウェア要求I/F350hは リソース割
当ポリシー356として「信頼性優先」を指定している。図33の論理ハードウェア要求
I/F350iはリソース割当ポリシー356として「帯域優先」を指定している。図3
4の論理ハードウェア要求I/F350jはリソース割当ポリシー356として「省電力
優先」を指定している。以下、各ポリシーに従って、どのような構成が選択されるのかを
見ていく。
10を示している。図35の物理−論理ハードウェア割当表310hでは、CPUコアと
メモリとして、仮想サーバ1が使用しているのとは異なるCPUソケット110b上のC
PUコア#2とDIMM#4、5を割り当てて、要求された信頼性優先のポリシーを満足
している。一方、図36の物理−論理ハードウェア割当表310iにおいては、仮想サー
バ1が使用しているのと同じCPUソケット110a上のCPUコア#1とDIMM#2
、3を割り当てて、要求された帯域優先のポリシーを満足している。
の基準として前記リソース間距離計算表600に代わる別の指標が必要となる。
ワーク割当表650を示している。コンポーネント・ネットワーク割当表650は、複数
仮想サーバ間で共用しているコンポーネントやネットワーク、および実効ネットワーク帯
域を仮想マシンモニタ300の論理ハードウェア割当処理部801が調べるための表であ
り、仮想サーバの識別子または連番を示す仮想サーバ#351、仮想サーバ間で共用して
いるコンポーネントの識別子を示す共用コンポーネント#651、共用しているコンポー
ネントを使用するために利用しているネットワークの識別子を示す共用ネットワーク#6
52の項目と、さらに各仮想サーバ内で使用しているネットワーク全てに対応して、ネッ
トワーク#653、共用数654、実効帯域655、といった各項目から構成される。
ウェア割当表310hのリソース割当に対応した表である。共用コンポーネント#651
としてはI/Oハブ160aが該当し、共用ネットワーク#652は無しとなる。各ネッ
トワーク#653に対して共用していないため共用数654は1となる。実効帯域655
は、物理ネットワーク構成表550の各ネットワーク#555に対応した帯域560の値
を、共用数654(つまり仮想サーバの数)で割った値となる。この場合、共用数は1な
ので、ネットワークの帯域560の値がそのまま実効帯域655となる。
ウェア割当表310iのリソース割当に対応した表である。共用コンポーネント#651
としてはI/Oハブ160aとCPUソケット110aが該当する。また、共用ネットワ
ーク#652として、I/Oハブ160aとCPUソケット110aを接続するネットワ
ーク#5が相当する。この場合共用数654は2であるため、実効帯域655は元のネッ
トワークの帯域560の半分の値となる。
共用ネットワーク数がなるべく少なくなるような構成を選択する。この場合、仮想サーバ
1と仮想サーバ2の要求するI/Oアダプタが同じI/Oハブ160a上にあるため、共
用コンポーネント数を0とすることは不可能である。しかし物理−論理ハードウェア割当
表310hと310iにそれぞれ対応したコンポーネント・ネットワーク割当表650h
、650iを比較した場合、図35に示した物理−論理ハードウェア割当表310hに対
応する方が共用コンポーネント数が少ないことがわかる。従って要求されたポリシーが「
信頼性優先」である図32の論理ハードウェア要求I/F350hの要求に対しては、図
35に示した物理−論理ハードウェア割当表310hの割当が選択される。
るべく大きくなるような構成を選択する。この場合、図37のコンポーネント・ネットワ
ーク割当表650hと650iを比較すると、コンポーネント・ネットワーク割当表65
0hの構成の方が実効帯域が大きい。従ってポリシーが「帯域優先」である論理ハードウ
ェア要求I/F350iの要求に対しては、実効帯域が最大となる図37の物理−論理ハ
ードウェア割当表310hの割当が選択される。
ードウェア割当表310hに対応した割当リソース消費電力計算表700hを示している
。本表は仮想サーバ単位ではなく、システム全体で使用されているリソースとコンポーネ
ントに対して仮想マシンモニタ300によって構成され、対象のハードウェアがリソース
かコンポーネントかを示すカテゴリ701、リソース種別/コンポーネント種別を示す7
02、使用リソースまたはコンポーネントの識別子を示す使用リソース/コンポーネント
#703、各リソース毎の消費電力を示す消費電力704、そして消費電力の総和705
から構成される。リソースとしてはCPUコア、メモリ、I/Oスロット、I/Oアダプ
タの各項目があり、使用されているリソースが列挙されていく。また、消費電力704は
、物理コンポーネント構成表400のリソース消費電力430、およびI/Oアダプタ構
成表450の消費電力475の項目を参照し、それぞれの値を設定する。カテゴリ701
がコンポーネントのエントリでは、各リソースを使用する際に必要となるコンポーネント
が列挙され、コンポーネントの消費電力704は、物理コンポーネント構成表400のコ
ンポーネント消費電力435に従って設定される。消費電力の総和705は、消費電力7
04の総和として仮想マシンモニタ300によって計算される。
費電力計算表700iを示している。使用しているリソースの数自体は物理−論理ハード
ウェア割当表310hと310iで変わらないため、リソースの項目は使用しているリソ
ースの番号#こそ違うもののほとんど同じある。違いが出るのはコンポーネントの項目で
、物理−論理ハードウェア割当表310hでは使用するコンポーネントは合計3つであっ
たが、物理−論理ハードウェア割当表310iでは使用するコンポーネントは合計2つと
なっている。このため、消費電力の総和705を比較すると、図39の割当リソース消費
電力計算表700hでは345[W]という値なのに対して700iでは265[W]という
値になっている。
った場合、仮想マシンモニタ300は消費電力の総和705がなるべく小さくなるような
割当方法を選択する。従って、ポリシーが「省電力優先」である図34の論理ハードウェ
ア要求I/F350jの要求に対しては、仮想マシンモニタ300の論理ハードウェア割
当処理部801は図36の物理−論理ハードウェア割当表310iの割当を選択する。
成図である。
成図である。
ス及びコンポーネントの発熱量を用いても良い。
ここで、第1の実施形態における、論理ハードウェア構成要求I/F350から物理−
論理ハードウェア構成表310を生成する手順について、図55〜62を用いて詳しく説
明する。
ハードウェア割当処理全体のフローチャートを示している。まず、ゲストOS360に要
求されたI/Oアダプタを割り当て、さらに未割当のCPU・メモリの中から選んで割り
当て、要求されたポリシーに従って評価を行い、最も要求されたポリシーに近いCPU・
メモリの組み合わせを選ぶ、という手順となる。
801は、物理−論理ハードウェア割り当て表310に、仮想サーバ351のエントリを
確保する。ステップ805へと進む。
353の割り当て要求が専有か共有かを判定する。判定の結果専有であればステップ81
0へ、共有であればステップ830へと進む。
に他の仮想サーバに割り当てられていて割り当て不可である場合はステップ820へ、割
り当て可能であればステップ830へと進む。
ップである。エラー応答後、ステップ890へと進む。
830のサブルーチンのフローは図56に示す。このサブルーチンの完了後、ステップ8
40へと進む。
Ф)に設定するステップである。ここで割り当て候補CPU841と割り当て候補メモリ
842は、それまでの組み合わせの中で最も割り当てポリシーに近いCPUとメモリの組
み合わせの候補を示す。この時点ではまだCPU・メモリは選んでいないため、空集合(
Ф)とする。ステップ850へと進む。
を選択する処理である。CPU/メモリ選択処理850のサブルーチンのフローは図57
に示す。このサブルーチンの完了時、エラー応答があった場合はステップ820へと進む
。そうでない場合はステップ860へと進む。
ーに従った評価を行うステップである。ポリシー評価860のサブルーチンのフローは図
58に示す。このサブルーチンの完了後、ステップ870へと進む。
テップである。まだ残っている場合はステップ850へと戻る。そうでない場合はステッ
プ880へと進む。
ェア割当表310の仮想サーバ351へ割り当てる処理である。CPU/メモリ割当処理
880のサブルーチンのフローは図63に示す。このサブルーチンが完了すると論理ハー
ドウェア割当処理は完了となる。
テップ810で割り当てるリソースが足りなかった場合)に、物理−論理ハードウェア割
当表310の仮想サーバ351のエントリを抹消するステップである。このエントリの抹
消後、論理ハードウェア割当処理は完了となる。
900へと進む。
応するI/Oアダプタ#455をI/Oアダプタ構成表450から選択し、物理−論理ハ
ードウェア構成表310の仮想サーバ351のエントリの使用I/Oアダプタ312へ追
加するステップである。ステップ901へ進む。
アダプタ構成表450から選択し、物理コンポーネント構成表400のリソース種別41
0がI/OスロットのエントリからI/Oスロット#465に対応するエントリを探し、
対応するコンポーネント420を物理−論理ハードウェア構成表310の仮想サーバ35
1のエントリの使用コンポーネント315へ追加するステップである。ステップ902へ
進む。
る。まだ割り当てていないアダプタが残っている場合はステップ900へ戻る。そうでな
い場合はI/Oアダプタ割り当て処理830は完了となる。
905へと進む。
54とメモリ量355が割り当て可能かどうか判定するステップである。割り当て不可能
である場合、ステップ907へと進む。割り当て可能ならばステップ906へと進む。
50aで要求されたCPUコア数354とメモリ量355を満たすCPUコアとメモリを
選び、仮割当CPU851と仮割当メモリ852に設定するステップである。これにより
CPU/メモリ選択処理850は完了となる。
処理850は完了となる。
と進む。
従って条件分岐を行うステップである。割り当てポリシー356がCPU−メモリ優先、
CPU−I/O優先、I/O−メモリ優先、CPU−I/O−メモリ優先のいずれかであ
る場合、ステップ920へと進む。ポリシー356が信頼性優先である場合、ステップ9
30へと進む。ポリシー356が帯域優先である場合、ステップ940へと進む。ポリシ
ー356が省電力優先である場合、ステップ950へと進む。
ーを示す。このサブルーチンの完了後ステップ911へと進む。
ーを示す。完了後ステップ911へと進む。
了後ステップ911へと進む。
了後ステップ911へと進む。
うかを判定するステップである。空集合(Ф)である場合、ステップ913へ進む。そう
でない場合、ステップ912へ進む。
方が小さいかどうかを判定するステップである。ここでポリシー値とは、各割当ポリシー
356に従って、割り当てたリソース・コンポーネントの構成を定量的に評価するための
指数であり、小さい値である程より要求されたポリシーに近いと定義する。仮割当ポリシ
ー値853の方が割当候補ポリシー値843よりも小さい場合にはステップ913へと進
む。そうでない場合、ポリシー評価860は完了する。
3を、それぞれ割当候補CPU841、割当候補メモリ842、割当候補ポリシー値84
3へと代入するステップである。この処理によって、割当候補CPU841、割当候補メ
モリ842、割当候補ポリシー値843には、これまで割り当てた中で最もポリシー値が
小さな組み合わせのCPU・メモリの組み合わせが保持される。この処理により、ポリシ
ー評価860は完了する。
値853の値を引き継ぐ形で設定されまており、初回のステップ912では割当候補ポリ
シー値843の初期値は不定となるが、初回は図55のステップ840において、割当候
補CPU841と割当候補メモリ842がФに設定されるので、ステップ911の判定に
て必ずステップ913へと向かうことになり、ステップ912は通過しない。なお、割当
候補ポリシー値843を所定の最大値で初期化しておいてもよい。
プ921へと進む。
アダプタ353と、仮割当CPU851と、仮割当メモリ852とを使って、リソース間
距離計算表600を作成するステップである。具体的には、
(1) 各リソースの所属するコンポーネントを物理コンポーネント構成表400より求
める。
(2) 各コンポーネント間の距離をコンポーネント間距離対応表500に従い、リソー
ス間距離計算表600のコンポーネント間距離604へと設定する。
(3) カテゴリ601別にコンポーネント間距離604の合計を求めΣ605へと代入
する。
といった処理から構成される。次に、ステップ922へと進む。
て条件分岐を行うステップである。ポリシー356がCPU−メモリ優先である場合、ス
テップ923へと進む。ポリシー356がCPU−I/O優先である場合、ステップ92
4へと進む。ポリシー356がI/O−メモリ優先である場合、ステップ925へと進む
。ポリシー356がCPU−I/O−メモリ優先である場合、ステップ926へと進む。
対応するΣ605を仮割当ポリシー値853とするステップである。これによりコンポー
ネント間距離算出920は完了する。
対応するΣ605を仮割当ポリシー値853とするステップである。これによりコンポー
ネント間距離算出920は完了する。
対応するΣ605を仮割当ポリシー値853とするステップである。これによりコンポー
ネント間距離算出920は完了する。
合計を仮割当ポリシー値853とするステップである。これによりコンポーネント間距離
算出920は完了する。
ップ931へと進む。
仮割当CPU851と、仮割当メモリ852とを使った仮想サーバ351を含む、全ての
割当済みの仮想サーバに対して、コンポーネント・ネットワーク割当表650を作成する
ステップである。具体的には、
(1) 各リソースの所属するコンポーネントを物理コンポーネント構成表400より求
める。
(2) 異なる仮想サーバ間で共用されるコンポーネントを共用コンポーネント#651
へと設定する。
(3) 共用コンポーネント#の数を共用数654へと設定する。
といった処理から構成される。ステップ932へと進む。
ステップ932は、コンポーネント・ネットワーク割当表650の仮想サーバ351に対
応する共用数654を仮割当ポリシー値853とするステップである。これによりコンポ
ーネント共用数算出930は完了する。
と進む。
仮割当CPU851と、仮割当メモリ852とを使った仮想サーバ351を含む、全ての
割当済みの仮想サーバに対して、コンポーネント・ネットワーク割当表650を作成する
ステップである。具体的には、
(1) 各リソースの所属するコンポーネントを物理コンポーネント構成表400より求
める。
(2) コンポーネント間で使用するネットワークを物理ネットワーク構成表550より
求め、ネットワーク#653へと設定する。
(3) 異なる仮想サーバ間で共用されるネットワーク#653共用ネットワーク#65
2へと設定する。
(4) 各ネットワークの帯域を物理ネットワーク構成表550の帯域560より求め、
これを共有数654で割った値を実効帯域655へと設定する、
といった処理を含む。ステップ942へと進む。
対応する実効帯域655のマイナスを仮割当ポリシー値853とするステップである。こ
こでポリシー値853は小さいほどより要求したポリシーに近いと定義されている。一方
、実効帯域の絶対値は大きいほど良い。そこで実効帯域の値をマイナスとした値を仮割当
ポリシー値853とすることで、最も実効帯域の大きな構成が最終的には選ばれるように
している。これにより、実行帯域算出940は完了である。
と進む。
仮割当CPU851と、仮割当メモリ852とを使った仮想サーバ351を含む、全ての
割当済みの仮想サーバに対して、割当リソース消費電力計算表700を計算するステップ
である。具体的には、
(1) 各リソースの所属するコンポーネントを物理コンポーネント構成表400より求
める。
(2) 物理コンポーネント構成表400から、割当済の全てのリソースのリソース消費
電力430およびコンポーネントについて消費電力を求め、計算表700の消費電力70
4へと設定。
(3)全ての消費電力704の合計を計算しΣ705へと設定。
といった処理を含む。ステップ952へと進む。
ポリシー値853とするステップである。これにより、消費電力算出950は完了する。
プ960へと進む。
想サーバ351のエントリの使用CPUコア313へ、割当候補メモリ842を使用メモ
リ314へ追加するステップである。ステップ961へと進む。
アのエントリからCPUコア313に対応するエントリを探し、対応するコンポーネント
420を物理−論理ハードウェア構成表310の仮想サーバ351のエントリの使用コン
ポーネント315へ追加し、同じくリソース種別410がメモリのエントリからメモリ3
14に対応するエントリの使用コンポーネント315へ追加するステップである。ステッ
プ962へと進む。
てたかどうか判定するステップである。まだ未割当の割当候補CPU841または割当候
補メモリ842が残っている場合はステップ960へと戻る。そうでなければCPU/メ
モリ割当処理880は完了する。
た論理ハードウェア要求I/F350から、物理−論理ハードウェア割当表310を作る
ことができる。
システム100内のコンポーネントの物理的な位置情報を示すコンポーネント間の距離を
取得して、コンポーネント間距離対応表500を予め設定し、また、物理的なネットワー
クの構成や各リソースの消費電力を取得して物理コンポーネント構成表400とI/Oア
ダプタ構成表450及び物理ネットワーク構成表を予め設定しておく。そして、仮想マシ
ンモニタ300は、コンソール230から仮想サーバの生成(または設定)要求である論
理ハードウェア要求I/F350を受け付けて、まず、要求されたI/Oアダプタ180
を選択し、要求された仮想サーバへI/Oアダプタ180の専有割当を行う。次に、仮想
マシンモニタ300は、仮想サーバに上記コンポーネント間距離対応表500や物理コン
ポーネント構成表400からリソースの物理的な位置情報や消費電力を参照し、専有割当
を行ったI/Oデバイスから、要求されるポリシーを満たすCPUとメモリを選択して仮
想サーバに割り当てることで、要求されたポリシーに対して最適の仮想サーバを提供する
ことができる。
ーバ毎にポリシーが異なっても、I/Oデバイス、CPUソケット、メモリの物理的な位
置情報から各仮想サーバに最適な構成を自動的に割り当てることが可能となり、仮想計算
機の可用性を向上させることが可能となるのである。
図43〜図48にて本発明の第2の実施形態を示す。なお、本第2の実施形態のマルチ
プロセッサシステム100の構成は、前記第1実施形態と同様である。
。論理ハードウェア要求I/F350kでは、4つのCPUコアと8GBのメモリ、I/
Oアダプタとして180dと180fを要求している。
ドウェア割当表310kを示している。図45に図1のマルチプロセッサシステム100
上に割り当てた仮想サーバ1_370aの配置を示す。図中点線で囲まれた部分が仮想サ
ーバ1_370aである。
ストOS1_360aはマルチプロセッサシステム100上のOSであり、上述のような
ACPIに準拠したCPUとメモリに関するAffinity制御の機能を持っているとする。Af
finity制御の機能により、ゲストOS360上のアプリケーションに対してCPUソケッ
ト110c上のCPUコア#4、5とDIMM#8、9、10、11を割り当てる、ある
いはCPUソケット110d上のCPUコア#6、7とDIMM#12、13、14、1
5を割り当てることにより、CPUコアからメモリへのアクセスのレイテンシを短くし、
性能向上を図る。しかしこのようなAffinity制御の機能を使うためには、ゲストOS1_
360aが仮想サーバ1のハードウェアの配置を知っている必要がある。そのために、仮
想マシンモニタ300からゲストOS360への構成情報通知I/F(論理ハードウェア
構成情報通知I/F340)が必要となる。
れは物理−論理ハードウェア割当表310から二次的に作られる情報であり、CPUコア
120の識別子または連番を示すホストCPUコア#751、割り当てたメモリ150の
物理アドレスの始点を示すホスト物理アドレスベース752、および割り当てたメモリ1
50の量を示すホスト物理アドレス範囲753から成る。しかしこの情報をそのままゲス
トOS1_360aに対して通知しても、ゲストOS1_360aは正しくAffinity制御
を行うことはできない。なぜならば、仮想マシンモニタ300がゲストOS360aに割
り当てたマルチプロセッサシステム100上のホスト物理アドレスベースと、ゲストOS
1_360aにおけるゲスト物理アドレスベースとは異なるからである。
アドレスベースの0x2_0000_0000に対してゲストOS1_360aを割り当
てた場合、ゲスト物理アドレスベースの0x0_0000_0000がホスト物理アドレ
スベースの0x2_0000_0000に相当するようにアドレスのずれが生じる。従っ
て、論理ハードウェア構成情報をゲストOS1_360aに対して通知する場合には、こ
のずれを考慮して通知する必要がある。
ア構成情報通知I/F340を示す。論理ハードウェア構成情報通知I/F340は、ゲ
ストOS360に割り当てたCPUコア120の識別子または連番を示すゲストCPUコ
ア#341、ゲストOS360に割り当てたベースアドレスを示すゲスト物理アドレスベ
ース342、ゲストOS360に割り当てたアドレス範囲を示すゲスト物理アドレス範囲
343から成る。図47においてゲストCPUコア#341は、ゲストOS360内で0
から順番に付け直す。ゲスト物理アドレスベース342は、ホスト物理アドレスベース7
52から、仮想サーバ1_370aのベースアドレス0x2_0000_0000を引い
た値とする。ゲスト物理アドレス範囲343は、ホスト物理アドレス範囲753と同じ値
とする。以上により、ゲストOS1_360aがACPIに準拠したAffinity制御のため
に利用可能な使用論理ハードウェア構成情報が作られる。仮想マシンモニタ300は、こ
の論理ハードウェア構成情報通知I/F340を生成してゲストOS360に通知する。
なお、ここではCPU#341とメモリのアドレス範囲の組だけを通知するとしたが、よ
り高度な情報(たとえばリソース間距離計算表600のような距離の情報まで含めた)を
通知することも可能である。その場合でも、ホスト物理アドレスをゲスト物理アドレスへ
と変換する、という原則は変わらない。
スを仮想サーバに対して割り当てて、仮想サーバ上のゲストOS360は仮想マシンモニ
タ300が生成した論理ハードウェア構成情報通知I/F340を取得することで、使用
するコンポーネントの物理位置情報を正しく利用することが可能となって、ゲストOS3
60のAffinity制御を正しく動作させて、物理サーバと同等の性能や信頼性を確保するこ
とが可能となる。
図43〜図45および図49〜図54を使って、本発明の第三の実施形態を説明する。
前記第二の実施形態と同じく、図43に示す論理ハードウェア要求I/F350kに従っ
て、仮想マシンモニタ300が図44に示す物理−論理ハードウェア割当表310kのよ
うに仮想サーバ1_370aを割り当てた結果を図45に示す。
ーバ2に関する論理ハードウェア要求I/F350mがコンソール230から仮想マシン
モニタ300へ入力されたと仮定する。図49の論理ハードウェア要求I/F350mで
は、優先度357が10となっており、仮想サーバ1の論理ハードウェア要求I/F35
0kの優先度5よりも大きな値となっている。この場合、より優先度の高い仮想サーバ2
のリソース割当ポリシーを満たすように、仮想サーバ1に既に割り当てられたリソースを
再配置することが仮想マシンモニタ300に求められる。
モニタ300が仮想サーバ2_370bに対してリソースを割り当てた場合の物理−論理
ハードウェア割当表310mを示す。また、図51に仮想サーバ1_370aから割当済
みのリソースを一旦取り上げ、仮想サーバ2_370bに対してリソースを割り当てた後
で仮想サーバ1_370aに改めてリソースを割り当てた場合の物理−論理ハードウェア
割当表310nを示す。また、図52に図50の物理−論理ハードウェア割当表310m
に従って計算したリソース間距離計算表600mを示し、図53に図51の物理−論理ハ
ードウェア割当表310nに従って計算したリソース間距離計算表600nを示す。
O−メモリ優先」となっており、リソース間距離計算表600の「I/O−メモリ」のコ
ンポーネント間距離の総和605を比較すると、図52の計算表600mでは2なのに対
して図53の計算表600nでは1となっており、リソースの再配置を行った方が、より
仮想サーバ2のリソース割当ポリシーを満たす配置が可能となっていることがわかる。図
54に物理−論理ハードウェア割当表310nに従って仮想マシンモニタ300がマルチ
プロセッサシステム100上に仮想サーバ1_370aと仮想サーバ2_370bを割り
当てた様子を示す。
理ハードウェア要求I/F350から順にリソースを割り当てることで、より優先度の高
い要求に対して優先的にリソースを割り当てることが可能となる。ただし、リソースの再
配置を行う場合には、CPUおよびメモリの移動が必要となるケースがある。CPUの移
動に関しては、レジスタの内容のコピー、キャッシュやTLBのフラッシュ、等が必要に
なり、またメモリの移動に関してはメモリのコピーが必要となる。CPUやメモリの具体
的な移動手法については公知または周知の手法を適用すればよい。
サシステム100へ割り当てる際に、既に割り当てたリソースを一旦解放させてから、仮
想サーバの優先度の高い順にリソースの再割当を行うことで、より最適な仮想サーバを構
成することが可能となる。
仮想サーバに分割された計算機システムおよびその仮想マシンモニタに対して適用できる
。
110 CPUソケット
120 CPUコア
130 メモリコントローラ
140 メモリインタフェース
150 メモリ
160 I/Oハブ
170 I/O接続インタフェース
180 I/Oアダプタ
190 I/Oデバイス
200 モジュール間接続インタフェース
210 モジュール情報取得インタフェース
220 サービスプロセッサ
300 仮想マシンモニタ
310 物理−論理ハードウェア割当表
320 物理ハードウェア構成情報取得インタフェース
330 物理−論理ハードウェア割当インタフェース
340 論理ハードウェア構成情報通知インタフェース
350 論理ハードウェア要求インタフェース
400 物理コンポーネント構成表
500 コンポーネント間距離対応表
550 物理ネットワーク構成表
600 リソース間距離計算表
650 コンポーネント・ネットワーク割当表
700 割当リソース消費電力系計算表
750 物理HW構成情報
801 論理ハードウェア割当処理部
Claims (12)
- 複数のプロセッサと、複数のメモリと、複数のI/Oデバイスとを含むコンピュータリソースを備え、前記コンピュータリソースは、グループに分かれてそれぞれコンポーネントに所属し、それらコンポーネント同士を内部ネットワークで接続したマルチプロセッサシステム上で仮想サーバを稼働させる仮想マシンモニタであって、
前記仮想マシンモニタは、
前記所属の情報と、前記コンポーネント間の物理的な接続関係を示す情報と、を含むハードウェアの構成情報を取得する物理ハードウェア情報取得部と、
生成する仮想サーバに要求されるプロセッサの数及びメモリ量の情報と、I/Oデバイスの指定の情報と、リソースの割り当てポリシーと、を含む生成要求を受け付ける受付部と、
受け付けた前記生成要求で指定されるI/Oデバイスを前記仮想サーバに割り当て、かつ要求される数のプロセッサと要求される量のメモリを、受け付けた前記ポリシーと、前記所属の情報及び前記物理的な接続関係を示す情報から求められる評価指標と、に基づいて前記仮想サーバに割り当てる割り当て処理部と、
を備えたことを特徴とする仮想マシンモニタ。 - 前記生成要求には、さらに前記仮想サーバの優先度の情報が含まれ、
前記割り当て処理部は、
割り当て済みの仮想サーバよりも前記生成要求のあった新たな仮想サーバの優先度が高い場合には、割り当て済みの前記仮想サーバに既に割り当てたプロセッサとメモリの割り当てを一旦解放し、割り当てが解放されたプロセッサを含むプロセッサ群、及び割り当てが解放されたメモリを含むメモリ群から、前記新たな仮想サーバに割り当てるプロセッサ及びメモリを選択することを特徴とする請求項1に記載の仮想マシンモニタ。 - 前記物理ハードウェア情報取得部は、前記評価指標として、前記所属の情報及び前記物理的な接続関係を示す情報からプロセッサとメモリ間、及びプロセッサとI/Oデバイス間の距離を求め、
前記割り当て処理部は、
前記ポリシー及び前記評価指標に基づいて前記仮想サーバに割り当てる際に、前記プロセッサ、メモリ、及びI/Oデバイスの距離の総和が最小となるように、前記仮想サーバへプロセッサとメモリとを割り当てることを特徴とする請求項1に記載の仮想マシンモニタ。 - 前記生成要求には、さらに前記指定されるI/Oデバイスが前記仮想サーバに専有されるか否かの情報が含まれ、
前記割り当て処理部は、
前記生成要求に、前記指定されるI/Oデバイスが前記仮想サーバに専有される情報が含まれている場合には、前記指定されるI/Oデバイスが、既に他の仮想サーバに割り当てられているか否かの判定を行い、
既に他の仮想サーバに割り当てられている場合には、前記生成要求のあった仮想サーバの生成を取り止めることを特徴とする請求項1に記載の仮想マシンモニタ。 - 前記物理ハードウェア情報取得部は、前記評価指標として、前記所属の情報及び前記物理的な接続関係を示す情報からプロセッサとメモリ間の距離を求め、
前記割り当て処理部は、
前記リソースの割当ポリシーが、プロセッサのメモリへのアクセスを優先する場合には、前記ポリシー及び前記評価指標に基づいて前記仮想サーバに割り当てる際に、前記プロセッサとメモリ間の距離の総和が最小となるように、前記仮想サーバへプロセッサとメモリとを割り当てることを特徴とする請求項1に記載の仮想マシンモニタ。 - 前記物理ハードウェア情報取得部は、前記評価指標として、前記所属の情報及び前記物理的な接続関係を示す情報からプロセッサとI/Oデバイス間の距離を求め、
前記割り当て処理部は、
前記リソースの割当ポリシーが、プロセッサとI/Oデバイスのアクセスを優先する場合には、前記ポリシー及び前記評価指標に基づいて前記仮想サーバに割り当てる際に、前記プロセッサとI/Oデバイスの距離の総和が最小となるように、前記仮想サーバへプロセッサとメモリとを割り当てることを特徴とする請求項1に記載の仮想マシンモニタ。 - 前記物理ハードウェア情報取得部は、前記評価指標として、前記所属の情報及び前記物理的な接続関係を示す情報からメモリとI/Oデバイス間の距離を求め、
前記割り当て処理部は、
前記リソースの割当ポリシーが、メモリとI/Oデバイスのアクセスを優先する場合には、前記ポリシー及び前記評価指標に基づいて前記仮想サーバに割り当てる際に、前記メモリとI/Oデバイスの距離の総和が最小となるように、前記仮想サーバへプロセッサとメモリとを割り当てることを特徴とする請求項1に記載の仮想マシンモニタ。 - 前記物理ハードウェア情報取得部は、前記評価指標として、前記所属の情報及び前記物理的な接続関係を示す情報からプロセッサ、メモリ、及びI/Oデバイスの相互の距離を求め、
前記割り当て処理部は、
前記リソースの割当ポリシーが、仮想サーバの全体の性能を確保する場合には、前記ポリシー及び前記評価指標に基づいて前記仮想サーバに割り当てる際に、前記プロセッサ、メモリ、及びI/Oデバイスの距離の総和が最小となるように、前記仮想サーバへプロセッサとメモリとを割り当てることを特徴とする請求項1に記載の仮想マシンモニタ。 - 前記物理ハードウェア情報取得部は、前記評価指標として、前記所属の情報及び前記物理的な接続関係を示す情報からプロセッサ、メモリ、及びI/Oデバイスを接続する内部ネットワークの経路を求め、
前記割り当て処理部は、
前記リソースの割当ポリシーが、仮想サーバの信頼性を優先する場合には、前記ポリシー及び前記評価指標に基づいて前記仮想サーバに割り当てる際に、既に割り当てた仮想サーバが使用する内部ネットワークと、前記生成要求のあった新たな仮想サーバが使用する内部ネットワークで、重複する内部ネットワークの数の総和が最小となるように、前記新たな仮想サーバへプロセッサとメモリとを割り当てることを特徴とする請求項1に記載の仮想マシンモニタ。 - 前記物理ハードウェア情報取得部は、前記評価指標として、前記所属の情報及び前記物理的な接続関係を示す情報からプロセッサ、メモリ、及びI/Oデバイスを接続する内部ネットワークの経路を求め、
前記割り当て処理部は、
前記リソースの割当ポリシーが、内部ネットワークの帯域を優先する場合には、前記ポリシー及び前記評価指標に基づいて前記仮想サーバに割り当てる際に、既に割り当てた仮想サーバが使用する内部ネットワークと、前記生成要求のあった新たな仮想サーバが使用する内部ネットワークで、重複する内部ネットワークの帯域を仮想サーバの数で除した値を実効帯域とし、当該実効帯域が最大となるように、前記新たな仮想サーバへプロセッサとメモリとを割り当てることを特徴とする請求項1に記載の仮想マシンモニタ。 - 前記物理ハードウェア情報取得部は、前記評価指標として、前記所属の情報及び前記物理的な接続関係を示す情報から、前記プロセッサとメモリと、I/Oデバイスと、該プロセッサ、該メモリ、及び該I/Oデバイスの各々が所属するコンポーネントの消費電力とをそれぞれ求め、
前記割り当て処理部は、
前記リソースの割当ポリシーが、消費電力を優先する場合には、前記ポリシー及び前記評価指標に基づいて前記仮想サーバに割り当てる際に、既に割り当てた仮想サーバのプロセッサ、メモリ、I/Oデバイス、及びコンポーネントの消費電力と、前記生成要求のあった新たな仮想サーバが使用するプロセッサ、メモリ、I/Oデバイス、及びコンポーネントの消費電力の総和が最小となるように、前記新たな仮想サーバへプロセッサとメモリとを割り当てることを特徴とする請求項1に記載の仮想マシンモニタ。 - 前記コンポーネントは、プロセッサソケット、またはI/Oハブであることを特徴とする請求項1に記載の仮想マシンモニタ。
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008169803A JP5210730B2 (ja) | 2007-11-28 | 2008-06-30 | 仮想マシンモニタ及びマルチプロセッサシステム |
US12/222,227 US8819675B2 (en) | 2007-11-28 | 2008-08-05 | Virtual machine monitor and multiprocessor system |
EP08014080A EP2065804A1 (en) | 2007-11-28 | 2008-08-06 | Virtual machine monitor and multi-processor system |
KR1020080079105A KR101090651B1 (ko) | 2007-11-28 | 2008-08-12 | 가상 머신 모니터 및 멀티프로세서 시스템 |
CN2008102106429A CN101446928B (zh) | 2007-11-28 | 2008-08-13 | 虚拟机器监视器 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007307626 | 2007-11-28 | ||
JP2007307626 | 2007-11-28 | ||
JP2008169803A JP5210730B2 (ja) | 2007-11-28 | 2008-06-30 | 仮想マシンモニタ及びマルチプロセッサシステム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2009151745A JP2009151745A (ja) | 2009-07-09 |
JP5210730B2 true JP5210730B2 (ja) | 2013-06-12 |
Family
ID=40742614
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008169803A Expired - Fee Related JP5210730B2 (ja) | 2007-11-28 | 2008-06-30 | 仮想マシンモニタ及びマルチプロセッサシステム |
Country Status (3)
Country | Link |
---|---|
JP (1) | JP5210730B2 (ja) |
KR (1) | KR101090651B1 (ja) |
CN (1) | CN101446928B (ja) |
Families Citing this family (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101068537B1 (ko) * | 2008-12-18 | 2011-09-28 | 한국전자통신연구원 | 가상화 플랫폼을 이용한 가상화 관리 장치 및 그 제어방법 |
JP4962921B2 (ja) | 2009-08-26 | 2012-06-27 | 日本電気株式会社 | コンピュータのメモリ再配置制御方法およびプログラム並びにコンピュータシステム |
FR2952731B1 (fr) | 2009-11-13 | 2011-11-04 | Bull Sas | Procede et dispositif d'optimisation d'execution d'applications logicielles dans une architecture multiprocesseur comprenant plusieurs controleurs d'entree/sortie et unites de calcul secondaires |
KR101277274B1 (ko) * | 2009-11-27 | 2013-06-20 | 한국전자통신연구원 | 자원 간의 물리적/논리적 관계를 맵핑하는 방법 및 장치 |
JP5720577B2 (ja) | 2009-12-04 | 2015-05-20 | 日本電気株式会社 | サーバ及びフロー制御プログラム |
US8898663B2 (en) * | 2009-12-16 | 2014-11-25 | Symantec Corporation | Storage visibility in virtual environments |
WO2011083505A1 (en) | 2010-01-05 | 2011-07-14 | Hitachi, Ltd. | Method and server system for testing and executing migration between virtual servers |
KR101334842B1 (ko) * | 2010-03-02 | 2013-12-02 | 한국전자통신연구원 | 가상화 지원 단말 플랫폼을 위한 가상머신 관리장치 및 방법 |
JP5600277B2 (ja) * | 2010-09-27 | 2014-10-01 | 株式会社日立システムズ | クラウドサービス再配置システムと方法およびプログラム |
CN102822800B (zh) | 2011-02-04 | 2017-02-22 | 松下电器(美国)知识产权公司 | 虚拟计算机***、器件共享控制方法 |
WO2012114398A1 (en) | 2011-02-24 | 2012-08-30 | Nec Corporation | Network system, controller, and flow control method |
JP5696891B2 (ja) * | 2011-03-31 | 2015-04-08 | 日本電気株式会社 | Io構成によるジョブスケジューリング方法 |
CN102915292B (zh) * | 2011-08-02 | 2015-12-09 | 北京大学 | 基于多核处理器的通信方法及其检测方法和控制方法 |
WO2013042271A1 (ja) | 2011-09-22 | 2013-03-28 | 富士通株式会社 | 電子計算機システム及び仮想マシン配置方法 |
WO2013072978A1 (ja) * | 2011-11-18 | 2013-05-23 | 株式会社日立製作所 | 計算機、仮想マシン配備方法及びプログラム |
KR101867960B1 (ko) | 2012-01-05 | 2018-06-18 | 삼성전자주식회사 | 매니 코어 시스템을 위한 운영체제 동적 재구성 장치 및 방법 |
US9626222B2 (en) * | 2012-01-17 | 2017-04-18 | Alcatel Lucent | Method and apparatus for network and storage-aware virtual machine placement |
WO2013162548A1 (en) * | 2012-04-25 | 2013-10-31 | Empire Technology Development, Llc | Certification for flexible resource demand applications |
JP5881852B2 (ja) * | 2012-11-15 | 2016-03-09 | 三菱電機株式会社 | 仮想計算機システム |
JP5945512B2 (ja) | 2013-02-13 | 2016-07-05 | 株式会社日立製作所 | 計算機システム、及び仮想計算機管理方法 |
JP5660149B2 (ja) * | 2013-03-04 | 2015-01-28 | 日本電気株式会社 | 情報処理装置、ジョブスケジューリング方法およびジョブスケジューリングプログラム |
WO2014186945A1 (zh) * | 2013-05-21 | 2014-11-27 | 华为技术有限公司 | 实现物理资源和虚拟资源对应的方法和基础输入输出*** |
US10229043B2 (en) * | 2013-07-23 | 2019-03-12 | Intel Business Machines Corporation | Requesting memory spaces and resources using a memory controller |
CN104811361B (zh) * | 2014-01-24 | 2018-06-15 | 新华三技术有限公司 | 一种生成虚拟化网络设备的方法和装置 |
JP6323101B2 (ja) | 2014-03-20 | 2018-05-16 | 富士通株式会社 | 配置制御プログラム、方法及び装置 |
WO2016056060A1 (ja) * | 2014-10-07 | 2016-04-14 | 株式会社日立製作所 | 計算機及びベクタの設定方法 |
KR101647099B1 (ko) * | 2014-12-18 | 2016-08-09 | 권영민 | 가상화 멀티 세션 지원을 위한 서버 구조 |
US9535606B2 (en) * | 2014-12-22 | 2017-01-03 | Intel Corporation | Virtual serial presence detect for pooled memory |
US20160179582A1 (en) * | 2014-12-23 | 2016-06-23 | Intel Corporation | Techniques to dynamically allocate resources for local service chains of configurable computing resources |
EP3391213A1 (en) * | 2015-12-18 | 2018-10-24 | Telefonaktiebolaget LM Ericsson (publ) | Method and arrangement for utilization of a processing arrangement |
CN106412075A (zh) * | 2016-10-14 | 2017-02-15 | 郑州云海信息技术有限公司 | 一种基于云计算的资源配置方法及装置 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001282560A (ja) * | 2000-03-31 | 2001-10-12 | Hitachi Ltd | 仮想計算機制御方法及びその実施装置並びにその処理プログラムを記録した記録媒体 |
US20030163651A1 (en) * | 2002-02-26 | 2003-08-28 | International Business Machines Corporation | Apparatus and method of transferring data from one partition of a partitioned computer system to another |
US6912625B2 (en) * | 2003-01-09 | 2005-06-28 | International Business Machines Corporation | Method, system, and computer program product for creating and managing memory affinity in logically partitioned data processing systems |
US20060253682A1 (en) * | 2005-05-05 | 2006-11-09 | International Business Machines Corporation | Managing computer memory in a computing environment with dynamic logical partitioning |
JP4702127B2 (ja) * | 2006-03-22 | 2011-06-15 | 日本電気株式会社 | 仮想計算機システム及びその物理リソース再構成方法並びにプログラム |
-
2008
- 2008-06-30 JP JP2008169803A patent/JP5210730B2/ja not_active Expired - Fee Related
- 2008-08-12 KR KR1020080079105A patent/KR101090651B1/ko not_active IP Right Cessation
- 2008-08-13 CN CN2008102106429A patent/CN101446928B/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2009151745A (ja) | 2009-07-09 |
CN101446928B (zh) | 2011-05-25 |
KR20090055459A (ko) | 2009-06-02 |
CN101446928A (zh) | 2009-06-03 |
KR101090651B1 (ko) | 2011-12-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5210730B2 (ja) | 仮想マシンモニタ及びマルチプロセッサシステム | |
EP2065804A1 (en) | Virtual machine monitor and multi-processor system | |
US9250947B2 (en) | Determining placement fitness for partitions under a hypervisor | |
RU2571366C2 (ru) | Виртуальная архитектура неоднородного доступа к памяти для виртуальных машин | |
KR100998298B1 (ko) | 하이퍼트랜스포트 환경에서 i/o 어댑터 lpar 구분 | |
JP6329318B2 (ja) | 情報処理装置 | |
US8782657B2 (en) | Dynamic creation and destruction of IO resources based on actual load and resource availability | |
US20140282584A1 (en) | Allocating Accelerators to Threads in a High Performance Computing System | |
CN112099941A (zh) | 实现硬件加速处理的方法、设备和*** | |
US10409519B2 (en) | Interface device, and computer system including interface device | |
US8615586B2 (en) | Discovery of logical images at storage area network endpoints | |
US10248460B2 (en) | Storage management computer | |
US9111046B2 (en) | Implementing capacity and user-based resource allocation for a shared adapter in a virtualized system | |
US11995019B2 (en) | PCIe device with changeable function types and operating method thereof | |
US11928070B2 (en) | PCIe device | |
JP2015504541A (ja) | マルチプロセッサ・コンピューティング・システムにおけるメモリ・アクセスを動的に最適化する方法、プログラム、及びコンピューティング・システム | |
JP5195756B2 (ja) | Pciデバイスのi/o空間要求抑止方法 | |
JP2008021252A (ja) | 計算機システム及びアドレス割当方法 | |
WO2017181851A1 (zh) | 一种bios启动方法及装置 | |
Ha et al. | Dynamic capacity service for improving CXL pooled memory efficiency | |
US9176669B2 (en) | Address resource mapping in a shared memory computer system | |
JP2011221634A (ja) | 計算機システム、論理区画管理方法及び論理分割処理プログラム | |
KR20170094911A (ko) | 반도체 장치의 동작 방법 및 반도체 시스템 | |
JP2008310610A (ja) | システム構成管理方法 | |
Wong | PCI express multi-root switch reconfiguration during system operation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20110523 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20120718 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120731 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120928 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20121204 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130111 |
|
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: 20130129 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130225 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160301 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160301 Year of fee payment: 3 |
|
LAPS | Cancellation because of no payment of annual fees |