管理対象デバイスでのファームウェアの更新

Lenovo XClarity Administrator Web インターフェースから、シャーシ、サーバー、ストレージ・システム、およびスイッチなどの管理対象デバイスのファームウェア更新について、ダウンロード、インストール、管理を実行できます。ファームウェア・コンプライアンス・ポリシーを管理対象デバイスに割り当て、それらのデバイスのファームウェアの適合状態が保たれるようにすることができます。検証されたファームウェア・レベルが推奨される事前定義ポリシーと一致しない場合、ファームウェア・コンプライアンス・ポリシーを作成および編集することもできます。

手順

次の図は、管理対象デバイスのファームウェア更新のワークフローを示しています。

1. ファームウェア更新リポジトリーの管理

   ファームウェア更新リポジトリーには、管理対象デバイスに適用できる使用可能な更新および更新パッケージのカタログが含まれます。

   カタログには、 XClarity Administrator でサポートされているすべてのデバイスに対して、現在使用できるファームウェア更新に関する情報が含まれます。このカタログでは、ファームウェア更新がデバイス・タイプごとに分類されています。カタログを最新の情報に更新すると、XClarity Administrator は Lenovo の Web サイト (メタデータ .xml または .json および readme .txt ファイルを含む) から利用可能な最新のファームウェア更新に関する情報を取得し、その情報をファームウェア更新リポジトリーに保存します。ペイロード・ファイル (.exe) がダウンロードされていません。カタログの更新について詳しくは、製品カタログの更新を参照してください。

   新しいファームウェア更新が使用可能になったとき、管理対象デバイスでそのファームウェアを更新するには、最初に更新パッケージをダウンロードする必要があります。カタログを更新しても、更新パッケージが自動的にダウンロードされるわけではありません。ファームウェア更新リポジトリーページにある製品カタログ表では、どの更新パッケージがダウンロード済みで、どれがダウンロード可能かを識別できます。

   ファームウェア更新をダウンロードするには、いくつかの方法があります。

   • ファームウェア更新リポジトリー・パック

     ファームウェア更新リポジトリー・パックとは、最もサポートされているすべてのデバイスに対する XClarity Administrator のリリースと同時に使用できる、最新のファームウェアのコレクションであり、更新済みのデフォルトのファームウェア・コンプライアンス・ポリシーです。これらのリポジトリー・パックは、インポートされた後管理サーバーの更新ページで適用されます。ファームウェア更新リポジトリー・パックを適用すると、パック内の各更新パッケージがファームウェア更新リポジトリーに追加され、すべての管理可能デバイスでデフォルトのファームウェア・コンプライアンス・ポリシーが自動的に作成されます。この事前定義済みポリシーはコピーすることはできますが、変更することはできません。

     以下のリポジトリー・パックを使用できます。

     • lnvgy_sw_lxca_cmmswitchrepox-x.x.x_anyos_noarch。すべての CMM および Flex System スイッチのファームウェア更新が含まれます。
     • lnvgy_sw_lxca_storagerackswitchrepox-x.x.x_anyos_noarch。すべての RackSwitch スイッチと Lenovo Storage デバイスのファームウェア更新が含まれます。
     • lnvgy_sw_lxca_systemxrepox-x.x.x_anyos_noarch。すべての Converged HX シリーズ、Flex System、NeXtScale、および System x サーバーのファームウェア更新が含まれます。
     • lnvgy_sw_thinksystemrepox-x.x.x_anyos_noarch。すべての ThinkAgile および ThinkSystem サーバーのファームウェア更新が含まれます。
     • lnvgy_sw_lxca_thinksystemv2repox-x.x.x_anyos_noarch。すべての ThinkAgile および ThinkSystem V2 サーバーのファームウェア更新が含まれます。
     • lnvgy_sw_lxca_thinksystemv3repox-x.x.x_anyos_noarch。すべての ThinkAgile および ThinkSystem V3 サーバーのファームウェア更新が含まれます。
   • UpdateXpress System Packs (UXSPs)
     UXSP には、オペレーティング・システムごとに分類された利用可能な最新のファームウェアおよびデバイス・ドライバーの更新が含まれています。UXSP をダウンロードすると、カタログに示されたバージョンに基づいて UXSP が XClarity Administrator によりダウンロードされ、ファームウェア更新リポジトリーに更新パッケージが保存されます。UXSP をダウンロードすると、UXSP 内の各ファームウェア更新がファームウェア更新リポジトリーに追加され、「個別更新」タブにリストされ、以下の名前を使用してすべての管理可能デバイスにデフォルトのファームウェア・コンプライアンス・ポリシーが自動的に作成されます。この事前定義済みポリシーはコピーすることはできますが、変更することはできません。

     • {uxsp-version}-{date}-{server-short-name}-UXSP (例: v1.50-2017-11-22- SD530-UXSP)
     ファームウェア更新: リポジトリー

     「」ページから UXSP をダウンロードまたはインポートした場合、ファームウェア更新のみがダウンロードされ、リポジトリーに保存されます。デバイス・ドライバーの更新は破棄されます。UXSP を使用した Windows デバイス・ドライバー更新のダウンロードまたはインポートについて詳しくは、XClarity Administrator オンライン・ドキュメントの OS デバイス・ドライバー・リポジトリーの管理。

     手動で UXSP を XClarity Administrator にインポートする場合は、ペイロード (*.zip)、メタデータ (.xml)、変更履歴 (.chg または .html)、readme (.txt) の必要なファイルを含める必要があります。

   • システム・ファームウェア・バンドル

     ThinkSystem V3 サーバー (XCC2 を含む) の場合、ファームウェア更新パックはシステム・ファームウェア・バンドルと呼ばれます。

     XClarity Administrator からシステム・ファームウェア・バンドルをダウンロードすると、バンドル内の各ファームウェア更新がファームウェア更新リポジトリーに追加され、「個別更新」タブにリストされ、以下の名前を使用してすべての管理可能デバイスにデフォルトのファームウェア・コンプライアンス・ポリシーが自動的に作成されます。この事前定義済みポリシーはコピーすることはできますが、変更することはできません。

     • {bundle-version}-{server-short-name}-bundle (例: 22a.0-kaj92va-SR650V3-bundle)

     手動で XClarity Administrator にシステム・ファームウェア・バンドルをインポートする場合は、バンドル・ペイロード (.zip) のみが必要です。このファイルには、各更新のペイロード、メタデータ、変更履歴、readme が含まれています。

   • 個別のファームウェア更新

     ファームウェア更新パッケージを個別にダウンロードすることもできます。ファームウェア更新パッケージをダウンロードすると、カタログに示されたバージョンに基づいて更新が XClarity Administrator によりダウンロードされ、ファームウェア更新リポジトリーに更新パッケージが保存されます。その後、これらの更新パッケージを使用して、各管理対象デバイスのファームウェア・コンプライアンス・ポリシーを作成できます。

     注

     コア ファームウェア更新 (管理コントローラー、UEFI、pDSA など) は、オペレーティング・システムに依存しません。RHEL 6 または SLES 11 オペレーティング・システム用のファームウェア更新パッケージは、計算ノードとラック・サーバーの更新に使用されます。管理対象サーバーにどのファームウェア更新パッケージを使用するかについて詳しくは、ファームウェア更新のダウンロードを参照してください。

     手動でファームウェア更新を XClarity Administrator にインポートする場合は、ペイロード (イメージ)、メタデータ (.xml または .json)、変更履歴 (.chg)、readme (.txt) の必要なファイルを含める必要があります。ThinkSystem V3 サーバーの場合、メタデータ・ファイルはペイロード・ファイルに含まれており、別途インポートされません。

   「ファームウェア更新: リポジトリー」ページの「個別更新」タブの「ダウンロード・ステータス」列で、ファームウェア更新がファームウェア更新リポジトリーに保存されているかどうかを調べることができます。この列には、以下の値が含まれます。

   • ダウンロード済み。更新パッケージ全体または個々のファームウェア更新がリポジトリ―に保存されています。
   • x/y ダウンロード済み。更新パッケージ内の一部のファームウェア更新がリポジトリ―に保存されています。括弧内の番号は、利用可能な更新数と、保存された更新数、または特定のデバイス・タイプの更新がないことを示します。
   • 未ダウンロード。更新パッケージ全体または個々のファームウェア更新を使用できますが、リポジトリーに保存されていません。

   カタログを更新してファームウェア更新をダウンロードするには、XClarity Administrator がインターネットに接続されている必要があります。インターネットに接続されていない場合は、Web ブラウザーを使用して XClarity Administrator ホストにネットワーク・アクセスできるワークステーションに手動でファイルをダウンロードして、ファイルをファームウェア更新リポジトリーにインポートできます。
   
   

   注

   特定の ThinkSystem DM ストレージ・デバイスでは、ファームウェア更新をダウンロードすると、ONTAP オペレーティング・システム用の書き込みオファー PDF ファイルもダウンロードされます。これらのデバイスのファームウェア更新も手動でインポートする場合は、ONTAP 書き込みオファー PDF (該当する場合) をオプションで選択できます。Web インターフェースでファイルを表示するには、「リリース情報」列のアイコンをクリックして「リリース情報」ダイアログを表示し、「ONTAP 書き込みオファー」タブをクリックします。

   重要

   • これらの必要なファイルのみをインポートします。ファームウェアのダウンロード Web サイトに記載されている他のファイルはインポートしないでください。
   • 更新パッケージに メタデータ (.xml または .json) ファイルを含めなかった場合、更新はインポートされません。
   • 更新に関連する必要なすべてのファイルを含めなかった場合、リポジトリーで更新が未ダウンロードと表示されます。これは、一部インポート済みであることを意味します。その後、不足しているファイルを選択してインポートできます。
   • コア ファームウェア更新 (管理コントローラー、UEFI、pDSA など) は、オペレーティング・システムに依存しません。RHEL 6 または SLES 11 オペレーティング・システム用のファームウェア更新パッケージは、計算ノードとラック・サーバーの更新に使用されます。

   ファームウェア更新について詳しくは、ファームウェア更新リポジトリーの管理を参照してください。

2. (オプション) ファームウェア・コンプライアンス・ポリシーの作成と割り当て

   ファームウェア・コンプライアンス・ポリシーを使用すると、注意が必要なデバイスにフラグを付けることで、特定の管理対象デバイス上のファームウェアを現在のレベルまたは指定されたレベルに維持することができます。各ファームウェア・コンプライアンス・ポリシーは、デバイスのコンプライアンスを保つために、監視対象のデバイスと、インストールする必要のあるファームウェア・レベルを指定します。コンプライアンスは、デバイスまたはファームウェア・コンポーネントのレベルで設定できます。その後、XClarity Administrator はこれらのポリシーを使用して、管理対象デバイスのステータスを確認し、コンプライアンスに違反しているデバイスを特定します。

   ファームウェア・コンプライアンス・ポリシーを作成するときは、以下のような場合に XClarity Administrator がデバイスにフラグを立てるように選択できます。

   • デバイスのファームウェアが下位レベル
   • デバイスのファームウェアがコンプライアンス・ターゲット・バージョンと完全に一致していない

   XClarity Administrator には、リポジトリの最新ファームウェアと呼ばれる事前定義されたファームウェア・コンプライアンス・ポリシーが用意されています。新しいファームウェアがリポジトリーにダウンロードまたはインポートされると、このポリシーが更新されて、リポジトリー内で使用可能なファームウェアの最新バージョンが含まれるようになります。

   ファームウェア・コンプライアンス・ポリシーをデバイスに割り当てた後、XClarity Administrator はデバイス・インベントリーの変更またはファームウェア更新リポジトリーの変更があると、各デバイスのコンプライアンス状況を確認します。デバイスのファームウェアが割り当てられたポリシーに準拠していない場合、XClarity Administrator はファームウェア・コンプライアンス・ポリシーで指定したルールに基づいて、「ファームウェア更新: 適用/アクティブ化」ページでデバイスを非準拠として識別します
   
   

   たとえば、すべての ThinkSystem SR850 デバイスにインストールされたファームウェアの基準レベルを定義するファームウェア・コンプライアンス・ポリシーを作成し、そのファームウェア・コンプライアンス・ポリシーをすべての管理対象 ThinkSystem SR850 デバイスに割り当てることができます。ファームウェア更新リポジトリ―が最新の情報に更新され、新しいファームウェア更新が追加されると、それらの計算ノードがコンプライアンス違反となる可能性があります。その場合、XClarity Administrator は「ファームウェア更新: 適用/アクティブ化」ページを更新し、そのデバイスが非適合であることを表示して、アラートを生成します。

   注

   割り当てられたファームウェア・コンプライアンス・ポリシーの要件を満たしていないデバイスのアラートの表示または非表示を選択できます (ファームウェア更新の共通設定の構成を参照)。デフォルトではアラートは非表示です。

   ファームウェア・コンプライアンス・ポリシーについて詳しくは、ファームウェア・コンプライアンス・ポリシーの作成と割り当てを参照してください。

3. 更新の取得とアクティブ化

   XClarity Administrator では、管理対象デバイスにファームウェア更新が自動的に適用されません。ファームウェアを更新するには、選択されたデバイスで更新を手動で適用してアクティブ化する必要があります。ファームウェアは以下のいずれかの方法で適用できます。

   • コンプライアンス・ポリシーを使用するバンドルされたファームウェア更新の適用

     適用可能なファームウェア更新パッケージを含むバンドル・イメージを使用して、割り当てられたファームウェア・コンプライアンス・ポリシーに従って、選択済みデバイスのすべてのコンポーネントにファームウェア更新を適用できます。

     バンドル更新プロセスは、まず、ベースボード管理コントローラーと UEFI アウト・オブ・バンドを更新します。これらの更新が完了すると、プロセスは、マシン・タイプに基づいて、コンプライアンス ポリシー内の残りのファームウェアのバンドル・イメージを作成します。次に、プロセスは選択したデバイスにイメージをマウントし、デバイスを再起動してイメージをブートします。イメージは自動的に実行され、残りの更新が実行されます。

     重要

     選択したデバイスは、更新プロセスを開始する前に電源がオフになります。必ず、実行中のワークロードを停止してください。仮想化環境で作業している場合は、別のサーバーに移動してください。ジョブを実行中の場合、更新ジョブは他のジョブがすべて完了するまでキューに入れられます。アクティブ・ジョブのリストを表示するには、「監視」 > 「ジョブ」をクリックします。
     注

     • バンドルされたファームウェアの更新の適用は、ThinkSystem SR635 および SR655 サーバーでのみサポートされています。

     • バンドルされたファームウェア更新の適用は、IPv4 アドレスでのみサポートされています。IPv6 アドレスはサポートされていません。

     • インベントリー情報全体を取得するために、各ターゲット・デバイスが少なくとも 1 回 OS にブートされたことを確認してください。

     • バンドル更新機能を使用するには、ベースボード管理コントローラー・ファームウェア v2.94 以降が必要です。

     • リポジトリー・パックからのファームウェア更新または個々のファームウェア更新のみが使用されます。UpdateXpress System Packs (UXSPs) はサポートされていません。

     • ダウンロードしたファームウェア更新のみが適用されます。製品カタログを更新し、適切なファームウェア更新をダウンロードします (製品カタログの更新とファームウェア更新のダウンロード)。

       注

       XClarity Administrator を最初にインストールしたときは、製品カタログとリポジトリーは空です。

     • コンプライアンス確認は、ThinkSystem SR635 および SR655 サーバーのベースボード管理コントローラーと UEFI でのみサポートされます。ただし、XClarity Administrator は、利用可能なすべてのハードウェア・コンポーネントにファームウェア更新を適用しようとします。

     • 更新は、割り当てられたファームウェア・コンプライアンス・ポリシーに従って適用されます。コンポーネントのサブセットを更新することはできません。

     • Lenovo XClarity Provisioning Manager (LXPM)、LXPM のウィンドウ・ドライバー、または LXPM Linux ドライバーのファームウェア更新を ThinkSystem SR635 および SR655 サーバーに適用するには、XClarity Administrator v3.2 以降が必要です。

     • 現在インストールされているバージョンが、割り当てられたコンプライアンス・ポリシーよりも新しい場合、ベースボード管理コントローラーと UEFI の更新はスキップされます。

     • ファームウェア・コンプライアンス・ポリシーが作成済みであり、ファームウェア更新を適用するデバイスに割り当て済みである必要があります。詳しくは、ファームウェア・コンプライアンス・ポリシーの作成と割り当てを参照してください。

     • 選択したデバイスは、更新プロセスを開始する前に電源がオフになります。必ず、実行中のワークロードを停止してください。仮想化環境で作業している場合は、別のサーバーに移動してください。

   • コンプライアンス・ポリシーを使用する、または使用しない選択済みファームウェア更新の適用

     適用可能なファームウェア更新パッケージを使用する割り当てられたファームウェア・コンプライアンス・ポリシーに従って、選択済みコンポーネントとデバイスにファームウェア更新を適用できます。また、コンプライアンス・ポリシーを使用せずに、選択済みコンポーネントとデバイスに現在インストールされているファームウェアよりも新しいファームウェア更新を適用することもできます。

     特定のデバイスのすべてのコンポーネントに更新を適用することを選択できます。また、ベースボード管理コントローラーや UEFI など、選択済みデバイスでコンポーネントのサブセットのみを更新することもできます。

     ファームウェア更新をアクティブ化するには、デバイスを再起動する必要があります。(デバイスの再起動には中断が伴うことに注意してください。)更新プロセスの一部としてデバイスを再起動するか (即時アクティベーションと呼ばれます)、保守期間でデバイスを再起動できるようになるまで待機するか (据え置きアクティベーションと呼ばれます) を選択できます。この場合、更新を有効にするためにデバイスを手動で再起動する必要があります。

     管理対象デバイスのファームウェアを更新する場合は、以下の手順を実行します。

     1. XClarity Administrator がファームウェア更新 (たとえば、管理コントローラーの場合は UEFI や DSA など) をデバイスを送信します。
     2. デバイスが再起動すると、デバイスでファームウェアの更新がアクティブになります。
     3. サーバーの場合、XClarity Administrator がオプション・デバイスの更新 (ネットワーク・アダプターやハードディスク・ドライブの更新など) を送信します。XClarity Administrator によりこれらの更新が適用され、サーバーが再起動します。
     4. デバイスを再起動するか、即時アクティベーションを選択すると、オプション・デバイスの更新がアクティブになります。
     注

     • コンプライアンス・ポリシーを使用して更新を適用する場合は、ファームウェア・コンプライアンス・ポリシーを作成し、各ターゲット・デバイスに割り当てる必要があります。詳しくは、ファームウェア・コンプライアンス・ポリシーの作成と割り当てを参照してください。
     • 複数のコンポーネントに対する更新を含むファームウェア更新パッケージをインストールするように選択した場合、更新パッケージが適用されるすべてのコンポーネントが更新されます。
     • CMM および Flex スイッチに対する更新は、遅延アクティベーションを選択した場合でも、常に即座にアクティブ化されます。

   デバイス一式で更新の実行をする場合、XClarity Administrator は、次の順番で更新を実行します。

   • シャーシの CMM
   • RackSwitch および Flex System スイッチ
   • Flex 計算ノード、およびラックとタワー・サーバー
   • Lenovo Storage デバイス

   重要

   管理対象デバイスでファームウェア更新を適用しようとする前に、以下の操作を完了していることを確認してください。

   • 管理対象デバイスでファームウェアを更新する前に、ファームウェア更新の考慮事項を読んでください (ファームウェアの更新に関する考慮事項 を参照)。
   • 最初は、更新がサポートされていないデバイスはビューに表示されません。サポートされていないデバイスを更新するように選択することはできません。
   • デフォルトでは、検出されたすべてのコンポーネントが更新を適用できるコンポーネントとしてリストされますが、下位レベルのファームウェアが原因で、コンポーネントがインベントリーに表示されない可能性や、バージョン情報が詳細に報告されない可能性があります。更新を適用できる、すべてのポリシー・ベースのパッケージをリストに表示するには、「すべての操作」 > 「共通設定」をクリックし、「下位レベルのデバイスの拡張サポート」を選択します。このオプションを選択すると、未検出のデバイスの「インストール済みバージョン」列にその他の利用可能なソフトウェアがリストされます。詳しくは、ファームウェア更新の共通設定の構成を参照してください。
     注

     • 管理対象デバイスに対する更新が進行中の場合、グローバル設定を変更することはできません。
     • 追加のオプションを生成するには数分かかります。しばらくしてから、テーブルを更新するために「最新表示」アイコン () をクリックする必要がある場合があります。
   • ターゲット・サーバーで現在実行されているジョブがないことを確認します。ジョブを実行中の場合、更新ジョブは他のジョブがすべて完了するまでキューに入れられます。アクティブ・ジョブのリストを表示するには、「監視」 > 「ジョブ」をクリックします。
   • 有効にすると、Wake-on-LAN ブート・オプションが、サーバーの電源をオフにする XClarity Administrator の操作 (ネットワーク内に「Wake on Magic Packet」コマンドを発行する Wake-on-LAN クライアントがある場合はファームウェア更新など) によって中断されることがあります。
   • 始動パスワードとセットアップ・パスワードの両方が無効に設定されていることを確認します。これらのパスワードが有効で、サーバーが自動的に再起動された場合、準備度チェック中にファームウェア更新は失敗します。

   • デプロイするファームウェア・パッケージがファームウェア更新リポジトリ―に含まれていることを確認します。含まれていない場合は、製品カタログを更新し、適切なファームウェア更新をダウンロードします (製品カタログの更新とファームウェア更新のダウンロードを参照)。
     注

     XClarity Administrator を最初にインストールしたときは、製品カタログとリポジトリーは空です。

     前提条件ファームウェアをインストールする場合は、前提条件ファームウェアもリポジトリーにダウンロードしていることを確認してください。

     場合によっては、ファームウェアを更新するために複数のバージョンが必要になることがあり、その場合はすべてのバージョンをリポジトリーにダウンロードする必要があります。たとえば、IBM FC5022 SAN スケーラブル・スイッチを v7.4.0a から v8.2.0a にアップグレードするには、まず v8.0.1-pha、次に v8.1.1、そして v8.2.0a をインストールします。スイッチを v8.2.0a に更新するには、この 3 つのバージョンすべてがリポジトリーに含まれる必要があります。

   • 通常、ファームウェア更新をアクティブ化するにはデバイスを再起動する必要があります。更新プロセス中にデバイスの再起動を選択した場合 (即時アクティベーション)、必ず実行中のワークロードを停止してください。仮想化環境で作業している場合は、別のサーバーに移動してください。

   更新のインストールについて詳しくは、ファームウェア更新の適用とアクティブ化を参照してください。