JP2019211890A - リソース予約管理装置およびリソース予約管理方法 - Google Patents
リソース予約管理装置およびリソース予約管理方法 Download PDFInfo
- Publication number
- JP2019211890A JP2019211890A JP2018105868A JP2018105868A JP2019211890A JP 2019211890 A JP2019211890 A JP 2019211890A JP 2018105868 A JP2018105868 A JP 2018105868A JP 2018105868 A JP2018105868 A JP 2018105868A JP 2019211890 A JP2019211890 A JP 2019211890A
- Authority
- JP
- Japan
- Prior art keywords
- reservation
- resource
- reset
- priority
- sharing system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title description 6
- 238000007726 management method Methods 0.000 claims description 47
- 238000012856 packing Methods 0.000 claims description 5
- 230000004048 modification Effects 0.000 abstract 3
- 238000012986 modification Methods 0.000 abstract 3
- 238000010586 diagram Methods 0.000 description 9
- 238000012546 transfer Methods 0.000 description 7
- 238000012545 processing Methods 0.000 description 3
- 238000003860 storage Methods 0.000 description 3
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/722—Admission control; Resource allocation using reservation actions during connection setup at the destination endpoint, e.g. reservation of terminal resources or buffer space
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
- H04L47/745—Reaction in network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
- H04L47/748—Negotiation of resources, e.g. modification of a request
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/78—Architectures of resource allocation
- H04L47/781—Centralised allocation of resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/821—Prioritising resource allocation or reservation requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/827—Aggregation of resource allocation or reservation requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/828—Allocation of resources per group of connections, e.g. per group of users
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Strategic Management (AREA)
- Tourism & Hospitality (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Operations Research (AREA)
- Marketing (AREA)
- Quality & Reliability (AREA)
- Development Economics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】リソース共有システムで予約済みのリソースが利用不可となった場合に、効率的に予約の再設定を行う。【解決手段】リソース共有システム１０は、複数のユーザ２０（ユーザ端末）でリソース３０を共有する。リソース予約管理装置４２は、ユーザ２０からリソース３０の予約要求を受け付け、リソース共有システム１０内の所定のリソース３０に利用予約を設定する予約設定部４０２と、予約を設定したリソース３０が利用不可となった場合に、リソース共有システム１０内の他のリソース３０に利用予約を再設定する予約変更部４０４とを備える。予約変更部４０４は、再設定すべき利用予約に対して他のリソース３０のリソース量が不足する場合、再設定すべき利用予約のうちいずれの利用予約を優先して再設定するかを規定する予約変更ポリシーに基づいて、他のリソース３０に利用予約を再設定する。【選択図】図６
Description
本発明は、複数のユーザでリソースを共有するリソース共有システムにおけるリソース予約管理装置およびリソース予約管理方法に関する。
従来、IaaS（Infrastructure as a Service）のようなクラウドサービスにおいて、複数のユーザ（サービスやアプリケーション等）でリソース（コンピュート、ネットワーク、ストレージ等）を共有し、各ユーザが必要な時に必要な分だけリソースを利用するモデルが普及している。
一方で、共有リソースは有限であるため、ユーザが確実にリソースを利用できるように、リソースの予約を可能とする提案もなされている（例えば、非特許文献１および非特許文献２参照）。特に、リソースが限られる小規模プライベートクラウドサービスでは、予約の重要性がより大きくなる。
一方で、共有リソースは有限であるため、ユーザが確実にリソースを利用できるように、リソースの予約を可能とする提案もなされている（例えば、非特許文献１および非特許文献２参照）。特に、リソースが限られる小規模プライベートクラウドサービスでは、予約の重要性がより大きくなる。
"Blazar, the OpenStack Reservation Service"［online］、［平成３０年５月１４日検索］、インターネット<ＵＲＬ：https://docs.openstack.org/blazar/latest/>
"Amazon EC2 リザーブドインスタンス"［online］、［平成３０年５月１４日検索］、インターネット<ＵＲＬ：https://aws.amazon.com/jp/ec2/pricing/reserved-instances/>
Weijia Song, et. al, "Adaptive Resource Provisioning for the Cloud Using Online Bin Packing", IEEE Transactions on Computers, Volume: 63, Issue: 11, Nov. 2014
上述したようなリソース共有システムにおいて、予約済みのリソースが故障した場合には、空きのある他のリソース（代替リソース）に当該予約を振り替えることで、ユーザへの影響を解消ないし低減することができる。
しかしながら、システム内の空きリソースが足りない場合、一部の予約が不成立（予約したのにリソースを使えない状況）になる可能性があるという課題がある。
しかしながら、システム内の空きリソースが足りない場合、一部の予約が不成立（予約したのにリソースを使えない状況）になる可能性があるという課題がある。
本発明は、このような事情に鑑みなされたものであり、リソース共有システムで予約済みのリソースが利用不可となった場合に、効率的に予約の振り替えを行うことを目的とする。
上述の目的を達成するため、請求項１に記載の発明は、複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理装置であって、前記ユーザ端末から前記リソースの予約要求を受け付け、前記リソース共有システム内の所定のリソースに利用予約を設定する予約設定部と、前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更部と、を備え、前記予約変更部は、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記再設定すべき利用予約のうちいずれの利用予約を優先して再設定するかを規定する予約変更ポリシーに基づいて、前記他のリソースに前記利用予約を再設定する、ことを特徴とするリソース予約管理装置とした。
また、請求項８に記載の発明は、複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理方法であって、前記ユーザ端末から前記リソースの予約要求を受け付け、前記リソース共有システム内の所定のリソースに利用予約を設定する予約設定工程と、前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更工程と、を含み、前記予約変更工程では、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記再設定すべき利用予約のうちいずれの利用予約を優先して再設定するかを規定する予約変更ポリシーに基づいて、前記他のリソースに前記利用予約を再設定する、ことを特徴とするリソース予約管理方法とした。
このようにすることで、所定のリソースが利用不可となり、かつ再設定すべき利用予約に対して他のリソースのリソース量が不足する場合に、優先的に再設定する予約を一意に決定し、システムの効率を向上させることができる。
また、請求項２に記載の発明は、前記予約要求が、当該利用予約の優先度を示す情報を含んでおり、前記予約変更ポリシーが、前記優先度が高い前記利用予約を優先して再設定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
このようにすることで、利用予約の再設定順序にユーザの意思を反映することができ、ユーザの利便性を向上させることができる。
また、請求項３に記載の発明は、前記予約要求が、前記リソースを利用する日時を示す情報を含んでおり、前記予約変更ポリシーが、前記リソースの利用開始日時が早い前記利用予約を優先して再設定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
このようにすることで、利用不可となったリソースが復旧するまでに開始される可能性が高い予約を優先して再設定することができ、予約不成立となる予約数を低減することができる。
また、請求項４に記載の発明は、前記予約要求が、利用する前記リソースのリソース量を示す情報を含んでおり、前記予約変更ポリシーが、前記リソース量が少ない前記利用予約を優先して再設定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
このようにすることで、限りある空きリソースにより多くの予約を設定することができ、不成立となる予約の数を低減することができる。
また、請求項５に記載の発明は、前記予約要求が、前記リソースを利用する期間を示す情報を含んでおり、前記予約変更ポリシーが、前記リソースの利用期間が短い前記利用予約を優先して再設定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
このようにすることで、限りある空きリソースにより多くの予約を設定することができ、不成立となる予約の数を低減することができる。
また、請求項６に記載の発明は、前記予約要求が、前記リソースを利用する日時を示す情報、利用する前記リソースのリソース量を示す情報、前記リソースを利用する期間を示す情報のうち、少なくとも２つの情報を含んでおり、前記予約変更ポリシーが、前記少なくとも２つの情報に対してそれぞれ重み付けを行ってスコア化し、スコアの大小に基づいて優先して再設定する前記利用予約を決定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
このようにすることで、優先して再設定する予約を決定する際に複数の要因を反映することができる。
また、請求項７に記載の発明は、前記予約変更ポリシーが、Ｂｉｎ Ｐａｃｋｉｎｇ問題を解決するアルゴリズムを用いて、実行可能な前記利用予約の数が最大となるように前記利用予約を再設定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
このようにすることで、リソース共有システム全体で実行可能な予約を最大化することができ、より効率的に予約を設定することができる。
本発明によれば、リソース共有システムで予約済みのリソースが利用不可となった場合に、効率的に予約の振り替えを行うことができる。
以下に添付図面を参照して、本発明に係るリソース予約管理装置４２およびリソース予約管理方法の好適な実施の形態（以下、「実施形態」と称する。）を詳細に説明する。
図１は、本実施態に係るリソース共有システム１０の構成例を示す図である。
図１は、本実施態に係るリソース共有システム１０の構成例を示す図である。
リソース共有システム１０は、複数のユーザ２０で複数のリソース３０を共有するためのシステムである。
それぞれのユーザ２０は、例えば、リソース共有を実現するためのアプリケーションが格納されたユーザ端末（図示省略）である。リソース３０は、例えばベアメタル、仮想マシン、コンテナ、各種ストレージ等である。各リソース３０は、共通ネットワーク３２に接続されており、例えばＯｐｅｎＳｔａｃｋのようなクラウドオペレーティングシステム３４により管理されている。
それぞれのユーザ２０は、例えば、リソース共有を実現するためのアプリケーションが格納されたユーザ端末（図示省略）である。リソース３０は、例えばベアメタル、仮想マシン、コンテナ、各種ストレージ等である。各リソース３０は、共通ネットワーク３２に接続されており、例えばＯｐｅｎＳｔａｃｋのようなクラウドオペレーティングシステム３４により管理されている。
クラウドオペレーティングシステム３４は、システム管理装置４０上のダッシュボードを通じて管理され、管理者がＷＥＢインターフェイスを通じてリソース３０をプロビジョニングできるように構成されている。また、システム管理装置４０は、リソース共有システム１０のモニタリングやツールの提供を行う。
ここで、リソース共有システム１０では、Ｂｌａｚａｒのようなサービスを用いてユーザ２０によるリソース３０の予約が可能である。本実施形態では、システム管理装置４０は、リソース３０の予約を管理するリソース予約管理装置４２として機能する。
ここで、リソース共有システム１０では、Ｂｌａｚａｒのようなサービスを用いてユーザ２０によるリソース３０の予約が可能である。本実施形態では、システム管理装置４０は、リソース３０の予約を管理するリソース予約管理装置４２として機能する。
図２は、本実施形態に係るリソース予約管理装置４２の機能的構成を示すブロック図である。
リソース予約管理装置４２は、制御手段、記憶手段および入出力手段（いずれも図示省略）を備えるコンピュータ等により実現される。そして、制御手段は、予約設定部４０２と、予約変更部４０４とを備える。
リソース予約管理装置４２は、制御手段、記憶手段および入出力手段（いずれも図示省略）を備えるコンピュータ等により実現される。そして、制御手段は、予約設定部４０２と、予約変更部４０４とを備える。
予約設定部４０２は、ユーザ２０からリソース３０の予約要求を受け付け、リソース共有システム１０内の所定のリソース３０に利用予約を設定する。ユーザ２０からの利用要求には、図３に示すようなリソース３０の利用条件が含まれており、予約設定部４０２は、所定のリソース３０に対して利用条件に沿った利用予約を設定する。なお、予約設定部４０２は、後述する予約変更部４０４により利用予約の再設定が行われている間は、新規の予約要求の受け付けを停止する。
予約変更部４０４は、所定のリソース３０（利用予約が設定されたリソース３０）が利用不可となった場合に、リソース共有システム１０内の他のリソース３０に利用予約を再設定する。リソース３０が利用不可となる場合とは、例えばリソース３０が故障した場合やリソース３０とユーザ２０との間のネットワークに障害が生じた場合などである。以下、利用不可となったリソース３０に設定されていた予約を「変更対象予約」という。
図３は、リソース３０の予約要求の一例を模式的に示す説明図である。
ユーザ２０からの予約要求には、例えば当該予約を識別する予約識別子（図３の例では「プロジェクトＡ」）、リソース３０を利用する日時（図３の例では「２０１８／０２／１０／０：００〜２０１８／０２／１２／２３：５９」）、リソース３０を利用する期間（図３の例では「７２時間」）、利用するリソース３０の種類および容量（図３の例では「４コア、８ＧＢ ＲＡＭ、１００ＧＢ ｄｉｓｋのデバイス４台」）などが含まれている。
ユーザ２０からの予約要求には、例えば当該予約を識別する予約識別子（図３の例では「プロジェクトＡ」）、リソース３０を利用する日時（図３の例では「２０１８／０２／１０／０：００〜２０１８／０２／１２／２３：５９」）、リソース３０を利用する期間（図３の例では「７２時間」）、利用するリソース３０の種類および容量（図３の例では「４コア、８ＧＢ ＲＡＭ、１００ＧＢ ｄｉｓｋのデバイス４台」）などが含まれている。
予約要求を受けた予約設定部４０２は、リソース共有システム１０内のリソース３０に、利用条件に沿った利用予約を設定する。各リソース３０の予約状態は、図４に示すような予約テーブルで管理され、予約テーブルに沿って、ユーザ２０にリソース３０の利用権が与えられる。
図４は、リソース３０の予約テーブルを模式的に示す説明図である。
図４では、リソース３０の一例として４台のホストマシン（ホスト１〜ホスト４）を示している。
例えばホスト２は、日曜日はフリー（空き状態）であり、月曜日から火曜日にかけてはプロジェクトＡ、水曜日から木曜日にかけてはプロジェクトＢ、金曜日から土曜日にかけてはプロジェクトＤにより予約されている。
また、リソース量が足りるのであれば、１つのリソース３０を複数のユーザ２０が同時に予約することも可能である。例えばホスト１は、日曜日から火曜日にかけてプロジェクトＡおよびプロジェクトＢにより予約されている。すなわち、１つのリソース３０を部分的に予約することも可能である。
図４では、リソース３０の一例として４台のホストマシン（ホスト１〜ホスト４）を示している。
例えばホスト２は、日曜日はフリー（空き状態）であり、月曜日から火曜日にかけてはプロジェクトＡ、水曜日から木曜日にかけてはプロジェクトＢ、金曜日から土曜日にかけてはプロジェクトＤにより予約されている。
また、リソース量が足りるのであれば、１つのリソース３０を複数のユーザ２０が同時に予約することも可能である。例えばホスト１は、日曜日から火曜日にかけてプロジェクトＡおよびプロジェクトＢにより予約されている。すなわち、１つのリソース３０を部分的に予約することも可能である。
ここで、図４のような予約状態である時にホスト１とホスト２が故障して利用不可となった場合、ホスト１とホスト２に設定されている利用予約、すなわち図５で太実線に囲まれた予約が変更対象予約となる。この場合、予約変更部４０４は、基本的には故障していない他のリソース３０（ホスト３およびホスト４）に予約を再設定（振り替え）する。
例えば図示の例では、図５で太点線に囲まれた領域、すなわちホスト４は全時間帯が、ホスト３は日曜日が、それぞれフリー（空き状態）であるため、予約変更部４０４は、これら空きのあるリソース３０へと変更対象予約を割り振る。しかしながら、ホスト１〜ホスト４のスペックが同等の場合、月曜日以降は空きのあるリソース３０が変更対象予約の実行に必要なリソース量の半分となり、全ての変更対象予約を再設定することはできない。
例えば図示の例では、図５で太点線に囲まれた領域、すなわちホスト４は全時間帯が、ホスト３は日曜日が、それぞれフリー（空き状態）であるため、予約変更部４０４は、これら空きのあるリソース３０へと変更対象予約を割り振る。しかしながら、ホスト１〜ホスト４のスペックが同等の場合、月曜日以降は空きのあるリソース３０が変更対象予約の実行に必要なリソース量の半分となり、全ての変更対象予約を再設定することはできない。
このように、再設定すべき利用予約に対して故障していないリソース３０（他のリソース３０）のリソース量が不足する場合、予約変更部４０４は、リソース共有システム１０の管理者によって設定された予約変更ポリシーに基づいて他のリソース３０に利用予約を再設定する。
予約変更ポリシーとは、変更対象予約の全てを他のリソース３０に再設定することが不可能な場合に、いずれの利用予約を優先して再設定するかを規定するポリシーである。
予約変更ポリシーに基づいて利用予約を再設定することにより、限られたリソース３０をより効率的に利用することができ、予約済みのリソース３０が利用不可となったことによるユーザ２０への影響を最小限にすることができる。
予約変更ポリシーとは、変更対象予約の全てを他のリソース３０に再設定することが不可能な場合に、いずれの利用予約を優先して再設定するかを規定するポリシーである。
予約変更ポリシーに基づいて利用予約を再設定することにより、限られたリソース３０をより効率的に利用することができ、予約済みのリソース３０が利用不可となったことによるユーザ２０への影響を最小限にすることができる。
以下、より詳細に予約変更部４０４による予約変更処理ついて説明するが、これに先立って、リソース予約管理装置４２による予約受付処理について説明する。
図６は、リソース予約管理装置４２による予約受付処理の手順を示すフローチャートである。
図６は、リソース予約管理装置４２による予約受付処理の手順を示すフローチャートである。
予約に先立って、リソース予約管理装置４２の予約変更部４０４は、リソース共有システム１０の管理者から予約変更ポリシーの設定を受け付けておく（ステップＳ１００）。なお、予約変更ポリシーの設定内容は、任意のタイミングで変更可能である。
そして、リソース予約管理装置４２の予約設定部４０２は、ユーザ２０（ユーザ端末）から予約要求を受信したか否かを判定する（ステップＳ１０２）。そして、受信した場合（ステップＳ１０２：Ｙｅｓ）、予約設定部４０２は、所定のリソース（ユーザ２０が指定した種類のリソース３０）に利用予約を設定する（ステップＳ１０４）。一方、予約設定部４０２は、予約要求を受信していない場合には（ステップＳ１０２：Ｎｏ）、受信するまで待つ。
予約設定部４０２は、利用予約を設定したリソース３０に故障等が発生せず、利用可能な場合は（ステップＳ１０６：Ｙｅｓ）、ステップＳ１０２に戻り、利用予約の受付を継続する。なお、図示は省略しているが、利用予約に設定された利用日時となった場合、リソース予約管理装置４２は適宜ユーザ２０にリソース３０の利用権を与える（予約の実行）。
一方、利用予約を設定したリソース３０に故障等が発生し、利用不可となった場合（ステップＳ１０６：Ｎｏ）、予約設定部４０２は、新規の予約要求の受付を停止する（ステップＳ１０８）。
これは、新規予約の受付よりも、利用不可となったリソース３０に入っていた利用予約（変更対象予約）の再設定（振り替え）を優先させるためである。このようにすることで、新規の予約により元々設定されていた利用予約の振り替えが不成立となることを防止することができる。
これは、新規予約の受付よりも、利用不可となったリソース３０に入っていた利用予約（変更対象予約）の再設定（振り替え）を優先させるためである。このようにすることで、新規の予約により元々設定されていた利用予約の振り替えが不成立となることを防止することができる。
また、予約変更部４０４は、利用可能なリソース３０（他のリソース３０）の空き状況の情報を取得し（ステップＳ１１０）、利用不可となったリソース３０に入っていた利用予約（変更対象予約）の全てを他のリソース３０に振り替え可能か否かを判断する（ステップＳ１１２）。
リソース３０に空きが十分ある場合など、全ての変更対象予約を他のリソース３０に振り替え可能な場合（ステップＳ１１２：Ｙｅｓ）、予約変更部４０４は、全ての変更対象予約を他のリソース３０に振り替える（ステップＳ１１４）。
一方、リソース３０に空きが少ない場合など、全ての変更対象予約の振り替えが不可能な場合は（ステップＳ１１２：Ｎｏ）、ステップＳ１００で設定された予約変更ポリシーに基づいて優先度の高い利用予約から順に他のリソース３０に再設定する（ステップＳ１１６）。この結果、優先度の低い利用予約は予約不成立となる可能性がある。
利用予約の振り替えまたは再設定が完了すると、予約設定部４０２は新規の予約要求の受付を再開し（ステップＳ１１８）、ステップＳ１０２に戻り以降の処理を繰り返す。なお、予約受付再開後は、利用可能なリソース３０にのみ利用予約を割り振る。
つぎに、予約変更ポリシーに基づく利用予約の再設定（図６のステップＳ１１６）の詳細について説明する。
本実施形態では、予約変更ポリシーとして以下の６つの基準を例示する。
図６のステップＳ１００では、下記ポリシー１〜６のいずれを採用するかをリソース共有システム１０の管理者が決定し、リソース予約管理装置４２の予約変更部４０４がそれを受け付けて設定しておく。
本実施形態では、予約変更ポリシーとして以下の６つの基準を例示する。
図６のステップＳ１００では、下記ポリシー１〜６のいずれを採用するかをリソース共有システム１０の管理者が決定し、リソース予約管理装置４２の予約変更部４０４がそれを受け付けて設定しておく。
ポリシー１：ユーザ指定優先度ベース
ポリシー２：先発優先
ポリシー３：小容量優先
ポリシー４：短時間優先
ポリシー５：混合型
ポリシー６：実行予約数最大化
以下、各ポリシーの詳細について説明する。
ポリシー２：先発優先
ポリシー３：小容量優先
ポリシー４：短時間優先
ポリシー５：混合型
ポリシー６：実行予約数最大化
以下、各ポリシーの詳細について説明する。
＜ポリシー１：ユーザ指定優先度ベース＞
ポリシー１では、予約要求時にユーザ２０が当該予約の優先度を指定する。そして、予約再設定時には、優先度が高い予約から順に（優先的に）再設定する。
すなわち、ユーザ２０からの予約要求は当該利用予約の優先度を示す情報を含んでおり、予約変更ポリシー（ポリシー１）は、優先度が高い利用予約を優先して他のリソース３０に再設定すると規定する。
このようにすることで、利用予約の再設定順序にユーザの意思を反映することができ、ユーザの利便性を向上させることができる。
ポリシー１では、予約要求時にユーザ２０が当該予約の優先度を指定する。そして、予約再設定時には、優先度が高い予約から順に（優先的に）再設定する。
すなわち、ユーザ２０からの予約要求は当該利用予約の優先度を示す情報を含んでおり、予約変更ポリシー（ポリシー１）は、優先度が高い利用予約を優先して他のリソース３０に再設定すると規定する。
このようにすることで、利用予約の再設定順序にユーザの意思を反映することができ、ユーザの利便性を向上させることができる。
ポリシー１を採用した場合、優先度が低い予約は予約不成立となる可能性が高くなる。
これに伴い、各予約の優先度に偏りが生じる（例えば全ての予約が優先度の最大値に設定されるなど）のを防ぐため、例えばプロジェクトやユーザ２０ごとに優先度の制限をかけたり、全体の優先度要求状況を考慮して各ユーザ２０からの優先度要求の優先度を正規化するなどしてもよい。
これに伴い、各予約の優先度に偏りが生じる（例えば全ての予約が優先度の最大値に設定されるなど）のを防ぐため、例えばプロジェクトやユーザ２０ごとに優先度の制限をかけたり、全体の優先度要求状況を考慮して各ユーザ２０からの優先度要求の優先度を正規化するなどしてもよい。
図７は、ポリシー１を適用した場合の予約再設定順序を示す説明図である。
図７には、４つの予約（予約１〜予約４）の内容を例示しており、左から順に予約識別子、利用日時、利用期間、利用リソースおよびユーザ２０により設定された優先度を示している。図７では利用日時および利用期間を日単位で示している。
図７には、４つの予約（予約１〜予約４）の内容を例示しており、左から順に予約識別子、利用日時、利用期間、利用リソースおよびユーザ２０により設定された優先度を示している。図７では利用日時および利用期間を日単位で示している。
図７の例では、優先度の値が大きい順に優先度が高くなっており、優先度１０の予約１、優先度８の予約３、優先度５の予約４、優先度１の予約２の順に（優先して）他のリソース３０へと再設定する。既に予約が入っているリソース３０には予約が設定できないため、優先度が低い予約ほど予約が不成立となる可能性が高くなる。
＜ポリシー２：先発優先＞
ポリシー２では、利用開始日時が早い予約（先発予約）から順に再設定する。
すなわち、ユーザ２０からの予約要求は、リソース３０を利用する日時を示す情報を含んでおり、予約変更ポリシー（ポリシー２）は、リソース３０の利用開始日時が早い利用予約を優先して再設定すると規定する。
これは、利用不可となったリソース３０はいずれ復旧されるため、喫緊に影響を受ける予約を優先的に復旧するものである。つまり、利用不可となったリソース３０が復旧するまでに開始される可能性が高い予約を優先して再設定することができ、予約不成立となる予約数を低減することができる。
ポリシー２では、利用開始日時が早い予約（先発予約）から順に再設定する。
すなわち、ユーザ２０からの予約要求は、リソース３０を利用する日時を示す情報を含んでおり、予約変更ポリシー（ポリシー２）は、リソース３０の利用開始日時が早い利用予約を優先して再設定すると規定する。
これは、利用不可となったリソース３０はいずれ復旧されるため、喫緊に影響を受ける予約を優先的に復旧するものである。つまり、利用不可となったリソース３０が復旧するまでに開始される可能性が高い予約を優先して再設定することができ、予約不成立となる予約数を低減することができる。
図８は、ポリシー２を適用した場合の予約再設定順序を示す説明図である。
図８に示す４つの予約（予約１〜予約４）の内容は図７と同様である。
図８の例では、利用開始日時が２０１８／０２／１０の予約３、２０１８／０３／１２の予約１、２０１８／０４／０１の予約２、２０１８／０４／０２の予約４の順に（優先して）他のリソース３０へと再設定する。
利用開始日時が遅い予約は当初は予約不成立となる可能性が高くなるが、利用開始日時までにリソース３０が復旧すれば予約の再設定が可能となる。
図８に示す４つの予約（予約１〜予約４）の内容は図７と同様である。
図８の例では、利用開始日時が２０１８／０２／１０の予約３、２０１８／０３／１２の予約１、２０１８／０４／０１の予約２、２０１８／０４／０２の予約４の順に（優先して）他のリソース３０へと再設定する。
利用開始日時が遅い予約は当初は予約不成立となる可能性が高くなるが、利用開始日時までにリソース３０が復旧すれば予約の再設定が可能となる。
＜ポリシー３：小容量優先＞
ポリシー３では、利用リソース量の小さい予約から順に再設定する。
すなわち、ユーザ２０からの予約要求は、利用するリソース３０のリソース量を示す情報を含んでおり、予約変更ポリシー（ポリシー３）は、リソース量が少ない利用予約を優先して再設定すると規定する。
これは、再設定可能な予約数をなるべく多くし、不成立となる予約の数を低減させるためである。
ポリシー３では、利用リソース量の小さい予約から順に再設定する。
すなわち、ユーザ２０からの予約要求は、利用するリソース３０のリソース量を示す情報を含んでおり、予約変更ポリシー（ポリシー３）は、リソース量が少ない利用予約を優先して再設定すると規定する。
これは、再設定可能な予約数をなるべく多くし、不成立となる予約の数を低減させるためである。
図９は、ポリシー３を適用した場合の予約再設定順序を示す説明図である。
図９に示す４つの予約（予約１〜予約４）の内容は図７と同様である。
図９の例では、予約リソース量が（１コア、２ＧＢ ＲＡＭ、５ＧＢ ｄｉｓｋ）×１台の予約４、（２コア、４ＧＢ ＲＡＭ、１０ＧＢ ｄｉｓｋ）×３台の予約１、（４コア、８ＧＢ ＲＡＭ、１００ＧＢ ｄｉｓｋ）×４台の予約３、（８コア、１６ＧＢ ＲＡＭ、１００ＧＢ ｄｉｓｋ）×４台の予約２の順に（優先して）他のリソース３０へと再設定する。
利用リソース量が大きい予約では１つの予約でリソース３０を消費してしまう場合でも、利用リソース量が小さい予約を割り当てれば複数の予約を割り当て可能となる可能性が高くなる。
図９に示す４つの予約（予約１〜予約４）の内容は図７と同様である。
図９の例では、予約リソース量が（１コア、２ＧＢ ＲＡＭ、５ＧＢ ｄｉｓｋ）×１台の予約４、（２コア、４ＧＢ ＲＡＭ、１０ＧＢ ｄｉｓｋ）×３台の予約１、（４コア、８ＧＢ ＲＡＭ、１００ＧＢ ｄｉｓｋ）×４台の予約３、（８コア、１６ＧＢ ＲＡＭ、１００ＧＢ ｄｉｓｋ）×４台の予約２の順に（優先して）他のリソース３０へと再設定する。
利用リソース量が大きい予約では１つの予約でリソース３０を消費してしまう場合でも、利用リソース量が小さい予約を割り当てれば複数の予約を割り当て可能となる可能性が高くなる。
＜ポリシー４：短時間優先＞
ポリシー４では、利用期間の短い予約から順に予約再設定を行う。
すなわち、ユーザ２０からの予約要求は、リソース３０を利用する期間を示す情報を含んでおり、予約変更ポリシー（ポリシー４）は、リソース３０の利用期間が短い利用予約を優先して再設定すると規定する。
これは、ポリシー３同様、再設定可能な予約数をなるべく多くし、不成立となる予約の数を低減させるためである。
ポリシー４では、利用期間の短い予約から順に予約再設定を行う。
すなわち、ユーザ２０からの予約要求は、リソース３０を利用する期間を示す情報を含んでおり、予約変更ポリシー（ポリシー４）は、リソース３０の利用期間が短い利用予約を優先して再設定すると規定する。
これは、ポリシー３同様、再設定可能な予約数をなるべく多くし、不成立となる予約の数を低減させるためである。
図１０は、ポリシー４を適用した場合の予約再設定順序を示す説明図である。
図１０に示す４つの予約（予約１〜予約４）の内容は図７と同様である。
図１０の例では、利用期間が３日間の予約２、６日間の予約３、１６日間の予約１、２９日間の予約４の順に優先して他のリソース３０へと再設定する。
利用期間が長い予約では１つの予約でリソース３０を消費してしまう場合でも、利用期間が短い予約を割り当てれば複数の予約を割り当て可能となる可能性が高くなる。
図１０に示す４つの予約（予約１〜予約４）の内容は図７と同様である。
図１０の例では、利用期間が３日間の予約２、６日間の予約３、１６日間の予約１、２９日間の予約４の順に優先して他のリソース３０へと再設定する。
利用期間が長い予約では１つの予約でリソース３０を消費してしまう場合でも、利用期間が短い予約を割り当てれば複数の予約を割り当て可能となる可能性が高くなる。
＜ポリシー５：混合型＞
ポリシー５では、上記ポリシー２〜４の各指標、すなわち利用開始日時（先発優先）、利用リソース量（小容量優先）、利用期間（短時間優先）にそれぞれ重みづけを行って積算したスコアＳを計算し、スコアＳの高いものから順に予約再設定する。
このようにすることで、優先して再設定する予約を決定する際に複数の要因を反映することができる。なお、先発優先（ポリシー２）で設定される優先順序を「先発優先度」とし、小容量優先（ポリシー３）で設定される優先順序を「容量優先度」とし、短時間優先（ポリシー４）で設定される優先順序を「期間優先度」とする。
ポリシー５では、上記ポリシー２〜４の各指標、すなわち利用開始日時（先発優先）、利用リソース量（小容量優先）、利用期間（短時間優先）にそれぞれ重みづけを行って積算したスコアＳを計算し、スコアＳの高いものから順に予約再設定する。
このようにすることで、優先して再設定する予約を決定する際に複数の要因を反映することができる。なお、先発優先（ポリシー２）で設定される優先順序を「先発優先度」とし、小容量優先（ポリシー３）で設定される優先順序を「容量優先度」とし、短時間優先（ポリシー４）で設定される優先順序を「期間優先度」とする。
スコアＳは、例えば下記（式１）のように算出する。
スコアＳ ＝ 先発優先度×ｗ１＋容量優先度×ｗ２＋期間優先度×ｗ３・・（式１）
（ｗ１，ｗ２，ｗ３： 各指標の重み）
スコアＳ ＝ 先発優先度×ｗ１＋容量優先度×ｗ２＋期間優先度×ｗ３・・（式１）
（ｗ１，ｗ２，ｗ３： 各指標の重み）
なお、先発優先度、容量優先度、期間優先度の３つの指標を用いるのではなく、上記３つの指標のうち任意の２つの指標を用いてスコアを算出してもよい。
すなわち、ユーザ２０からの予約要求は、リソース３０を利用する日時を示す情報、利用するリソース３０のリソース量を示す情報、リソース３０を利用する期間を示す情報のうち、少なくとも２つの情報（指標）を含んでおり、予約変更ポリシー（ポリシー５）は、上記少なくとも２つの情報に対してそれぞれ重み付けを行ってスコア化し、スコアの大小に基づいて（優先して）再設定する利用予約を決定すると規定する。
すなわち、ユーザ２０からの予約要求は、リソース３０を利用する日時を示す情報、利用するリソース３０のリソース量を示す情報、リソース３０を利用する期間を示す情報のうち、少なくとも２つの情報（指標）を含んでおり、予約変更ポリシー（ポリシー５）は、上記少なくとも２つの情報に対してそれぞれ重み付けを行ってスコア化し、スコアの大小に基づいて（優先して）再設定する利用予約を決定すると規定する。
＜ポリシー６：実行可能予約数最大化＞
ポリシー６では、例えばＢｉｎ ｐａｃｋｉｎｇのような全体最適化アルゴリズム（非特許文献３参照）を利用し、予約変更に失敗する予約数が最小となるような順番で予約を再設定する。
すなわち、予約変更ポリシー（ポリシー６）は、Ｂｉｎ Ｐａｃｋｉｎｇ問題を解決するアルゴリズムを用いて、実行可能な利用予約の数が最大となるように利用予約を再設定すると規定する。
このようにすることで、リソース共有システム１０全体で実行可能な予約を最大化することができ、より効率的に予約を設定することができる。
ポリシー６では、例えばＢｉｎ ｐａｃｋｉｎｇのような全体最適化アルゴリズム（非特許文献３参照）を利用し、予約変更に失敗する予約数が最小となるような順番で予約を再設定する。
すなわち、予約変更ポリシー（ポリシー６）は、Ｂｉｎ Ｐａｃｋｉｎｇ問題を解決するアルゴリズムを用いて、実行可能な利用予約の数が最大となるように利用予約を再設定すると規定する。
このようにすることで、リソース共有システム１０全体で実行可能な予約を最大化することができ、より効率的に予約を設定することができる。
なお、本実施形態において、再設定の対象となる予約は以下の２パターンが考えられる。
＜パターン１＞
利用不可となったリソース３０に設定されている予約（変更対象予約）
パターン１の場合、利用不可となったリソース３０に設定されていた利用予約のみが再設定（振り替え）対象となり、障害等が発生していない利用可能なリソース３０に入っていた予約は影響を受けない。
＜パターン２＞
全てリソース３０に設定されている予約（変更対象予約＋利用可能なリソース３０に設定されている予約）
パターン２の場合、全ての利用予約が再設定対象となり、利用可能なリソース３０に設定されている予約も影響（予約不成立など）を受ける可能性がある。
＜パターン１＞
利用不可となったリソース３０に設定されている予約（変更対象予約）
パターン１の場合、利用不可となったリソース３０に設定されていた利用予約のみが再設定（振り替え）対象となり、障害等が発生していない利用可能なリソース３０に入っていた予約は影響を受けない。
＜パターン２＞
全てリソース３０に設定されている予約（変更対象予約＋利用可能なリソース３０に設定されている予約）
パターン２の場合、全ての利用予約が再設定対象となり、利用可能なリソース３０に設定されている予約も影響（予約不成立など）を受ける可能性がある。
例えばポリシー１は、予約要求時に指定された優先度が高い予約を優先して再設定するが、パターン１を採用した場合には、障害が発生していないリソース３０では当初の予約通りに優先度が低い予約が実行され、障害が発生したリソース３０に予約されていた比較的優先度が高い予約が実行できない、という事象が発生する可能性がある。
これに対して、パターン２を採用した場合には、障害が発生していないリソース３０に元々設定されていた予約を含めて、全ての予約について優先度が高い順に再設定されるため、より確実に優先度が高い予約を実行することができる。
すなわち、パターン２を用いることでシステム全体の予約を最適化することができる。
一方で、パターン１は変更対象予約のみが再設定対象であるため、リソース予約管理装置４２の処理負荷を軽減することができ、リソース３０の障害発生時により迅速に対応することができる。
これに対して、パターン２を採用した場合には、障害が発生していないリソース３０に元々設定されていた予約を含めて、全ての予約について優先度が高い順に再設定されるため、より確実に優先度が高い予約を実行することができる。
すなわち、パターン２を用いることでシステム全体の予約を最適化することができる。
一方で、パターン１は変更対象予約のみが再設定対象であるため、リソース予約管理装置４２の処理負荷を軽減することができ、リソース３０の障害発生時により迅速に対応することができる。
以上説明したように、本実施形態に係るリソース共有システム１０のリソース予約管理装置４２によれば、所定のリソース３０が利用不可となり、かつ再設定すべき利用予約に対して空きのある他のリソース３０のリソース量が不足する場合に、優先的に再設定する予約を一意に決定し、システムの効率を向上させることができる。
１０ リソース共有システム
２０ ユーザ（ユーザ端末）
３０ リソース
３２ 共通ネットワーク
３４ クラウドオペレーティングシステム
４０ システム管理装置
４２ リソース予約管理装置
４０２ 予約設定部
４０４ 予約変更部
２０ ユーザ（ユーザ端末）
３０ リソース
３２ 共通ネットワーク
３４ クラウドオペレーティングシステム
４０ システム管理装置
４２ リソース予約管理装置
４０２ 予約設定部
４０４ 予約変更部
Claims (8)
- 複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理装置であって、
前記ユーザ端末から前記リソースの予約要求を受け付け、前記リソース共有システム内の所定のリソースに利用予約を設定する予約設定部と、
前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更部と、を備え、
前記予約変更部は、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記再設定すべき利用予約のうちいずれの利用予約を優先して再設定するかを規定する予約変更ポリシーに基づいて、前記他のリソースに前記利用予約を再設定する、
ことを特徴とするリソース予約管理装置。 - 前記予約要求は、当該利用予約の優先度を示す情報を含んでおり、
前記予約変更ポリシーは、前記優先度が高い前記利用予約を優先して再設定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。 - 前記予約要求は、前記リソースを利用する日時を示す情報を含んでおり、
前記予約変更ポリシーは、前記リソースの利用開始日時が早い前記利用予約を優先して再設定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。 - 前記予約要求は、利用する前記リソースのリソース量を示す情報を含んでおり、
前記予約変更ポリシーは、前記リソース量が少ない前記利用予約を優先して再設定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。 - 前記予約要求は、前記リソースを利用する期間を示す情報を含んでおり、
前記予約変更ポリシーは、前記リソースの利用期間が短い前記利用予約を優先して再設定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。 - 前記予約要求は、前記リソースを利用する日時を示す情報、利用する前記リソースのリソース量を示す情報、前記リソースを利用する期間を示す情報のうち、少なくとも２つの情報を含んでおり、
前記予約変更ポリシーは、前記少なくとも２つの情報に対してそれぞれ重み付けを行ってスコア化し、スコアの大小に基づいて優先して再設定する前記利用予約を決定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。 - 前記予約変更ポリシーは、Ｂｉｎ Ｐａｃｋｉｎｇ問題を解決するアルゴリズムを用いて、実行可能な前記利用予約の数が最大となるように前記利用予約を再設定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。 - 複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理方法であって、
前記ユーザ端末から前記リソースの予約要求を受け付け、前記リソース共有システム内の所定のリソースに利用予約を設定する予約設定工程と、
前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更工程と、を含み、
前記予約変更工程では、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記再設定すべき利用予約のうちいずれの利用予約を優先して再設定するかを規定する予約変更ポリシーに基づいて、前記他のリソースに前記利用予約を再設定する、
ことを特徴とするリソース予約管理方法。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018105868A JP2019211890A (ja) | 2018-06-01 | 2018-06-01 | リソース予約管理装置およびリソース予約管理方法 |
| US17/058,745 US11343199B2 (en) | 2018-06-01 | 2019-05-24 | Resource reservation management device and resource reservation management method |
| PCT/JP2019/020583 WO2019230577A1 (ja) | 2018-06-01 | 2019-05-24 | リソース予約管理装置およびリソース予約管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018105868A JP2019211890A (ja) | 2018-06-01 | 2018-06-01 | リソース予約管理装置およびリソース予約管理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2019211890A true JP2019211890A (ja) | 2019-12-12 |
Family
ID=68697070
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2018105868A Pending JP2019211890A (ja) | 2018-06-01 | 2018-06-01 | リソース予約管理装置およびリソース予約管理方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US11343199B2 (ja) |
| JP (1) | JP2019211890A (ja) |
| WO (1) | WO2019230577A1 (ja) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004302918A (ja) * | 2003-03-31 | 2004-10-28 | Hitachi Ltd | 負荷分散方法及びその実施システム並びにその処理プログラム |
| JP2005234637A (ja) * | 2004-02-17 | 2005-09-02 | Hitachi Ltd | 計算機リソース管理方法及び実施装置並びに処理プログラム |
| JP2010028195A (ja) * | 2008-07-15 | 2010-02-04 | Panasonic Corp | リソース管理装置、リソース管理方法及びリソース管理プログラム |
| WO2012157754A1 (ja) * | 2011-05-19 | 2012-11-22 | 日本放送協会 | 放送通信連携受信装置 |
| WO2014119719A1 (ja) * | 2013-02-01 | 2014-08-07 | 日本電気株式会社 | リソース制御システム、制御パターン生成装置、制御装置、リソース制御方法及びプログラム |
| JP2016110448A (ja) * | 2014-12-08 | 2016-06-20 | 株式会社デンソー | 診断・修理事例検索装置 |
| JP2017033117A (ja) * | 2015-07-30 | 2017-02-09 | 日本電信電話株式会社 | クラスタ内リソース管理システム、クラスタ内リソース管理方法、管理サーバ及びプログラム |
| US20170083432A1 (en) * | 2015-09-17 | 2017-03-23 | International Business Machines Corporation | Prioritization of test cases |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7464147B1 (en) * | 1999-11-10 | 2008-12-09 | International Business Machines Corporation | Managing a cluster of networked resources and resource groups using rule - base constraints in a scalable clustering environment |
| US9015324B2 (en) * | 2005-03-16 | 2015-04-21 | Adaptive Computing Enterprises, Inc. | System and method of brokering cloud computing resources |
| US9466036B1 (en) * | 2012-05-10 | 2016-10-11 | Amazon Technologies, Inc. | Automated reconfiguration of shared network resources |
| EP3028224A4 (en) * | 2013-07-31 | 2017-01-18 | Livelyhood, Inc. | Systems and methods for providing on demand business resources |
| US9280392B1 (en) * | 2014-10-02 | 2016-03-08 | International Business Machines Corporation | Resource substitution and reallocation in a virtual computing environment |
| CN107113616A (zh) * | 2014-11-03 | 2017-08-29 | 诺基亚通信公司 | 基于无线网络中的资源的动态分配保护资源信息 |
| US9888127B2 (en) * | 2015-07-30 | 2018-02-06 | At&T Intellectual Property I, L.P. | Methods, systems, and computer readable storage devices for adjusting the use of virtual resources providing communication services based on load |
| KR102365755B1 (ko) * | 2015-11-11 | 2022-02-22 | 한국전자통신연구원 | 네트워크 관리 서버의 자원 관리 방법 및 네트워크 관리 서버를 포함하는 피투피 시스템 |
| US10313479B2 (en) * | 2015-11-24 | 2019-06-04 | Vmware, Inc. | Methods and apparatus to manage workload domains in virtual server racks |
| US11119824B2 (en) * | 2016-06-30 | 2021-09-14 | Intel Corporation | Technologies for implementing consolidated device infrastructure systems |
| US11150950B2 (en) * | 2016-12-01 | 2021-10-19 | Vmware, Inc. | Methods and apparatus to manage workload domains in virtual server racks |
-
2018
- 2018-06-01 JP JP2018105868A patent/JP2019211890A/ja active Pending
-
2019
- 2019-05-24 WO PCT/JP2019/020583 patent/WO2019230577A1/ja active Application Filing
- 2019-05-24 US US17/058,745 patent/US11343199B2/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004302918A (ja) * | 2003-03-31 | 2004-10-28 | Hitachi Ltd | 負荷分散方法及びその実施システム並びにその処理プログラム |
| JP2005234637A (ja) * | 2004-02-17 | 2005-09-02 | Hitachi Ltd | 計算機リソース管理方法及び実施装置並びに処理プログラム |
| JP2010028195A (ja) * | 2008-07-15 | 2010-02-04 | Panasonic Corp | リソース管理装置、リソース管理方法及びリソース管理プログラム |
| WO2012157754A1 (ja) * | 2011-05-19 | 2012-11-22 | 日本放送協会 | 放送通信連携受信装置 |
| WO2014119719A1 (ja) * | 2013-02-01 | 2014-08-07 | 日本電気株式会社 | リソース制御システム、制御パターン生成装置、制御装置、リソース制御方法及びプログラム |
| JP2016110448A (ja) * | 2014-12-08 | 2016-06-20 | 株式会社デンソー | 診断・修理事例検索装置 |
| JP2017033117A (ja) * | 2015-07-30 | 2017-02-09 | 日本電信電話株式会社 | クラスタ内リソース管理システム、クラスタ内リソース管理方法、管理サーバ及びプログラム |
| US20170083432A1 (en) * | 2015-09-17 | 2017-03-23 | International Business Machines Corporation | Prioritization of test cases |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2019230577A1 (ja) | 2019-12-05 |
| US20210377183A1 (en) | 2021-12-02 |
| US11343199B2 (en) | 2022-05-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110647394B (zh) | 一种资源分配方法、装置及设备 | |
| JP6373432B2 (ja) | 仮想環境における演算インフラストラクチャのリアルタイム最適化 | |
| EP2524311B1 (en) | Managing private use of program execution capacity | |
| CN107018091B (zh) | 资源请求的调度方法和装置 | |
| JP6636142B2 (ja) | スケールアウト関連付けの方法および装置、ならびにシステム | |
| US9246986B1 (en) | Instance selection ordering policies for network-accessible resources | |
| WO2021227999A1 (zh) | 云计算服务系统和方法 | |
| JP2013517544A5 (ja) | ||
| WO2017084453A1 (zh) | 云平台资源管理方法、装置及系统 | |
| CN112783659B (zh) | 一种资源分配方法、装置、计算机设备及存储介质 | |
| JPWO2018220708A1 (ja) | 資源割当システム、管理装置、方法およびプログラム | |
| WO2019230576A1 (ja) | リソース予約管理装置およびリソース予約管理方法 | |
| CN111338785A (zh) | 资源调度方法及装置、电子设备、存储介质 | |
| CN108718327A (zh) | 一种许可证资源调度方法及系统 | |
| JP6010975B2 (ja) | ジョブ管理装置、ジョブ管理方法、及びプログラム | |
| CN111427670A (zh) | 任务调度方法和系统 | |
| JP5790758B2 (ja) | スケジューリング方法およびスケジューリングシステム | |
| CN111240824A (zh) | 一种cpu资源调度方法及电子设备 | |
| JP2007328413A (ja) | 負荷分散方法 | |
| CN116157778A (zh) | 共享物理主机上混合集中分布式调度的系统和方法 | |
| WO2019230577A1 (ja) | リソース予約管理装置およびリソース予約管理方法 | |
| CN111488373A (zh) | 用于处理请求的方法和系统 | |
| US11762704B2 (en) | Resource allocation device, resource management system, and resource allocation program | |
| WO2016017161A1 (ja) | 仮想計算機システム、スケジューリング方法、および、プログラム記憶媒体 | |
| JP6339978B2 (ja) | リソース割当管理装置およびリソース割当管理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20201012 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20210817 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20220222 |