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

目次

サーバ ドメインの変更

手順の概要

手順のワークフロー

DNS レコードの更新

のノード名の更新

DNS ドメインの更新

ドメイン更新後のクラスタにあるすべてのサーバのリブート

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

セキュリティ証明書の再生成

手順の概要

この手順で、管理者は Cisco Unified Presence サーバまたはサーバのグループに関連付けた DNS ドメインを変更できます。


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

この手順ではサーバの DNS ドメインを変更しますが、Cisco Unified Presence 管理 GUI のクラスタ トポロジ設定で設定した全社的なプレゼンス ドメインを変更するものではありません。

全社的なプレゼンス ドメインは、どの Cisco Unified Presence サーバの DNS ドメインにも合わせる必要はありません。

導入環境の全社的なプレゼンス ドメインを変更する場合は、『Deployment Guide for Cisco Unified Presence』を参照してください。


) • この手順では、サードパーティの署名済みセキュリティ証明書がすべて、新しい自己署名の証明書で自動的に上書きされます。これらの証明書にサードパーティの認証局による再署名を適用するには、新しい証明書を手動で依頼し、アップロードする必要があります。

これらの新しい証明書を有効にするには、サービスの再起動が必要になることがあります。新しい証明書の要求に要する時間によっては、メンテナンス時間を別途設定して、サービスの再起動スケジュールを設定することが必要になる場合もあります。

この手順に先立って、これらの新しい証明書を要求することはできません。証明書署名要求(CSR)を生成できるのは、サーバでドメインを変更し、そのサーバを再起動した後だけです。


 

手順のワークフロー

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

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


) この手順の各タスクは、この表に示された順序どおりに実行する必要があります。


表の凡例:

X:必須の手順

NA:適用されない手順

表 6-1 DNS ドメインを変更するためのワークフロー

手順
タスク
ノード名の形式
IP アドレス
ホスト名
FQDN

1

クラスタにあるすべての適用対象ノードについて 「変更前のタスク」 を作成します。

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

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

X

X

X

2

クラスタにあるすべての適用対象ノードで、サーバに対して DNS レコードの更新を実行します。

SRV、順方向(A)、および逆方向(PTR)の各レコードを必要に応じて更新し、新しいサーバ ドメインを取り入れます。

X

X

X

3

クラスタにあるすべての適用対象ノードで、Cisco Unified Presence 管理 GUI から Cisco Unified Presence のノード名の更新を実行します。

ノード名が FQDN であるノードでは、ドメイン変更前のサーバのドメイン名を参照しています。したがって、FQDN の値に新しいサーバ ドメインが反映されるように、ノード名を更新する必要があります。

ノード名が IP アドレスまたはホスト名の場合は、ドメインを参照していないので、何の変更も必要ありません。

NA

NA

X

4

管理 CLI で、適用対象のすべてのノードに対して DNS ドメインの更新を実行します。

この CLI コマンドは、サーバのオペレーティング システムに対して必要なドメイン変更を実行します。これによって、各サーバで自動リブートが発生します。

X

X

X

5

ドメイン更新後のクラスタにあるすべてのサーバのリブート

この手順では、変更したサーバに関連付けられた DNS ドメインの変更が、すべてのノードでオペレーティング システムのコンフィギュレーション ファイルに反映されます。

X

X

X

6

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

クラスタにあるすべてのシステム ファイルが互いに同期した後で、データベースのレプリケーションを確認する必要があります。

X

X

X

7

サーバで セキュリティ証明書の再生成を実行します。

すべての Cisco Unified Presence のセキュリティ証明書では、件名 CN がサーバの FQDN に設定されています。したがって、新しいサーバ ドメインを取り入れるために、DNS ドメインの変更後は、すべての証明書が自動的に再生成されます。

それまでに認証局で署名されていた証明書には、再署名が必要です。

X

X

X

8

クラスタにあるすべての適用対象ノードについて 「変更後のタスク」 リストを作成します。

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

X

X

X

DNS レコードの更新

サーバの DNS ドメインを変更するため、そのサーバに関連付けられているすべての既存の DNS レコードを更新する必要があります。この対象となるレコードは、次のタイプのレコードです。

A レコード

PTR レコード

SRV レコード

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

パブリッシャ ノードを変更する場合は、この手順をまずパブリッシャ ノードで実行し、その後で該当するすべてのサブスクライバ ノードで同じ手順を繰り返します。


) • これらの DNS レコードの更新は、サーバでの DNS ノードの変更そのものを実行したメンテナンス時間の中で実行する必要があります。

スケジュールされているメンテナンス時間の前に DNS レコードを更新すると、Cisco Unified Presence サービスの機能に影響が及ぶ可能性があります。


 

はじめる前に

変更前のタスクが完了していることを確認します。詳細については、「変更前のタスク」を参照してください。

手順


ステップ 1 サーバの古い DNS 順方向(A)レコードを、古いドメインから削除します。

ステップ 2 新しいドメインに、このサーバの新しい DNS 順方向(A)レコードを作成します。

ステップ 3 このサーバの DNS 逆方向(PTR)レコードを更新し、サーバの更新された完全修飾ドメイン名(FQDN)を指すようにします。

ステップ 4 このサーバを指している DNS SRV レコードをすべて更新します。

ステップ 5 このサーバを指している他の DNS レコードをすべて更新します。

ステップ 6 各ノードの管理 CLI で次のコマンドを実行して、クラスタにある他のすべてのノードに上記の DNS の変更がすべて伝播されていることを確認します。

a. 新しい A レコードを検証するには:

utils network host new-fqdn
 

サーバの更新された FQDN を fqdn とします。

次に、例を示します。

admin: utils network host server1.new-domain.com
Local Resolution:
server1.new-domain.com resolves locally to 10.53.50.219
 
External Resolution:
server1.new-domain.com has address 10.53.50.219
 

b. 更新された PTR レコードを検証するには:

utils network host ip-addr
 

サーバの IP アドレスを ip-addr とします。

次に、例を示します。

admin: utils network host 10.53.50.219
Local Resolution:
10.53.50.219 resolves locally to server1.new-domain.com
 
External Resolution:
server1.new-domain.com has address 10.53.50.219
219.50.53.10.in-addr.arpa domain name pointer server1.new-domain.com.
 

) 手順のこの時点では、サーバの DNS ドメインを変更しない限り、IP アドレスのローカル解決は古い FQDN を指したままになっています。


c. 任意の更新済み SRV レコードを検証するには:

utils network host srv-name srv
 

SRV レコードを srv-name とします。

次に、_xmpp-server SRV レコードをルックアップする例を示します。

admin: utils network host _xmpp-server._tcp.galway-imp.com srv
Local Resolution:
Nothing found
 
External Resolution:
_xmpp-server._tcp.sample.com has SRV record 0 0 5269 server1.new-domain.com.
 


 

次の作業

「Cisco Unified Presence のノード名の更新」

Cisco Unified Presence のノード名の更新

Cisco Unified Presence の管理 GUI から [クラスタ トポロジ(Cluster Topology)] でサーバに定義しているノード名が、サーバの完全修飾ドメイン名(FQDN)に設定されている場合、そのノード名は古いドメイン名を参照しています。したがって、新しいドメイン名を参照するようにノード名を更新する必要があります。


) • この手順は、このサーバのノード名の値が FQDN に設定されている場合にのみ実行する必要があります。

ノード名がサーバの IP アドレスまたはホスト名と一致している場合、この手順は不要です。


 

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

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

はじめる前に

DNS レコードを更新済みであることを確認します。詳細については、「DNS レコードの更新」を参照してください。

手順


ステップ 1 Cisco Unified Presence サーバのノード名を変更します。

a. Cisco Unified Presence の管理 GUI にサインインします。

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

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

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

d. FQDN が新しいドメイン値を参照するように [完全修飾ドメイン名/IP アドレス(Fully Qualified Domain Name/IP Address)] フィールドを更新します。たとえば、[完全修飾ドメイン名/IP アドレス(Fully Qualified Domain Name/IP Address)] の値を server1.old-domain.com から server1.new-domain.com に更新します。

e. [保存(Save)] を選択します。

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

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

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

c. アプリケーション サーバのリストに、更新したノード名に対してエントリが存在することを確認します。


) このサーバのエントリが存在しない場合、またはそのエントリがあっても、サーバの古いノード名を反映している場合は、以降の手順には進まないでください。



 

次の作業

該当するすべてのノードで DNS ドメインを更新します。「DNS ドメインの更新」を参照してください。

DNS ドメインの更新

ここでは、管理 CLI を使用してサーバの DNS ドメインを変更する手順について説明します。

この手順ではサーバの DNS ドメインを変更しますが、Cisco Unified Presence 管理 GUI のクラスタ トポロジ設定で設定した全社的なプレゼンス ドメインを変更するものではありません。


) • 全社的なプレゼンス ドメインは、どの Cisco Unified Presence サーバの DNS ドメインにも合わせる必要はありません。

導入環境の全社的なプレゼンス ドメインを変更する場合は、『Deployment Guide for Cisco Unified Presence』を参照してください。


 

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

パブリッシャ ノードを変更する場合は、この手順をまずパブリッシャ ノードで実行し、その後で該当するすべてのサブスクライバ ノードで同じ手順を繰り返します。

はじめる前に

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

手順


ステップ 1 サーバで管理 CLI にサインインし、次のコマンドを実行してドメインを変更します

set network domain new-domain
 

設定する新しいドメインの値を new-domain とします。サンプル出力は次のとおりです。

admin: set network domain new-domain.com
 
*** W A R N I N G ***
Adding/deleting or changing domain name on this server will break
database replication. Once you have completed domain modification
on all systems that you intend to modify, please reboot all the
servers in the cluster. This will ensure that replication keeps
working correctly. After the servers have rebooted, please
confirm that there are no issues reported on the Cisco Unified
Reporting report for Database Replication.
 
The server will now be rebooted. Do you wish to continue.
 
Security Warning : This operation will regenerate
all CUP Certificates including any third party
signed Certificates that have been uploaded.
 
Continue (y/n)?
 

ステップ 2 y を選択して Return キーを押すことでドメインの変更を確認し、サーバをリブートします。


) ノード名の変更が完了すると、すべての証明書がサーバで再生成されます。これらの証明書の中に、サードパーティの認証局で署名したものがある場合、この手順の後半で、それらの署名済み証明書を再度要求する必要があります。「セキュリティ証明書の再生成」を参照してください。


ステップ 3 サーバが再起動した後、次のコマンドを実行して、ドメイン名の変更が反映されていることを確認します。

show network eth0
 

たとえば、次のコマンドでは、新しいドメインが「new-domain」であることを確認します。

admin: show network eth0
Ethernet 0
DHCP : disabled Status : up
IP Address : 10.53.50.219 IP Mask : 255.255.255.000
Link Detected: yes Mode : Auto disabled, Full, 1000 Mbits/s
Duplicate IP : no
 
DNS
Primary : 10.53.51.234 Secondary : Not Configured
Options : timeout:5 attempts:2
Domain : new-domain.com
Gateway : 10.53.50.1 on Ethernet 0
 

ステップ 4 クラスタにあるすべての該当するノードで、ステップ 1 ~ 3 を繰り返します。


 

次の作業

クラスタ内のすべてのサーバをリブートします。「ドメイン更新後のクラスタにあるすべてのサーバのリブート」を参照してください。

ドメイン更新後のクラスタにあるすべてのサーバのリブート

サーバがリブートされたら、手動でクラスタ内のすべてのサーバ(先程自動的にリブートされたサーバも含む)を再起動する必要があります。このリブートは、すべてのサーバで、オペレーティング システムのコンフィギュレーション ファイルを、新しいドメインの値に一致したものにすることを目的としています。

まず、パブリッシャ ノードのリブート プロセスから開始します。パブリッシャ ノードが再起動したら、任意の順序で残りのサブスクライバ ノードのリブートを実行します。

はじめる前に

サーバの DNS ドメインを変更したことを確認します。「DNS ドメインの更新」を参照してください。

手順


ステップ 1 管理 CLI で次のコマンドを使用してパブリッシャをリブートします。

utils system restart
 

次の出力が表示されます。

admin: utils system restart
Do you really want to restart ?
Enter (yes/no)?
 

ステップ 2 yes と入力して Return キーを押し、再起動します。

ステップ 3 パブリッシャ ノードが再起動したことを示す次のメッセージが表示されるまで待ちます。

Broadcast message from root (Wed Oct 24 16:14:55 2012):
 
The system is going down for reboot NOW!
Waiting .
 
Operation succeeded
 
restart now.
 

ステップ 4 サブスクライバ ノードごとに管理 CLI にサインインし、同じコマンドを実行してそのノードをリブートします。

utils system restart

) サービスの停止の試行で数分が経過すると、管理 CLI から強制的な再起動を要求されることがあります。その場合は yes を入力します。



 

次の作業

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

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

クラスタにあるすべてのサーバが再起動した後、データベースのレプリケーションを確認する必要があります。


) 次のステップに進む前に、以下の手順にリストされている検証メカニズムを使用して、すべてのノードでレプリケーションが完了していることを確認します。


はじめる前に

クラスタにあるすべてのサーバがリブートしていることを確認します。「ドメイン更新後のクラスタにあるすべてのサーバのリブート」を参照してください。

手順


ステップ 1 クラスタにあるすべてのノードで管理 CLI から次のコマンドを入力して、必須のデータベース サービスが稼働していることを確認します。

utils service list
 

ヒント utils service list コマンドの出力は非常に長くなります。出力をページごとに表示するには、コマンド utils service list page を入力します。


The following output displays:
Requesting service status, please wait...
System SSH [STARTED]
Cluster Manager [STARTED]
Service Manager is running
Getting list of all services
>> Return code = 0
A Cisco DB[STARTED]
A Cisco DB Replicator[STARTED]
Cisco AMC Service[STARTED]
Cisco AXL Web Service[STARTED]
Cisco Audit Event Service[STARTED]
Cisco Bulk Provisioning Service[STARTED]
Cisco CDP[STARTED]
...
...
...
Cisco XCP Authentication Service[STARTED]
Cisco XCP Config Manager[STARTED]
Cisco XCP Connection Manager[STARTED]
Cisco XCP Directory Service[STARTED]
Cisco XCP Router[STARTED]
Cisco XCP SIP Federation Connection Manager[STARTED]
Cisco XCP Text Conference Manager[STARTED]
Cisco XCP Web Connection Manager[STARTED]
Cisco XCP XMPP Federation Connection Manager[STARTED]
Host Resources Agent[STARTED]
MIB2 Agent[STARTED]
Platform SOAP Services[STARTED]
SNMP Master Agent[STARTED]
SOAP -Log Collection APIs[STARTED]
SOAP -Performance Monitoring APIs[STARTED]
SOAP -Real-Time Service APIs[STARTED]
System Application Agent[STARTED]
Cisco XCP Message Archiver[STOPPED] Service Not Activated
Primary Node =true
 

ステップ 2 この出力で、次のサービスの状態が STARTED であることを確認します。

Cisco DB

Cisco DB Replicator

Cisco Database Layer Monitor


注意 クラスタにあるすべてのノードで上記のサービスが稼働していることを確認できない場合は、以降の手順には進まないでください。

ステップ 3 管理 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
 

ステップ 4 すべてのノードで REPLICATION STATUS が Connected であることおよび REPLICATION SETUP 値が (2) Setup Complete であることが示されるまで、ステップ 3 を繰り返します。この時点で、パブリッシャ ノードでのデータベース レプリケーションが完全に確立されました。

ステップ 5 サブスクライバ ノードごとに管理 CLI から次のコマンドを実行して、すべてのサブスクライバ ノードでレプリケーションが正常に確立していることを確認します。

utils dbreplication runtimestate
 

ステップ 6 すべてのノードで REPLICATION STATUS が Connected であることおよび REPLICATION SETUP 値が (2) Setup Complete であることが示されるまで、ステップ 5 を繰り返します。この時点で、サブスクライバ ノードでのデータベース レプリケーションが完全に確立されました。

データベース レプリケーションがすべてのノードで正常に確認されたら、手順のこのステップは完了です。


 

セキュリティ証明書の再生成

サーバの完全修飾ドメイン名(FQDN)は、Cisco Unified Presence のすべてのセキュリティ証明書で件名 CN として使用されます。したがって、サーバで DNS ドメインを更新すると、すべてのセキュリティ証明書が自動的に再生成されます。

いずれかの証明書にサードパーティの認証局が署名していた場合は、認証局が署名した証明書を新たに手動で生成する必要があります。

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

はじめる前に

すべてのノードでデータベースのレプリケーションが正常に確立されていることを確認します。「データベース レプリケーションの確認」を参照してください。

手順


ステップ 1 証明書にサードパーティの認証局による署名が必要な場合は、Cisco Unified Presence オペレーティング システムの管理 GUI にサインインし、関連する証明書ごとに必要な手順を実行します。

ステップ 2 署名済み証明書をアップロードした後、Cisco Unified Presence サーバでサービスの再起動が必要になることがあります。再起動が必要になるサービスは次のとおりです。

Tomcat 証明書:管理 CLI から次のコマンドを実行して、tomcat サービスを再起動します。

utils service restart Cisco Tomcat
 

CUP-xmpp 証明書:Cisco Unified Presence Serviceability GUI から Cisco UP XCP Router サービスを再起動します。

CUP-xmpp-s2s 証明書:Cisco Unified Presence Serviceability GUI から Cisco UP XCP Router サービスを再起動します。


) • これらの再起動は、サービスに影響します。したがって、署名済み証明書を入手するまでに要する時間に応じて、これらのサービスを再起動するメンテナンス時間のスケジュール設定が別途必要になることがあります。サービスを再起動するまでの間は、暫定的に自己署名の証明書が関連のインターフェイスに引き続き提示されます。

上記のリストで指定されていない証明書では、サービスの再起動は不要です。


 


 

次の作業

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