UCCEアウトバウンドオプションのハイアベイラビリティの設定およびトラブルシューティング：クイックリファレンス
内容
はじめに
このドキュメントでは、Cisco Unified Contact Center Enterprise(UCCE)Outbound Option High Availability(OOHA)を設定およびトラブルシューティングする方法について説明します。
前提条件
要 件
次の項目に関する知識があることが推奨されます。
- UCCEアウトバウンドオプション
- Microsoft SQLトランザクションレプリケーション
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Cisco UCCE 11.6
- MS SQL Server 2014
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
バックグラウンド情報
アーキテクチャ
Outbound Option High-Availability(OOHA)機能は、UCCE 11.6バージョンで導入されました。 OOHAはオプションの機能です。UCCE 11.6バージョンから、Campaign ManagerプロセスはActive-StandByフェールオーバーモデルで冗長化できます。 WebSetupでOOHAを有効にすると、BA_AデータベースとBA_Bデータベース間のSQL双方向トランザクションレプリケーションが自動的に実行されます。
次のテーブルが複製されます。
- 連絡先
- ダイヤル一覧
- プリント基板
- コールしない(_N)
UCCE 11.6 OOHAアーキテクチャ
フェールオーバーモデルの概要
キャンペーンマネージャアクティブ – スタンバイ
- デフォルトでダイヤラ接続が60秒以上存在しない場合、Active Campaign Managerプロセスがフェールオーバーを開始します。このタイマーは、Logger/BlendedAgent/CurrentVersion/レジストリパスの下で、dword EMTClientTimeoutToFailoverを追加することで変更できます。この値は、ダイヤラ接続の待機時間（秒単位）である必要があります。
- ダイヤラがAからBへの接続を確立できない場合、Campaign ManagerプロセスはAからBへのバウンスを継続し、逆も同様です。
- BAデータベース間に膨大なレプリケーションキューがある場合、Campaign Managerのフェールオーバーに最大4.5分かかることがあります。4.5分はハードコードされたタイマーであり、変更できません。
ダイヤラアクティブ – スタンバイ
- 以前のバージョンからの変更はありません。ダイヤラフェールオーバーモデルは同じままで、同時に1つのダイヤラだけがアクティブになります。
BaImport – フェールオーバーなし
- BaImportはローカルのCampaign Managerプロセスでのみ動作し、そのステータスを複製します。BaImportプロセスがクラッシュすると、Campaign Managerレベルのフェールオーバーがトリガーされます。
設定
準備手順
ステップ 1：SQL Serverレプリケーション機能が有効になっていることを確認します。
- SQLのインストール中に、機能としてレプリケーションを選択する必要があります。ロガーサーバでレプリケーション機能を有効にするには、SQLディスクドライブ> setup.exe > Toolsの順に移動し、インストール済みSQL検出レポートのレポートを実行します。
- レポートに機能が表示されない場合は、Windows CMDツールでこのコマンドを実行し、それぞれのコマンドパラメーターにSQL Serverインスタンス名を指定します
setup.exe /q /Features=Replication /InstanceName=/ACTION=INSTALL /IAcceptSQLServerLicenseTerms
ステップ 2SQL Serverユーザーアカウントが構成されていることを確認してください。
- ユーザ名とパスワードは、ロガーサイドAとロガーサイドBで同じにする必要があります。
- ユーザはSQL Serverのシステム管理者権限を持っている必要があります。
- このユーザ名とパスワードは、WebSetupを実行してOutbound Optionを設定し、Outbound Option High Availabilityを有効にするときに使用します。
- ユーザがSQLのsaユーザである必要はありません。別のユーザでも構いませんが、sysadmin権限が必要で、有効のままになっています。
ステップ 3SQLユーザーNT AUTHORITY\SYSTEMにはsysadminロールが必要です。
ステップ 4ロガーサーバのホスト名(@@servername)とSQLサーバのサーバ名(@@servername)は同じである必要があります。
新しいインストール構成
ステップ 1：両方のロガーサーバでBAデータベースを作成します。
ステップ 2両方のロガーでsysadminロールを持つ同じローカルSQLユーザを設定します。
ステップ 3LoggerAでWebSetupを起動し、Logger Componentを編集して、Outbound OptionとOutbound High Availabilityを有効にします。
WebSetupが正常に完了した後、「Publication created and LoggerA SQL server and Subscribation on LoggerB」が表示されます。
SQL Server Management Studio(SSMS)で、LoggerAのReplication > Local Publicationsの順に選択し、LoggerBのLocal Subscriptionsを選択して、このファイルを確認します。
LoggerBでWebSetupを実行し、Loggerコンポーネントを編集して、Outbound OptionとOutbound High Availabilityを有効にします。
パブリケーションはLoggerBで作成し、サブスクリプションはLoggerAで作成する必要があります。
この図は、LoggerBサーバで作成されたパブリケーションとサブスクリプションを示しています。
この図は、LoggerAサーバで作成されたパブリケーションとサブスクリプションを示しています。
トラブルシュート
SQLレプリケーションの正常性チェック
Launch Replication Monitor Tool from SSMSを選択して、レプリケーションステータスを確認します。
レプリケーションの状態はOKである必要があります。
パブリッシャを展開すると、パフォーマンスと遅延の詳細が表示されます。
2番目のタブTracer Tokensに移動し、Insert Tracerを選択します。これにより、パブリッシャとディストリビュータの間、およびディストリビュータとサブスクライバの間の遅延がテストされます。
両方のロガーでこのチェックボックスをオンにする必要があります。
SQLサーバー名の変更
SSMSを開き、このSQLクエリを実行します。
SELECT @@servername
クエリの出力をWindowsサーバのホスト名と比較します。これらは一致する必要があります。
次の図は、LoggerAのホスト名とSQLサーバ名が一致しない場合の問題のシナリオを示しています。OOO HAセットアップの前に必ず修正してください。
SQLサーバ名を削除するには、マスターDBに対してSSMSでこのコマンドを実行します。
EXEC sp_dropserver @server=
新しいSQLサーバ名を追加するには、次のコマンドを実行します。
EXEC sp_addserver @server=, @local=LOCAL
Windows ServicesからSQL serverとSQL Server Agentを再起動し、select @@servername SQLクエリの出力を確認します。
SQLレプリケーションを手動で有効にする
それぞれの変数値を使用して、両方のロガーのBAデータベースに対してこのストアドプロシージャを実行します。
EXEC sp_ba_create_replication @instance=, @publisher= , @subscriber= , @working_directory = , @login = , @pwd =
「CREATE DATABASE failed」というエラーが発生した場合は、MSSQLSERVERアカウントにSQL作業ディレクトリへのフルアクセスがあるかどうかを確認します。
次の図は、SQLサーバのログの各エラーを示しています。
MSSQLSERVERアカウントにSQL作業ディレクトリへのフルアクセス権があることを確認します。
各ロガーSQLサーバでパブリケーションとサブスクリプションが作成されていることを確認します。
SQLレプリケーションを手動で無効にする
両方のロガーのBAデータベースに対して、それぞれの変数値を指定してこの手順を実行します。
EXEC sp_ba_remove_replication @instance =, @subscriber =
両方のロガーSQLサーバからパブリケーションが削除されているかどうかを確認します。
レプリケーション構成からSQLサーバーを完全にクリアするには、手動でサブスクリプションを削除し、両方のロガーSQLサーバーでディストリビューションデータベースを削除する必要があります。
USE master EXEC sp_dropdistpublisher @publisher=; EXEC sp_dropdistributiondb @database=distribution; EXEC sp_dropdistributor; GO
場合によっては、最後のコマンドが「Cannot drop server name as Distributor Publisher because that server on replication enabled」というエラーメッセージで失敗することがあります。
EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1
関連情報
- UCCE 11.6アウトバウンドオプションガイド
- UCCE 11.6設計ガイド：アウトバウンドオプションのハイアベイラビリティの考慮事項
- SQLトランザクションレプリケーションリファレンス
- テクニカル サポートとドキュメント – Cisco Systems
フィードバック