以下の詳細な説明は、例にすぎず、実施形態、または実施形態の適用もしくは使用を制限するよう意図されていない。さらに、先行する「背景技術」または「発明の概要」のセクション、あるいは「発明を実施するための形態」のセクションで提示された、いずれかの明示されたか、または暗示された情報によって制約されるという意図はない。
ここで、図面を参照して1つまたは複数の実施形態が説明され、図面全体を通じて、類似する参照番号が、類似する要素を参照するために使用されている。以下の説明では、説明の目的で、1つまたは複数の実施形態を十分に理解できるように、多数の特定の詳細が示されている。しかし、これらの特定の詳細がなくても、さまざまな事例において、1つまたは複数の実施形態が実践され得るということは明らかである。
マルウェア攻撃は、コンピュータ関連システムをダウンさせることができ、ダウンタイムおよび回復のコストにおいて、企業およびその他の実体に多額の(例えば、数千ドル、数万ドル、数十万ドルなどの)負担をかける可能性がある。通常、企業は、多数のシステム(例えば、コンピュータ関連システム)にパッチを適用するための時間およびリソースを持っておらず、一方、その他の企業は、不適切なほど余裕がある時間およびリソースを費やしている。
コンピュータ関連システムの自動化されたパッチ適用は、コンピュータ関連システムの手動のパッチ適用の損失およびコンピュータ関連システムにパッチを適用しないことのリスクに対する、コスト効率の高い代替手段になることができる。コンピュータ関連システムおよびその一部にパッチを適用することおよびパッチを適用しないことのコストをリスクのレベルに対して測定し、リスクに対するコストのそのような測定から、いつパッチを実行するべきか、およびどのパッチを実行するべきかを決定することは、有用かつ望ましいことであり得る。
パッチ適用に関する別の考慮事項は、パッチ適用時間が通常は一定でなく、複数の要因がパッチ適用に影響を与える可能性があるということである。システムの不均一性(例えば、システムのプラットフォーム、構成、およびデプロイされるアプリケーションにおける変化)は、非標準のシステムをテストすることが相対的に困難であることがあるため、少なくとも一部のパッチが失敗する可能性を増大させることがある。
さらに別の考慮事項は、パッチを実行するコストがパッチを適用しないコスト以下になることができる最も早い時点でコンピュータ関連システムまたはその一部にパッチを適用することが、通常はより良いことである可能性があるということである。コンピュータ関連システムの利用が公開された後に、パッチが適用されていないコンピュータ関連システムのリスクが、一般に、著しく(例えば、劇的に)増大することがある。
さらに別の考慮事項は、コンピュータ関連システムに対するパッチが、不具合を含んでいることがあるということである。その結果、パッチが実施された後に、パッチまたはパッチが実施されたコンピュータ関連システムが容認できる状態で機能していることの妥当性を確認できるのが望ましいことがあり、パッチまたはコンピュータ関連システムが容認できる状態で機能していない場合、パッチのロールバックまたは取消しを実行して、コンピュータ関連システムをパッチが実施される前の状態に戻すのが望ましいことがある。
コンピュータ関連システムのハイブリッド・ワークロードに対してパッチを実行する場合、重要な課題がさらに存在することがある。計算の条件および仕様が変化することがあり、ワークロードも変化することがある。ハイブリッド・ワークロードは、例えば、複数のクラウドまたは複数のオペレーティング・システム・アーキテクチャ、クラウド・デプロイメント・モデルの一種(例えば、従来のコンピューティング・インフラストラクチャ、プライベート・クラウドまたはパブリック・クラウド、オンプレミスおよびオフプレミス、専用または共有など)、デプロイメントの一種(例えば、ベアメタル・マシン、仮想マシン(VM:virtual machine)、コンテナ、外部サービスなど)、ワークロードの一種(例えば、バッチ・ワークロード、トランザクション・ワークロード、分析ワークロード、高性能のワークロード、データベース・ワークロードまたは中央処理装置(CPU:central processing unit)、ディスク負荷またはプロセッサ負荷の大きいワークロードなど)、パッチを実行する頻度(例えば、毎月または月末のパッチ適用、パッチ適用の季節変動など)、あるいは開発および運用(DevOps:development and operations)プロセスを含んでいる複数のディメンションから成る(例えば、複数のディメンションにわたる)ことができる。ワークロードの複数の層(例えば、ノード)間には、依存関係が存在することもある。
さらに、ノードのパッチ適用は、例えばクラスタ化されたサービスまたは常時接続のサービスに関しては、オンラインまたはライブで実行することができ、あるいはオフラインで実行することもでき、その場合、ノードおよび関連するアプリケーションがオフラインであるときに、パッチ適用が実行される。通常、オフラインであるときにノードおよび関連するアプリケーションに対してパッチを実行できる使用可能なダウンタイム・ウィンドウが制限されているという、別の課題が存在することがある。考慮するべきさらに別の課題は、例えば、あるパッチが高い重要性を有し、他のパッチが中程度の重要性を有し、さらに他のパッチが比較的低い重要性を有することがあるため、パッチに関連付けられた重要性、優先度、または脆弱性(例えば、脆弱性スコア)における変動が存在することがあるということである。また、現在、適用可能なインフラストラクチャの制約の範囲内でオペレーティング・システム、ミドルウェア、およびアプリケーションに別々にパッチを適用することに対して、通常はユーザ(例えば、顧客)が責任を負う可能性があるということに注意する。
そのような目的で、本明細書におけるさまざまな実施形態は、例えばハイブリッド・コンピューティング環境(例えば、ハイブリッド・クラウド・コンピューティング環境)などの、コンピューティング環境内でパッチを管理するための手法に関連している。パッチ識別コンポーネントは、コンピューティング・プラットフォームに関連付けられたワークロードを識別することができる。このワークロードは、パッチの第1のサブセットをオフラインで実行できる第1のワークロード部分およびパッチの第2のサブセットをオンラインで実行できる第2のワークロード部分を含むことができる。パッチ管理コンポーネント(PMC:patch management component)は、第1のワークロード部分に関して、パッチの第1のサブセットのパッチの脆弱性スコアに基づいて、オフラインであるときに保守時間ウィンドウ内で第1のワークロード部分の一部に対して実行できるパッチの第1のサブセットの一部(例えば、第3のサブセット)を決定することができ、第2のワークロード部分に関して、オンラインであるときに実行できるパッチの第2のサブセットを決定することができる。PMCは、保守時間ウィンドウの間に適用するためのパッチの第1のサブセットの一部(例えば、第3のサブセット)、および第2のワークロード部分に適用するためのパッチの第2のサブセットを決定することを容易にするために、パッチの相対的な重要度に少なくとも部分的に基づいて、パッチの脆弱性スコアまたはパッチのグループ(例えば、パッチの異なるグループ化)のグループ脆弱性スコア(group vulnerability scores)を決定することができる。一部の実施形態では、パッチの第3のサブセットのパッチの少なくとも一部を、互いに同時にまたは並列に適用することができ、あるいはパッチの第2のサブセットのパッチの少なくとも一部を、互いに、またはパッチの第3のサブセットのパッチの少なくとも一部と、同時にまたは並列に適用することができる。
パッチ実行コンポーネントは、第1のワークロード部分がオフラインであるときに、保守時間ウィンドウ内で、第1のワークロード部分の一部に対してパッチの第3のサブセットを実行することができ、第2のワークロード部分に対してパッチの第2のサブセットを実行することができ、そのようなパッチが実行されている(例えば、適用されている)ときに、第2のワークロード部分はオンラインであることができる。PMCは、パッチおよび関連するワークロードが適切に機能していることを保証するために、まだ保守時間ウィンドウ内であるときに、適用されるパッチおよび関連するワークロードの妥当性を確認することができる。PMCが、パッチの妥当性が確認されない(例えば、パッチが適用された後に、そのようなパッチまたは関連するワークロードのアイテムが適切に機能していない)ということを決定した場合、PMCは、保守時間ウィンドウ内でこのパッチを取り消し、ワークロードのアイテムをパッチが適用される前の状態に戻すことができる。
ここで、開示される対象のこれらおよびその他の態様および実施形態が、図面に関して説明される。
図1は、開示される対象のさまざまな態様および実施形態に従って、コンピューティング・システム上でパッチを効率的に管理して適用することに利用され得る、例示的な非限定的システム100のブロック図を示している。システム100は、さまざまなコンポーネントを備えることができるコンピューティング・システム102を含むことができる。コンピューティング・システム102は、1つまたは複数のネットワーク(例えば、コンピューティング・ネットワークまたは通信ネットワーク)を備えることができる。一部の実施形態では、コンピューティング・システム102は、マルチディメンションであることができ、コンピューティング・システム102は、複数のディメンションにわたって広がることができ、コンピューティング・システム102の複数のディメンションにわたって広がることができるワークロード(例えば、ハイブリッド・ワークロード)を含むことができる。例えば、コンピューティング・システム102は、本明細書においてさらに詳細に説明されるように、複数のクラウドまたは複数のオペレーティング・システム・アーキテクチャを備えることができ、マルチディメンションのデプロイメント・モデル(例えば、従来のコンピューティング・インフラストラクチャ、プライベート・クラウドまたはパブリック・クラウド、オンプレミスおよびオフプレミス、専用または共有)を採用することができ、マルチディメンションのデプロイメント・モデルの複数の層または複数の部分にわたって広がることができるさまざまな種類のコンポーネントまたはデバイス(例えば、ベアメタル・マシン、VM、コンテナ、外部サービスなど)を採用することができ、コンピューティング・システム102の複数のディメンションにわたって広がることができるさまざまな種類のワークロード(例えば、バッチ・ワークロード、トランザクション・ワークロード、分析ワークロード、高性能のワークロード、データベース・ワークロードまたはCPU、ディスク負荷またはプロセッサ負荷の大きいワークロードなど)を伴うことができ、コンピューティング・システム102の複数のディメンションにわたって広がることができるDevOpsプロセスまたはその他の特徴を備えることができる。
コンピューティング・システム102は、さまざまなコンテナ104、仮想マシン(VM)106、物理マシン(PM:physical machines)108、その他のリソース110、およびノード112を備えることができ、これらは互いに関連して配置されるか、または互いに関連付けられて、コンピューティング・システム102を形成すること、およびさまざまなサービス(例えば、コンピュータ関連のサービスおよびアプリケーション)を提供することができる。例えば、さまざまなコンテナ104、VM106、PM108、その他のリソース110、またはノード112は、本明細書においてさらに詳細に説明されるように、コンピューティング・システム102の複数のディメンションにわたって広がることができ、複数の層に配置され得る(例えば、コンテナ104は、第1の層に存在することができ、第2の層内の別のコンテナ104またはVM106に関連付けることができ、第2の層内の他のコンテナ104またはVM106は、第3の層内の別のVM106またはPM108に関連付けることができる、などである)。さまざまな実施形態に従って、コンテナ104、VM106、PM108、またはその他のリソース110は、ノード112であることができ、ノード112の一部であることができ、またはノード112に関連付けられ得る。
さまざまなときに、コンピュータ・プログラムまたは関連するデータにパッチを適用してコンピューティング・システム102を改良するのが、望ましいことがある。パッチは、コンピュータ・プログラムまたはコンピュータ・プログラムを支援するデータを更新するように設計されたか、またはコンピュータ・プログラムを修正もしくは改良するように設計された、1つのソフトウェアであることができる。パッチは、セキュリティの脆弱性またはその他のバグを修正すること、あるいはコンピュータ・プログラムのアップグレードに伴ってコンピュータ・プログラムの使い勝手または性能を改善することを、含むことができる。1つまたは複数の層に属することができるノードに対するパッチは、通常、オペレーティング・システム(例えば、第1の種類のオペレーティング・システム、第2の種類のオペレーティング・システム、第3の種類のオペレーティング・システムなど)に限定されず、ノードにインストールされているソフトウェア(例えば、アプリケーション、ミドルウェア、またはデータベース)にも適用され得る。
パッチの適用を容易にするために、システム100は、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従ってさまざまなコンテナ104、VM106、PM108、その他のリソース110、ノード112、アプリケーション、関連するデータなどへのパッチの適用を管理(例えば、制御)できる、パッチ管理コンポーネント(PMC:patch management component)114(更新管理コンポーネントとも呼ばれる)を備えることができる。PMC114は、(例えば、保守時間ウィンドウの間に)パッチを識別または決定して実行することができるパッチ識別コンポーネント116(更新識別コンポーネントとも呼ばれる)、およびさまざまなコンテナ104、VM106、PM108、その他のリソース110、ノード112、アプリケーション、または関連するデータなどに対してパッチ(例えば、選択されたパッチ)を実施または実行(例えば、適用)することができるパッチ実行コンポーネント118(更新実行コンポーネントとも呼ばれる)を、含むことができる。
一部のパッチは、システム100の一部のコンポーネント(例えば、コンテナ104、VM106、PM108、またはその他のリソース110、あるいはノード112など)に対して、それらのコンポーネントがオンラインであるときに実行することができ、一方、特定のパッチは、システム100の特定のコンポーネント(例えば、特定のコンテナ104、VM106、PM108、その他のリソース110、またはノード112など)に、それらの特定のコンポーネントがオフラインになるまで、適用することができない。通常は、パッチを適用するためにコンポーネントがオフラインになることができる、比較的短い時間(例えば、保守時間ウィンドウ)が存在することがある。さらに、さまざまなパッチが、さまざまなレベルの脆弱性、優先度、重要性、またはリスクに関連付けられることがある。したがって、保守時間ウィンドウが制限されていることがあるため、保守時間ウィンドウの間に、一部のパッチ(例えば、より高いレベルの脆弱性、優先度、重要性、またはリスクに関連付けられたパッチ)の適用を、他のパッチ(例えば、相対的に低いレベルの脆弱性、優先度、重要性、またはリスクに関連付けられたパッチ)よりも優先するのが、望ましいことがある。
さまざまな実施形態に従って、所定の保守時間ウィンドウの間に、PMC114は、第1のワークロード部分がオフラインであるときにパッチが適用される第1のワークロード部分、および第2のワークロード部分がオンラインであるときにパッチが適用され得る第2のワークロード部分を含んでいるワークロードを識別することができ、本明細書においてさらに詳細に説明されるように、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、パッチに関連付けられた脆弱性スコアに少なくとも部分的に基づいて、第1のワークロード部分がオフラインであるときに、保守時間ウィンドウの間に適用され得るパッチのサブセットを決定することができる。どのパッチを(例えば、保守時間ウィンドウの間に)実行するかを決定することにおいて、PMC114は、コンテナ104、VM106、PM108、その他のリソース110、ノード112、アプリケーションなどへのパッチの適用に関連する特徴を含む、コンテナ104、VM106、PM108、その他のリソース110、ノード112、アプリケーションなどに関するさまざまな特徴を考慮することができる。
例えば、コンテナ・プラットフォーム(例えば、特定の種類のコンテナ・プラットフォーム)に関連付けられたコンテナ(例えば、コンテナ104)にパッチを適用することに関して、通常、実行中のコンテナにパッチは適用されない。代わりに、コンテナ(例えば、104)に関して、コンテナがまだ実行中である(例えば、オンラインである)ときに、コンテナによって使用されるイメージに(例えば、パッチ実行コンポーネント118によって)パッチを適用することができ、新しいパッチ適用済みのコンテナ・イメージを使用して、コンテナが再起動され得る。新しいコンテナ(例えば、新しいコンテナ・イメージ)が起動されるときに、コンテナ上で実行されているアプリケーションが(例えば、PMC114によって)停止されることがあり、したがって、コンテナ・イメージのパッチ適用に関連して、アプリケーションに、停止時間および起動時間が生じることがある。
VM(例えば、VM106)にパッチを適用することに関しては、VMにパッチを適用することによって、アプリケーションに停止時間および起動時間が生じることがあり、多くの場合、(例えば、PMC114による)リブートが必要になる。さらに、アプリケーションが(例えば、PMC114によって)停止された後に、パッチ実行コンポーネント118は、VM(例えば、VM106)のVMインスタンス(イメージではない)にパッチを適用することができ、したがって、PMC114がアプリケーションを再起動する前に、VMインスタンスに、VMに適用可能なパッチの各々に関するパッチ適用時間が生じることがある。
示されたように、通常は、パッチ実行コンポーネント118によってオフラインのパッチ適用を実行できる制限されたウィンドウが存在することがある。例えば、クラスタ化されていないコンテナ104またはVM106の場合、制限された保守時間ウィンドウ(例えば、保守ダウンタイム・ウィンドウ(maintenance downtime window))が存在することがあり、この保守時間ウィンドウ内で、パッチ適用プロセスによって、アプリケーションの停止時間および起動時間、ならびにコンテナ104およびVM106のリブート時間および再起動時間が生じることがある。この制限された保守時間ウィンドウ内で、VM106にパッチ適用時間が生じることがある。保守時間ウィンドウの間に使用可能な制限された(例えば、相対的に短い)時間に起因して、通常、パッチ実行コンポーネント118は、保守時間ウィンドウの間に、パッチの部分的なサブセットのみを適用することができる。コンテナ104のパッチ適用に関しては、この保守時間ウィンドウの外側で(例えば、コンテナ104およびその他のリソースがオンラインであるときに)コンテナのイメージにパッチを適用することができるため、コンテナには、通常、このパッチ適用時間が生じない。したがって、コンテナ104の場合、パッチ実行コンポーネント118は、通常、(例えば、オンラインまたはオフラインであるときに)パッチをコンテナ104に適用することができる(例えば、すべてのパッチを適用することができる)。
オンラインのパッチ適用に関しては、例えば、コンテナ・プラットフォームの特定の種類(例えば、ローリング・アップデートをサポートできるコンテナ・プラットフォーム)に関して、(例えば、PMC114によって管理される)パッチ実行コンポーネント118は、ローリング・アップデート(例えば、ローリング・パッチ適用)を実行することができ、望ましい(例えば、正しい)レプリカの数に達する(例えば、達成される)まで新しいコントローラおよび古いコントローラでのレプリカ数を増やすか、または減らすことができる複製コントローラが採用され得る。例えば、ポッドが1つまたは複数のコンテナを含んでいることがある。複製コントローラは、任意の時間に望ましい(例えば、指定された)数のポッドのレプリカ(ポッドのレプリカ数またはコピーとも呼ばれる)が実行中である(例えば、1つまたは複数のノード上で同時に実行中である)ことを保証することができる。複製コントローラは、複数のノードにわたって複数のポッドを管理する(例えば、監視する)ことができる。例えば、複製コントローラが、多すぎるポッドが存在するということを決定した場合、複製コントローラは余分なポッドを終了することができ、複製コントローラが、十分なポッドが存在しないということを決定した場合、複製コントローラは、追加のポッドを起動または作成することができる。サービス停止が発生せずにサービスを更新するために、パッチ実行コンポーネント118は、ポッドに対してローリング・アップデートを実行することができ、ローリング・アップデートは、サービス全体(例えば、サービスのすべてのポッド)を同時に受け取るのではなく、一度に1つのポッドを更新することができる。サービスに関連付けられたワークロード部分(およびしたがって、サービス)は、更新中のさまざまなときに、それでも機能し続けることができ、このワークロード部分に対して実行しているノードの一部(例えば、レプリカ数に属するノード)は、パッチ適用のために停止されることがある。一部の実施形態では、PMC114が、ポッドに対するレプリカ数が1より大きいということを決定した場合、PMC114は、ポッドにライブで(例えば、オンラインで)パッチを適用できるということを決定できる。このようにして、パッチ実行コンポーネント118が、要求されたバッチ・サイズを有する新しいインスタンスでポッドのインスタンスを増加的に更新することによって、ダウンタイムなしでデプロイメントの更新が発生することを可能にする。VM106またはコンテナ104上の高可用性アプリケーション(例えば、特定のアプリケーション・サーバ)は、パッチ実行コンポーネント118を含んでいるPMC114が自動アプリケーション・ロールアウト更新プロセス(automatic application rollout update process)を実行できるようにすることができ、自動アプリケーション・ロールアウト更新プロセスは、アプリケーションのダウンタイムなしで、更新が実行されるクラスタのメンバーをホストしている各アプリケーション・サーバを停止または一時停止することができる。高可用性障害復旧(HADR:high availability disaster recovery)環境は、ソフトウェアまたはハードウェアをアップグレードするときに、ローリング・アップデート・プロセス全体を通じてデータベース・サービスを利用可能に保ちながら、処理が1つのデータベースから他のデータベースに切り替えられるときの瞬間的なサービスの中断のみを伴って、パッチ実行コンポーネント118を含んでいるPMC114が、データベース関連のソフトウェア(例えば、データベース製品ソフトウェア)を更新すること、またはデータベース構成パラメータを変更(例えば、修正、調整)することを可能にすることができる。
パッチ適用を管理することに関連して、PMC114は、定義されたパッチ管理基準に従って、所定の期間(例えば、保守時間ウィンドウ)の間にどのパッチを実装するかを決定することを容易にするために、コンピューティング・システム102(例えば、ハイブリッド・クラウド・コンピューティング・システム)の他の特徴または要因を考慮することもできる。例えば、ハイブリッド・クラウドに関しては、ハイブリッド・クラウドは、異なるプロバイダまたはベンダーからのクラウドのプラットフォームおよびサービスを使用するために、プラグ・アンド・プレイ手法を実装することができる。これらのクラウドは、本明細書においてさらに詳細に説明されるように、プライベート・クラウドまたはパブリック・クラウドあるいはオフプレミスまたはオンプレミスのクラウドを含むことができ、コンテナ104、VM106、PM108などであること、またはこれらを備えることができる。
一部の実施形態では、コンピューティング・システム102は、さまざまな依存関係(例えば、層間の依存関係)を含むことがある多層アプリケーションを採用することができる。多層アプリケーションは、プレゼンテーション機能、アプリケーション処理機能、業務処理機能、およびデータ管理機能を物理的に分離可能にすることができる。層は、1つのレイヤが他のレイヤに依存することがあるため、通常、積み重なったレイヤになることができる。各レイヤは、上位のレイヤを伴わずに存在することができ、そのようなレイヤの下位のレイヤを利用して機能することができる。層(例えば、段階的レイヤ)間のデータ転送は、アーキテクチャの一部であることができる。n層システムを通るデータ・フローのエンドツーエンドの追跡可能性は、システムの複雑さが増すときにより重要になる、困難な課題になることがある。各層自体は、クラスタとして実行することができる。
多層アプリケーション、依存関係、ならびにオフラインおよびオンラインのパッチ適用に関しては、オフラインの層とオンラインの層の間に、パッチ適用にとって重要な(例えば、重大な)依存関係が存在することがある。保守時間ウィンドウの間にオフラインのパッチ適用が実行される第1の層が存在し、次にその第1の層が、オンラインのパッチ適用を実行できる別の層に依存する場合、第1の層のためにオフラインで実行されているパッチが保守時間ウィンドウを満たすのが、望ましい(例えば、有用である)ことがある。オンラインのパッチ適用が実行される第1の層が存在し、次にその第1の層が、オフラインのパッチ適用が実行される別の層に依存する場合、オンラインのパッチ適用に関連付けられた第1の層は、基本的に、オフラインのパッチ適用に関連付けられた他の層の期間の間、(例えば、PMC114によって)オフラインであると見なされ得る。これによって、オンラインでパッチを適用できる依存関係ツリーの分岐を識別することを可能にすることができ、オフラインのパッチ適用のための保守時間ウィンドウの間に、より多くのサービスにパッチを適用することを可能にすることができる。
特定の実施形態では、PMC114は、定義されたパッチ管理基準に従って、さまざまなリソース(例えば、コンテナ104、VM106など)の同時の、または並列なパッチ適用を実行できることが望ましい。同じPM108を使用できる複数のコンテナ104およびVM106の同時のパッチ適用に関しては、マシン(例えば、VM106)が他のアプリケーションによっても使用されている場合、クラウド内でそれらのマシンに多すぎる負荷をかけないようにするのが望ましいことがある。したがって、PMC114は、マシン(例えば、VM106)に同時に適用されるパッチの量を望ましく制限するように、パッチ適用を制御することができる。サービスが別のアプリケーションからのリソースを使用できないようなやり方で、コンピューティング・システム102のクラウドが共有されるということが仮定される場合、パッチ実行コンポーネント118を採用しているPMC114は、定義されたパッチ管理基準に従って、望ましいだけの数のサービスへのパッチ適用を開始できる可能性がある。
したがって、開示される対象に関して、ワークロードにパッチを適用する問題が、パッチのサブセットを検出することに帰着することができ、このサブセットの一部は、他のパッチが(例えば、アプリケーションを停止することによって)オフラインで適用される間に、オンラインで適用することができ、パッチを適用するための合計時間は、許容される保守時間ウィンドウを超えない。パッチを適用することに関しては、開示されるように、パッチを適用するための時間は、パッチを実行するための実際の実行時間に加えて、アプリケーションの停止時間および起動時間、ならびにVMまたはコンテナのリブート時間および再起動時間を含むことがある。PMC114の目標は、優先順位を決めることであることができ、PMC114は、優先度が低いか、またはあまり緊急でないアプリケーションのパッチよりも、リスクの高い脆弱性へのパッチ適用、およびより緊急性の高いアプリケーションのパッチを優先することができる。
PMC114は、ハイブリッド・クラウド環境内のノードのグループにわたってデプロイされた複数のリソースを含んでいる多層ワークロードへのパッチ適用を管理することができ、ワークロードは、ノード(コンテナ104、VM106、PM108など)の混合にわたってデプロイされたリソースを含むことができる。PMC114は、他の望ましいリソースにオフラインでパッチを適用しながら、かつ保守時間ウィンドウ内で、サービスおよびアプリケーション、ならびにコンピューティング・システム102の関連するコンポーネントがオフラインである間に、パッチ適用が望ましいサービスおよびアプリケーションにパッチを適用できることを保証しながら、(例えば、オンラインのパッチ適用を実行できるということが決定された場合に)リソースの一部にオンラインでパッチが適用されることを可能にすることもできる。例えば、PMC114は、適用可能な保守時間ウィンドウ内で脆弱性のリスクのより高いパッチ(例えば、高い脆弱性または重要性のスコアまたはレベルを有するパッチ)を優先しながら、オフラインであるときに保守時間ウィンドウの間に特定のパッチが適用される第1のワークロード部分、およびオンラインであるときに他のパッチを適用できる第2のワークロード部分を含んでいるワークロードを、同時に、または実質的に同時に処理する(例えば、管理する)ことができる。
一部の実施形態では、PMC114は、コンテナ104、VM106、PM108、その他のリソース110、またはノード112などの間のワークロードの依存関係を決定することを容易にするために、要求(例えば、リソース間の要求)に関してネットワーク(例えば、コンピューティング・システム102のネットワーク)を監視することができ、ワークロードの依存関係は、第1の種類のアイテム(例えば、コンテナ104)と別の種類のアイテム(例えば、PM108)の間に存在するか、または同じ種類のアイテム(例えば、第1のVM106および第2のVM106)間に存在することがある。リソース間の要求は、リソース間の関連性、または1つのリソースが他のリソースに依存しているかどうか、要求の種類、またはリソースの層もしくは相対的層を(例えば、PMC114に)示すことがある(例えば、1つのリソースが1つの層(またはレイヤ)内に存在し、他のリソースが、この1つの層の下の別の層(またはレイヤ)内に存在する)。
PMC114は、本明細書において説明されているように、要求に関してネットワークを監視することに少なくとも部分的に基づいて、またはそのようなワークロードの依存関係を決定する他の手段によって、コンテナ104、VM106、PM108、その他のリソース110、またはノード112などの間のワークロードの依存関係を決定することができる。一部の実施形態では、PMC114は、要求を分析することに少なくとも部分的に基づいて、リソース間の依存関係を含んでいるネットワークのトポロジーを決定または識別することができる。また、要求を分析することに少なくとも部分的に基づいて、またはそのようなワークロードの依存関係を決定する他の手段によって、PMC114は、リソース/ノード間の依存関係ツリーを決定または生成することができ、コンピューティング・システム102またはその一部の依存関係ツリーは、PMC114が複数のサービスに同時にパッチを適用することを可能にする形状を有することができる。PMC114は、依存関係ツリーを活用して、所定の保守時間ウィンドウ内でより多くのパッチを含めること、および実行することを可能にすることができる。
PMC114は、リソース間のワークロードの依存関係に少なくとも部分的に基づいて、ワークロードを決定することができる。ワークロードは、保守時間ウィンドウ内で(例えば、ワークロードのアイテムのワークロードの依存関係に少なくとも部分的に起因して)オフラインであるときにパッチの第1のサブセットによってパッチが適用されるワークロードのアイテム(例えば、コンテナ104、VM106、PM108、リソース110、またはノード112など)であることができる第1のワークロード部分、およびオンラインであるときにパッチの第2のサブセットによってパッチが適用され得る第2のワークロード部分を含むことができる。パッチ識別コンポーネント116は、ワークロードに適用されるパッチ、あるいはパッチまたはパッチに関連する情報の相対的な重要度(例えば、脆弱性スコア)を識別または決定することができる。
所定の保守時間ウィンドウの間にどのパッチを実行するかを決定することを容易にするために、PMC114は、少なくとも、保守時間ウィンドウの間にオフラインであるときにワークロードの第1のワークロード部分に対して実行されるのが望ましいパッチの第1のサブセットに対して、脆弱性スコアを決定することができる。一部の実施形態では、PMC114は、オンラインであるときにワークロードの第2のワークロード部分に対して実行され得るパッチの第2のサブセットに対して、脆弱性スコアを決定することもできる。
保守時間ウィンドウの間に使用可能な制限された時間を前提として、保守時間ウィンドウの間に、第1のワークロード部分に対してパッチの第1のサブセット内のすべてのパッチを実行できないことが多い。PMC114は、パッチの第1のサブセットまたはパッチの第2のサブセットのパッチの各々の重要性、優先度、脆弱性、またはリスク・レベルに少なくとも部分的に基づいて、パッチの第1のサブセットまたはパッチの第2のサブセットのパッチの脆弱性スコアを決定することができる。通常、パッチの第1のサブセット内の他のパッチよりも、実行することがより重要である一部のパッチが存在することがある。PMC114は、保守時間ウィンドウの間に、実行することができるパッチの第1のサブセットのより重要なパッチを実行するように、パッチに優先順位を付けることによって、対処されるリスク(例えば、コンピューティング・システム102またはその一部(コンテナ104、VM106、PM108、その他のリソース110、ノード112、アプリケーション、またはデータなど)に対するリスク)を最大化することができ、保守時間ウィンドウの間に実行される(例えば、実行されるパッチの第3のサブセットに含まれる)より重要なパッチを選択することができる。
脆弱性スコアは、パッチの重要性における変動を示すことができる。例えば、PMC114は、パッチの各々に関する各問題の重大さの程度について知らせることができる脆弱性評価尺度(vulnerability scoring scale)(例えば、点尺度)を採用することができ、PMC114は、この尺度を使用して、パッチごとに問題の重大度を判定または決定し、最も重要なパッチを決定することができる。脆弱性評価尺度は、正確な欠陥および欠陥の種類(または現在の脅威レベル、ただし、現在の脅威レベルはそのような分析から省略されることがある)の技術的分析に基づいて、可能性のあるリスクを考慮することができる。共通脆弱性評価システム(CVSS:Common vulnerability scoring system)ベースのスコアは、脆弱性に関する追加の指針を提供することができ、脆弱性の一定の態様(例えば、アクセス・ベクトル、アクセスの複雑さ、認証、機密性、完全性、および可用性)を採点することによって、詳細な重大度の評価を行う。一部の実施形態では、PMC114は、1~3の脆弱性評価尺度を採用することができ、1が最も重要なパッチ適用を表し、3が重要性が最も低いパッチ適用を表す。例えば、1の値またはスコアは、パッチに関連付けられた脆弱性のレベルが高く、そのようなパッチの優先度が高いことを示すことができ、2の値またはスコアは、パッチに関連付けられた脆弱性のレベルが中程度であり、そのようなパッチの優先度が相対的に中程度であることを示すことができ、3の値またはスコアは、パッチに関連付けられた脆弱性のレベルが低く、そのようなパッチの優先度が相対的に低いことを示すことができる。さまざまなその他の実施形態では、PMC114が、例えば、5(または10または100)が最も重要なパッチ適用を表し、1が重要性が最も低いパッチ適用を表すか、またはその逆を表す、1~5(または10または100)の尺度などの、その他の脆弱性、重要性、またはリスクの評価尺度を採用することができるということが、認識され、理解されるべきである。
特定の実施形態では、PMC114は、本明細書においてさらに詳細に説明されるように、望ましいパッチ管理アルゴリズムを使用して、(パッチのグループごとの)個別のパッチの個別の脆弱性スコアに少なくとも部分的に基づいて、パッチのグループに対して、グループ脆弱性スコアを決定するか、または割り当てることができる。例えば、適用され得る1つのパッチ管理アルゴリズムに従って、PMC114は、本明細書においてさらに詳細に説明されるように、等比級数の合計に基づく式を個別の脆弱性スコアに適用することによって、(パッチのグループごとの)個別のパッチの個別の脆弱性スコアに少なくとも部分的に基づいて、第1のワークロード部分または第2のワークロード部分に関連付けられたパッチのグループ(例えば、パッチの異なるグループ化)のグループ脆弱性スコアを決定する(例えば、計算する)ことができる。PMC114は、より高い脆弱性スコアを有しているパッチにより高い優先度を与えるために、そのような式を使用して、低い脆弱性スコアを有している多数のパッチが、高い脆弱性スコアを有している相対的に少数のパッチよりも高いグループ脆弱性スコアを有することにならないようにすることを、容易にすることができる。
パッチの脆弱性スコアを評価した後に、PMC114は、パッチの第1のサブセットまたはパッチの第2のサブセットのパッチの脆弱性スコア、および保守時間ウィンドウに少なくとも部分的に基づいて、第1のワークロード部分の一部(例えば、コンテナ104、VM106、PM108、リソース110、またはノード112などのサブセット)に適用され得るパッチの第3のサブセットを、第1のワークロード部分に関連付けられたパッチの第1のサブセットから決定することができる。例えば、PMC114は、望ましいパッチ管理アルゴリズムに従って(例えば、式またはその他の望ましいパッチ管理アルゴリズムを使用して)、第1のワークロード部分または第2のワークロード部分に関連付けられたパッチの他のグループのグループ脆弱性スコアと比較して最も高いグループ脆弱性スコアを有している第1のワークロード部分または第2のワークロード部分に関連付けられたパッチのグループを、決定することができる。PMC114は、パッチ適用に関して最も高いグループ脆弱性スコアを有しているパッチのグループを選択することができ、このパッチのグループは、保守時間ウィンドウの間にオフラインであるときに第1のワークロード部分の一部に適用され得るパッチの第3のサブセット、またはオンラインであるときに第2のワークロード部分に適用され得るパッチの第2のサブセットを含むことができる。
パッチ実行コンポーネント118は、保守時間ウィンドウの間に、第1のワークロード部分の一部に対して、パッチの第3のサブセットを実行する(例えば、適用する)ことができる。一部の実施形態では、パッチ実行コンポーネント118は、PMC114によって決定されたネットワークのトポロジーに従って、トポロジー的順序で、パッチの第3のサブセットのパッチを実行することができる。特定の実施形態では、パッチ実行コンポーネント118は、使用可能な保守時間ウィンドウ内で、第1のワークロード部分の一部の、依存関係を有するワークロードのアイテムを含む複数のワークロードのアイテム(例えば、コンテナ104、VM106、PM108、その他のリソース110、ノード112、アプリケーション、またはデータなど)に対して、パッチの第3のサブセットのパッチを同時に(例えば、並列に)実行することができる。
パッチ実行コンポーネント118を含んでいるPMC114は、パッチの第3のサブセットの実行を容易にするためのパッチ適用プロセスを実行することができ、このパッチ適用プロセスは、本明細書においてさらに詳細に説明されるように、第1のワークロード部分の一部に関連付けられたリソースを停止することおよび再起動すること、ならびにパッチの第3のサブセットに関連付けられたノードをリブートすることを含むことができる。パッチが適用されるコンテナ104に関しては、変更不可能なコンテナ・インスタンスに通常はパッチが適用されないため、パッチ実行コンポーネント118は、コンテナ104のコンテナ・イメージにパッチを適用することができる。VM106およびPM108に関しては、パッチ実行コンポーネント118は、必ずしもVM106またはPM108のVMまたはPMのイメージではなく、通常、VM106またはPM108のVMまたはPMのインスタンスにパッチを適用することができる。
パッチ実行コンポーネント118は、第2のワークロード部分に対してパッチの第2のサブセットを実行することもでき、パッチの第2のサブセットは、第2のワークロード部分(または、コンピューティング・システム102の他の部分)がオンラインであるときに実行することができ、あるいは保守時間ウィンドウの外側で、または保守時間ウィンドウの間に実行することができる。特定の実施形態では、パッチ実行コンポーネント118は、パッチの第2のサブセットのパッチのすべて、または少なくとも一部を、第2のワークロード部分に対して同時(例えば、並列に)に実行することができ、保守時間ウィンドウの間に、パッチの第3のサブセットのパッチの一部が第1のワークロード部分の一部に対して実行される。
一部の実施形態では、パッチ実行コンポーネント118を含んでいるPMC114は、次のようにパッチ(例えば、パッチの第2および第3のサブセット)を適用することができる。パッチ実行コンポーネント118は、ライブのパッチ適用を(例えば、バックグラウンドで)開始し、第2のワークロード部分(例えば、コンテナ104(例えば、ポッド)、VM106、PM108、その他のリソース110、ノードなど)に関して、例えば、パッチがライブで(例えば、オンラインで)適用され得る関連するサービスのために、パッチを適用することができる。ポッドのサブセット、および第1のワークロード部分の一部のVM106ごとのパッチのサブセットに関する、オフラインで実行されている第1のワークロード部分の一部に関連付けられたパッチ適用に関しては、パッチ実行コンポーネント118は、依存関係を有していないポッド(例えば、コンテナ104)およびVM106に対するパッチ適用を開始することができ、そのようなポッドおよびVMに並列にパッチを適用する(例えば、更新する)ことができる。ポッドまたはVMにパッチが適用されるたびに、PMC114は、パッチが適用され得るポッドおよびVMのリストを更新することができ、ポッドおよびVMのリスト上のポッドおよびVMに対してパッチ適用を開始することができる。パッチ実行コンポーネント118を含んでいるPMC114は、望ましい(例えば、選択された)サービスのすべてにパッチが適用されるまで、この開示されたプロセスを継続することができる。
パッチの実行後に、PMC114は、パッチが適切に適用されたことを保証し、そのようなパッチが適用された後に、パッチ、ならびに第1のワークロード部分または第2のワークロード部分の一部の各アイテム、およびコンピューティング・システム全体が適切に機能していることを保証するのを容易にするために、保守時間ウィンドウ内で第1のワークロード部分または第2のワークロード部分の一部のパッチ適用の妥当性を確認することができる。例えば、1つまたは複数のパッチが適用された後に、PCM114は、パッチのうちの1つまたは複数に関連付けられたか、またはパッチのうちの1つまたは複数による影響を受けたアプリケーション、ノード、またはリソースなどを分析するか、または調べて、アプリケーション、ノード、またはリソースなどが、アプリケーション、ノード、またはリソースなどが定義された正常な動作状態または使用可能な動作状態にある(例えば、アプリケーション、ノード、またはリソースなどが、正しく、適切に、容認できる状態で、または最適に動作しているか、あるいは少なくとも、定義された最小限の動作基準を満たすか、または超えるように十分良好に動作している)ことを示す定義されたパッチ管理基準を満たしているかどうかを決定することができる。1つまたは複数のパッチが適用された後に、PMC114が、アプリケーション、ノード、またはリソースなどがそのような定義されたパッチ管理基準を満たしているということを決定した場合、PMC114は、1つまたは複数のパッチの妥当性が確認されたということを決定できる。PMC114が、特定のパッチの妥当性が確認されたということを決定した場合、PMC114は、この特定のパッチを維持することができる。しかし、特定のパッチおよび関連するワークロードのアイテムの妥当性を確認できないということの決定に応答して、PMC114は、保守時間ウィンドウ内で、ワークロードのアイテムに関連付けられた特定のパッチを取り消し、ワークロードのアイテムを特定のパッチが適用される前の状態に戻すことができる。
保守時間ウィンドウの間にPMC114によって実行対象として選択されなかったパッチの第1のサブセットの他のパッチ(例えば、適用されていないパッチ)に関しては、PMC114は、定義されたパッチ管理基準に従って、そのような他のパッチを第1のワークロード部分の他の一部に対して実行することを、次の、または将来の保守時間ウィンドウに延期することができる。PMC114は、パッチ実行コンポーネント118がパッチの第1のサブセットの他のパッチ(または、もしあれば、その後使用可能になることができるか、もしくは検出され得る他のパッチ)を適用できる次の保守時間ウィンドウを、決定または計算することができる。
ここで図2を(図1と共に)参照すると、図2は、開示される対象のさまざまな態様および実施形態に従って、複数のディメンションにわたることができるワークロードを含んでいる例示的な非限定的コンピューティング・システム200の図を示している。コンピューティング・システム200(例えば、ハイブリッド・クラウドベースのコンピューティング・プラットフォーム)は、従来のITプラットフォーム202、プライベート・クラウド・コンピューティング・プラットフォーム204、およびパブリック・クラウド・コンピューティング・プラットフォーム206を備えることができ、それによって、コンピューティング・プラットフォームに関して、複数のディメンションに広がることができる。従来のITプラットフォーム202は、例えば、アプリケーション208および210を含むアプリケーション(app:applications)、アプリケーション・サーバ212および214を含むアプリケーション・サーバ(app ser:application servers)、ならびにデータベース216および218を含むデータベース(DB:databases)を備えることができる。プライベート・クラウド・コンピューティング・プラットフォーム204は、例えば、アプリケーション220および222を含むアプリケーション、アプリケーション・サーバ224および226を含むアプリケーション・サーバ、ならびにデータベース228および230を含むデータベースを備えることができる。パブリック・クラウド・コンピューティング・プラットフォーム206は、例えば、アプリケーション232および234を含むアプリケーション、アプリケーション・サーバ236および238を含むアプリケーション・サーバ、ならびにデータベース240および242を含むデータベースを備えることができる。
一部の実施形態では、コンピューティング・クラウド(例えば、204、206)は、異なるベンダー(例えば、第1のベンダー、第2のベンダー、または第3のベンダーなど)に関連付けることができ、したがって、ベンダーおよびベンダーの種類(例えば、ベンダーによって提供されるサービスの種類)に関して、複数のディメンションにわたって広がることができる。コンピューティング・システム200は、例えば、さまざまなコンピューティング・サービスを提供することができるベアメタル・ハイパーバイザ技術、カーネルベースのVM(KVM:kernel-based VM)(例えば、カーネルベースのハイパーバイザ技術)、マイクロカーネルベースのハイパーバイザ技術、コンテナ、またはユニカーネルなどの複数のハイパーバイザ技術を採用することもでき、したがってハイパーバイザ技術の種類に関して複数のディメンションにわたって広がることができる。
ワークロードは、例えばコンピューティング・プラットフォーム(例えば、従来のITプラットフォーム202、プライベート・クラウド・コンピューティング・プラットフォーム204、またはパブリック・クラウド・コンピューティング・プラットフォーム206)、コンピューティングまたはクラウド・サービス・ベンダー、ハイパーバイザ技術、リソースの種類(例えば、VM、コンテナ、PM、ノード、またはその他のリソース)に関して、複数のディメンションにわたって広がることができ、各ワークロードは、ワークロードのリソース間のそれ自身の依存関係(例えば、ワークロードの複数の層のノード間の依存関係)を有している(または依存関係を有していない)ことがある。例えば、例示的なコンピューティング・システムは、第1のワークロード244、第2のワークロード246、および第3のワークロード248を含むことができる。第1のワークロード244は、従来のITプラットフォーム202およびプライベート・クラウド・コンピューティング・プラットフォーム204にわたって広がることができるVM(例えば、VMのみ)を含むことができ、第1のワークロード244のVMは、従来のITプラットフォーム202のデータベース216、ならびにプライベート・クラウド・コンピューティング・プラットフォーム204のアプリケーション220およびアプリケーション・サーバ224によって実装されるか、またはデータベース216、アプリケーション220、およびアプリケーション・サーバ224に関連付けられることができ、データベース216、アプリケーション220、およびアプリケーション・サーバ224は、VMとして、またはVMの形態で実装され得る。
第2のワークロード246は、VM、PM、およびコンテナを含むことができ、プライベート・クラウド・コンピューティング・プラットフォーム204およびパブリック・クラウド・コンピューティング・プラットフォーム206にわたって広がることができる。例えば、第2のワークロード246のVMは、パブリック・クラウド・コンピューティング・プラットフォーム206の(例えば、VMとして実装された)アプリケーション・サーバ236、プライベート・クラウド・コンピューティング・プラットフォーム204の(例えば、PMとして実装された)データベース228、およびパブリック・クラウド・コンピューティング・プラットフォーム206の(例えば、コンテナ(Con:container)として実装された)アプリケーション234によって実装されるか、またはアプリケーション・サーバ236、データベース228、およびアプリケーション234に関連付けられることができる。
第3のワークロード248は、コンテナ(例えば、コンテナのみ)を含むことができ、プライベート・クラウド・コンピューティング・プラットフォーム204およびパブリック・クラウド・コンピューティング・プラットフォーム206にわたって広がることができる。例えば、第3のワークロード248のコンテナは、プライベート・クラウド・コンピューティング・プラットフォーム204のデータベース230、ならびにパブリック・クラウド・コンピューティング・プラットフォーム206のアプリケーション234およびアプリケーション・サーバ238によって実装されるか、またはデータベース230、アプリケーション234、およびアプリケーション・サーバ238に関連付けられることができ、データベース230、アプリケーション234、およびアプリケーション・サーバ238は、コンテナとして、またはコンテナの形態で実装され得る。これらのワークロード(例えば、244、246、248)は、単に例示的なワークロードであり、さまざまな実施形態に従って、開示される対象は、これらの例示的なワークロードおよび本明細書に記載された他のワークロードに加えて、または代替として、さまざまな異なる種類のワークロードを含むか、さまざまな異なる種類のワークロードに関連するか、またはさまざまな異なる種類のワークロードを伴うことができるということが、認識され理解されるべきである。
第1のワークロード244、第2のワークロード246、および第3のワークロード248は、(例えば、PMC114およびパッチ実行コンポーネント118による)オフラインのパッチ適用に関して、リソース間の依存関係の例を提供することができ、リソースは、図2に示されているように(および、別の方法で図面に示されているか、または本明細書に記載されているように)、1つまたは複数のノードにわたって分散され得る。PMC114は、本明細書においてさらに詳細に説明されるように、ワークロード(例えば、244、246、248など)に関連付けられたワークロードのリソース間の依存関係(例えば、ワークロードの複数の層のノード間の依存関係)を決定または識別し、定義されたパッチ管理基準(および、例えば関連するパッチ管理アルゴリズム)に従って、特定のワークロードを中断することも妨げることもなく、どのリソースを停止して起動することができるかを決定することを含む、特定の保守時間ウィンドウの間にどのパッチが特定のワークロードに対して実行されるか(例えば、特定の保守時間ウィンドウに関して、どのパッチが他のパッチよりも優先されて実行されるか)を決定することを、容易にすることができる。
図3を(図1と共に)参照すると、図3は、開示される対象のさまざまな態様および実施形態に従って、パッチに関連付けられたワークロードがオフラインであるときに、保守時間ウィンドウの間にパッチを適用するための例示的なパッチ・シーケンス300のブロック図を示している。例示的なパッチ適用シーケンス300は、例示的なワークロードに関連することができる。ただし、例示的なパッチ適用シーケンス300が、例示的なワークロードに関連することができる1つの例示的なパッチ適用シーケンスであり、本明細書において説明されているように、さまざまな実施形態によれば、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、他のワークロードに関して他のパッチ適用シーケンスが(例えば、PMCによって)実行され得るということが、認識され理解されるべきである。
保守時間ウィンドウの間にパッチ適用シーケンス300に関連付けられた例示的なワークロードに対してパッチを実行するときに、例示的なパッチ適用シーケンス300は、パッチ適用シーケンス300の参照番号302によって示されているように、保守時間ウィンドウの間に、パッチが実行されるワークロードに関連付けられたWebサーバを停止する(例えば、Webサーバの動作を停止または一時停止する)ことを含むことができる。例えば、PMC114は、保守時間ウィンドウの間、Webサーバを停止することができる。パッチ適用シーケンス300の参照番号304で、PMC114は、ワークロードに関連付けられたアプリケーション・サーバを停止する(例えば、アプリケーション・サーバの動作を停止または一時停止する)ことができる。参照番号306で、PMC114は、ワークロードに関連付けられたデータベースのデータベース・バックアップの妥当性を確認することができる(例えば、データベースに格納されているデータを保護するために、データベースがバックアップされたことの妥当性を確認すること、または検証することができる)。例えば、データベースに格納されているデータのバックアップを容易にするために、データベースに格納されているデータを、1つまたは複数のデータ・ストアに格納することができる。参照番号308で、PMC114がデータベースを停止することができる。
パッチ適用シーケンス300の参照番号310で、パッチ実行コンポーネント118がパッチをワークロードに適用することができ、これらのパッチは、ワークロードに関連付けられたオペレーティング・システム、ミドルウェア、またはアプリケーションに対するものであることができる。参照番号312で、PMC114が、ワークロードに関連付けられたノード(例えば、パッチが適用されるノード)を再起動する(例えば、ノードの動作をリブートまたは再開する)ことができる。参照番号314で、PMC114がデータベースを起動することができる。参照番号316で、PMC114がアプリケーション・サーバを起動する(例えば、アプリケーション・サーバの動作を再開する)ことができる。参照番号318で、PMC114がWebサーバを起動することができる。
パッチ適用シーケンス300の参照番号320で、PMC114は、ワークロードの妥当性を確認することができる。例えば、保守時間ウィンドウの間に、ワークロードに関連付けられたリソースがオフラインであるときに、PMC114は、ワークロードおよびワークロードに対して実行された関連するパッチの妥当性を確認し、パッチが実行された後に、ワークロードに関連付けられたリソースおよび関連するパッチが適切に機能している(例えば、Webサーバが適切に機能している、アプリケーション・サーバが適切に機能している、データがデータベースに復元されていることを含めて、データベースが適切に機能している、およびノードが適切に機能している)ことの妥当性を確認すること、または検証することができる。妥当性確認プロセスの間に、PMC114が、パッチが実行された後に、特定のパッチまたは関連するワークロードのアイテムもしくはリソース(例えば、ノード、Webサーバ、アプリケーション・サーバ、データベースなど)が適切に、または容認できる状態で機能していないことを決定した場合、PMC114は、本明細書においてさらに詳細に説明されるように、保守時間ウィンドウの間にパッチを取り消し(例えば、元に戻し)、ワークロードのアイテムもしくはリソースをパッチが実行される前の状態に戻すことができる。妥当性を確認できないパッチは、将来のある時点で、例えば、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、望ましい(例えば、許容できる、適切な、改善された、または最適な)方式で機能するようにパッチが修正された後に、再実行することができる。
図4を(図1と共に)参照すると、図4は、開示される対象のさまざまな態様および実施形態に従って、ワークロードのリソース間の依存関係の決定およびパッチ管理に関連して例示的なアプリケーション・トポロジー400の図を示している。クラウド・コンピューティング・システム402は、望ましいように互いに関連して配置されるか、または互いに関連付けられてクラウド・コンピューティング・システム402を形成し、さまざまな望ましいサービスおよびアプリケーションを提供することができる、さまざまなリソースおよびノードを備えることができる。
クラウド・コンピューティング・システム402では、例示的なアプリケーション・トポロジー400が、トレーダー・アプリケーションに関連付けられ得るトレーダー・コンテナ404、ソーシャル・ネットワーキング・アプリケーションに関連付けられ得るソーシャル・ネットワーキング・サービス(soc nw svc:social networking service)コンテナのレプリカ406、消費者ロイヤルティ・サービス・アプリケーションに関連付けられ得る消費者ロイヤルティ・サービス(loyalty svc:loyalty service)コンテナのレプリカ408、および通信サービス・アプリケーションに関連付けられ得る通信サービス(comm svc:communication service)コンテナ410を備えることができる。
トレーダー・コンテナ404は、例えば、ユーザ・インターフェイス(UI:user interface)であることができるか、またはユーザ・インターフェイスを備えることができ、アプリケーション・トポロジー400の第1の層(例えば、最上層または最高の層)に位置することができる。トレーダー・コンテナ404は、アプリケーション・トポロジー400の第2の層に位置することができるポートフォリオ・コンテナ412に関連付ける(例えば、通信によって、または動作可能なように、ポートフォリオ・コンテナ412に接続される)ことができ、ポートフォリオ・コンテナ412は、サーバであることができ、またはサーバを備えることができる。ポートフォリオ・コンテナ412は、アプリケーション・トポロジー400内のポートフォリオ・コンテナ412およびトレーダー・コンテナ404の下の、アプリケーション・トポロジー400の第3の層に位置することができるデータベースVM414に関連付けることができ、データベースVM414は、データベースまたはデータベース・アプリケーションもしくはデータベース・サービスであることができ、あるいはデータベースまたはデータベース・アプリケーションもしくはデータベース・サービスを備えることができる。ポートフォリオ・コンテナ412は、アプリケーション・トポロジー400内のポートフォリオ・コンテナ412およびトレーダー・コンテナ404の下の、アプリケーション・トポロジー400の第3の層に位置することができる株式コンテナ416に関連付けることもでき、株式コンテナ416は、サービス(例えば、株式取引などの、株式に関連するサービス)であることができ、またはサービスを備えることができる。
PMC114は、ネットワーク、リソース、またはノード、あるいはリソース間の要求を分析することができ、この分析に少なくとも部分的に基づいて、コンテナ104、VM106、PM108、その他のリソース110、またはノード112などの間の依存関係を識別または決定することができる。例えば、PMC114は、要求に関してネットワークを監視することができ、そのような要求を分析することができ、この分析の結果に少なくとも部分的に基づいて、コンテナ104、VM106、PM108、その他のリソース110、またはノード112などの間の依存関係を決定または推定することができる。例えば、例示的なアプリケーション・トポロジー400に関して、PMC114は、互いに関連して、トレーダー・コンテナ404が第1の層内にあり、ポートフォリオ・コンテナ412が第2の層内にあり、データベースVM414および株式コンテナ416が第3の層内にあるということの決定を含めて、トレーダー・コンテナ404、ポートフォリオ・コンテナ412、データベースVM414、および株式コンテナ416の間の依存関係を決定することができる。
図5を(図1と共に)参照すると、図5は、開示される対象のさまざまな態様および実施形態に従って、ワークロードのリソース間の依存関係およびパッチ管理に関連して、コンピューティング・システムに関連付けられた例示的なワークロードに関して例示的なパッチ選択500の図を示している。例示的なパッチ選択500に関して、PMC114は、本明細書においてさらに詳細に説明されるように、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、ワークロードのリソース間の依存関係(例えば、ワークロードの複数の層のノード間の依存関係)、ワークロードのアイテムおよび実行される関連するパッチの相対的な重要性、優先度、または脆弱性、あるいはその他の要因を考慮して、ワークロードの第1のワークロード部分に関連付けられたリソース、ノードなどがオフラインであるときに、保守時間ウィンドウ内で(例えば、パッチ実行コンポーネント118によって)適用されるワークロードの第1のワークロード部分に関連付けられ得るパッチのサブセットを含んでいる、実行対象として選択されるパッチを決定することができる。PMC114は、第2のワークロード部分に関連付けられたリソース、ノードなどがオンライン(例えば、ライブ)であるときに(例えば、パッチ実行コンポーネント118によって)適用され得るワークロードの第2のワークロード部分に関連付けられたパッチの別のサブセットを決定することもでき、第2のワークロード部分に関連付けられた、パッチの他のサブセットまたはパッチの他のサブセットの少なくとも一部が、保守時間ウィンドウ内で(例えば、第1のワークロード部分に関連付けられたパッチを実行することと同時に、または並列に)適用され得る。
PMC114は、本明細書においてさらに詳細に説明されるように、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、所定の保守時間ウィンドウ内でより脆弱性の高いパッチ(例えば、より緊急性の高いアプリケーションのパッチ)を適用することを優先することができる。例えば、PMC114は、所定の保守時間ウィンドウ内で脆弱性のより高いパッチ(例えば、高い脆弱性または重要性のスコアまたはレベルを有するパッチ)を優先するために、オフラインであるときに保守時間ウィンドウの間に特定のパッチが適用される第1のワークロード部分の少なくとも一部、およびオンラインであるときに他のパッチを適用できる第2のワークロード部分を含んでいるワークロードのパッチ適用を、(例えば、同時に、または実質的に同時に)処理する(例えば、管理する)ことができる。
例示的なパッチ選択500に関して、ワークロード(例えば、アプリケーションまたは関連するリソース、ノードなど)の第1のワークロード部分がオフラインであり、第2のワークロード部分がオンラインであるときに、保守時間ウィンドウ(例えば、適用可能なダウンタイム・ウィンドウ)内でパッチを実行することが望ましいさまざまなアプリケーションに関連付けられたワークロードが存在することができる。これらのアプリケーションは、例えば、通信サービス(comm svc)アプリケーション502、消費者ロイヤルティ・サービス(loyalty svc)アプリケーション504、トレーダー・アプリケーション506、ポートフォリオ・アプリケーション508、データベース・アプリケーション510、ソーシャル・ネットワーキング・サービス(soc nw svc)アプリケーション512、および株価アプリケーション514を含むことができる。
アプリケーション(例えば、502、504、506、508、510、512、514)に関して、アプリケーションに関連付けられたリソース間の依存関係およびワークロードに関連付けられたパッチの分析の結果に少なくとも部分的に基づいて、PMC114は、実行される(例えば、適用される)ことが望ましいさまざまなパッチを決定または識別することができ、第1のワークロード部分がオフラインであるときに、保守時間ウィンドウ内で、それらのパッチのうちのどのパッチが、第1のワークロード部分に関連付けられたリソース(例えば、コンテナ104、VM106、PM108、その他のリソース110)、ノード(例えば、ノード112)などに適用されるかを決定することができ、第2のワークロード部分がオンラインであるときに、それらのパッチのうちのどのパッチが、リソース、ノードなどに適用され得るかを決定することができる。第1のワークロード部分に関連付けられ、第1のワークロード部分に関連付けられたリソース、ノードなどがオフラインであるときに保守時間ウィンドウの間に実行されるパッチの一部に関して、PMC114は、保守時間ウィンドウ内で実行されることが望ましいパッチの相対的な(例えば、異なる)重要性、優先度、または脆弱性(例えば、高レベル、中レベル、または低レベル)を決定することができる。しかし、多くの場合に当てはまるように、保守時間ウィンドウ内で適用できるパッチの数よりも多い適用対象のパッチが存在することがある。例えば、PMC114は、通信サービス・アプリケーション502に関して実行されるパッチ516および518を決定または識別することができ、パッチ516および518が低レベルのパッチである(例えば、パッチ516および518が、相対的に低いレベルの重要性、優先度、または脆弱性を有していることを示す脆弱性スコアをそれぞれ有している)ということを、さらに決定することができる。PMC114は、消費者ロイヤルティ・サービス・アプリケーション504に関して実行されるパッチ520、522、および524を決定または識別することもでき、パッチ520が高レベルのパッチであり(例えば、パッチ520が、高レベルの重要性、優先度、または脆弱性を有していることを示す脆弱性スコアを有しており)、パッチ522が中レベルのパッチであり(例えば、パッチ522が、中レベルの重要性、優先度、または脆弱性を有していることを示す脆弱性スコアを有しており)、パッチ524が低レベルのパッチである(例えば、パッチ524が、相対的に低いレベルの重要性、優先度、または脆弱性を有していることを示す脆弱性スコアを有している)ということを、さらに決定することができる。
PMC114は、トレーダー・アプリケーション506に関して実行されるパッチ526、528、および530をさらに決定または識別することができ、パッチ526および528が高レベルのパッチであり、パッチ530が低レベルのパッチであるということを、さらに決定することができる。さらに、PMC114は、ポートフォリオ・アプリケーション508に関して実行されるパッチ532および534を決定または識別することができ、パッチ532および534が中レベルのパッチであるということを、さらに決定することができる。PMC114は、データベース・アプリケーション510に関して実行されるパッチ536、538、および540を決定または識別することもでき、パッチ536が中レベルのパッチであり、パッチ538および540が低レベルのパッチであるということを、さらに決定することができる。
PMC114は、ソーシャル・ネットワーキング・サービス・アプリケーション512に関して実行されるパッチ542および544をさらに決定または識別することができ、パッチ542が中レベルのパッチであり、パッチ544が低レベルのパッチであるということを決定することもできる。PMC114は、株価アプリケーション514に関して実行されるパッチ546、548、および550をさらに決定または識別することができ、パッチ546が中レベルのパッチであり、パッチ548および550が低レベルのパッチであるということを決定することもできる。
PMC114は、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、パッチ(例えば、パッチ516~550)を分析し、ワークロードに関連付けられたリソース間の依存関係を決定および分析し、第1のワークロード部分がオフラインであるときに実行されるパッチ(例えば、パッチのサブセット)を決定し、第2のワークロード部分がオンラインであるときに実行され得るパッチ(例えば、パッチの他のサブセット)を決定し、パッチの脆弱性スコアまたはパッチのさまざまなグループ(例えば、グループ化)のグループ脆弱性スコアを決定し、保守時間ウィンドウ内で実行され得る、パッチの他のサブセットの他の全体的脆弱性スコアよりも高い(例えば、最高の)全体的脆弱性スコアを有するパッチの望ましい(例えば、最適な、適切な、または許容できる)サブセットを決定することができる。パッチのそのような望ましいサブセットは、最高の全体的脆弱性スコアを有する(例えば、脆弱性スコアを最大化する)ことによって、コンピューティング・システムの脆弱性を最小限に抑えるか、または少なくとも大幅に低減することができる。
例示的なパッチ選択500では、分析結果に少なくとも部分的に基づいて、PMC114は、例えば、通信サービス・アプリケーション502に関連付けられた低レベルのパッチであることができるパッチ516および518、ならびにソーシャル・ネットワーキング・サービス・アプリケーション512に関連付けられた、それぞれ中レベルのパッチおよび低レベルのパッチであることができるパッチ542および544が、第2のワークロード部分に関連付けることができ、第2のワークロード部分がオンラインであるときに適用され得る(例えば、保守時間ウィンドウ内または保守時間ウィンドウ外で適用され得る)ということを、決定することができる。また、分析結果に少なくとも部分的に基づいて、PMC114は、(例えば、最高の全体的脆弱性スコアを有し、保守時間ウィンドウ内で実行することができる)パッチの望ましいサブセットが、パッチ520、522、524、526、528、530、532、534、および536を含むことができるが、パッチ538、540、546、548、および550を含まないということを、決定することができる。パッチ実行コンポーネント118は、本明細書においてさらに詳細に説明されるように、第1のワークロード部分がオフラインであるときに、保守時間ウィンドウ内で、第1のワークロード部分に関連付けられたパッチのサブセット(例えば、パッチ520~536)を適用することができ、第2のワークロード部分がオンラインであるときに、保守時間ウィンドウ内で、第2のワークロード部分に関連付けられたパッチの他のサブセット(例えば、パッチ516、518、542、および544)を適用することができる。
さらに図1に関して、保守時間ウィンドウの間に実行されるパッチを決定するためにPMC114が利用または適用できる、複数のパッチ管理アルゴリズムが存在する。1つのパッチ管理アルゴリズムに従って、PMC114は、VMの各パッチを単一のエントリとして扱うことができ、例えば、保守時間ウィンドウの間にすべてのパッチを適用できない場合に、高い脆弱性スコアを有するパッチを優先することができ、コンテナ(例えば、ポッド)ごとのすべてのパッチを単一のエントリとして扱うことができ、オフラインでコンテナ・イメージにパッチが適用されるため、そのようなパッチを適用するための時間ならびにポッド内のすべてのリソースの起動時間および停止時間が一緒に組み合わされ得る。
VM(例えば、VM106)上の特定のアプリケーション・サーバにパッチを適用するためにリソースを停止して起動するための時間の例として、アプリケーション・サーバを停止するのに約2分かかり、パッチを適用するのに約1分かかり、パッチの適用後にアプリケーション・サーバを起動するのに約4分かかることがある。アプリケーション・サーバのリソースのための複数のパッチが存在する場合、PMC114は、これらのパッチを適用するためにアプリケーション・サーバを複数回停止して再起動する必要がないように、これらのパッチを単一のエントリに一緒に組み合わせることができる。アプリケーション・サーバのパッチが別々に考慮された場合、複数回の再起動を含めることによって、時間が過剰になる可能性がある(例えば、保守時間ウィンドウ内で使用可能な時間を超える可能性がある)。そのVMの再起動時間を、パッチを実行するための時間が0である別のエントリとして含めることができるということに注意する。
そのようなパッチ管理アルゴリズムに従って、各パッチは、コンテナ104、VM106、PM108、またはその他のリソース110を停止するための時間、コンテナ104、VM106、PM108、またはその他のリソース110を再起動するための時間、パッチを適用するために時間(コンテナ104の場合は、0であることができる)、パッチの重要性スコア(例えば、重要性または脆弱性スコア)、パッチに関連付けられたレプリカ数、およびパッチの種類、という属性を含むことができる。一部の実施形態では、パッチの重要性または脆弱性スコアを決定する(例えば、計算する)ときに、PMC114は、等比級数の和をコンテナに使用して重要性または脆弱性スコアを計算することができる。
等比級数の和に基づく式を使用してポッドの重要性スコアを決定する(例えば、計算する)例示的な非限定的例は、次のようなものであることができる。更新の各種類に関して、ポッドの更新の重要性または脆弱性スコア(例えば、高い重要性、中程度の重要性、または低い重要性)を決定する(例えば、計算する)ことを容易にするために、PMC114は、次の例示的な方程式を使用して更新のその種類の重要性または脆弱性スコア(例えば、個別の重要性または脆弱性スコア)を決定することができる。
ここで、xは重要性値(2=高、3=中、4=低)を有する更新の種類であることができ、nxはポッドに適用される特定の種類の更新の数であることができる。PMC114は、ポッドの異なる種類の更新に対して決定された個別の重要性または脆弱性スコアを合計することによって、ポッドのすべての更新に対して重要性または脆弱性スコアの合計(例えば、全体またはグループ)を決定することができる。例えば、ポッドには、x=2という高い重要性を有する2つの更新(例えば、パッチ)、およびx=3という中程度の重要性を有する4つの更新が存在することがある。PMC114は、高い重要性を有する更新の重要性または脆弱性スコアを[(1/2)
2+(1/2)
3]として決定することができ、中程度の重要性を有する更新の重要性または脆弱性スコアを[(1/3)
2+(1/3)
3+(1/3)
4+(1/3)
5]として決定することができ、ポッドの更新の重要性または脆弱性スコアの合計を[(1/2)
2+(1/2)
3]+[(1/3)
2+(1/3)
3+(1/3)
4+(1/3)
5]として決定することができる。コンテナまたはポッドのスコア、およびスコアの決定方法を決定するときに、多すぎるより低い重要性を有する更新(例えば、脆弱性のより低い更新またはパッチ)の合計が、高い重要性を有する更新の合計を圧倒しないようにするのが望ましいことがある。このパッチ管理アルゴリズム(および本明細書で開示されたその他のパッチ管理アルゴリズム)は、高い重要性を有する更新(例えば、高い重要性を有する更新の合計)が、より低い重要性を有する更新(例えば、相対的に多いより低い重要性を有する更新の合計)によって圧倒されないようにすることができる。
一部の実施形態では、PMC114は、定義されたパッチ管理基準に従って保守時間ウィンドウ内でワークロードに対して実行するためのパッチの望ましい(例えば、適切な、最適な、または少なくとも事実上最適な)サブセットを決定することを容易にするために、別のパッチ管理アルゴリズムを適用することができる。そのようなパッチ管理アルゴリズムは、適用するパッチの望ましいサブセット決定するために、動的プログラミング解決策を提供することができ、例えば次のように表され得る。
PMC114は、空の2次元配列K[(N+1)][(W+1)]を作成することができ、Nは、更新(例えば、パッチ)の総数であることができ、Wは、サービスがリブートされ得るウィンドウ(例えば、保守時間ウィンドウ)のサイズであることができる。PMC114は、この配列を初期化することができ、位置ごとに、この配列のK[i][j]は、i個の更新およびウィンドウ・サイズjを前提として、更新[1:i]のサブセット、およびウィンドウ・サイズjの最大累積スコアを与えることができる更新の推定完了時間を含むことができるマップと、ウィンドウ・サイズj内で達成可能な最大累積スコアと、この最大累積スコアを達成するための複数のスレッドにわたる更新の分布を含むことができるスレッド・マップと、というエントリを保持することができ、スレッド・マップは、(例えば、オンラインで実行され得る更新のための)「ライブ」と呼ばれる特殊なスレッドも含むことができる。解は、K[(N+1)][(W+1)]の位置のエントリであることができる。
Kを埋めること、および配列の各K[i][j]でK[(N+1)][(W+1)]を決定することに関して、PMC114は、初期最大スコアをK[i-1][j]のスコアに割り当てることができ、ポッドの最良のサブセットがK[i-1][j]でのサブセットに等しくなるように、かつスレッド・マップがK[i-1][j]のスレッド・マップに等しくなるように、初期化することができ、更新iを、K[i-1][l]に位置する更新のサブセットに追加できるかどうかをチェックすることができ、ここでlは、ウィンドウ・サイズjを超えない0~jであり、更新iを更新のサブセットに追加できる場合、追加された新しいポッド/コンテナのすべてのスコアをK[i-1][l]に加算し、その値を前の最大スコアと比較することができ、新しいポッド/コンテナのすべてのスコアをK[i-1][l]に加算することから取得されたスコアが、前の最大スコアより大きい場合、3つのエントリを更新することができ、PMC114がすべてのl:0~jを試みるまで、上記の動作の実行を継続することができる。PMC114は、最大スコア(例えば、最大または最高の脆弱性スコア)に関連付けられたパッチのサブセットを識別または決定することができる。
さらに、更新iを更新のサブセットに追加できるかどうかをチェックして決定することに関して、PMC114は、現在のポッド/コンテナの依存関係(例えば、ワークロードの複数の層のノード間の依存関係)のすべてのリストを取得または決定することができる。PMC114は、現在のポッド/コンテナのすべての依存関係にライブで(例えば、オンラインで)パッチを適用できるかどうかをチェック(例えば、分析、評価)して決定することができる。現在のポッド/コンテナのすべての依存関係にライブでパッチを適用できる場合、PMC114は、それらの依存関係をライブ・スレッドに追加し、スコア(例えば、脆弱性スコア)を更新することができる。現在のポッド/コンテナにライブでパッチを適用できないが、依存関係の一部にライブでパッチを適用できる場合、PMC114は、それらの依存関係をライブ・スレッドから除去し、そのような依存関係を、ライブでパッチを適用できない新しい依存関係として扱うことができる。各依存関係に関して、前の依存関係が終了した時間がスレッド内に存在しない場合、PMC114は、前の依存関係が終了した時間をスレッドに追加することができ、これによって、(例えば、欲張りスケジューリングに従って)前の依存関係が終了した後の最も早い依存関係を完了し、完了時間がjを超えていないかどうかチェックし、現在の依存関係のスコアを合計スコアに加算することができる。
特定の実施形態では、PMC114は、定義されたパッチ管理基準に従って、パッチのすべての可能なサブセットを列挙し、このリストから実行可能なサブセットをフィルタリングし、最高の累積スコアを有するパッチの実行可能なサブセットを決定することによって、パッチの望ましい(例えば、最も重要な)サブセットを決定することができる。保留中のパッチの総数がmである場合、サブセットの数は2mになることができる。
特定の実施形態では、PMC114は、定義されたパッチ管理基準に従って保守時間ウィンドウ内でワークロードに対して実行するためのパッチの望ましい(例えば、適切な、または最適な)サブセットを決定することを容易にするために、パッチ管理アルゴリズム(例えば、本明細書で開示されているようなアルゴリズム1(getOptimalSubset))を適用することができる。このパッチ管理アルゴリズム(例えば、アルゴリズム1)において使用される変数および関数の定義は、次を含むことができる:Wは、オフライン・ウィンドウのサイズであることができ、[p1,p2,p3,...pm]は、保留中のパッチのリストであることができ、保留中のパッチの総数はmであり、[(depsDict)]は、アプリケーションの依存関係ツリー(隣接リスト)であることができ、Kは、部分問題に対する解を保持できる2次元配列であることができ、scheduleCritは、最長クリティカル・パスを最初にスケジューリングすることによって、パッチの所定のリストをスケジューリングすることができ、scheduleGreedyは、欲張った先着順の方法でパッチの所定のリストをスケジューリングすることができ、schedPolicyは、欲張りまたはクリティカルのいずれかであることができる、スケジューリング・ポリシーであることができる。
パッチ管理アルゴリズムは、次のように表され得る。
このパッチ管理アルゴリズム(例えば、アルゴリズム1(getOptimalSubset))は、パッチを適用するための時間をパッチの重みと見なすことができ、パッチのスコアがパッチの値であることができ、合計オフライン・ウィンドウ・サイズを、ナップザックのサイズとして扱うことができるようなやり方で、パッチ選択をナップザックとしてモデル化することができる。このパッチ管理アルゴリズム(例えば、PMC114によって実装されるようなパッチ管理アルゴリズム)は、W分内で最も重要なパッチのパッチ適用を保証する、パッチのサブセットを決定することができる。このパッチ管理アルゴリズム(例えば、PMC114によって実装されるようなパッチ管理アルゴリズム)は、累積スコアを最大化するパッチの実行可能なサブセットを決定することを目的として、各パッチに重要性スコアを割り当てることができる。パッチ管理アルゴリズムは、同時のパッチの数に対する制限が存在する場合の事例に対処することができる。このパッチ管理アルゴリズム(例えば、PMC114によって実装されるようなパッチ管理アルゴリズム)は、依存制約に違反しないようなやり方で、許可された数のスレッドにわたってパッチをスケジューリングすることができ、例えば、サービスを停止してパッチを適用する前に、アプリケーションのサービスの依存関係をオフにすることができる。パッチの最適なスケジュールへの近接を検出するために、パッチ管理アルゴリズム(例えば、PMC114によって実装されるようなパッチ管理アルゴリズム)は、例えば、欲張りおよびクリティカル・パスなどの、複数の技術のうちの1つを使用することができる。欲張り法(scheduleGreedy)は、パッチ管理アルゴリズムの時間複雑さを低減することができ、現在のパッチを、すでに選択されたパッチのうちのパッチのスケジュールに単に適合させようとする。クリティカル・パス・スケジューリング(scheduleCrit)に関しては、すべての部分問題K「i」「j」に対して、クリティカル・パス・スケジューリング(例えば、PMC114によって実装されるクリティカル・パス・スケジューリング)は、常に最初にクリティカル・パスをスケジューリングし、その後、そのクリティカル・パスを保留中のパッチから除去することができる。クリティカル・パス・スケジューリング・プロセスは、スケジューリングするパッチが残っていない状態になるまで、またはすべてのスレッドが時間Wに関して占有されるまで、再帰的に繰り返され得る。
パッチ管理アルゴリズム(例えば、PMC114によって実装されるようなパッチ管理アルゴリズム)は、空の2次元配列K[(m+1)][(W+1)]を作成することができ、mは、更新(例えば、パッチ)の総数であることができ、Wは、サービスがリブートされ得るウィンドウ(例えば、保守時間ウィンドウ)のサイズであることができる。PMC114は、この配列を0に初期化することができ、位置ごとに、この配列のK[i][j]は、i個の更新およびウィンドウ・サイズjを前提として、更新[1:i]のサブセット、およびウィンドウ・サイズjの最大累積スコアを与えることができる更新の推定完了時間を含むことができるマップと、ウィンドウ・サイズj内で達成可能な最大累積スコアと、この最大累積スコアを達成するための複数のスレッドにわたる更新の分布を含むことができるスレッド・マップと、というエントリを保持することができる。解は、K[(m+1)][(W+1)]の位置のエントリであることができる。
Kを埋めること、および配列の各K[i][j]でK[(m+1)][(W+1)]を決定することに関して、PMC114は、初期最大スコアをK[i-1][pw]のスコアに割り当てることができ、ポッドの最良のサブセットがK[i-1][j]でのサブセットに等しくなるように、かつスレッド・マップがK[i-1][j]のスレッド・マップに等しくなるように、初期化することができ、更新iを、K[i-1][pw]に位置する更新のサブセットに追加できるかどうかをチェックすることができ、ここでpwは、ウィンドウ・サイズjを超えない0~jである。この、更新iを追加できるかどうかをチェックすることは、欲張りアルゴリズムまたはクリティカル・パス・ファースト・アルゴリズム(critical path first algorithm)を使用して実行され得る。更新iを更新のサブセットに追加できる場合、PMC114は、追加された新しいポッド/コンテナのすべてのスコアをK[i-1][pw]に加算し、この値を前の最大スコアと比較することができ、新しいポッド/コンテナのすべてのスコアをK[i-1][l]に加算することから取得されたスコアが前の最大スコアよりも大きい場合、PMC114は3つのエントリを更新することができ、PMC114は、PMC114がすべてのpw:0~jを試みるまで、上記の動作の実行を継続することができる。PMC114は、最大スコア(例えば、最大または最高の脆弱性スコア)に関連付けられたパッチのサブセットを識別または決定することができる。
各依存関係に関して、前の依存関係が終了した時間がスレッド内に存在しない場合、PMC114は、前の依存関係が終了した時間をスレッドに追加することができ、これによって、(例えば、欲張りスケジューリングまたはクリティカル・パス・スケジューリングに従って)前の依存関係が終了した後の最も早い依存関係を完了し、完了時間がjを超えていないかどうかチェックし、現在の依存関係のスコアを合計スコアに加算することができる。
特定の実施形態では、同時のパッチ(スレッド)に対する制限がない場合、PMC114は、さらに別のパッチ管理アルゴリズムを適用することができる。この場合、ジョブのスケジューリングおよび分割の問題を解決する必要がない。コンテナにデプロイされるサービスごとに、PMC114は、コンテナに対するオフラインのパッチ適用の合計時間が、適用されるパッチに依存しないため、所定の保守時間ウィンドウ内で、依存関係と共にサービスを再起動できるかどうかを単にチェックすることができる。コンテナに対してパッチを適用し、このコンテナに依存しているものを再起動するための時間が、ウィンドウ・サイズWよりも小さい場合、保守時間ウィンドウ(例えば、オフライン・ウィンドウ)の間に、このコンテナにパッチを適用することができる。VMの場合、オフラインのパッチ適用時間は、適用されるパッチに依存することがある。このことが同時のパッチに対する制限にならないため、VMごとに、PMC114は、別々のナップザック・アルゴリズムを実行または実装し、所定の時間内に適用され得るパッチの最適なサブセットを決定して選択することができる。VMのこの別々のナップザック問題ごとに、PMC114は、本明細書で開示されているように、依存しているものを再起動するための時間を考慮することもできる。
図6は、開示される対象のさまざまな態様および実施形態に従って、例示的なPMC600のブロック図を示している。PMC600は、本明細書においてさらに詳細に説明されるように、各コンポーネント(例えば、それぞれ名前が付けられたコンポーネント)とそれぞれ同じもしくは類似することができるか、または各コンポーネントと同じもしくは類似する機能を含むことができる、パッチ識別コンポーネント602およびパッチ実行コンポーネント604を備えることができる。
PMC600は、PMC600に関連付けられた動作を制御する(例えば、管理する)ことができる動作管理コンポーネント606を含むことができる。例えば、動作管理コンポーネント606は、定義されたパッチ管理基準、定義されたパッチ管理アルゴリズム(例えば、本明細書に記載された方法、システム、および技術によって本明細書において開示されたか、定義されたか、列挙されたか、具現化されたか、または示されたパッチ管理アルゴリズム)に従って、PMC600のコンポーネントに動作を実行させるための命令を生成することを容易にすることができ、命令に少なくとも部分的に基づいてPMC600のコンポーネントによる動作の実行を容易にするために、命令をPMC600のコンポーネント(例えば、パッチ識別コンポーネント602、パッチ実行コンポーネント604など、プロセッサ・コンポーネント618、データ・ストア620など)に通信することができる。動作管理コンポーネント606は、PMC600のコンポーネント間のデータ・フローを制御すること、およびPMC600と、PMC600に関連付けられた(例えば、接続された)別のコンポーネントまたはデバイス(例えば、コンピュータ、ラップトップ・コンピュータ、またはその他の種類のコンピューティング・デバイスもしくは通信デバイス)との間のデータ・フローを制御することを、容易にすることもできる。
PMC600は、例えば、トポロジー識別コンポーネント608、スコア決定コンポーネント610、パッチ選択コンポーネント612、妥当性確認コンポーネント614、および復元コンポーネント616を備えることもできる。トポロジー識別コンポーネント608は、コンピューティング・システムに関連付けられたワークロード(例えば、ハイブリッド・クラウドベースのコンピューティング・システムに関連付けられたハイブリッド・ワークロード)のトポロジーを決定または識別することができる。ワークロードのトポロジーを決定することの一部として、トポロジー識別コンポーネント608は、ワークロードの依存関係ツリーを決定することを容易にするため、および保守時間ウィンドウの間にどのパッチを適用するかを効率的に決定し、パッチが適用される(例えば、オフラインでパッチが第1のワークロード部分に対して実行される)順序を決定し、保守時間ウィンドウの間にワークロードの少なくとも望ましい一部にパッチを適用することを容易にするために、ワークロードに関連付けられたノードまたはリソース間の依存関係を決定または識別することができる。
スコア決定コンポーネント610は、定義されたパッチ管理基準および関連する適用可能なパッチ管理アルゴリズムに従って、パッチの脆弱性および重要性のレベル(例えば、高レベル、中レベル、または低レベルの脆弱性)の分析の結果に少なくとも部分的に基づいて、ワークロードに関連付けられたパッチの、パッチ関連のスコア(例えば、ワークロードに関連付けられたパッチの脆弱性、重要性、またはリスクのスコア、あるいはワークロードに関連付けられたパッチのサブセットの全体的な、累積した、またはグループの脆弱性、重要性、またはリスクのスコア)を決定することができる。例えば、スコア決定コンポーネント610は、例えば本明細書に記載されたパッチ管理アルゴリズムなどの、望ましいパッチ管理アルゴリズムを利用して、ワークロードに関連付けられた、パッチの脆弱性スコアまたはパッチのサブセット(例えば、異なるグループ)のグループ脆弱性スコアを決定することを容易にすることができる。
パッチ選択コンポーネント612は、定義されたパッチ管理基準に従って、ワークロードに関連付けられたパッチに対して決定されたパッチ関連のスコア、あるいはワークロードに関連付けられたパッチのサブセットの全体的な、または累積したパッチ関連のスコアに少なくとも部分的に基づいて、保守時間ウィンドウの間に実行するために、ワークロードに関連付けられたパッチのセットから、パッチのサブセットを選択または決定することができ、ワークロードの第1のワークロード部分がオフラインであるときに、パッチのサブセットの少なくとも一部が適用され、ワークロードの第2のワークロード部分がオンラインであるときに、パッチのサブセットの別の一部が適用され得る。例えば、パッチ選択コンポーネント612は、適用可能なパッチ管理アルゴリズムに従って、ワークロードに関連付けられたパッチのサブセットが、ワークロードに関連付けられたパッチの他のサブセットの他のグループの、全体的な、または累積したパッチ関連のスコアと比較して最高のグループの、全体的な、または累積したパッチ関連のスコアを有しているということの決定に少なくとも部分的に基づいて、保守時間ウィンドウの間に実行するために、ワークロードに関連付けられたパッチのセットから、パッチのサブセットを選択または決定することができる。
妥当性確認コンポーネント614は、第1のワークロード部分に関連付けられたリソース、ノード、またはアプリケーションなどがオフラインであるときに、保守時間ウィンドウの間に、第1のワークロード部分または第2のワークロード部分に適用されたパッチを分析するか、あるいは第1のワークロード部分または第2のワークロード部分に関連付けられたリソース、ノード、アプリケーション、またはデータなどを分析し、パッチが適用された後に、第1のワークロード部分または第2のワークロード部分に関連付けられたパッチ、あるいはリソース、ノード、アプリケーション、またはデータなどが適切に機能している(例えば、Webサーバが適切に機能している、アプリケーション・サーバが適切に機能している、データベースが、データベースに復元されたデータを含めて適切に機能している、およびノードが適切に機能している)かどうかを決定すること、および妥当性を確認する(例えば、検証する)ことができる。妥当性確認コンポーネント614が、パッチの妥当性が確認されない(例えば、パッチまたは関連するリソース、ノード、アプリケーションなどが、定義されたパッチ管理基準に従って適切に機能していない)ということを決定した場合、妥当性確認コンポーネント614は、そのようなパッチの妥当性が確認されないということを示すことができる指標(例えば、妥当性未確認指標)を生成し、提示することができる。
復元コンポーネント616は、パッチの妥当性が確認されないということの決定に応答して、保守時間ウィンドウの間にパッチを取り消し(例えば、元に戻し)、ワークロードのアイテム(例えば、リソース、ノード、アプリケーション、またはデータなど)をパッチが実行される前の状態に戻すことができる。例えば、保守時間ウィンドウの間に、復元コンポーネント616は、パッチの妥当性が確認されないということを示すことができる、パッチに関連する無効指標を受信することができる。無効指標を受信したことに応答して、復元コンポーネント616は、保守時間ウィンドウ内でパッチを取り消し、ワークロードのアイテム(例えば、リソース、ノード、アプリケーション、またはデータなど)を、パッチがワークロードのアイテムに適用される前のワークロードのアイテムの状態に戻すことができる。
プロセッサ・コンポーネント618は、他のコンポーネント(例えば、パッチ識別コンポーネント602、パッチ実行コンポーネント604、動作管理コンポーネント606など、またはデータ・ストア620など)と連動して機能し、PMC600のさまざまな機能の実行を容易にすることができる。プロセッサ・コンポーネント618は、本明細書でさらに詳細に開示されているようなPMC600の動作を容易にし、PMC600と、PMC600に関連付けられた(例えば、接続された)他のコンポーネント(例えば、コンピュータ、ラップトップ・コンピュータ、またはその他のコンピューティング・デバイスもしくは通信デバイス)の間のデータ・フローを制御するために、ワークロード、アプリケーション、オペレーティング・システム、ミドルウェア、VM、PM、コンテナ、リソース、ノード、定義されたパッチ管理基準、定義されたパッチ管理アルゴリズム、トラフィック・フロー、ポリシー、プロトコル、インターフェイス、ツール、またはその他の情報に関連付けられた、パッチ、ワークロード、クラウドコンピューティング環境、脆弱性スコア、ノード間の依存関係、リソースなどに関連する情報などのデータを処理できる、1つまたは複数のプロセッサ、マイクロプロセッサ、またはコントローラを採用することができる。
データ・ストア620は、PMC600に関連付けられた動作の制御を容易にするために、データ構造(例えば、ユーザ・データ、メタデータ)、コード構造(例えば、モジュール、オブジェクト、ハッシュ、クラス、プロシージャ)、または命令、ワークロード、アプリケーション、オペレーティング・システム、ミドルウェア、VM、PM、コンテナ、リソース、ノード、定義されたパッチ管理基準、定義されたパッチ管理アルゴリズム、トラフィック・フロー、ポリシー、プロトコル、インターフェイス、ツール、またはその他の情報に関連付けられた、パッチ、ワークロード、クラウドコンピューティング環境、脆弱性スコア、ノード間の依存関係、リソースなどに関連する情報を格納することができる。1つの態様では、プロセッサ・コンポーネント622は、動作することが望まれる情報を格納して取り出すため、あるいは少なくとも部分的に機能をパッチ識別コンポーネント602、パッチ実行コンポーネント604、動作管理コンポーネント606、もしくはデータ・ストア620など、またはPMC600の実質的に任意のその他の動作可能な態様に提供するために、(例えば、メモリ・バスを介して)データ・ストア624に機能的に結合され得る。
システムまたはデバイスは、本明細書では複数のコンポーネント間の相互作用に関して説明された(または説明される)。そのようなシステムおよびコンポーネントが、それらのコンポーネントもしくはそれらの内部で指定されたサブコンポーネント、指定されたコンポーネントもしくはサブコンポーネントの一部、または追加のコンポーネントを含むことができるということが、認識されるべきである。サブコンポーネントは、親コンポーネント内に含まれるのではなく、他のコンポーネントに通信によって結合されたコンポーネントとして実装することもできる。さらに、1つまたは複数のコンポーネントまたはサブコンポーネントは、集合的機能を提供する単一のコンポーネントに組み合わされてよい。コンポーネントは、簡潔にするために本明細書では具体的に説明されないが、当業者によって知られている1つまたは複数の他のコンポーネントと、相互作用してもよい。
図7は、開示される対象のさまざまな態様および実施形態に従って、コンピューティング・プラットフォームに関連付けられたパッチを管理するための例示的な非限定的方法700のフロー図を示している。方法700は、例えば、パッチ識別コンポーネント、PMC、パッチ実行コンポーネント、またはプロセッサ・コンポーネントを備えるか、あるいはこれらのコンポーネントに動作可能なように結合されたシステムによって、実行され得る。本明細書に記載された他の実施形態で採用されている類似する要素の説明の繰り返しは、簡潔にするために省略されているか、または省略されてよい。
702で、コンピューティング・プラットフォームに関連付けられたワークロードを決定することができ、このワークロードは、パッチの第1のサブセットが実行され得る第1のワークロード部分を含むことができる。パッチ識別コンポーネントまたはPMCは、ワークロード(例えば、ハイブリッド・ワークロード)を識別または決定することができ、保守時間ウィンドウの間に、コンピューティング・プラットフォーム(例えば、ハイブリッド・クラウド・コンピューティング環境)の第1のワークロード部分がオフラインであるときにパッチの第1のサブセットを実行できる第1のワークロード部分(例えば、適用可能なリソース、ノード、またはアプリケーションなど)を識別することができ、第2のワークロード部分がオンラインであるときにパッチの第2のサブセットを実行できる第2のワークロード部分を識別または決定することもできる。
704で、第1のワークロード部分に関連付けられたパッチの第1のサブセットのパッチの脆弱性スコアに少なくとも部分的に基づいて、保守時間ウィンドウ内で第1のワークロード部分の一部に適用するためのパッチの第3のサブセットを決定することができ、パッチの第1のサブセットはパッチの第3のサブセットを含むことができる。PMCは、第1のワークロード部分に関連付けられたパッチの第1のサブセットのパッチの脆弱性スコアに少なくとも部分的に基づいて、コンピューティング・プラットフォームまたはコンピューティング・プラットフォームの適用可能な一部がオフラインであるときに、保守時間ウィンドウ内で第1のワークロード部分の一部(例えば、パーツ)に適用するためのパッチの第3のサブセットを決定することができる。例えば、PMCは、保守時間ウィンドウの間に第1のワークロード部分内のパッチのすべてを実行するための十分な時間が、保守時間ウィンドウの間に存在しないということを、決定することができる。PMCは、第1のワークロード部分に関連付けられたパッチの第1のサブセットのパッチの脆弱性スコアを少なくとも決定することができる。パッチの脆弱性スコアに少なくとも部分的に基づいて、PMCは、保守時間ウィンドウ内で第1のワークロード部分の一部に適用するためのパッチの第3のサブセットを、パッチの第1のサブセットから決定することができる。パッチの第3のサブセット内のパッチの少なくとも一部は、パッチの第3のサブセットに含めるようにPMCによって選択されなかったパッチの第1のサブセットの他のパッチよりも相対的に高い脆弱性スコアを有することができる。
図8は、開示される対象のさまざまな態様および実施形態に従って、コンピューティング・プラットフォームに関連付けられたパッチを管理するための別の例示的な非限定的方法800のフロー図を示している。方法800は、例えば、パッチ識別コンポーネント、PMC、パッチ実行コンポーネント、またはプロセッサ・コンポーネントを備えるか、あるいはこれらのコンポーネントに動作可能なように結合されたシステムによって、実行され得る。本明細書に記載された他の実施形態で採用されている類似する要素の説明の繰り返しは、簡潔にするために省略されているか、または省略されてよい。
802で、リソース間のワークロードの依存関係を決定することを容易にするために、リソースに関連付けられた要求に関してネットワークを監視することができる。PMCは、リソース間のワークロードの依存関係を決定することを容易にするために、リソース(例えば、コンテナ、VM、PM、その他のリソース、またはノード)に関連付けられた要求に関してネットワーク(例えば、コンピューティング・ネットワークまたは通信ネットワーク)を監視することができ、ワークロードの依存関係は、第1の種類のアイテム(例えば、ノード)と別の種類のアイテム(例えば、VMまたはPM)の間に存在することがあり、または同じ種類のアイテム(例えば、第1のVMおよび第2のVM)間に存在することがある。
804で、要求に関するネットワークの監視に少なくとも部分的に基づいて、リソース間のワークロードの依存関係を決定できる。PMCは、本明細書において説明されているように、要求に関してネットワークを監視することに少なくとも部分的に基づいて、またはそのようなワークロードの依存関係を決定する他の手段によって、リソース間のワークロードの依存関係を決定することができる。一部の実施形態では、PMCは、本明細書において説明されているように、要求に関してネットワークを監視することに少なくとも部分的に基づいて、ネットワークのトポロジーまたは依存関係ツリーを決定または識別することができる。
806で、ワークロードの依存関係に少なくとも部分的に基づいて、オフラインである間にパッチの第1のサブセットによってパッチを適用するための第1のワークロード部分、およびオンラインである間にパッチの第2のサブセットによってパッチを適用するための第2のワークロード部分を含んでいるワークロードを決定することができる。PMCは、ワークロードに関連付けられた依存関係に少なくとも部分的に基づいて、ワークロードを決定することができる。ワークロードは、(例えば、ワークロードのアイテムのワークロードの依存関係に少なくとも部分的に起因して)オフラインであるときにパッチの第1のサブセットによってパッチが適用されるワークロードのアイテムまたはリソース(例えば、コンテナ、VM、PM、その他のリソース、ノードなど)であることができる第1のワークロード部分、およびオンラインであるときにパッチの第2のサブセットによってパッチが適用され得る第2のワークロード部分を含むことができる。
808で、少なくとも、第1のワークロード部分に関連付けられたパッチの第1のサブセットのパッチの脆弱性スコアを決定することができる。PMCは、少なくとも、ワークロードの第1のワークロード部分に対して実行されるパッチの第1のサブセットのパッチの脆弱性スコアを決定する(例えば、計算する)ことができる。一部の実施形態では、PMCは、パッチの第2のサブセットのパッチの脆弱性スコアを決定することもできる。
810で、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、パッチの脆弱性スコアおよび保守時間ウィンドウに少なくとも部分的に基づいて、第1のワークロード部分に関連付けられたパッチの第1のサブセットから、第1のワークロード部分の一部に対するパッチの第3のサブセットを決定することができる。PMCは、本明細書においてさらに詳細に説明されるように、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、パッチの脆弱性スコアおよび保守時間ウィンドウに少なくとも部分的に基づいて、第1のワークロード部分に関連付けられたパッチの第1のサブセットから、第1のワークロード部分の一部(例えば、コンテナ、VM、PM、その他のリソース、またはノードなどのサブセット)に適用され得るパッチの第3のサブセットを決定することができる。
812で、第1のワークロード部分の一部に関連付けられたリソース、ノードなどがオフラインであるときに、保守時間ウィンドウの間に第1のワークロード部分の一部に対してパッチの第3のサブセットを実行することができる。パッチ実行コンポーネントは、第1のワークロード部分の一部の、または第1のワークロード部分の一部に関連付けられた、リソース、ノード、アプリケーションなどがオフラインであるときに、保守時間ウィンドウの間に第1のワークロード部分の一部に対してパッチの第3のサブセットを実行する(例えば、適用する)ことができる。一部の実施形態では、PMCは、ネットワークのトポロジーに従って、トポロジー的順序でパッチの第3のサブセットのパッチを実行することができる。特定の実施形態では、パッチ実行コンポーネントは、使用可能な保守時間ウィンドウ内で、第1のワークロード部分の一部の、依存関係を有するアイテムを含む複数のアイテム(例えば、コンテナ、VM、PM、その他のリソース、またはノードなど)に対して、パッチの第3のサブセットのパッチを同時に(例えば、並列に)実行することができる。PMCおよびパッチ実行コンポーネントは、パッチの第3のサブセットの実行を容易にするためのパッチ適用プロセスを実行することができ、このパッチ適用プロセスは、本明細書においてさらに詳細に説明されるように、第1のワークロード部分の一部に関連付けられたリソースを停止することおよび再起動すること、ならびにパッチの第3のサブセットに関連付けられたノードをリブートすることを含むことができる。
814で、保守時間ウィンドウの間に第1のワークロード部分の一部のパッチ適用の妥当性を確認することができる。PMCは、パッチが適切に適用されたことを保証し、そのようなパッチが適用された後に、パッチ、ならびに第1のワークロード部分の一部の各アイテム、およびコンピューティング・システム全体が適切に機能していることを保証するのを容易にするために、保守時間ウィンドウ内で第1のワークロード部分の一部のパッチ適用の妥当性を確認することができる。
816で、第1のワークロード部分の一部のワークロードのアイテムに対するパッチの妥当性を確認できないということが決定された場合、保守時間ウィンドウ内でこのワークロードのアイテムに対するパッチを取り消し、ワークロードのアイテムをパッチ適用前の状態に戻すことができる。PMCは、ワークロードのアイテム(例えば、コンテナ、VM、PM、その他のリソース、またはノードなど)に対するパッチの妥当性が確認されたかどうかを決定することができる。ワークロードのアイテムに対するパッチの妥当性を確認できないということの決定に応答して、PMCまたはパッチ実行コンポーネントは、保守時間ウィンドウ内でワークロードのアイテムに対するパッチを取り消し、ワークロードのアイテムをパッチ適用前の状態に戻すことができる。
818で、第2のワークロード部分に対してパッチの第2のサブセットを実行することができる。パッチ実行コンポーネントは、第2のワークロード部分に対してパッチの第2のサブセットを実行することができ、パッチの第2のサブセットは、少なくとも第2のワークロード部分がオンラインであるときに実行することができ、あるいは保守時間ウィンドウの間に、または保守時間ウィンドウの外側で実行することができる。特定の実施形態では、パッチ実行コンポーネントは、パッチの第2のサブセットのパッチの少なくとも一部を、第2のワークロード部分に対して同時に(例えば、並列に)実行することができ、保守時間ウィンドウの間に、パッチの第3のサブセットのパッチの一部が第1のワークロード部分の一部に対して実行される。
PMCは、パッチが適切に適用されたことを保証し、そのようなパッチが適用された後に、パッチ、ならびに第2のワークロード部分の一部の各アイテム、およびコンピューティング・システム全体が適切に機能していることを保証するのを容易にするために、第2のワークロード部分に対して実行されたパッチの妥当性を確認することもできる。PMCは、ワークロードのアイテムに対する特定のパッチの妥当性が確認されたかどうかを決定することができる。ワークロードのアイテムに対する特定のパッチの妥当性を確認できないということの決定に応答して、PMCまたはパッチ実行コンポーネントは、ワークロードのアイテムに対するパッチを取り消し、ワークロードのアイテムをパッチ適用前の状態に戻すことができる。
説明を簡単にするために、一連の動作として方法またはコンピュータ実装方法が示され、説明される。開示される対象が、示された動作によって、または動作の順序によって制限されず、例えば動作が、本明細書において提示されておらず、説明されていない他の動作と共に、さまざまな順序で、または同時に発生できるということが、理解され認識されるべきである。さらに、開示される対象に従ってコンピュータ実装方法を実装するために、示されているすべての動作が必要でなくてもよい。加えて、当業者は、コンピュータ実装方法が、代替として、状態図を介して相互に関連する一連の状態またはイベントとして表され得るということを理解し認識するであろう。そのようなコンピュータ実装方法をコンピュータに輸送または転送するのを容易にするために、以下および本明細書全体を通じて開示されたコンピュータ実装方法を製品に格納できるということが、さらに認識されるべきである。製品という用語は、本明細書において使用されるとき、任意のコンピュータ可読デバイスまたはコンピュータ可読ストレージ媒体からアクセスできるコンピュータ・プログラムを包含するよう意図されている。
開示される対象のさまざまな態様の背景を提供するために、図9および以下の説明は、開示される対象のさまざまな態様が実装され得る適切な環境の概要を示すよう意図されている。図9は、本明細書に記載された1つまたは複数の実施形態を容易にすることができる例示的な非限定的動作環境のブロック図を示している。本明細書に記載された他の実施形態で採用されている類似する要素の説明の繰り返しは、簡潔にするために省略されているか、または省略されてよい。図9を参照すると、本開示のさまざまな態様を実装するための適切な動作環境900は、コンピュータ912を含むこともできる。コンピュータ912は、処理ユニット914、システム・メモリ916、およびシステム・バス918を含むこともできる。システム・バス918は、システム・メモリ916を含むが、これに限定されないシステム・コンポーネントを、処理ユニット914に結合する。処理ユニット914は、さまざまな使用可能なプロセッサのいずれかであることができる。デュアル・マイクロプロセッサおよびその他のマルチプロセッサ・アーキテクチャが、処理ユニット914として採用されてもよい。システム・バス918は、ISA(Industry Standard Architecture)、MCA(Micro Channel Architecture)、EISA(Extended ISA)、IDE(Intelligent Drive Electronics)、VESAローカル・バス(VLB:VESA Local Bus)、PCI(Peripheral Component Interconnects)、カード・バス、ユニバーサル・シリアル・バス(USB:Universal Serial Bus)、AGP(Advanced Graphics Port)、FireWire(IEEE 1394)、および小型コンピュータ・システム・インターフェイス(SCSI:Small Computer Systems Interface)を含むが、これらに限定されない、任意のさまざまな使用可能なバス・アーキテクチャを使用する、メモリ・バスもしくはメモリ・コントローラ、ペリフェラル・バスもしくは外部バス、またはローカル・バスを含む、複数の種類のバス構造のいずれかであることができる。システム・メモリ916は、揮発性メモリ920および不揮発性メモリ922を含むこともできる。起動中などにコンピュータ912内の要素間で情報を転送するための基本ルーチンを含んでいる基本入出力システム(BIOS:basic input/output system)が、不揮発性メモリ922に格納される。不揮発性メモリ922の例としては、読み取り専用メモリ(ROM:read only memory)、プログラマブルROM(PROM:programmable ROM)、電気的プログラマブルROM(EPROM:electrically programmable ROM)、電気的消去可能プログラマブルROM(EEPROM(登録商標):electrically erasable programmable ROM)、フラッシュ・メモリ、または不揮発性ランダム・アクセス・メモリ(RAM:random access memory)(例えば、強誘電体RAM(FeRAM:ferroelectric RAM))が挙げられるが、これらに限定されない。揮発性メモリ920は、外部キャッシュ・メモリとして機能するランダム・アクセス・メモリ(RAM)を含むこともできる。例えばRAMは、スタティックRAM(SRAM:static RAM)、ダイナミックRAM(DRAM:dynamic RAM)、シンクロナスDRAM(SDRAM:synchronous DRAM)、ダブル・データ・レートSDRAM(DDR SDRAM:double data rate SDRAM)、拡張SDRAM(ESDRAM:enhanced SDRAM)、シンクリンクDRAM(SLDRAM:Synchlink DRAM)、ダイレクト・ラムバスRAM(DRRAM:direct Rambus RAM)、ダイレクト・ラムバス・ダイナミックRAM(DRDRAM:direct Rambus dynamic RAM)、およびラムバス・ダイナミックRAM(RDRAM:Rambus dynamic RAM)などの、ただしこれらに限定されない、多くの形態で利用可能である。
コンピュータ912は、取り外し可能/取り外し不可能な揮発性/不揮発性のコンピュータ・ストレージ媒体を含むこともできる。例えば図9は、ディスク・ストレージ924を示している。ディスク・ストレージ924は、磁気ディスク・ドライブ、フロッピー(登録商標)・ディスク・ドライブ、テープ・ドライブ、Jazドライブ、Zipドライブ、LS-100ドライブ、フラッシュ・メモリ・カード、またはメモリ・スティック(登録商標)などの、ただしこれらに限定されない、デバイスを含むこともできる。ディスク・ストレージ924は、コンパクト・ディスクROMデバイス(CD-ROM:compact disk ROM device)、記録可能CDドライブ(CD-Rドライブ:CD recordable drive)、再書き込み可能CDドライブ(CD-RWドライブ:CD rewritable drive)、またはデジタル多用途ディスクROMドライブ(DVD-ROM:digital versatile disk ROM drive)などの光ディスク・ドライブを含むが、これらに限定されないストレージ媒体を、別々に、または他のストレージ媒体と組み合わせて、含むこともできる。システム・バス918へのディスク・ストレージ924の接続を容易にするために、インターフェイス926などの、取り外し可能または取り外し不可能なインターフェイスが通常は使用される。図9は、ユーザと、適切な動作環境900において説明された基本的なコンピュータ・リソースとの間の仲介として機能するソフトウェアも示している。そのようなソフトウェアは、例えば、オペレーティング・システム928を含むこともできる。ディスク・ストレージ924に格納できるオペレーティング・システム928は、コンピュータ912のリソースを制御し、割り当てるように動作する。システムのアプリケーション930は、例えばシステム・メモリ916またはディスク・ストレージ924のいずれかに格納されたプログラム・モジュール932およびプログラム・データ934を介して、オペレーティング・システム928によるリソースの管理を利用する。さまざまなオペレーティング・システムまたはオペレーティング・システムの組み合わせを使用して本開示が実装され得るということが、認識されるべきである。ユーザは、入力デバイス936を介して、コマンドまたは情報をコンピュータ912に入力する。入力デバイス936は、マウス、トラックボール、スタイラス、タッチ・パッド、キーボード、マイクロホン、ジョイスティック、ゲーム・パッド、衛星放送受信アンテナ、スキャナ、TVチューナー・カード、デジタル・カメラ、デジタル・ビデオ・カメラ、Webカメラなどのポインティング・デバイスを含むが、これらに限定されない。これらおよびその他の入力デバイスは、インターフェイス・ポート938を介してシステム・バス918を通り、処理ユニット914に接続する。インターフェイス・ポート938は、例えば、シリアル・ポート、パラレル・ポート、ゲーム・ポート、およびユニバーサル・シリアル・バス(USB)を含む。出力デバイス940は、入力デバイス936と同じ種類のポートの一部を使用する。このようにして、例えば、USBポートを使用して、入力をコンピュータ912に提供し、コンピュータ912から出力デバイス940に情報を出力できる。出力アダプタ942は、特殊なアダプタを必要とする出力デバイス940の中でも特に、モニタ、スピーカ、およびプリンタのような何らかの出力デバイス940が存在することを示すために提供される。出力アダプタ942の例としては、出力デバイス940とシステム・バス918の間の接続の方法を提供するビデオ・カードおよびサウンド・カードが挙げられるが、これらに限定されない。リモート・コンピュータ944などの、その他のデバイスまたはデバイスのシステムが、入力機能および出力機能の両方を提供するということに、注意するべきである。
コンピュータ912は、リモート・コンピュータ944などの1つまたは複数のリモート・コンピュータへの論理接続を使用して、ネットワーク環境内で動作できる。リモート・コンピュータ944は、コンピュータ、サーバ、ルータ、ネットワークPC、ワークステーション、マイクロプロセッサベースの機器、ピア・デバイス、またはその他の一般的なネットワーク・ノードなどであることができ、通常は、コンピュータ912に関連して説明された要素の多くまたはすべてを含むこともできる。簡潔にするために、メモリ・ストレージ・デバイス946のみが、リモート・コンピュータ944と共に示されている。リモート・コンピュータ944は、ネットワーク・インターフェイス948を介してコンピュータ912に論理的に接続されてから、通信接続950を介して物理的に接続される。ネットワーク・インターフェイス948は、ローカル・エリア・ネットワーク(LAN:local-area network)、広域ネットワーク(WAN:wide-area network)、セルラー・ネットワークなどの、有線通信ネットワークまたは無線通信ネットワークを包含する。LAN技術は、光ファイバ分散データ・インターフェイス(FDDI:Fiber Distributed Data Interface)、銅線分散データ・インターフェイス(CDDI:Copper Distributed Data Interface)、イーサネット(登録商標)、トークン・リングなどを含む。WAN技術は、ポイントツーポイント・リンク、総合デジタル通信網(ISDN:Integrated Services Digital Network)およびその変形などの回路交換網、パケット交換網、およびデジタル加入者回線(DSL:Digital Subscriber Line)を含むが、これらに限定されない。通信接続950は、ネットワーク・インターフェイス948をシステム・バス918に接続するために採用されたハードウェア/ソフトウェアのことを指す。通信接続950は、説明を明確にするために、コンピュータ912内に示されているが、コンピュータ912の外部に存在することもできる。ネットワーク・インターフェイス948に接続するためのハードウェア/ソフトウェアは、単に例示の目的で、通常の電話の等級のモデム、ケーブル・モデム、およびDSLモデムを含むモデム、ISDNアダプタ、ならびにイーサネット(登録商標)・カードなどの、内部および外部の技術を含むこともできる。