この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
• 「手順の概要」
この手順で、管理者は IM and Presence サーバまたはサーバのグループに関連付けた DNS ドメインを変更できます。
この手順ではサーバの 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 つのクラスタで変更を完了する必要があります。
(注) この手順の各タスクは、この表に示された順序どおりに実行する必要があります。
|
|
|
||
---|---|---|---|---|
|
|
|
||
クラスタにあるすべての適用対象ノードについて 作業前のチェックリストを作成します。 • このチェックリストには、変更を実施する前にシャットダウンを必要とするサービスのリストなど、前提条件の手順がいくつか記載されています。 • これらの手順の中には、パブリッシャ ノードのみに適用するものが存在することがあります。したがって、サブスクライバ ノードのチェックリストを扱う場合は、そのような手順を省略してもかまいません。 |
||||
クラスタにあるすべての適用対象ノードで、サーバに対して DNS レコードの更新を実行します。 • SRV、順方向(A)、および逆方向(PTR)の各レコードを必要に応じて更新し、新しいサーバ ドメインを取り入れます。 |
||||
クラスタにあるすべての適用対象ノードで、Cisco Unified CM IM およびプレゼンス管理 GUI から IM and Presence のノード名の更新を実行します。 • ノード名が FQDN であるノードでは、ドメイン変更前のサーバのドメイン名を参照しています。したがって、FQDN の値に新しいサーバ ドメインが反映されるように、ノード名を更新する必要があります。 |
||||
管理 CLI で、適用対象のすべてのノードに対して DNS ドメインの更新を実行します。 この CLI コマンドは、サーバのオペレーティング システムに対して必要なドメイン変更を実行します。これによって、各サーバで自動リブートが発生します。 |
||||
この手順では、変更したサーバに関連付けられた DNS ドメインの変更が、すべてのノードでオペレーティング システムのコンフィギュレーション ファイルに反映されます。 |
||||
管理 CLI で データベース レプリケーションの再開を実行します。 |
||||
サーバで セキュリティ証明書の再生成を実行します。 • すべての IM and Presence のセキュリティ証明書では、件名 CN がサーバの FQDN に設定されています。したがって、新しいサーバ ドメインを取り入れるために、DNS ドメインの変更後は、すべての証明書が自動的に再生成されます。 |
||||
クラスタにあるすべての適用対象ノードについて 変更後の作業リストリストを作成します。 |
サーバの DNS ドメインが変更されるので、そのサーバに関連付けられた既存の DNS レコードをすべて更新する必要があります。この対象となるレコードは、次のタイプのレコードです。
クラスタにある複数のサーバを変更する場合は、それらのサーバごとに次の手順を実行する必要があります。
パブリッシャ ノードを変更する場合は、この手順をまずパブリッシャ ノードで実行し、その後で該当するすべてのサブスクライバ ノードで同じ手順を繰り返します。
(注) • これらの DNS レコードの更新は、サーバでの DNS ノードの変更そのものを実行したメンテナンス時間の中で実行する必要があります。
• スケジュールされているメンテナンス時間の前に DNS レコードを更新すると、IM and Presence サービスの機能に影響が及ぶ可能性があります。
作業前のチェックリストでのチェックを完了していることを確認します。詳細については、「作業前のチェックリスト」を参照してください。
ステップ 1 サーバの古い DNS 順方向(A)レコードを、古いドメインから削除します。
ステップ 2 新しいドメインに、このサーバの新しい DNS 順方向(A)レコードを作成します。
ステップ 3 このサーバの DNS 逆方向(PTR)レコードを更新し、サーバの更新された完全修飾ドメイン名(FQDN)を指すようにします。
ステップ 4 このサーバを指している DNS SRV レコードをすべて更新します。
ステップ 5 このサーバを指している他の DNS レコードをすべて更新します。
ステップ 6 各ノードの管理 CLI で次のコマンドを実行して、クラスタにある他のすべてのノードに上記の DNS の変更がすべて伝播されていることを確認します。
(注) 手順のこの時点では、サーバの DNS ドメインを変更しない限り、IP アドレスのローカル解決は古い FQDN を指したままになっています。
次に、_xmpp-server SRV レコードをルックアップする例を示します。
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 に更新します。
ステップ 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 ドメインの更新」を参照してください。
ここでは、管理 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 にサインインし、次のコマンドを実行してドメインを変更します。
設定する新しいドメインの値を new-domain とします。サンプル出力は次のとおりです。
ステップ 2 y を選択して Enter キーを押すことでドメインの変更を確認し、サーバをリブートします。
(注) ノード名を変更すると、すべての証明書がサーバで再生成されます。これらの証明書の中に、サードパーティの認証局で署名したものがある場合、この手順の後半で、それらの署名済み証明書を再度要求する必要があります。「セキュリティ証明書の再生成」を参照してください。
ステップ 3 上記の例で示したように、ドメイン名を変更すると、サーバが自動的にリブートします。サーバが再起動した後、次のコマンドを実行して、ドメイン名の変更が反映されていることを確認します。
たとえば、次のコマンドでは、新しいドメインが「new-domain」であることを確認します。
クラスタにあるすべてのサーバをリブートします。「ドメイン更新後のクラスタにあるすべてのサーバのリブート」を参照してください。
サーバがリブートして稼働状態に戻った後、クラスタにあるすべてのサーバを手動でリブートする必要があります(自動的にリブートしたサーバも同様にリブートします)。このリブートは、すべてのサーバで、オペレーティング システムのコンフィギュレーション ファイルを、新しいドメインの値に一致したものにすることを目的としています。
まず、パブリッシャ ノードのリブート プロセスから開始します。パブリッシャ ノードが再起動したら、任意の順序で残りのサブスクライバ ノードのリブートを実行します。
サーバの DNS ドメインを変更済みであることを確認します。「DNS ドメインの更新」を参照してください。
ステップ 1 管理 CLI で次のコマンドを使用してパブリッシャをリブートします。
ステップ 2 yes と入力して Enter キーを押し、再起動します。
ステップ 3 パブリッシャ ノードが再起動したことを示す次のメッセージが表示されるまで待ちます。
ステップ 4 サブスクライバ ノードごとに管理 CLI にサインインし、同じコマンドを実行してそのノードをリブートします。
(注) サービスの停止の試行で数分が経過すると、管理 CLI から強制的な再起動を要求されることがあります。その場合は yes を入力します。
データベースのレプリケーションを再開します。「データベース レプリケーションの再開」を参照してください。
クラスタにあるすべてのサーバが再起動した後、データベースのレプリケーションを再開する必要があります。
(注) ライセンス許諾されたユーザが多数存在するクラスタでは、データベースのレプリケーションの再開が完了するまでに 1 時間以上を要することがあります。次の手順に示す検証機能を使用して、すべてのノードでレプリケーションが完了したことを確認したうえで、次の手順に進みます。
クラスタにあるすべてのサーバがリブートしていることを確認します。「ドメイン更新後のクラスタにあるすべてのサーバのリブート」を参照してください。
ステップ 1 クラスタにあるすべてのノードで管理 CLI から次のコマンドを入力して、必須のデータベース サービスが稼働していることを確認します。
ステップ 2 この出力で、次のサービスの状態が STARTED であることを確認します。
• Cisco Database Layer Monitor
(注) クラスタにあるすべてのノードで上記のサービスが稼働していることを確認できない場合は、以降の手順には進まないでください。
ステップ 3 パブリッシャ ノードの管理 CLI で以下のコマンドを入力して、クラスタ全体で複数を再開します。
この CLI コマンドが返るまでに 1 ~ 2 分を要することがあります。一方、レプリケーションの回復処理はバックグラウンドで実行を継続しており、その完了には 1 ~ 2 分よりもはるかに長い時間がかかることがあります。
ステップ 4 管理 CLI で次のコマンドを実行して、パブリッシャ ノードでレプリケーションが正常に確立されたことを確認します。
ステップ 5 すべてのノードで REPLICATION STATUS が Connected であることおよび REPLICATION SETUP 値が (2) Setup Complete であることが示されるまで、ステップ 3 を繰り返します。この時点で、パブリッシャ ノードでは、データベースのレプリケーションが完全に確立されたと見なします。
(注) REPLICATION SETUP 値に (4) が示されているサーバがある場合は、レプリケーションに問題があることが考えられます。この手順のステップ 1 に戻り、レプリケーションを再度再開します。
ステップ 6 サブスクライバ ノードごとに管理 CLI から次のコマンドを実行して、すべてのサブスクライバ ノードでレプリケーションが正常に確立していることを確認します。
ステップ 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 サービスを再起動します。
• 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 サービスを再起動します。
(注) • これらの再起動によって、サービスが影響を受けます。したがって、署名済み証明書を入手するまでに要する時間に応じて、これらのサービスを再起動するメンテナンス時間のスケジュール設定が別途必要になることがあります。サービスを再起動するまでの間は、暫定的に自己署名の証明書が関連のインターフェイスに引き続き提示されます。
• 上記のリストで指定されていない証明書では、サービスの再起動は不要です。
クラスタにあるすべての該当するノードで、変更後の作業リストにある作業を完了します。「変更後の作業リスト」を参照してください。