この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章は、次の内容で構成されています。
Cisco UCS ドメインのエンドポイントのファームウェアをアップグレードする前に、次の注意、ガイドライン、および制約事項を考慮してください。
(注) |
Cisco UCS Manager CLI では、アップグレード後のリリースでサポートされていないハードウェアをアップグレードできません。Cisco UCS Manager CLI では、サポートされていないリリースにハードウェアをアップグレードしようとすると、エラー メッセージが表示されます。 |
Cisco UCS ドメインの設定に応じて、アップグレード後に設定を変更するには、次の変更が必要な場合があります。 障害などの問題を回避するには、必要な変更を行ってからアップグレードすることを推奨します。
2 つの iSCSI vNIC があり、両方が同じイニシエータ IQN(Cisco UCS Release 2.0(1) でサポート)を使用している場合は、アップグレードすると、単一のサービス プロファイル レベルのイニシエータ IQN が作成され、iSCSI vNIC のイニシエータ IQN はリセットされて値を失います。
Cisco UCS Release 2.0(1) のサービス プロファイル全体において、iSCSI vNIC で同じイニシエータ IQN が使用されている場合は、アップグレードすると、サービス プロファイル・レベルの重複したイニシエータ IQN が生成されます。 このような構成では、サービス プロファイル レベルで定義された重複イニシエータ IQN を持つ各 iSCSI vNIC に対してエラーが生成されます。 これらのエラーは、サービス プロファイル レベルの重複イニシエータ IQN を変更すると解消されます。 サービス プロファイル関連の操作(ホスト ファームウェア パッケージのアップデートなど)を実行する前に、これらのエラーを解消する必要があります。
デフォルトのメンテナンス ポリシーは、ホスト メンテナンス ポリシーによるサーバ ファームウェアのアップグレードなど、大きな影響を及ぼす変更がサービス プロファイルに加えられた場合にただちにサーバがリブートするように設定されています。 サーバ トラフィックの予期せぬ中断を避けるため、デフォルトのメンテナンス ポリシーのリブート ポリシー設定をユーザ確認応答に変更することを推奨します。
デフォルトのメンテナンス ポリシーのリブート ポリシー設定をユーザ確認応答に変更すると、大きな影響を及ぼす変更のリストが保留中のアクティビティと共に一覧表示されます。 これにより、サーバのリブートを制御することができます。
注意 |
Cisco UCS 1.4 以前のリリースでは、イーサネット VLAN と FCoE VLAN で VLAN ID のオーバーラップが可能でした。 ただし、Cisco UCS Release 2.0 以降では、VLAN ID のオーバーラップは許可されません。 アップグレード中に Cisco UCS Manager で VLAN ID のオーバーラップが検出されると、重大なエラーが生成されます。 VLAN ID を再設定しない場合、Cisco UCS Manager によって重大なエラーが生成され、オーバーラップしている VLAN のイーサネット トラフィックがドロップされます。 このため、イーサネットと FCoE の VLAN ID がオーバーラップしていないことを確認してから、Cisco UCS Release 2.2 にアップグレードすることを推奨します。 アップリンク トランクの設定で VLAN ID 1 がネイティブ VLAN として定義および設定されている場合、イーサネット VLAN 1 ID を別の値に変更すると、ファブリック インターコネクトでネットワークの中断やフラッピングが生じ、その結果、HA イベントが発生して、大量のトラフィックが取り込まれ、サービスを一時的に使用できなくなります。 Cisco UCS 1.4 以前のリリースでは、VSAN の FCoE VLAN ID を明示的に設定しなかった場合、Cisco UCS Manager は、デフォルトの VSAN のデフォルト FCoE VLAN として VLAN 1 を割り当てました(デフォルトの VSAN ID 1 を使用)。 これらのリリースでは、VLAN 1 は、イーサネット トラフィックのデフォルト VLAN としても使用されました。 このため、FCoE VLAN および 1 つ以上のイーサネット VLAN のデフォルト VLAN ID を受け入れた場合は、VSAN の FCoE VLAN またはイーサネット VLAN の VLAN ID を再設定する必要があります。 |
Cisco UCS Release 2.2 の新規インストールでは、デフォルトの VLAN ID は次のようになります。
(注) |
Cisco UCS ドメインでデフォルト VLAN ID の 1 つが使用されているため VLAN のオーバーラップが発生している場合は、1 つ以上のデフォルト VLAN ID を、使用または予約されていない VLAN ID に変更します。 リリース 2.0 以降では ID が 3968 ~ 4047 の VLAN は予約されます。 |
予約範囲の ID を持つ VSAN は、アップグレード後に正常に動作しません。 次を実行して、Cisco UCS Manager で設定されている VSAN が予約済み範囲に含まれないようにします。
Cisco UCS ドメイン FC スイッチ モードを使用する予定の場合は、ID が 3040 ~ 4078 の範囲にある VSAN を設定しないでください。
Cisco UCS ドメイン FC エンドホスト モードを使用する予定の場合は、ID が 3840 ~ 4079 の範囲にある VSAN を設定しないでください。
VSAN に予約済み範囲の ID がある場合は、その VSAN ID を、使用または予約されていない VSAN ID に変更します。
ホスト オペレーティング システム レベルで、1 つ以上の vNIC で [Enable Failover] を設定し、同時に NIC チーミング/ボンディングを設定した場合は、ファームウェアのアップグレード時にすべての接続が失われる可能性があります。 いずれかの方法を使用して可用性を設計します。両方は使用しないでください。
Cisco UCS ドメインの 1 つ以上の vNIC に対してフェールオーバーをイネーブルにしているかどうかを確認するには、サーバに関連付けられている各サービス プロファイル内で vNIC の設定を確認します。 詳細については、実行しているリリースの Cisco UCS Manager コンフィギュレーション ガイドを参照してください。
以前の Cisco UCS ファームウェア リリースを Release 1.3(1i) 以降にアップグレードすると、アップグレード後にサーバが初めてサーバ プロファイルに関連付けられる際に、ローカル ディスク設定ポリシーの Protect Configuration プロパティに次の影響が生じます。
Cisco UCS ドメインをアップグレードした後、最初のサーバ アソシエーションは、ローカル ディスクの設定ポリシーがサーバ ハードウェアに一致しているかどうかにかかわらず、設定エラーにならずに進行します。 Protect Configuration プロパティを有効にしていても、前のサービス プロファイルと新しいサービス プロファイルの間でローカル ディスク設定ポリシーの設定に不一致がある場合、Cisco UCS はサーバ上のユーザ データを保護しません。
(注) |
Protect Configuration プロパティを有効にした場合、前のサービス プロファイルと新しいサービス プロファイルの間でローカル ディスク設定ポリシーに不一致があると、サーバに対する後続のサービス プロファイル アソシエーションはすべてブロックされます。 |
すでにサービス プロファイルに関連付けられているサーバは、アップグレード後にリブートしません。 Cisco UCS Manager は、ローカル ディスクの設定ポリシーとサーバ ハードウェアの間に不一致があっても、設定エラーを報告しません。
サービス プロファイルがサーバから関連付けを解除され、新しいサービス プロファイルが関連付けられると、新しいサービス プロファイルの Protect Configuration プロパティの設定が優先され、前のサービス プロファイルの設定が上書きされます。
Cisco UCS ドメインのハードウェアはアップグレード方法に影響を与えることがあります。 エンドポイントをアップグレードする前に、次の注意事項および制約事項を考慮してください。
注意 |
更新が完了するまで、エンドポイントがあるハードウェアを取り外したり、メンテナンス作業を実行しないでください。 ハードウェアが取り外されたり、その他のメンテナンス作業により使用できない場合、ファームウェアの更新は失敗します。 この失敗により、バックアップ パーティションが破損する場合があります。 バックアップ パーティションが破損しているエンドポイントではファームウェアを更新できません。 |
Cisco UCS インフラストラクチャやサーバ ファームウェアのアップグレードの実施前および実施中は、以下を順守してください。
Cisco UCS Gen-2 アダプタは、エンドポイントで直接アップグレードすることはできません。 このようなアダプタのファームウェアは、ホスト ファームウェア パッケージを使用してアップグレードする必要があります。
Intel ベースのアダプタ カードである Cisco UCS 82598KR-CI 10-Gigabit Ethernet Adapter(N20-AI0002)のファームウェアは、製造元でハードウェアに書き込まれます。 このアダプタのファームウェアはアップグレードできません。
2 つのファブリック インターコネクトのあるクラスタ設定の場合、ファブリック インターコネクト間のフェールオーバーを利用して、データ トラフィックを中断せずに、エンドポイントの直接のファームウェア アップグレードを実行できます。 ただし、ホストまたは管理ファームウェア パッケージによってアップグレードする必要があるエンドポイントの場合は、データ トラフィックの中断が避けられません。
単一のファブリック インターコネクトのスタンドアロン設定の場合、エンドポイントの直接のファームウェア アップグレードを実行すると、データ トラフィックの中断を最小にできます。 ただし、アップグレードを完了するために、ファブリック インターコネクトをリブートする必要があるため、トラフィックの中断は避けられません。
エンドポイントをアップグレードする前に、次の注意事項および制約事項を考慮してください。
アダプタやサーバ CIMC などの一部のエンドポイントは、直接のファームウェア アップグレードか、またはサービス プロファイルに含まれるファームウェア パッケージによって、アップグレードできます。 Cisco UCS ドメインの設定によって、これらのエンドポイントのアップグレード方法が決まります。 サーバに関連付けられているサービス プロファイルに、ホスト ファームウェア パッケージが含まれる場合、ファームウェア パッケージによって、それらのサーバのアダプタをアップグレードします。 同様に、サーバに関連付けられているサービス プロファイルに管理ファームウェア パッケージが含まれる場合、ファームウェア パッケージによって、それらのサーバの CIMC をアップグレードします。
管理ファームウェア パッケージによる CIMC のアップグレード、またはサーバに関連付けられたサービス プロファイル内のファームウェア パッケージによるアダプタのアップグレードは、直接のファームウェア アップグレードより優先されます。 サーバに関連付けられたサービス プロファイルにファームウェア パッケージが含まれる場合、エンドポイントを直接アップグレードすることはできません。 直接のアップグレードを実行するには、サービス プロファイルからファームウェア パッケージを削除する必要があります。
Cisco UCS Manager GUI を使用してファームウェアをアップデートする場合、[Activate Firmware] ダイアログボックスの [Filter] ドロップダウン リストで [ALL] を選択して、すべてのエンドポイントを同時にアクティブにしないでください。 多くのファームウェア リリースやパッチには依存関係があるため、ファームウェアの更新を正常に実行するためにエンドポイントを特定の順序でアクティブにする必要があります。 この順序はリリースやパッチの内容によって異なります。 すべてのエンドポイントをアクティブにすると、必要な順序でアップデートが行われることが保証されず、エンドポイント、ファブリック インターコネクト、および Cisco UCS Manager 間の通信が中断することがあります。 特定のリリースやパッチの依存関係については、当該のリリースやパッチに付属のリリース ノートを参照してください。
直接のアップグレード時に、アダプタに [スタートアップバージョンのみを設定する] を設定する必要があります。 この設定では、アクティブ化されたファームウェアが pending-next-boot 状態に移行し、サーバがすぐにリブートしません。 アクティブ化されたファームウェアは、サーバがリブートされるまで、アダプタで実行されているバージョンのファームウェアになりません。 ホスト ファームウェア パッケージのアダプタに [スタートアップバージョンのみを設定する] を設定することはできません。
サーバがサービス プロファイルに関連付けられていない場合、アクティブ化されたファームウェアは pending-next-boot 状態のままになります。 Cisco UCS Manager は、サーバがサービス プロファイルに関連付けられるまで、エンドポイントをリブートせず、ファームウェアをアクティブにしません。 必要に応じて、関連付けられていないサーバを手動でリブートまたはリセットして、ファームウェアをアクティブにできます。
I/O モジュールに対して [スタートアップバージョンのみを設定する] を設定した場合、そのデータ パス内のファブリック インターコネクトがリブートされると、I/O モジュールがリブートされます。 I/O モジュールに対して、[スタートアップバージョンのみを設定する] を設定しない場合、I/O モジュールがリブートし、トラフィックが中断します。 また、Cisco UCS Manager がファブリック インターコネクトと I/O モジュールの間のプロトコルとファームウェア バージョンの不一致を検出した場合、Cisco UCS Manager は、ファブリック インターコネクトのファームウェアに一致するファームウェア バージョンを使用して I/O モジュールを自動的に更新し、ファームウェアをアクティブ化して、I/O モジュールを再度リブートします。
Cisco UCS ドメインをアップグレードすると、Cisco UCS Manager によってコンポーネントが再起動され、アップグレード プロセスが完了します。 この再起動によって、サービスの中断およびコンポーネントの障害と同じイベントが発生し、Call Home アラートの送信がトリガーされます。 アップグレードの開始前に Call Home をディセーブルにしない場合は、アップグレードに関連したコンポーネントの再起動によって生成されるアラートを無視してください。
自動インストールを使用して Cisco UCS ドメインのエンドポイントのファームウェアをアップグレードする前に、次の注意、ガイドライン、および制約事項を考慮してください。
(注) |
次の注意事項は自動インストールに固有の事項であり、ファームウェア アップグレードに関する注意、ガイドライン、および制約事項の項目と併せて考慮する必要があります。 |
アップグレードを開始する前に、影響を受けるすべてのエンドポイントが次の状態であることが必要です。
Cisco UCS ドメインの一部またはすべてのエンドポイントを 自動インストール でアップグレードするには、すべてのエンドポイントが Cisco UCS Release 1.3 以降でなければなりません。
Cisco UCS Manager をアップグレードすると、「default」という名前の新しいホスト ファームウェア ポリシーが作成され、まだホスト ファームウェア ポリシーが含まれていないすべてのサービス プロファイルに割り当てられます。 デフォルトのホスト ファームウェア ポリシーは空白です。 いかなるコンポーネントのいかなるファームウェア エントリも含まれていません。 このデフォルトのポリシーは、ユーザの確認応答を受けてからサーバをリブートするのではなく、即時にリブートするように設定することもできます。
サーバ ファームウェアのアップグレード時に、Cisco UCS ドメインのブレード サーバやラックマウント サーバのファームウェアをデフォルトのホスト ファームウェア ポリシーに追加できます。 アップグレードを完了するには、すべてのサーバをリブートする必要があります。
デフォルトのホスト ファームウェア ポリシーが割り当てられている各サービス プロファイルは、そこに含まれているメンテナンス ポリシーに従って、関連付けられているサーバをリブートします。 メンテナンス ポリシーが即時リブートに設定されている場合は、[Install Server Firmware] ウィザードでの設定の完了後に、アップグレードをキャンセルしたり、サーバのリブートを阻止することはできません。 これらのサービス プロファイルに関連付けられているメンテナンス ポリシーを検証して、時限リブートまたはユーザ確認応答のいずれが設定されているかを確認することを推奨します。
クラスタ構成内のファブリック インターコネクトを確実に同期させるには、それらが同じ日付、時刻、タイム ゾーンに設定されていることを確認する必要があります。 両方のファブリック インターコネクトに NTP サーバと正しいタイム ゾーンを設定することを推奨します。 ファブリック インターコネクトの日付、時刻、タイムゾーンが同期していないと、自動インストール でエラーが発生することがあります。
インフラストラクチャのファームウェアをサーバのファームウェアと同時にアップグレードすることはできません。 インフラストラクチャのファームウェアを先にアップグレードし、次にサーバのファームウェアをアップグレードすることを推奨します。 インフラストラクチャのファームウェアのアップグレードが完了するまで、サーバのファームウェアのアップグレードは開始しないでください。
自動インストールを使用してエンドポイントをアップグレードするには、次の権限が必要です。
権限 | 実行できるアップグレード作業 |
---|---|
admin |
|
サービス プロファイルの計算(ls-compute) |
サーバ ファームウェアのインストールの実行 |
サービス プロファイルのサーバ ポリシー(ls-server-policy) |
ホスト ファームウェア パッケージの追加、削除、および変更 |
サービス プロファイルの設定ポリシー(ls-config-policy) |
ホスト ファームウェア パッケージの追加、削除、および変更 |
サーバ ファームウェアのインストールでは、ホスト ファームウェア パッケージを使用してサーバをアップグレードするため、Cisco UCS ドメインのすべてのサーバを同じファームウェア バージョンにアップグレードする必要はありません。 ただし、関連するサービス プロファイルにサーバ ファームウェアのインストールを設定したときに選択したホスト ファームウェア パッケージが含まれるサーバは、すべて指定したソフトウェア バンドルのファームウェア バージョンにアップグレードされます。
サーバに関連付けられているサービス プロファイルにホスト ファームウェア パッケージだけでなく管理ファームウェア パッケージも含まれている場合は、サーバ ファームウェアのインストールでは、管理ファームウェア パッケージのファームウェア バージョンを使用して、サーバの CIMC をアップグレードします。 CIMC は、ホスト ファームウェア パッケージの CIMC の方が管理ファームウェア パッケージの CIMC より新しいバージョンの場合でも、ホスト ファームウェア パッケージのファームウェア バージョンにはアップグレードされません。 ホスト ファームウェア パッケージを使用してサーバの CIMC をアップグレードする場合は、関連付けられたサービス プロファイルから管理ファームウェア パッケージを削除する必要があります。
サーバに関連付けられたサービス プロファイルにホスト ファームウェア パッケージが含まれていない場合、このサーバのエンドポイントのアップグレードにサーバ ファームウェアのインストールを使用すると、サーバ ファームウェアのインストールではデフォルトのホスト ファームウェア パッケージを使用してサーバをアップグレードします。 サーバ ファームウェアのインストールでは、デフォルトのホスト ファームウェア パッケージのみ更新できます。
サーバに関連付けられているサービス プロファイルが以前に サーバ ファームウェアのインストール のデフォルトのホスト ファームウェア パッケージによって更新されている場合、このサーバの CIMC またはアダプタをアップグレードするには、次のいずれかの方法を使用する必要があります。
サーバ ファームウェアのインストールを実行した後、Cisco UCS ドメインにサーバを追加すると、新しいサーバのファームウェアはサーバ ファームウェアのインストールによって自動的にアップグレードされません。 新しく追加したサーバのファームウェアを、最後にサーバ ファームウェアのインストールを実行したときに使用したファームウェア バージョンにアップグレードする場合は、エンドポイントをそのサーバのファームウェアに手動でアップグレードする必要があります。 サーバ ファームウェアのインストールには、ファームウェア バージョンの変更が毎回必要です。 サーバを同じファームウェア バージョンにアップグレードするためにサーバ ファームウェアのインストールを再実行することはできません。
(注) |
リリース 2.2 へのアップグレードが終了すると、Cisco UCS Manager で [Firmware Auto Sync Server] ポリシーを使用して、新たに検出されたサーバを自動的に更新できます。 詳細については、該当する『Cisco UCS B シリーズ ファームウェア管理ガイド』を参照してください。 |
Cisco UCS Central から Cisco UCS Manager のファームウェアの管理を開始する前に、次の注意、ガイドライン、および制約事項を考慮してください。
ドメイン グループに定義したファームウェア ポリシーは、このドメイン グループに追加されるすべての新しい Cisco UCS ドメインに適用されます。 ドメイン グループでファームウェア ポリシーが定義されていない場合、Cisco UCS ドメインは親ドメイン グループからポリシーを継承します。
グローバル ポリシーは、Cisco UCS Manager が Cisco UCS Central との接続を失った場合でも Cisco UCS Manager にグローバルに残ります。 Cisco UCS Manager でグローバルなポリシーのいずれかに変更を適用するには、所有権をグローバルからローカルに変更する必要があります。
ホスト ファームウェア パッケージを Cisco UCS Central から作成した場合は、これをサービス プロファイルに関連付けて、Cisco UCS ドメインにアップデートを展開する必要があります。
Cisco UCS Central でホスト ファームウェア パッケージを変更すると、その変更はホスト ファームウェア アップデートに関連付けられた次のメンテナンス スケジュールの際に Cisco UCS ドメインに適用されます。
Cisco UCS Central で定義したホスト ファームウェア メンテナンス ポリシーは、Cisco UCS ドメインの org-root に適用されます。 Cisco UCS Central から Cisco UCS ドメインのサブ組織に対して別のホスト メンテナンス ポリシーを定義することはできません。
サービス プロファイルとの関連付けを持たないサーバは、ホスト ファームウェア パックのデフォルト バージョンにアップグレードされます。 これらのサーバにはメンテナンス ポリシーがないため、ただちにリブートされます。
Cisco UCS Central で保守ポリシーを指定し、ユーザの確認応答をイネーブルにし、スケジュールを指定しない場合は、Cisco UCS Manager からのみ保留中のタスクに確認応答できます。 Cisco UCS Central からの保留中のアクティビティに確認応答するには、グローバルなスケジューラをイネーブルにしてメンテナンスをスケジュールし、ユーザの確認応答をイネーブルにする必要があります。
Cisco UCS Central でメンテナンス ポリシーをスケジュールし、ユーザの確認応答をイネーブルにすると、このタスクは保留中のアクティビティ タブにスケジュールで指定した時刻で表示されます。
メンテナンス ポリシーの保留中のアクティビティは、ドメイン グループのセクションからのみ表示できます。
任意のファームウェアのスケジュールに対するユーザの確認応答をイネーブルにして、Cisco UCS ドメインでの予期せぬリブートを避けるようにしてください。
目次
この章は、次の内容で構成されています。
ファームウェア アップグレードに関する注意、ガイドライン、および制約事項
Cisco UCS ドメインのエンドポイントのファームウェアをアップグレードする前に、次の注意、ガイドライン、および制約事項を考慮してください。
(注)
Cisco UCS Manager CLI では、アップグレード後のリリースでサポートされていないハードウェアをアップグレードできません。Cisco UCS Manager CLI では、サポートされていないリリースにハードウェアをアップグレードしようとすると、エラー メッセージが表示されます。
- 設定の変更とアップグレードに影響を与える可能性がある設定
- ファームウェア アップグレードのハードウェアに関する注意事項および制限事項
- アップグレードのファームウェアおよびソフトウェアに関する注意事項および制約事項
- 自動インストールによるアップグレードに関する注意、ガイドライン、および制約事項
設定の変更とアップグレードに影響を与える可能性がある設定
Cisco UCS ドメインの設定に応じて、アップグレード後に設定を変更するには、次の変更が必要な場合があります。 障害などの問題を回避するには、必要な変更を行ってからアップグレードすることを推奨します。
Cisco UCS Release 2.1(2) 以降へのアップグレードがサービス プロファイル レベルで定義されているイニシエータ IQN に及ぼす影響
2 つの iSCSI vNIC があり、両方が同じイニシエータ IQN(Cisco UCS Release 2.0(1) でサポート)を使用している場合は、アップグレードすると、単一のサービス プロファイル レベルのイニシエータ IQN が作成され、iSCSI vNIC のイニシエータ IQN はリセットされて値を失います。
Cisco UCS Release 2.0(1) のサービス プロファイル全体において、iSCSI vNIC で同じイニシエータ IQN が使用されている場合は、アップグレードすると、サービス プロファイル・レベルの重複したイニシエータ IQN が生成されます。 このような構成では、サービス プロファイル レベルで定義された重複イニシエータ IQN を持つ各 iSCSI vNIC に対してエラーが生成されます。 これらのエラーは、サービス プロファイル レベルの重複イニシエータ IQN を変更すると解消されます。 サービス プロファイル関連の操作(ホスト ファームウェア パッケージのアップデートなど)を実行する前に、これらのエラーを解消する必要があります。
デフォルトのメンテナンス ポリシーの設定を「ユーザ確認応答」にする
デフォルトのメンテナンス ポリシーは、ホスト メンテナンス ポリシーによるサーバ ファームウェアのアップグレードなど、大きな影響を及ぼす変更がサービス プロファイルに加えられた場合にただちにサーバがリブートするように設定されています。 サーバ トラフィックの予期せぬ中断を避けるため、デフォルトのメンテナンス ポリシーのリブート ポリシー設定をユーザ確認応答に変更することを推奨します。
デフォルトのメンテナンス ポリシーのリブート ポリシー設定をユーザ確認応答に変更すると、大きな影響を及ぼす変更のリストが保留中のアクティビティと共に一覧表示されます。 これにより、サーバのリブートを制御することができます。
FCoE VLAN ID とイーサネット VLAN ID のオーバーラップは Cisco UCS Release 2.0 以降では許可されない
注意
Cisco UCS 1.4 以前のリリースでは、イーサネット VLAN と FCoE VLAN で VLAN ID のオーバーラップが可能でした。 ただし、Cisco UCS Release 2.0 以降では、VLAN ID のオーバーラップは許可されません。 アップグレード中に Cisco UCS Manager で VLAN ID のオーバーラップが検出されると、重大なエラーが生成されます。 VLAN ID を再設定しない場合、Cisco UCS Manager によって重大なエラーが生成され、オーバーラップしている VLAN のイーサネット トラフィックがドロップされます。 このため、イーサネットと FCoE の VLAN ID がオーバーラップしていないことを確認してから、Cisco UCS Release 2.2 にアップグレードすることを推奨します。
アップリンク トランクの設定で VLAN ID 1 がネイティブ VLAN として定義および設定されている場合、イーサネット VLAN 1 ID を別の値に変更すると、ファブリック インターコネクトでネットワークの中断やフラッピングが生じ、その結果、HA イベントが発生して、大量のトラフィックが取り込まれ、サービスを一時的に使用できなくなります。
Cisco UCS 1.4 以前のリリースでは、VSAN の FCoE VLAN ID を明示的に設定しなかった場合、Cisco UCS Manager は、デフォルトの VSAN のデフォルト FCoE VLAN として VLAN 1 を割り当てました(デフォルトの VSAN ID 1 を使用)。 これらのリリースでは、VLAN 1 は、イーサネット トラフィックのデフォルト VLAN としても使用されました。 このため、FCoE VLAN および 1 つ以上のイーサネット VLAN のデフォルト VLAN ID を受け入れた場合は、VSAN の FCoE VLAN またはイーサネット VLAN の VLAN ID を再設定する必要があります。
Cisco UCS Release 2.2 の新規インストールでは、デフォルトの VLAN ID は次のようになります。
FCoE ストレージ ポートのネイティブ VLAN に対して VLAN ID 4048 が使用されている場合に、 Cisco UCS Release 1.4 からリリース 2.0 にアップグレードすると、デフォルトの VLAN ID は次のようになります。
(注)
Cisco UCS ドメインでデフォルト VLAN ID の 1 つが使用されているため VLAN のオーバーラップが発生している場合は、1 つ以上のデフォルト VLAN ID を、使用または予約されていない VLAN ID に変更します。 リリース 2.0 以降では ID が 3968 ~ 4047 の VLAN は予約されます。
予約済み範囲の ID を持つ VSAN は正常に動作しない
予約範囲の ID を持つ VSAN は、アップグレード後に正常に動作しません。 次を実行して、Cisco UCS Manager で設定されている VSAN が予約済み範囲に含まれないようにします。
Cisco UCS ドメイン FC スイッチ モードを使用する予定の場合は、ID が 3040 ~ 4078 の範囲にある VSAN を設定しないでください。
Cisco UCS ドメイン FC エンドホスト モードを使用する予定の場合は、ID が 3840 ~ 4079 の範囲にある VSAN を設定しないでください。
VSAN に予約済み範囲の ID がある場合は、その VSAN ID を、使用または予約されていない VSAN ID に変更します。
vNIC フェールオーバーと NIC チーミングの両方がイネーブルになっている場合、アップグレード時にすべての接続が失われる可能性がある
ホスト オペレーティング システム レベルで、1 つ以上の vNIC で [Enable Failover] を設定し、同時に NIC チーミング/ボンディングを設定した場合は、ファームウェアのアップグレード時にすべての接続が失われる可能性があります。 いずれかの方法を使用して可用性を設計します。両方は使用しないでください。
Cisco UCS ドメインの 1 つ以上の vNIC に対してフェールオーバーをイネーブルにしているかどうかを確認するには、サーバに関連付けられている各サービス プロファイル内で vNIC の設定を確認します。 詳細については、実行しているリリースの Cisco UCS Manager コンフィギュレーション ガイドを参照してください。
リリース 1.3(1i) 以前のリリースからのアップグレードの影響
以前の Cisco UCS ファームウェア リリースを Release 1.3(1i) 以降にアップグレードすると、アップグレード後にサーバが初めてサーバ プロファイルに関連付けられる際に、ローカル ディスク設定ポリシーの Protect Configuration プロパティに次の影響が生じます。
- 関連付けられていないサーバ
Cisco UCS ドメインをアップグレードした後、最初のサーバ アソシエーションは、ローカル ディスクの設定ポリシーがサーバ ハードウェアに一致しているかどうかにかかわらず、設定エラーにならずに進行します。 Protect Configuration プロパティを有効にしていても、前のサービス プロファイルと新しいサービス プロファイルの間でローカル ディスク設定ポリシーの設定に不一致がある場合、Cisco UCS はサーバ上のユーザ データを保護しません。
(注)
Protect Configuration プロパティを有効にした場合、前のサービス プロファイルと新しいサービス プロファイルの間でローカル ディスク設定ポリシーに不一致があると、サーバに対する後続のサービス プロファイル アソシエーションはすべてブロックされます。
- 関連付けられているサーバ
すでにサービス プロファイルに関連付けられているサーバは、アップグレード後にリブートしません。 Cisco UCS Manager は、ローカル ディスクの設定ポリシーとサーバ ハードウェアの間に不一致があっても、設定エラーを報告しません。
サービス プロファイルがサーバから関連付けを解除され、新しいサービス プロファイルが関連付けられると、新しいサービス プロファイルの Protect Configuration プロパティの設定が優先され、前のサービス プロファイルの設定が上書きされます。
ファームウェア アップグレードのハードウェアに関する注意事項および制限事項
Cisco UCS ドメインのハードウェアはアップグレード方法に影響を与えることがあります。 エンドポイントをアップグレードする前に、次の注意事項および制約事項を考慮してください。
サーバまたはシャーシのメンテナンスなし
注意
更新が完了するまで、エンドポイントがあるハードウェアを取り外したり、メンテナンス作業を実行しないでください。 ハードウェアが取り外されたり、その他のメンテナンス作業により使用できない場合、ファームウェアの更新は失敗します。 この失敗により、バックアップ パーティションが破損する場合があります。 バックアップ パーティションが破損しているエンドポイントではファームウェアを更新できません。
アップグレードの実施前や実施中に RAID 構成ハードディスクを交換しない
Cisco UCS インフラストラクチャやサーバ ファームウェアのアップグレードの実施前および実施中は、以下を順守してください。
常にホスト ファームウェア パッケージを使用して Cisco UCS Gen-2 アダプタをアップグレードする
Cisco UCS Gen-2 アダプタは、エンドポイントで直接アップグレードすることはできません。 このようなアダプタのファームウェアは、ホスト ファームウェア パッケージを使用してアップグレードする必要があります。
Cisco UCS 82598KR-CI 10-Gigabit Ethernet Adapter はアップグレードできない
Intel ベースのアダプタ カードである Cisco UCS 82598KR-CI 10-Gigabit Ethernet Adapter(N20-AI0002)のファームウェアは、製造元でハードウェアに書き込まれます。 このアダプタのファームウェアはアップグレードできません。
ファブリック インターコネクト数
2 つのファブリック インターコネクトのあるクラスタ設定の場合、ファブリック インターコネクト間のフェールオーバーを利用して、データ トラフィックを中断せずに、エンドポイントの直接のファームウェア アップグレードを実行できます。 ただし、ホストまたは管理ファームウェア パッケージによってアップグレードする必要があるエンドポイントの場合は、データ トラフィックの中断が避けられません。
単一のファブリック インターコネクトのスタンドアロン設定の場合、エンドポイントの直接のファームウェア アップグレードを実行すると、データ トラフィックの中断を最小にできます。 ただし、アップグレードを完了するために、ファブリック インターコネクトをリブートする必要があるため、トラフィックの中断は避けられません。
アップグレードのファームウェアおよびソフトウェアに関する注意事項および制約事項
エンドポイントをアップグレードする前に、次の注意事項および制約事項を考慮してください。
各エンドポイントの適切なタイプのファームウェア アップグレードの決定
アダプタやサーバ CIMC などの一部のエンドポイントは、直接のファームウェア アップグレードか、またはサービス プロファイルに含まれるファームウェア パッケージによって、アップグレードできます。 Cisco UCS ドメインの設定によって、これらのエンドポイントのアップグレード方法が決まります。 サーバに関連付けられているサービス プロファイルに、ホスト ファームウェア パッケージが含まれる場合、ファームウェア パッケージによって、それらのサーバのアダプタをアップグレードします。 同様に、サーバに関連付けられているサービス プロファイルに管理ファームウェア パッケージが含まれる場合、ファームウェア パッケージによって、それらのサーバの CIMC をアップグレードします。
管理ファームウェア パッケージによる CIMC のアップグレード、またはサーバに関連付けられたサービス プロファイル内のファームウェア パッケージによるアダプタのアップグレードは、直接のファームウェア アップグレードより優先されます。 サーバに関連付けられたサービス プロファイルにファームウェア パッケージが含まれる場合、エンドポイントを直接アップグレードすることはできません。 直接のアップグレードを実行するには、サービス プロファイルからファームウェア パッケージを削除する必要があります。
Cisco UCS Manager GUI ですべてのエンドポイントを同時にアクティブにしない
Cisco UCS Manager GUI を使用してファームウェアをアップデートする場合、[Activate Firmware] ダイアログボックスの [Filter] ドロップダウン リストで [ALL] を選択して、すべてのエンドポイントを同時にアクティブにしないでください。 多くのファームウェア リリースやパッチには依存関係があるため、ファームウェアの更新を正常に実行するためにエンドポイントを特定の順序でアクティブにする必要があります。 この順序はリリースやパッチの内容によって異なります。 すべてのエンドポイントをアクティブにすると、必要な順序でアップデートが行われることが保証されず、エンドポイント、ファブリック インターコネクト、および Cisco UCS Manager 間の通信が中断することがあります。 特定のリリースやパッチの依存関係については、当該のリリースやパッチに付属のリリース ノートを参照してください。
アダプタおよび I/O モジュールのアクティベーションの影響
直接のアップグレード時に、アダプタに [スタートアップバージョンのみを設定する] を設定する必要があります。 この設定では、アクティブ化されたファームウェアが pending-next-boot 状態に移行し、サーバがすぐにリブートしません。 アクティブ化されたファームウェアは、サーバがリブートされるまで、アダプタで実行されているバージョンのファームウェアになりません。 ホスト ファームウェア パッケージのアダプタに [スタートアップバージョンのみを設定する] を設定することはできません。
サーバがサービス プロファイルに関連付けられていない場合、アクティブ化されたファームウェアは pending-next-boot 状態のままになります。 Cisco UCS Manager は、サーバがサービス プロファイルに関連付けられるまで、エンドポイントをリブートせず、ファームウェアをアクティブにしません。 必要に応じて、関連付けられていないサーバを手動でリブートまたはリセットして、ファームウェアをアクティブにできます。
I/O モジュールに対して [スタートアップバージョンのみを設定する] を設定した場合、そのデータ パス内のファブリック インターコネクトがリブートされると、I/O モジュールがリブートされます。 I/O モジュールに対して、[スタートアップバージョンのみを設定する] を設定しない場合、I/O モジュールがリブートし、トラフィックが中断します。 また、Cisco UCS Manager がファブリック インターコネクトと I/O モジュールの間のプロトコルとファームウェア バージョンの不一致を検出した場合、Cisco UCS Manager は、ファブリック インターコネクトのファームウェアに一致するファームウェア バージョンを使用して I/O モジュールを自動的に更新し、ファームウェアをアクティブ化して、I/O モジュールを再度リブートします。
自動インストールによるアップグレードに関する注意、ガイドライン、および制約事項
自動インストールを使用して Cisco UCS ドメインのエンドポイントのファームウェアをアップグレードする前に、次の注意、ガイドライン、および制約事項を考慮してください。
(注)
次の注意事項は自動インストールに固有の事項であり、ファームウェア アップグレードに関する注意、ガイドライン、および制約事項の項目と併せて考慮する必要があります。
自動インストールの実行に必要な最小ファームウェア レベル
Cisco UCS ドメインの一部またはすべてのエンドポイントを 自動インストール でアップグレードするには、すべてのエンドポイントが Cisco UCS Release 1.3 以降でなければなりません。
デフォルトのホスト ファームウェア ポリシーに関する推奨事項
Cisco UCS Manager をアップグレードすると、「default」という名前の新しいホスト ファームウェア ポリシーが作成され、まだホスト ファームウェア ポリシーが含まれていないすべてのサービス プロファイルに割り当てられます。 デフォルトのホスト ファームウェア ポリシーは空白です。 いかなるコンポーネントのいかなるファームウェア エントリも含まれていません。 このデフォルトのポリシーは、ユーザの確認応答を受けてからサーバをリブートするのではなく、即時にリブートするように設定することもできます。
サーバ ファームウェアのアップグレード時に、Cisco UCS ドメインのブレード サーバやラックマウント サーバのファームウェアをデフォルトのホスト ファームウェア ポリシーに追加できます。 アップグレードを完了するには、すべてのサーバをリブートする必要があります。
デフォルトのホスト ファームウェア ポリシーが割り当てられている各サービス プロファイルは、そこに含まれているメンテナンス ポリシーに従って、関連付けられているサーバをリブートします。 メンテナンス ポリシーが即時リブートに設定されている場合は、[Install Server Firmware] ウィザードでの設定の完了後に、アップグレードをキャンセルしたり、サーバのリブートを阻止することはできません。 これらのサービス プロファイルに関連付けられているメンテナンス ポリシーを検証して、時限リブートまたはユーザ確認応答のいずれが設定されているかを確認することを推奨します。
ファブリック インターコネクトの時刻、日付、およびタイムゾーンは同一でなければなりません。
クラスタ構成内のファブリック インターコネクトを確実に同期させるには、それらが同じ日付、時刻、タイム ゾーンに設定されていることを確認する必要があります。 両方のファブリック インターコネクトに NTP サーバと正しいタイム ゾーンを設定することを推奨します。 ファブリック インターコネクトの日付、時刻、タイムゾーンが同期していないと、自動インストール でエラーが発生することがあります。
インフラストラクチャとサーバのファームウェアを同時にアップグレードすることは不可能
インフラストラクチャのファームウェアをサーバのファームウェアと同時にアップグレードすることはできません。 インフラストラクチャのファームウェアを先にアップグレードし、次にサーバのファームウェアをアップグレードすることを推奨します。 インフラストラクチャのファームウェアのアップグレードが完了するまで、サーバのファームウェアのアップグレードは開始しないでください。
サーバ ファームウェアのインストールに対するホスト ファームウェア パッケージと管理ファームウェア パッケージの影響
サーバ ファームウェアのインストールでは、ホスト ファームウェア パッケージを使用してサーバをアップグレードするため、Cisco UCS ドメインのすべてのサーバを同じファームウェア バージョンにアップグレードする必要はありません。 ただし、関連するサービス プロファイルにサーバ ファームウェアのインストールを設定したときに選択したホスト ファームウェア パッケージが含まれるサーバは、すべて指定したソフトウェア バンドルのファームウェア バージョンにアップグレードされます。
サーバに関連付けられているサービス プロファイルにホスト ファームウェア パッケージだけでなく管理ファームウェア パッケージも含まれている場合は、サーバ ファームウェアのインストールでは、管理ファームウェア パッケージのファームウェア バージョンを使用して、サーバの CIMC をアップグレードします。 CIMC は、ホスト ファームウェア パッケージの CIMC の方が管理ファームウェア パッケージの CIMC より新しいバージョンの場合でも、ホスト ファームウェア パッケージのファームウェア バージョンにはアップグレードされません。 ホスト ファームウェア パッケージを使用してサーバの CIMC をアップグレードする場合は、関連付けられたサービス プロファイルから管理ファームウェア パッケージを削除する必要があります。
サービス プロファイルにホスト ファームウェア パッケージが含まれていないサーバに対してサーバ ファームウェアのインストールを使用した場合の影響
サーバに関連付けられたサービス プロファイルにホスト ファームウェア パッケージが含まれていない場合、このサーバのエンドポイントのアップグレードにサーバ ファームウェアのインストールを使用すると、サーバ ファームウェアのインストールではデフォルトのホスト ファームウェア パッケージを使用してサーバをアップグレードします。 サーバ ファームウェアのインストールでは、デフォルトのホスト ファームウェア パッケージのみ更新できます。
サーバに関連付けられているサービス プロファイルが以前に サーバ ファームウェアのインストール のデフォルトのホスト ファームウェア パッケージによって更新されている場合、このサーバの CIMC またはアダプタをアップグレードするには、次のいずれかの方法を使用する必要があります。
新たに追加されたサーバのサーバ ファームウェアのアップグレード
サーバ ファームウェアのインストールを実行した後、Cisco UCS ドメインにサーバを追加すると、新しいサーバのファームウェアはサーバ ファームウェアのインストールによって自動的にアップグレードされません。 新しく追加したサーバのファームウェアを、最後にサーバ ファームウェアのインストールを実行したときに使用したファームウェア バージョンにアップグレードする場合は、エンドポイントをそのサーバのファームウェアに手動でアップグレードする必要があります。 サーバ ファームウェアのインストールには、ファームウェア バージョンの変更が毎回必要です。 サーバを同じファームウェア バージョンにアップグレードするためにサーバ ファームウェアのインストールを再実行することはできません。
(注)
リリース 2.2 へのアップグレードが終了すると、Cisco UCS Manager で [Firmware Auto Sync Server] ポリシーを使用して、新たに検出されたサーバを自動的に更新できます。 詳細については、該当する『Cisco UCS B シリーズ ファームウェア管理ガイド』を参照してください。
Cisco UCS Central のファームウェア管理に関する注意、ガイドライン、および制約事項
Cisco UCS Central から Cisco UCS Manager のファームウェアの管理を開始する前に、次の注意、ガイドライン、および制約事項を考慮してください。
ドメイン グループに定義したファームウェア ポリシーは、このドメイン グループに追加されるすべての新しい Cisco UCS ドメインに適用されます。 ドメイン グループでファームウェア ポリシーが定義されていない場合、Cisco UCS ドメインは親ドメイン グループからポリシーを継承します。
グローバル ポリシーは、Cisco UCS Manager が Cisco UCS Central との接続を失った場合でも Cisco UCS Manager にグローバルに残ります。 Cisco UCS Manager でグローバルなポリシーのいずれかに変更を適用するには、所有権をグローバルからローカルに変更する必要があります。
ホスト ファームウェア パッケージを Cisco UCS Central から作成した場合は、これをサービス プロファイルに関連付けて、Cisco UCS ドメインにアップデートを展開する必要があります。
Cisco UCS Central でホスト ファームウェア パッケージを変更すると、その変更はホスト ファームウェア アップデートに関連付けられた次のメンテナンス スケジュールの際に Cisco UCS ドメインに適用されます。
Cisco UCS Central で定義したホスト ファームウェア メンテナンス ポリシーは、Cisco UCS ドメインの org-root に適用されます。 Cisco UCS Central から Cisco UCS ドメインのサブ組織に対して別のホスト メンテナンス ポリシーを定義することはできません。
サービス プロファイルとの関連付けを持たないサーバは、ホスト ファームウェア パックのデフォルト バージョンにアップグレードされます。 これらのサーバにはメンテナンス ポリシーがないため、ただちにリブートされます。
Cisco UCS Central で保守ポリシーを指定し、ユーザの確認応答をイネーブルにし、スケジュールを指定しない場合は、Cisco UCS Manager からのみ保留中のタスクに確認応答できます。 Cisco UCS Central からの保留中のアクティビティに確認応答するには、グローバルなスケジューラをイネーブルにしてメンテナンスをスケジュールし、ユーザの確認応答をイネーブルにする必要があります。
Cisco UCS Central でメンテナンス ポリシーをスケジュールし、ユーザの確認応答をイネーブルにすると、このタスクは保留中のアクティビティ タブにスケジュールで指定した時刻で表示されます。
メンテナンス ポリシーの保留中のアクティビティは、ドメイン グループのセクションからのみ表示できます。
任意のファームウェアのスケジュールに対するユーザの確認応答をイネーブルにして、Cisco UCS ドメインでの予期せぬリブートを避けるようにしてください。