JP2022115430A - 情報処理プログラム、情報処理方法および情報処理装置 - Google Patents
情報処理プログラム、情報処理方法および情報処理装置 Download PDFInfo
- Publication number
- JP2022115430A JP2022115430A JP2021012019A JP2021012019A JP2022115430A JP 2022115430 A JP2022115430 A JP 2022115430A JP 2021012019 A JP2021012019 A JP 2021012019A JP 2021012019 A JP2021012019 A JP 2021012019A JP 2022115430 A JP2022115430 A JP 2022115430A
- Authority
- JP
- Japan
- Prior art keywords
- application
- terminals
- terminal
- patch
- index value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
【課題】パッチ適用を効率良く行うこと。【解決手段】記憶部11は、複数の端末それぞれの過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションの実行予定および他のパッチ適用の予定の少なくとも1つ以上の指標を示す情報を記憶する。処理部12は、複数の端末の数、適用期間および1つの端末当たりの最大適用回数に基づく単位時間当たりのパッチ適用の制限台数を取得する。処理部12は、記憶部11に記憶された少なくとも1つ以上の指標に基づいて算出された負荷指標値であって、適用期間に属する複数の時間帯それぞれにおける複数の端末それぞれの負荷指標値を取得する。処理部12は、制限台数と負荷指標値とに基づいて、複数の端末それぞれに対するパッチ適用のタイミングを制御する。【選択図】図1
Description
本発明は情報処理プログラム、情報処理方法および情報処理装置に関する。
現在、多数の端末を含む情報処理システムが利用されている。端末は、物理マシンによって実現されることもあるし、物理マシン上で動作する仮想マシンによって実現されることもある。ここで、各端末で実行されるオペレーティングシステム(OS:Operating System)などのソフトウェアに対して、更新プログラムが配信されることがある。更新プログラムは、パッチと呼ばれることもある。そこで、更新プログラムの適用を制御する方法が考えられている。
例えば、予め登録された稼働スケジュールと、更新プログラムのインストールのために要するインストールコストとに基づいて、更新プログラムをインストールするための最適なインストール時間帯を算出する情報処理装置の提案がある。
また、ユーザが通信端末を使用しない時間帯を記憶し、当該時間帯等にプログラムの更新を行う通信端末の提案もある。更に、非使用状態にある端末を抽出し、端末に組み込まれているソフトウェアの更新を自動的に行うソフト自動更新装置の提案もある。
端末に対するパッチ適用は失敗することがある。ある端末に対して予定されたパッチ適用が失敗すると、パッチ適用の予定が別の日時に繰り越される。すると、繰り越し先の日時において比較的多くの端末に対するパッチ適用が集中する可能性が高まる。比較的多くの端末に対するパッチ適用が一部の日時に集中すると、各端末でパッチを取得するためのネットワーク負荷や仮想マシンとして端末を動作させる物理マシンの負荷などの環境負荷が増大し得る。このため、パッチ適用に時間がかかったり、パッチ適用が予定時間内に終わらなかったりして、パッチ適用の効率が悪化する可能性がある。
1つの側面では、本発明は、パッチ適用を効率良く行う情報処理プログラム、情報処理方法および情報処理装置を提供することを目的とする。
1つの態様では、複数の端末に対するパッチ適用のタイミングを制御する情報処理プログラムが提供される。この情報処理プログラムは、コンピュータに、複数の端末の数、適用期間および1つの端末当たりの最大適用回数に基づく単位時間当たりのパッチ適用の制限台数を取得し、複数の端末それぞれの過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションの実行予定および他のパッチ適用の予定の少なくとも1つ以上の指標に基づいて算出された負荷指標値であって、適用期間に属する複数の時間帯それぞれにおける複数の端末それぞれの負荷指標値を取得し、制限台数と負荷指標値とに基づいて、複数の端末それぞれに対するパッチ適用のタイミングを制御する、処理を実行させる。
また、1つの態様では、情報処理方法が提供される。
また、1つの態様では、情報処理装置が提供される。
また、1つの態様では、情報処理装置が提供される。
1つの側面では、パッチ適用を効率良く行うことができる。
以下、本実施の形態について図面を参照して説明する。
[第1の実施の形態]
第1の実施の形態を説明する。
[第1の実施の形態]
第1の実施の形態を説明する。
図1は、第1の実施の形態の情報処理装置を説明する図である。
情報処理装置10は、複数の端末それぞれに対するOSなどのソフトウェアのパッチ適用のタイミングを制御する。複数の端末は、例えば、端末21,22,23,24,25を含む。複数の端末の数は5台以外でもよい。情報処理装置10および端末21~25は、ネットワーク5に接続される。パッチは、例えば、ネットワーク5を介して端末21~25に接続された所定の情報処理装置(図示を省略している)により配信される。
情報処理装置10は、複数の端末それぞれに対するOSなどのソフトウェアのパッチ適用のタイミングを制御する。複数の端末は、例えば、端末21,22,23,24,25を含む。複数の端末の数は5台以外でもよい。情報処理装置10および端末21~25は、ネットワーク5に接続される。パッチは、例えば、ネットワーク5を介して端末21~25に接続された所定の情報処理装置(図示を省略している)により配信される。
端末21~25は、物理マシンにより実現されてもよいし、ある物理マシン上の仮想マシンにより実現されてもよい。端末21の識別情報(ID:IDentifier)を「X1」とする。端末22のIDを「X2」とする。端末23のIDを「X3」とする。端末24のIDを「X4」とする。端末25のIDを「X5」とする。
情報処理装置10は、記憶部11および処理部12を有する。記憶部11は、RAM(Random Access Memory)などの揮発性記憶装置でもよいし、HDD(Hard Disk Drive)やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部12は、CPU(Central Processing Unit)、DSP(Digital Signal Processor)、ASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)などを含み得る。処理部12はプログラムを実行するプロセッサでもよい。「プロセッサ」には、複数のプロセッサの集合(マルチプロセッサ)も含まれ得る。
記憶部11は、複数の端末それぞれの過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションソフトウェアの実行予定および他のパッチ適用の予定の少なくとも1つ以上の指標を示す情報を記憶する。
アプリケーションソフトウェアは、アプリケーションまたはアプリと略記されることがある。アプリケーションの実行予定には、例えば、Web会議ソフト、ウイルススキャンを行うウイルス対策ソフト、表計算ソフトおよび文書作成ソフトなど種々のアプリケーションの将来の実行予定が含まれ得る。ここで、ソフトは、ソフトウェアの略である。
例えば、Web会議ソフトの実行予定は、Web会議ソフトに登録された、ユーザのWeb会議への参加予定の情報から特定される。ウイルス対策ソフトによるウイルススキャンの実行予定は、ウイルス対策ソフトに登録された当該実行予定の情報から特定される。また、表計算ソフトなどのその他のソフトウェアの実行予定は、ユーザによる過去のソフトウェアの実行履歴から分析される各ソフトウェアが実行される時間帯の傾向に基づいて予測される。処理部12が、ソフトウェアの実行予定の予測を行ってもよい。
補助記憶装置のアクティブ率は、当該補助記憶装置の所定単位時間当たりのアクセス実行時間であり、ビジー率や使用率などとも呼ばれる。また、端末起動率は、過去の所定長さの時間帯において該当の端末が起動していた時間の長さの割合として表されてもよい。更に、過去のメモリ空き容量については、過去のメモリ使用量または過去のメモリ使用率(全サイズのうちの使用量の割合)などの情報を用いても実質的には同じである。なお、「メモリ」は、該当の端末が使用可能な主記憶装置を示す。
処理部12は、複数の端末の数、適用期間および1つの端末当たりの最大適用回数に基づく単位時間当たりのパッチ適用の制限台数を取得する。適用期間とは、複数の端末の全体に対するパッチ適用を行うための将来の起点の日時からパッチ適用を完了させるべき終点の日時までの時間である。最大適用回数とは、端末に対するパッチ適用が失敗することを考慮して、失敗分を含めて当該端末に許容される適用期間内の最大のパッチ適用回数である。
例えば、パッチ適用の対象となる端末の数をN台、適用期間をM日間、単位時間を1日、最大適用回数をa回、適用期間の終点からの余裕日をb日とするとき、制限台数Lは、L=(N/(M-b))*aと表される。Lの式の右辺の計算結果の小数以下は切り上げられる。なお、N,Mはそれぞれ2以上の整数であり、aは1以上の整数である。また、余裕日bは、適用期間の終点からどの程度早めに全端末へのパッチ適用を完了させるかを示す余裕時間の長さを示すパラメータである。余裕日bは0日以上とすることができる。処理部12は、複数の端末の数、適用期間および1つの端末当たりの最大適用回数の入力を受け付けて、制限台数Lを算出してもよい。
処理部12は、記憶部11に記憶された複数の端末それぞれの過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションの実行予定および他のパッチ適用の予定の少なくとも1つ以上の指標を取得する。処理部12は、当該1つ以上の指標に基づいて、適用期間に属する複数の時間帯それぞれにおける複数の端末それぞれの負荷指標値を算出する。例えば、負荷指標値は、大きい程負荷が高いことを表し、小さいほど負荷が低いことを表す負荷の指標値である。
例えば、処理部12は、過去の端末起動率および過去の補助記憶装置のアクティブ率の何れか1つの指標のみを使用してもよい。この場合、処理部12は、ある端末について当該指標の値の過去の変化の周期性を検出する。そして、処理部12は、当該周期性から予測される、適用期間内の時間帯における端末の当該指標の値が大きいほど、負荷指標値を大きい値とする。
ここで、指標の値の変化の周期性は、例えば、日単位、週単位および月単位などのパターンで検出され得る。例えば、週単位の周期性が見出される場合、処理部12は、適用期間内のある曜日のある時間帯の負荷指標値を、過去の同じ曜日の同じ時間帯における指標値の、直近の所定数の平均(例えば直近4日分の指標値の平均)などとして求めることができる。なお、時間帯の幅は、例えば9時00分から9時30分などのように、1日のうちの所定長さの時間範囲として定められる。
また、処理部12は、過去のメモリ空き容量のみを指標として使用してもよい。この場合、処理部12は、ある端末についてメモリ空き容量の過去の変化の周期性を検出する。そして、処理部12は、当該周期性から予測される、適用期間内の時間帯における端末のメモリ空き容量の値が小さいほど、負荷指標値を大きい値とする。
また、処理部12は、所定のアプリケーションの実行予定および他のパッチ適用の予定の何れか1つの指標のみを使用してもよい。この場合、処理部12は、ある端末について、適用期間におけるアプリケーションの実行予定または他のパッチ適用の予定がある時間帯の負荷指標値を、当該予定のない時間帯の負荷指標値よりも大きくする。
更に、処理部12は、過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションの実行予定および他のパッチ適用の予定のうちの2つ以上の指標を組み合わせて使用して負荷指標値を求めてもよい。この場合、処理部12は、各指標に対して個別に算出した該当の時間帯の負荷指標値を総合して、複数の指標に対し、正規化された1つの負荷指標値を算出する。例えば、処理部12は、ある端末の該当の時間帯に関し、各指標に対して個別に算出した負荷指標値の重み付け和を、複数の指標に対する1つの負荷指標値として算出してもよい。
グラフ31,32,33,…は、処理部12による負荷指標値の算出結果の例を表す。グラフ31,32,33,…の横軸は時間であり、縦軸は負荷指標値である。グラフ31は、端末21に対する負荷指標値の算出結果の例である。グラフ32は、端末22に対する負荷指標値の算出結果の例である。グラフ33は、端末23に対する負荷指標値の算出結果の例である。端末24,25に対する負荷指標値の算出結果の例の図示は省略されている。
処理部12は、取得した単位時間当たりの制限台数と適用期間における各端末の負荷指標値とに基づいて、複数の端末それぞれに対するパッチ適用のタイミングを制御する。例えば、処理部12は、適用期間の早い方の時間帯から順に、各端末に対するパッチ適用予定を割り当てる。このとき、処理部12は、対象の端末に対して求めた負荷指標値が小さい時間帯を優先して、当該端末に割り当てる。
パッチ適用スケジュール40は、処理部12による端末21~25へのパッチ適用予定の割り当て結果の例を示す。ここで、N=5,M=5,a=2,b=0であり、L=(5/5)*2=2である。適用期間は、単位時間で区切られた5つの時間範囲t1,t2,t3,t4,t5を含む。時間範囲t1から時間範囲t5へ向かう方向が時間の正方向である。例えば、処理部12は、端末のIDの数値の小さい順(X1,X2,…,X5の順)に、適用期間内の各時間帯の負荷指標値に基づいて、端末21~25に対するパッチ適用予定の時間帯を決定する。ただし、端末の順序は任意に決定することができる。
例えば、処理部12は、端末21に関して、時間範囲t1に属する時間帯に、負荷指標値の比較的小さな値となる箇所が存在するため、端末21のパッチ適用を時間範囲t1の該当の時間帯に割り当てる。同様にして、処理部12は、端末22を時間範囲t2に属する時間帯に割り当て、端末23を時間範囲t3に属する時間帯に割り当て、端末24を時間範囲t1に属する時間帯に割り当てる。この時点で、時間範囲t1に割り当てられた端末の数は制限台数L=2に達するため、時間範囲t1にはこれ以上端末のパッチ適用予定を割り当てることはできなくなる。そして、処理部12は、端末25を時間範囲t2に属する時間帯に割り当てる。これにより、時間範囲t2に割り当てられた端末の数は制限台数L=2に達する。
ここで、最大適用回数a=2としている。このため、処理部12は、各端末でパッチ適用が失敗したときの繰り越し用のスケジュールを決定することもできる。例えば、処理部12は、端末21に関して、時間範囲t3に属する時間帯に、負荷指標値の比較的小さな値となる箇所が存在するため、端末21のパッチ適用予定の繰り越し先を時間範囲t3の該当の時間帯に割り当ててもよい。これにより、時間範囲t3に割り当てられた端末の数は制限台数L=2に達する。同様にして、処理部12は、端末22の繰り越し先を時間範囲t5に属する時間帯に割り当て、端末23の繰り越し先を時間範囲t5に属する時間帯に割り当て、端末24の繰り越し先を時間範囲t4に属する時間帯に割り当てる。
このようにして、処理部12は、パッチ適用スケジュール40の情報を作成することができる。なお、上記の手順によってパッチ適用の時間帯を割り当てることができなかった端末が発生する場合も考えられる。この場合、処理部12は、例外的に、端末の負荷指標値に依らずに、パッチ適用スケジュール40の制限台数に達していない時間範囲の時間帯を該当の端末に割り当ててもよいし、制限台数を超えて、何れかの時間範囲の時間帯を該当の端末に割り当ててもよい。
そして、処理部12は、パッチ適用スケジュール40に従って、端末21~25それぞれに割り当てた時間帯においてパッチ適用を行うように、端末21~25に指示し、パッチ適用を実行させる。端末21~25は、処理部12から指示された時間帯において、情報処理装置10または前述の所定の情報処理装置からパッチをダウンロードして、自端末に対するパッチ適用を行う。
情報処理装置10によれば、複数の端末の数、適用期間および1つの端末当たりの最大適用回数に基づく単位時間当たりのパッチ適用の制限台数が取得される。複数の端末それぞれの過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションの実行予定および他のパッチ適用の予定の少なくとも1つ以上の指標に基づいて算出された負荷指標値であって、適用期間に属する複数の時間帯それぞれにおける複数の端末それぞれの負荷指標値が取得される。制限台数と負荷指標値とに基づいて、複数の端末それぞれに対するパッチ適用のタイミングが制御される。
これにより、パッチ適用を効率良く行うことができる。
ここで、端末に対するパッチ適用には比較的大きな負荷を伴う。例えば、パッチ適用が一部の時間帯に集中すると、各端末がパッチをダウンロードするために生じるネットワーク負荷や仮想マシンとして端末を動作させる物理マシンの共有ハードウェアリソースの負荷などの環境負荷が増大する可能性が高まる。このため、パッチ適用に時間がかかったり、パッチ適用が予定時間内に終わらなかったりして、パッチ適用の効率が悪化する可能性がある。環境負荷の増大は、該当の端末だけでなく、パッチ適用を行っていない他の端末による処理遅延などにも影響し得る。
ここで、端末に対するパッチ適用には比較的大きな負荷を伴う。例えば、パッチ適用が一部の時間帯に集中すると、各端末がパッチをダウンロードするために生じるネットワーク負荷や仮想マシンとして端末を動作させる物理マシンの共有ハードウェアリソースの負荷などの環境負荷が増大する可能性が高まる。このため、パッチ適用に時間がかかったり、パッチ適用が予定時間内に終わらなかったりして、パッチ適用の効率が悪化する可能性がある。環境負荷の増大は、該当の端末だけでなく、パッチ適用を行っていない他の端末による処理遅延などにも影響し得る。
そこで、単位時間当たりにパッチ適用を行う端末の台数を制限台数により制限することで、システムにおいて同時にパッチ適用が行われる端末の数を制限台数以内に抑えられる。また、パッチ適用タイミングの制御に各端末に対して予測される負荷を考慮することで、該当の端末においてパッチ適用が失敗する可能性を減らせ、パッチ適用の予定が繰り越される可能性を低減できる。更に、仮に、パッチ適用の予定が繰り越されるとしても、最大適用回数aを用いて制限台数を決定することで、繰り越し先の時間帯においてパッチ適用を行う端末が制限台数を超えて集中することを抑えられる。
このように、パッチ適用を行う端末が一部の時間帯に集中することを抑えられるため、各端末がパッチをダウンロードするために生じるネットワーク負荷や仮想マシンとして端末を動作させる物理マシンの負荷などの環境負荷が増大することを抑えられる。こうして、予定された期間内においてパッチ適用を効率良く行うことができる。また、ある時間帯にパッチ適用を行う端末だけでなく、同じ時間帯にパッチ適用を行っていない他の端末に対する影響を低減できる。
[第2の実施の形態]
次に、第2の実施の形態を説明する。
図2は、第2の実施の形態の情報処理システムの例を示す図である。
次に、第2の実施の形態を説明する。
図2は、第2の実施の形態の情報処理システムの例を示す図である。
第2の実施の形態の情報処理システムは、情報処理装置100および端末200,300,400,…を含む。情報処理装置100および端末200,300,400,…は、ネットワーク50に接続されている。ネットワーク50は、例えばLAN(Local Area Network)である。ネットワーク50は、インターネットやWAN(Wide Area Network)でもよい。
情報処理装置100は、端末200,300,400,…それぞれに対するOSのパッチ適用のタイミングを制御する。情報処理装置100は、例えばサーバコンピュータでもよい。
端末200,300,400,…は、ユーザが使用するクライアントコンピュータである。端末200,300,400,…は、物理的なコンピュータ、すなわち、物理マシンによって実現されてもよいし、物理マシン上で動作する仮想的なコンピュータ、すなわち、仮想マシンによって実現されてもよい。端末200,300,400,…が複数の仮想マシンによって実現される場合、物理マシンが備えるCPU、RAM、HDDおよびNIC(Network Interface Card)などのハードウェアリソースが、各仮想マシンに割り当てられる。
図3は、情報処理装置のハードウェア例を示す図である。
情報処理装置100は、CPU101、RAM102、HDD103、GPU(Graphics Processing Unit)104、入力インタフェース105、媒体リーダ106およびNIC107を有する。なお、CPU101は、第1の実施の形態の処理部12の一例である。RAM102またはHDD103は、第1の実施の形態の記憶部11の一例である。
情報処理装置100は、CPU101、RAM102、HDD103、GPU(Graphics Processing Unit)104、入力インタフェース105、媒体リーダ106およびNIC107を有する。なお、CPU101は、第1の実施の形態の処理部12の一例である。RAM102またはHDD103は、第1の実施の形態の記憶部11の一例である。
CPU101は、プログラムの命令を実行するプロセッサである。CPU101は、HDD103に記憶されたプログラムやデータの少なくとも一部をRAM102にロードし、プログラムを実行する。なお、CPU101は複数のプロセッサコアを含んでもよい。また、情報処理装置100は複数のプロセッサを有してもよい。以下で説明する処理は複数のプロセッサまたはプロセッサコアを用いて並列に実行されてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。
RAM102は、CPU101が実行するプログラムやCPU101が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、情報処理装置100は、RAM以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。
HDD103は、OSやミドルウェアやアプリケーションなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、情報処理装置100は、フラッシュメモリやSSD(Solid State Drive)などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。
GPU104は、CPU101からの命令に従って、情報処理装置100に接続されたディスプレイ51に画像を出力する。ディスプレイ51としては、CRT(Cathode Ray Tube)ディスプレイ、液晶ディスプレイ(LCD:Liquid Crystal Display)、プラズマディスプレイ、有機EL(OEL:Organic Electro-Luminescence)ディスプレイなど、任意の種類のディスプレイを用いることができる。
入力インタフェース105は、情報処理装置100に接続された入力デバイス52から入力信号を取得し、CPU101に出力する。入力デバイス52としては、マウス・タッチパネル・タッチパッド・トラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、情報処理装置100に、複数の種類の入力デバイスが接続されていてもよい。
媒体リーダ106は、記録媒体53に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体53として、例えば、磁気ディスク、光ディスク、光磁気ディスク(MO:Magneto-Optical disk)、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク(FD:Flexible Disk)やHDDが含まれる。光ディスクには、CD(Compact Disc)やDVD(Digital Versatile Disc)が含まれる。
媒体リーダ106は、例えば、記録媒体53から読み取ったプログラムやデータを、RAM102やHDD103などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、CPU101によって実行される。なお、記録媒体53は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体53やHDD103を、コンピュータ読み取り可能な記録媒体と言うことがある。
NIC107は、ネットワーク50に接続され、ネットワーク50を介して他のコンピュータと通信を行うインタフェースである。NIC107は、例えば、スイッチやルータなどの通信装置とケーブルで接続される。NIC107は、無線通信インタフェースでもよい。
端末200,300,400,…も、情報処理装置100と同様のハードウェアにより実現できる。また、端末200,300,400,…が複数の仮想マシンで実現される場合、当該複数の仮想マシンを動作させる物理マシンも、情報処理装置100と同様のハードウェアにより実現できる。端末200,300,400,…が使用するHDDまたはSSDなどが第1の実施の形態の補助記憶装置の一例である。
図4は、情報処理装置の機能例を示す図である。
情報処理装置100は、記憶部110および制御部120を有する。記憶部110には、RAM102やHDD103の記憶領域が用いられる。制御部120は、RAM102に記憶されたプログラムがCPU101によって実行されることで実現される。
情報処理装置100は、記憶部110および制御部120を有する。記憶部110には、RAM102やHDD103の記憶領域が用いられる。制御部120は、RAM102に記憶されたプログラムがCPU101によって実行されることで実現される。
記憶部110は、制御部120の処理に用いられる情報を記憶する。例えば、記憶部110は、端末起動履歴情報111、リソース使用履歴情報112、アプリ実行予定情報113、アプリ重み情報114、ユーザ所属部署情報115およびパッチ適用予定情報116を記憶する。
端末起動履歴情報111は、各端末の起動履歴を示す情報である。例えば、端末起動履歴情報111には、各端末が起動していた日時が記録されている。
リソース使用履歴情報112は、各端末のハードウェアリソースの使用履歴を示す情報である。リソース使用履歴は、メモリ使用履歴およびディスク使用履歴などの記憶リソースの使用履歴を含む。メモリ使用履歴は、各端末に関する、過去の各日時におけるメモリ空き容量、メモリ使用量およびメモリ使用率などを示す情報である。ディスク使用履歴は、各端末に対する、過去の各日時における補助記憶装置のアクティブ率を示す情報である。ディスクは、例えば、HDDやSSDなどの補助記憶装置を示していると考えてよい。
リソース使用履歴情報112は、各端末のハードウェアリソースの使用履歴を示す情報である。リソース使用履歴は、メモリ使用履歴およびディスク使用履歴などの記憶リソースの使用履歴を含む。メモリ使用履歴は、各端末に関する、過去の各日時におけるメモリ空き容量、メモリ使用量およびメモリ使用率などを示す情報である。ディスク使用履歴は、各端末に対する、過去の各日時における補助記憶装置のアクティブ率を示す情報である。ディスクは、例えば、HDDやSSDなどの補助記憶装置を示していると考えてよい。
なお、リソース使用履歴情報112は、過去の各日時における各端末のCPU使用率などの情報を含んでもよい。また、リソース使用履歴情報112は、1日における所定長さの時間帯(例えば、9時00分から9時30分までの30分間など)のリソース使用量(あるいはリソース空き容量)の平均が記録されてもよい。
アプリ実行予定情報113は、各端末におけるアプリケーションの実行予定を示す情報である。アプリ実行予定情報113には、例えば、Web会議ソフト、ウイルススキャンを行うウイルス対策ソフト、表計算ソフトおよび文書作成ソフトなど種々のアプリケーションの将来の実行予定の情報が含まれる。
例えば、Web会議ソフトの実行予定は、Web会議ソフトに登録された、ユーザのWeb会議への参加予定の情報から特定される。ウイルス対策ソフトによるウイルススキャンの実行予定は、ウイルス対策ソフトに登録された当該実行予定の情報から特定される。また、表計算ソフトなどのその他のソフトウェアの実行予定は、ユーザによる過去のソフトウェアの実行履歴から分析される各ソフトウェアが実行される時間帯の傾向に基づいて予測される。制御部120が、ソフトウェアの実行予定の予測を行ってもよい。
アプリ重み情報114は、アプリ実行予定情報113に含まれる各アプリケーションの実行時における負荷に対する重みを示す情報である。アプリケーションごとの重みは、制御部120により端末ごとに、あるいは、当該端末を使用するユーザごとに、該当のアプリケーションの過去の実行時における端末負荷の傾向に応じて最適化される。
ユーザ所属部署情報115は、各端末を使用するユーザが所属する、組織内の部署を示す情報である。
パッチ適用予定情報116は、各端末に対するOSのパッチ適用予定を示す情報である。パッチ適用予定情報116は、制御部120により作成される。
パッチ適用予定情報116は、各端末に対するOSのパッチ適用予定を示す情報である。パッチ適用予定情報116は、制御部120により作成される。
制御部120は、端末起動履歴情報111、リソース使用履歴情報112、アプリ実行予定情報113およびユーザ所属部署情報115を取得し、記憶部110に格納する。端末起動履歴情報111、リソース使用履歴情報112、アプリ実行予定情報113およびユーザ所属部署情報115は、ユーザにより情報処理装置100に入力されてもよいし、制御部120により各端末から収集されてもよい。
制御部120は、各端末に対するOSのパッチ適用のタイミングを制御する。制御部120は、新たに適用すべきパッチの配信が開始されたことを検出すると、まず、適用対象の端末の数、パッチの適用期間および1つの端末当たりの最大適用回数に基づいて、単位時間当たりのパッチ適用の制限台数を計算する。単位時間の長さは、例えば1日である。
ここで、適用期間とは、複数の端末の全体に対するパッチ適用を行うための将来の起点の日時から全端末へのパッチ適用を完了させるべき終点の日時までの時間である。最大適用回数とは、端末に対するパッチ適用が失敗することを考慮して、失敗分を含めて当該端末に許容される適用期間内での最大のパッチ適用回数である。
例えば、パッチ適用の対象となる端末の数をN台、適用期間をM日間、単位時間を1日、最大適用回数をa回、適用期間の終点からの余裕日をb日とするとき、制限台数Lは、L=(N/(M-b))*aと表される。小数以下は切り上げられる。なお、N,Mはそれぞれ2以上の整数であり、aは1以上の整数である。最大適用回数がa回の場合、最初の1回目のパッチ適用に加えて、(a-1)回のパッチ適用のやり直しが許容されることになる。また、余裕日bは、適用期間の終点からどの程度早めに全端末へのパッチ適用を完了させるかという余裕時間の長さを表すパラメータである。余裕日bは0日以上とすることができる。例えば、制御部120は、N,M,a,bの、ユーザによる入力を受け付けて、制限台数Lを算出する。
また、制御部120は、アプリ実行予定情報113に含まれる各アプリケーションに対するアプリ重み情報114を生成し、記憶部110に格納する。例えば、制御部120は、ある端末において過去にアプリケーションが実行されたときの当該端末の負荷をアプリケーションごとに記憶部110に記録し、実行時の負荷が大きくなるアプリケーションほど、重みを大きくする。制御部120は、アプリ実行予定情報113およびアプリ重み情報114を、該当の端末における将来の負荷を示す負荷指標値の計算に用いる。負荷指標値は、パッチの適用期間に属する時間帯において、適用対象の端末に対して予測される負荷を示す指標である。負荷指標値が大きいほど、該当の端末に対して予測される負荷が大きいことを示す。
また、制御部120は、端末ごとの負荷指標値の計算に、端末起動履歴情報111、リソース使用履歴情報112、ユーザ所属部署情報115およびパッチ適用予定情報116も用いる。すなわち、制御部120は、記憶部110に記憶された情報から各端末の将来の負荷を総合的に判断して、単位時間当たりの適用台数が制限台数を超えないように、各端末に対するパッチ適用のタイミングを制御する。
図5は、アプリ重み情報の例を示す図である。
アプリ重み情報114は、記憶部110に格納される。アプリ重み情報114は、ユーザID、アプリ名および負荷に対する重みの項目を含む。ユーザIDの項目には、ユーザIDが登録される。アプリ名の項目には、アプリケーションの名称(アプリ名)が登録される。負荷に対する重みの項目には、該当のユーザが使用する端末の負荷に対する当該アプリケーションの影響の大きさを表す重みの値が登録される。重みは、値が大きいほど、負荷に対する影響が大きい、すなわち、該当のアプリケーションによる処理実行時の負荷が大きいことを示す。
アプリ重み情報114は、記憶部110に格納される。アプリ重み情報114は、ユーザID、アプリ名および負荷に対する重みの項目を含む。ユーザIDの項目には、ユーザIDが登録される。アプリ名の項目には、アプリケーションの名称(アプリ名)が登録される。負荷に対する重みの項目には、該当のユーザが使用する端末の負荷に対する当該アプリケーションの影響の大きさを表す重みの値が登録される。重みは、値が大きいほど、負荷に対する影響が大きい、すなわち、該当のアプリケーションによる処理実行時の負荷が大きいことを示す。
例えば、アプリ重み情報114には、ユーザID「U1」、アプリ名「表計算ソフト」、負荷に対する重み「w1」というレコードが登録されている。このレコードは、ユーザID「U1」のユーザが使用する端末において「表計算ソフト」を実行するときの当該端末に対する負荷の重みが「w1」であることを示す。
アプリ重み情報114には、ユーザID「U1」のユーザに対して、他のアプリ名に対しても同様に、負荷に対する重みが登録される。また、アプリ重み情報114には、他のユーザIDおよびアプリ名の組に対しても同様に、負荷に対する重みが登録される。
制御部120は、例えば、分析対象のアプリケーションおよびユーザの組ごとに、該当のアプリケーションの実行時における端末の過去の負荷を記録し、記録された直近の所定数分の負荷を平均して正規化した値を、当該組に対応する重みとする。例えば、重みの計算に用いる負荷としては、該当のユーザが使用する端末のCPU使用率やメモリ使用量などが考えられる。なお、ユーザと端末との対応関係を示す情報は、記憶部110に予め格納される。制御部120は、記憶部110に記憶された当該対応関係を示す情報に基づいて、ユーザが使用する端末を特定することができる。こうして、ユーザごとに、アプリケーションに対する重みが最適化される。
なお、新規ユーザが使用する端末に対しては、アプリケーションの実行実績の情報がないため、重みを計算することができない。このため、制御部120は、新規ユーザが使用する端末に対しては、該当の新規ユーザと同じ部署に所属する他ユーザに対する該当のアプリケーションの重みの平均値を、新規ユーザに対する該当のアプリケーションの重みとして用いる。
そして、制御部120は、端末起動履歴情報111、リソース使用履歴情報112、アプリ実行予定情報113、アプリ重み情報114およびパッチ適用予定情報116に基づいて、各端末の負荷予測を行う。
図6は、端末の負荷予測結果の例を示す図である。
グラフ60は、ある端末に対する負荷予測結果の例を示す。グラフ60の横軸は時間であり、縦軸は負荷指標値である。例えば、グラフ60では、負荷指標値は、パッチの適用期間における所定長さの時間帯(例えば、30分)に対して1つプロットされる。
グラフ60は、ある端末に対する負荷予測結果の例を示す。グラフ60の横軸は時間であり、縦軸は負荷指標値である。例えば、グラフ60では、負荷指標値は、パッチの適用期間における所定長さの時間帯(例えば、30分)に対して1つプロットされる。
制御部120は、リソース使用履歴情報112に基づいて、端末ごとに、ユーザの端末利用に応じた負荷の変動の周期を検出し、過去のリソース使用量に応じた適用期間内の各時間帯におけるリソース使用量を予測する。例えば、制御部120は、該当の端末に対する負荷の変動の周期を、日、週および月などの単位で区分することが考えられる。
例えば、周期が日の場合、制御部120は、適用期間内のある時間帯のリソース使用量を、直近の所定数(例えば、4つや5つなど)の日における同じ時間帯のリソース使用量の平均として予測する。
また、周期が週の場合、制御部120は、適用期間内のある曜日のある時間帯のリソース使用量を、直近の所定数の同曜日の日の同時間帯のリソース使用量の平均として予測する。
更に、周期が月の場合、制御部120は、適用期間内の第n週(nは1以上の整数)のある曜日のある時間帯のリソース使用量を、直近の所定数の第n週の同曜日の日の同時間帯のリソース使用量の平均として予測する。
上記の例では、メモリ使用量、ディスクアクティブ率およびCPU使用率などのリソース使用量について説明したが、メモリ空き容量などのリソース空き容量に関しても、同様にして予測できる。
また、制御部120は、アプリ実行予定情報113およびアプリ重み情報114に基づいて、適用期間内における各時間帯の所定のアプリケーションの実行による負荷を予測する。所定のアプリケーションの実行には、前述のように、Web会議ソフトによるWeb会議の実行、ウイルス対策ソフトによるウイルススキャン、表計算ソフトの実行および文書作成ソフトの実行などがある。例えば、制御部120は、該当の時間帯で実行される予定のアプリケーションの重みの合計を、当該時間帯の負荷として予測する。
なお、新規ユーザに対してはアプリ重み情報114が存在しない。このため、制御部120は、新規ユーザに対しては、ユーザ所属部署情報115に基づいて、新規ユーザが属する部署のユーザに対する重みの平均値をアプリ名ごとに計算し、当該平均値を当該アプリ名に対する重みの初期値として用いる。そして、制御部120は、該当の新規ユーザに対するアプリ実行による端末負荷の実績がある程度記録されてから、該当の新規ユーザに対するアプリ名ごとの重みを、アプリ重み情報114に登録する。
このとき、制御部120は、リソース使用履歴情報112を基に検出した、該当の端末の負荷の変動の周期に応じて、実行される時間帯ごとに、アプリケーションの負荷に対する重みを求めてもよい。例えば、制御部120は、アプリ重み情報114において、周期に応じた曜日や時間帯の情報を追加し、1つのアプリケーションに対して曜日や時間帯ごとに重みを決定することが考えられる。
このように、制御部120は、リソース使用履歴情報112で予測される負荷とアプリ実行予定情報113およびアプリ重み情報114から予測される負荷とを、時間帯ごとに正規化して合計することで、該当の端末の当該時間帯における負荷指標値を求める。例えば、制御部120は、該当の時間帯についてリソース使用履歴情報112から予測される負荷を示す値(例えば、メモリ空き容量やディスクアクティブ率)が閾値より低いか否かをスコアで表してもよい。例えば、スコアが大きいほど、負荷が大きいと判断されるように、スコアが決定される。より具体的には、制御部120は、メモリ空き容量が1GBよりも大きければ3点、1GB以下であれば0点としたり、ディスクアクティブ率が20%よりも大きければ2点、ディスクアクティブ率が20%以下であれば0点としたりする方法が考えられる。また、制御部120は、CPU使用率が50%よりも大きければ5P、50%以下であれば0Pというように、他の指標についてもスコア化して負荷指標値の計算に用いてもよい。また、制御部120は、指標の種類に応じて、スコアの重みを変化させてもよい。
制御部120は、アプリ実行予定情報113およびアプリ重み情報114から予測される負荷についても同様にスコア化することができる。そして、制御部120は、該当の端末の該当の時間帯におけるスコアを合計して、負荷指標値を計算する。例えば、負荷指標値は、最小値=0、最大値=所定値(例えば、40、50、100など)の範囲に収まるように正規化される。
更に、制御部120は、端末起動履歴情報111およびパッチ適用予定情報116も、負荷の予測に考慮する。例えば、制御部120は、端末起動履歴情報111を基に、パッチの適用期間のうち、端末ごとに稼働している可能性が高い稼働時間帯を取得し、当該稼働時間帯以外の時間帯の負荷指標値を最小値または最小値近傍の所定値に設定する。これにより、負荷指標値が当該最小値または当該所定値以下である時間帯を、該当の端末が稼働していない時間帯として識別可能になる。
また、制御部120は、パッチ適用予定情報116により、他のパッチ適用が既に予定されている時間帯の負荷指標値を例えば最大値に設定することで、新たなパッチ適用の割り当てが行われないようにする。
図7は、パッチ適用日時の割り当て例を示す図である。
制御部120は、図6で例示した負荷予測を端末ごとに行い、端末ごとの負荷予測結果を基に、パッチの適用期間内に該当の端末で低負荷となる時間が、パッチ適用予定時間以上となる箇所を探索する。このとき、制御部120は、適用期間の早い時間から優先的に探索を開始する。パッチによりセキュリティホールに対する対策が行われる場合もあり、パッチ適用は、できるだけ早く行うことが好ましいためである。
制御部120は、図6で例示した負荷予測を端末ごとに行い、端末ごとの負荷予測結果を基に、パッチの適用期間内に該当の端末で低負荷となる時間が、パッチ適用予定時間以上となる箇所を探索する。このとき、制御部120は、適用期間の早い時間から優先的に探索を開始する。パッチによりセキュリティホールに対する対策が行われる場合もあり、パッチ適用は、できるだけ早く行うことが好ましいためである。
負荷予測結果70は、適用期間に含まれる8月9日(木)から8月15日(水)までの、ある端末に対する負荷指標値に基づく負荷の予測結果を示す。負荷予測結果70には、30分刻みの時間帯に対して、「高負荷」、「空」、「稼働なし」という文字列が記載されている。「高負荷」は、負荷指標値が閾値よりも大きい時間帯である。「空」は、負荷指標値が閾値よりも小さい時間帯である。「稼働なし」は、該当の端末が起動していないと予測される時間帯である。なお、負荷指標値の判定に用いる閾値は、例えば、負荷指標値の最大値の2分の1などとすることが考えられる。
制御部120は、早い時間から優先的に、「空」がパッチ適用予定時間だけ連続する箇所を探索する。パッチ適用予定時間は、パッチ適用のために所要される時間の予測値であり、例えば、パッチのサイズと、サイズに応じた過去のパッチ適用時間の実績とに基づき、制御部120により予め計算される。例えば、パッチ適用予定時間は2時間であるとする。
負荷予測結果70の例では、制御部120は、8月9日の早い時間帯から順に探索し、8月10日の10時00分から12時00分までの2時間分を、パッチ適用に割り当てる。この場合、制御部120は、該当の端末に対するパッチ適用の開始日時を8月10日の10時00分とすることを示す情報を、パッチ適用予定情報116に登録する。例えば、制御部120は、端末のIDなどに応じた順番で、各端末についてパッチ適用の開始日時を決定し、パッチ適用予定情報116に登録する。
なお、制御部120は、Web会議ソフトによるWeb会議の実行予定の日時や、ウイルス対策ソフトによるウイルススキャンの実行予定の日時を、パッチ適用の割り当て候補から除外するように制御してもよい。
また、制御部120は、パッチ適用のスケジューリングの他に、制限台数と各端末の負荷指標値とに基づき、各端末でのウイルス対策ソフトによるウイルススキャンの実行のタイミングを制御してもよい。その場合、制御部120は、次回のウイルススキャンの実行が可能な期間である実行可能期間の遅い時間帯から優先的に、ウイルススキャンの実行予定の時間帯として割り当てることが考えられる。前回のウイルススキャンからある程度離れた時間帯で行う方がウイルススキャンの効率性を高められるためである。なお、ウイルススキャンの実行可能期間は、ユーザによって情報処理装置100に予め設定される。
例えば、実行可能期間が8月9日から8月15日の場合、制御部120は、ある端末に対し、8月15日の遅い時間帯から遡ってウイルススキャンの実行予定時間の分だけ「空」となる箇所を探索し、当該箇所の起点の日時をウイルススキャンの開始日時に設定する。制御部120は、各端末に対して割り当てた時間帯にウイルススキャンを実行するように指示する。
図8は、パッチ適用スケジュールの例を示す図である。
スケジュール結果80は、制御部120による20台の端末A~Tのパッチ適用のスケジュールを示す。端末A~Tは端末200,300,400,…の一例である。適用期間は8月9日0時00分から8月18日23時59分までである。また、N=20、M=10、a=1、b=3であり、制限台数L=(20/(10-3))*1=2.87…≒3である。
スケジュール結果80は、制御部120による20台の端末A~Tのパッチ適用のスケジュールを示す。端末A~Tは端末200,300,400,…の一例である。適用期間は8月9日0時00分から8月18日23時59分までである。また、N=20、M=10、a=1、b=3であり、制限台数L=(20/(10-3))*1=2.87…≒3である。
スケジュール結果80で示されるように、制御部120は、端末A~Tそれぞれに対するパッチ適用の時間帯を、適用期間に属する各日に最大で3台ずつ割り当てることができる。また、制御部120は、早い時間帯を優先的に割り当てることで、適用期間の終端からb=3日分(8月16日から8月18日の3日分)の余裕を確保して、端末A~Tの全てにパッチ適用を行うようにスケジュールできる。余裕分があることで、制御部120は、仮にパッチ適用に失敗する端末が生じたとしても、余裕分として確保された日時において、失敗した端末のパッチ適用予定を繰り越すことができる。
例えば、制御部120は、8月12日の端末Jのパッチ適用が失敗した場合、端末Jに対するパッチ適用予定を8月16日に繰り越してもよい。また、制御部120は、8月14日の端末F,Pのパッチ適用が失敗した場合、端末Fに対するパッチ適用予定を8月15日に、端末Pに対するパッチ適用予定を8月16日にそれぞれ繰り越してもよい。更に、制御部120は、8月15日の端末Tのパッチ適用が失敗した場合、端末Tに対するパッチ適用予定を8月16日に繰り越してもよい。制御部120は、繰り越しの際にも、繰り越し先候補の時間帯における各端末の負荷指標値や単位時間(例えば1日)当たりの制限台数Lに基づいて繰り越し先の時間帯を決定する。
更に、スケジュール結果80の例ではa=1の場合を示したが、制御部120は、a>1として、パッチ適用失敗時の繰り越し先の時間帯を含めて予めスケジュールしてもよい。制御部120は、スケジュール結果80を示すパッチ適用予定情報116を生成し、記憶部110に格納する。制御部120は、パッチ適用予定情報116に基づいて、各端末にパッチ適用を行うように指示する。
次に、情報処理装置100の処理手順を説明する。
図9は、情報処理装置の処理例を示すフローチャートである。
下記の手順は、制御部120が各端末に適用すべき新たなパッチの配信が開始されたことを検出すると実行される。
図9は、情報処理装置の処理例を示すフローチャートである。
下記の手順は、制御部120が各端末に適用すべき新たなパッチの配信が開始されたことを検出すると実行される。
(S10)制御部120は、パッチの適用期間における単位時間当たりの制限台数Lを算出する。適用期間は、制御部120に予め与えられる。例えば、新たなパッチの配信が開始されたことを検出した日の翌日0時、あるいは、次週の開始日の0時などを起点に、所定日数で定められる時間範囲が適用期間となる。
(S11)制御部120は、パッチの適用期間の各時間帯における各端末の負荷指標値を算出する。制御部120は、図6で説明したように、端末起動履歴情報111、リソース使用履歴情報112、アプリ実行予定情報113、アプリ重み情報114およびパッチ適用予定情報116に基づいて、当該負荷指標値を算出する。
(S12)制御部120は、パッチ適用対象の端末を1つ選択する。端末の選択順は任意に決定できる。例えば、制御部120は、端末ID順、ユーザID順またはランダムに、端末を選択してよい。
(S13)制御部120は、端末の負荷指標値が低い時間がパッチ適用予定時間だけ継続する日時を、早い順から特定する。例えば、制御部120は、前述のように、端末の負荷指標値が閾値よりも小さい時間帯が連続する箇所の起点の日時を、端末の負荷指標値が低い時間がパッチ適用予定時間だけ継続する日時として特定する。なお、同じ端末についてステップS13を次に実行するときは、制御部120は、特定済の日時の次の日時から探索を始める。
(S14)制御部120は、特定した日時にパッチ適用予定を割り当てた場合に、パッチ適用予定済の端末の数が、単位時間(例えば1日)当たりの制限台数Lに収まるか否かを判定する。制限台数Lに収まる場合(パッチ適用予定済の端末の数が制限台数L以下の場合)、ステップS15に処理が進む。制限台数Lに収まらない場合(パッチ適用予定済の端末の数が制限台数Lより大きい場合)、ステップS13に処理が進む。
(S15)制御部120は、特定した日時を該当の端末へのパッチ適用のタイミングとして割り当てる。制御部120は、割り当て結果を、パッチ適用予定情報116に記録する。
(S16)制御部120は、パッチ適用対象の全端末のパッチ適用のスケジュールを決定済であるか否かを判定する。全端末についてスケジュールを決定済の場合、処理が終了する。スケジュールを未決定の端末がある場合、ステップS12に処理が進む。
その後、制御部120は、図9の手順により作成したパッチ適用予定情報116に従った日時にパッチ適用を行うように各端末に指示し、各端末によるパッチ適用を実行させる。
なお、上記の手順によってパッチ適用の時間帯を割り当てることができない端末が発生する場合も考えられる。この場合、制御部120は、例外的に、端末の負荷指標値に依らずに、適用期間内の制限台数に達していない時間範囲を該当の端末に割り当ててもよいし、制限台数を超えて、適用期間内の何れかの時間範囲を該当の端末に割り当ててもよい。
図10は、パッチ適用スケジュールの比較例を示す図である。
スケジュール90は、端末A~Tに対して、8月9日~8月18日の各日に2台ずつパッチ適用予定を割り当てる例を示す。このように、各端末のパッチ適用予定を、適用期間内に単純に均等に割り当てることも考えられる。しかし、パッチ適用は失敗することがある。例えば、8月14に端末F,Pでパッチ適用が失敗し、端末F,Pのパッチ適用予定を翌日に繰り越すと、翌日には端末G,Q,F,Pの4台の端末へのパッチ適用が行われることになり、パッチ適用による負荷が2倍になる。パッチ適用による負荷が高まると、各端末によるパッチのダウンロードなどによるネットワーク負荷や、端末が仮想マシンで実現される場合に当該仮想マシンを動作させる物理マシンの負荷が増大する可能性が高くなる。例えば、端末が仮想マシンで実現される場合、1台の物理マシン上で複数の端末が当該物理マシンのRAMやHDDまたはSSDなどを共有するため、複数の端末でパッチ適用が同時に行われると物理マシンの負荷が過大になる可能性がある。
スケジュール90は、端末A~Tに対して、8月9日~8月18日の各日に2台ずつパッチ適用予定を割り当てる例を示す。このように、各端末のパッチ適用予定を、適用期間内に単純に均等に割り当てることも考えられる。しかし、パッチ適用は失敗することがある。例えば、8月14に端末F,Pでパッチ適用が失敗し、端末F,Pのパッチ適用予定を翌日に繰り越すと、翌日には端末G,Q,F,Pの4台の端末へのパッチ適用が行われることになり、パッチ適用による負荷が2倍になる。パッチ適用による負荷が高まると、各端末によるパッチのダウンロードなどによるネットワーク負荷や、端末が仮想マシンで実現される場合に当該仮想マシンを動作させる物理マシンの負荷が増大する可能性が高くなる。例えば、端末が仮想マシンで実現される場合、1台の物理マシン上で複数の端末が当該物理マシンのRAMやHDDまたはSSDなどを共有するため、複数の端末でパッチ適用が同時に行われると物理マシンの負荷が過大になる可能性がある。
また、8月18日に端末J,Tのパッチ適用が失敗すると、端末J,Tのパッチ適用予定が翌日以降に繰り越されることになり、適用期間内に、全端末のパッチ適用が未完了となる。適用期間内にパッチ適用を完了できない場合、パッチ適用が遅れることで端末にセキュリティ上のリスクが生じてしまい、好ましくない。
そこで、情報処理装置100は、単位時間当たりにパッチ適用を行う端末の台数を制限台数により制限することで、システムにおいて同時にパッチ適用が行われる端末の数を制限台数以内に抑えられる。また、各端末に対して予測される負荷を考慮することで、該当の端末においてパッチ適用が失敗する可能性を減らせ、パッチ適用の予定が繰り越される可能性を低減できる。更に、仮に、パッチ適用の予定が繰り越されるとしても、最大適用回数aや余裕日bを用いて制限台数Lを決定することで、図8で例示したように、繰り越し先の時間帯においてパッチ適用を行う端末が制限台数を超えて集中することを抑えられる。
このように、パッチ適用を行う端末が一部の時間帯に集中することを抑えられるため、各端末がパッチをダウンロードするために生じるネットワーク負荷や仮想マシンとして端末を動作させる物理マシンの負荷などの環境負荷が増大することを抑えられる。また、適用期間内に対象の全端末に対するパッチ適用を完了できる可能性を高められる。こうして、パッチ適用を効率良く行うことができる。また、ある時間帯にパッチ適用を行う端末だけでなく、同じ時間帯にパッチ適用を行っていない他の端末に対する影響を低減できる。
また、情報処理装置100は、端末の負荷の予測において、リソース使用履歴情報112やアプリ実行予定情報113に基づいて端末ごとに最適化された負荷指標値を求めることで、該当の端末の負荷の予測精度を高めることができる。このため、該当の端末で、予定された日時におけるパッチ適用が失敗する可能性を低減でき、パッチ適用予定が繰り越される頻度が低減される。このため、パッチ適用を行う端末が一部の時間帯に集中することを一層抑えられ、各端末がパッチをダウンロードするために生じるネットワーク負荷や仮想マシンとして端末を動作させる物理マシンの負荷などの環境負荷の増大を一層抑えられる。また、適用期間内に対象の全端末に対するパッチ適用を完了できる可能性を一層高められる。こうして、パッチ適用を一層効率良く行うことができる。
なお、端末200,300,400,…は、前述のように物理マシンで実現されてもよいし、仮想マシンで実現されてもよい。例えば、端末200,300,400,…の中に、物理マシンで実現される端末と仮想マシンで実現される端末とが混在することも考えられる。この場合、制御部120は、物理マシンで実現される端末のグループと、仮想マシンで実現される端末のグループとについて、該当のグループに属する端末へのパッチ適用のスケジュールの決定を、グループごとに行ってもよい。
以上で説明した情報処理装置100は、例えば、次の処理を実行する。
制御部120は、複数の端末の数、適用期間および1つの端末当たりの最大適用回数に基づく単位時間当たりのパッチ適用の制限台数を取得する。制御部120は、複数の端末それぞれの過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションの実行予定および他のパッチ適用の予定の少なくとも1つ以上の指標に基づいて算出された負荷指標値であって、適用期間に属する複数の時間帯それぞれにおける複数の端末それぞれの負荷指標値を取得する。制御部120は、制限台数と負荷指標値とに基づいて、複数の端末それぞれに対するパッチ適用のタイミングを制御する。
制御部120は、複数の端末の数、適用期間および1つの端末当たりの最大適用回数に基づく単位時間当たりのパッチ適用の制限台数を取得する。制御部120は、複数の端末それぞれの過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションの実行予定および他のパッチ適用の予定の少なくとも1つ以上の指標に基づいて算出された負荷指標値であって、適用期間に属する複数の時間帯それぞれにおける複数の端末それぞれの負荷指標値を取得する。制御部120は、制限台数と負荷指標値とに基づいて、複数の端末それぞれに対するパッチ適用のタイミングを制御する。
これにより、パッチ適用を効率良く行うことができる。
なお、制御部120は、過去の端末起動率のみに基づく負荷指標値を用いて各端末のパッチ適用をスケジューリングする場合、該当の端末が起動していないと予測される時間帯に該当の端末を起動させてパッチ適用を実行させてもよい。
なお、制御部120は、過去の端末起動率のみに基づく負荷指標値を用いて各端末のパッチ適用をスケジューリングする場合、該当の端末が起動していないと予測される時間帯に該当の端末を起動させてパッチ適用を実行させてもよい。
所定のアプリケーションの実行予定は、Web会議用のアプリケーションによる、端末を利用するユーザのWeb会議への参加予定およびウイルススキャンを行うアプリケーションによるウイルススキャンの実行予定の少なくとも1つを含む。
これにより、Web会議やウイルススキャンが行われている最中にパッチ適用が行われて端末負荷が過大となり、ユーザによる端末の操作性が損なわれることを抑えられる。
また、制御部120は、複数のアプリケーションそれぞれの実行時における端末の過去の負荷に基づいて、複数のアプリケーションそれぞれの負荷に対する重みを、端末を使用するユーザごとに付与する。制御部120は、複数のアプリケーションそれぞれの重みに基づいて、ユーザが使用する端末の負荷指標値を算出する。
また、制御部120は、複数のアプリケーションそれぞれの実行時における端末の過去の負荷に基づいて、複数のアプリケーションそれぞれの負荷に対する重みを、端末を使用するユーザごとに付与する。制御部120は、複数のアプリケーションそれぞれの重みに基づいて、ユーザが使用する端末の負荷指標値を算出する。
これにより、端末の負荷指標値の精度が高まり、パッチ適用のスケジューリングを適切に行える。
また、制御部120は、ユーザが使用する端末の過去の負荷の情報がない場合、ユーザが所属する部署内の複数のユーザそれぞれに対して算出済の重みの平均値を複数のアプリケーションそれぞれに対して算出する。制御部120は、複数のアプリケーションそれぞれに対して算出した重みの平均値に基づいて、ユーザが使用する端末の負荷指標値を算出する。
また、制御部120は、ユーザが使用する端末の過去の負荷の情報がない場合、ユーザが所属する部署内の複数のユーザそれぞれに対して算出済の重みの平均値を複数のアプリケーションそれぞれに対して算出する。制御部120は、複数のアプリケーションそれぞれに対して算出した重みの平均値に基づいて、ユーザが使用する端末の負荷指標値を算出する。
これにより、例えば、新たなユーザのように端末の過去の利用実績がない場合でも当該ユーザに対する各アプリケーションの負荷に対する重みを適切に求めることができる。同じ部署のユーザ同士では、端末利用の傾向が近似している可能性が高いためである。
また、制御部120は、パッチの適用期間に対して確保する余裕時間の長さに基づいて、制限台数を算出してもよい。余裕時間の長さは、制限台数Lの計算式におけるパラメータbに相当する。
これにより、適用期間に余裕をもって全ての端末に対するパッチ適用をスケジューリングでき、仮に、何れかの端末でパッチ適用の失敗が生じても、適用期間内にパッチ適用予定を繰り越せる可能性が高まる。例えば、制御部120は、前述のように、端末の数Nを、適用期間と余裕時間との長さの差(M-b)で割った商(N/(M-b))と、最大適用回数aとの積((N/(M-b))*a)に基づいて制限台数Lを求めることができる。
また、制御部120は、制限台数と負荷指標値とに基づいて、複数の端末それぞれに対するウイルススキャンの実行のタイミングを制御してもよい。制御部120は、パッチ適用のタイミングの制御では、適用期間のうちの早い時間帯を優先的に、端末に対するパッチ適用予定の時間帯として割り当てる。一方、制御部120は、ウイルススキャンの実行のタイミングの制御では、ウイルススキャンの実行可能期間のうちの遅い時間帯を優先的に、端末に対するウイルススキャンの実行予定の時間帯として割り当てる。
これにより、パッチ適用に加えて、ウイルススキャンを効率良く行うことができる。
なお、第1の実施の形態の情報処理は、処理部12にプログラムを実行させることで実現できる。また、第2の実施の形態の情報処理は、CPU101にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体53に記録できる。
なお、第1の実施の形態の情報処理は、処理部12にプログラムを実行させることで実現できる。また、第2の実施の形態の情報処理は、CPU101にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体53に記録できる。
例えば、プログラムを記録した記録媒体53を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体53に記録されたプログラムまたは他のコンピュータから受信したプログラムを、RAM102やHDD103などの記憶装置に格納し(インストールし)、当該記憶装置からプログラムを読み込んで実行してもよい。
5 ネットワーク
10 情報処理装置
11 記憶部
12 処理部
21,22,23,24,25 端末
31,32,33 グラフ
40 パッチ適用スケジュール
10 情報処理装置
11 記憶部
12 処理部
21,22,23,24,25 端末
31,32,33 グラフ
40 パッチ適用スケジュール
Claims (8)
- 複数の端末に対するパッチ適用のタイミングを制御する情報処理プログラムであって、コンピュータに、
前記複数の端末の数、適用期間および1つの端末当たりの最大適用回数に基づく単位時間当たりの前記パッチ適用の制限台数を取得し、
前記複数の端末それぞれの過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションの実行予定および他のパッチ適用の予定の少なくとも1つ以上の指標に基づいて算出された負荷指標値であって、前記適用期間に属する複数の時間帯それぞれにおける前記複数の端末それぞれの前記負荷指標値を取得し、
前記制限台数と前記負荷指標値とに基づいて、前記複数の端末それぞれに対する前記パッチ適用のタイミングを制御する、
処理を実行させる情報処理プログラム。 - 前記所定のアプリケーションの実行予定は、Web会議用のアプリケーションによる、端末を利用するユーザのWeb会議への参加予定およびウイルススキャンを行うアプリケーションによるウイルススキャンの実行予定の少なくとも1つを含む、
請求項1記載の情報処理プログラム。 - 前記負荷指標値の取得では、複数のアプリケーションそれぞれの実行時における端末の過去の負荷に基づいて、前記複数のアプリケーションそれぞれの前記負荷に対する重みを、前記端末を使用するユーザごとに付与し、前記複数のアプリケーションそれぞれの前記重みに基づいて、前記ユーザが使用する前記端末の前記負荷指標値を算出する、
請求項1記載の情報処理プログラム。 - 前記負荷指標値の算出では、前記ユーザが使用する前記端末の過去の前記負荷の情報がない場合、前記ユーザが所属する部署内の複数のユーザそれぞれに対して算出済の前記重みの平均値を前記複数のアプリケーションそれぞれに対して算出し、前記複数のアプリケーションそれぞれに対して算出した前記重みの前記平均値に基づいて、前記ユーザが使用する前記端末の前記負荷指標値を算出する、
請求項3記載の情報処理プログラム。 - 前記制限台数の取得では、前記適用期間に対して確保する余裕時間の長さに基づいて、前記制限台数を算出する、
請求項1記載の情報処理プログラム。 - 前記コンピュータに更に、前記制限台数と前記負荷指標値とに基づいて、前記複数の端末それぞれに対するウイルススキャンの実行のタイミングを制御する処理を実行させ、
前記パッチ適用のタイミングの制御では、前記適用期間のうちの早い時間帯を優先的に、端末に対するパッチ適用予定の時間帯として割り当て、
前記ウイルススキャンの実行のタイミングの制御では、前記ウイルススキャンの実行可能期間のうちの遅い時間帯を優先的に、前記端末に対する前記ウイルススキャンの実行予定の時間帯として割り当てる、
請求項1記載の情報処理プログラム。 - 複数の端末に対するパッチ適用のタイミングを制御する情報処理方法であって、コンピュータが、
前記複数の端末の数、適用期間および1つの端末当たりの最大適用回数に基づく単位時間当たりの前記パッチ適用の制限台数を取得し、
前記複数の端末それぞれの過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションの実行予定および他のパッチ適用の予定の少なくとも1つ以上の指標に基づいて算出された負荷指標値であって、前記適用期間に属する複数の時間帯それぞれにおける前記複数の端末それぞれの前記負荷指標値を取得し、
前記制限台数と前記負荷指標値とに基づいて、前記複数の端末それぞれに対する前記パッチ適用のタイミングを制御する、
情報処理方法。 - 複数の端末に対するパッチ適用のタイミングを制御する情報処理装置であって、
前記複数の端末それぞれの過去の端末起動率、過去のメモリ空き容量、過去の補助記憶装置のアクティブ率、所定のアプリケーションの実行予定および他のパッチ適用の予定の少なくとも1つ以上の指標を示す情報を記憶する記憶部と、
前記複数の端末の数、適用期間および1つの端末当たりの最大適用回数に基づく単位時間当たりの前記パッチ適用の制限台数を取得し、前記少なくとも1つ以上の指標に基づいて算出された負荷指標値であって、前記適用期間に属する複数の時間帯それぞれにおける前記複数の端末それぞれの前記負荷指標値を取得し、前記制限台数と前記負荷指標値とに基づいて、前記複数の端末それぞれに対する前記パッチ適用のタイミングを制御する処理部と、
を有する情報処理装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021012019A JP2022115430A (ja) | 2021-01-28 | 2021-01-28 | 情報処理プログラム、情報処理方法および情報処理装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021012019A JP2022115430A (ja) | 2021-01-28 | 2021-01-28 | 情報処理プログラム、情報処理方法および情報処理装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2022115430A true JP2022115430A (ja) | 2022-08-09 |
Family
ID=82747744
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2021012019A Pending JP2022115430A (ja) | 2021-01-28 | 2021-01-28 | 情報処理プログラム、情報処理方法および情報処理装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2022115430A (ja) |
-
2021
- 2021-01-28 JP JP2021012019A patent/JP2022115430A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11425194B1 (en) | Dynamically modifying a cluster of computing nodes used for distributed execution of a program | |
JP6455035B2 (ja) | 負荷分散管理装置、制御方法およびプログラム | |
JP6044131B2 (ja) | プログラム、管理サーバおよび仮想マシン移動制御方法 | |
US9442760B2 (en) | Job scheduling using expected server performance information | |
CN106502791B (zh) | 一种任务分配方法及装置 | |
US9477460B2 (en) | Non-transitory computer-readable storage medium for selective application of update programs dependent upon a load of a virtual machine and related apparatus and method | |
US8966030B1 (en) | Use of temporarily available computing nodes for dynamic scaling of a cluster | |
US10831387B1 (en) | Snapshot reservations in a distributed storage system | |
JP6233413B2 (ja) | タスク割り当て判定装置、制御方法、及びプログラム | |
US7979864B2 (en) | Apparatus for setting used license of executing job into unused license state and allocating the set unused license to a to be executed job based on priority | |
JP5609730B2 (ja) | 情報処理プログラム及び方法、転送処理装置 | |
WO2012066640A1 (ja) | 計算機システム、マイグレーション方法及び管理サーバ | |
JP2012094030A (ja) | 計算機システム及び処理制御方法 | |
US20150234713A1 (en) | Information processing apparatus and virtual machine migration method | |
US8918776B2 (en) | Self-adapting software system | |
US10565021B2 (en) | Automated capacity management in distributed computing systems | |
US9632840B2 (en) | Load balancing with granularly redistributable workloads | |
JP6969282B2 (ja) | 情報処理装置、情報処理システムおよび情報処理方法 | |
US9766939B1 (en) | Resource overprovisioning in a virtual machine environment | |
JP7197776B2 (ja) | スケジューリングプログラム、スケジューリング方法、およびスケジューリング装置 | |
WO2013171944A1 (ja) | 仮想マシン管理システム、仮想マシン管理方法およびプログラム | |
JP5515889B2 (ja) | 仮想マシンシステム、自動マイグレーション方法および自動マイグレーションプログラム | |
US20150074454A1 (en) | Information processing method and apparatus for migration of virtual disk | |
JP6550945B2 (ja) | 判定制御プログラム、判定制御方法及び仮想マシン管理装置 | |
JP2016130892A (ja) | 監視装置、情報処理システム及び監視プログラム |