JP2015069282A

JP2015069282A - 情報処理装置および情報処理装置の内部情報更新方法

Info

Publication number: JP2015069282A
Application number: JP2013201024A
Authority: JP
Inventors: 貴工中平; Kiko Nakahira
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2013-09-27
Filing date: 2013-09-27
Publication date: 2015-04-13
Anticipated expiration: 2033-09-27
Also published as: JP6268869B2

Abstract

【課題】複数のサーバ等の情報処理装置の内部情報更新を行う場合に、マネジメントソフトウェアなどを使用しなくても管理対象の情報処理装置の内部情報を設定できるようにする。【解決手段】互いにネットワークで接続された管理端末と複数の情報処理装置において、各情報処理装置は自分自身の管理を行う制御部を有する。管理端末により１台の情報処理装置（マスタ装置）の内部情報を更新すると、他の情報処理装置（スレーブ装置）の制御部は、ネットワークに接続し、ネットワークを通じて自身の内部情報を更新する。【選択図】図１

Description

本発明は、サーバなどの情報処理装置に係り、特に複数の情報処理装置の内部情報更新方法に関する。

近年、データセンターなどで、情報処理装置としてサーバの大量導入が増えているが、サーバ内部の設定やファームウェアのアップデートの簡単な方法が確立されておらず、これらを人手で行う場合がある。このため、データセンターのサーバのすべての設定を完了するまで時間がかかり、設定ミスが発生する場合もある。また、ファームウェアのアップデートを適用せずに古いまま使用するために、修正されているはずの不具合が発生し、問題となる場合もある。大量のサーバをサーバの外部から一括して管理するマネジメントソフトウェアも存在するが、構築のための基礎的な設定は人手で行う必要があり、またマネジメントソフトウェアにサーバを認識させるなど手間と時間が必要となる。

上記の課題を解決するために、例えば、特許文献１のように、ブレードサーバを起動することなく、ブレードサーバに搭載されたすべてのファームウェアの設定データの変更およびファームウェアイメージの更新を可能とする技術が開示されている。

特開２０１２−２０３４４２号公報

しかしながら、特許文献１は、複数のブレードサーバを管理するエンクロージャマネージャが必要となっている。これは、管理の範囲がエンクロージャマネージャごとになり、ブレードサーバの柔軟な選択ができないという課題があった。

本発明の目的は、この点を鑑みたものであり、複数のサーバ等の情報処理装置の内部情報更新を行う場合に、マネジメントソフトウェアを使用しなくても管理対象の情報処理装置の内部情報を設定できるようにすることにある。

本発明では、上記課題を解決するために、互いにネットワークで接続された複数の情報処理装置において、各々が複数の情報処理装置の管理を行う制御部を有し、制御部は、ネットワークに接続し、ネットワークを通じて自身の内部情報を更新することを特徴としている。

また、互いにネットワークで接続された複数の情報処理装置において、各々が複数の情報処理装置の管理を行う制御部を有し、制御部は、ネットワークに接続し、ネットワークを通じて自身の内部情報を更新するステップを有することを特徴としている。

本発明によれば、複数の情報処理装置の内部情報更新を行う場合に、マネジメントソフトウェアなどを使用せず、情報処理装置の管理を行う制御部が、それぞれ連携して内部情報更新を行うことができる。

本発明の第１の実施の形態におけるサーバの構成例を示すブロック図である。本発明の第１の実施の形態におけるサーバの動作を示すフローチャートである。本発明の第１の実施の形態におけるサーバの動作を示すフローチャートである。本発明の第１の実施の形態におけるサーバの動作を示すフローチャートである。本発明の第１の実施の形態におけるサーバの動作を示すフローチャートである。

以下、本発明の実施形態について図面を参照して詳細に説明する。
（第１の実施の形態）
図１は、本発明の第１の実施の形態におけるサーバの構成例を示すブロック図である。図１において、マスタ装置となるサーバ１１とスレーブ装置となるサーバ１２〜１６がネットワークを構成している。サーバの台数は、この構成例では６台であるが、２台以上であれば何台でも構わない。ネットワークには、これらのサーバを管理する管理端末１０が接続されている。サーバは、それぞれにＢＭＣ（ＢａｓｅｂｏａｒｄＭａｎａｇｅｍｅｎｔＣｏｎｔｒｏｌｌｅｒ）２１〜２６を有している。ＢＭＣはサーバ等に使われる管理用のコントローラであり、ハードウェア(ＣＰＵ、メモリ、温度等)の監視、リモートコントロール、ハードウェアイベントの記録、ファームウェアの管理などを行うものである。

そして、それぞれのＢＭＣ２１〜２６がネットワークに接続されている。各ＢＭＣは、管理端末１０からネットワークを通して管理されている。また、各々のＢＭＣ間でも交互に情報伝達が可能である。さらに個々のＢＭＣから、このネットワークに接続されているすべてのＢＭＣに同時に情報発信することもできる。

本発明の第１の実施の形態におけるＢＭＣ２１〜２６は、上記のようなネットワーク内で通信する機能と各ＢＭＣ内の内部情報を更新する機能とを有している。さらに、内部の設定を変更するだけで、マスタ装置とスレーブ装置とのどちらにでも設定されることが可能である。

図２、図３、図４、図５は、本発明の第１の実施の形態におけるサーバの動作を示すフローチャートである。

図２、図３、図４、図５を用いて、サーバが、スレーブ装置とマスタ装置の動作を行う場合について説明する。

ネットワークに接続されているサーバのうち、１台がマスタ装置となり、残りがスレーブ装置となって動作する。ここで、同期とは、内部情報である、ファームウェアや設定をすべて同じにすることを意味している。図２、図３、図４は、マスタ装置側から同期処理を開始する場合の手順であり、一連のフローを便宜上３つの図に分けて記載している。ここでは、管理端末１０から、内部情報を更新という命令がマスタとなる装置に送信されたとする。

まず、スレーブ装置のＢＭＣのネットワーク上の識別子であるＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）アドレスを設定する（Ｓ１０１）。ＤＨＣＰ（ＤｙｎａｍｉｃＨｏｓｔＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ）による自動設定も可能である。

また、マスタとなる装置のファームウェア(ＢＩＯＳ（ＢａｓｉｃＩｎｐｕｔＯｕｔｐｕｔＳｙｓｔｅｍ）、ＢＭＣ、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）など)のアップデートを行い、設定を行う（Ｓ１０２）。マスタ装置１１のＢＭＣ２１内のＮＶＲＡＭ（ＮｏｎＶｏｌａｔｉｌｅＲＡＭ：不揮発性メモリ）に、マスタ装置であることを示すフラグ情報を書き込む。フラグ情報を書き込んだ時間も同時に保存する（Ｓ１０３）。マスタフラグが設定された場合、すなわち、マスタ装置となった場合には、ＢＭＣ２１は、ＮＶＲＡＭ内にファームウェアの設定一覧を保存する（Ｓ１０４）。また、ファームウェアのバックアップを行い、アップデートモジュールを作成する（Ｓ１０５）。ファームウェアや設定の更新を行う範囲(ＩＰアドレスの範囲やサブネット)の設定を行う。設定更新を除外する範囲も合わせて設定する（Ｓ１０６）。

スレーブ装置のアップデート方法に関する情報の設定(以下、アップデートモード設定)を行う（Ｓ１０７）。ここで設定される情報は、ファームウェアの強制同期(ダウングレード含む)や古い場合のみアップデートを行うこと、マスタ装置がいない場合のエラーメッセージやブート抑止の表示有無などである。

マスタ装置は設定が完了すると、同期を適用する範囲のすべてのスレーブ装置に対して、クリアフラグを通知する。この時、クリアフラグ通知と同時に、マスタフラグ情報をセットした時間(マスタ時間)も同時に通知する（Ｓ１０８）。

スレーブ装置が、クリアフラグを受け取った場合は、同期完了フラグがセットされているかチェックし（図３のＳ１０９）、同期完了フラグがセットされていない場合は（Ｓ１０９のＮｏ）、同期設定フラグのセットを行う（Ｓ１１２）。同期完了フラグがセットされている場合は（Ｓ１０９のＹｅｓ）、前回、同期したマスタ装置のマスタ時間が記録されているので、この時間と今回受け取ったマスタ時間の比較を行う（Ｓ１１０）。受け取ったマスタ時間の方が古い場合は（Ｓ１１０のＮｏ）、何もしないが、受け取ったマスタ時間が新しい場合は（Ｓ１１０のＹｅｓ）、自身の同期完了フラグをクリアし（Ｓ１１１）、同期設定フラグをセットする（Ｓ１１２）。

ここで、マスタ装置が、クリアフラグを受け取った場合は、自身のマスタ時間と比較し、受け取ったマスタ時間が新しい場合は、新しくマスタ装置が出現したので、自身はスレーブ装置となる。マスタフラグをクリアし、設定一覧、アップデートモジュールおよび適用範囲の設定のクリアを行う。また、自身のマスタ時間と比較し、受け取ったマスタ時間が古い場合は、何もしない。このクリアフラグは、マスタ装置が定期的に送出するため、ある適用範囲のなかにマスタが２台あったとしても、最終的には一台となる。

スレーブ装置がクリアフラグ通知を受け、同期フラグがセットされた場合、マスタに対しファームウェアレビジョン一覧要求を通知する（図４のＳ１１３）。また、自身がつながれたネットワーク内に、自身のＩＰアドレスの情報と共にマスタ捜索ブロードキャストメッセージを送出し、マスタ装置の捜索を行う。

マスタ装置が、ファームウェア一覧要求およびマスタ捜索ブロードキャストメッセージを受け取った場合、送出元のＩＰアドレスをチェックし（Ｓ１１４）、同期を適用する適用範囲に入っていれば（Ｓ１１５のＹｅｓ）、スレーブ装置に対して、マスタ装置のＩＰアドレスとファームウェアのレビジョン一覧、マスタ時間を返信する（Ｓ１１６）。

スレーブ装置は、マスタ装置からの応答がない場合は、一定期間経過後に、再びファームウェア一覧要求およびマスタ捜索ブロードキャストメッセージを送出する。また、マスタ装置が見つからない場合は、（Ｓ１０７）で設定したアップデートモード設定に従いブート抑止、エラー表示の動作を行う。

スレーブ装置は、マスタ装置のＩＰアドレスおよびマスタ時間を一時領域に保存を行い（Ｓ１１７）、受け取ったファームウェアレビジョン一覧と自身のファームウェアレビジョンの比較を行う（Ｓ１１８）。アップデートの必要なものがあった場合、マスタ装置に対しファームウェアのアップデートモジュールの取得要求を行う（Ｓ１１９）。

マスタ装置は、ファームウェアのアップデートモジュール取得要求に対し、要求のあったファームウェアのアップデートモジュールの圧縮などを行い（Ｓ１２０）、スレーブ装置に転送を行う（Ｓ１２１）。

スレーブ装置は、ファームウェアアップデートモジュールを受け取った場合、装置の電源ＯＮ／ＯＦＦに関わらずアップデートできるものについては、即座に適用を行う（Ｓ１２２）。すぐに適用できないものについては、一旦、ＢＭＣのＮＶＲＡＭ内に格納を行い、ＰＯＳＴ（ＰｏｗｅｒＯｎＳｅｌｆＴｅｓｔ）実行時にアップデートを行う。アップデートを行うファームウェアの個数によっては、アップデート作業が複数回行われる。

スレーブ装置は、ファームウェアのアップデート後、設定情報の取得要求をマスタ装置に行う（Ｓ１２３）。マスタ装置は、設定情報の一覧を作成し（Ｓ１２４）、スレーブ装置に転送する（Ｓ１２５）。

スレーブ装置は、取得した設定情報一覧をもとに、ファームウェアのアップデートと同様に装置の電源ＯＮ／ＯＦＦに関わらず適用できるものに関しては、即座に適用を行う（Ｓ１２６）。すぐに適用できないものについては、一旦ＢＭＣのＮＶＲＡＭ内に格納を行い、ＰＯＳＴ実行時に設定値の適用を行う。スレーブ装置の電源がＯＮ中の場合は再起動を行い、ＰＯＳＴを実行するようユーザに通知を行う。そして、ＰＯＳＴ実行時のみ実行可能なファームウェアのアップデート、設定の適用を行う。適用の順序はまず、ファームウェアのアップデートを行い、その後設定の適用を行う（Ｓ１２７）。

ＰＯＳＴ完了時に、エラーが無ければ、スレーブ装置自身に同期完了フラグをセットし（Ｓ１２８）、マスタ装置に設定完了を通知する（Ｓ１２９）。一時領域に保存していたＩＰアドレスおよびマスタ時間をＢＭＣのＮＶＲＡＭに保存する。エラーが発生した場合は、マスタ装置にエラーの通知を行う。エラーの場合は、ＩＰアドレスおよびマスタ時間は保存しない。マスタ装置は、完了、エラー通知を受け取った場合、自身のリストに登録を行う（Ｓ１３０）。

図５は、管理端末１０からの同期処理開始の指示を受けて、スレーブ装置側から同期処理を開始する場合の手順である。

図５において、まず、スレーブ装置のＢＭＣのＩＰアドレスを設定する（Ｓ２０１）。
次に、スレーブ装置で、同期設定フラグのセットを行う（Ｓ２０２）。同期設定フラグは、スレーブ装置自身でセットが可能である。

そして、マスタ装置に対しファームウェアレビジョン一覧要求を通知する。また、自身がつながれたネットワーク内に、自身のＩＰアドレスの情報と共にマスタ捜索ブロードキャストメッセージを送出し、マスタ装置の捜索を行う（Ｓ２０３）。

マスタ装置が、ファームウェア一覧要求およびマスタ捜索ブロードキャストメッセージを受け取った場合、送出元のＩＰアドレスをチェックし（Ｓ２０４）、同期を適用する適用範囲に入っていれば（Ｓ２０５のＹｅｓ）、スレーブ装置に対して、マスタ装置のＩＰアドレスとファームウェアのレビジョン一覧、マスタ時間を返信する（Ｓ２０６）。

以降の動作は、図４と同様であるので説明を省略する。

このように本実施形態によれば、複数のサーバの内部情報更新を行う場合に、マネジメントソフトウェアなどを使用せず、サーバ内のＢＭＣが、それぞれ連携して内部情報更新を行うことができ、しかも、どのＢＭＣでも内部情報更新を指示することができる。マネジメントソフトウェアを導入すると、構築のための基礎的な設定は人手で行う必要があり、またマネジメントソフトウェアにサーバを認識させるなど手間と時間が必要であった。しかし本実施形態では、元々存在するＢＭＣの通信機能を利用してＢＭＣ間で設定の更新とマスタ／スレーブの入れ替わりをするので、ＢＭＣをわずかに改修するだけで済む。

また特許文献１ではエンクロージャマネージャを使用するので更新対象のブレードサーバを柔軟に選択できずエンクロージャマネージャ毎にしか選択できない。しかし本実施形態では各サーバが保有するＢＭＣを使うので、更新対象のサーバを柔軟に選択できる。

尚、本願発明は、上述の実施の形態に限定されるものではなく、本願発明の要旨を逸脱しない範囲で種々変更、変形して実施することが出来る。たとえば、本願発明では、サーバのＢＭＣで実施しているが、何らかの通信手段に接続された管理コントローラに制御されるものであれば、いかなるものでも実現可能である。

本発明は、複数の情報処理装置の内部情報更新方法として利用できる。

１０管理端末
１１、１２、１３、１４、１５、１６サーバ
２１、２２、２３、２４、２５、２６ＢＭＣ

Claims

互いにネットワークで接続された複数の情報処理装置において、
各々が前記複数の情報処理装置の管理を行う制御部を有し、
前記制御部は、前記ネットワークに接続し、前記ネットワークを通じて自身の内部情報を更新することを特徴とする情報処理装置。
前記制御部はＢＭＣ（ＢａｓｅｂｏａｒｄＭａｎａｇｅｍｅｎｔＣｏｎｔｒｏｌｌｅｒ）である請求項１に記載の情報処理装置。
前記複数の情報処理装置は、１台がマスタ装置となり、前記マスタ装置以外がスレーブ装置となることを特徴とする請求項１または２に記載の情報処理装置。
前記複数の情報処理装置は、前記マスタ装置と前記スレーブ装置が入れ替え可能であることを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
前記制御部は、前記ネットワークに接続するための識別子を有することを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
前記制御部は、前記ネットワーク内において前記識別子を有する他の制御部と情報を交換することを特徴とする請求項１から５のいずれか１項に記載の情報処理装置。
前記制御部は、前記ネットワーク内において前記識別子を検索することを特徴とする請求項１から６のいずれか１項に記載の情報処理装置。
前記制御部は、前記内部情報が書き込まれた時刻を基準に前記内部情報の更新の有無を判断することを特徴とする請求項１から７のいずれか１項に記載の情報処理装置。
互いにネットワークで接続された複数の情報処理装置において、
各々が前記複数の情報処理装置の管理を行う制御部を有し、
前記制御部は、前記ネットワークに接続し、前記ネットワークを通じて自身の内部情報を更新するステップを有すること
を特徴とする情報処理装置の内部情報更新方法。
前記内部情報を更新するステップは、
前記ネットワーク内において前記制御部の識別子を検索するステップと、
前記ネットワーク内において前記識別子を有する他の制御部と情報を交換するステップと、
前記内部情報が書き込まれた時刻を基準に前記内部情報の更新の有無を判断するステップと、
を有することを特徴とする請求項９記載の情報処理装置の内部情報更新方法。