JP2020052730A - Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム - Google Patents

Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム Download PDF

Info

Publication number
JP2020052730A
JP2020052730A JP2018181418A JP2018181418A JP2020052730A JP 2020052730 A JP2020052730 A JP 2020052730A JP 2018181418 A JP2018181418 A JP 2018181418A JP 2018181418 A JP2018181418 A JP 2018181418A JP 2020052730 A JP2020052730 A JP 2020052730A
Authority
JP
Japan
Prior art keywords
node
container
volume
virtual machine
storage
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.)
Granted
Application number
JP2018181418A
Other languages
English (en)
Other versions
JP6957431B2 (ja
Inventor
司 柴山
Tsukasa Shibayama
司 柴山
彰義 土谷
Akiyoshi Tsuchiya
彰義 土谷
智大 川口
Tomohiro Kawaguchi
智大 川口
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2018181418A priority Critical patent/JP6957431B2/ja
Priority to CN201910123837.8A priority patent/CN110955487A/zh
Priority to US16/298,584 priority patent/US11080080B2/en
Priority to US16/409,481 priority patent/US11080081B2/en
Publication of JP2020052730A publication Critical patent/JP2020052730A/ja
Priority to US17/389,679 priority patent/US11663029B2/en
Priority to JP2021164588A priority patent/JP7118230B2/ja
Application granted granted Critical
Publication of JP6957431B2 publication Critical patent/JP6957431B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • 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]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • 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
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0647—Migration mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0658—Controller construction arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0665—Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • 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]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • 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]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • 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]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Hardware Design (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】HCI環境において、ノードの計算機資源の上限を超えることなく、新規VM/コンテナやボリュームの作成するVM／コンテナおよびボリューム等のリソース配置決定方法を提供する。【解決手段】ハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定に関し、各ノード上で動作する、仮想マシン及びストレージコントローラが、共用する計算機資源の利用状況を管理し、利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する。【選択図】図１

Description

本発明は、ハイパーコンバージドインフラストラクチャ（HCI）環境でのVM／コンテナおよびデータ配置決定に関する技術である。
近年、ソフトウェア（例えば、OS）の層を追加することによって、ハードウェア（例えば、CPUおよび周辺機器）を仮想化して、ユーザからのハードウェアとのインターフェース方法の詳細を「隠す」技術である仮想化技術が広く用いられている。
この仮想化技術は、複数の仮想化コンピュータ（例えば、VM、コンテナ）が物理リソースを共有することを可能にし、１つの仮想化コンピュータによる非活動期間中に別の仮想コンピュータが共有リソースを利用して、物理デバイスを効率よく使用可能となりリソース管理コストが改善される。しかしながら、VMを搭載した多くのストレージネットワーク環境では、VMまたは仮想サーバがSAN内の同じファイルシステムを共有するため、輻輳やボトルネックが発生する可能性がある。複数のサーバによって構成されるシステムにおいて、ストレージIO負荷分散方法は、VMを異なる物理サーバに移動することによって負荷の分散する技術が、特許文献１に開示されている。
米国特許出願公開第２００９／０１７２６６６号明細書
特許文献１は、VMとストレージOSで計算機資源を共有する、所謂ハイパーコンバージド（HCI）環境での計算機資源の有効利用については言及されていない。即ち、VMで動作するアプリケーションによるデータを処理するための計算機資源と、ストレージOS（ストレージコントローラ）がアプリケーションからのデータのリード/ライトを処理するための計算機資源の双方を考慮して、どのノードにVMやボリューム等を配置すべきかについて言及されていない。
また、複数ノード間でデータの冗長化を行っている場合に、他のノードのストレージコントローラからの冗長化データのライト処理のためにストレージコントローラが利用する計算機資源を考慮した、VMやボリュームの配置については言及されていない。
そこで、本発明の目的は、HCI環境において、ノードの計算機資源の上限を超えることなく、新規VM/コンテナやボリュームを作成するVM／コンテナおよびボリューム配置決定方法およびストレージシステムを提供することを目的とする。
本発明は、上記の課題を解決するためのリソース配置決定方法の一例を挙げるならば、複数のノードを有し、複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、複数のノードの各ノードは、データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置とを含む計算機資源を有し、各ノード上で動作する、仮想マシン及びストレージコントローラが、共用する前記計算機資源の利用状況を管理し、管理部が、前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する。
本発明によれば、VM/コンテナ、ボリュームの条件に基づいて、ノードの計算機資源の上限を超えることなく、新規VM/コンテナやボリュームの作成をすることができる。
また、新規に作成するVM/コンテナやボリュームの条件を満たすノードがない場合であっても、既存のVM/コンテナやボリュームを移動した結果、条件を満たす計算機資源が確保できるノードがあった場合、条件を満たすように既存のVM/コンテナやボリュームを移動し、ノードの計算機資源の上限を超えることなく、新規にVM/コンテナやボリュームを作成することができる。
ノード障害時に、障害が発生したノード上に配置されていたVM、コンテナやボリュームを、ノードの計算機資源を超えることなく、新規に作成されるVM/コンテナやボリュームの配置先を算出し、再冗長化することができる。
マルチノード構成のストレージシステムで、データの冗長度に基づいて他ノードからのIOを考慮して、ノードで発生するIO量を計算して、VM/コンテナやボリュームの配置先を計算することができる。
システムの全体構成の概要説明図である。 システムの全体構成図である。 ノードのハードウェア構成図である。 複数のノードを用いたクラスタの論理構成を示した図である。 ノードのメモリに格納される各種プログラムと制御情報を示した図である。 ノードのメモリに格納されるストレージノード物理構成表を示した図である。 ノードのメモリに格納されるVM管理表を示した図である。 ノードのメモリに格納されるコンテナ管理表を示した図である。 ノードのメモリに格納されるアプリ管理表を示した図である。 ノードのメモリに格納されるストレージノード構成表を示した図である。 ノードのメモリに格納される容量稼働情報を示した図である。 ノードのメモリに格納されるIO量管理表を示した図である。 ノードのメモリに格納される性能稼働情報を示した図である。 ノードのメモリに格納されるノード単位稼働情報を示した図である。 新規作成VM/コンテナおよびボリュームの配置決定する処理フロー図である。 VM/コンテナ作成条件を満たすノード群を算出するフロー図である。 既存VM/コンテナの移動により条件を満たすか計算するフロー図である。 実施例２のノード障害時のVM/コンテナおよびボリューム配置を決定するフロー図である。 実施例３の異なる二つのノード内の二つのストレージコントローラによりペアを組んだ構成を示した図である。 実施例３のストレージコントローラの構成情報を示した図である。 実施例３のVM/コンテナ作成条件を満たすノード群を算出するフロー図である。 実施例３の既存VM/コンテナの移動により条件を満たすかを計算処理するフロー図である。 実施例４のノード障害時のVM/コンテナおよびボリュームの配置決定処理を示すフロー図である。 実施例５の新規作成VM/コンテナおよびボリュームの配置決定する処理フロー図である。 実施例５のVM/コンテナ作成条件を満たすノード群を算出するフロー図である。 実施例５の既存VM/コンテナの移動により条件を満たすか計算するフロー図である。 実施例６のシステムの全体構成図である。
＜明細書中の用語の定義＞
以下、本発明の実施の形態を、図を用いて説明する。各図において、同一の構成には同一の符号を付す。
以下、発明の実施の形態を、図面を参照して詳細に説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。
図面において示す各構成要素の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面に開示された位置、大きさ、形状、範囲などに限定されない。
以下の説明では、「テーブル」、「リスト」、「キュー」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」、「Ｒｅｇｉｏｎ」等の表現を用いるが、これらについてはお互いに置換が可能である。
同一あるいは同様な機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。
また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ、ＧＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えば記憶装置）および／またはインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、制御部であれば良く、特定の処理を行う専用回路（例えばＦＰＧＡやＡＳＩＣ）を含んでいてもよい。
プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
＜仮想化の概要＞
本発明が適用される「仮想化」について、以下説明する。
「仮想化」という用語は、コンピュータやオペレーティングシステム（OS）の領域、ストレージとネットワークの領域で多くの意味を持っている。ソフトウェア（例えば、OS）の層を追加することによって、ハードウェア（例えば、CPUおよび周辺機器）を仮想化して、ユーザからのハードウェアとのインターフェース方法の詳細を「隠す」ことができる。同様に、OSは、ソフトウェアの層（例えば、ハイパーバイザ）を追加することによって、OSとのインターフェース方法の詳細を「隠す」ように、仮想化することができる。ユーザは、特定のOSや特定のベンダーやハードウェアの特定の構成など、基盤となるインフラストラクチャに強く依存することなく、いくつかの機能を実行するためのコードを書くことができる。
「仮想マシン」または「VM」とは、実際のコンピュータ（例えば、CPU、メモリなど）のハードウェアリソースを仮想化または仮想化環境に変換する、仮想化環境における特定のソフトウェアベースのマシンの実装を意味する。本明細書では、「仮想マシン」を単に「VM」と表記する場合がある。実際のコンピュータと同じように、基本的な物理リソース上で独自のOSとアプリケーションを実行できる、完全に機能する仮想マシンをサポートする。仮想化は、コンピュータハードウェアまたはホストOS上にソフトウェアの薄い層を直接挿入することによって機能する。このソフトウェア層には、ハードウェアリソースを動的かつ透過的に割り当てる仮想マシンモニターまたは「ハイパーバイザ」が含まれている。複数のOSが単一の物理コンピュータ上で同時に実行され、ハードウェアリソースを互いに共有する。
近年、コンテナベースの仮想化技術が普及している。ホストのOS上で実行される仮想マシンを作成して独立した物理マシンを模倣する仮想マシンと比較して、コンテナはOSのカーネル上で、直接ユーザ空間で実行できるアプリケーションを仮想化する。コンテナ内から実行されるWebサーバやデータベースなどのアプリケーションでは、物理マシンとのインターフェースにエミュレーションレイヤーまたはハイパーバイザーレイヤーは必要がない。代わりに、"コンテナ化された"アプリケーションは、OSの通常のシステムコールを使用して機能することができる。このようにして、コンテナは仮想化されたゲストOSを必要としないため、コンテナは、仮想マシンより一般的に速い（例えば、転送が速く、ブートまたはロードが速い）OSレベルの仮想化を提供する。
仮想マシンやコンテナなどの仮想化テクノロジが広く採用されている理由の１つは、仮想アーキテクチャによって提供されるリソースの利点があるためである。仮想化がなければ、物理マシンが単一の専用OSに限定されている場合、専用OSによる非アクティブ期間中、物理マシンは有益な作業を実行するために使用されない。これは、現在コンピューティングリソースを待っている他の物理マシン上のユーザがいる場合、無駄で非効率的なものとなる。対照的に、仮想化は、複数の仮想化コンピュータ（例えば、VM、コンテナ）が物理リソースを共有することを可能にし、１つの仮想化コンピュータによる非アクティブ期間中に別の仮想コンピュータが共有リソースを利用して、物理デバイスを効率よく使用可能となりリソース管理コストが改善される可能性がある。
実施例１では、基本構成での処理を説明する。基本構成とは、各ノードのCPUやメモリ等の計算機資源を、ハイパーバイザを用いて論理的に分割したハイパーコンバージド構成のことを言う。
＜システム概要＞
図１は、システムの全体構成の概要説明図である。各ノード100には、ハイパーバイザ104が動作しており、物理的なノードの中に、仮想的なコンピュータ（バーチャルマシンVM）を作り出し、同じ物理ノード100内で複数の異なるOSを並列に実行する。
まず、実施例1が動作するシステムの構成について説明する。システムは、複数のノード100から構成され、各ノード100はCPU101、メモリ102、記憶装置であるドライブ103等の計算機資源を有する。実施例１の実施される環境は、一般的なサーバにコンピューティング機能とストレージ機能を統合し、シンプルな構成を実現した仮想化基盤として知られる、所謂ハイパーコンバージドインフラストラクチャ（HCI）環境である。HCI環境では、アプリケーションを動作させるアプリVM、コンテナとストレージコントローラを動作させるストレージVMが同一ノードに存在し、計算機資源（CPU,メモリなど）を共有する。本明細書では、一般サーバのようにIO命令を出すアプリVM、ストレージコントローラとして動作するストレージVM、およびコンテナを仮想化ソフトと呼ぶ。
従って、各ノード100は、仮想マシン(VM)及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御する。
アプリVMとコンテナを、単にVM/コンテナと記載することもあるし、ストレージコントローラとして動作するストレージVM（ストレージコントローラ）と対比して単にVM等と記載することもある。
各VM105上のOSはストレージコントローラによって提供されるボリューム経由で記憶装置ドライブへアクセスする。複数のノード100からなるマルチノード構成において、データを冗長化するために、ストレージコントローラの機能によりドライブから構成されるボリュームへライトされるデータは、他のノードのドライブへのライトが実行される冗長化処理を行う。冗長化処理は、例えば、ミラーリング、Erasure Coding技術を用いて実行される。図１において、実線で記載されるライト動作は、ストレージコントローラの機能によりドライブから構成されるボリュームへライトされる動作を示し、点線で記載されるライト動作は、他のノードのドライブへのライトが実行される冗長化処理を示す。
ボリュームへのインプット/アウトプット（IO）を実行するために、物理的には、ドライブへデータを書き込む、またはドライブからデータを読む動作のために、ストレージコントローラはノードのCPUを利用する。点線で示すように、別のノードから冗長化のために転送されたデータを書き込む場合のIO処理でも、ストレージコントローラとしてCPUを利用することとなる。
そのため、各ノードにおいて、アプリVMのIO量により、ストレージコントローラで必要となるCPU利用量の変動の方が、一般的には大きい。
HCI環境では、アプリVMとストレージコントローラVMが共有する計算機資源を考慮して各VMやボリュームを配置する必要があり、本発明では、例えばアプリVMとストレージVMが必要とする計算機資源が、各ノードの計算機資源内に収まるように、アプリVMとストレージVMやボリュームを配置する技術を提案する。尚、実施例１においては、アプリVMとしてコンテナが含まれる形態として説明する。
ストレージコントローラ側で必要なCPU利用量は、アプリVMによるデータR/WのIO量に基づいて、ストレージコントローラとして必要となるCPUリソースを計算する。このときに冗長化度合い（ミラーリング、Erasure Codingのユーザデータとデータ保護のためのパリティデータの比率)も考慮する必要があるが、実施例1では、冗長化によるIO量の計算の説明はしない。冗長化によるIO量の計算については、実施例３以降において説明する。
ボリュームおよびアプリVMの配置（デプロイ）する時に、全てのVMが利用するCPUのCPU利用量の和が、ノードのCPU利用量の上限に収まるようにVMとボリュームを配置する。配置できない場合は、既存のアプリVMとボリュームを別のノードに移動し、ボリュームおよびアプリVMを配置できるように、ノードの計算機資源の利用をシステム内で平準化する。
上記はCPU利用量の例であるが、アプリVMとストレージコントローラVMで共有するリソース（メモリ、 drive容量、NW帯域、etc.）の全てについて、同様に、各リソースの利用量が各ノードの上限値を超えることがないようにするため、各リソースについてボリュームおよびアプリVMを配置できるように、ノードの計算機資源の利用をシステム内で平準化する。
図１において、各ノード100では、アプリVMがノード内のドライブに対し、データの書き込みや読み出し（IO）処理107を実行している状態を示している。
ノード100aでは２つのアプリVMがIO処理を実行し、ドライブは2つのアプリVMからのIO処理を実行している。ノード100bでは、１つのアプリVMがIO処理を実行し、ドライブにIO処理を実行している。ノード100cではドライブに対するIO処理を実行していない。
アプリVM側とドライブ側のIO処理の合計は、ノード100aでは「２」、ノード100bでは「１」、ノード100cでは「０」となり、ノード間で負荷が偏っている状態である。
図１では、実施例1として、各ノード100がドライブCPU101、メモリ102、各VM105、ドライブ103等の計算機資源の稼働情報を収集106し、ノード100aが稼働情報に基づき、ノード間の負荷が平準化するようにボリュームとアプリVMを、ノード100cに配置するための配置計算を行い、実際にノード100cに新しいVMやボリュームを作成する配置実行処理108を行う方法について説明する。
図２は、システムの全体構成図である。図２に示したように、通常、複数のノード100によりクラスタ203を構成し、フロントエンドネットワーク201によりクライアントノード200と接続され、バックエンドネットワーク202によりクラスタを構成する複数のノード100が接続されている。但し、フロントエンドネットワーク201とバックエンドネットワーク202は同一のネットワークで構成されていても良く、フロントエンドネットワーク201とバックエンドネットワーク202の他に管理用ネットワークにより複数のノードが接続される構成であっても良い。
各ノード100では、ハイパーバイザが動作しており、ハイパーバイザ上に作成されたVM上でストレージコントローラ、アプリケーションやコンテナが動作している。
図３は、ノード100のノードのハードウェア構成図である。図３に示したように、各ノード100は、一般的な汎用サーバと同様の構成で、CPU101、メモリ102、記憶装置であるNVMeドライブ103a、SASドライブ103b、SATAドライブ103cとこれらを接続する内部バス302で構成される。さらに、外部装置とのデータの送受信等のためのネットワークI/F301を備えている。尚、CPU101、メモリ102は複数備えていてもよい。また、ドライブは、不揮発メモリ（SCM）や光ドライブであっても良い。また、ネットワークI/F301は、ファイバチャネル（FC）、イーサネット（Ethernet）（登録商標）の他、インフィニバンドでも良く、異なる種類のネットワークを用いても良い。
図４は、複数のノードを用いたクラスタの論理構成を示した図である。クラスタ内には、1以上のプール404がある。プールは、物理ドライブ103の容量を仮想的に管理したものである。プールは、ノード内のドライブのみを扱うノード内プール404aと異なるノードのドライブも管理する跨りプール404bがある。また、管理容易化のため、例えば、複数のノード内プールを組み合わせて、一つの跨りプールとするように、階層構造として管理しても良い。
プールの物理記憶領域は、ドライブ103を所定の小領域に分割し、分割された単位で管理する。ボリューム403は、プールから切り出して作成される。Thin Provisioning技術を用いる場合には、ボリューム403に対するライト要求に応じて、プール404から物理記憶領域がボリュームに対して割り当てられ、ライト処理を実行する。尚、ボリュームはプールを定義することなく、ボリュームに直接ドライブ103の物理記憶領域を割り当てるように構成することもできる。
データストア402は、ボリューム403から作成される。データストア402は仮想マシン（VM）のデータを格納するボリュームであって、VMの構成情報やOSが格納される。VM401は、データストア402から作成される。
ボリューム、データストア、VMの個数の関係は、特に決まったものはなく、例えば、（ボリューム：データストア：VM＝１：１：１でも良いし、１：１：N（Nは正の整数））であっても良い。これらの関係は、後述するストレージ管理プログラム502によって管理される。
図５は、ノード100のメモリ102に格納される各種プログラムと制御情報を示した図である。
各種プログラムとして、ストレージ制御プログラム501、ストレージ管理プログラム502、VM管理プログラム503、コンテナ管理プログラム504、アプリ管理プログラム514、稼働情報収集プログラム505がある。
各種制御情報として、ストレージノード物理構成表507、ストレージノード論理構成表508、VM管理表509、コンテナ管理表510、IO量管理表511、アプリ管理表515、性能稼働情報506、容量稼働情報512、ノード単位稼働情報513がある。
ストレージIO制御プログラム501は、VM/コンテナに提供するボリュームに対するIOの制御を行う（ストレージVM、ストレージコントローラと呼ぶ場合がある）。また、ストレージコントローラ間、ノード間のIOも制御する。また、ストレージIO制御プログラムが制御するIO量を計測する。
ストレージ管理プログラム502は、プール404やボリューム403の作成を実現し、ストレージリソースを管理する。
VM管理プログラム503は、データストア402やVM401を作成したり、VMを異なるノードに移行する。
コンテナ管理プログラム504は、コンテナを作成、管理する。Linux（登録商標）にその機能が付されているものがある。
アプリ管理プログラム514は、VM上で動作するアプリケーションを管理する。
ストレージノード物理構成表507は、各ノード100のCPU、メモリ、ドライブ、ポート等の物理資源を示す情報を管理する。詳細は図６で説明する。
ストレージ論理構成表508は、ノードのプールやボリューム等の論理ストレージ構成を示す情報を管理する。詳細は、図１０で説明する。
VM管理表509は、ノード、ボリュームとVMの構成及びVMに割り当てられる物理資源を管理する情報であり。詳細は、図７で説明する。
コンテナ管理表510は、VMとコンテナの関連およびコンテナに割当てられる資源を管理する情報である。詳細は、図８で説明する。
稼働情報収集プログラム505は、IO量や性能、容量といった各種稼働情報を定期的に収集する機能を実現する。VMの性能やIO量収集処理については、VM管理の一般的なハイパーバイザとハイパーバイザ管理ソフトの機能、およびノードについてはOS付属の一般的な機能（sar等）を利用する。容量収集処理は、一般的なストレージ管理の情報取得機能を利用する。
IO量管理表511は、各VMのリード/ライト量を時系列で管理する情報である。詳細は、図１２で説明する。
アプリ管理表515は、VM上で動作するアプリケーションに関する情報である。詳細は、図９に示す。
性能稼働情報506は、ノード及びVM毎に利用するリソースの利用量を示す。詳細は、図１３に示す。
容量稼働情報512は、ストレージリソースおよびVMの容量を時系列に示す。詳細は、図１１に示す。
ノード単位稼働情報513は、ノード単位でのVM/コンテナ等についてのCPU,メモリ等の計算機資源の利用状況を示す。詳細は、図１４に示す。
制御情報として、ノード間のデータの冗長性を確保するために、同一ノードに配置できないストレージコントローラ等の配置条件表を含めても良い。
これらの表は全ノードで常にコピーして同じ情報を保持しても良いし、事前に決められた１つ以上のノードだけに保持してもよい。また、各ノードに関する情報だけを各ノードに分散して保持してもよい。ストレージ管理プログラム502、VM管理プログラム503、コンテナ管理プログラム504は、各ノードで協調して動作してもよいし、全クラスタのうち、代表プログラムが１つ動作し、全てのクラスタの管理を実行してもよい。また、ノードとは異なる管理サーバ(図示せず)に、ノード単位稼働情報513、ストレージノード論理構成表508を格納し、ストレージ管理プログラム502、VM管理プログラム503、コンテナ管理プログラム504、アプリ管理プログラム514を動作させることにより、VMやコンテナ、ボリューム等の配置先ノードを決定することができる。本明細書では、ノード単位稼働情報513、ストレージノード論理構成表508に基づき、ストレージ管理プログラム502、VM管理プログラム503、コンテナ管理プログラム504、アプリ管理プログラム514によって実現される管理部によって、VMやコンテナ、ボリューム等の配置先ノードを決定する。即ち、管理部は、管理サーバあるいは複数のノードの内の少なくとも一つに実装されることとなる。
実施例１では１ノードの代表プログラムが動作する例を示す。
＜各種制御情報＞
図６は、ノード100のメモリ102に格納されるストレージノード物理構成表507の内容を示した図である。ストレージノード物理構成表507は、ストレージ管理プログラム502によって管理され、ストレージIO制御プログラム501によって参照される。
ストレージノード物理構成表507は、ノード物理リソース表601、CPU物理リソース表602、drive物理リソース表603及びポート物理リソース表604を含む。
ノード物理リソース表601は、ノードを一意に識別する識別子であるノードID6011に対し、各ノードが具備するCPUを一意に識別する識別子であるCPU_IDs6012、メモリ量を示すメモリ6013、ドライブを構成するディスクを一意に識別するディスク_ID6014、ノードのポートを一意に識別するポート_IDs6015を管理する。例えば、ノードID「１」は、CPU_IDが「１」で特定されるCPUと、メモリ量「100」のメモリと、ディスク_ID「１」のドライブと、ポート_ID「１」のポートを有する。これにより、各ノード（ストレージ）の物理構成を管理している。
CPU物理リソース表602は、CPUを一意に識別するCPU_ID6021、CPU_IDに対し、各CPUのコア数6022、周波数6023、ノードとの関連を示すノード_ID6025を管理する。尚、CPUはコア毎に別のIDで管理してもよい。例えば、CPU_ID「１」で示されるCPUは、コア数「１」、周波数「１」GHzで、ノード「１」に配置されていることを示す。
drive物理リソース表603は、ディスクを一意に識別するディスク_ID6031に対し、各ディスクの容量6032、ドライブの種別6033、ノードとの関連の情報であるノード_ID6035等を管理する。
ポート物理リソース表604は、ポートを一意に識別するポート_ID6041に対し、各ポートの種別（FC,iSCSI等）6042、速度6043、ノードとの関連の情報であるノード_ID6045などを管理する。尚、上記各IDは数字でも文字列でもよい。図６では表形式で説明したが、各項目の関係が管理できれば、ドキュメント形式等、他の形式で値を保持してよい。
図７は、ノードのメモリに格納されるVM管理表509の内容を示した図である。この制御情報は、VM管理プログラム503によって管理される。
VM管理表509は、VMを一意に識別する識別子VM_ID7011に対し、VMが配置されているノードを示すノードID7012、VMに対応するデータストアを一意に識別するデータストア_ID7013等の対応を管理する。役割7014は、対VMの役割を示す。例えば「ストレージ制御・管理用」、「VM管理用」、「コンテナ管理用」、「ユーザアプリケーション」などの値を取りうる。「ストレージ制御・管理用」、「VM管理用」、「コンテナ管理用」は一つにまとめて例えば「クラスタ管理用」としてもよい。
また、VMに割り当てられる計算機資源として、CPU、メモリ量、また、必要に応じて、driveを構成するディスク、ポート、ボリュームのIDを7015〜7019のそれぞれのカラムで管理する。
例えば、VM_ID「１」で示されるVMは、ノード_ID「１」に配置され、その役割は、「ストレージ制御・管理」であり、CPU_ID7015は「１」である。
CPUはコアごとに別のカラムとして管理してよい。計算機資源の情報は、IDの他、具体的に各VMに割り当てられる値を保持しても良い。図7のようなテーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。VM_ID等のIDは数字でも文字列でもよい。
図８は、ノードのメモリに格納されるコンテナ管理表510を示した図である。コンテナ管理表510は、コンテナを一意に識別する識別子コンテナID8011に対し、VMを識別するVM_ID8012、IPアドレス8013、コンテナに割り当てられる計算機資源であるCPUのID、メモリ量を管理する。IPアドレスはIPv4でもIPv6でもよい。またIPアドレスでなく、FCで通信をするためのWWNでもよいしその他のプロトコルで通信するための識別情報であっても良い。コンテナ管理表510は、図８に示したようなテーブル形式で無く、ドキュメント形式等、他の形式で値を保持してよい。また、コンテナIDは数字でも文字列でもよい。例えば、コンテナID「１」に対し、VM_ID「１」、CPU_ID「３」、メモリ量「50」が対応している。
図９は、アプリ管理表515の内容を示した図である。この情報は、アプリ管理プログラム514によって管理されている。アプリケーションを一意に識別するApp_ID901に対し、VM（コンテナ）を識別するVM_ID902、ノードID903、用途904を管理する。図９に示したようなテーブル形式で無く、ドキュメント形式等、他の形式で値を保持してよい。また、コンテナIDは数字でも文字列でもよい。例えば、App_ID「１」に対し、VM_ID「１」、ノード_ID「１」、用途「ストレージコントローラ」が対応して管理されている。
図１０は、ノードのメモリに格納されるストレージノード論理管理表508を示した図である。ストレージノード論理管理表508には、プールの構成情報1001とボリュームの構成情報1002が含まれる。ストレージノード論理管理表508は、プールやボリュームといったストレージの論理リソースを示す表である。各リソースに表が存在する。ここでは代表的なものとして、プールとボリュームの例を示す。
プールの構成情報1001には、システム内でプールを一意に識別するプールID10011に対し、プールの容量10012、プールの名前10013、プールが配置されるノードのID10014、ミラー、EC(Erasure Coding)のプールの冗長度10015、冗長先のノードID10016が対応されて管理されている。
ボリュームの構成情報1002は、ボリュームを識別するボリュームID10021に対し、ボリュームの名前10022、ボリュームの容量10023、ブロック数10024、ボリュームが属するプールのID10025、プールが属するノードのID10026、ボリュームと関連するデータストアのID10027、データストアから作成されるVMのID10028や関連するコンテナのID10029などの情報を表す。図９に示したように、テーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。
図１１は、ノードのメモリに格納される容量稼働情報512を示した図であり、ストレージリソースおよびVMの中で容量を持つリソースの時系列の情報を示す。容量稼働情報512は、記憶装置から構成される記憶容量の利用状況を管理する。
管理対象がプールの場合は、プールの容量稼働情報1101で管理される。プールの容量稼働情報1101は、システム内でプールを一意に識別するプールのID11011に対し、プールの自体の総容量11012、時刻11013と時刻毎の使用量11014の情報などを管理する。
管理対象がボリュームの場合は、ボリュームの容量稼働情報1102で管理される。ボリュームの容量稼働情報1102は、システム内でボリュームを一意に識別するボリュームID11021、ボリュームの容量11022、時刻11023、時刻毎の使用量11024等の情報を管理する。
管理対象がVMの場合は、VMの容量稼働情報1103で管理される。VMの容量稼働情報1103は、システム内でVMを一意に識別するVM_ID11031、VMの容量11032、時刻11033、時刻毎の使用量11034等の情報を管理する。尚、各情報は、図示したようなテーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。
管理対象がアプリケーションの場合は、アプリの容量稼働情報1104で管理される。システム内でアプリを一意に識別するアプリ_ID11041、容量11042、時刻11043、時刻毎の使用量11044等の情報を管理する。
図１２は、ノードのメモリに格納されるVM毎のIO量管理表511を示した図であり、VMのRead/WriteのIO量の時系列での情報を示す。VM毎のIO量管理表511は、VMを一意に識別するVM_ID1201に対し、IOがリードかライトかを示すIO種類1202と、時刻1203、一定時間ごとのIO量1204を対応させて管理する。IO種類には、Sequential R/W, Random R/Wの区別があっても良い。一般的なVMの管理ソフトとして提供されているVM管理プログラム503によって記録される。図１２ではVM毎にIO量を管理している例を説明したが、コンテナ単位でIO量を管理してもよい。また、図１２に示したテーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。
図１３は、ノードのメモリに格納される性能稼働情報506を示した図であり、ノード、およびVMごとに利用するリソースの利用量を示す。稼働情報収集プログラム505によって参照、更新される。ノードの性能稼働情報1301は、ノードを一意に識別するノードID13011に対し、CPU利用率、メモリ利用量、使用通信帯域などのメトリック13012、時刻13013、一定時間ごとのCPU利用率、メモリ利用量、使用通信帯域13014を管理する。
また、VMの性能稼働情報1302は、VMを一意に識別するVM_ID13021に対し、CPU利用率、メモリ利用量、使用通信帯域などのメトリック13022、時刻13023、一定時間ごとのCPU利用率、メモリ利用量、使用通信帯域13024を管理する。ノードの性能稼働情報1301とVMの性能稼働情報1302は、他の情報（メモリWrite Pending Rateなど）を保持してもよい。また、コンテナ毎、アプリ毎に同様の性能稼働情報を管理しても良い。また、図１３に示したテーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。
他の制御情報として、配置条件表を含めることもできる。例えば、VMごとの配置条件として、VM_IDに対し、VMのタイプを識別するタイプID、NoSQL DB等のアプリケーションの種類を示すタイプ、ボリュームと同一ノード、同一タイプと同じノードで同居しない等の条件を管理する。タイプの情報は、例えば、条件でタイプIDが同じものは同一ノードに作成しない、という目的で利用する。この条件には、VMとボリュームが同一ノードに必ず存在させる必要がある（もしくはボリュームとVMが同一ノードでなくてもよい）、タイプが同じものは異なるノードに存在させる、といった条件を設定する。これらの条件はVMデプロイ時にユーザがVM管理プログラム経由で設定してもよいし、アプリケーションによって自動で設定されるように設定ファイルに記載しておいてもよい。
図１４は、ノードのメモリに格納されるノード単位稼働情報表513を示した図である。ノード単位で、VM/コンテナ、及びアプリごとの、CPU,メモリ、NW帯域等の計算機資源の利用状況を管理する。図は、VMの例として、VM＿IDを管理しているが、コンテナを対象としコンテナ_ID、アプリを対象としてアプリ_IDを管理しても良い。
ノード単位稼働情報表513は、各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を管理する情報である。
図６のストレージノード物理構成表507、図１１の容量稼働情報512、図１２のIO管理表511、図１３の性能稼働情報506、図７のVM管理表509（コンテナの場合は図８のコンテナ管理表、アプリの場合は図９のアプリ管理表）の情報から、ストレージ管理プログラム502が定期的に作成する。図１１、図１２、図１３の稼働情報の履歴からは最新の時刻の情報を抽出して保存する例を示すが、最新の情報だけでなく、履歴情報を保存してもよい。この例はVMごとの情報を記載しているが、コンテナごと、アプリごとの情報を管理してもよい。
例えば、図６のストレージノード物理構成表507からは、各ノードのCPU_ID等の物理的な計算機資源を特定できる。これにより、ノード毎のCPUの上限1402、メモリ上限1404、NW帯域上限1406が把握できる。図７のVM管理表509から各VMと、ノードとCPU_ID等の物理的な計算機資源の対応を把握できる。これにより、ノード_ID1401とVM_ID1410の対応が明らかになる。
図１１の容量稼働情報512から各VMの容量と、各時刻における使用量を特定できるため、VM_IDに対する容量上限11032と使用量11034から、VM毎の容量使用量1414が把握される。VMとボリュームとの対応を管理する図１０ボリューム構成情報1002により、VM毎に割り当てられているボリューム容量を把握することができる。図１２のIO量管理表511から、VM毎のIO量1415が把握できる。また、図１３のVMの性能稼働情報1302から、VM毎のCPU利用率1411、メモリ利用量1412、NW帯域利用量1414が把握できる。
つまり、ノード毎に管理される計算機資源の上限1402、1404、1406と容量上限1408、及びVM毎に管理される利用状況1411−1415が把握される。また、VM毎に割り当てられているボリューム容量も図１０のボリューム構成情報から把握できる。各ノードに配置されるVMは、各ノードに配置されているVMを図７のVM管理表で把握できる。
従って、各ノードに配置される計算機資源（CPU、メモリ、帯域、容量）の上限値と、VMが利用する計算機資源、ボリューム容量の総和を比較することで、図１４に示す対応表が管理され、各ノードにおいて利用されているCPU、メモリ、NW帯域等の計算機資源、記憶装置から構成される記憶容量の利用状況（容量の利用量(率)）を把握することができる。
図１４ではVMごとの情報を記載しているが、コンテナごと、アプリごとの情報を管理してもよい。また、テーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。
＜VM/コンテナおよびボリュームの配置決定処理＞
図１５は、新規作成VM/コンテナおよびボリュームの配置決定する処理フロー図である。この処理は、IOの冗長度を考慮することなく、新規作成VM/コンテナの想定IO量とボリュームの条件を、管理者であるユーザが入力してVM/コンテナを配置するケースである。図１５に示した処理は、主として管理部のストレージ管理プログラム502によって処理されるが、ステップ1508と1504の処理は、新規VMを作成する場合にはVM管理プログラム503により、新規コンテナを作成する場合にはコンテナ管理プログラム504により、処理される。
まず、ステップ1501で、ユーザにより新規作成VM/コンテナの想定IO量、容量、作成個数を入力される。
次に、ステップ1502で、入力情報からVM/コンテナ作成条件を満たすノード群を算出する。この処理の詳細は、図１６を用いて説明する。
次に、ステップ1503で、条件を満たすノード群があるか判定し、ある場合にはステップ1504に進み、条件を満たすノード群に新規ボリュームと新規VM/コンテナを作成する。
ステップS1503の判断の結果、条件を満たすノード群がない場合、ステップS1505に進み、既存VM/コンテナの移動により、条件を満たすことができるか計算する。このステップの詳細は、図１７を用いて説明する。
ステップS1506で、ステップS1505で計算された内容が条件を満たす移動方法があるかを判断する。条件を満たす移動方法がある場合には、ステップS1508に進み、既存ボリュームと既存VM/コンテナを他のノードに移動する。ステップS1508で作成条件を満たしたうえで、ステップS1504の新規ボリュームと新規VM/コンテナの作成処理を実行する。
ステップS1506で条件を満たす移動方法がないと判断された場合、エラーを返し（S1507）、処理を終了する。
図１５では、ユーザによる入力情報として、IO量だけでなく、想定負荷としてメモリ使用量等他の値を入力してもよい。
図１６は、VM/コンテナ作成条件を満たすノード群を算出する処理を示したフロー図である。図１６に示した処理は、図１５のステップS1502の処理に相当し、管理部のストレージ管理プログラム502によって実行される。
まず、ストレージ管理プログラム502は、図１４に示したノード単位稼働情報1400の容量上限1408と容量利用量1409を参照することで、新規VM/コンテナ向けの空き容量（記憶領域の容量）があるノード群があるかを判定する（S1601）。この処理で、ノード群がなかった場合、容量条件を満たすノード群無し、と判定する（S1607）。
次に、CPU処理単価とIO量から各ノードで必要なCPU量（CPU時間）を計算する(S1602)。ここで、CPU処理単価は、IO処理に要するCPU時間をIO量で除算した値であって、一つのIOを処理するのに必要となるCPU利用時間と定義される。
次に、新規VM/コンテナを作成して増加するCPU量（CPU時間）にノード単位稼働情報のCPU利用率1403を加え、ノードのCPU上限1402を超えないノード群を検索する（S1603）。検索の結果、ステップS1603のCPU条件を満たすノードがあれば、ステップ1606に進み、条件を満たすノード群ありと判定する。ステップS1603のCPU条件を満たすノードがなければ、ステップS1605に進み、CPU条件を満たすノード群無し、と判定する。
以上により、容量と計算機資源であるCPUに余力があるノードに新規VM等を作成することができる。
なお、ボリュームが、Thin Provisioning（仮想的に容量を利用する）の場合は、容量条件のチェックを省略してよい。CPU処理単価は固定で値を持っておいてもよいし、ノードのCPUコア周波数から計算してもよい。この例ではCPU処理単価×IO量でCPU量（CPU時間）の計算によりCPU利用量を算出しているが別の方法でもよい。検索処理は動的計画法等を利用して求められる一つの解を出して条件チェック処理実行、を繰り返してもよいし、全検索をして最も利用率の少ないノード群を検出しても、チェック処理による絞り込みをするようにしてもよい。
CPU条件だけでなく、IO処理のために必要なメモリ量のチェックや通信帯域のチェックを入れてもよい。
図１７は、既存VM/コンテナの移動により条件を満たすか計算するフロー図である。図１７に示した処理は、図１５のステップS1505の処理に相当し、管理部のストレージ管理プログラム502によって実行される。
図１６の処理で、容量条件を満たすノード群があり、と判定された場合は、ステップS1702 に進み、ノード単位稼働情報表の情報から既存VM/コンテナのIO1405量を取得する。次に、CPU処理単価とIO量から既存および新規VM/コンテナによるCPU量（CPU時間）を計算する（S1703）。ここで、CPU処理単価とは、IO処理に要するCPU時間をIO量で除算した値であって、一つのIOを処理するのに必要となるCPU利用時間と定義される。
次に、既存VM/コンテナの移動を考慮してCPU性能上限を超えない組み合わせがあるか検索し（S1704）、CPU条件を満たすノード群ありか判定する（S1707）。判定の結果、CPU条件を満たすノード群がある場合、移動対象のVM/コンテナおよびボリュームとその移動先ノード、さらに新規作成で利用するノードの情報を返却する（S1709）。
図１６の処理で、容量条件を満たすノード群がない、と判定された場合、ステップS1705に進み、VM/コンテナと紐づくボリュームを移動すれば容量条件を満たせるかを判定する（S1705）。S1705の判定結果がネガティブな場合、移動しても新規VM/コンテナ作成に十分なリソース無し、と返却する（S1708）。S1705の判定結果、VM/コンテナと紐づくボリュームを移動すれば容量条件を満たせる、と判定された場合、VM/コンテナおよびボリュームを移動すると仮定し、図１６の算出処理を再計算する（S1706）。その後ステップS1707に進み、CPU条件を判定し、判定結果に従って、ステップS1708、ステップS1709の処理を実行する。
このように、図１７の処理は、計算機資源或いは容量に、新規VM等を作成する余力がない場合であっても、既存のVM等を移動することで、ノード間の計算機資源や容量の配分を適正化することで、既存VM等を移動することにより、計算機資源に余力が生じたノード上に新規VM等を作成するための方法を示している。
図１７では、図１６の算出処理を再計算するときに、移動対象のVM/コンテナおよびボリュームと、これから作成するVM/コンテナおよびボリュームを全て新規作成すると考えて計算する。また、移動VM/コンテナ/ボリューム分の利用リソースは現在の利用量から減算して計算する。移動を考慮した組み合わせが複数検索される場合に、 現在のシステム影響を考慮して、現在のIO量が少ない既存VM/コンテナを移動させる、というように追加の絞り込み検索を実施しても良い。CPU条件だけでなく、IOを処理するために必要なメモリ量のチェックやNW帯域のチェックを入れてもよい。
図１５から図１７に示したように、既存のVM/コンテナの情報に基づいて、ノードのCPU量の上限を超えることなく、配置条件を満たして新規VM/コンテナを作成することができる。また、新規ボリュームについても、ノードのCPU量や配置条件、容量条件を満たすように作成することができる。また、新規に作成するVM/コンテナやボリュームの条件を満たすノードがない場合であっても、既存のVM/コンテナやボリュームを移動した結果、条件を満たす計算機資源が確保できるノードがあった場合、条件を満たすように既存のVM/コンテナやボリュームの移動を実行することができる。
上記VM/コンテナ、ボリュームの作成、既存のVM/コンテナやボリュームを移動は、管理サーバや、代表ノードの管理部によって実行される。
図１５の処理で最終的にエラーが返ってきた場合、システムの管理者は、計算機の物理資源を増やすために、新たなノードをシステムに追加する処理を行うことができる。計算機の物理資源を増やすために追加ノードが必要な場合のみノードの追加を行えばよく、効率の良いシステム運用を可能とする。
図１８は、実施例２のノード障害時のVM/コンテナおよびボリューム配置を決定するフロー図である。図１８に示した処理は、管理部のストレージ管理プログラム502によって実行され、実施例１の図１５の処理の変形例として理解できる。この処理は、あるノード障害により、障害発生ノードで動作していたVM/コンテナを再冗長化するケースである。例として、５ ノード（N1,N2,N3,N4,N5）中の３ノード（N1,N2,N3）で２冗長化して動かしていたアプリが動作するVM/コンテナがあり、N1に障害が発生した場合に、N2〜N5のどこかに再冗長化するケースを考える。
実施例１の図１５の処理では、S1501で、ユーザにより新規作成VM/コンテナの想定IO量、容量、作成個数を入力されていたのに対し、実施例２では、ノード障害を検知（S1801）し、障害ノードで動作していたVM/コンテナのIDを特定（S1802）することで、障害が生じたノードの想定IO量、容量、作成個数を把握する点が異なる。その後、ステップS1803からステップS1808の処理は、図１５で説明したステップS1502からステップS1507と同様であるため、説明は省略する。障害ノードは選択候補からは除外して条件を満たすノード選択処理を実施する。
実施例２によれば、ノード障害時に、障害が発生したノード上に配置されていたVM、コンテナやボリュームを、ノードの計算機資源を超えることなく、どこに配置すべきかを算出し、再冗長化することができる。
図１９は、実施例３の異なる二つのNode内の二つのストレージVM（一つのストレージVMに2台のストレージコントローラ1901、1902を構成）し、各Nodeで2台のストレージコントローラ（1901、1903）によりペアを組んだ構成を示した図である。
ストレージコントローラ（1901、1904）がNode間で冗長構成（ActiveとStandbyの間で冗長構成）を組む。常に少なくとも１NodeでActiveストレージコントローラ（1901）が動作。この例はActive/Standbyの例を示す。
あるノードに障害が発生すると、Activeストレージ コントローラに対応するStandbyストレージ コントローラがActiveストレージ コントローラに昇格し、IO処理を継続する（これをFailoveｒと呼ぶ）。図１９の例ではNode2(100b)に障害が発生すると、Activeストレージ コントローラ2が停止し、Node3(100c)のStandbyストレージ コントローラ2がActiveに昇格し、Activeストレージ コントローラ2の処理を継続して実施する。この場合、Node3にActiveストレージ コントローラが2つ存在するため他のノードよりも処理量が増加する。
あるActiveストレージ コントローラ経由でアクセスしていたデータは他のノードに冗長化されており、Failover後もStandbyストレージ コントローラが昇格後にデータにアクセス可能となる。
つまり、ノード100aは、ストレージコントローラ1901とボリューム(図示せず)を有し、ストレージコントローラ1901は、Activeのストレージコントローラ1901がIOを処理する。つまり、ストレージコントローラ1901は、アプリVM等の仮想マシンからのボリュームに対するIO要求を処理するアクティブモードとして動作し、ボリュームにデータを書き込む。
また、ノード100bは、ストレージコントローラ1904とボリューム(図示せず)を有し、ストレージコントローラ1904は、ストレージコントローラ1901の冗長構成となるスタンバイモードとして、ストレージコントローラ1901から冗長データを受け取って、ノード２(100b)のボリュームに冗長データを書き込む。
図２０は、実施例１の図１０の情報に加え、ストレージコントローラ毎の状態等のストレージコントローラの構成情報を示した図である。図１０と同様、ノードのメモリに格納され、ストレージ管理プログラム502によって管理される。
ストレージコントローラの構成情報2000は、ストレージコントローラを識別するための識別子2001、に対し、Active/Passive/Standby等の状態2002、ペアの識別子であるグループID2003、ストレージコントローラが配置されている稼働ノードID2004、VM_ID2005が対応して管理されている。状態2002には、障害を示す状態（例：Dead）を保持してもよい。
図２１は、実施例３の新規作成VM/コンテナおよびボリュームの配置決定する処理フロー図である。実施例１を図１９の構成を利用し、管理部によるデータの冗長化を行う例となる。実施例１の図１６に対応するものが図２１、実施例１の図１７に対応するものが図２２となる。
基本的な流れは、実施例１の図１６に示した処理と対応する。図１６のステップS1601とステップS1602の間に、ステップS2102のストレージコントローラの冗長度から自ノード以外で発生するIO量を計算する処理を追加している。その他のステップは、図１６のステップに対応するため、説明は省略する。この処理は、データの冗長性を確保するため、異なるノードにデータの複製を記憶するため、自ノードのアプリVMからのIOの他に、他ノードのストレージVMからのIOを考慮するためのステップである。
図２２は、管理部により実行され、実施例３の既存VM/コンテナの移動により条件を満たすかを計算処理するフロー図である。図２２は、実施例１の図１７に対応し、図１７のステップ1702とステップS1703の間に、ステップS2203において、ストレージコントローラの冗長度から自ノード以外で発生するIO量を計算するステップを設けている。
他ノードの情報は、図２０から、同一グループIDが同一の値をとるストレージコントローラを特定する。例えば、ノードID「１」に対して、他ノードのIOとして考慮されるストレージコントローラは、ノード「１」のストレージコントローラ「２６」と同一のグループ_ID「３」、即ち、ペアとして管理されるノード「３」のストレージコントローラ「２０」であることが分かる。ストレージコントローラ「２０」は、VM上に乗っているアプリであり、App_IDによって識別可能である。従って、図１３のアプリの性能管理情報をアプリ毎に管理することで、他ノードからのIO量を把握することができる。
実施例３によれば、マルチノード構成のストレージシステムで、他ノードからのIOを考慮して、ノードで発生するIO量を計算することができる。即ち、自ノードのストレージコントローラと他ノードのストレージコントローラとがペアとなり、他ノードのストレージコントローラがアクティブ状態でアプリVMからのIO処理を行い、自ノードのストレージコントローラがスタンバイ状態となり、冗長データを自ノードに記憶する場合に、他ノードからのIO量を特定し、自ノードで使用するCPU、容量等の計算機資源を計算することが可能となる。
実施例４のノード障害時のVM/コンテナおよびボリュームの配置決定処理を示すフロー図である。実施例２の図１８に対応するものであるが、図２３の処理は、ノード障害によりActiveストレージ コントローラが別のノードにFailoverしたときに、障害ノードで動いていたユーザVM/コンテナをどこに配置すべきかを算出する、管理部のVM/コンテナ管理プログラムによる処理である。
まず、ノード障害を検知する（S2301）。次に、ストレージノード論理構成表のストレージコントローラの関係からActiveストレージコントローラが動作するノードを切替る（S2302）。次に、VM管理表509を参照し、障害ノードで動作していたVM/コンテナのIDを特定する（S2303）。次に、VM/コンテナのIDから性能稼働情報506、IO量管理表511、容量稼働情報512を取得（S2304）する。
次に、障害ノードにあったVM/コンテナをActiveに昇格したノードに配置してリソース（容量、性能）が問題なく収まるかを判定し(S2306)、リソースが収まる場合、Active昇格ノードに新規ボリュームと新規VM/コンテナ作成する(S2308)。リソースが収まらない場合、障害ノードにあったVM/コンテナを新規作成すると考え、図１５の処理を実施する。
図２３で示した処理により、ノード障害によりActiveストレージ コントローラが別のノードにFailoverしたときに、ノードの計算機資源の上限の範囲内で、障害ノードで動いていたユーザVM/コンテナをどこに配置すべきかを算出することができる。
図２４は、実施例５の新規作成VM/コンテナおよびボリュームの配置決定する管理部の処理フロー図である。図２４の処理は、図１５の処理に対応し、S2407とS2408を除き、ストレージ管理プログラム502によって実行される。実施例３との違いとして、指定された冗長度、および図１０のプールの構成情報で保持している冗長度と冗長化先ノードIDの情報から、他ノードのIO量を特定し、自ノードで使用するCPU、容量等の計算機資源を計算する。
最初のステップは、ユーザにより新規作成VM/コンテナの想定IO量、容量、データの冗長度、作成個数を入力が入力される（S2401）。データの冗長度が加わる点が、図１５とは異なる。次に、入力情報からVM/コンテナ作成条件を満たすノード群を算出する（S2402）。この処理は、冗長度が加わるため、図２５の処理を行うこととなる。尚、冗長度は、図１０の構成情報に記載の冗長度に対応させる。
ステップS2403で条件を満たすノードがない場合、既存VM/コンテナの移動により条件を満たすか計算する（S2404）が、冗長度が加わったため、図２６の処理を行う。それ以外は、図１５の処理と同様である。
図２５は、実施例５のVM/コンテナ作成条件を満たすノード群を算出する、管理部の処理フロー図である。この処理は、実施例１の図１６及び実施例３の図２１の処理に対応する。入力された冗長度から自ノード以外で発生するIO量の計算ステップS2502が追加された点、新規VM/コンテナを作成して増加するCPU量（CPU時間）とノードの性能管理情報のCPU利用率が、ノードのCPU上限を超えないノード群を、指定された冗長度の領域を作成可能なプールを持っているノードの条件下で、検索するステップS2504が追加されている。
図２６は、実施例５の既存VM/コンテナの移動により条件を満たすか計算する、管理部の処理フロー図である。図２６は、実施例１の図１７及び実施例３の図２２に示した処理と対応する。入力された冗長度から自ノード以外で発生するIO量を計算するステップS2603、既存VM/コンテナの移動を考慮してCPU性能上限を超えない組み合わせが、冗長度条件を満たすプールを持つノードの条件下であるか検索するステップS2605が異なる。
実施例５によれば、プールの構成情報から冗長化の相手ノードを判断し、他ノードで発生するIO量を考慮して、VMやボリュームの配置先を、ノードの計算機資源の上限値を超えることなく決定することができる。
図２７は、実施例６のシステムの全体構成図である。実施例１の図２、実施例３の図１９との相違は、コンテナをHypervisorのVM上OSではなく、Hypervisorを経由しないOS上に作成する構成とした点である。
この構成では、ユーザデータヘのアクセスはストレージコントローラが提供するボリューム経由である。コンテナ経由の場合はHypervisorを経由せずにIO可能となる。実施例１との違いは、コンテナを特定するときにVMを必要としないこと（VM管理表、コンテナ管理表、ストレージノード論理構成表でコンテナIDとVM_IDの関係を持たないこと。コンテナ管理表のVM_IDカラムがノードIDカラムと変わる）である。
本発明の観点では、構成のみが変更となり処理フローは変わらない。変形例として、最下層のOSの上に直接ストレージコントローラが動作する構成でもよい。
100：ノード、101：CPU、102：メモリ、103：ドライブ、104：ハイパーバイザ、105：VM、200：クライアントノード、201：フロントエンドネットワーク、202：バックエンドネットワーク、203：クラスタ、301：ネットワークインタフェース、402：データストア、403ボリューム、404：プール、501：ストレージIO制御プログラム、502：ストレージ管理プログラム、503：VM管理プログラム、504：コンテナ管理プログラム、505：稼働情報収集プログラム、506：性能稼働情報、507：ストレージノード物理構成表、508：ストレージノード論理構成表、509：VM管理表、510：コンテナ管理表、511：IO量管理表、512：容量稼働情報、513：ノード単位稼働情報、514：アプリ管理プログラム、515：アプリ管理表。
本発明は、上記の課題を解決するためのリソース配置決定方法の一例を挙げるならば、複数のノードを有し、複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンおよびコンテナの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、複数のノードの各ノードは、データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置とを含む計算機資源を有し、各ノード上で動作する、仮想マシン及びストレージコントローラが、共用する前記計算機資源の利用状況を管理し、管理部が、前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する。

Claims (12)

  1. 複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、
    前記複数のノードの各ノードは、
    データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置とを含む計算機資源を有し、
    前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を管理し、
    管理部が、前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する、こと特徴とするリソース配置決定方法。
  2. 前記計算機資源の利用状況は、前記各ノードにおける記憶装置から構成される記憶容量の利用状況、前記各ノードにおけるCPUの利用状況、前記ノードにおけるメモリの利用状況及びネットワーク帯域の利用状況の少なくとも一つである、ことを特徴とする請求項１記載のリソース配置決定方法。
  3. 前記計算機資源の利用状況に基づき、新規の仮想マシン或いはボリュームの配置先となるべきノードがない場合、前記複数のノードの第１のノード上の仮想マシン、コンテナ、ボリューム及び前記ストレージコントローラの何れかを他のノードに移行させ、前記第１のノードを前記新規の仮想マシン或いはボリュームの配置先となる、ことを特徴とする請求項２に記載のリソース配置決定方法。
  4. 前記複数のノードの第２のノードで障害が発生した場合、第２のノード上で動作する仮想マシン或いはコンテナを特定し、
    前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
    前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有するノードに、前記第２のノード上で動作する仮想マシン、コンテナ及びボリュームの少なくとも一つを第３のノードに作成する、ことを特徴とする請求項１に記載のリソース配置決定方法。
  5. 前記複数のノードの第２のノードで障害が発生した場合、第２のノード上で動作する仮想マシン或いはコンテナを特定し、
    前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
    前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有するノードに、前記第２のノード上で動作する仮想マシン、コンテナ及びボリュームの少なくとも一つを第３のノードに作成する、ことを特徴とする請求項３に記載のリソース配置決定方法。
  6. 複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、
    前記複数のノードのそれぞれは、
    データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置を含む計算機資源を有し、
    前記複数のノードの第４のノードは、第１のストレージコントローラと第１のボリュームと第１のドライブを有し、前記第１のストレージコントローラは、前記仮想マシンからの前記ボリュームに対するIO要求を処理し、前記第１のドライブにデータを書き込み、
    前記複数のノードの第５のノードは、第２のストレージコントローラと第２のボリュームと第２のドライブとを有し、前記第２のストレージコントローラは、前記第１のストレージコントローラの冗長先のストレージコントローラとして動作し、前記第１のストレージコントローラから冗長データを受け取って、前記第２のドライブに冗長データを書き込み、
    前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが共用する前記計算機資源の利用状況に、前記冗長データの書き込みのための計算機リソースも合わせて管理し、
    管理部が、
    前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する、こと特徴とするリソース配置決定方法。
  7. 前記計算機資源の利用状況に基づき、新規の仮想マシン或いはボリュームの配置先となるべきノードがない場合、前記複数のノードの特定のノードの仮想マシン、コンテナ、ボリューム及び前記ストレージコントローラの何れかを他のノードに移行させ、前記新規の仮想マシン或いはボリュームの配置先となる、ことを特徴とする請求項６に記載のリソース配置決定方法。
  8. 前記複数のノードの第６のノードで障害が発生した場合、第６のノード上で動作する仮想マシン或いはコンテナを特定し、
    前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
    前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有する第7のノードに、前記第６のノード上で動作する仮想マシン、コンテナ及びボリュームの少なくとも一つを、作成する、ことを特徴とする請求項７に記載のリソース配置決定方法。
  9. 複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン(VM)及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、
    前記複数のノードの各ノードは、
    データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置を含む計算機資源を有し、
    前記複数のノードの内、データの冗長化を行うための冗長構成を管理し、
    前記ストレージコントローラは、データの記憶領域となるボリュームを経由して自ノードのドライブに対するデータの読み書き制御と、前記冗長構成に基づき、他ノードのドライブに対する冗長化処理を実行し、
    前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を、前記冗長構成を考慮して管理し、
    管理部が、
    前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する、こと特徴とするリソース配置決定方法。
  10. 前記計算機資源の利用状況に基づき、新規の仮想マシン或いはボリュームの配置先となるべきノードがない場合、前記複数のノードの一つのノード上の仮想マシン、コンテナ及び前記ストレージコントローラの何れかを他のノードに移行させ、前記複数のノードの内の特定のノードを前記新規の仮想マシン或いはボリュームの配置先となる、ことを特徴とする請求項９に記載のリソース配置決定方法。
  11. 前記複数のノードの第８のノードで障害が発生した場合、第８のノード上で動作する仮想マシン或いはコンテナを特定し、
    前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
    前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有する第９のノードに、前記第８のノード上で動作する仮想マシン或いはコンテナを、作成する、ことを特徴とする請求項９に記載のリソース配置決定方法。
  12. 複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおいて、
    前記複数のノードの各ノードは、
    データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置を含む計算機資源を有し、
    前記ストレージコントローラは、データの記憶領域となるボリュームを経由して自ノードのドライブに対するデータの読み書き制御と、他ノードのドライブに対する冗長化処理を実行し、
    前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を管理し、
    前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する管理部とを、有することを特徴とするストレージシステム。
JP2018181418A 2018-09-27 2018-09-27 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム Active JP6957431B2 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2018181418A JP6957431B2 (ja) 2018-09-27 2018-09-27 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム
CN201910123837.8A CN110955487A (zh) 2018-09-27 2019-02-19 Hci环境下的vm/容器和卷配置决定方法及存储系统
US16/298,584 US11080080B2 (en) 2018-09-27 2019-03-11 Virtual machine and volume allocation in hyperconverged infrastructure environment and storage system
US16/409,481 US11080081B2 (en) 2018-09-27 2019-05-10 Virtual machine and volume allocation in hyperconverged infrastructure environment and storage system
US17/389,679 US11663029B2 (en) 2018-09-27 2021-07-30 Virtual machine storage controller selection in hyperconverged infrastructure environment and storage system
JP2021164588A JP7118230B2 (ja) 2018-09-27 2021-10-06 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018181418A JP6957431B2 (ja) 2018-09-27 2018-09-27 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2021164588A Division JP7118230B2 (ja) 2018-09-27 2021-10-06 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム

Publications (2)

Publication Number Publication Date
JP2020052730A true JP2020052730A (ja) 2020-04-02
JP6957431B2 JP6957431B2 (ja) 2021-11-02

Family

ID=69946975

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2018181418A Active JP6957431B2 (ja) 2018-09-27 2018-09-27 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム
JP2021164588A Active JP7118230B2 (ja) 2018-09-27 2021-10-06 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2021164588A Active JP7118230B2 (ja) 2018-09-27 2021-10-06 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム

Country Status (3)

Country Link
US (3) US11080080B2 (ja)
JP (2) JP6957431B2 (ja)
CN (1) CN110955487A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021196687A (ja) * 2020-06-10 2021-12-27 株式会社日立製作所 計算機システム及び計算機システムの制御方法

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7035858B2 (ja) * 2018-07-03 2022-03-15 富士通株式会社 マイグレーション管理プログラム、マイグレーション方法およびマイグレーションシステム
US11249852B2 (en) 2018-07-31 2022-02-15 Portwonx, Inc. Efficient transfer of copy-on-write snapshots
US11354060B2 (en) 2018-09-11 2022-06-07 Portworx, Inc. Application snapshot for highly available and distributed volumes
JP6957431B2 (ja) * 2018-09-27 2021-11-02 株式会社日立製作所 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム
WO2020081512A1 (en) * 2018-10-15 2020-04-23 Netapp, Inc. Improving available storage space in a system with varying data redundancy schemes
US11681278B2 (en) * 2019-06-19 2023-06-20 Honeywell International Inc. High availability for container based control execution
US10992526B1 (en) * 2019-10-15 2021-04-27 Dell Products L.P. Hyper-converged infrastructure networking configuration system
US11494128B1 (en) 2020-01-28 2022-11-08 Pure Storage, Inc. Access control of resources in a cloud-native storage system
JP7122332B2 (ja) * 2020-02-26 2022-08-19 株式会社日立製作所 情報処理システム及び方法
US11762742B2 (en) 2020-03-31 2023-09-19 Honeywell International Inc. Process control system with different hardware architecture controller backup
US11513830B2 (en) * 2020-04-02 2022-11-29 Vmware, Inc. Introspection into workloads running within virtual machines
US11989084B2 (en) 2020-09-23 2024-05-21 Honeywell International Inc. Self-healing process control system
JP7154261B2 (ja) * 2020-09-25 2022-10-17 株式会社日立製作所 複合型ストレージシステム
US11874938B2 (en) 2020-11-03 2024-01-16 Honeywell International Inc. Admittance mechanism
CN112468458B (zh) * 2020-11-12 2022-04-12 鹏城实验室 一种基于neutron分层机制的调度方法
US20220197701A1 (en) * 2020-12-22 2022-06-23 Red Hat, Inc. Managing resource allocation in a software-defined system
US11531467B1 (en) 2021-01-29 2022-12-20 Pure Storage, Inc. Controlling public access of resources in a secure distributed storage system
US11520516B1 (en) 2021-02-25 2022-12-06 Pure Storage, Inc. Optimizing performance for synchronous workloads
US11733897B1 (en) 2021-02-25 2023-08-22 Pure Storage, Inc. Dynamic volume storage adjustment
US11726684B1 (en) 2021-02-26 2023-08-15 Pure Storage, Inc. Cluster rebalance using user defined rules
CN115220862A (zh) * 2021-04-20 2022-10-21 华为云计算技术有限公司 负载处理方法、计算节点、计算节点集群及相关设备
JP7473522B2 (ja) * 2021-12-22 2024-04-23 株式会社日立製作所 ストレージ管理システム、及びストレージ管理方法
US20230362234A1 (en) * 2022-05-04 2023-11-09 Microsoft Technology Licensing, Llc Method and system of managing resources in a cloud computing environment
JP2024055158A (ja) * 2022-10-06 2024-04-18 富士通株式会社 情報処理プログラム、情報処理方法及び情報処理装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007136021A1 (ja) * 2006-05-24 2007-11-29 Nec Corporation 仮想マシン管理装置、仮想マシン管理方法およびプログラム
JP2010212807A (ja) * 2009-03-06 2010-09-24 Nec Corp フェイルオーバー方法、そのシステム、ノード及びプログラム
JP2014021847A (ja) * 2012-07-20 2014-02-03 Mitsubishi Electric Corp リソース管理装置及びリソース管理方法及びプログラム
WO2018029820A1 (ja) * 2016-08-10 2018-02-15 株式会社日立製作所 計算機システム

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8554981B2 (en) * 2007-02-02 2013-10-08 Vmware, Inc. High availability virtual machine cluster
JP4906686B2 (ja) 2007-11-19 2012-03-28 三菱電機株式会社 仮想マシンサーバサイジング装置及び仮想マシンサーバサイジング方法及び仮想マシンサーバサイジングプログラム
US8117495B2 (en) * 2007-11-26 2012-02-14 Stratus Technologies Bermuda Ltd Systems and methods of high availability cluster environment failover protection
WO2009088435A1 (en) 2007-12-31 2009-07-16 Netapp, Inc. System and method for automatic storage load balancing in virtual server environments
US8549364B2 (en) * 2009-02-18 2013-10-01 Vmware, Inc. Failure detection and recovery of host computers in a cluster
US8918585B2 (en) * 2010-01-28 2014-12-23 Hitachi, Ltd. Management system calculating storage capacity to be installed/removed
US8429449B2 (en) * 2010-03-01 2013-04-23 International Business Machines Corporation Optimized placement of virtual machines in a network environment
US8447850B2 (en) * 2011-02-28 2013-05-21 Hitachi, Ltd. Management computer and computer system management method
US8694995B2 (en) * 2011-12-14 2014-04-08 International Business Machines Corporation Application initiated negotiations for resources meeting a performance parameter in a virtualized computing environment
US9158578B1 (en) * 2011-12-30 2015-10-13 Emc Corporation System and method for migrating virtual machines
JP2015526830A (ja) * 2012-08-28 2015-09-10 ブイシーイー カンパニー エルエルシー 既存のコンピューティング環境内に配備される統合コンピューティング・プラットフォーム
US9323577B2 (en) * 2012-09-20 2016-04-26 Amazon Technologies, Inc. Automated profiling of resource usage
US20140101279A1 (en) * 2012-10-04 2014-04-10 Hitachi, Ltd. System management method, and computer system
US9608933B2 (en) * 2013-01-24 2017-03-28 Hitachi, Ltd. Method and system for managing cloud computing environment
CN104956327B (zh) * 2013-07-31 2018-07-03 株式会社日立制作所 计算机系统及计算机系统控制方法
WO2015049789A1 (ja) * 2013-10-04 2015-04-09 株式会社日立製作所 リソース管理システムおよびリソース管理方法
CN104506589B (zh) * 2014-12-10 2018-04-27 上海爱数信息技术股份有限公司 一种基于超融合存储的资源迁移调度方法
US9542320B2 (en) * 2015-01-12 2017-01-10 Avago Technologies General Ip (Singapore) Pte. Ltd. Multi-node cache coherency with input output virtualization
EP3304295B1 (en) * 2015-06-05 2024-05-29 Nutanix, Inc. Architecture for managing i/o and storage for a virtualization environment using executable containers and virtual machines
CN107894913B (zh) * 2016-09-30 2022-05-13 超聚变数字技术有限公司 一种计算机系统和存储访问装置
US10552272B2 (en) * 2016-12-14 2020-02-04 Nutanix, Inc. Maintaining high availability during N-node failover
US10891162B2 (en) * 2018-01-25 2021-01-12 Vmware, Inc Methods and apparatus to improve external resource allocation for hyper-converged infrastructures based on costs analysis
JP6878369B2 (ja) * 2018-09-03 2021-05-26 株式会社日立製作所 ボリューム配置管理装置、ボリューム配置管理方法、及びボリューム配置管理プログラム
JP6957431B2 (ja) * 2018-09-27 2021-11-02 株式会社日立製作所 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007136021A1 (ja) * 2006-05-24 2007-11-29 Nec Corporation 仮想マシン管理装置、仮想マシン管理方法およびプログラム
JP2010212807A (ja) * 2009-03-06 2010-09-24 Nec Corp フェイルオーバー方法、そのシステム、ノード及びプログラム
JP2014021847A (ja) * 2012-07-20 2014-02-03 Mitsubishi Electric Corp リソース管理装置及びリソース管理方法及びプログラム
WO2018029820A1 (ja) * 2016-08-10 2018-02-15 株式会社日立製作所 計算機システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021196687A (ja) * 2020-06-10 2021-12-27 株式会社日立製作所 計算機システム及び計算機システムの制御方法
JP7163341B2 (ja) 2020-06-10 2022-10-31 株式会社日立製作所 計算機システム及び計算機システムの制御方法
US11586471B2 (en) 2020-06-10 2023-02-21 Hitachi, Ltd. Computer system and control method for computer system

Also Published As

Publication number Publication date
US11080081B2 (en) 2021-08-03
JP7118230B2 (ja) 2022-08-15
CN110955487A (zh) 2020-04-03
US20210357248A1 (en) 2021-11-18
US20200104153A1 (en) 2020-04-02
US20200104151A1 (en) 2020-04-02
JP6957431B2 (ja) 2021-11-02
US11663029B2 (en) 2023-05-30
US11080080B2 (en) 2021-08-03
JP2022003577A (ja) 2022-01-11

Similar Documents

Publication Publication Date Title
JP7118230B2 (ja) Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム
CA2978889C (en) Opportunistic resource migration to optimize resource placement
JP5830599B2 (ja) 計算機システム及びその管理システム
US10437642B2 (en) Management system for computer system
US20160004552A1 (en) Computer system and control method therefor
US20160156568A1 (en) Computer system and computer resource allocation management method
US9348515B2 (en) Computer system, management computer and storage management method for managing data configuration based on statistical information
US10616134B1 (en) Prioritizing resource hosts for resource placement
US10990433B2 (en) Efficient distributed arrangement of virtual machines on plural host machines
JP2021026659A (ja) ストレージシステム及びリソース割当て制御方法
WO2022146475A1 (en) Techniques for workload balancing using dynamic path state modifications
WO2016174739A1 (ja) 複合計算機システム、管理計算機、およびデータ連携管理方法
US11768744B2 (en) Alerting and managing data storage system port overload due to host path failures
US11550613B2 (en) Computer system
US11336519B1 (en) Evaluating placement configurations for distributed resource placement
US20210392087A1 (en) Computer system and operation management method for computer system
US11550488B2 (en) Computer system and load distribution method
US11803425B2 (en) Managing storage resources allocated to copies of application workloads
JP2023094302A (ja) 情報処理システム及び構成管理方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190530

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190530

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200714

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200911

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210202

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210319

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210713

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210721

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: 20210907

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211006

R150 Certificate of patent or registration of utility model

Ref document number: 6957431

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150