JP2011076370A

JP2011076370A - デプロイシステム

Info

Publication number: JP2011076370A
Application number: JP2009227203A
Authority: JP
Inventors: Yoshimitsu Aoyanagi; 慶光青柳
Original assignee: Hitachi Solutions Ltd
Current assignee: Hitachi Solutions Ltd
Priority date: 2009-09-30
Filing date: 2009-09-30
Publication date: 2011-04-14

Abstract

【課題】複数の異なるサーバ環境に対するセキュリティパッチ適用、ソフトウェアのデプロイを一括、高速に行なうことができるデプロイシステム及びデプロイ方法を提供すること。
【解決手段】個々のサーバ環境に対応したＯＳのディスクイメージファイルを専用の更新サーバのボリュームとしてマウントする起動手段と、セキュリティパッチの適用やソフトウェアのデプロイ処理を実行する更新手段と、更新手段からのＩ／Ｏアクセス要求を選択的に振り分けるアクセス管理手段からなるデプロイシステムにおいて、更新手段が過去の更新の履歴を管理するリポジトリにアクセスする際、どのサーバに対する更新を実行しているか判断し、適切なＯＳのディスクイメージファイルをマウントしたボリュームにＩ／Ｏアクセスを振り分ける第１の手段と、ＯＳのディスクイメージファイルを前記専用の更新サーバのボリュームとしてマウントする第２の手段とを備えることを特徴とする。
【選択図】図１

Description

本発明は、不特定多数のオペレーティングシステム（以下、OS）やアプリケーションのセキュリティパッチの更新やソフトウェアのデプロイ（deploy）を行なう際のＯＳ起動時のオーバヘッドを削減するデプロイシステムに関する。

仮想化技術の普及により、様々な組織で稼動するサーバの台数は爆発的に増加している。これに伴い、ＯＳやアプリケーションのセキュリティパッチの適用、ソフトウェアのデプロイにかかわる時間、作業量も増大している。
従来、サーバシステムにオペレーティングシステム等のソフトウェアを高速にデプロイする方法に関して、下記特許文献１に記載の技術が知られている。
下記特許文献１に記載のものは、ディスクイメージを記憶する論理ディスクを有するストレージ装置と、ストレージネットワークを介して前記ストレージ装置に接続する複数のサーバとを備えるサーバシステムにおけるデプロイ方法であって、デプロイ管理機構が、デプロイの指令を受ける以前に、前記ディスクイメージを記憶する論理ディスクを前記ストレージ装置の空き領域に複製する処理を含むことを特徴とするものである。

特開２００６−１６３８８５号公報

しかしながら、上記特許文献１に記載の技術は、現在稼働中のＯＳを記憶するハードディスクをバックアップし、次に、ＯＳを記憶するハードディスクから固有情報を抜いてマスタディスクを作成し、作成したマスタディスクを別のディスクへ複製する、イメージコピーによるデプロイに特化した技術である。同一のサーバ環境を多数複製する用途には使えるが、複数の異なるサーバ環境にそれぞれセキュリティパッチを適用する場合やソフトウェアのデプロイには対応できない。

本発明の目的は、複数の異なるサーバ環境に対するセキュリティパッチ適用、ソフトウェアのデプロイを一括、高速に行なうことができるデプロイシステム及びデプロイ方法を提供することにある。

上記目的を達成するため、本発明に係るデプロイシステムは、個々のサーバ環境に対応したＯＳのディスクイメージファイルを専用の更新サーバのボリュームとしてマウントする起動手段（起動プログラム）と、実際にセキュリティパッチの適用やソフトウェアのデプロイ処理を実行する更新手段（更新エージェント）と、更新手段からのＩ／Ｏアクセス要求を選択的に振り分けるアクセス管理手段（アクセス管理エージェント）からなるデプロイシステムにおいて、
前記更新手段が過去の更新の履歴を管理するリポジトリにアクセスする際、どのサーバに対する更新を実行しているか判断し、適切なＯＳのディスクイメージファイルをマウントしたボリュームにＩ／Ｏアクセスを振り分ける第１の手段と、
ＯＳのディスクイメージファイルを前記専用の更新サーバのボリュームとしてマウントする第２の手段とを備えることを特徴とする。

また、本発明に係るデプロイ方法は、個々のサーバ環境に対応したＯＳのディスクイメージファイルを専用の更新サーバのボリュームとしてマウントする起動手段（起動プログラム）と、実際にセキュリティパッチの適用やソフトウェアのデプロイ処理を実行する更新手段（更新エージェント）と、更新手段からのＩ／Ｏアクセス要求を選択的に振り分けるアクセス管理手段（アクセス管理エージェント）からなるデプロイシステムにおいて、
前記更新手段が過去の更新の履歴を管理するリポジトリにアクセスする際、どのサーバに対する更新を実行しているか判断し、適切なＯＳのディスクイメージファイルをマウントしたボリュームにＩ／Ｏアクセスを振り分ける第１のステップと、
ＯＳのディスクイメージファイルを前記専用の更新サーバのボリュームとしてマウントする第２のステップとを備えることを特徴とする。

本発明によれば、複数の異なるサーバ環境に対するセキュリティパッチの更新、ソフトウェアのデプロイを少なくとも一台以上の専用の更新サーバ上で一括で行なうことができる。また、ＯＳディスクイメージからＯＳを起動する際のオーバヘッド、起動時間を削減することができる。

本発明の実施形態を示すシステム構成図である。従来におけるＯＳのパッチ更新方法を説明図である。本発明の実施形態におけるＯＳのパッチ更新方法を示す説明図である。本発明の実施形態におけるＯＳイメージファイルの構成を示す図である。本発明の実施形態における更新リストの構成を示す図である。本発明の実施形態におけるリポジトリの構成を示す図である。本発明の実施形態における更新エージェントの処理を示すフローチャートである。本発明の実施形態における仮想マシンモニターの処理を示すフローチャートである。本発明の実施形態における起動プログラムのボリュームマウント処理を示すフローチャートである。本発明の実施形態における起動プログラムのボリュームアンマウント処理を示すフローチャートである。本発明の実施形態におけるアクセス管理モジュールの処理を示すフローチャートである。

以下、本発明を実施する場合の一形態について図面を参照して具体的に説明する。
図１は、本発明の実施形態を示すシステム構成である。
この実施形態のシステムは、更新サーバ１０、更新サイト２０、仮想マシン（１）３０〜（ｎ）がそれぞれネットワーク１で接続された構成となっている。なお、仮想マシン（ｎ）は図示を省略している。
専用の更新サーバ１０の内部では起動プログラム１１、更新エージェント（０）１２、アクセス管理モジュール１３、オペレーティングシステム１４が稼動している。
更新サーバ１０は過去における更新の履歴を管理するリポジトリ１５を管理しており、セキュリティパッチを適用する都度、また、ソフトウェアをデプロイする都度、更新履歴が更新される。

更新サイト２０には最新の更新を配布するための配布プログラム２１が稼動しており、最新の更新がある度に、更新情報を格納した更新リスト（１）５０を確認元に送信する。仮想マシン（１）３０にも更新エージェント（１）３１、オペレーティングシステム３２、リポジトリ３３が稼動している。
仮想マシンモニター４０はＯＳイメージファイル（１）６０を読み込むことで仮想マシン１３０を起動する。本発明が対象とする「異なるサーバ環境」とはＯＳイメージファイル（１）６０が（１）〜（ｎ）まで複数個存在することを意味する。

図２は、従来のＯＳのパッチ更新方法を示す説明図であり、ここでは仮想マシン（１）３０でＯＳのセキュリティパッチを適用するケースについて説明する。
ユーザは、まず仮想マシン（１）３０のＯＳイメージファイル（１）６０から仮想マシン（１）３０を起動させる。上記操作はＯＳの起動処理を伴うため、起動時間がかかるとともに、オーバヘッドが高く、サーバの負荷が高まる。
本発明は上記したＯＳの起動処理に伴う負荷の増大を回避するものである。仮想マシン（１）３０が起動すると、更新エージェント（１）５０は更新サイト２０の配布プログラム２１にアクセスし、更新の有無を検索し、更新されていた場合には仮想マシン（１）３０用の更新リスト（１）５０をダウンロードする。この後、更新エージェント（１）３１は仮想マシン（１）３０の内部に保持されているリポジトリ（１）３３を検索し、仮想マシン（１）３０の過去の更新リストを取得する。上記更新リスト（１）５０とリポジトリ（１）３３の検索結果を照合し、更新すべきセキュリティパッチを発見した場合には、更新エージェント（１）３１は更新サイト２０で稼動する配布プログラム２１に再度アクセスし、必要な更新をダウンロードする。

更新エージェント（１）３１はダウンロードした更新ファイルを保存する。この際、仮想マシン（１）３０上で発生するＩ／Ｏアクセスは仮想マシンモニター４０によってＯＳイメージファイル１へのファイルアクセスに変換される。この結果、ＯＳイメージファイル（１）６０には最新のセキュリティパッチが反映される。なお、ソフトウェアをデプロイする場合の動作の仕組みも上記と同様であり、更新エージェント（１）３１がソフトウェアのインストールプログラム、移行ツールに置き換わったと考えればよい。

図３は本発明におけるＯＳのパッチ更新方法を示す。図２の説明で示したＯＳの起動処理に伴う負荷の増大を回避するため、本発明では、ＯＳを起動する代わりに、専用の更新サーバ１０上にＯＳイメージファイル（１）６０をマウントし、更新サーバ１０上で複数のＯＳイメージファイルのセキュリティパッチの一括更新、ソフトウェアの一括デプロイを行なう。
起動プログラム１１はＯＳイメージファイル（１）６０からシステムボリュームに相当する部分を抽出し、更新サーバ１０上のボリューム（１）７０としてマウントする。ボリュームのマウントが完了すると、アクセス管理モジュール１３にボリューム（１）７０がマウントされたことを通知する。これ以降、更新エージェント（０）１２、アクセス管理モジュール１３は更新サーバ１０ではなく、ボリューム（１）７０を参照してＯＳイメージファイル（１）６０へのセキュリティパッチの適用、ソフトウェアのデプロイを行なうように動作する。

更新エージェント（０）１２が更新サイト２０の配布プログラム２１にアクセスし、仮想マシン（１）３０用の更新リスト（１）５０をダウンロードする処理は従来と同様である。従来との違いは、通常なら更新エージェント（０）１２は更新サーバ１０の内部に保持されているリポジトリ１５を検索して過去の更新リストを取得するのだが、アクセス管理モジュール１３がリポジトリ１５へのアクセスをボリューム（１）７０のリポジトリ（１）３３へのアクセスに振り分けることである。この結果、仮想マシン（１）３０の過去の更新リストを取得できるため、仮想マシン（１）３０で必要な更新が何であるかを確認できる。

更新エージェント（０）１２が更新サイト２０で稼動する配布プログラム２１に再度アクセスし、必要な更新をダウンロードする処理は従来と同様である。更新エージェント（０）１２がダウンロードした更新ファイルを保存する処理も同様に、アクセス管理モジュール１３はＩ／Ｏアクセスをボリューム（１）７０へのアクセス、つまりＯＳイメージファイル（１）６０へのＩ／Ｏアクセスに振り分け、更新ファイルの書込み要求をボリューム（１）７０にリダイレクトし、仮想マシン（１）に更新ファイルの内容を反映させる。
セキュリティパッチの適用、ソフトウェアのデプロイが終了すると、更新エージェント（０）１２は起動プログラム１１に終了通知を出す。

起動プログラム１１は上記通知を受けて、ボリューム（１）７０のアンマウント、アクセス管理モジュール１３へのボリューム（１）７０のアンマウントを通知する。これ以降、更新サーバ１０は通常の状態に戻るため、例えば、更新サーバ１０自体のセキュリティパッチの適用、ソフトウェアのデプロイを行なうことができる。
なお、更新エージェント（０）１２はオペレーティングシステム１４の基本構成であり、サーバの種類毎に異なる。つまり、ＯＳイメージファイル（１）６０に含まれるオペレーティングシステムとオペレーティングシステム１４は同一のオペレーティングシステムであることが前提である。複数のオペレーティングシステムを対象とする場合、個々のオペレーティングシステム毎に更新サーバ１０を用意する方法で対応可能である。

図４は本発明におけるＯＳイメージファイルの構成を示す。
ＯＳイメージファイル６０は単一のイメージファイルとして構成されており、仮想マシン構成情報、ＯＳ起動情報(ブートセクタ)、ボリューム（１）７０、ボリューム（ｎ）から成る。本実施例では、ボリューム（１）７０がＯＳのシステムボリュームの場合の例を示しており、リポジトリ（１）３３を内部に保持している。

図５は、本発明における更新リストの構成例を示す図である。
本実施例では更新リストの一実施例として、モジュール名、バージョン、更新日時、ファイルサイズを挙げている。実際には上記要素以外の物が含まれる場合が考えられるが、無論、本発明の範囲に含まれることは言うまでもない。

図６は、本発明におけるリポジトリの構成例を示す図である。
本実施例ではリポジトリ３３の一実施例として、モジュール名、バージョン、作成日時、更新日時、アクセス日時、ファイルサイズを挙げている。実際には上記要素以外の物が含まれる場合が考えられるが、無論、本発明の範囲に含まれることは言うまでもない。なお、リポジトリ３３の斜線部分は更新リスト５０に対応する、実際に更新されたファイルである。例えば、foo3.dllのバージョン番号はリポジトリ３３では6.3.1.1であるが、更新リストでは6.4.0.0となっており、仮想マシン（１）３０の更新エージェント（１）３１は更新があったことを確認することができる。

以下、本発明を実施する場合の処理の流れについてフローチャートを用いて具体的に説明する。
図７は、更新エージェント（０）１２の処理を示すフローチャートである。
更新エージェント（０）１２は更新サイト２０にアクセスして更新リスト（１）５０を入手する（ステップ７０１）。この後で、リポジトリ（１）３３を検索し、過去の更新履歴を入手する（ステップ７０２）。この際にアクセスするリポジトリ（１）３３はローカルのリポジトリ１５ではなく、ＯＳイメージファイル（１）６０からマウントしたボリューム（１）７０に保持されているリポジトリ３３であるが、これは更新エージェント（０）１２が自発的にアクセスしているのではなく、アクセス管理モジュール１３がアクセス先を振り分けていることによる効果である。

この後で更新リスト（１）５０とリポジトリ（１）３３の内容を照合し、更新の有無をチェックする（ステップ７０３）。ステップ７０３で更新なしの場合はステップ７０１から繰り返す。それ以外の場合は更新サイト２０から更新ファイルをダウンロードする（ステップ７０４）。
最終的に更新エージェント（０）１２は更新ファイルをボリューム（１）７０経由でＯＳイメージファイル（１）６０に格納する（ステップ７０５）。ステップ７０４についても上記同様にアクセス管理モジュール１３のアクセス先を振り分け処理の影響を受ける。ステップ７０５終了後はステップ７０１から繰り返す。

図８は、本発明に記載の仮想マシンモニターの処理を示すフローチャートである。
仮想マシン（１）〜（ｎ）の仮想マシンモニター４０は仮想マシン（１）３０からのファイル書込み要求を待ち（ステップ８０１）、仮想マシン（１）３０からのファイル書込み要求を受信すると（ステップ８０２）、対応したＯＳイメージファイルとしてＯＳイメージファイル（１）６０にアクセスし（ステップ８０３）、イメージファイル（１）６０への書込みを行なう（ステップ８０４）。通常、仮想マシンモニター４０は複数のＯＳイメージファイル（１）〜（ｎ）を起動するため、上記のようなアクセス先のＯＳイメージファイルを選択する機能が必要になる。ステップ８０４終了後はステップ８０１から繰り返す。

図９は、更新サーバ１０の起動プログラム１１のボリュームマウント処理を示すフローチャートである。
起動プログラム１１はユーザからの更新要求としてＯＳイメージファイル（１）６０の入力を待ち（ステップ９０１）、ＯＳイメージファイル（１）６０の入力を受信すると（ステップ９０２）、ＯＳイメージファイル（１）６０のシステムボリュームを認識し、ボリューム（１）７０にマウントする（ステップ９０３）。そして、アクセス管理モジュール１３にボリュームをマウントしたことの通知として、例えばマウントしたボリュームのボリューム識別子等を通知する。ステップ９０４終了後はステップ９０１から繰り返す。
複数のＯＳイメージファイルの更新を行なう場合はステップ９０１からステップ９０４までの処理が繰り返される。

図１０は起動プログラム１１のボリュームアンマウント処理を示すフローチャートである。
起動プログラム１１は更新エージェント（０）１２から更新終了通知を待ち（ステップ１００１）、更新終了通知を受信すると（ステップ１００２）、ボリューム（１）７０をアンマウントする（ステップ９０３）。そして、アクセス管理モジュール１３にボリュームをアンマウントしたことの通知として、例えばアンマウントしたボリュームのボリューム識別子等を通知する。ステップ１００４終了後はステップ１００１から繰り返す。

図１１は、アクセス管理モジュール１３の処理を示すフローチャートである。
アクセス管理モジュール１３は更新エージェント（０）１２からのリポジトリへのアクセス要求を待ち（ステップ１１０１）、リポジトリへのアクセス要求を受信すると（ステップ１１０２）、ボリューム（１）７０がマウント済みかチェックする（ステップ１１０３）。ステップ１１０３でボリューム（１）７０がマウント済みの場合はボリューム（１）７０が保持しているリポジトリ（１）３３にＩ／Ｏアクセスを振り分ける（ステップ１１０４）。これはＯＳイメージファイル（１）６０の更新を行なう場合の処理である。
一方、ステップ１１０３でボリューム（１）７０がマウントされていない場合はローカルのリポジトリ１５にＩ／Ｏアクセスを振り分ける（ステップ１１０５）。これは通常の更新サーバ１１におけるＯＳ１４の更新を行なう場合である。

以上の説明から明らかなように、本発明は、仮想マシンのＯＳのセキュリティパッチの更新あるいはソフトウェアのデプロイを実施する場合に、仮想マシン別にＯＳを起動して更新ファイルを適用するのでなく、専用の更新サーバに仮想マシンのＯＳイメージファイルからシステムボリューム抽出してマウントし、そのマウントしたシステムボリューム内のリポジトリを参照して当該仮想マシンのＯＳの更新ファイルを適用するかを判断し、更新する必要がある場合には、アクセス管理モジュールにより更新ファイルの書込み要求をＯＳイメージファイルへの書込みに変更し、更新ファイルの内容を反映させるようにしたため、仮想マシン別にＯＳを立ち上げる必要がなく、更新サーバへ各仮想マシンのＯＳイメージファイルから抽出したシステムボリュームのマウント、更新ファイルの適用、システムボリュームアンマウント処理を繰り返すだけで、サーバ環境が異なる複数の仮想マシンのセキュリティパッチの更新、ソフトウェアの更新などのデプロイを実施することができる。

１ネットワーク
１０更新サーバ
１１起動プログラム
１２更新エージェント（０）
１３アクセス管理モジュール
１４オペレーティングシステム
１５リポジトリ
２０更新サイト
２１配布プログラム
３０仮想マシン（１）
３１更新エージェント（１）
３２オペレーティングシステム
３３リポジトリ（１）
４０仮想マシンモニター
５０更新リスト（１）
６０ＯＳイメージファイル（１）

Claims

個々のサーバ環境に対応したＯＳのディスクイメージファイルを専用の更新サーバのボリュームとしてマウントする起動手段と、実際にセキュリティパッチの適用やソフトウェアのデプロイ処理を実行する更新手段と、更新手段からのＩ／Ｏアクセス要求を選択的に振り分けるアクセス管理手段からなるデプロイシステムにおいて、
前記更新手段が過去の更新の履歴を管理するリポジトリにアクセスする際、どのサーバに対する更新を実行しているか判断し、適切なＯＳのディスクイメージファイルをマウントしたボリュームにＩ／Ｏアクセスを振り分ける第１の手段と、
ＯＳのディスクイメージファイルを前記専用の更新サーバのボリュームとしてマウントする第２の手段とを備えることを特徴とするデプロイシステム。
個々のサーバ環境に対応したＯＳのディスクイメージファイルを専用の更新サーバのボリュームとしてマウントする起動手段と、実際にセキュリティパッチの適用やソフトウェアのデプロイ処理を実行する更新手段と、更新手段からのＩ／Ｏアクセス要求を選択的に振り分けるアクセス管理手段からなるデプロイシステムにおいて、
前記更新手段が過去の更新の履歴を管理するリポジトリにアクセスする際、どのサーバに対する更新を実行しているか判断し、適切なＯＳのディスクイメージファイルをマウントしたボリュームにＩ／Ｏアクセスを振り分ける第１のステップと、
ＯＳのディスクイメージファイルを前記専用の更新サーバのボリュームとしてマウントする第２のステップとを備えることを特徴とするデプロイ方法。