内容

概要

前提条件

要件

使用するコンポーネント

設定

パート 1：証明書の作成

パート 2：Call Bridge 設定

ネットワーク図

確認

トラブルシュート

関連情報

概要

このドキュメントでは、Cisco Meeting Server(CMS)またはAcanoコールブリッジ(CB)でデータベース(DB)クラスタリングを設定する手順について説明します。

前提条件

要件

- 実行可能なDBクラスタを作成できるCMSノードが少なくとも3つあることを推奨します

注：マスター選択とアクティブなフェールオーバーメカニズムでは重要であるため、DBクラスタノードの数を奇数にすることをお勧めします。別の理由は、マスターDBノードがクラスタ内のDBの大部分に接続しているノードであることです。DBクラスタには最大5ノードを設定できます。

- ファイアウォールでポート5432が開いている

注:DBクラスタマスターは、クライアントノードからの接続をポート5432でリッスンします。したがって、ノード間にファイアウォール(FW)がある場合は、このポートが開いていることを確認してください。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

設定

DBクラスタリングの証明書には、次の2つのタイプがあります。

1.クライアント：クライアント証明書は、名前が示すように、DBクライアントがDBサーバ（マスター）に接続するために使用されます。 この証明書の[Common Name (CN)]フィールドには、文字列postgresが含まれている必要があります。

2.サーバー：サーバ証明書は、名前が示すように、DBサーバがpostgres DBに接続するために使用されます。

パート 1：証明書の作成

1.サーバMMPに管理者クレデンシャルを使用してセキュアシェル(SSH)で接続します。

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:<ドメイン名>

例：pki csr databasecluster_server CN:vngtpres.aca

3. CSRを証明書の認証(CA)に送信して、署名させます。CAがルートCA（および任意の中間CA）証明書を提供することを確認します。

4.セキュアファイル転送プロトコル(SFTP)クライアント（WinSCPなど）を使用して、署名付き証明書、ルートCA（および中間CA）証明書をすべてのDBノードにアップロードします。

注：パートAのCNはpostgresで、パートBはコールブリッジのドメイン名である必要があります。サブジェクト代替名(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ノードで同じクライアント証明書とサーバ証明書を使用できます。これは、証明書に特定のコールブリッジに関連付けられるSANが含まれていないために可能です。ただし、DBノードごとに個別の証明書を設定することをお勧めします。

3.ローカルCBでこのDBを、このDBクラスタのマスターとして初期化します。

database cluster initialize

4.クラスタ化されたDBに属し、DBスレーブになるCallBridgeで、パート2の手順1と2を完了した後に、次のコマンドを実行します。

database cluster join <Master CB IP address>

以下に、いくつかの例を示します。database cluster join <10.48.36.61>

これにより、DB同期が開始され、マスターピアからDBがコピーされます。

注：database cluster joinコマンドが開始される前に存在していたローカルDBは、ノードがクラスタ化されたDBから削除されるまで存在し続けます。したがって、ノードが db クラスタにある限り、そのローカル db は使用されません。

ネットワーク図

確認

ここでは、設定が正常に機能しているかどうかを確認します。

クラスタ化されたDBのステータスを確認するには、DBクラスタ内のいずれかのノードで次のコマンドを実行します。

database cluster status

出力は次のようになります。

Status                   : Enabled

Nodes:

10.48.36.61          : Connected Master

10.48.36.118         : Connected Slave ( In Sync )

10.48.36.182 (me)    : Connected Slave ( 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 DBMaster 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 DBMaster 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 DBMaster 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 DBMaster postgres[20882]:  [2-10] #011PL/pgSQL function create_matching_domain(uuid,text,uuid,integer,integer,text) line 3 at SQL statement

CMSログコレクタを使用すると、CMSサーバからログを収集するための使いやすいユーザインターフェイス(UI)が提供されます。

一般的なDBの問題と解決策を次に示します。

問題：マスターピア以外のDBスキーマエラー

ERROR                    : Couldn't upgrade the schema

Status                   : Error

Nodes:

10.48.54.75          : Connected Master

10.48.54.76          : Connected Slave ( In Sync )

10.48.54.119 (me)    : Connected Slave ( 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.  Secure File Transfer Protocol(SFTP)クライアントを使用してサーバに接続し、ルートディレクトリから.pcapファイルをダウンロードします。

3. Wiresharkでキャプチャファイルを開き、tcp.port==5432を使用してポート5432をフィルタし、非マスターピアとDBマスター間のトラフィックを確認します。

4.サーバからのリターントラフィックがない場合、FWが2台のサーバの論理的な場所の間のポートをブロックしている可能性があります。

次に、クライアントとサーバ間の正常な接続からの典型的なパケット キャプチャを示します。

この例では、クライアントの IP は 10.48.54.119 であり、サーバは 10.48.54.75 です。

関連情報

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

- データベースサーバをクラスタリングする場合、異なる場所に配置する必要があるのはなぜですか。

- データベースクラスタがあり、ログにデータベースエラーまたは警告が表示されます。何をすべきか

- 1つ以上のデータベースサーバーが接続されていないか、"同期"状態です。何をすべきか

- マスタデータベースがない場合の対処方法

- マスターデータベースを移動する方法

- テクニカル サポートとドキュメント – Cisco Systems