Cisco Unified Presence Release 8.6(5) の IP アドレス、ホスト名、ドメイン名、ノード名の変更
サーバのノード名の変更
サーバのノード名の変更
発行日;2013/07/23 | 英語版ドキュメント(2013/04/30 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 833KB) | フィードバック

目次

サーバのノード名の変更

手順の概要

手順のワークフロー

のノード名の更新

データベース レプリケーションの確認

Cisco Unified Communications Manager での更新の確認

手順の概要

この手順で、Cisco Unified Presence サーバまたはサーバのグループに関連付けたノード名を変更できます。この手順は、Cisco Unified Presence 管理 GUI の [クラスタトポロジ(Cluster Topology)] ウィンドウに表示されるノード名を変更します。


注意 この手順は、ネットワーク レベルの変更が必要ない場合に、Cisco Unified Presence サーバのノード名を変更する場合にだけ使用されます。ネットワーク IP アドレス、ホスト名、またはドメイン名への変更が必要な場合は、このマニュアルの該当する手順を実行します。


注意 Cisco Unified Presence クラスタにあるどのサーバでノード名を変更しても、サーバが再起動することになるので、プレゼンス サービスと他のシステム機能が中断します。システムにこのような影響があることから、このノード名変更手順は、スケジュールしたメンテナンス時間の中で実行する必要があります。

この手順は、次のノード名変更のシナリオをサポートしています。

IP アドレスからホスト名へ

IP アドレスから完全修飾ドメイン名(FQDN)へ

ホスト名から IP アドレスへ

ホスト名から FQDN へ

FQDN からホスト名へ

FQDN から IP アドレスへ


) ノード名の推奨事項の詳細については、『Deployment Guide for Cisco Unified Presence』を参照してください。


手順のワークフロー

次の表では、Cisco Unified Presence サーバまたはサーバのグループに関連付けたノード名を変更する手順を説明しています。この手順の詳しい説明では、変更を実行するステップの正確な順序を指定しています。

複数のクラスタにわたってこの手順を実行する場合は、順番に一度に 1 つのクラスタで変更を完了する必要があります。

表 7-1 ノード名を変更するためのワークフロー

手順
タスク

1

更新するすべてのノードで 「変更前のタスク」 を実行します。

この手順には、変更を行う前にシャット ダウンする必要があるサービスのリストを含む、複数の前提条件となるステップが含まれます。

これらのステップの一部は、パブリッシャ ノードにのみ適用されるため、サブスクライバ ノードに対して手順を実行するときは、そのステップをとばすことができます。

2

Cisco Unified Presence 管理 GUI から Cisco Unified Presence のノード名の更新を実行します。

3

管理 CLI で データベース レプリケーションの確認を実行します。

ノード名の更新が完了した後、データベースの複製を確認します。

4

Cisco Unified Communications Manager での更新の確認

更新されたサーバに対するアプリケーション サーバ エントリが Cisco Unified Communications Manager 管理 GUI の新しいノード名を反映していることを確認します。

5

更新したノードの 「変更後のタスク」 リストを実行します。

ノードが再び稼働状態になっていることを確認する一連の手順を実行します。

Cisco Unified Presence のノード名の更新

クラスタにある複数のサーバを変更する場合は、それらのサーバごとに次の手順を順番に実行する必要があります。

パブリッシャ ノードを変更する場合は、この手順をまずサブスクライバ ノードで実行し、その後にパブリッシャ ノードで同様にこの手順を実行する必要があります。

はじめる前に

変更前のタスクを実行します。「変更前のタスク」を参照してください。

手順


ステップ 1 Cisco Unified Presence の管理 GUI にサインインします。

ステップ 2 [システム(System)] > [クラスタ トポロジ(Cluster Topology)] を選択します。

ステップ 3 [クラスタ トポロジ(Cluster Topology)] ページの左側ペインで、ツリー ビューからサーバを選択します。

右側のペインに [ノードの設定(Node Configuration)] セクションと [完全修飾ドメイン名/IP アドレス(Fully Qualified Domain Name/IP Address)] フィールドが表示されます。

ステップ 4 [完全修飾ドメイン名/IP アドレス(Fully Qualified Domain Name/IP Address)] フィールドを新しいノード名で更新します。

ステップ 5 [保存(Save)] を選択します。

ステップ 6 クラスタ内の複数のサーバを変更する場合は、サーバごとにこの手順を繰り返して行います。


 

次の作業

「データベース レプリケーションの確認」

データベース レプリケーションの確認

新しいノード名がクラスタ全体に複製されたことを確認します。

はじめる前に

Cisco Unified Presence のノード名を更新します。「Cisco Unified Presence のノード名の更新」を参照してください。


) 次に示す検証メカニズムを使用して、新しいノード名がクラスタ全体で複製されたこと、およびそのデータベース レプリケーションが動作可能であることを確認します。


手順


ステップ 1 新しいノード名が正しく複製されたことを検証するには、クラスタ内のすべてのノードの管理 CLI から次のコマンドを実行します。

run sql name from ProcessNode
 

このコマンドの出力例を次に示します。

admin:run sql select name from ProcessNode
name
=====================
EnterpriseWideData
server1.example.com
server2.example.com
server3.example.com
server4.example.com
 

新しいノード名を指定する、クラスタの各ノードに対するエントリがあることを確認します。古いノード名が出力に表示されることはありません。次のように進めます。

a. 新しいノード名が欠落している、または古いノード名への参照が存在する場合は、ステップ 2 に進み、さらにデータベースのレプリケーションを検証します。

b. 出力が想定どおりである場合、検証が成功し、この手順の残りのステップを無視できます。

ステップ 2 ステップ 1 で新しいノード名が正しく表示されない場合、パブリッシャ ノードの管理 CLI から次のコマンドを実行して、クラスタ内のデータベース レプリケーションが正しい状態であることを確認します。

utils dbreplication runtimestate
 

次の例のような出力が表示されます。

admin: utils dbreplication runtimestate
 
DDB and Replication Services: ALL RUNNING
 
DB CLI Status: No other dbreplication CLI is running...
 
Cluster Replication State: BROADCAST SYNC Completed on 1 servers at: 2012-09-26-15-18
Last Sync Result: SYNC COMPLETED 257 tables sync'ed out of 257
Sync Errors: NO ERRORS
 
DB Version: ccm9_0_1_10000_9000
Number of replicated tables: 257
Repltimeout set to: 300s
 
Cluster Detailed View from gwydlvm020105 (2 Servers):
PING REPLICATION REPL. DBver& REPL. REPLICATION SETUP
SERVER-NAME IP ADDRESS (msec) RPC? STATUS QUEUE TABLES LOOP? (RTMT) & details
----------- -------------- ------ ---- ----------- ----- ------ ----- -----------------
server1 192.168.10.201 0.038 Yes Connected 0 match Yes (2) PUB Setup Completed
server2 192.168.10.202 0.248 Yes Connected 0 match Yes (2) Setup Completed
server3 192.168.10.203 0.248 Yes Connected 0 match Yes (2) Setup Completed
server4 192.168.10.204 0.248 Yes Connected 0 match Yes (2) Setup Completed
 

次のように進めます。

a. 出力で、各ノードの REPLICATION STATUS が Connected であることおよび REPLICATION SETUP 値が (2) Setup Complete であることを確認します。これは、クラスタ内のレプリケーション ネットワークが稼働していることを意味しているため、ステップ 3 の、クラスタ内のノード間の不一致の解決に進むことができます。

b. レプリケーションの状態およびセットアップ値が想定どおりでない場合、クラスタ内のレプリケーション ネットワークが切断されているため、ステップ 5 に進みレプリケーションを再確立します。

ステップ 3 パブリッシャ ノードの管理 CLI から次のコマンドを実行して、レプリリケーションの修復を試行します。

utils dbreplication repair all
 

このコマンドの出力例を次に示します。

admin:utils dbreplication repair all
-------------------- utils dbreplication repair --------------------
 
Replication Repair is now running in the background.
Use command 'utils dbreplication runtimestate' to check its progress
 
Output will be in file cm/trace/dbl/sdi/ReplicationRepair.2013_03_06_12_33_57.out
 
Please use "file view activelog cm/trace/dbl/sdi/ReplicationRepair.2013_03_06_12_33_57.out " command to see the output
 

) データベースのサイズによっては、データベース レプリケーションの修復に数分を要することがあります。


レプリケーションの修復の進行状況をモニタするには、ステップ 4 に進みます。

ステップ 4 パブリッシャ ノードの管理 CLI から次のコマンドを実行して、レプリケーション修復の進行状況をチェックします。

utils dbreplication runtimestate
 

次に、レプリケーションが完了したときの出力例を示します。太字のテキストは、レプリケーション修復の最終ステータスを強調表示しています。

admin:utils dbreplication runtimestate
 
DB and Replication Services: ALL RUNNING
 
Cluster Replication State: Replication repair command started at: 2013-03-06-12-33
Replication repair command COMPLETED 269 tables processed out of 269
No Errors or Mismatches found.
 
Use 'file view activelog cm/trace/dbl/sdi/ReplicationRepair.2013_03_06_12_33_57.out' to see the details
 
DB Version: ccm8_6_4_98000_192
Number of replicated tables: 269
 
Cluster Detailed View from PUB (2 Servers):
 
PING REPLICATION REPL. DBver& REPL. REPLICATION SETUP
SERVER-NAME IP ADDRESS (msec) RPC? STATUS QUEUE TABLES LOOP? (RTMT) & details
----------- ----------- ------ ---- ----------- ----- -------- ---- -----------------
server1 10.53.56.17 0.052 Yes Connected 0 match Yes (2) PUB Setup Completed
server2 10.53.56.14 0.166 Yes Connected 0 match Yes (2) Setup Completed
 

次のように進めます。

a. レプリケーションの修復がエラーまたは不一致なしで完了した場合は、ステップ 1 に戻り、新しいノード名が正常に複製されたことを検証します。

b. エラーまたは不一致が見つかった場合は、サーバ間の一時的な不一致が存在する可能性があります。レプリケーションの修復を再度実行するには、ステップ 3 に戻ります。


) レプリケーションの修復を数回試行した後も、不一致またはエラーがレポートされる場合は、シスコのサポート担当者に連絡して問題を解決してください。


ステップ 5 パブリッシャ ノードの管理 CLI から次のコマンドを実行して、レプリケーション再確立の進行状況をチェックします。

utils dbreplication reset all
 

このコマンドの出力例を次に示します。

admin:utils dbreplication reset all
This command will try to start Replication reset and will return in 1-2 minutes.
Background repair of replication will continue after that for 1 hour.
Please watch RTMT replication state. It should go from 0 to 2. When all subs
have an RTMT Replicate State of 2, replication is complete.
If Sub replication state becomes 4 or 1, there is an error in replication setup.
Monitor the RTMT counters on all subs to determine when replication is complete.
Error details if found will be listed below
OK [10.53.56.14]
 

) データベースのサイズによっては、データベース レプリケーションが完全に再確立するのに数分を要することがあります。


レプリケーションの再確立の進行状況をモニタするには、ステップ 6 に進みます。

ステップ 6 パブリッシャ ノードの管理 CLI から次のコマンドを実行して、ステップ 5 のデータベース レプリケーションを再確立する試行の進行状況をモニタします。

utils dbreplication runtimestate
 

次の例のような出力が表示されます。

admin: utils dbreplication runtimestate
 
DDB and Replication Services: ALL RUNNING
 
DB CLI Status: No other dbreplication CLI is running...
 
Cluster Replication State: BROADCAST SYNC Completed on 1 servers at: 2012-09-26-15-18
Last Sync Result: SYNC COMPLETED 257 tables sync'ed out of 257
Sync Errors: NO ERRORS
 
DB Version: ccm9_0_1_10000_9000
Number of replicated tables: 257
Repltimeout set to: 300s
 
Cluster Detailed View from gwydlvm020105 (2 Servers):
PING REPLICATION REPL. DBver& REPL. REPLICATION SETUP
SERVER-NAME IP ADDRESS (msec) RPC? STATUS QUEUE TABLES LOOP? (RTMT) & details
----------- -------------- ------ ---- ----------- ----- ------ ----- -----------------
server1 192.168.10.201 0.038 Yes Connected 0 match Yes (2) PUB Setup Completed
server2 192.168.10.202 0.248 Yes Connected 0 match Yes (2) Setup Completed
server3 192.168.10.203 0.248 Yes Connected 0 match Yes (2) Setup Completed
server4 192.168.10.204 0.248 Yes Connected 0 match Yes (2) Setup Completed
 

すべてのノードで REPLICATION STATUS が Connected であり、REPLICATION SETUP 値が (2) Setup Complete であれば、レプリケーションは再確立されたと見なされます。次のように進めます。

a. レプリケーションが再確立されたら、ステップ 1 に戻り、新しいノード名が正常に複製されたことを検証します。

b. レプリケーションが回復しない場合は、シスコのサポート担当者に連絡してこの問題を解決してください。


注意 データベース レプリケーションが切断されている場合は、これより先に進まないでください。


 

次の作業

「Cisco Unified Communications Manager での更新の確認」

Cisco Unified Communications Manager での更新の確認

Cisco Unified Communications Manager の管理 GUI で、このサーバのアプリケーション サーバのエントリが、新しいノード名を反映して更新されていることを確認します。

変更された各ノード名でこの手順を実行する必要があります。

はじめる前に

データベース レプリケーションがすべてのノードで動作可能であることを確認します。「データベース レプリケーションの確認」を参照してください。

手順


ステップ 1 Cisco Unified Communications Manager の管理 GUI にサインインし、[システム(System)] > [アプリケーション サーバ(Application Server)] に移動します。

ステップ 2 [アプリケーション サーバの検索/一覧表示(Find and List Application Servers)] ページで、必要に応じて、[検索(Find)] をクリックします。

ステップ 3 アプリケーション サーバのリストに、更新したノード名に対してエントリが存在することを確認します。エントリがない場合は、新しいノード名のエントリを追加します。


 

次の作業

クラスタにあるすべての該当するノードで、変更後の作業リストにある作業を完了します。「変更後のタスク」を参照してください。