この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Cisco UCS domainのエンドポイントのファームウェアをアップグレードする前に、次のガイドライン、ベスト プラクティス、および制約事項を考慮してください。
Cisco UCS domainの設定に応じて、アップグレード プロセスで追加の変更を行うことが必要な場合があります。
デフォルトのメンテナンス ポリシーは、ホスト メンテナンス ポリシーによるサーバ ファームウェアのアップグレードなど、大きな影響を及ぼす変更がサービス プロファイルに加えられた場合にただちにサーバがリブートするように設定されています。サーバ トラフィックの予期せぬ中断を避けるため、デフォルトのメンテナンス ポリシーのリブート ポリシー設定をユーザ確認応答に変更することを推奨します。
デフォルトのメンテナンス ポリシーのリブート ポリシー設定をユーザ確認応答に変更すると、大きな影響を及ぼす変更のリストが保留中のアクティビティと共に一覧表示されます。これにより、サーバのリブートを制御することができます。
注意 | Cisco UCS 1.4 以前のリリースでは、イーサネット VLAN と FCoE VLAN で VLAN ID のオーバーラップが可能でした。ただし、Cisco UCS リリース 2.0 以降では、VLAN ID のオーバーラップは許可されません。アップグレード中に Cisco UCS Manager で VLAN ID のオーバーラップが検出されると、重大なエラーが生成されます。VLAN ID を再設定しない場合、Cisco UCS Manager によって重大なエラーが生成され、オーバーラップしている VLAN からのイーサネット トラフィックがドロップされます。このため、イーサネットと FCoE の VLAN ID がオーバーラップしていないことを確認してから、Cisco UCS リリース 3.1 にアップグレードすることを推奨します。 アップリンク トランクの設定で VLAN ID 1 がネイティブ VLAN として定義および設定されている場合、イーサネット VLAN 1 ID を別の値に変更すると、ファブリック インターコネクトでネットワークの中断やフラッピングが生じ、その結果、HA イベントが発生して、大量のトラフィックが取り込まれ、サービスを一時的に使用できなくなります。 |
Cisco UCS リリース 3.1 の新規インストールでは、デフォルトの VLAN ID は次のようになります。
(注) | Cisco UCS domainでデフォルト VLAN ID の 1 つが使用されているため VLAN のオーバーラップが発生している場合は、1 つ以上のデフォルト VLAN ID を、使用または予約されていない VLAN ID に変更します。リリース 2.0 以降では ID が 3968 ~ 4047 の VLANは予約されます。 |
VSAN、FC、および FCoE は M シリーズ モジュラ サーバではサポートされません。
予約範囲の ID を持つ VSAN は、アップグレード後に正常に動作しません。次を実行して、Cisco UCS Manager で設定されている VSAN が予約済み範囲に含まれないようにします。
Cisco UCS domain FC スイッチ モードを使用する予定の場合は、ID が 3040 ~ 4078 の範囲にある VSAN を設定しないでください。
Cisco UCS domain FC エンドホスト モードを使用する予定の場合は、ID が 3840 ~ 4079 の範囲にある VSAN を設定しないでください。
VSAN に予約済み範囲の ID がある場合は、その VSAN ID を、使用または予約されていない VSAN ID に変更します。
Cisco UCS Manager リリース 3.1 では、ブレード サーバに割り当てる電力の上限値がハーフワイド サーバでは 550 W から 600 W に、フルワイド サーバでは 1100 W から 1200 W に増加しました。
電源に接続された PSU 4 点を持つ 1 つまたは複数のフル実装シャーシを搭載した Cisco UCS Manager リリース 2.2 または 3.0 で、次の構成を用いる場合、電源オンを伴うサーバ管理操作(検出やサービス プロファイルなど)は、シャーシのブレード サーバのいずれかに影響を及ぼします。影響を受けたブレード サーバには、「Insufficient power available to power-on server」というエラー メッセージが表示されます。
このエラーは、アップグレード後に次の構成のいずれかを変更することで解消できます。ただし、構成の変更は Cisco UCS Manager リリース 3.1 へのアップグレード前に実行することが強く推奨されます。
Cisco UCS domainのハードウェアはアップグレード方法に影響を与えることがあります。エンドポイントをアップグレードする前に、次の注意事項および制約事項を考慮してください。
注意 | 更新が完了するまで、エンドポイントがあるハードウェアを取り外したり、メンテナンス作業を実行しないでください。 ハードウェアが取り外されたり、その他のメンテナンス作業により使用できない場合、ファームウェアの更新は失敗します。 この失敗により、バックアップ パーティションが破損する場合があります。 バックアップ パーティションが破損しているエンドポイントではファームウェアを更新できません。 |
Cisco UCS インフラストラクチャやサーバ ファームウェアのアップグレードの実施前および実施中は、以下を順守してください。
サードパーティ アダプタは、エンドポイントから直接アップグレードできません。このようなアダプタのファームウェアは、ホスト ファームウェア パッケージを使用してアップグレードする必要があります。
クラスタ化されたファブリック インターコネクトは、データ パスの冗長性を意図的に提供します。ただし、データ トラフィックが中断されないように、サービス プロファイルに冗長イーサネットおよびストレージ(FC/FCoE)インターフェイスを設定する必要があります。また、対応するオペレーティング システムが 1 つのファブリック パスの停止を処理するように正しく設定されていることを確認する必要があります。
単一のファブリック インターコネクトのスタンドアロン設定の場合、エンドポイントの直接のファームウェア アップグレードを実行すると、データ トラフィックの中断を最小にできます。ただし、アップグレードを完了するために、ファブリック インターコネクトをリブートする必要があるため、トラフィックの中断は避けられません。
エンドポイントをアップグレードする前に、次の注意事項および制約事項を考慮してください。
シスコのアダプタやサーバ CIMC などの一部のエンドポイントは、直接のファームウェア アップグレードか、またはサービス プロファイルに含まれるファームウェア パッケージによって、アップグレードできます。Cisco UCS domainの設定によって、これらのエンドポイントのアップグレード方法が決まります。サーバに関連付けられているサービス プロファイルに、ホスト ファームウェア パッケージが含まれる場合、ファームウェア パッケージによって、それらのサーバのアダプタをアップグレードします。
サーバに関連付けられたサービス プロファイル内のファームウェア パッケージによるアダプタのアップグレードは、直接のファームウェア アップグレードより優先されます。サーバに関連付けられたサービス プロファイルにファームウェア パッケージが含まれる場合、エンドポイントを直接アップグレードすることはできません。直接のアップグレードを実行するには、サービス プロファイルからファームウェア パッケージを削除する必要があります。
Cisco UCS Manager GUIを使用してファームウェアをアップデートする場合、[Activate Firmware] ダイアログボックスの [Filter] ドロップダウン リストで [ALL]を選択して、すべてのエンドポイントを同時にアクティブにしないでください。多くのファームウェア リリースやパッチには依存関係があるため、ファームウェアの更新を正常に実行するためにエンドポイントを特定の順序でアクティブにする必要があります。この順序はリリースやパッチの内容によって異なります。すべてのエンドポイントをアクティブにしても、更新が目的の順序で実行される保証はなく、エンドポイント、ファブリック インターコネクト、Cisco UCS Manager の間での通信が損なわれる可能性があります。特定のリリースやパッチの依存関係については、当該のリリースやパッチに付属のリリース ノートを参照してください。
ブートフラッシュ パーティションは、Cisco UCS Managerによって管理されるファームウェア イメージ専用です。アップグレードまたはダウングレードを開始するには、ブートフラッシュ パーティションの少なくとも 20 % が使用可能である必要があります。ブートフラッシュ パーティションが 70 % を超えると、障害が発生しますが、自動インストールは続行します。ブートフラッシュ パーティションが 80 % を超えると、障害が発生し、自動インストールは続行しません。
ファブリック インターコネクトのワークスペース パーティションには、テクニカル サポート ファイル、コア ファイル、およびデバッグ プラグインが保存されます。アップグレードまたはダウングレードを開始するには、ワークステーション パーティションの少なくとも 20 % が使用可能である必要があります。
ファブリック インターコネクトの空き領域のチェック には、これらのパーティションで使用可能なストレージのモニタリングに関する詳細情報が掲載されています。
直接のアップグレード時に、アダプタに [Set Startup Version Only] を設定する必要があります。この設定では、アクティブ化されたファームウェアが pending-next-boot 状態に移行し、サーバがすぐにリブートしません。アクティブ化されたファームウェアは、サーバがリブートされるまで、アダプタで実行されているバージョンのファームウェアになりません。ホスト ファームウェア パッケージのアダプタに [Set Startup Version Only] を設定することはできません。
サーバがサービス プロファイルに関連付けられない場合、アクティブ化されたファームウェアは pending-next-boot 状態を維持します。Cisco UCS Manager は、サーバがサービス プロファイルに関連付けられるまで、エンドポイントをリブートせず、ファームウェアをアクティブにしません。必要に応じて、関連付けられていないサーバを手動でリブートまたはリセットして、ファームウェアをアクティブにできます。
I/O モジュールに対して [Set Startup Version Only]を設定した場合、そのデータ パッチ内のファブリック インターコネクトがリブートされると、I/O モジュールがリブートされます。I/O モジュールに対して、[Set Startup Version Only]を設定しない場合、I/O モジュールがリブートし、トラフィックが中断します。また、Cisco UCS Managerがファブリック インターコネクトと I/O モジュールの間のプロトコルとファームウェア バージョンの不一致を検出した場合、Cisco UCS Manager は、ファブリック インターコネクトのファームウェアに一致するファームウェア バージョンを使用して I/O モジュールを自動的に更新し、ファームウェアをアクティブ化して、I/O モジュールを再度リブートします。Cisco UCS domainをアップグレードすると、Cisco UCS Manager によってコンポーネントが再起動され、アップグレード プロセスが完了します。この再起動は、Call Home アラートをトリガーする、サービス中断と同様のイベントおよびコンポーネント障害を発生させます。アップグレードを開始する前に Call Home を無効にしない場合、アップグレード関連コンポーネントによってアラートが生成され、Call Home の設定に基づいて再起動と通知が送信されます。
リリース 2.2(4) で導入されたファブリック インターコネクト トラフィックの待避は、IOM または FEX を通じてファブリック インターコネクトに接続されているすべてのサーバからファブリック インターコネクトを通過するすべてのトラフィックを待避させる機能です。
システムのセカンダリ ファブリック インターコネクトをアップグレードすると、ファブリック インターコネクト上でアクティブなトラフィックが中断されます。このトラフィックは、プライマリ ファブリック インターコネクトにフェールオーバーします。アップグレード プロセス中は、次のようにファブリック待避を使用できます。
[Admin Evac Mode]を [On] に設定して、ファブリック インターコネクトでアクティブなすべてのトラフィックを停止します。
フェールオーバーが設定されている vNIC に対して、Cisco UCS Managerや vCenter などのツールを使用して、トラフィックがフェールオーバーされたことを確認します。
セカンダリ ファブリック インターコネクトをアップグレードします。
[Admin Evac Mode]を [Off] に設定して、停止されたすべてのトラフィック フローを再開します。
クラスタ リードをセカンダリ ファブリック インターコネクトに変更します。
ステップ 1 ~ 4 を繰り返し、他のファブリック インターコネクトをアップグレードします。
次の例では、ファブリック インターコネクト B を通過するアクティブなすべてのトラフィックを停止する方法を示します。
UCS-A# scope fabric-interconnect b UCS-A /fabric-interconnect # stop server traffic Warning: Enabling fabric evacuation will stop all traffic through this Fabric Interconnect from servers attached through IOM/FEX. The traffic will fail over to the Primary Fabric Interconnect for fail over vnics. UCS-A /fabric-interconnect # commit-buffer
コマンドまたはアクション | 目的 |
---|
次の例では、ファブリック インターコネクト B を通過するトラフィックを再開する方法を示します。
UCS-A# scope fabric-interconnect b UCS-A /fabric-interconnect # start server traffic Warning: Resetting fabric evacuation will cause server traffic that failed over to the Primary Fabric Interconnect to fail back to this Fabric Interconnect. UCS-A /fabric-interconnect # commit-buffer
コマンドまたはアクション | 目的 |
---|
次の例は、ファブリック退避前の VIF パスを示しています。
(注) |
UCS-A# show service-profile circuit server 1/6 Service Profile: test1 Server: 1/6 Fabric ID: A Path ID: 1 VIF vNIC Link State Oper State Prot State Prot Role Admin Pin Oper Pin Transport ---------- --------------- ----------- ---------- ------------- ----------- ---------- ---------- --------- 692 eth0 Up Active Active Primary 0/0 1/15 Ether Fabric ID: B Path ID: 1 VIF vNIC Link State Oper State Prot State Prot Role Admin Pin Oper Pin Transport ---------- --------------- ----------- ---------- ------------- ----------- ---------- ---------- --------- 693 eth0 Up Active Passive Backup 0/0 1/15 Ether UCS-A#
次の例は、ファブリック インターコネクト A 退避後の VIF パスを示しています。
(注) |
UCS-A# show service-profile circuit server 1/6 Service Profile: test1 Server: 1/6 Fabric ID: A Path ID: 1 VIF vNIC Link State Oper State Prot State Prot Role Admin Pin Oper Pin Transport ---------- --------------- ----------- ---------- ------------- ----------- ---------- ---------- --------- 692 eth0 Error Error Active Primary 0/0 0/0 Ether Fabric ID: B Path ID: 1 VIF vNIC Link State Oper State Prot State Prot Role Admin Pin Oper Pin Transport ---------- --------------- ----------- ---------- ------------- ----------- ---------- ---------- --------- 693 eth0 Up Active Passive Backup 0/0 1/15 Ether UCS-A#
コマンドまたはアクション | 目的 |
---|
(注) | Admin Evacuation と Oper Evacuation はファブリック インターコネクトの退避ステータスを示します。 |
UCS-A /fabric-interconnect # show detail Fabric Interconnect: ID: B Product Name: Cisco UCS 6248UP PID: UCS-FI-6248UP VID: V01 Vendor: Cisco Systems, Inc. Serial (SN): SSI171400HG HW Revision: 0 Total Memory (MB): 16165 OOB IP Addr: 10.193.32.172 OOB Gateway: 10.193.32.1 OOB Netmask: 255.255.255.0 OOB IPv6 Address: :: OOB IPv6 Gateway: :: Prefix: 64 Operability: Operable Thermal Status: Ok Admin Evacuation: On Oper Evacuation: On Current Task 1: Current Task 2: Current Task 3:
Cisco UCS Managerリリース 3.1(2) では、セキュア ファームウェア アップデートが採用されています。これは、サード パーティの Intel ネットワークおよびストレージ アダプタ用にアダプタのファームウェアを安全に更新できるものです。アダプタのファームウェアをアップグレードまたはダウングレードできるのはサーバ管理者のみです。root 権限を持つ OS 管理者は、アダプタ ファームウェアをダウングレードできません。
以下の NVMe ストレージ ディスクは、UCSB-LSTOR-PT ストレージ コントローラが搭載された Cisco UCS B200 M4 サーバ上でセキュア ファームウェア アップデートをサポートしています。
ストレージ ディスク |
---|
UCS-PCI25-8003 |
UCS-PCI25-16003 |
UCS-PCI25-40010 |
UCS-PCI25-80010 |
(注) |
以下の Intel ネットワーク アダプタは、Cisco UCS C460、C240、および C220 M4 サーバ上でセキュア ファームウェア アップデートをサポートしています。
ネットワーク アダプタ |
---|
UCSC-PCIE-IQ10GF |
UCSC-PCIE-ID10GF |
UCSC-PCIE-ID40GF |
NVMe ストレージ ディスク |
説明 |
---|---|
UCS-PCI25-8003 |
P3600 2.5" |
UCS-PCI25-16003 |
P3600 2.5" |
UCS-PCI25-40010 |
P3700 2.5" |
UCS-PCI25-80010 |
P3700 2.5" |
UCSC-F-I80010 |
P3700 HHHL |
UCSC-F-I160010 |
P3700 HHHL |
UCSC-F-I20003 |
P3600 HHHL |
Cisco UCS Managerリリース 3.1(2) では、セキュア ファームウェア アップデートのサポートが導入されています。
CIMC がバージョン 2.0(13) 以降を実行し、Cisco UCS Managerがリリース 3.1(2) 以降のリリースを実行していることを確認します。CIMC が 2.0(13) よりも前のバージョンを実行し、Cisco UCS Managerがリリース 3.1(2) よりも前のリリースを実行している場合、セキュア ファームウェア アップデートを参照。実行できません。
以前のリリースの Cisco UCS Manager を実行している場合は、Cisco UCS Manager インフラストラクチャ ソフトウェア バンドルと B シリーズ サーバ ソフトウェア バンドルをCisco UCS Manager リリース 3.1(2) にアップグレードします。詳細については、『Cisco UCS Manager Firmware Management Guide, Release 3.1』を参照してください。
Cisco UCS B200 M4 サーバ上に UCSB-LSTOR-PT ストレージ コントローラを取り付け、NVMe ディスクを挿入します。
Cisco UCS B200 M4 サーバを再認識させます。『Cisco UCS Manager Infrastructure Management Guide, Release 3.1』の「Reacknowledging a Blade Server」セクションを参照してください。
(注) | NVMe ディスクのホット プラグはサポートされていません。サーバ検出に失敗せず、NVMe ディスクが CIMC および BIOS で認識されることを確認します。サーバがデフォルト ホスト ファームウェア パッケージを使用するサービス プロファイルに関連付けられた後、Auto Installがトリガーされます。NVMe ディスクは、Auto Install中に最新のファームウェアで更新できます。 Cisco UCS Managerリリース 3.1(2) は NVMe ブートをサポートしていません。NVMe ディスクは、ホスト OS が SAN または iSCSI ブートにある、データ LUN としてのみ使用できます。 |
以前のリリースの Cisco UCS Manager を実行している場合は、Cisco UCS Manager インフラストラクチャ ソフトウェア バンドルと C シリーズ サーバ ソフトウェア バンドルをCisco UCS Manager リリース 3.1(2) にアップグレードします。詳細については、『Cisco UCS Manager Firmware Management Guide, Release 3.1』を参照してください。
Cisco UCS サーバを再認識させます。『Cisco UCS Manager Infrastructure Management Guide, Release 3.1』の「Reacknowledging a Rack Server」セクションを参照してください。
(注) | NVMe ディスクのホット プラグはサポートされていません。サーバ検出に失敗せず、NVMe ディスクが CIMC および BIOS で認識されることを確認します。サーバがデフォルト ホスト ファームウェア パッケージを使用するサービス プロファイルに関連付けられた後、Auto Installがトリガーされます。NVMe ディスクは、Auto Install中に最新のファームウェアで更新できます。 Cisco UCS Managerリリース 3.1(2) は NVMe ブートをサポートしていません。NVMe ディスクは、ホスト OS がローカル ディスク、SAN、または iSCSI ブートにある、データ LUN としてのみ使用できます。 |
Auto Installを使用して Cisco UCS domainのエンドポイントのファームウェアをアップグレードする前に、次の注意、ガイドライン、および制約事項を考慮してください。
(注) | 次の注意事項はAuto Installに固有の事項であり、ファームウェア アップグレードに関するガイドラインとベスト プラクティスの項目と併せて考慮する必要があります。 |
アップグレードを開始する前に、影響を受けるすべてのエンドポイントが次のようになっていることが必要です。
クラスタ設定の場合、ファブリック インターコネクトの高可用性ステータスに、両方が稼働中であると示されていることを確認します。
スタンドアロン設定の場合、ファブリック インターコネクトの [Overall Status] が [Operable] であることを確認します。
アップグレードするすべてのエンドポイントについて、動作可能な状態にあることを確認します。
アップグレードするすべてのサーバについて、すべてのサーバが検出され、検出が失敗しないことを確認します。いずれかのサーバ エンドポイントをアップグレードできないと、Install Server Firmwareの処理は失敗します。
アップグレードする各サーバについて、ストレージ コントローラとローカル ディスク上で実行されているファームウェアのバージョンを確認し、それらが [Ready]状態になっていることを確認します。
Cisco UCS Managerをアップグレードすると、「default」という名前の新しいホスト ファームウェア ポリシーが作成され、まだホスト ファームウェア ポリシーが含まれていないすべてのサービス プロファイルに割り当てられます。デフォルトのホスト ファームウェア ポリシーは空白です。いかなるコンポーネントのいかなるファームウェア エントリも含まれていません。このデフォルトのポリシーは、ユーザの確認応答を受けてからサーバをリブートするのではなく、即時にリブートするように設定することもできます。
サーバ ファームウェアのアップグレード中に、デフォルトのホスト ファームウェア ポリシーを変更して、Cisco UCS domain内のブレード サーバおよびラックマウント サーバ用のファームウェアを追加できます。アップグレードを完了するには、すべてのサーバをリブートする必要があります。
デフォルトのホスト ファームウェア ポリシーに割り当てられている各サービス プロファイルは、そこに含まれているメンテナンス ポリシーに従って、関連付けられているサーバをリブートします。メンテナンス ポリシーが即時リブートに設定されている場合は、[Install Server Firmware]ウィザードでの設定の完了後に、アップグレードをキャンセルしたり、サーバのリブートを阻止することはできません。これらのサービス プロファイルに関連付けられているメンテナンス ポリシーを検証して、時限リブートまたはユーザ確認応答のいずれが設定されているかを確認することを推奨します。
(注) | 2.1(2a) より前のリリースからアップグレードする場合は、CSCup57496 の影響を受ける可能性があります。手動で CIMC をアップグレードしてサービス プロファイルを関連付けたら、管理ファームウェア パックを削除して CIMC のファームウェアをアクティブにします。詳細については、https://tools.cisco.com/bugsearch/bug/CSCup57496を参照してください。これは Cisco UCSには該当しません。 |
クラスタ構成内のファブリック インターコネクトを確実に同期させるには、それらが同じ日付、時刻、タイム ゾーンに設定されていることを確認する必要があります。両方のファブリック インターコネクトに NTP サーバと正しいタイム ゾーンを設定することを推奨します。ファブリック インターコネクトの日付、時刻、タイム ゾーンが同期していないと、Auto Installでエラーが発生することがあります。
インフラストラクチャ ファームウェアをサーバ ファームウェアと同時にアップグレードすることはできません。インフラストラクチャ ファームウェアを先にアップグレードし、次にサーバ ファームウェアをアップグレードすることを推奨します。インフラストラクチャ ファームウェアのアップグレードが完了するまで、サーバ ファームウェアのアップグレードは開始しないでください。
Auto Installを使用してエンドポイントをアップグレードするには、次の権限が必要です。
権限 | 実行できるアップグレード作業 |
---|---|
admin |
|
サービス プロファイルの計算(ls-compute) |
Install Server Firmwareの実行 |
サービス プロファイルのサーバ ポリシー(ls-server-policy) |
ホスト ファームウェア パッケージの追加、削除、および変更 |
サービス プロファイルの設定ポリシー(ls-config-policy) |
ホスト ファームウェア パッケージの追加、削除、および変更 |
Install Server Firmwareでは、ホスト ファームウェア パッケージを使用してサーバをアップグレードするため、Cisco UCS domainのすべてのサーバを同じファームウェア バージョンにアップグレードする必要はありません。ただし、関連するサービス プロファイルにInstall Server Firmwareを設定したときに選択したホスト ファームウェア パッケージが含まれるサーバは、すべて指定したソフトウェア バンドルのファームウェア バージョンにアップグレードされます。
サーバに関連付けられたサービス プロファイルにホスト ファームウェア パッケージが含まれていない場合、このサーバのエンドポイントのアップグレードにInstall Server Firmwareを使用すると、Install Server Firmwareではデフォルトのホスト ファームウェア パッケージを使用してサーバをアップグレードします。Install Server Firmwareでは、デフォルトのホスト ファームウェア パッケージのみ更新できます。
サーバに関連付けられているサービス プロファイルが以前に Install Server Firmwareのデフォルトのホスト ファームウェア パッケージによって更新されている場合、このサーバの CIMC またはアダプタをアップグレードするには、次のいずれかの方法を使用する必要があります。
Install Server Firmwareを実行した後、Cisco UCS domainにサーバを追加すると、新しいサーバのファームウェアはInstall Server Firmwareによって自動的にアップグレードされません。新しく追加したサーバのファームウェアを、最後にInstall Server Firmwareを実行したときに使用したファームウェア バージョンにアップグレードする場合は、エンドポイントを手動でアップグレードしてそのサーバのファームウェアをアップグレードする必要があります。Install Server Firmwareには、ファームウェア バージョンの変更が毎回必要です。サーバを同じファームウェア バージョンにアップグレードするためにInstall Server Firmwareを再実行することはできません。
(注) | アップグレードが終了すると、Cisco UCS Managerで [Firmware Auto Sync Server] ポリシーを使用して、新たに検出されたサーバを自動的に更新できます。 |
Cisco UCS Centralから Cisco UCS Manager のファームウェアの管理を開始する前に、次の注意、ガイドライン、および制約事項を考慮してください。
ドメイン グループに定義したファームウェア ポリシーは、このドメイン グループに追加されるすべての新しい Cisco UCS Domainに適用されます。ドメイン グループでファームウェア ポリシーが定義されていない場合、Cisco UCS Domainは親ドメイン グループからポリシーを継承します。
グローバル ポリシーは、Cisco UCS Manager が Cisco UCS Central との接続を失った場合でも Cisco UCS Manager にグローバルに残ります。Cisco UCS Manager でグローバルなポリシーのいずれかに変更を適用するには、所有権をグローバルからローカルに変更する必要があります。
ホスト ファームウェア パッケージを Cisco UCS Centralから作成した場合は、これをサービス プロファイルに関連付けて、Cisco UCS domainsにアップデートを展開する必要があります。
Cisco UCS Centralでホスト ファームウェア パッケージを変更すると、その変更はホスト ファームウェア アップデートに関連付けられた次のメンテナンス スケジュールの際に Cisco UCS domainsに適用されます。
Cisco UCS Centralで定義したホスト ファームウェア メンテナンス ポリシーは、Cisco UCS domainsの org-root に適用されます。Cisco UCS Centralから Cisco UCS Domainのサブ組織に対して別のホスト メンテナンス ポリシーを定義することはできません。
サービス プロファイルとの関連付けを持たないサーバは、ホスト ファームウェア パックのデフォルト バージョンにアップグレードされます。これらのサーバにはメンテナンス ポリシーがないため、ただちにリブートされます。
Cisco UCS Centralでメンテナンス ポリシーを指定してユーザの確認応答をイネーブルにし、スケジュールを指定しない場合は、Cisco UCS Manager からのみ保留中のタスクに確認応答できます。Cisco UCS Centralから保留中のアクティビティに確認応答するには、グローバルなスケジューラを使用してメンテナンスをスケジュールし、ユーザの確認応答をイネーブルにする必要があります。
Cisco UCS Centralでメンテナンス ポリシーをスケジュールし、ユーザの確認応答をイネーブルにすると、このタスクは保留中のアクティビティ タブにスケジュールで指定した時刻で表示されます。
メンテナンス ポリシーの保留中のアクティビティは、ドメイン グループのセクションからのみ表示できます。
任意のファームウェアのスケジュールに対するユーザの確認応答をイネーブルにして、Cisco UCS domainsでの予期せぬリブートを避けるようにしてください。
(注) | Cisco UCS Centralのファームウェア管理の詳細については、『Cisco UCS Central Administration Guide』および『Cisco UCS Central CLI Reference Manual』の「Firmware Management」の章を参照してください。 |
Cisco UCS domainのすべてのエンドポイントが完全に機能し、それらのエンドポイントのファームウェアのアップグレードまたはダウングレードを開始する前に、すべてのプロセスが完了している必要があります。機能状態でないエンドポイントはアップグレードまたはダウングレードすることはできません。
たとえば、検出されていないサーバのファームウェアはアップグレードまたはダウングレードできません。最大回数の再試行後に失敗した FSM などの未完了のプロセスによって、エンドポイントのアップグレードやダウングレードが失敗する可能性があります。FSM が実行中の場合、Cisco UCS Manager によって、更新とアクティベーションがキューに入れられ、FSM が正常に完了すると、それらが実行されます。
Cisco UCS domainのファームウェアをアップグレードまたはダウングレードする前に、次の作業を実行します。
リリース ノートの内容を確認します。
適切な『Hardware and Software Interoperability Matrix』を参照し、すべてのサーバのオペレーティング システムドライバのレベルが、アップグレード予定の Cisco UCS のリリースに対して正しいレベルになっていることを確認します。
設定を All Configuration バックアップ ファイルにバックアップします。
クラスタ設定の場合、ファブリック インターコネクトの高可用性ステータスに、両方が稼働中であると示されていることを確認します。
スタンドアロン設定の場合、ファブリック インターコネクトの [Overall Status] が [Operable] であることを確認します。
データ パスが稼働中であることを確認します。詳細については、データ パスの準備が整っていることの確認を参照してください。
すべてのサーバ、I/O モジュール、アダプタが完全に機能することを確認します。動作不能なサーバはアップグレードできません。
Cisco UCS domainに致命的または重大な障害がないことを確認します。このような障害がある場合は解決してから、システムをアップグレードしてください。致命的または重大な障害があると、アップグレードが失敗する可能性があります。
すべてのサーバが検出されていることを確認します。サーバの電源を入れる必要はありません。また、サーバをサービス プロファイルと関連付ける必要もありません。
ラックマウント サーバを Cisco UCS domainに統合する場合、Cisco UCS Manager で管理するシステムにラックマウント サーバをインストールし、統合する方法については、該当する『C-Series Rack-Mount Server Integration Guide』の指示に従います。
iSCSI ブート用に設定されている Cisco UCS domainsの場合、次の操作を行ってから、Cisco UCS リリース 3.1(1) 以降にアップグレードしてください。
ファームウェアをインストールする前に、次のアップグレード前検証を実行してください。
Cisco UCS Managerからバックアップを実行する場合は、システム設定全体またはその一部のスナップショットを作成し、ファイルをネットワーク上の場所にエクスポートします。バックアップは、システムが起動されて動作している間に実行できます。バックアップ操作では、管理プレーンからの情報だけが保存されます。バックアップは、サーバまたはネットワーク トラフィックには影響しません。
シスコでは、Cisco UCS ファームウェア アップグレードを開始する前に、次のバックアップ ファイルを作成することを推奨します。
この手順は、All Configuration バックアップ ファイルの既存のバックアップ操作がないことを前提としています。
バックアップ サーバの IPv4 アドレスまたは IPv6 アドレスおよび認証クレデンシャルを取得します。
次の例では、SCP を使用して host35 という名前のホストに All Configuration バックアップ ファイルを作成し、トランザクションをコミットしています。
UCS-A# scope system UCS-A /system* # create backup scp://user@host35/backups/all-config.bak all-configuration enabled Password: UCS-A /system* # commit-buffer UCS-A /system #
バックアップ サーバの IPv4 アドレスまたは IPv6 アドレスおよび認証クレデンシャルを取得します。
次の例では、週単位のバックアップのための full state バックアップ ポリシーを設定し、トランザクションをコミットする方法を示します。
UCS-A# scope org / UCS-A /org # scope backup-policy default UCS-A /org/backup-policy # set hostname host35 UCS-A /org/backup-policy* # set protocol scp UCS-A /org/backup-policy* # set user UserName32 UCS-A /org/backup-policy* # set password Password: UCS-A /org/backup-policy* # set remote-file /backups/full-state1.bak UCS-A /org/backup-policy* # set adminstate enable UCS-A /org/backup-policy* # set schedule weekly UCS-A /org/backup-policy* # set descr "This is a full state weekly backup." UCS-A /org/backup-policy* # commit-buffer UCS-A /org/backup-policy #
Cisco Smart Call Home は、Cisco UCS の Call Home 機能を強化する Web アプリケーションです。Smart Call Home により、予防的な診断および重要なシステム イベントのリアルタイムの電子メール アラートが提供されます。それにより、ネットワークの可用性が高まり、運用効率が向上します。Smart Call Home は、Cisco UCS の Cisco Unified Computing Support サービスと Cisco Unified Computing Mission Critical Support サービスによって提供されるセキュア接続のサービスです。『Cisco UCS Manager Administration Management Guide』には、Smart Call Home の設定に関する詳細情報が掲載されています。
ファームウェアをアップグレードすると、Cisco UCS Manager によってコンポーネントが再起動され、アップグレード プロセスが完了します。この再起動によって、電子メール アラートがトリガーされる可能性があります。Smart Call Home を無効にすることで、ファームウェア アップグレード プロセス中にこのようなアラートや TAC への自動サポート ケースを回避できます。
コマンドまたはアクション | 目的 |
---|
次に、Smart Call Home を無効にし、トランザクションをコミットする例を示します。
UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # disable UCS-A /monitoring/callhome* # commit-buffer UCS-A /monitoring/callhome #
フォールト抑制を使用すると、予定されたメンテナンス時間中に SNMP トラップおよび Call Home 通知を抑制することができます。フォールト抑制タスクを作成し、一時的な障害がレイズまたはクリアされるたびに通知が送信されることを防止できます。
障害は、期限切れになるか、フォールト抑制タスクがユーザによって手動で停止されるまで抑制されたままになります。障害抑制が終了すると、Cisco UCS Manager はクリアされなかった未処理の抑制された障害に関する通知を送信します。
ファームウェア アップグレード中のすべてのコンポーネントのフォールト抑制を有効にすると、期限切れになるか、またはアップグレード後にコンポーネントが再稼働状態になるまで、そのコンポーネントに関連するエラーが抑制されます。たとえば、ファブリック インターコネクト障害がファームウェア アップグレード中に抑制されるように設定されている場合、アップグレード中にそのファブリック インターコネクトによってトリガーされたすべての障害は表示されません。
ファブリック インターコネクトが再起動するときにダウンするポート設定とサービスは、ファブリック インターコネクトがアップ状態に戻ったときに再確立されるようにすることがきわめて重要です。
Cisco UCS Managerリリース 3.1 以降では、ファブリック インターコネクトの最後のリブート後に再確立されないサービスがCisco UCS Manager に表示されます。Cisco UCS Managerは、ファブリック インターコネクトをリブートする前に未処理の障害のベースラインを作成します。ファブリック インターコネクトがリブートして再稼働状態に復帰したら、最後のベースライン以降に生成された新しい障害を確認して、ファブリックのリブートによってダウンしたサービスを特定できます。
Cisco UCS Manager が未処理の障害のベースラインを作成してから特定の期間が経過すると、ベースラインはクリアされ、すべての障害が新しい障害として表示されます。この期間は、ベースラインの有効期限と呼ばれます。障害のベースライン有効期限の変更には、Cisco UCS Managerでベースラインの有効期限を変更する方法に関する詳細が掲載されています。
シスコでは、ファブリック インターコネクトのリブートまたは待避を実行する前に、サービスに影響する障害を解決することを推奨します。
Cisco UCS Managerでは、ベースラインの有効期限を変更できます。
コマンドまたはアクション | 目的 | |||
---|---|---|---|---|
ステップ 1 | UCS-A# scope monitoring |
モニタリング モードを開始します。 | ||
ステップ 2 | UCS-A /monitoring # scope fault policy |
モニタリング障害ポリシー モードを開始します。 | ||
ステップ 3 | UCS-A /monitoring/fault-policy # show |
障害ポリシーの詳細を表示します。 | ||
ステップ 4 | UCS-A /monitoring/fault-policy # set baseline-expiration-interval {days hours minutes seconds} |
ベースライン有効期限を変更します。 デフォルトのベースライン有効期限は 24 時間です。
| ||
ステップ 5 | UCS-A /monitoring/fault-policy* # commit |
トランザクションをコミットします。 | ||
ステップ 6 | UCS-A /monitoring/fault-policy # show |
障害ポリシーの詳細を表示します。 |
次に、障害のベースライン有効期限を変更する例を示します。
UCS-A# scope monitoring UCS-A /monitoring # scope fault policy UCS-A /monitoring/fault-policy # show Fault Policy: Clear Action Clear Interval Retention Interval (dd:hh:mm:ss) Flap Interval (sec) Baseline Expiration Interval (dd:hh:mm:ss) ------------ -------------- -------------------------------- ----------------------- ------------------------------------------ Retain 00:00:20:00 00:01:00:00 10 10:00:00:12 UCS-A /monitoring/fault-policy # set baseline-expiration-interval 0 2 24 0 UCS-A /monitoring/fault-policy* # commit UCS-A /monitoring/fault-policy # show Fault Policy: Clear Action Clear Interval Retention Interval (dd:hh:mm:ss) Flap Interval (sec) Baseline Expiration Interval (dd:hh:mm:ss) ------------ -------------- -------------------------------- ----------------------- ------------------------------------------ Retain 10:00:00:00 01:01:01:01 10 00:02:24:00 UCS-A /monitoring/fault-policy #
コマンドまたはアクション | 目的 |
---|
次に、アップグレード プロセスのさまざまな段階で生成された障害を表示する方法の例を示します。
プライマリ ファブリック インターコネクトのリブート前の障害
UCS-A# show fault Severity Code Last Transition Time ID Description --------- -------- ------------------------ -------- ----------- Major F0283 2015-06-17T21:08:09.301 57360 fc VIF 687 on server 1 / 6 of switch A down, reason: NPV upstream port not available Warning F0156 2015-06-17T21:07:44.114 53557 Server, vendor(Cisco Systems Inc), model(N20-B6620-1), serial(QCI133400WR) in slot 1/3 presence: mismatch Major F0283 2015-06-16T21:02:33.014 72467 fc VIF 688 on server 1 / 6 of switch B down, reason: NPV upstream port not available Major F0207 2015-06-15T22:40:11.636 57312 Adapter host interface 1/6/1/1 link state: down Major F0479 2015-06-15T22:40:11.635 57311 Virtual interface 687 link state is down Major F0207 2015-06-15T22:40:11.633 57310 Adapter host interface 1/6/1/2 link state: down Major F0479 2015-06-15T22:40:11.632 57309 Virtual interface 688 link state is down
プライマリ ファブリック インターコネクトのリブート後の障害
UCS-A# show fault Severity Code Last Transition Time ID Description --------- -------- ------------------------ -------- ----------- Major F0209 2015-06-17T21:40:49.301 57760 Adapter uplink interface on server 1 / 6 of switch A down, Please verify the connectivity to Fabric Interconnect. Major F0207 2015-06-17T21:40:11.636 57712 Adapter host interface 1/6/1/1 link state: down Major F0479 2015-06-17T21:40:11.635 57711 Virtual interface 685 link state is down Major F0283 2015-06-17T21:08:09.301 57360 fc VIF 687 on server 1 / 6 of switch A down, reason: NPV upstream port not available Warning F0156 2015-06-17T21:07:44.114 53557 Server, vendor(Cisco Systems Inc), model(N20-B6620-1), serial(QCI133400WR) in slot 1/3 presence: mismatch Major F0283 2015-06-16T21:02:33.014 72467 fc VIF 688 on server 1 / 6 of switch B down, reason: NPV upstream port not available Major F0207 2015-06-15T22:40:11.636 57312 Adapter host interface 1/6/1/1 link state: down Major F0479 2015-06-15T22:40:11.635 57311 Virtual interface 687 link state is down Major F0207 2015-06-15T22:40:11.633 57310 Adapter host interface 1/6/1/2 link state: down Major F0479 2015-06-15T22:40:11.632 57309 Virtual interface 688 link state is down
プライマリ ファブリック インターコネクトのリブートにより生成された障害を表示する方法
UCS-A /monitoring # show new-faults Severity Code Last Transition Time ID Description --------- -------- ------------------------ -------- ----------- Major F0209 2015-06-17T21:40:49.301 57760 Adapter uplink interface on server 1 / 6 of switch A down, Please verify the connectivity to Fabric Interconnect. Major F0207 2015-06-17T21:40:11.636 57712 Adapter host interface 1/6/1/1 link state: down Major F0479 2015-06-17T21:40:11.635 57711 Virtual interface 685 link state is down
プライマリ ファブリック インターコネクトのリブート前の障害を表示する方法
UCS-A# show baseline-faults Severity Code Last Transition Time ID Description --------- -------- ------------------------ -------- ----------- Major F0283 2015-06-17T21:08:09.301 57360 fc VIF 687 on server 1 / 6 of switch A down, reason: NPV upstream port not available Warning F0156 2015-06-17T21:07:44.114 53557 Server, vendor(Cisco Systems Inc), model(N20-B6620-1), serial(QCI133400WR) in slot 1/3 presence: mismatch Major F0283 2015-06-16T21:02:33.014 72467 fc VIF 688 on server 1 / 6 of switch B down, reason: NPV upstream port not available Major F0207 2015-06-15T22:40:11.636 57312 Adapter host interface 1/6/1/1 link state: down Major F0479 2015-06-15T22:40:11.635 57311 Virtual interface 687 link state is down Major F0207 2015-06-15T22:40:11.633 57310 Adapter host interface 1/6/1/2 link state: down Major F0479 2015-06-15T22:40:11.632 57309 Virtual interface 688 link state is down
Cisco UCS domainがハイ アベイラビリティ クラスタ設定で実行されている場合は、両方のファブリック インターコネクトが動作していることを確認する必要があります。
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | UCS-A# scope fabric-interconnect {a | b} |
指定したファブリック インターコネクトのファブリック インターコネクト モードを開始します。 |
ステップ 2 | UCS-A /fabric-interconnect #show |
ファブリック インターコネクトの情報を表示します。 ファブリック インターコネクトの動作が Operable 状態であることを確認します。動作可能な状態でない場合は、show tech-support コマンドを実行してシスコのテクニカル サポートに問い合わせてください。ファームウェア アップグレードに進まないでください。show tech-support コマンドの詳細については、Cisco UCS Manager B-Series Troubleshooting Guideを参照してください。 |
次の例では、両方のファブリック インターコネクトの動作が Operable 状態として表示されています。
UCS-A# scope fabric-interconnect a UCS-A /fabric-interconnect # show Fabric Interconnect: ID OOB IP Addr OOB Gateway OOB Netmask Operability -- --------------- --------------- --------------- ----------- A 192.168.100.10 192.168.100.20 255.255.255.0 Operable UCS-A /fabric-interconnect # exit UCS-A# scope fabric-interconnect b UCS-A /fabric-interconnect # show Fabric Interconnect: ID OOB IP Addr OOB Gateway OOB Netmask Operability -- --------------- --------------- --------------- ----------- B 192.168.100.11 192.168.100.20 255.255.255.0 Operable
高可用性ステータスは、クラスタ設定の両方のファブリック インターコネクトで同じです。
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | UCS-A# show cluster state |
ハイ アベイラビリティ クラスタの両方のファブリック インターコネクトの動作状態およびリーダーシップ ロールを表示します。 両方のファブリック インターコネクト(A および B)が Up 状態であること、および HA が Ready 状態であることを確認します。ファブリック インターコネクトが Up 状態でない場合、または HA が Ready 状態でない場合、show tech-support コマンドを実行し、シスコ テクニカル サポートにお問い合わせください。ファームウェア アップグレードに進まないでください。show tech-support コマンドの詳細については、Cisco UCS Troubleshooting Guideを参照してください。 また、どのファブリック インターコネクトがプライマリ ロールで、どのファブリック インターコネクトが従属ロールであるかにも注目してください。ファブリック インターコネクトのファームウェアをアップグレードするためにこの情報が必要です。 |
次の例の表示では、両方のファブリック インターコネクトが Up 状態、HA が Ready 状態、ファブリック インターコネクト A がプライマリ ロール、ファブリック インターコネクト B が従属ロールです。
UCS-A# show cluster state Cluster Id: 0x4432f72a371511de-0xb97c000de1b1ada4 A: UP, PRIMARY B: UP, SUBORDINATE HA READY
サービス プロファイルの変更の一部、またはサービス プロファイル テンプレートの更新は、中断をともなうことや、サーバのリブートが必要になることがあります。メンテナンス ポリシーは、サーバに関連付けられたサービス プロファイル、または 1 つ以上のサービス プロファイルに関連付けられた更新中のサービス プロファイルに対して、サーバのリブートが必要になるような変更が加えられた場合の Cisco UCS Managerの対処方法を定義します。
このメンテナンス ポリシーを遅延展開のために設定する場合は、スケジュールを作成します。
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | UCS-A# scope org org-name |
指定した組織の組織モードを開始します。ルート組織モードを開始するには、org-name として / を入力します。 |
ステップ 2 | UCS-A /org # scope maint-policy default |
デフォルト メンテナンス ポリシーのメンテナンス ポリシー モードを開始します。 |
ステップ 3 | UCS-A /org/maint-policy # set reboot-policy {immediate | timer-automatic | user-ack} |
|
ステップ 4 | UCS-A /org/maint-policy # set scheduler scheduler-name | (任意)
reboot-policy プロパティが timer-automatic に設定された場合、メンテナンス操作がサーバに適用されるタイミングを指定するスケジュールを選択する必要があります。Cisco UCS はスケジュールされた時刻にサーバをリブートしてサービス プロファイルの変更を完了します。 |
ステップ 5 | UCS-A /org/maint-policy # commit-buffer |
トランザクションをシステムの設定にコミットします。 |
UCS-A# scope org / UCS-A /org # scope maint-policy default UCS-A /org/maint-policy* # set reboot-policy user-ack UCS-A /org/maint-policy* # commit-buffer UCS-A /org/maint-policy #
ファームウェアをアップグレードする前に、セカンダリ ファブリック インターコネクトの管理インターフェイスをシャットダウンします。これにより、サーバと管理インターフェイス間のアクティブな KVM 接続がすべてリセットされます。GUI フローがプライマリ ファブリック インターコネクトにフェールオーバーされるため、GUI から切断される時間が短縮されます。
Cisco UCS Manager によって管理インターフェイスの障害が検出されると、障害レポートが生成されます。障害レポートの数が設定された数に達した場合、システムは管理インターフェイスが使用不能であると見なし、障害を生成します。デフォルトでは、管理インターフェイス モニタリング ポリシーは有効です。『Cisco UCS Manager システム モニタリング ガイド』には、管理インターフェイス モニタリング ポリシーに関する詳細が掲載されています。
ステップ 1 | モニタリング モードを開始します。
UCS-A# scope monitoring |
ステップ 2 | 管理インターフェイス モニタリング ポリシーをイネーブルにするか、ディセーブルにします。
UCS-A /monitoring # set mgmt-if-mon-policy admin-state {enabled | disabled} |
ステップ 3 | UCS-A /monitoring # commit-buffer
トランザクションをシステムの設定にコミットします。 |
ステップ 4 | ファブリック インターコネクトに接続されているアップストリーム スイッチへの Telnet セッションを開きます。 |
ステップ 5 | ファブリック インターコネクトの管理ポートが接続されているインターフェイスの設定を確認し、スイッチの shut コマンドを使用して無効にします。
このインターフェイスを通じて開いているすべての KVM セッションが終了します。 |
ステップ 6 | KVM セッションを再接続して、これらのセッションがセカンダリ ファブリック インターコネクトのアップグレードの影響を受けないようにします。 |
次に、管理インターフェイス モニタリング ポリシーを無効にし、トランザクションをコミットする例を示します。
UCS-A# scope monitoring UCS-A /monitoring # set mgmt-if-mon-policy admin-state enabled UCS-A /monitoring* # commit-buffer UCS-A /monitoring #
Cisco UCSがハイ アベイラビリティ クラスタ設定で実行されている場合、すべてのシャーシで両方の I/O モジュールのステータスを確認する必要があります。
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | UCS-A# scope chassis chassis-id |
指定したシャーシでシャーシ モードを開始します。 |
ステップ 2 | UCS-A /chassis # scope iom iom-id |
選択した I/O モジュールでシャーシ I/O モジュール モードを開始します。 |
ステップ 3 | UCS-A # show |
指定したシャーシの指定した I/O モジュールのステータスを表示します。 I/O モジュールの全体的なステータスが Operable 状態であることを確認します。全体的なステータスが Operable 状態ではない場合、show tech-support コマンドを実行し、シスコ テクニカル サポートにお問い合わせください。ファームウェア アップグレードに進まないでください。show tech-support コマンドの詳細については、Cisco UCS Troubleshooting Guideを参照してください。 |
次の例では、シャーシ 1 の両方の I/O モジュールの全体的なステータスが Operable 状態として表示されています。
UCS-A# scope chassis 1 UCS-A /chassis # scope iom 1 UCS-A /chassis/iom # show IOM: ID Side Fabric ID Overall Status ---------- ----- --------- -------------- 1 Left A Operable UCS-A /chassis/iom # exit UCS-A /chassis # scope iom 2 UCS-A /chassis/iom # show IOM: ID Side Fabric ID Overall Status ---------- ----- --------- -------------- 2 Right B Operable
コマンドまたはアクション | 目的 |
---|
次の例では、シャーシ 1 のサーバ 7 の全体的なステータスが Ok 状態として表示されています。
UCS-A# scope server 1/7 UCS-A /chassis/server # show status detail Server 1/7: Slot Status: Equipped Conn Path: A,B Conn Status: A,B Managing Instance: B Availability: Unavailable Admin State: In Service Overall Status: Ok Oper Qualifier: N/A Discovery: Complete Current Task:
コマンドまたはアクション | 目的 |
---|
次の例では、シャーシ 1 のサーバ 7 のアダプタの全体的なステータスが Operable 状態として表示されています。
UCS-A# scope server 1/7 UCS-A /chassis/server # show adapter status Server 1/1: Overall Status -------------- Operable
以下の項では、データ パスの準備ができていることを確認する手順を説明します。
ダイナミック vNIC および VMware vCenter との統合を含むCisco UCSをアップグレードするとき、すべてのダイナミック vNIC が新しいプライマリ ファブリック インターコネクトで動作中であることを確認する必要があります。データ パスの中断を避けるため、以前のプライマリ ファブリック インターコネクト上で新しいソフトウェアを有効にする前に、vNIC が動作中であることを確認します。
この手順は Cisco UCS Manager GUIで実行します。
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | UCS-A /fabric-interconnect # connect nxos {a | b} |
ファブリック インターコネクトの NX-OS モードを開始します。 |
ステップ 2 | UCS-A(nxos)# show int br | grep -v down | wc –l |
アクティブなイーサネット インターフェイスの数を返します。 この数がアップグレードの前に稼働していたイーサネット インターフェイスの数と一致することを確認します。 |
ステップ 3 | UCS-A(nxos)# show platform fwm info hw-stm | grep '1.'| wc –l |
MAC アドレスの合計数を返します。 この数がアップグレード前の MAC アドレスの数と一致することを確認します。 |
次の例では、従属ファブリック インターコネクト A のアクティブなイーサネット インターフェイスおよび MAC アドレスの数が返され、ファブリック インターコネクトのイーサネット データ パスが稼働していることを確認できます。
UCS-A /fabric-interconnect # connect nxos a UCS-A(nxos)# show int br | grep -v down | wc -l 86 UCS-A(nxos)# show platform fwm info hw-stm | grep '1.' | wc -l 80
Cisco UCS domainのアップグレード時に最適な結果を得るためには、アップグレードを開始する前、および従属ファブリック インターコネクトをアクティブ化した後にこのタスクを実行し、結果を比較することを推奨します。
コマンドまたはアクション | 目的 |
---|
次の例では、flogi テーブルおよび従属ファブリック インターコネクト A にログインしたサーバの数が返され、ファブリック インターコネクトのファイバ チャネル データ パスがファイバ チャネル エンドホスト モードで稼働していることを確認できます。
UCS-A /fabric-interconnect # connect nxos a UCS-A(nxos)# show npv flogi-table -------------------------------------------------------------------------------- SERVER EXTERNAL INTERFACE VSAN FCID PORT NAME NODE NAME INTERFACE -------------------------------------------------------------------------------- vfc705 700 0x69000a 20:00:00:25:b5:27:03:01 20:00:00:25:b5:27:03:00 fc3/1 vfc713 700 0x690009 20:00:00:25:b5:27:07:01 20:00:00:25:b5:27:07:00 fc3/1 vfc717 700 0x690001 20:00:00:25:b5:27:08:01 20:00:00:25:b5:27:08:00 fc3/1 Total number of flogi = 3. UCS-A(nxos)# show npv flogi-table | grep fc | wc -l 3
Cisco UCS domainのアップグレード時に最適な結果を得るためには、アップグレードを開始する前、および従属ファブリック インターコネクトをアクティブ化した後にこのタスクを実行し、結果を比較することを推奨します。
コマンドまたはアクション | 目的 |
---|
次の例では、flogi テーブルおよび従属ファブリック インターコネクト A にログインしたサーバの数が返され、ファブリック インターコネクトのファイバ チャネル データ パスがファイバ チャネル エンドホスト モードで稼働していることを確認できます。
UCS-A /fabric-interconnect # connect nxos a UCS-A(nxos)# show flogi database -------------------------------------------------------------------------------- INTERFACE VSAN FCID PORT NAME NODE NAME -------------------------------------------------------------------------------- vfc726 800 0xef0003 20:00:00:25:b5:26:07:02 20:00:00:25:b5:26:07:00 vfc728 800 0xef0007 20:00:00:25:b5:26:07:04 20:00:00:25:b5:26:07:00 vfc744 800 0xef0004 20:00:00:25:b5:26:03:02 20:00:00:25:b5:26:03:00 vfc748 800 0xef0005 20:00:00:25:b5:26:04:02 20:00:00:25:b5:26:04:00 vfc764 800 0xef0006 20:00:00:25:b5:26:05:02 20:00:00:25:b5:26:05:00 vfc768 800 0xef0002 20:00:00:25:b5:26:02:02 20:00:00:25:b5:26:02:00 vfc772 800 0xef0000 20:00:00:25:b5:26:06:02 20:00:00:25:b5:26:06:00 vfc778 800 0xef0001 20:00:00:25:b5:26:01:02 20:00:00:25:b5:26:01:00 Total number of flogi = 8. UCS-A(nxos)# show flogi database | grep fc | wc -l 8