Cisco Unified Communications Manager, Release 9.1(1) IM and Presence サービス用 IP アドレス/ドメイン/ホスト名
サーバ ドメインの変更
サーバ ドメインの変更
発行日;2013/04/23 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 788KB) | フィードバック

目次

サーバ ドメインの変更

手順の概要

手順のワークフロー

DNS レコードの更新

のノード名の更新

DNS ドメインの更新

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

データベース レプリケーションの再開

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

手順の概要

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


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

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

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

実際の導入環境で全社的なプレゼンス ドメインを変更するには、『Deployment Guide for IM and Presence Service on Cisco Unified Communications Manager』を参照してください。


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

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

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


 

手順のワークフロー

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

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


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


表の凡例:

X:必須の手順

NA:適用されない手順

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

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

1

クラスタにあるすべての適用対象ノードについて 作業前のチェックリストを作成します。

このチェックリストには、変更を実施する前にシャットダウンを必要とするサービスのリストなど、前提条件の手順がいくつか記載されています。

これらの手順の中には、パブリッシャ ノードのみに適用するものが存在することがあります。したがって、サブスクライバ ノードのチェックリストを扱う場合は、そのような手順を省略してもかまいません。

X

X

X

2

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

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

X

X

X

3

クラスタにあるすべての適用対象ノードで、Cisco Unified CM IM およびプレゼンス管理 GUI から IM and 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

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

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

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

X

X

X

8

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

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

X

X

X

DNS レコードの更新

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

A レコード

PTR レコード

SRV レコード

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

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


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

スケジュールされているメンテナンス時間の前に DNS レコードを更新すると、IM and 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.
 


 

次の作業

「IM and Presence のノード名の更新」

IM and Presence のノード名の更新

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


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

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


 

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

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

はじめる前に

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

手順


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

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

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

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

右側のペインでは、[ノード設定(Node Configuration)] セクションで [名前(Name)] パラメータがサーバの FQDN に設定されています。

d. この FQDN が新しいドメイン名の値を参照するように、[名前(Name)] パラメータを更新します。たとえば、[名前(Name)] の値を 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 CM IM およびプレゼンス管理 GUI のクラスタ トポロジ設定で設定した全社的なプレゼンス ドメインを変更するものではありません。


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

実際の導入環境で全社的なプレゼンス ドメインを変更するには、『Deployment Guide for IM and Presence Service on Cisco Unified Communications Manager』を参照してください。


 

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

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

はじめる前に

IM and Presence のノード名を更新していることを確認します。「IM and 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 を選択して Enter キーを押すことでドメインの変更を確認し、サーバをリブートします。


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


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


 

次の作業

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

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

サーバがリブートして稼働状態に戻った後、クラスタにあるすべてのサーバを手動でリブートする必要があります(自動的にリブートしたサーバも同様にリブートします)。このリブートは、すべてのサーバで、オペレーティング システムのコンフィギュレーション ファイルを、新しいドメインの値に一致したものにすることを目的としています。

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

はじめる前に

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

手順


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

utils system restart
 

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

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

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

ステップ 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 時間以上を要することがあります。次の手順に示す検証機能を使用して、すべてのノードでレプリケーションが完了したことを確認したうえで、次の手順に進みます。


はじめる前に

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

手順


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

utils service list
 

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

admin: utils service list
 
 
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 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.50.219]
 

この CLI コマンドが返るまでに 1 ~ 2 分を要することがあります。一方、レプリケーションの回復処理はバックグラウンドで実行を継続しており、その完了には 1 ~ 2 分よりもはるかに長い時間がかかることがあります。

ステップ 4 管理 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):
 
SERVER-NAME
-----------
IP ADDRESS
---------------
PING (msec)
------
RPC?
-----
REPLICATION STATUS
----------
REPL. QUEUE
------
DBver& TABLES
------
REPL LOOP?
-----
REPLICATION SETUP
(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

server3

192.168.10.204

0.248

Yes

Connected

0

match

Yes

(2)Setup Completed

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


) REPLICATION SETUP 値に (4) が示されているサーバがある場合は、レプリケーションに問題があることが考えられます。この手順のステップ 1 に戻り、レプリケーションを再度再開します。


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

utils dbreplication runtimestate
 

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


) REPLICATION SETUP 値に (4) が示されているサーバがある場合は、レプリケーションに問題があることが考えられます。この手順のステップ 1 に戻り、レプリケーションを再度再開します。


すべてのノードでレプリケーションが正常に確立されれば、データベースのレプリケーションを再開するこの手順は完了です。


 

次の作業

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

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

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

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

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

はじめる前に

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

手順


ステップ 1 証明書にサードパーティの認証局による署名が必要な場合は、Cisco Unified IM and Presence Operating System Administration GUI にサインインし、関連する証明書ごとに必要な手順を実行します。

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

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

utils service restart tomcat
 

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

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


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

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


 


 

次の作業

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