この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章は、次の項で構成されています。
サービス プロファイルの変更の一部、またはサービス プロファイル テンプレートの更新は、中断をともなうことや、サーバのリブートが必要になることがあります。 ただし、これらの中断をともなう設定変更をいつ実行するかを、遅延展開によって制御できます。 たとえば、サービス プロファイルの変更をすぐに展開するか、指定されたメンテナンス時間帯に展開するかを選択できます。 また、サービス プロファイルの展開にユーザの明示的な確認応答が必要かどうかを選択できます。
遅延展開は、サーバとサービス プロファイルとの関連付けによって発生するすべての設定変更に使用できます。 これらの設定変更は、サービス プロファイルへの変更、サービス プロファイルに含まれるポリシーへの変更、更新サービス プロファイル テンプレートへの変更によってプロンプト表示される場合があります。 たとえば、サーバ BIOS、RAID コントローラ、ホスト HBA、ネットワーク アダプタなどのホスト ファームウェア パッケージや管理ファームウェア パッケージによって、ファームウェアのアップグレードおよびアクティブ化を延期することもできます。 ただし、Cisco UCS Manager、ファブリック インターコネクト、I/O モジュールなど、ファームウェア パッケージを使用しないコンポーネントのファームウェア イメージの直接展開を遅延させることはできません。
遅延展開は、サーバのリブートを必要とする次のアクションに使用できません。
サーバのサービス プロファイルの最初の関連付け
サービス プロファイルと別のサーバを関連付けない、サービス プロファイルのサーバからの関連付けの最終解除
サーバの解放
サーバの再認識
サーバのリセット
サービス プロファイル変更の展開を遅延させる場合、1 つ以上のメンテナンス ポリシーを設定し、各サービス プロファイルにメンテナンス ポリシーを設定する必要があります。 展開が発生する時間帯を指定する場合、1 つ以上の繰り返しオカレンスまたはワンタイム オカレンスを持つスケジュールを少なくとも 1 つ作成し、そのスケジュールをメンテナンス ポリシーに含める必要があります。
スケジュールには、一連のオカレンスが含まれます。 これらのオカレンスは、1 回だけ発生させるか、または毎週指定した日時に繰り返し発生させることができます。 オカレンスの時間長や実行されるタスクの最大数といった、オカレンスで定義されるオプションにより、サービス プロファイルの変更が展開されるかどうかが決まります。 たとえば、最大時間長またはタスク数に達したため特定のメンテナンス時間帯に変更を展開できない場合、この展開は次のメンテナンス時間に持ち越されます。
各スケジュールは、Cisco UCS ドメインが 1 つまたは複数のメンテナンス時間に入っているかどうか、定期的に確認します。 入っている場合、スケジュールはメンテナンス ポリシーで指定された制限に対し適切な展開を実行します。
スケジュールには、スケジュールに関連付けられたメンテナンス時間を決定する 1 つ以上のオカレンスが含まれています。 オカレンスは次のいずれかになります。
ワンタイム オカレンスは、単一のメンテナンス時間を定義します。 これらの時間帯は、その時間帯の最大時間長まで、または時間帯の中で実行可能なタスクの最大数に達するまで継続されます。
繰り返しオカレンスは、一連のメンテナンス時間を定義します。 これらの時間帯は、タスクの最大数に達するまで、またはオカレンスに指定された日の終わりに達するまで継続します。
メンテナンス ポリシーは、サーバに関連付けられたサービス プロファイル、または 1 つ以上のサービス プロファイルに関連付けられた更新中のサービス プロファイルに対して、サーバのリブートが必要になるような変更が加えられた場合の Cisco UCS Manager の対処方法を定義します。
メンテナンス ポリシーは、Cisco UCS Manager でのサービス プロファイルの変更の展開方法を指定します。 展開は、次のいずれかの方法で実行されます。
スケジュール済みのメンテナンス ウィンドウ中に変更を展開するように設定されているメンテナンス ポリシーでは、ポリシーに有効なスケジュールが含まれていることが必要です。 この場合、最初に使用可能なメンテナンス ウィンドウ中に変更が展開されます。
![]() (注) |
メンテナンス ポリシーでは、関連付けられたサービス プロファイルに設定変更が加えられた場合に、サーバの即時リブートは回避できますが、 次のアクションの即時実行は回避されません。
|
Cisco UCS ドメインで遅延展開を設定すると、Cisco UCS Manager を使用して保留中のアクティビティすべてを表示することができます。 ユーザの確認応答を待っているアクティビティと、スケジュールされたアクティビティを表示できます。
Cisco UCS ドメイン ドメインに保留中のアクティビティがある場合、Cisco UCS Manager GUI は管理者権限を持つユーザがログインしたときに通知します。
Cisco UCS Manager は、すべての保留アクティビティについて次のような情報を表示します。
![]() (注) |
特定の保留アクティビティをサーバに適用するメンテナンス時間帯を指定することはできません。 メンテナンス時間帯は、保留アクティビティの数およびサービス プロファイルに割り当てられているメンテナンス ポリシーに応じて変化します。 ただし、保留アクティビティがユーザの確認応答またはメンテナンス時間帯のいずれを待っているかにかかわらず、管理者権限を持つユーザは、手動で保留アクティビティを開始して、ただちにサーバをリブートできます。 |
保留中の変更をキャンセルする場合、Cisco UCS Manager はサーバを再起動せずに変更のロール バックを試みます。 ただし、複雑な変更を行った場合、Cisco UCS Manager は変更のロール バックのためサーバを 2 回リブートしなければならない場合があります。 たとえば、vNIC を削除すると、Cisco UCS Manager はサービス プロファイルに含まれているメンテナンス ポリシーに従ってサーバをリブートします。 サービス プロファイルで元の vNIC を復元しても、この再起動および変更はキャンセルできません。 代わりに、Cisco UCS Manager は 2 回目の展開とサーバのリブートをスケジュールします。
Cisco UCS Manager がサービス プロファイルの関連付けを開始した後、スケジューラとメンテナンス ポリシーは手順を制御する方法を持っていません。 サービス プロファイルの関連付けが割り当てられたメンテナンス時間に完了しない場合、プロセスが完了するまで続行されます。 たとえば、いくつかの段階の再試行やその他の問題のため、関連付けが完了しなかった場合に発生することがあります。
スケジュールされた展開は、独立して並行実行されます。 展開が発生する順序は指定できません。 また、あるサービス プロファイルの変更を他のものの完了を条件として実行することもできません。
Cisco UCS Manager は、サーバ プロファイルに加えられたすべての変更をスケジュールされたメンテナンス時間に適用します。 サービス プロファイルに複数の変更を加えた後にそれらの変更を別々のメンテナンス時間に振り分けることはできません。 サービス プロファイルの変更を展開するとき、Cisco UCS Manager はデータベース内の最新の設定に一致するようにサービス プロファイルを更新します。
The following example creates a scheduler called maintenancesched and commits the transaction:
UCS-A# scope system UCS-A /system # create scheduler maintenancesched UCS-A /system/scheduler* # commit-buffer UCS-A /system/scheduler #
Create a one time occurrence or recurring occurrence for the schedule.
UCS-A# scope system UCS-A /system # scope scheduler maintsched UCS-A /system/scheduler # create occurrence one-time onetimemaint UCS-A /system/scheduler/one-time* # set date apr 1 2011 11 00 UCS-A /system/scheduler/one-time* # set concur-tasks 5 UCS-A /system/scheduler/one-time* # commit-buffer UCS-A /system/scheduler/one-time #
UCS-A# scope system UCS-A /system # scope scheduler maintsched UCS-A /system/scheduler # create occurrence recurring recurringmaint UCS-A /system/scheduler/recurring* # set day even-day UCS-A /system/scheduler/recurring* # set hour 11 UCS-A /system/scheduler/recurring* # set minute 5 UCS-A /system/scheduler/recurring* # set concur-tasks 5 UCS-A /system/scheduler/recurring* # commit-buffer UCS-A /system/scheduler/recurring #
これがスケジュールにおける唯一の実行である場合には、そのスケジュールは実行なしで再設定されます。 スケジュールがメンテナンス ポリシーに含まれており、そのポリシーがサービス プロファイルに割り当てられている場合、サービス プロファイルに関連付けられているサーバに関連する保留中のアクティビティは展開できません。 保留中のアクティビティを展開するには、1 回限りの実行か繰り返し実行をスケジュールに追加する必要があります。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 | UCS-A# scope system | システム モードを開始します。 |
| ステップ 2 | UCS-A /system # scope scheduler sched-name | スケジューラ システム モードを開始します。 |
| ステップ 3 | UCS-A /system/scheduler # delete occurrence one-time occurrence-name | 指定されたワンタイム オカレンスを削除します。 |
| ステップ 4 | UCS-A /system/scheduler # commit-buffer | トランザクションをシステムの設定にコミットします。 |
UCS-A# scope system UCS-A /system # scope scheduler maintsched UCS-A /system/scheduler # delete occurrence one-time onetimemaint UCS-A /system/scheduler* # commit-buffer UCS-A /system/scheduler #
これがスケジュールにおける唯一の実行である場合には、そのスケジュールは実行なしで再設定されます。 スケジュールがメンテナンス ポリシーに含まれており、そのポリシーがサービス プロファイルに割り当てられている場合、サービス プロファイルに関連付けられているサーバに関連する保留中のアクティビティは展開できません。 保留中のアクティビティを展開するには、1 回限りの実行か繰り返し実行をスケジュールに追加する必要があります。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 | UCS-A# scope system | システム モードを開始します。 |
| ステップ 2 | UCS-A /system # scope scheduler sched-name | スケジューラ システム モードを開始します。 |
| ステップ 3 | UCS-A /system/scheduler # delete occurrence recurring occurrence-name | 指定された繰り返しオカレンスを削除します。 |
| ステップ 4 | UCS-A /system/scheduler # commit-buffer | トランザクションをシステムの設定にコミットします。 |
UCS-A# scope system UCS-A /system # scope scheduler maintsched UCS-A /system/scheduler # delete occurrence recurring onetimemaint UCS-A /system/scheduler* # commit-buffer UCS-A /system/scheduler #
このスケジュールがメンテナンス ポリシーに含まれている場合、ポリシーはスケジュールなしで再設定されます。 そのポリシーがサービス プロファイルに割り当てられている場合、サービス プロファイルに関連付けられているサーバに関連する保留中のアクティビティは展開できません。 保留中のアクティビティを展開するには、スケジュールをメンテナンス ポリシーに追加する必要があります。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 | UCS-A# scope system | システム モードを開始します。 |
| ステップ 2 | UCS-A /system # delete scheduler sched-name | スケジューラを削除し、スケジューラ モードを開始します。 |
| ステップ 3 | UCS-A /system # commit-buffer | トランザクションをシステムの設定にコミットします。 |
次の例は、maintenancesched というスケジューラを削除し、トランザクションをコミットします。
UCS-A# scope system UCS-A /system # delete scheduler maintenancesched UCS-A /system* # commit-buffer UCS-A /system #
このメンテナンス ポリシーを遅延展開のために設定する場合は、スケジュールを作成します。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 | UCS-A# scope org org-name | 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。 |
| ステップ 2 | UCS-A /org # create maint-policy policy-name | 指定されたメンテナンス ポリシーを作成し、メンテナンス ポリシー モードを開始します。 |
| ステップ 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 # create maint-policy maintenance UCS-A /org/maint-policy* # set reboot-policy immediate UCS-A /org/maint-policy* # commit-buffer UCS-A /org/maint-policy #
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 | UCS-A# scope org org-name | 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。 |
| ステップ 2 | UCS-A /org # delete maint-policy policy-name | 指定されたメンテナンス ポリシーを削除します。 |
| ステップ 3 | UCS-A /org # commit-buffer | トランザクションをシステムの設定にコミットします。 |
UCS-A# scope org / UCS-A /org # delete maint-policy maintenance UCS-A /org/maint-policy* # commit-buffer UCS-A /org/maint-policy #
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 | UCS-A# scope org org-name | 組織モードを開始します。 ルート組織モードを開始するには、org-name に / と入力します。 |
| ステップ 2 | UCS-A /org # scope service-profile profile-name | 指定したサービスで組織サービス プロファイル モードを開始します。 |
| ステップ 3 | UCS-A /org/service-profile # show pending-changes [detail | expand] | 保留中の変更に関する詳細を表示します。 |
次に、accounting というサービス プロファイルの保留中の変更を表示する例を示します。
UCS-A# scope org /
UCS-A /org # scope service-profile accounting
UCS-A /org/service-profile # show pending-changes detail
Pending Changes:
Scheduler:
Changed by: admin
Acked by:
Mod. date: 2010-09-20T20:36:09.254
State: Untriggered
Admin State: Untriggered
Pend. Changes: 0
Pend. Disr.: 0
UCS-A /org/service-profile #
保留中のアクティビティを確認した後、Cisco UCS Manager が影響のあるサーバをリブートすることは禁止できません。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 | UCS-A# scope org org-name | 組織モードを開始します。 ルート組織モードを開始するには、org-name に / と入力します。 |
| ステップ 2 | UCS-A /org # scope service-profile profile-name | 指定したサービスで組織サービス プロファイル モードを開始します。 |
| ステップ 3 | UCS-A /org/service-profile # apply pending-changes immediate | 保留中の変更をただちに適用します。 Cisco UCS Manager 保留中のアクティビティの影響を受けるサーバがただちにリブートします。 |
次に、accounting というサービス プロファイルの保留中の変更を適用する例を示します。
UCS-A# scope org / UCS-A /org # scope service-profile accounting UCS-A /org/service-profile # apply pending-changes immediate UCS-A /org/service-profile #
保留中のアクティビティを確認した後、Cisco UCS Manager が影響のあるサーバをリブートすることは禁止できません。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 | UCS-A# scope org org-name | 組織モードを開始します。 ルート組織モードを開始するには、org-name に / と入力します。 |
| ステップ 2 | UCS-A /org # scope service-profile profile-name | 指定したサービスで組織サービス プロファイル モードを開始します。 |
| ステップ 3 | UCS-A /org/service-profile # apply pending-changes immediate | 保留中の変更をただちに適用します。 Cisco UCS Manager 保留中のアクティビティの影響を受けるサーバがただちにリブートします。 |
次に、accounting というサービス プロファイルの保留中の変更を適用する例を示します。
UCS-A# scope org / UCS-A /org # scope service-profile accounting UCS-A /org/service-profile # apply pending-changes immediate UCS-A /org/service-profile #
目次
- サービス プロファイル更新の遅延展開
- サービス プロファイルの遅延展開
- 遅延展開スケジュール
- メンテナンス ポリシー
- 保留アクティビティ
- 遅延展開に関するガイドラインおよび制限事項
- スケジュールの設定
- Creating a Schedule
- スケジュールへのワンタイム オカレンスの作成
- スケジュールへの繰り返しオカレンスの作成
- スケジュールからのワンタイム オカレンスの削除
- スケジュールからの繰り返しオカレンスの削除
- スケジュールの削除
- メンテナンス ポリシーの設定
- メンテナンス ポリシーの作成
- メンテナンス ポリシーの削除
- 保留アクティビティの管理
- 保留アクティビティの表示
- ユーザの確認応答待ちサービス プロファイル変更の展開
- スケジュールされたサービス プロファイル変更の即時展開
この章は、次の項で構成されています。
サービス プロファイルの遅延展開
サービス プロファイルの変更の一部、またはサービス プロファイル テンプレートの更新は、中断をともなうことや、サーバのリブートが必要になることがあります。 ただし、これらの中断をともなう設定変更をいつ実行するかを、遅延展開によって制御できます。 たとえば、サービス プロファイルの変更をすぐに展開するか、指定されたメンテナンス時間帯に展開するかを選択できます。 また、サービス プロファイルの展開にユーザの明示的な確認応答が必要かどうかを選択できます。
遅延展開は、サーバとサービス プロファイルとの関連付けによって発生するすべての設定変更に使用できます。 これらの設定変更は、サービス プロファイルへの変更、サービス プロファイルに含まれるポリシーへの変更、更新サービス プロファイル テンプレートへの変更によってプロンプト表示される場合があります。 たとえば、サーバ BIOS、RAID コントローラ、ホスト HBA、ネットワーク アダプタなどのホスト ファームウェア パッケージや管理ファームウェア パッケージによって、ファームウェアのアップグレードおよびアクティブ化を延期することもできます。 ただし、Cisco UCS Manager、ファブリック インターコネクト、I/O モジュールなど、ファームウェア パッケージを使用しないコンポーネントのファームウェア イメージの直接展開を遅延させることはできません。
遅延展開は、サーバのリブートを必要とする次のアクションに使用できません。
サーバのサービス プロファイルの最初の関連付け
サービス プロファイルと別のサーバを関連付けない、サービス プロファイルのサーバからの関連付けの最終解除
サーバの解放
サーバの再認識
サーバのリセット
サービス プロファイル変更の展開を遅延させる場合、1 つ以上のメンテナンス ポリシーを設定し、各サービス プロファイルにメンテナンス ポリシーを設定する必要があります。 展開が発生する時間帯を指定する場合、1 つ以上の繰り返しオカレンスまたはワンタイム オカレンスを持つスケジュールを少なくとも 1 つ作成し、そのスケジュールをメンテナンス ポリシーに含める必要があります。
遅延展開スケジュール
スケジュールには、一連のオカレンスが含まれます。 これらのオカレンスは、1 回だけ発生させるか、または毎週指定した日時に繰り返し発生させることができます。 オカレンスの時間長や実行されるタスクの最大数といった、オカレンスで定義されるオプションにより、サービス プロファイルの変更が展開されるかどうかが決まります。 たとえば、最大時間長またはタスク数に達したため特定のメンテナンス時間帯に変更を展開できない場合、この展開は次のメンテナンス時間に持ち越されます。
各スケジュールは、Cisco UCS ドメインが 1 つまたは複数のメンテナンス時間に入っているかどうか、定期的に確認します。 入っている場合、スケジュールはメンテナンス ポリシーで指定された制限に対し適切な展開を実行します。
スケジュールには、スケジュールに関連付けられたメンテナンス時間を決定する 1 つ以上のオカレンスが含まれています。 オカレンスは次のいずれかになります。
- ワンタイム オカレンス
ワンタイム オカレンスは、単一のメンテナンス時間を定義します。 これらの時間帯は、その時間帯の最大時間長まで、または時間帯の中で実行可能なタスクの最大数に達するまで継続されます。
- 繰り返しオカレンス
繰り返しオカレンスは、一連のメンテナンス時間を定義します。 これらの時間帯は、タスクの最大数に達するまで、またはオカレンスに指定された日の終わりに達するまで継続します。
メンテナンス ポリシー
メンテナンス ポリシーは、サーバに関連付けられたサービス プロファイル、または 1 つ以上のサービス プロファイルに関連付けられた更新中のサービス プロファイルに対して、サーバのリブートが必要になるような変更が加えられた場合の Cisco UCS Manager の対処方法を定義します。
メンテナンス ポリシーは、Cisco UCS Manager でのサービス プロファイルの変更の展開方法を指定します。 展開は、次のいずれかの方法で実行されます。
スケジュール済みのメンテナンス ウィンドウ中に変更を展開するように設定されているメンテナンス ポリシーでは、ポリシーに有効なスケジュールが含まれていることが必要です。 この場合、最初に使用可能なメンテナンス ウィンドウ中に変更が展開されます。
(注)
メンテナンス ポリシーでは、関連付けられたサービス プロファイルに設定変更が加えられた場合に、サーバの即時リブートは回避できますが、 次のアクションの即時実行は回避されません。
関連付けられたサービス プロファイルのシステムからの削除
サーバ プロファイルのサーバからの関連付けの解除
サービス ポリシーを使用しないファームウェア アップグレードの直接インストール
サーバのリセット
保留アクティビティ
Cisco UCS ドメインで遅延展開を設定すると、Cisco UCS Manager を使用して保留中のアクティビティすべてを表示することができます。 ユーザの確認応答を待っているアクティビティと、スケジュールされたアクティビティを表示できます。
Cisco UCS ドメイン ドメインに保留中のアクティビティがある場合、Cisco UCS Manager GUI は管理者権限を持つユーザがログインしたときに通知します。
Cisco UCS Manager は、すべての保留アクティビティについて次のような情報を表示します。
(注)
特定の保留アクティビティをサーバに適用するメンテナンス時間帯を指定することはできません。 メンテナンス時間帯は、保留アクティビティの数およびサービス プロファイルに割り当てられているメンテナンス ポリシーに応じて変化します。 ただし、保留アクティビティがユーザの確認応答またはメンテナンス時間帯のいずれを待っているかにかかわらず、管理者権限を持つユーザは、手動で保留アクティビティを開始して、ただちにサーバをリブートできます。
遅延展開に関するガイドラインおよび制限事項
サービス プロファイルまたはサービス プロファイル テンプレートへのすべての変更を元に戻すことはできない
保留中の変更をキャンセルする場合、Cisco UCS Manager はサーバを再起動せずに変更のロール バックを試みます。 ただし、複雑な変更を行った場合、Cisco UCS Manager は変更のロール バックのためサーバを 2 回リブートしなければならない場合があります。 たとえば、vNIC を削除すると、Cisco UCS Manager はサービス プロファイルに含まれているメンテナンス ポリシーに従ってサーバをリブートします。 サービス プロファイルで元の vNIC を復元しても、この再起動および変更はキャンセルできません。 代わりに、Cisco UCS Manager は 2 回目の展開とサーバのリブートをスケジュールします。
サービス プロファイルの関連付けはメンテナンス時間の境界を超えてもよい
Cisco UCS Manager がサービス プロファイルの関連付けを開始した後、スケジューラとメンテナンス ポリシーは手順を制御する方法を持っていません。 サービス プロファイルの関連付けが割り当てられたメンテナンス時間に完了しない場合、プロセスが完了するまで続行されます。 たとえば、いくつかの段階の再試行やその他の問題のため、関連付けが完了しなかった場合に発生することがあります。
Creating a Schedule
手順
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope system Enters system mode.
ステップ 2 UCS-A /system # create scheduler sched-name Creates a scheduler and enters scheduler mode.
ステップ 3 UCS-A /system/scheduler # commit-buffer Commits the transaction to the system configuration.
次の作業The following example creates a scheduler called maintenancesched and commits the transaction:
UCS-A# scope system UCS-A /system # create scheduler maintenancesched UCS-A /system/scheduler* # commit-buffer UCS-A /system/scheduler #
Create a one time occurrence or recurring occurrence for the schedule.
スケジュールへのワンタイム オカレンスの作成
手順
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope system システム モードを開始します。
ステップ 2 UCS-A /system # scope schedule sched-name スケジューラ システム モードを開始します。
ステップ 3 UCS-A /system/scheduler # create occurrence one-time occurrence-name ワンタイム オカレンスを作成します。
ステップ 4 UCS-A /system/scheduler/one-time # set date month day-of-month year hour minute このオカレンスを実行する日時を設定します。
ステップ 5 UCS-A /system/scheduler/one-time # set concur-tasks {unlimited | max-num-concur-tasks (任意) このオカレンスの間に同時実行可能なタスクの最大数を設定します。
タスクの最大数に達すると、スケジューラは新しいタスクをスケジュールする前に、[minimum interval] プロパティで設定された時間だけ待機します。
ステップ 6 UCS-A /system/scheduler/one-time # set max-duration {none | num-of-days num-of-hours num-of-minutes num-of-seconds} (任意) このスケジュール オカレンスが実行可能な時間の最大長を設定します。 Cisco UCS は、指定された時間内にできるだけ多くのスケジュール タスクを完了します。
ステップ 7 UCS-A /system/scheduler/one-time # set min-interval {none | num-of-days num-of-hours num-of-minutes num-of-seconds} (任意) システムが新しいタスクを開始するまで待機する時間の最小長を設定します。
ステップ 8 UCS-A /system/scheduler/one-time # set proc-cap {unlimited | max-num-of-tasks} (任意) このオカレンスの間に実行可能な、スケジュール設定されたタスクの最大数を設定します。
ステップ 9 UCS-A /system/scheduler/one-time # commit-buffer トランザクションをシステムの設定にコミットします。
次の例は、onetimemaint というワンタイム オカレンスを maintsched というスケジューラに作成し、同時実行タスクの最大数を 5 に設定し、開始日時を 2011 年 4 月 1 日 11:00 に設定し、トランザクションをコミットします。UCS-A# scope system UCS-A /system # scope scheduler maintsched UCS-A /system/scheduler # create occurrence one-time onetimemaint UCS-A /system/scheduler/one-time* # set date apr 1 2011 11 00 UCS-A /system/scheduler/one-time* # set concur-tasks 5 UCS-A /system/scheduler/one-time* # commit-buffer UCS-A /system/scheduler/one-time #スケジュールへの繰り返しオカレンスの作成
手順
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope system システム モードを開始します。
ステップ 2 UCS-A /system # scope schedule sched-name スケジューラ システム モードを開始します。
ステップ 3 UCS-A /system/scheduler # create occurrence recurring occurrence-name 繰り返しオカレンスを作成します。
ステップ 4 UCS-A /system/scheduler/recurring # set day {even-day | every-day | friday | monday | never | odd-day | saturday | sunday | thursday | tuesday | wednesday} (任意) Cisco UCS でこのスケジュールのオカレンスを実行する曜日を選択します。
デフォルトでは、このプロパティは never に設定されています。
ステップ 5 UCS-A /system/scheduler/recurring # set hour hour (任意) このオカレンスが開始する時間(時)を指定します。
(注) Cisco UCS は、最長期間に到達していない場合でも、すべての繰り返しオカレンスを開始されたその日のうちに終了します。 たとえば、開始時刻を午後 11 時に指定し、 最長期間を 3 時間に設定した場合、Cisco UCS はオカレンスを 11 時に開始しますが、 午後 11:59 に終了させます。 これはわずか 59 分後になります。
ステップ 6 UCS-A /system/scheduler/recurring # set minute minute (任意) このオカレンスが開始する時間(分)を指定します。
ステップ 7 UCS-A /system/scheduler/recurring # set concur-tasks {unlimited | max-num-concur-tasks (任意) このオカレンスの間に同時実行可能なタスクの最大数を設定します。
タスクの最大数に達すると、スケジューラは新しいタスクをスケジュールする前に、[minimum interval] プロパティで設定された時間だけ待機します。
ステップ 8 UCS-A /system/scheduler/recurring # set max-duration {none | num-of-hours num-of-minutes num-of-seconds} (任意) このスケジュール オカレンスが実行可能な時間の最大長を設定します。 Cisco UCS は、指定された時間内にできるだけ多くのスケジュール タスクを完了します。
ステップ 9 UCS-A /system/scheduler/recurring # set min-interval {none | num-of-days num-of-hours num-of-minutes num-of-seconds} (任意) システムが新しいタスクを開始するまで待機する時間の最小長を設定します。
ステップ 10 UCS-A /system/scheduler/recurring # set proc-cap {unlimited | max-num-of-tasks} (任意) このオカレンスの間に実行可能な、スケジュール設定されたタスクの最大数を設定します。
ステップ 11 UCS-A /system/scheduler/recurring # commit-buffer トランザクションをシステムの設定にコミットします。
次の例は、maintsched というスケジューラに recurringmaint という繰り返しオカレンスを作成し、同時実行タスクの最大数を 5 に設定し、このオカレンスの実行日を偶数日に設定し、11:05 から開始するように時間を設定してトランザクションをコミットします。UCS-A# scope system UCS-A /system # scope scheduler maintsched UCS-A /system/scheduler # create occurrence recurring recurringmaint UCS-A /system/scheduler/recurring* # set day even-day UCS-A /system/scheduler/recurring* # set hour 11 UCS-A /system/scheduler/recurring* # set minute 5 UCS-A /system/scheduler/recurring* # set concur-tasks 5 UCS-A /system/scheduler/recurring* # commit-buffer UCS-A /system/scheduler/recurring #スケジュールからのワンタイム オカレンスの削除
手順これがスケジュールにおける唯一の実行である場合には、そのスケジュールは実行なしで再設定されます。 スケジュールがメンテナンス ポリシーに含まれており、そのポリシーがサービス プロファイルに割り当てられている場合、サービス プロファイルに関連付けられているサーバに関連する保留中のアクティビティは展開できません。 保留中のアクティビティを展開するには、1 回限りの実行か繰り返し実行をスケジュールに追加する必要があります。
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope system システム モードを開始します。
ステップ 2 UCS-A /system # scope scheduler sched-name スケジューラ システム モードを開始します。
ステップ 3 UCS-A /system/scheduler # delete occurrence one-time occurrence-name 指定されたワンタイム オカレンスを削除します。
ステップ 4 UCS-A /system/scheduler # commit-buffer トランザクションをシステムの設定にコミットします。
スケジュールからの繰り返しオカレンスの削除
手順これがスケジュールにおける唯一の実行である場合には、そのスケジュールは実行なしで再設定されます。 スケジュールがメンテナンス ポリシーに含まれており、そのポリシーがサービス プロファイルに割り当てられている場合、サービス プロファイルに関連付けられているサーバに関連する保留中のアクティビティは展開できません。 保留中のアクティビティを展開するには、1 回限りの実行か繰り返し実行をスケジュールに追加する必要があります。
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope system システム モードを開始します。
ステップ 2 UCS-A /system # scope scheduler sched-name スケジューラ システム モードを開始します。
ステップ 3 UCS-A /system/scheduler # delete occurrence recurring occurrence-name 指定された繰り返しオカレンスを削除します。
ステップ 4 UCS-A /system/scheduler # commit-buffer トランザクションをシステムの設定にコミットします。
スケジュールの削除
手順このスケジュールがメンテナンス ポリシーに含まれている場合、ポリシーはスケジュールなしで再設定されます。 そのポリシーがサービス プロファイルに割り当てられている場合、サービス プロファイルに関連付けられているサーバに関連する保留中のアクティビティは展開できません。 保留中のアクティビティを展開するには、スケジュールをメンテナンス ポリシーに追加する必要があります。
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope system システム モードを開始します。
ステップ 2 UCS-A /system # delete scheduler sched-name スケジューラを削除し、スケジューラ モードを開始します。
ステップ 3 UCS-A /system # commit-buffer トランザクションをシステムの設定にコミットします。
メンテナンス ポリシーの作成
手順
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope org org-name 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。
ステップ 2 UCS-A /org # create maint-policy policy-name 指定されたメンテナンス ポリシーを作成し、メンテナンス ポリシー モードを開始します。
ステップ 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 トランザクションをシステムの設定にコミットします。
メンテナンス ポリシーの削除
保留アクティビティの表示
手順
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope org org-name 組織モードを開始します。
ルート組織モードを開始するには、org-name に / と入力します。
ステップ 2 UCS-A /org # scope service-profile profile-name 指定したサービスで組織サービス プロファイル モードを開始します。
ステップ 3 UCS-A /org/service-profile # show pending-changes [detail | expand] 保留中の変更に関する詳細を表示します。
次に、accounting というサービス プロファイルの保留中の変更を表示する例を示します。
UCS-A# scope org / UCS-A /org # scope service-profile accounting UCS-A /org/service-profile # show pending-changes detail Pending Changes: Scheduler: Changed by: admin Acked by: Mod. date: 2010-09-20T20:36:09.254 State: Untriggered Admin State: Untriggered Pend. Changes: 0 Pend. Disr.: 0 UCS-A /org/service-profile #ユーザの確認応答待ちサービス プロファイル変更の展開
Cisco UCS Manager CLI ユーザの確認応答待ちの、複数のサービス プロファイルの保留中のすべての変更を展開することはできません。 複数のサービス プロファイルの保留中のすべての変更を同時に展開するには、 Cisco UCS Manager GUIを使用します。手順重要:保留中のアクティビティを確認した後、Cisco UCS Manager が影響のあるサーバをリブートすることは禁止できません。
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope org org-name 組織モードを開始します。
ルート組織モードを開始するには、org-name に / と入力します。
ステップ 2 UCS-A /org # scope service-profile profile-name 指定したサービスで組織サービス プロファイル モードを開始します。
ステップ 3 UCS-A /org/service-profile # apply pending-changes immediate 保留中の変更をただちに適用します。
Cisco UCS Manager 保留中のアクティビティの影響を受けるサーバがただちにリブートします。
スケジュールされたサービス プロファイル変更の即時展開
Cisco UCS Manager CLI 複数のサービス プロファイルの、スケジュールされているすべての変更を同時に展開することはできません。 複数のサービス プロファイルの、スケジュールされているすべての変更を同時に展開するには、 Cisco UCS Manager GUIを使用します。手順重要:保留中のアクティビティを確認した後、Cisco UCS Manager が影響のあるサーバをリブートすることは禁止できません。
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope org org-name 組織モードを開始します。
ルート組織モードを開始するには、org-name に / と入力します。
ステップ 2 UCS-A /org # scope service-profile profile-name 指定したサービスで組織サービス プロファイル モードを開始します。
ステップ 3 UCS-A /org/service-profile # apply pending-changes immediate 保留中の変更をただちに適用します。
Cisco UCS Manager 保留中のアクティビティの影響を受けるサーバがただちにリブートします。