この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
次の表は、クラスタ内の Cisco Unified Communications Manager ノードの IP アドレスまたはホスト名を変更した後に実行するタスクを示しています。
導入環境に適用するこれらのタスクは、タスク リストに示されている順序で実行してください。システム ヘルス チェックまたは ITL 証明書の作成方法の詳細については、関連トピックを参照してください。
注意 | これらのタスクを実行する際、期待する結果が得られない場合は、その問題が解決されるまで次の手順へ進まないでください。 |
項目 |
タスク |
||
---|---|---|---|
システム ヘルス チェック |
|||
1 |
クラスタにあるすべてのサーバが正常に稼働し、利用可能であること、また、ServerDown 警告が発生していないことを確認します。
|
||
2 |
クラスタにあるすべての Cisco Unified Communications Manager ノードでデータベース レプリケーションのステータスを調べ、すべてのサーバがデータベースの変更内容を正常に複製していることを確認します。 |
||
3 |
CLI コマンド utils diagnose module validate_network を使用して、ネットワーク接続と、変更されたノードの DNS サーバ設定を確認します。 |
||
4 |
Cisco Unified レポート ツールで Unified CM Database Status レポートを生成します。そのレポートにエラーや警告が記録されていないか確認します。 |
||
5 |
Cisco Unified レポート ツールで Unified CM Cluster Overview レポートを生成します。そのレポートにエラーや警告が記録されていないか確認します。 |
||
セキュリティを有効にしたクラスタ タスク |
|||
6 |
セキュリティが有効になっているクラスタ(クラスタ セキュリティ モード 1 - 混合)の場合、CTL ファイルを更新し、クラスタ内のすべてのノードを再起動してから、システム ヘルス チェックと他の変更後タスクを実行します。 既存の CTL ファイルへの新しい TFTP サーバの追加など、CTL ファイルの更新と管理の方法の詳細については、『Cisco Unified Communications Manager Security Guide』を参照してください。 |
||
7 |
証明書信頼リスト(CTL)ファイルと USB eToken を使用してクラスタ セキュリティを有効にした場合、リリース 8.0 以降のノードの IP アドレスまたはホスト名を変更した際は、Initial Trust List(ITL; 初期信頼リスト)ファイルと ITL の証明書を再生成する必要があります。 クラスタ セキュリティの有効化に証明書信頼リスト(CTL)ファイルと USB eToken を使用していない場合は、このステップをスキップしてください。 |
||
変更後のタスク |
|||
8 |
手動で DRS バックアップを実行し、すべてのノードとアクティブなすべてのサービスが正しくバックアップされていることを確認します。 詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。
|
||
9 |
関連する IP フォンの URL パラメータをすべて更新します。 |
||
10 |
Cisco Unified Communications Manager Administration を使って、関連するすべての IP フォン サービスを更新します。 |
||
11 |
Unified RTMT カスタム警告と保存済みプロファイルを更新します。 |
||
12 |
Cisco Unified Communications Manager で動作する統合 DHCP サーバを使用している場合は、DHCP サーバを更新します。 |
||
13 |
Cisco Unity Connection、Cisco Unified MeetingPlace Express などの他の関連する Cisco Unified Communications コンポーネントの設定を確認し、必要に応じて変更します。
|
||
18 |
電話機の DNS IP アドレスの変更後、更新された情報を反映するため電話機をリセットします。電話機をリセットすると、電話機のキャッシュがクリアされます。 |
次の表に、クラスタ内にある IM and Presence サービス ノードの IP アドレス、ホスト名、ドメイン名、またはノード名を変更した後で実行するタスクを示します。
これらのタスクは、タスク リストに示されている順序どおりに実行してください。
注意 | これらのタスクを実行する際、期待する結果が得られない場合は、その問題が解決されるまで次の手順へ進まないでください。 |
項目 |
タスク |
||
---|---|---|---|
システム ヘルス チェック |
|||
1 |
ホスト名または IP アドレスに対する変更内容が、Cisco Unified Communications Manager サーバ上で更新されていることを確認します。 |
||
2 |
変更したノードのネットワーク接続と DNS サーバの設定を確認してください。
|
||
3 |
IP アドレス、ホスト名、またはその両方への変更がネットワークで完全に実装されていることを確認してください。 |
||
4 |
ホスト名を変更した場合は、ネットワークでホスト名の変更が確実に実装されていることを確認します。 |
||
5 |
データベース レプリケーションが正常に確立されたことを確認します。すべてのノードのスタータスが 2 で、[接続済み(Connected)] になっている必要があります。レプリケーションがセットアップされていない場合、データベース レプリケーションのトラブルシューティングに関するトピックを参照してください。 |
||
変更後のタスク |
|||
6 |
手順を実行する前に OpenAM SSO を無効にした場合、この時点で有効にできます。OpenAM SSO を有効にする方法の詳細については、『Deployment Guide for IM and Presence Service on Cisco Unified Communications Manager』を参照してください。 |
||
7 |
CUP、CUP-xmpp、Tomcat の証明書に新しいホスト名が含まれていることを確認します。 |
||
8 |
ノードの IP アドレスを変更した場合、Unified RTMT カスタム警告と保存済みプロファイルを更新します。 |
||
9 |
その他の関連する Cisco Unified Communications のコンポーネント(たとえば Cisco Unified Communications Manager の SIP トランクなど)に必要な設定変更を確認し、変更を行ってください。 |
||
10 |
CUP サービス グループの下にリストされているすべてのネットワーク サービスを開始します。所定の順序で CUP サービスのネットワーク サービスを開始する必要があります。
|
||
11 |
すべての機能サービスを開始します。機能サービスを開始する順序は重要ではありません。
|
||
12 |
変更前のセットアップ中に HA を無効にした場合は、ハイ アベイラビリティを再度有効にする前に Cisco Jabber セッションが再作成されたことを確認します。そうしないと、セッションが作成された Jabber クライアントは接続できなくなります。 すべてのクラスタ ノードで show perf query counter "Cisco Presence Engine" ActiveJsmSessions CLI コマンドを実行します。アクティブ セッションの数は、ハイ アベイラビリティを無効にした際に記録したユーザ数と一致するはずです。セッションの開始に 30 分以上かかると、システムの問題が大きくなる可能性があります。 Jabber セッションが作成されたことを確認できたら、再度すべてのプレゼンス冗長グループでハイ アベイラビリティを有効にします。 |
||
13 |
IM and Presence サービスが変更後に正しく機能していることを確認します。 |
||
18 |
ノードの IP アドレスまたはホスト名の変更後、ディザスタ リカバリ システムのバックアップを手動で実行します。 |
変更後タスクすべてを実行し、導入環境に変更が適切に実装されていることを確認してください。
これらのタスクは、タスク リストに示されている順序どおりに実行してください。
注意 | これらのタスクを実行しても期待する結果が得られない場合は、問題が解決されるまで続行しないでください。 |
Cisco Unified Communications Manager ノードのセキュリティを有効にしたクラスタ タスク
Cisco Unified Communications Manager リリース 8.0 リリース以降のクラスタでサーバの IP アドレスまたはホスト名を変更すると、ITL の初期信頼リスト(ITL)ファイルと証明書が再生成されます。再生されたファイルは、電話機に保存されたファイルと一致しません。
(注) | 証明書信頼リスト(CTL)ファイルと USB eToken を使用してクラスタ セキュリティを有効にする場合は、eToken によって信頼が保持され、eToken は変更されないため、次の手順を実行する必要はありません。 クラスタ セキュリティが有効になっていない場合は、シングルサーバ クラスタまたはマルチサーバ クラスタでこの手順を実行して電話をリセットします。 |
Cisco Unified Communications Manager リリース 8.0 以降のシングルサーバ クラスタでサーバの IP アドレスまたはホスト名を変更する際に、ITL ファイルを使用する場合、以下の手順を実行して電話機をリセットします。
サーバの IP アドレスまたはホスト名を変更する前に、ロールバックを有効にします。
ステップ 1 | 更新された ITL を処理できるようにすべての電話機が登録され、オンラインであることを確認します。この手順を実行するときに電話機がオンラインでない場合は、ITL を手動で削除する必要があります。 |
ステップ 2 | Prepare Cluster for Rollback to pre-8.0 エンタープライズ パラメータを True に設定します。すべての電話機は自動的にリセットされ、空の信頼検証サービス(TVS)と TFTP 証明書セクションを含む ITL ファイルがダウンロードされます。 |
ステップ 3 | 電話機で、 の順に選択し、ITL ファイルの TVS および TFTP 証明書セクションが空であることを確認します。 |
ステップ 4 | サーバの IP アドレスまたはホスト名を変更し、クラスタへの登録がロールバックされるように電話機を設定します。 |
ステップ 5 | すべての電話機がクラスタに正常に登録されたら、エンタープライズ パラメータ Prepare Cluster for Rollback to pre-8.0 を False に設定します。 |
CTL ファイルまたはトークンを使用する場合は、サーバの IP アドレスまたはホスト名を変更した後、または DNS ドメイン名を変更した後に、CTL クライアントを再実行します。
マルチサーバ クラスタでは、電話機が、再生成された ITL ファイルおよび証明書を確認するためのプライマリおよびセカンダリ TVS サーバを持つ必要があります。電話機がプライマリ TVS サーバに(最近の設定変更により)接続できない場合は、セカンダリ サーバにフォール バックされます。TVS サーバは、電話機に割り当てられた CM グループによって識別されます。
マルチサーバ クラスタでは、一度に 1 つのサーバだけで IP アドレスまたはホスト名を変更するようにしてください。CTL ファイルまたはトークンを使用する場合は、サーバの IP アドレスまたはホスト名を変更した後、または DNS ドメイン名を変更した後に、CTL クライアントまたは CLI コマンド set utils ctl を再実行します。
変更後タスクすべてを実行し、導入環境に変更が適切に実装されていることを確認してください。
注意 | これらのタスクを実行しても期待する結果が得られない場合は、問題が解決されるまで続行しないでください。 |
該当するすべての検証システム ヘルス チェックを実行し、導入に対して加えられた変更を確認します。
ステップ 1 | OpenAM シングル サインオン(SSO)を無効にした場合、ここで有効にできます。OpenAM SSO の詳細については、『Deployment Guide for IM and Presence Service on Cisco Unified Communications Manager』を参照してください。 | ||
ステップ 2 | ホスト名を変更した場合、cup、cup-xmpp、および Tomcat の証明書に新しいホスト名が含まれていることを確認する必要があります。 | ||
ステップ 3 | ノードの IP アドレスを変更したら、Cisco Unified Real-Time Monitoring Tool(RTMT)のカスタム アラートと保存済みプロファイルを更新してください。 | ||
ステップ 4 | その他の関連する Cisco Unified Communications のコンポーネント(たとえば Cisco Unified Communications Manager の SIP トランクなど)に必要な設定変更を確認し、変更を行ってください。 | ||
ステップ 5 | Cisco Unified Serviceability を使用して CUP サービス グループの下にリストされるすべてのネットワーク サービスを開始するには、
を選択します。
| ||
ステップ 6 | Cisco Unified Serviceability を使用してすべての機能サービスを開始するには、
を選択します。機能サービスを開始する順序は重要ではありません。
| ||
ステップ 7 | ハイ アベイラビリティを再度有効にする前に Cisco Jabber セッションが再作成されたことを確認します。そうしないと、セッションが作成された Jabber クライアントは接続できなくなります。 すべてのクラスタ ノードで show perf query counter "Cisco Presence Engine" ActiveJsmSessions CLI コマンドを実行します。アクティブ セッションの数は、ハイ アベイラビリティを無効にした際に記録したユーザ数と一致するはずです。セッションの開始に 30 分以上かかると、システムの問題が大きくなる可能性があります。 | ||
ステップ 8 | 変更前のセットアップ中にハイ アベイラビリティ(HA)を無効にした場合、すべてのプレゼンス冗長グループの HA を有効にします。 | ||
ステップ 9 | IM and Presence サービスが変更後に正しく機能していることを確認します。 | ||
ステップ 10 | ノードの IP アドレスまたはホスト名を変更した後は、手動でディザスタ リカバリ システム バックアップを実行する必要があります。これは、DRS ファイルでノードを復元するには、DRS ファイルとノードで IP アドレスとホスト名が一致している必要があるからです。変更後の DRS ファイルには、新しい IP アドレスや新しいホスト名が記録されています。 詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |