JP6491299B2 - サーバ装置のファームウェア及びカスタム設定の自動的なプロビジョニング - Google Patents

Description

本発明は、サーバ装置のファームウェア及びカスタム設定を自動的にプロビジョニングするシステム及び方法に関する。

ここ数年の間に、サーバ管理の分野はかなり発展している。「ＩＰＭＩ: Intelligent Platform Management Interface Specification, Second Generation」， v.2.0, Feb. 12, 2004に記載されているインテリジェントプラットフォーム管理インタフェース（ＩＰＭＩ）と呼ばれる業界基準は、サーバクラスのコンピュータシステムに用いられる管理ソリューションを実施するプロトコル、要求及びガイドラインを定義する。ＩＰＭＩ標準により提供される機能には、電源管理、システムイベントロギング、各種センサを用いた環境ヘルスモニタリング、ウォッチドッグタイマ、フィールド置換ユニット（field replaceable unit）情報、管理コントローラへの帯域内及び帯域外アクセス、ＳＮＭＰトラップ等が含まれる。

ＩＰＭＩ標準を実装するためにサーバクラスのコンピュータに通常含まれるコンポーネントは、ベースボード管理コントローラ（ＢＭＣ）として知られている。ＢＭＣは、コンピュータのマザーボードに組み込まれた専用のマイクロコントローラであって、システム管理ソフトウェアとプラットフォームハードウェアとの間のインタフェースを管理する。ＢＭＣは、通常、ＩＰＭＩアーキテクチャにおける「インテリジェンス」を提供する。

現在のマーケットにおける多くのサーバクラスのコンピュータシステムは、動作可能になるためにファームウェアイメージを必要とするシステムコンポーネントを有する。「ファームウェア」は、例えばＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ等の読み出し専用メモリ（ＲＯＭ）（再プログラム可能であってもよい）に記憶されるソフトウェアである。ファームウェアを必要とするこのようなコンポーネントのいくつかの例は、ＢＭＣ、基本入出力システム（ＢＩＯＳ）、ストレージコントローラ（例えば、ＳＣＳＩ／ＳＡＳ／ファイバーチャネルコンポーネント）、及び、ネットワークインタフェースコントローラ（ＮＩＣｓ）等が挙げられる。これらのファームウェアイメージは、通常、ＢＩＯＳが存在するシステムフラッシュメモリ又はコンポーネント固有のフラッシュ部分に位置する。

任意の機械コンポーネントと同様に、これらのシステムコンポーネントは、ドライブ読み書きパフォーマンスを低下させたり、ドライブ故障を引き起こす動作上の問題に直面する。いくつかの問題は、磁気媒体、スピンモータ、読み取り／書き込みヘッドアセンブリ若しくは駆動回路を含む、ドライブファームウェア又はハードウェアに関する。このようなファームウェア及びハードウェアの問題は、通常、ディスクドライブを製造元に返却して修理や交換することを要求する。その他の潜在的問題は、ユーザに関連する問題であり、通常、ストレージオペレーティングシステム又はユーザアプリケーション内のソフトウェアの問題に起因する。

サーバで動作するとき、インストールされたファームウェアのバージョンがカスタマイズされ、マザーボードの周辺ＩＯと完全互換である。ファームウェアの設定は、通常、インストールされているシャーシの構成と一致している。但し、修復後にシステムコンポーネントが返却される場合、ファームウェアが、修復期間中に、アップグレード又はダウングレードされた（即ち、修復モードで構成された）可能性がある。さらに、交換又は新たなシステムコンポーネントを提供する場合、ファームウェアは、元のファームウェア（つまり、工場モード）に対してアップグレード又はダウングレードされてもよい。

カスタム設定を用いてシステムコンポーネントをユーザモードに復元するには、システムコンポーネント設定を手動で保存及び復元し、顧客のプロファイル毎にファームウェアを手動でアップグレード又はダウングレードする必要がある。しかし、これらの作業を手動で実行すると、コストが高くなりメンテナンスが面倒になる可能性がある。

本発明は、サーバ装置のファームウェア及びカスタム設定を自動的にプロビジョニングするシステム及び方法を提供する。

本発明の実施形態は、サーバ装置のファームウェア及びカスタム設定を自動的にプロビジョニングするシステム及び方法に関する。各種実施形態による方法は、ラック装置にインストールされたサーバ装置の設置場所及び識別情報を決定する工程を含むことができる。いくつかの実施形態では、サーバ装置は、第１動作モードで動作し、第１動作モードは、工場モード又は修復モードを含む。また、本方法は、サーバ装置の設置場所及び識別情報に基づいて、サーバ装置のファームウェアパッケージを識別する工程を含むことができる。さらに、この方法は、決定されたサーバ装置の設置場所及び識別情報に基づいて、ファームウェアをインストールする工程を含む。

本発明のいくつかの実施形態では、修復モードは、サービスの前にサービスエンジニアによって構成され、クラウドサーバにアップロードされたファームウェアバージョン及びカスタム設定を含む。本発明のいくつかの実施形態では、ファームウェアパッケージのインストールは、ファームウェアのインストールを容易にするためにベースボード管理コントローラ（ＢＭＣ）を用いる工程を含む。本発明のいくつかの実施形態では、ファームウェアのインストールを容易にするためにＢＭＣを用いる工程は、ＢＭＣを用いて、基本入出力システム（ＢＩＯＳ）ファームウェアイメージを取得する工程を含む。本発明の別の実施形態では、ファームウェアのインストールを容易にするためにＢＭＣを用いる工程は、ＢＭＣを用いて、ＣＰＬＤ（Complex Programmable Logic Device）ファームウェアイメージを取得する工程を含む。

本発明の別の実施形態では、ファームウェアパッケージのインストールは、ファームウェアのインストールを容易にするためにラック管理コントローラ（ＲＭＣ）を用いる工程を含む。さらに、本発明のいくつかの実施形態では、設置場所を決定する工程は、ラック装置及び設置場所に関連するＲＦＩＤタグを読み取る工程を含む。本発明のいくつかの別の実施形態では、設置場所を決定する工程は、電気的に消去可能なプログラマブルＲＯＭ（ＥＥＰＲＯＭ）からサーバ装置の識別情報を検索する工程を含む。

本発明のいくつかの実施形態では、ファームウェアパッケージは、システム管理ソフトウェアに保存される。システム管理ソフトウェアは、安全なクラウドサーバを含むことができる。セキュアに保護するクラウドサーバにファームウェアパッケージが保存されている場合、ファームウェアパッケージは、データ構造として構成されてもよい。いくつかの実施形態では、データ構造は、証明書（certificate）のアレイを有するパッケージヘッダを含むことができる。本発明のいくつかの実施形態では、サーバ装置情報、サーバ装置ＩＤ（identification）、ファームウェアパッケージデータ、及び／又は、ファームウェアの検証に対応するイメージファイルを含むことができる。本発明のいくつかの実施形態では、ＢＭＣを用いてクラウドサーバからファームウェアイメージを取得し、ファームウェアイメージがセキュアであるか否かを検証し、ファームウェアパッケージとサーバ装置の識別情報（サーバ装置ＩＤ）との間でサーバシステムのＩＤを比較する。

本発明のいくつかの実施形態では、ファームウェアパッケージのインストールは、サーバ装置を、カスタムモードで動作するように構成する。本発明の別の実施形態では、ファームウェアパッケージのインストールは、サーバ装置を、ユーザモードで動作するように構成する。本発明のいくつかの実施形態では、サーバ装置を、ユーザモードで動作するように構成する工程は、カスタムファームウェアをロードし、ソフトウェア読み書きインタフェースを起動して、カスタムファームウェア設定をサーバ装置にプログラムする工程を有する。本発明のいくつかの実施形態では、ユーザモードは、第１動作モードからアップグレードしたファームウェアを有する。本発明の別の実施形態では、ユーザモードは、第１動作モードからダウングレードしたファームウェアを有する。別の実施形態では、ユーザモードは、第１動作モードからプロビジョニングした追加の設定を有する。

本発明によれば、サーバ装置のファームウェア及びカスタム設定を自動的にプロビジョニングすることができる。

一実施形態による、本発明を実施し得る処理システムのハイレベルブロック図である。 一実施形態による、サーバ内にインストールされたセンサを実装する、追跡されるサーバコンポーネントのブロック図である。 いくつかの実施形態による、例示的なシステム管理ソフトウェアを示す図である。 一実施形態による、システム管理ソフトウェアを用いてファームウェアパッケージをアップロードする例示的な方法のブロック図である。 一実施形態による、サーバコンポーネントのファームウェアを自動的にプロビジョニングする例示的な方法のブロック図である。 一実施形態による、ユーザモードにおいて、システム管理ソフトウェアを用いてファームウェアパッケージをアップロード又はダウンロードする例示的な方法のブロック図である。 一実施形態による、ユーザモードにおいて、システム管理ソフトウェアを用いてファームウェアパッケージをアップロード又はダウンロードする例示的な方法のブロック図である。 一実施形態による、サーバコンポーネント内の設定をプログラミングして、サーバコンポーネントをカスタムモードで動作するようにプロビジョニングする例示的な方法のブロック図である。 一実施形態による、サーバコンポーネント内の設定をプログラミングして、サーバコンポーネントをカスタムモードで動作するようにプロビジョニングする例示的な方法のブロック図である。 一実施形態による、サーバコンポーネント内の設定をプログラミングして、サーバコンポーネントをカスタムモードで動作するようにプロビジョニングする例示的な方法のブロック図である。 一実施形態による、サーバコンポーネント内の設定をプログラミングして、サーバコンポーネントをカスタムモードで動作するようにプロビジョニングする別の例示的な方法のブロック図である。 一実施形態による、サーバコンポーネント内の設定をプログラミングして、サーバコンポーネントを、ＲＭＡを用いて、カスタムモードで動作するようにプロビジョニングする別の例示的な方法のブロック図である。 一実施形態による、サーバコンポーネント内の設定をプログラミングして、サーバコンポーネントを、ＲＭＡを用いて、カスタムモードで動作するようにプロビジョニングする別の例示的な方法のブロック図である。

説明を簡単及び分かりやすくするために、符号は、適切な状況下で、異なる図において重複して使用されること、対応又は類似する構成要素を示すことを理解されたい。この他、記載される実施形態についての十分な理解を提供すべく、多くの詳細な説明が記載されている。しかし、当業者であれば理解できるように、ここで記載される実施形態は、これらの特定の詳細がなくても実現可能である。その他の実施形態において、特徴点が曖昧にならないようにするために、周知の方法、工程及び構成要素については詳述されていない。図面は、必ずしも尺寸通りに描かれておらず、ある部分の比率が拡大されることにより、詳細と特徴点をさらに説明している。これらの記載は、記載される実施形態の範囲を制限するものではない。

本発明の好ましい実施形態は、システムコンポーネントを、カスタム設定を用いてユーザモードに効率的に復元するために、サーバ装置のファームウェア及びカスタム設定を自動的にプロビジョニングするシステム及び方法を提供する。この開示では、サーバラック内で動作するサーバ装置は、サービス又は交換を必要とする可能性がある。サーバラックで動作するサーバ装置は、特定のファームウェア及びカスタム設定で動作することができる。しかし、サービス又は交換時に、サーバコンポーネントを、異なるファームウェア、カスタム設定、又は、カスタム設定なしでプロビジョニングすることができる。例えば、サービス又は交換時に、サーバコンポーネントを、修復モード又は工場モードで動作するようにプロビジョニングすることができる。本発明は、サービス又は交換後のサーバ装置及び／又はコンポーネントのファームウェア及びカスタム設定を自動的にプロビジョニングする効果的な方法を提供する。

いくつかの実施形態では、サーバ装置の物理的位置及び関連する装置情報が決定される。また、サーバ装置の設置場所やＩＤ情報に基づいて、サーバ装置のファームウェアパッケージを特定することができる。ファームウェアは、サーバ装置の設置場所やＩＤ情報に基づいてインストールすることができる。本明細書において、「一実施形態」、「１つの実施形態」等は、記載される特定の特徴、構造又は特性が本発明の少なくとも１つの実施形態に含まれることを意味する。本明細書におけるかかる語句の出現によって、必ずしも全ての語句が同じ実施形態を指すとは限らない。

図１は、いくつかの実施形態による、サーバ装置のファームウェア及びカスタム設定を自動的にプロビジョニングする例示的なシステム１００を示す図である。いくつかの実装において、システム１００は、複数のサーバ１０４を含むサーバラック１０２を有し得る。各サーバ１０４は、各種コンポーネント（例えば、１つ以上の中央処理ユニット（ＣＰＵ）１１２と、１つ以上のサービスコントローラ（例えば、管理コントローラ（ＭＣ）１１４と、１つ以上のセンサ１１８と、１つ以上のストレージデバイス１２０と、既知であるが図示されていないその他のコンポーネント（例えば、電源、ファン、メモリモジュール等）を有する。いくつかの実施形態では、ＭＣは、ベースボード管理コントローラ（ＢＭＣ）を有する。ここで説明される方法は、特定のサービスコントローラ又はサービスコントローラの集合に限定されない。

ＣＰＵ１１２は、複数のコアを有しており、サーバ１０４のメインプロセッサである。いくつかの実施形態では、少なくとも１つのサーバ１０４は、複数のＣＰＵ１１２を含むことができる。ここで、「ラックシステム」、「サーバ」、「ハードドライブ」、「サービスコントローラ」等のように、本明細書の例における単数形の使用は、各種実施形態における複数形の使用を排除するものではないことを理解されたい。

いくつかの実施形態では、ＭＣ１１４は、通常、コンピュータ（通常、サーバ）のマザーボードに組み込まれた専用のマイクロコントローラ（マイクロプロセッサ）である。例えば、ＭＣ１１４は、システム管理ソフトウェアとプラットフォームハードウェアとの間のインタフェースを管理し、センサを用いてサーバ１０４の物理的状態を監視し、独立した接続（例えば、帯域外）を介してシステムアドミニストレータ１０８と通信する。システム管理ソフトウェアについては以下で詳しく説明する。ＭＣ１１４は、インテリジェントプラットフォーム管理インタフェース（ＩＰＭＩ）の一部であり、ＣＰＵ１１２から独立して動作することができる。

いくつかの実施形態では、サーバ１０４に組み込まれた異なるタイプのセンサは、サーバコンポーネントの設置場所及びサーバコンポーネントのＩＤ情報等のパラメータをＭＣ１１４に報告する。サーバコンポーネントは、サーバ１０４、ストレージデバイス、ネットワークスイッチ、ターミナルサーバ、配電ユニット、サーバラック１０２等を含むがこれらに限定されない各種ＩＴコンポーネントとすることができる。いくつかの実施形態では、サーバラック１０２は、異なるタイプのサーバコンポーネント（例えば、サーバラック１０２から操作することができるサーバ又は他のＩＴアセット等）を含むことができる。例えば、サーバラック１０２又はサーバ１０４自身は、サーバコンポーネントを監視するように構成された無線周波数識別（ＲＦＩＤ）タグを有する。或いは、サーバラック１０２又はサーバ１０４自身は、電気的に消去可能なプログラマブルＲＯＭ（ＥＥＰＲＯＭ）（図示省略）を含むことができ、ＥＥＰＲＯＭは、再プログラミング及び確実性のある読み取りをサポートする。さらに、いくつかの実施形態では、ＩＤ情報は、ＭＣ１１４又はラック管理コントローラ（ＲＭＣ）（図示省略）内に構築された互換性のあるハードウェア回路及びソフトウェアによって読み取ることができる。いくつかの実施形態では、センサ１１８は、ＭＣ１１４を通じてＩＰＭＩによって監視することができるデバイスである。

図２は、本発明の一実施形態によるサーバラック１０２又はサーバ１０４内に設置されたセンサを実装することによって追跡されるサーバコンポーネントのブロック図である。例示的な実施形態として、図２は、ＭＣ１１４又はラック管理コントローラ（ＲＭＣ）（図示省略）を介して追跡される全てのアセットに取り付けられたＲＦＩＤタグ２３０，２４０，２５０を実装する。いくつかの実施形態では、ＲＦＩＤタグ２５０は、各サーバ１０４に関連付けられている。ＲＦＩＤタグ２４０は、サーバ１０４のクラスタに関連付けることができる。ＲＦＩＤタグ２３０は、サーバラック１０２に関連付けることができる。一実施形態において、ＭＣ１１４又はラック管理コントローラ（ＲＭＣ）（図示省略）は、アセットを制御する機構によりメンテナンスされてもよい。ＲＦＩＤタグ２３０，２４０，２５０は、ＭＣ１１４内の適切な情報（例えば、記述、所有者、装置のシリアル番号、位置ＩＤ等を含む）と同期することができる。一実施形態では、アセット上の以前のバーコードを同期に利用することができる。バーコードに関連付けられた情報がＭＣ１１４で同期化され、さらに、アセットの新たなＲＦＩＤタグ２３０，２４０，２５０と関連付けられる。

本発明のいくつかの実施形態では、ＲＦＩＤタグ２３０，２４０，２５０はパッシブタグである。つまり、タグ２３０，２４０，２５０は、自身のバッテリ又は他の電源を含まない。パッシブタグは、通常、より安価な材料とコンポーネントで構成されているので、実装に必要なコストが少なくて済む。アンテナ等の外部ソースは、パッシブタグをアクティブにして、タグが信号を送信するようにする。この信号は、ＩＤ情報と、ＭＣ１１４又はラック管理コントローラ（ＲＭＣ）（図示省略）によって追跡されるシステムコンポーネントの設置場所と、を有する。そして、外部ソースは、ＭＣ１１４又はラック管理コントローラ（ＲＭＣ）（図示省略）のシステムコンポーネントにより送信されている信号を読み取ることができる。本発明のいくつかの実施形態では、この外部ソースは、タグをアクティブにしたソースと同じソースである。例えば、外部ソースは、ＲＦＩＤ読み取りモジュールを有する。

本発明の別の実施形態では、ＲＦＩＤタグ２３０，２４０，２５０は、パッシブ、セミパッシブ又はアクティブタグのうち何れか１つ又は組み合わせを含むことができる。セミパッシブタグには、タグに電力を供給するバッテリが含まれるが、伝送信号をアンテナに送信するのに必要な電力がない。アクティブタグには、タグをオンにする電源と、アンテナへの信号の送信をサポートする電源が含まれる。

本発明のいくつかの実施形態では、ＲＦＩＤタグ２３０，２４０，２５０の実際のサイズは、タグが識別するコンポーネントの実際の高さより小さい。例えば、ＲＦＩＤタグのサイズは１インチ×１インチであってもよい。他の実施形態では、タグは、内部が発泡材で、外部がマイラー樹脂（Mylar）である。これは、タグの正常動作に影響する各種外力（例えば、引っ張る、捻る、叩く等）からタグを保護する。本発明のいくつかの実施形態では、ＲＦＩＤタグ２３０，２４０，２５０は、タグに電力を供給するアンテナに対して水平に向けられており、タグの正常動作を容易にする。さらに、ＲＦＩＤタグ２３０，２４０，２５０は、識別しているサーバコンポーネントから少なくとも１／４インチオフセットして、コンポーネントとタグからのＲＦ信号との間の干渉を低減する。一実施形態では、覆い（boot）又は他の構造が、サーバコンポーネントからのタグのオフセットを容易にするために用いられてもよい。

さらに別の実施形態では、各種アタッチメントを用いて、ＲＦＩＤタグ２３０，２４０，２５０をサーバコンポーネントに取り付けることができると想定される。例えば、クリップ、タイ、接着材料のうち少なくとも１つ又はこれらの組み合わせを用いて、タグをコンポーネントに取り付けることができる。この取り付けは、ＲＦＩＤタグの正常動作のために、他の要件（例えば、方向やオフセット等）を維持するような方法で使用することができる。センサ１１８は、それらが割り当てられるサーバコンポーネントを識別するように構成された任意の装置であってもよいことを理解されたい。上述したＲＦＩＤ装置は単なる一例であり、本発明の内容を限定するものではない。当業者は、本開示に従って任意の装置をフレキシブルに選択することができる。サーバコンポーネントの設置場所を決定すると、サーバ装置の設置場所及びＩＤ情報に基づいて、サーバコンポーネントのファームウェアパッケージを識別することができる。

図３Ａは、いくつかの実施形態による例示的なシステム管理ソフトウェア３００を示す図である。システム管理ソフトウェア３００は、セキュアなクラウドサーバを有することができる。本発明の別の実施形態では、システム管理ソフトウェアは、ローカルサーバを有することができる。システム管理ソフトウェア３００は、パッケージヘッダ３０１を有するデータ構造として構成することができる。パッケージヘッダ３０１は、証明書３０２のアレイを有することができる。さらに、システム管理ソフトウェア３００は、サーバシステム情報３０３及びサーバシステムＩＤ３０４を有することができる。個々のコンポーネントの情報及びＩＤは、サーバシステム情報３０３及びサーバシステムＩＤ３０４内にそれぞれ含まれ得る。さらに、システム管理ソフトウェア３００は、パッケージデータ３０５、オプションデータ３０６及びイメージデータディレクトリ３０７を有することができる。イメージデータディレクトリ３０７は、イメージ３０８Ｎを有することができる。イメージファイル３０８Ｎは、製造バージョンとして検証された様々なファームウェアを有することができる。

図３Ｂは、一実施形態によるシステム管理ソフトウェア３００を用いてファームウェアパッケージをアップロードする方法３５０のブロック図である。工程３５１において、ファームウェアイメージ３０８Ｎが、オペレータ３６０によって、サーバコンポーネントから収集される。工程３５２において、サーバコンポーネント情報及びＩＤが、システム管理ソフトウェア３００に入力される。工程３５３において、ファームウェアパッケージが準備される。ファームウェアの準備については図４〜図８を参照して以下に詳細に説明する。各サーバコンポーネントには、所有者の秘密鍵３６１及び公開鍵のペアが関連付けられている。公開鍵のペアについては後述する。工程３５４において、署名ツールが用いられる。秘密鍵３６１は、サインを生成して、セキュアイメージを検索又はサーバコンポーネントを暗号化するための署名を生成するのに用いられる。工程３５５において、秘密鍵３６１を用いて、ファームウェアパッケージを署名し、証明書をインストールする。工程３５６において、現在のファームウェアが、システム管理ソフトウェア３００にアップロードされる。

図４は、一実施形態による、サーバコンポーネントのファームウェアを自動的にプロビジョニングする例示的な方法４００のブロック図である。工程４１０において、サーバコンポーネントが受信され、工場モードで動作するようにプロビジョニングされる。例えば、サーバコンポーネントは、標準バージョンのファームウェア及び標準設定がプロビジョニングされた、新たに構築されたサーバマザーボードを有することができる。いくつかの実施形態では、受信された新たなサーバマザーボードが製造ラインで構築される場合、ウェアバージョン及びファームウェア設定が、基本検証に基づいて予め決定される。いくつかの実施形態では、基本検証は、サーバマザーボード上のハードウェア機能の標準テスト項目を有し、マザーボードの設定は、カスタム設定テスト項目の代わりに、工場テスト項目に用いるために構成される。この状態において、各ファームウェアは、工場モードで構成される。その後、オペレータは、サーバコンポーネントをサーバ１０４にインストールすることができる。サーバコンポーネントに関連する使用可能なファームウェアのＩＤでサーバ１０４及びサーバラック１０２にログインすることができる。このファームウェアは、このサーバコンポーネント及びその設置場所に関連する。

工程４２０において、サーバコンポーネントをサーバ１０４及びサーバラック１０２にインストールすると、ＭＣ１１４又はラック管理コントローラ（ＲＭＣ）は、タグからＩＤを読み取ることによって、設置場所を決定することができる。工程４２０において、決定された設置場所に基づいて、ＭＣ１１４又はラック管理コントローラ（ＲＭＣ）が、システム管理ソフトウェア（例えば、クラウドベースのサーバ）にログインすることができ、サーバ１０４及びサーバラック１０２内に位置するサーバコンポーネントに適したファームウェアパッケージをダウンロードすることができる。その後、ＭＣ１１４は、サーバコンポーネント内のファームウェアをアップグレード又はダウングレードして、サーバコンポーネントをユーザモードで動作するようにプロビジョニングする。例えば、ユーザモードにおいて、サーバコンポーネントは、サーバ１０４にインストールされたサーバマザーボードと、互換性があるバージョンファームウェア及び標準設定がプロビジョニングされたサーバラック１０２と、を有することができる。

工程４３０において、サーバコンポーネントをサーバ１０４及びサーバラック１０２にインストールすると、ＭＣ１１４又はラック管理コントローラ（ＲＭＣ）は、タグからＩＤを読み取ることによって設置場所を決定することができる。設置場所に基づいて、ＭＣ１１４又はラック管理コントローラ（ＲＭＣ）は、システム管理ソフトウェア（例えば、クラウドベースのサーバ）にログインして、正確なサーバ１０４及び正確なサーバラック１０２に位置するサーバコンポーネントに適した設定パッケージをダウンロードすることができる。その後、ＭＣ１１４は、サーバコンポーネント内の設定をプログラムして、サーバコンポーネントをカスタムモードで動作するようにプロビジョニングする。例えば、顧客は、最適なハードウェアパフォーマンスを得るために、自身のプライベート設定をカスタマイズすることができる。

場合によっては、個別の設定は、独自のプログラミング方法を必要とする。例えば、ストレージコントローラは、全体の帯域インタフェース全体に予めプログラムされた設定（例えば、LSI Storlib機能）をサポートすることができる。ＭＣ１１４は、Ｉ２Ｃ（Inter-Integrated Circuit）バスを用いて、サーバコンポーネントのカスタム設定をプログラムすることができる。プロトコルは、Ｉ２Ｃ上の管理コンポーネントトランスポートプロトコル（ＭＣＴＰ）、Ｉ２Ｃ及びプラットフォーム環境制御インタフェース（ＰＥＣＩ）等を含むことができる。工程４３０において、カスタム設定がプロビジョニングされると、ファームウェアは、カスタムモードで動作カスタムモードにおいて、サーバコンポーネントは、互換性があるバージョンファームウェア及びカスタム設定を用いてプロビジョニングされたサーバラック１０２のサーバ１０４にインストールされたサーバマザーボードを有することができる。任意の機械コンポーネントと同様に、サーバコンポーネントは、ドライブの読み書きパフォーマンスを低下させるか、ドライブの故障を引き起こす操作上の問題が発生する可能性がある。

工程４４０において、ユーザーは、返品保証（ＲＭＡ）フォームを有するシステムコンポーネントを用いて、必要な保証請求をベンダのカスタマサービスに送ることができる。サービスエンジニアは、システム管理ソフトウェアのコンポーネント障害のプロファイルを記入することができる。いくつかの実施形態では、サービスエンジニアは、コンポーネント障害の設定を検索することができる。さらに、サービスエンジニアは、設定をシステム管理ソフトウェアにアップロードすることができる。本発明のいくつかの実施形態では、システム管理ソフトウェアは、セキュアなクラウドサーバを有することができる。本発明の別の実施形態では、システム管理ソフトウェアは、ローカルサーバを有することができる。次に、サービスエンジニアは、サーバコンポーネント内のファームウェアをプログラムして、修復モードで動作するようにサーバコンポーネントをプロビジョニングする。サービスエンジニアがサーバコンポーネントを修復するとき、ＭＣ１１４は、その“状態”変数を修復モードとして認識することができる。サーバコンポーネントがサーバ１０４及びサーバラック１０２にインストールされると、ＭＣ１１４は、その状態が修復モードであると認識することができる。ＭＣ１１４は、帯域内、帯域外又はＥＥＰＲＯＭを介してファイルをロードすることにより、古いファームウェア設定を再プログラムすることができる。例えば、修復モードでは、サーバコンポーネントは、サーバ１０４にインストールされたサーバマザーボードと、標準バージョンのファームウェア及び標準設定がプロビジョニングされたサーバラック１０２と、を有することができる。サーバコンポーネントをユーザーに戻すと、サーバコンポーネントは、サーバラック１０２のサーバ１０４に再び挿入され、ユーザモードで動作するようにプロビジョニングされる（４２０）。サーバコンポーネントが置換される場合において、工場モードで動作するようにプロビジョニングされた新たなサーバコンポーネントがユーザ（４１０）に提供され、プロセスは、再度プロビジョニングされるように繰り返される。

図５Ａ〜５Ｂは、一実施形態による、ユーザモードで、システム管理ソフトウェア３００を用いて、ファームウェアパッケージをアップグレード又はダウングレードする例示的な方法５００のブロック図である。オペレータ３６０が、インテリジェントプラットフォーム管理インタフェース（ＩＰＭＩ）コマンド又は表現状態転送（ＲＥＳＴ）若しくはＲＥＳＴｆｕｌ命令をＭＣ１１４に送信すると、ＭＣ１１４は、その“状態”変数を向上モードからユーザモードに転送することを要求する。工程５０１において、ＭＣ１１４は、特定のＩＰアドレス及びドメインネームサーバを有するクラウドサーバに接続するために、イントラネット接続を検査する。工程５０２において、ＭＣ１１４は、システム管理ソフトウェア３００に対してファームウェアパッケージの要求を送信する。この要求は、サーバ１０４内のサーバコンポーネントのＩＤを参照して、システム管理ソフトウェア３００内で同一のＩＤを有する最新のファームウェアパッケージを検索する。システム管理ソフトウェア３００からの応答が工程５０３で受信され、要求の受信とファームウェアパッケージの送信を指示する（工程５０４）。

システム管理ソフトウェア３００が同じＩＤを有する最新のファームウェアパッケージをＭＣ１１４に送信した後、工程５０５において、ＭＣ１１４は、サーバ製品の公開鍵５６１を用いたファームウェアパッケージ証明書を検査する。公開鍵５６１は、セキュアイメージをデコード又はサーバコンポーネントを復号するのに用いられる。工程５０６及び５０８において、ファームウェア証明書の安全性が判断される。ファームウェア証明書が安全でないと判断された場合、方法５００は工程５０７に進み、故障イベントが返される。工程５０９及び５１１において、サーバコンポーネントＩＤ及びサーバコンポーネント情報とファームウェアパッケージ及びサーバ製品のレコードとを比較して、それらが同じか否か判断する。比較によって両者が同じではないと判断した場合、方法５００は工程５０７に進み、故障イベントが返される。比較によって両者が同じであると判断した場合、ＭＣ１１４は、ファームウェアパッケージが最初に署名されたものであることを保証する。ファームウェアリストが工程５１２で生成される。工程５１３において、検証されたファームウェアパッケージを用いて、サーバコンポーネント内のファームウェアバージョンをアップグレード／ダウングレードする。故障が発生した場合、パッケージは、アップグレード／ダウングレードに適していない。よって、オペレータは、イベントログのエラー報告を再検査し、修正された動作を実行する。いくつかの実施形態では、修正された動作は、例えば、正確な署名が署名されたファームウェアパッケージをシステム管理ソフトウェアに再アップロードする工程を有することができる。これは、イベントログのエラー報告が、不正確なサインが検出されたことを示す場合である。

図６Ａ−１〜６Ａ−２は、一実施形態による、サーバコンポーネント内の設定をプログラミングして、サーバコンポーネントを、カスタムモードで動作するようにプロビジョニングする例示的な方法６００のブロック図である。オペレータ３６０が、インテリジェントプラットフォーム管理インターフェース（ＩＰＭＩ）コマンド又は表現状態遷移（ＲＥＳＴ）若しくはＲＥＳＴｆｕｌ命令をＭＣ１１４に送信すると、ＭＣ１１４がその“状態”変数をユーザモードからカスタムモードに転送することを要求する。工程６０１において、サーバ装置及びサーバラック内のサーバコンポーネントの位置が決定される。カスタムファームウェア設定が不揮発性メモリからロードされ得る。ソフトウェア読み書きインタフェースを呼び出して、カスタムファームウェア設定をサーバコンポーネントにプログラムする。例えば、ＭＣ１１４は、Ｉ２Ｃインターェース及びＰＣＩ（Peripheral Component Interconnect）インタフェースを介した管理コンポーネントトランスポートプロトコル（ＭＣＴＰ）を用いて、ストレージコントローラ及びカスタムファームウェア設定プログラムのカスタムファームウェア設定をサーバコンポーネント装置にロードすることができる。

工程６０２において、ＭＣ１１４は、サーバコンポーネントの設置場所及びサーバコンポーネントの識別情報に基づいて、サーバコンポーネントのカスタムファームウェアリストを生成する。工程６０３において、ＭＣ１１４は、インストールされるインタフェースをサポートするか否かを判断する。

ＭＣ１１４がインタフェースをサポートしていない場合、ＢＩＯＳ（基本入出力システム）を用いて、そのカスタムファームウェア設定をロードすることができる別の方法を実装することができる。プロセス６００は工程６１１に進み、エンティティのカテゴリが識別される。次に、プロセスは工程６１２に進み、システムマネジメント割り込み（ＳＭＩ）番号フラグがアサートされ、カスタムファームウェア設定をロードするようにＢＩＯＳに通知する。工程６１３において、要求が受信され、検査されたことを通知するＢＩＯＳからの肯定応答が受信される。肯定応答が受信された場合、プロセスは工程６１４から工程６０８に進み、完成ステージは、状態が正常であると判断し（工程６０８）、工程６１０において、アップロードが成功したと記録される。肯定応答が受信されない場合、プロセスは工程６１５に進み、プロセスが「タイムアウト」であると判断する。この時点で、工程６０９において、プロセスは要求を繰り返し、工程６１０において「成功」通知を戻すか工程６０３においてプロセスを再開する。

ＭＣ１１４がインタフェースをサポートする場合、方法６００は工程６０４に進み、サーバコンポーネントのカスタム設定が準備される。

図６Ｂを参照する。工程６０５において、プログラム設定がサーバコンポーネントにインストールされる。具体的には、工程６１６において、ＭＣ１１４は、サーバコンポーネント上のストレージコントローラにカスタム設定をプログラムする。工程６１７において、カスタム設定が準備される。カスタムファームウェア設定は、不揮発性メモリからロードされる。ソフトウェア読み書きインタフェースが呼び出され、カスタムファームウェア設定をサーバコンポーネントにプログラムする。例えば、ＭＣ１１４は、Ｉ２Ｃインタフェース（工程６１９）又はＰＣＩインターフェースを介した管理コンポーネントトランスポートプロトコル（ＭＣＴＰ）（工程６２０）を用いて、ストレージコントローラのカスタムファームウェア設定及びカスタムファームウェア設定プログラムをサーバコンポーネント装置にロードする。工程６２１において、インストールされると、ストレージコントローラからの状態が収集される。

図６Ａ−１を参照する。ストレージコントローラのカスタムファームウェア設定、及び、カスタムファームウェア設定プログラムをサーバコンポーネント装置にロードした後、工程６０６において、設定が検証される。検証ステージが、状態が異常である（工程６０７）又は正常である（工程６０８）と判断した場合、工程６１０において、インストールが成功であると記録される。

いくつかの実施形態では、カスタムファームウェア設定は、サーバコンポーネント又はサーバ１０４の不揮発性メモリに保存することができる。例えば、カスタムファームウェア設定は、ＭＣ１１４のＥＥＰＲＯＭ、ＵＥＦＩ ＢＩＯＳフラッシュチップ、又は、ＲＭＣのＥＥＰＲＯＭに保存することができる。カスタムファームウェア設定のフォーマットは、装置のソフトウェア読み書きインタフェースにより制限され、カスタムファームウェア設定を装置に書き込むには、ＢＭＣ、ＵＥＦＩ ＢＩＯＳ又はＲＭＣに組み込まれた独立したソフトウェアインタフェースが用いられる。

図７は、一実施形態による、サーバコンポーネント内の設定をプログラミングして、サーバコンポーネントを、カスタムモードで動作するようにプロビジョニングする別の例示的な方法７００のブロック図である。別の例示的なプロセスでは、ＵＥＦＩ（unified extensible firmware interface）ＢＩＯＳ（基本入出力システム）を用いて、そのカスタムファームウェア設定をロードすることができる。先ず、工程７０２において、ＭＣ１１４には、カスタムファームウェア（ＢＩＯＳ）の設定及び構成がクエリーされる。工程７０３において、ＭＣ１１４は、ストレージコントローラのカスタムファームウェア（ＢＩＯＳ）の設定及び構成と、カスタムファームウェア設定プログラムとを、サーバコンポーネント装置にロードするか否かを判断する。ＢＩＯＳ設定がロードされるように構成されていると判断される場合、プロセス７００は工程７０４に進み、カスタム設定が準備される。工程７０５において、プログラム設定は、ファームウェア不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）に保存され、ＭＣ１１４に通知される（工程７０６）。プロセスは工程７０７に進み、システムをブートして、カスタムファームウェアのインストールを終了するか否かを判断する。インストールプロセスでエラーが発生した場合、プロセス７００は工程７０９に進み、ＢＩＯＳ ＰＯＳＴシーケンスロードプロセスが繰り返される。

図８Ａ〜８Ｂは、一実施形態による、ＲＭＡ状態でのファームウェア設定を読み出す別の例示的な方法８００のブロック図である。ＲＭＡ状態の間、故障サーバコンポーネントが受信されると、サービスエンジニア３６２は、サーバコンポーネント情報及びサーバコンポーネントＩＤをカスタマプロファイルとして保存する。ユーザは、用途毎に新たなカスタム設定を有し得るので、サービスエンジニアは、故障したサーバコンポーネントから新たなカスタムファームウェア設定を取得したり、顧客に対して、サービスサーバコンポーネントから既存のカスタムファームウェア設定を提供するように要求することができる。

工程８０１において、サービスエンジニアは、ＩＰＭＩコマンド又はＲＥＳＴ若しくはＲＥＳＴｆｕｌ命令をＭＣ１１４に送信し、ＭＣ１１４に対して、全てのエンティティのファームウェアカスタム設定を収集するように要求する。工程８０２において、ＭＣ１１４は、そのソフトウェアインタフェースが既存の設定を検索するように構成されているか否かを判断する。ＭＣ１１４が既存の設定を検索するように構成されている場合、プロセス８００は工程８０３に進み、ソフトウェアインタフェースが配置される。いくつかの実施形態では、ファームウェアの既存／カスタム設定の各々は、プライベートフォーマットを有する。ＭＣ１１４は、ファームウェア設定を、テキストファイル、バイナリファイル、ＪＳＯＮ（JavaScript（登録商標） Object Notation）、又は、帯域内サービス及び帯域外サービスを介してＭＣ１１４から配信可能なファイルフォーマットとして保存することができる。工程８０５において、プロセス８００は、出力先を判断する。いくつかの実施形態では、サービスエンジニアは、ファイルをシステム管理ソフトウェア３００にアップロードすることを決定するか（工程８０６）、ＭＣ１１４の影響により、サーバコンポーネントのＥＥＰＲＯＭ、サーバラック１０２のＥＥＰＲＯＭ、又は、ＲＭＣのＥＥＰＲＯＭにバックアップを実行する（工程８０７）。

ファイルをシステム管理ソフトウェア３００にアップロードするか（工程８０６）、サーバコンポーネントのＥＥＰＲＯＭに対してバックアップを実行した後（工程８０７）、工程８０８において、ＭＣ１１４は、アップロードが完了したか否かを判断する。完了ステージは、状態が正常であると判断すると（工程８０９）、工程８１１において、アップロードが成功したと記録される。

ＭＣ１１４が既存の設定を検索するように構成されていない場合、ＢＩＯＳ（基本入出力システム）を用いて、そのカスタムファームウェア設定をロードする他の方法を実行することができる。プロセス８００は工程８１２に進み、エンティティのカテゴリが識別される。次に、プロセスは工程８１３に進み、システム管理割り込み（ＳＭＩ）番号フラグがアサートされ、カスタムファームウェア設定をロードするようにＢＩＯＳに通知する。工程８１４において、要求を通知したＢＩＯＳからの肯定応答を受信して、検査する。肯定応答を受信した場合、プロセスは工程８１５から工程８０９に進み、完了ステージが、状態が正常であると判断すると（工程８０９）、工程８１１において、アップロードが成功であると記録される。肯定応答を受信していない場合、プロセスは工程８１６に進み、プロセスが「タイムアウト」であると判断する。この時点で、工程８１０において、プロセスは、要求を繰り返し、工程８１１において「成功」通知を戻すか、工程８０２においてプロセスを再開する。

以上、本発明の各種実施形態について説明したが、これらは例示に過ぎず、限定的ではないことを理解されたい。本発明の趣旨又は範囲から逸脱することなく、本発明の開示内容に基づいて、開示された実施形態に対する多数の変更を加えることができる。したがって、本発明の幅及び範囲は、上記の実施形態の何れかによって限定されるべきではい。むしろ、本発明の範囲は、添付の特許請求の範囲及びその均等物によって定義されるべきである。

本発明は、１つ以上の実施形態に関して図示及び説明されているが、本明細書及び図面を読んで理解すると、当業者であれば、同等の変更及び修正を行うことができるであろう。また、本発明の特定の特徴は、複数の実施形態のち何れか１つのみに関して開示されているが、かかる特徴は、任意の所定又は特定のアプリケーションに対して望ましく、且つ、有利である場合、他の実施形態の１つ以上の他の特徴と組み合わせることができる。

本明細書で使用する用語は、特定の実施形態のみを説明するためのものであり、本発明を制限するものではない。本明細書で使用されるように、単数形“a”、“an”及び“the”は、文脈がそうでないことを明確に示さない限り、複数形も含むことが意図される。さらに、詳細な説明及び／又は特許請求の範囲において、“including”、“includes”、“having”、“has”、“with”又はこれらの変形が使用される限り、これらの用語は、「備える“comprising”」と同様の態様で包含される。

本発明の好ましい実施形態を上述したように開示したが、これらは決して本発明を限定するものではなく、当業者であれば誰でも、本発明の趣旨及び範囲を逸脱しない範囲で各種の変更や修正を加えることができる。従って、本発明の保護範囲は、特許請求の範囲で特定した内容を基準とする。

１００…システム
１０２…サーバラック
１０４…サーバ
１０６…ネットワーク
１０８…システムアドミニストレータ
１１０…コンピュータ
１１２…ＣＰＵ
１１４…ＢＭＣ
１１８…センサ
１２０…ストレージデバイス
２３０，２４０，２５０…ＲＦＩＤタグ
３６０…オペレータ
５００，６００，７００，８００…方法
５０１〜５１３，６０１〜６２１，７０１〜７０９，８０１〜８１６…工程

Claims (11)

1. サーバ装置のファームウェア及びカスタム設定をプロビジョニングする方法であって、
   ラック装置にインストールされたサーバ装置の設置場所及び識別情報を決定する工程であって、前記サーバ装置が第１動作モードで動作し、前記第１動作モードは、工場モード及び修復モードの少なくとも１つを有する、工程と、
   前記サーバ装置の前記設置場所及び識別情報に基づいて、前記サーバ装置のファームウェアパッケージを識別する工程と、
   前記サーバ装置の前記決定された設置場所及び識別情報に基づいて、前記ファームウェアをインストールする工程と、
   を有することを特徴とする方法。
2. 修復モードは、サービスの前にサービスエンジニアにより構成され、クラウドサーバにアップロードされたファームウェアバージョン及びカスタム設定を実行することを特徴とする請求項１に記載の方法。
3. 前記ファームウェアパッケージをインストールする工程は、
   前記ファームウェアのインストールを容易にするために、ベースボード管理コントローラ（ＢＭＣ）を用いて、基本入出力システム（ＢＩＯＳ）ファームウェアイメージを取得する工程を有することを特徴とする請求項１に記載の方法。
4. 前記ファームウェアパッケージをインストールする工程は、
   前記ファームウェアのインストールを容易にするために、ベースボード管理コントローラ（ＢＭＣ）を用いて、ＣＰＬＤ（Complex Programmable Logic Device）ファームウェアイメージを取得する工程を有することを特徴とする請求項１に記載の方法。
5. 前記設置場所を決定する工程は、
   前記ラック装置及び前記設置場所に関連するＲＦＩＤタグを読み取る工程、又は、電気的に消去可能なプログラマブルＲＯＭ（ＥＥＰＲＯＭ）から前記サーバ装置の識別情報を検索する工程、を含むことを特徴とする請求項１に記載の方法。
6. 前記ファームウェアパッケージは、セキュアに保護するクラウドサーバに保存され、
   ＢＭＣを用いて、前記クラウドサーバからファームウェアイメージを取得し、
   前記ファームウェアイメージがセキュアであるか否かを検証し、
   前記ファームウェアパッケージと前記サーバ装置の識別情報との間でサーバシステムのＩＤを比較し、
   前記ファームウェアパッケージはデータ構造として構成されており、
   前記データ構造は、
   証明書のアレイを有するパッケージヘッダと、
   サーバ装置情報と、
   サーバ装置ＩＤと、
   ファームウェアパッケージデータと、
   ファームウェアの検証に対応するイメージファイルと、
   のうち少なくとも１つを有することを特徴とする請求項１に記載の方法。
7. 前記ファームウェアパッケージのインストールは、前記サーバ装置を、カスタムモードで動作するように構成することを特徴とする請求項１に記載の方法。
8. 前記ファームウェアパッケージのインストールは、前記サーバ装置を、ユーザモードで動作するように構成することを特徴とする請求項１に記載の方法。
9. 前記ユーザモードは、前記第１動作モードからファームウェアをアップグレードすることを特徴とする請求項８に記載の方法。
10. 前記ユーザモードは、前記第１動作モードからファームウェアをダウングレードすることを特徴とする請求項８に記載の方法。
11. 前記ユーザモードは、前記第１動作モードからプロビジョニングした追加の設定を実行することを特徴とする請求項８に記載の方法。

Images