XシリーズサーバをCisco Meeting Serverアプライアンスまたは仮想マシンに置き換える

概要

このドキュメントでは、Acano Xシリーズサーバを安全かつ確実にCisco Meeting Server(CMS)仮想マシン(VM)、CMS1000、またはCMS2000サーバに置き換える方法について説明します。Acano Xシリーズサーバのサポートは、バージョン3.0以降では廃止されました。  Xシリーズで実行できる最新のソフトウェアは2.9.5で、2022年3月1日までしかサポートされていません。  その後、これ以上のメンテナンスリリースやバグ修正はありません。  つまり、Acano Xシリーズサーバがある場合は、その前にサーバを交換する必要があります。

要件

次の項目に関する知識があることが推奨されます。

• CMS管理
• CMSのアップグレード
• 証明書の作成と署名

使用するコンポーネント

このドキュメントの情報は、Cisco Meeting Server（VM、CMS1K、またはCMS2K）およびAcano Xシリーズサーバに基づいています。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

Xシリーズサーバを交換する場合は、さまざまなサーバのコールキャパシティを認識する必要があります。サイジングのガイダンスについては、付録C(https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-installation-and-configuration-guides-list.html)のCisco Meeting Server導入ガイドを参照してください。

参照用のXシリーズサイズ：

• X1 - 25 HD(720p)コール
• X2 - 125 HD(720p)コール
• X3 - 250 HD(720p)コール

交換用サーバのセットアップ手順は、インストールに関するドキュメントに記載されており、次の項では説明しません。  インストール ガイドは次の場所にあります。  https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-installation-guides-list.html にアクセスしてください。

XシリーズサーバをCMSアプライアンスまたは仮想マシンに交換

Xシリーズサーバを置き換えるためにサポートされている方法は、新しいデバイスをデータベースクラスタに追加し、データベースのコピーを取得する方法です。

注意：Xシリーズサーバからのバックアップを使用して交換を導入しないでください。

交換を完了するには、次のすべての手順が必要なわけではありません。  新しいサーバを古いサーバでクラスタ化し、データベースのコピーを取得することが最も重要な部分です。 

移行プロセスが完了すると、すべてのデータベース情報（着信ルール、発信ルール、コスペース、コールIDなど）が新しいサーバ上に表示されます。

注：グラフィカルユーザインターフェイス(GUI)で[Configuration] > [General]および[Configuration] > [Active Directory]に入力されたデータはデータベースに含まれていません。  Lightweight Directory Access Protocol(LDAP)設定をGUIからアプリケーションプログラミングインターフェイス(API)に移動する必要があります。 まだ準備ができていない場合は、新しいサーバに再入力できるように、これらの2ページのすべてのデータをコピーします。LDAPユーザ名のパスワードはLDAPにも必要です。この情報はコピーできないためです。

最初にワークフローの概要を示し、次に手順の説明を示します。交換手順の手順に従うことを強く推奨します。

作業の概要

ステップ1：古いAcano Xシリーズサーバからバックアップファイルを作成します。

ステップ2：新しいサーバのメインボード管理プロセッサ(MMP)を設定するために情報が必要な場合は、古いサーバからバックアップファイルとlogbundle.tar.gzファイルをダウンロードします。

ステップ3：古いXシリーズサーバで、MMPにログインし、各サービス/構成の出力を取得し、情報をノートファイルにコピーします。 

ステップ4：新しいサーバをセットアップします。

ステップ5：新しいサーバでライセンスを取得します。

ステップ6：古いサーバから新しいサーバに証明書をコピーします。

ステップ7：古いサーバにセットアップされた新しいサーバでMMPサービスを有効にします。
(Acano Xシリーズは、専用の管理インターフェイスを使用して管理できます。A-Dインターフェイスを使用して新しいサーバを管理する必要がありますが、新しいサーバ上のすべてのサービスをAインターフェイス上に配置できます)。

ステップ8：古いサーバで使用したのと同じユーザアカウントを新しいサーバに作成します。

ステップ9：データベースを新しいサーバにコピーします。

ステップ10：データベースクラスタからXシリーズを削除します。

ステップ11：新しいサーバが置き換えるXシリーズサーバをシャットダウンします。

ステップ12：新しいデバイスのIPを、交換対象の古いXシリーズインターフェイスAのIPと一致するように変更します。  Xシリーズで複数のインターフェイスを使用する場合は、新しいサーバでも使用する必要があります。これにより、DNSレコードを変更する必要がなくなります。

ステップ13：サーバをデータベースクラスタに戻します（元の展開が単一の統合サーバでない場合のみ）。

ステップ14:API - api/v1/system/configuration/clusterの新しいサーバに応じてロード制限を調整します。

ステップ15：展開をテストして、引き続き動作することを確認します。

詳細な手順

ステップ1:MMPコマンドbackup snapshot <server_specific_filename>を使用してバックアップを作成します。

ステップ2：置き換える各Xシリーズサーバから、バックアップファイルとlogbundle.tar.gz(https://video.cisco.com/video/5810051601001)ファイルをダウンロードします。

ステップ3:Xシリーズサーバで次のコマンドを実行して、さまざまなサービスの設定を取得し、ノートファイルに保存します。これにより、新しいサーバを再設定する方法を簡単に参照できます。

'webadmin'、'callbridge'、'webbridge'、'xmpp'、'turn'、'dns'、'ntp server list'、'tls sip'、'tls ldap'、'tls dtls'、'tls webadmin'、'database cluster status'、'user list'、'ipv4 a'、'ipv4 b'、'ipv4 c'、'ipv4 d'、'recorder '、'streamer'、'uploader'、'dscp'、'sipedge'、'h323_gateway'、'syslog'、'ldap'

注：H323_gateway、Sip Edge、およびXMPPはCMS 3.0で廃止されました。 

SIPエッジを使用する場合、インターネットとの間でトラフィックをルーティングするには、Cisco Expressway-CおよびEが必要です。 
H323ゲートウェイを使用する場合、H.323からSIPへのインターワーキングを実行するために、Cisco Expresswayサーバを使用してこれを設定する必要があります。
XMPPを使用する場合は、CMS 3.xにアップグレードした後で、設定を変更する必要があります。ただし、Xシリーズを交換して2.9.xでしばらく待ち、WebRTC、レコーダ、またはストリーマを使用する必要がある場合は、新しいサーバでXMPPを再設定する必要があります。 

このドキュメントでは、CMS 3.0にアップグレードする前に認識しておく必要のある変更について詳しく説明します。

ステップ4：新しいサーバをセットアップします。Xシリーズサーバと同じバージョンのコードを使用していることを確認します。現在使用されていないサーバのIPを指定します(ipv4 <interface> add <address>/<prefix length> <gateway>)。ただし、作業が完了すると、IPはXシリーズで使用されたものに変更されます。これは、DNSレコードと証明書の変更を回避するためです。  古いIPを再利用しない場合は、それに応じてDNSと証明書を更新する必要があります。

ステップ5：新しいサーバと古いXシリーズサーバのMMPで、コマンドiface aを実行してAインターフェイスのMACアドレスを取得します。交換しようとしているXシリーズから、cms.licファイルをダウンロードし、TACライセンスケースをオープンします。新しいサーバのインターフェイスAのMACアドレスと古いサーバのMACをライセンスエージェントに渡し、古いサーバを新しいサーバに置き換えることを指示します。古いMACから新しいMACにライセンスを交換するように依頼します。新しいライセンスファイルが提供されます。このファイルを解凍し、cms.licという名前を変更して、新しいサーバにアップロードする必要があります。

ステップ6：古いXシリーズで使用されている証明書、キー、および認証局(CA)ファイルを、WinSCPまたはその他のSFTPプログラムを使用して新しいサーバにコピーします。

ステップ7：新しいサーバで、古いXシリーズと同じサービスと設定をMMPで有効にします。手順3で収集した情報を参照して、以前と同じ設定になっていることを確認してください。 

注：これらの新しいサーバのセットアップ直後にCMS 3.xにアップグレードする場合は、XMPP、Webbridge、SIP Edge、またはH323_gatewayコンポーネントを設定する必要はありません。これらはCMS 3.xでは使用されなくなりました。

ステップ8：コマンドuser add <username> <role> (およびルールが設定されている場合はuser rule <rule name> <value>を使用)を使用して、MMP上のXシリーズサーバと同じユーザアカウントを作成します。 Cisco Meeting Management(CMM)、TelePresence Management Suite(TMS)、またはCisco Unified Communications Manager(CUCM)などの他のデバイスは、これらのアカウントの機能を設定できるため、新しいサーバで設定する必要があります。

ステップ9：データベースのコピーを新しいサーバに取得します。 

9a。現在の配置が単一の結合サーバ(データベース・クラスタなし)の場合は、データベース・クラスタを初期化する必要があります。CMSバージョン2.7以降では、データベースクラスタには証明書が必要です。したがって、データベース証明書の署名に使用できる、バージョン2.7以降の組み込み認証局(CA)がCMSに導入されています。

1.単一の組み合わせXシリーズMMPで、pki selfsigned dbca CN:<会社名> (例：pki自己署名dbca(CN:tplab.local)

2.単一の組み合わせXシリーズMMPで、pki csr dbserver CN:xseries.example.com subjectAltName:<newcms1fqdn>を使用してデータベースサーバの証明書を作成します

（この時点ではDNS Aレコードは必要ありません）。

3.単一の組み合わせXシリーズMMPで、pki csr dbclient CN:postgresを使用してデータベースクライアントの証明書を作成します

4.単一の組み合わせXシリーズMMPでは、dbca（ステップ1から）を使用して、dbserver（ステップ2から）証明書pki署名dbserver dbcaに署名します

5.単一の組み合わせXシリーズMMPでは、dbca（ステップ1から）を使用して、dbclient（ステップ3から）証明書pki sign dbclient dbcaに署名します

6. dbserver.crt、dbserver.key、dbclient.crtおよびdbclient.keyファイルを、データベース（データベースクラスタを構成するノード）に参加するすべてのサーバ（Xシリーズから新しいサーバ）にコピーします

7. Xシリーズからすべてのサーバにdbca.crtファイルをコピーします

8.単一の組み合わせXシリーズMMPで、database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt （ルートCA証明書としてdbca.crt）を実行します

9.単一の組み合わせXシリーズMMP上で、データベースクラスタlocalnode aを実行します

10.単一の組み合わせXシリーズMMPで、データベースクラスタの初期化を実行します

11.単一の結合XシリーズMMPで、データベースクラスタの状態を実行します。次のように表示される必要があります。
ノード：<XseriesIP> (me):接続プライマリ

12.データベースクラスタに参加する新しいサーバで、MMPからdatabase cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt

13.参加する新しいサーバ（データベースと共存）で、MMPから：

a.データベースクラスタlocalnode aを実行します

b.データベースクラスタ結合の実行<プライマリノードIP>

この時点で、新しいサーバはデータベースのコピーを持っています。新しいサーバのMMPでデータベースクラスタの状態を実行し、それらが同期として表示されることを確認します。  同期されていない場合は、データベースクラスタの設定を確認し、サーバ間のTCP 5432経由の通信をブロックするネットワークに何も存在しないことを確認する必要があります。

9b。現在の展開が既にデータベースクラスタである場合、Xシリーズサーバを一度に1つずつ置き換える必要があります。XシリーズでMMPデータベースクラスタの状態で実行し、サーバがデータベースクラスタに参加しているか、接続されているかを確認します。サーバのIPがデータベースクラスタリストにある場合は、サーバに参加します。  表示されていない場合、最後のコマンドが「database cluster connect」であれば、ノードが接続されます。 

新しいノードを同じロール（参加または接続）として追加し直す必要があるため、Xシリーズサーバのロールをメモします。  Xシリーズがデータベース・プライマリの場合は、まずサーバを再起動してレプリカにします。

1.交換しようとしているXシリーズでは、サーバキー/証明書、クライアントキー/証明書、およびCA証明書に使用される証明書に注意してください

2.交換しようとしているXシリーズで、データベースクラスターの削除を実行します

ステップ10。組み合わされた1台のXシリーズサーバを置き換える場合は、ステップ10に進みます。  クラスタの場合は、ステップ11に進みます。

これで、新しいサーバにデータベースのコピーが作成されます。  これを確認するには、新しいサーバのWebインターフェイスにログインし、ユーザとスペースの設定を確認します。確認後、データベースクラスタから新しいサーバを削除し、IPを変更します。

1.新しいサーバーで、'database cluster remove'を実行します。

2. Xシリーズサーバをシャットダウンします。

3.新しいサーバのIPをXシリーズサーバで使用されているIPに変更します。

4.新しいサーバをリブートします。

5. CMS 2.9.xのバージョンを使用している場合は、すべての設定が機能するように新しいサーバをテストします。

6.新しいサーバのWeb管理ページにログインし、スペースとユーザを確認します。以前にデータベースに参加したときにサーバに存在していたすべてのスペースとユーザが、データベースのコピーを取得したときに表示されている必要があります。

ステップ11：クラスタの一部であるXシリーズサーバを交換する場合は、次の手順に従います。

1.停止するXシリーズサーバをシャットダウンします。

2.新しいサーバのIPを、Xシリーズサーバのデータベースlocalnodeインターフェイス（通常はa）で以前に使用されていたIPに変更します。

3.サーバキー/証明書、クライアントキー/証明書、およびCA証明書をSFTPプログラムを使用して新しいサーバにコピーします。

4.新しいサーバで、コマンド「database cluster localnode a」を実行します

5a.新しいノードをデータベース・クラスタに結合する場合は、コマンド「database cluster certs <server.key> <server.crt> <client.key> <client.crt> <ca.crt> 」を実行します

5b.新しいノードをデータベースクラスタに接続する場合（データベースと同じ場所に配置しない場合）、コマンド「database cluster certs <client.key> <client.crt> <ca.crt> 」を実行します。

6a.新しいノードを結合する必要がある場合(データベースと同じ場所に配置する場合)は、次のコマンドを実行します。'database cluster join <primary node IP>'

6b.新しいノードを接続する必要がある場合（データベースと同じ場所に配置する必要がない場合）は、次のコマンドを実行します：'database cluster connect <primary node IP>'

停止する必要があるXシリーズごとに、ステップ9bと11を繰り返します。

ステップ12：この時点で、新しいCMSサーバにはデータベースのコピーが作成されます。接続されている場合は、データベースノードへの到達方法を認識しており、以前と同じIPアドレスを持っています。

ステップ13：配置でロードバランシングが有効になっていますか。

Loadbalancing=Trueで設定されたAPI上のCallBridgeGroupsでCMSコールロードバランシングを使用する場合は、環境内の新しいサーバの推奨制限に一致するようにロード制限を変更する必要があります。  api/v1/system/configuration/clusterに移動し、それに応じてloadlimitを更新します。

システム	推奨される負荷制限
CMS1000 M5v2	120000
CMS1000 M4またはM5v1	96000
CMS2000 M5v2	875000
CMS2000	700000
VM（vCPU数x 1250）	例：70 vCPU x 1250 = 87500

ステップ14：この作業が完了する前にXMPPクラスタがあり、しばらくの間CMS 2.9.xに留まる場合は、XMPPクラスタを再構築する必要があります。

MMPコマンド	例
すべてのXMPPノードでの設定	すべてのXMPPノードでの設定
1. xmpp reset	1. xmpp reset
2.xmpp domain <ドメイン名>	2.xmpp domain example.com
を選択します。xmpp listen <interface whitelist>	を選択します。xmpp listen a
4.xmpp certs <keyfile> <certificate file> <cert-bundle>	4.xmpp certs xmpcluster.key xmpcluster.cer root.cer
5.xmpp cluster trust <xmpp cert>	5.xmpp cluster trust xmpp cluster.cer ***注1
第1ノードの設定	第1ノードの設定
6.xmpp enable	6 xmpp enable
7.xmpp callbridge add <callbridge name>	7.xmpp callbridge add cb1
8.xmpp callbridge add <callbridge name>	8.xmpp callbridge add cb2
9.xmpp callbridge add <callbridge name>	9.xmpp callbridge add cb3
10. xmpp callbridge add <callbridge name>	10. xmpp callbridge add cb4*** Note 2
11. xmpp callbridge list	11. xmpp callbridge list < – この出力をメモ帳にコピーします
12. xmpp disable	12. xmpp disable
13. xmpp cluster enable	13. xmpp cluster enable
14. xmppクラスタの初期化	14. xmppクラスタの初期化
15. xmpp enable	15. xmpp enable
16. xmppクラスタステータス	16. xmppクラスタステータス
第2および第3ノードの設定	第2および第3ノードの設定
17. xmpp enable	17. xmpp enable
18. xmpp callbridge add-secret <callbridge name>	18. xmpp callbridge add-secret cb1
19. callbridge secret:	19. callbridge secret:<メモ帳からcb1の秘密をコピー>
20. xmpp callbridge add-secret <callbridge name>	20. xmpp callbridge add-secret cb2
21. callbridge secret:	21. callbridge secret:<メモ帳からcb2の秘密をコピー>
22. xmpp callbridge add-secret <callbridge name>	22. xmpp callbridge add-secret cb3
23. callbridge secret:	23:callbridge secret:<メモ帳からcb3の秘密をコピー>
24. xmpp callbridge add-secret <callbridge name>	24. xmpp callbridge add-secret cb4 ***注3
25. callbridge secret:	25. callbridge secret:<メモ帳からcb4のシークレットをコピー>
26. xmpp disable	26. xmpp disable
27. xmpp cluster enable	27. xmpp cluster enable
28. xmpp enable	28. xmpp enable
29. xmpp cluster join <cluster>	29. xmpp cluster join <ノード1のIPアドレスまたはFQDN>
Web AdminでのXMPP設定の構成	Web AdminでのXMPP設定の構成
CallBridgeサービスを使用する各サーバ	CallBridgeサービスを使用する各サーバ
30.上記で設定したcallbridgeの一意の名前を入力します	30. callbridge1などにcb1と入力します。
31.ドメインの入力	31. domain:example.com
32.メモ帳からシークレットを入力します	32.対応するcallbridgeの秘密をメモ帳から入力します
33.認証のためのwebadmin statusページの確認	33.認証のためのwebadmin statusページの確認

注 1：例のxmppクラスタ信頼は、サブジェクト代替名(SAN)属性にすべてのXMPPサーバFQDNが含まれているか、ワイルドカード証明書であるため、XMPP証明書です。  各XMPPサーバに独自の証明書がある場合は、それらを結合し、xmppクラスタの信頼として追加する必要があります。

注 2：xmpp callbridge add cb4  この手順を例として、xmppサーバよりも多くのcallbridgeを使用できます。  この手順は必要ありませんが、例として追加されています。

注 3：xmpp callbridge ad-secret cb4  この手順をノート2に追加しました。  4つのcallbridgeがある場合は、すべての4をxmppクラスタ内のすべてのノードに追加する必要があります。

CMS 2.9.xバージョンを使用している場合は、テストと検証を今すぐ開始して、新しいサーバが期待どおりに動作することを確認できます。

確認

新しいサーバへの移行後、すべてのユーザとスペースが表示され、SIPコールが引き続き機能することを確認します。  CMS 2.9.xバージョンを使用している場合は、XMPPが引き続き動作していることを確認します（WebRTCユーザは引き続き参加/サインインでき、レコーダは接続できます）。  CMSと通信中のサーバが機能していることを確認します(Cisco Meeting Manager(CMM)、Cisco Unified Communications Manager(CUCM)、TelePresence Management Suite(TMS)、Expressway)。  また、MMPで「syslog follow」を実行して、対処が必要なエラーがあるかどうかを確認することをお勧めします。 

トラブルシュート

問題が発生した場合は、Xシリーズサーバに戻るか、Cisco TACにサポートを依頼してください。