はじめに
このドキュメントでは、Cisco Meeting Server(CMS)またはAcano Call Bridge(CB)でデータベース(DB)クラスタリングを設定する手順について説明します。
前提条件
要件
- 実行可能なDBクラスタを作成するには、少なくとも3つのCMSノードを用意することをお勧めします
注:プライマリの選択とアクティブなフェールオーバーメカニズムにとって重要なので、DBクラスタノードの数は奇数にすることを推奨します。 もう1つの理由は、プライマリDBノードがクラスタ内のほとんどのDBへの接続を持つノードであることです。1つのデータベースクラスタに参加できるのは3つのノードだけです。database cluster connectコマンドを使用して、このクラスタにサーバを追加することもできます。
注:DBクラスタのプライマリノードは、レプリカノードからの接続をポート5432でリッスンするため、ノード間にファイアウォール(FW)がある場合は、このポートが開いていることを確認してください。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
設定
DBクラスタリングには、次の2種類の証明書があります。
1. クライアント:クライアント証明書は、名前が示すように、DBクライアントがDBサーバ(プライマリ)に接続するために使用します。 この証明書のCommon Name(CN;共通名)フィールドには、文字列postgresが含まれている必要があります。
2. サーバ:サーバ証明書は、名前が示すように、DBサーバがpostgres DBに接続するために使用します。
パート1:証明書の作成
1. 管理者クレデンシャルを使用して、セキュアシェル(SSH)でサーバMMPに接続します。
2. 証明書署名要求(CSR)を生成します。
a. databaseclusterクライアント証明書の場合
pki csr <key/cert basename> CN:postgres
例:pki csr databasecluster_client CN:postgres
b. databaseclusterサーバ証明書の場合:
pki csr <key/cert basename> CN:<domainname>
例:pki csr databasecluster_server CN:vngtpres.aca
3. CSRを認証局(CA)に送信し、署名を依頼します。CAがルートCA(および中間CA)証明書を提供することを確認します。
4. 署名付き証明書、ルートCA(および中間CA)証明書を、Secure File Transfer Protocol(SFTP)クライアント(WinSCPなど)を使用してすべてのDBノードにアップロードします。
注:パートAのCNはpostgresである必要があり、パートBはCall Bridgeのドメイン名にすることができます。サブジェクト代替名(SAN)エントリは必要ありません。
パート2:Call Bridgeの設定
プライマリDBを実行するCBで、次の手順を実行します。
1. 使用するインターフェイスを選択するには、次のコマンドを入力します。
database cluster localnode a
これにより、インターフェイス「a」をDBクラスタリングに使用できます。
2. 次のコマンドを使用して、クライアント、サーバ、ルートCA証明書、およびDBクラスタで使用される秘密鍵を定義します。
database cluster certs <client_key> <client_crt> <ca_crt>
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>
注:秘密キーと証明書を他のノードにコピーする際、クラスタ化される他のCBノードで同じクライアント証明書とサーバ証明書を使用できます。これが可能なのは、証明書を特定のCall Bridgeに結び付けるSANが証明書に含まれていないためです。ただし、DBノードごとに個別の証明書を用意することをお勧めします。
3. ローカルCB上のこのDBを、このDBクラスタのプライマリとして初期化します。
database cluster initialize
4. クラスタ化されたDBの一部となり、DBレプリカになるCallBridgeで、パート2のステップ1と2を完了した後で、次のコマンドを実行します。
database cluster join <プライマリCB IPアドレス>
例:database cluster join <10.48.36.61>

これにより、DBの同期が開始され、プライマリピアからDBがコピーされます。
注:database cluster joinコマンドよりも前に存在していたローカルDBは上書きされるため、その内容は削除されます。
ネットワーク図

確認
このセクションでは、設定が正常に動作していることを確認します。
クラスタ化されたDBのステータスを確認するには、DBクラスタ内の任意のノードで次のコマンドを実行します。
database cluster status
出力は次のようになります。
Status : Enabled
Nodes:
10.48.36.61 : Connected Primary
10.48.36.118 : Connected Replica ( In Sync )
10.48.36.182 (me) : Connected Replica ( In Sync )
Node in use : 10.48.36.61
Interface : a
Certificates
Server Key : dbclusterserver.key
Server Certificate : dbclusterserver.cer
Client Key : dbclusterclient.key
Client Certificate : dbclusterclient.cer
CA Certificate : vngtpRootca.cer
Last command : 'database cluster join 10.48.36.61' (Success)
トラブルシュート
ここでは、設定のトラブルシューティングに使用できる情報を示します。
CLIで次のコマンドを使用して、DBクラスタリングに関連する現在のログを表示します。
syslog follow
DBのログ出力には通常、postgres文字列が含まれています。例は次のとおりです。
Mar 30 12:39:04 local0.warning ClusterCore1 postgres[20882]: [2-7] #011SQL statement "INSERT INTO domains(domain_id, domain_name, tenant_id, target, priority, passcode_separator) VALUES (inp_domain_id, inp_domain_name, inp_tenant_id, existing_target, inp_priority, inp_passcode_separator)"
Mar 30 12:39:04 local0.warning ClusterCore1 postgres[20882]: [2-8] #011PL/pgSQL function create_or_update_matching_domain(boolean,uuid,text,boolean,uuid,integer,integer,integer,text) line 61 at SQL statement
Mar 30 12:39:04 local0.warning ClusterCore1 postgres[20882]: [2-9] #011SQL statement "SELECT * FROM create_or_update_matching_domain(TRUE, inp_domain_id, inp_domain_name, TRUE, inp_tenant_id, inp_target_true, 0, inp_priority, inp_passcode_separator)"
Mar 30 12:39:04 local0.warning ClusterCore1 postgres[20882]: [2-10] #011PL/pgSQL function create_matching_domain(uuid,text,uuid,integer,integer,text) line 3 at SQL statement
一般的なDBの問題と解決策の一部を次に示します。
問題:非プライマリピアのDBスキーマエラー
ERROR : Couldn't upgrade the schema
Status : Error
Nodes:
10.48.54.75 : Connected Primary
10.48.54.76 : Connected Replica ( In Sync )
10.48.54.119 (me) : Connected Replica ( In Sync )
Node in use : 10.48.54.75
Interface : a
Certificates
Server Key : dbclusterServer.key
Server Certificate : dbserver.cer
Client Key : dbclusterClient.key
Client Certificate : dbclient.cer
CA Certificate : Root.cer
Last command : 'database cluster upgrade_schema' (Failed)
ソリューション:
1. まず、次のコマンドを実行してエラーをクリアします。
database cluster clear error
2. 続いて、DBスキーマをアップグレードするために次のコマンドを実行します。
database cluster upgrade_schema
3. 次に、DBクラスタリングのステータスを次のように確認します。
database cluster status
ログには次のような出力が表示されます。
Mar 30 11:22:45 user.notice acanosrv05 schema_builder: Upgrading schema with connect line 'connect_timeout=4 user=postgres host=127.0.0.1 port=9899 sslmode=verify-ca sslcert=/srv/pgsql/client.crt sslkey=/srv/pgsql/client.key sslrootcert=/srv/pgsql/ca.crt '
Mar 30 11:22:45 user.notice acanosrv05 schema_builder: Using database name 'cluster'
Mar 30 11:22:45 user.notice acanosrv05 schema_builder: schema build on database cluster complete
Mar 30 11:22:45 user.notice acanosrv05 schema_builder: Using CiscoSSL 1.0.1u.4.13.322-fips (caps 0x4FABFFFF)
Mar 30 11:22:45 user.notice acanosrv05 schema_builder: Using 0x1000115F
Mar 30 11:22:45 user.notice acanosrv05 schema_builder: INFO : Waiting for database cluster to settle...
Mar 30 11:22:45 user.notice acanosrv05 schema_builder: INFO : Database cluster settled
Mar 30 11:22:45 user.notice acanosrv05 schema_builder: Schema upgrade complete
Mar 30 11:22:45 user.info acanosrv05 dbcluster_watcher: Operation Complete
問題:ピアノードがDBプライマリノードに接続できない
Mar 31 10:16:59 user.info acanosrv02 sfpool: Health check 10.48.54.119: error (up = 1): could not connect to server: Connection refused|#011Is the server running on host "10.48.54.119" and accepting|#011TCP/IP connections on port 5432?|
ソリューション:
次の手順を使用して、トレースを収集して接続の問題のトラブルシューティングをします。
1. 非プライマリ(レプリカ)ノードでpcap <interface>コマンドを実行し、数分後に、Ctrl-Cでキャプチャを停止します。
2. セキュアファイル転送プロトコル(SFTP)クライアントを使用してサーバに接続し、ルートディレクトリから.pcapファイルをダウンロードします。

3. Wiresharkでキャプチャファイルを開き、tcp.port==5432を使用してポート5432でフィルタリングを行い、非プライマリピアとDBプライマリとの間のトラフィックを確認します。
4. サーバからのリターントラフィックがない場合、FWが2つのサーバの論理的な場所の間のポートをブロックしている可能性があります。
次に、クライアントとサーバ間の正常な接続からの典型的なパケット キャプチャを示します。
この例では、クライアントIPは10.48.54.119で、サーバは10.48.54.75です。

関連情報
データベースクラスタリングに関する問題のトラブルシューティング方法やその他の質問については、次のリンクのFAQを参照してください。