UCCEアウトバウンドオプションのハイアベイラビリティの設定とトラブルシューティング：クイックリファレンス

ダウンロード オプション

  • PDF     (1.6 MB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (1.3 MB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (841.4 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2019 年 7 月 30 日
Document ID:214104

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

概要

このドキュメントでは、Cisco Unified Contact Center Enterprise(UCCE)Outbound Option High Availability(OOHA)の設定とトラブルシューティングの方法について説明します。

前提条件

要件

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

  • UCCEアウトバウンドオプション
  • Microsoft SQLトランザクションレプリケーション

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

  • Cisco UCCE 11.6
  • MS SQL Server 2014

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

背景説明

アーキテクチャ

アウトバウンドオプションのハイアベイラビリティ(OOHA)機能は、UCCE 11.6バージョンで導入されました。OOHAはオプション機能です。UCCE 11.6バージョンのCampaign Managerプロセスは、Active-StandByフェールオーバーモデルと冗長化できます。WebSetupでOOHAが有効になっている場合、システムはBA_AデータベースとBA_Bデータベース間でSQL双方向のトランザクション複製をします。

次のテーブルが複製されます。

  • 設定
  • Dialing_List
  • PCB
  • Do_Not_Call

UCCE 11.6 OOHAアーキテクチャ

  

フェールオーバーモデルの概要

キャンペーンマネージャのアクティブ – スタンバイ

  • デフォルトで60秒を超えるダイヤラ接続がない場合、Active Campaign Managerプロセスはフェールオーバーを開始します。このタイマーは、Logger/BlendedAgent/CurrentVersion/レジストリパスの下にdword EMTClientTimeoutToFailoverを追加することで変更できます。この値は、ダイヤラ接続の待機時間（秒）である必要があります。
  • Campaign Managerのプロセスは、ダイヤラがこれらとの接続を確立できない場合は、AからBへのバウンスを継続し、その逆も継続します。
  • BAデータベース間に巨大なレプリケーションキューがある場合、Campaign Managerのフェールオーバーには最大4,5分かかります。4,5分はハードコードされたタイマーであり、変更できません。

Dialers Active - StandBy

  • 以前のバージョンからの変更はありません。ダイヤラフェールオーバーモデルは同じままであり、一度に1つのダイヤラだけがアクティブです。

BaImport – フェールオーバーなし

  • BaImportはローカルのCampaign Managerプロセスでのみ動作し、そのステータスを複製します。BaImportプロセスがクラッシュした場合、Campaign Managerレベルでのフェールオーバーがトリガーされます。

  

設定

予備手順

ステップ1:SQL Server Replication機能が有効になっていることを確認します。

  • SQLのインストール中に、機能としてのレプリケーションを選択する必要があります。ロガーサーバでレプリケーション機能が有効になっていることを確認するには、[SQL disk drive > setup.exe] > [Tools]に移動して、[Installed SQL Discovery Report]を実行します
  • レポートに機能がリストされていない場合は、Windows CMDツールでこのコマンドを実行し、それぞれのコマンドパラメータにSQL Serverインスタンス名を指定します
setup.exe /q /Features=Replication /InstanceName= 
       /ACTION=INSTALL /IAcceptSQLServerLicenseTerms

ステップ2:SQL Serverユーザアカウントが設定されていることを確認します。

  • ユーザ名とパスワードは、ロガー側Aとロガー側Bで同じである必要があります。
  • ユーザは、SQL Server System Admin権限を持っている必要があります。
  • このユーザ名とパスワードは、WebSetupを実行してアウトバウンドオプションを設定し、アウトバウンドオプションのハイアベイラビリティを有効にするときに使用します。
  • ユーザーはSQL saユーザーである必要はありません。これは別のユーザである可能性がありますが、sysadmin権限が必要であり、有効なままです。

        

ステップ3:SQLユーザNT AUTHORITY\SYSTEMにはsysadminロールが必要です。 

ステップ4：ロガーサーバのホスト名とSQL Serverサーバ名(@@サーバ名)は同じである必要があります。

新規インストール構成

ステップ1：両方のロガーサーバでBAデータベースを作成します。

ステップ2：両方のロガーでsysadminロールを持つ同じローカルSQLユーザを設定します。

ステップ3：ロガーAでWebSetupを起動し、ロガーコンポーネントを編集し、アウトバウンドオプションとアウトバウンドハイアベイラビリティを有効にします。

注：[ロガーのパブリックインターフェイス]フィールドにロガーのホスト名を指定してください。この値は、それぞれのロガーのSQLサーバ名と一致する必要があります。

WebSetupが正常に完了したら、「Publication created」と「LoggerA SQL server」が表示され、LoggerBに「Subscribation」が表示されます。

SQL Server Management Studio (SSMS)からLoggerAのReplication > Local PublicationsとLoggerBのLocal Subsciptionsの下をチェックします。

LoggerBでWebSetupを実行し、Loggerコンポーネントを編集し、Outbound OptionとOutbound High Availabilityを有効にします。

LoggerBとLoggerAのサブスクリプションでパブリケーションを作成する必要があります。 

次の図は、LoggerBサーバで作成されたパブリケーションとサブスクリプションを示しています。

この図は、LoggerAサーバで作成されたパブリケーションとサブスクリプションを示しています。

  

トラブルシュート

SQLレプリケーションのヘルスチェック

レプリケーションの状態を確認するには、[SSMSからレプリケーションモニタツールを起動する]を選択します。

レプリケーションのステータスはOKである必要があります。

パブリッシャを展開して、パフォーマンスと遅延に関する詳細情報を取得します。

2番目のタブ[トレーサー・トークン]に移動し、[トレーサの挿入]を選択します。これにより、パブリッシャとディストリビュータ間、およびディストリビュータとサブスクライバ間の遅延がテストされます。

これは両方のロガーで確認する必要があります。

SQLサーバー名の変更 

SSMSを開き、このSQLクエリを実行します。

SELECT @@servername

クエリーの出力をWindowsサーバのホスト名と比較します。一致する必要があります。

この図は、LoggerAのホスト名とSQLサーバ名が一致しない場合の問題シナリオを示しています。OO 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レプリケーションを手動で有効にする

注意：この手順は、WebSetupがレプリケーションを確立できず、エラーが明確でない場合にのみ使用してください。

このストアドプロシージャは、それぞれの変数値を持つ両方のロガーのBAデータベースに対して実行します。

EXEC sp_ba_create_replication 
@instance= 
      ,
@publisher= 
      ,
@subscriber= 
      ,
@working_directory = 
      ,
@login = 
      ,
@pwd =

「CREATE DATABASE failed」というエラーが発生した場合は、MSSQLSERVERアカウントにSQL作業ディレクトリへの完全なアクセス権があるかどうかを確認します。

次の図は、SQL Serverログの各エラーを示しています。 

MSSQLSERVERアカウントがSQL作業ディレクトリに完全にアクセスできることを確認します。

各ロガーSQLサーバでパブリケーションとサブスクリプションが作成されていることを確認します。

   

SQLレプリケーションを手動で無効にする

注意：この手順は、WebSetupがレプリケーションを確立できず、エラーが明確でない場合にのみ使用してください。

この手順は、それぞれの変数値を持つ両方のロガーの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 there are databases enabled for replication on the server」というエラーメッセージが表示されることがあります。

EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1

関連情報

TAC Authored

シスコ エンジニア提供

  • Aleksey Yankovskyy
    Cisco TAC Engineer

このドキュメントは役に立ちましたか?

Feedbackフィードバック

シスコに問い合わせ

このドキュメントは次の製品に対応しています