この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Cisco Unity Connection クラスタの設定
Cisco Unity Connection クラスタ展開は、同じバージョンの Unity Connection を実行している 2 台のサーバを通して高可用性ボイス メッセージングを提供します。クラスタ内の最初のサーバがパブリッシャ サーバで、2 番目のサーバがサブスクライバ サーバです。
Unity Connection クラスタを作成するには、次のタスクを実行します。
Cisco Unity Connection クラスタの要件を収集します。詳細については、https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/11x/requirements/b_11xcucsysreqs.html で、『System Requirements for Cisco Unity Connection Release 11.x』を参照してください。
パブリッシャ サーバをインストールします。詳細については、「パブリッシャ サーバのインストール」の項を参照してください。
サブスクライバ サーバをインストールします。詳細については、「サブスクライバ サーバのインストール」の項を参照してください。
パブリッシャ サーバとサブスクライバ サーバの両方の Cisco Unified Real-Time Monitoring Tool を、次の Unity Connection アラートに関する通知を送信するように設定します。
Unity Connection アラートに関するアラート通知のセットアップ手順については、http://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-maintenance-guides-list.html で、必要なリリースの『Cisco Unified Real-Time Monitoring Tool Administration Guide』の「Cisco Unified Real-Time Monitoring Tool」を参照してください。
(任意)パブリッシャ サーバ上のクラスタ設定をカスタマイズするには、次のタスクを実行します。
Cisco Unity Connection Administration にサインインします。
[システム設定(System Settings)] > [詳細設定(Advanced)] を展開し、[クラスタ設定(Cluster Configuration)] を選択します。
[クラスタ設定(Cluster Configuration)] ページで、サーバ ステータスを変更し、[保存(Save)] を選択します。クラスタ内のサーバ ステータスの変更方法については、[ヘルプ(Help)] > [このページ(This Page)] を参照してください。
(注) | クラスタ設定は、Cisco Unified Communications Manager Business Edition 5000 ではサポートされません。 |
クラスタが正しく設定され、正常に動作していることを確認するために Unity Connection クラスタのステータスをチェックする必要があります。クラスタ内のさまざまなサーバのステータスとクラスタ内でサーバのステータスが変化した場合の影響を理解しておくことも重要です。
Web インターフェイスまたはコマンドライン インターフェイス(CLI)を使用して、Unity Connection クラスタ ステータスを確認することができます。
Web インターフェイスから Unity Connection クラスタ ステータスを確認する手順
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | パブリッシャ サーバまたはサブスクライバ サーバの Cisco Unity Connection Serviceability にサインインします。 | |
ステップ 2 | [ツール(Tools)] を展開して、[クラスタ管理(Cluster Management)] を選択します。 | |
ステップ 3 | [クラスタ管理(Cluster Management)] ページで、サーバ ステータスをチェックします。サーバ ステータスの詳細については、「Unity Connection クラスタ内のサーバ ステータスと機能」の項を参照してください。 |
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | パブリッシャ サーバまたはサブスクライバ サーバで show cuc cluster status CLI コマンドを実行して、クラスタ ステータスをチェックすることができます。 | |
ステップ 2 | サーバのステータスと関連機能の詳細については、「Unity Connection クラスタ内のサーバ ステータスと機能」の項を参照してください。 |
Unity Connection クラスタでは、すべてのサーバが同じ電話システム統合を共有します。各サーバは、クラスタの着信コールの担当分を処理します(電話への応答とメッセージの受け付け)。
電話システムの統合に基づいて、各ボイスメッセージング ポートは特定のサーバに割り当てられるか、両方のサーバで使用されます。表 4-1 で、ポート割り当てについて説明します。
サーバのすべてのポートで新規コールに応答しないようにするには、この項の手順を実行します。進行中のコールは、発信者が電話を切るまで切断されません。
ヒント | Real-Time Monitoring Tool(RTMT)の [ポート モニタ(Port Monitor)] ページを使用して、現在ポートでサーバのコールを処理しているかどうかを確認します。詳細については、ステップ a を参照してください。 Unity Connection サーバの全ポートでの新規コールへの応答停止 |
Unity Connection サーバ上のすべてのポートを停止後に再起動して再びコールへの応答を許可するには、この項の手順に従います。
クラスタ内の各サーバのステータスは、Cisco Unity Connection Serviceability の [クラスタ管理(Cluster Management)] ページに表示されます。表 4-2 に記載されているように、ステータスはサーバが現在クラスタ内で実行している機能を示します。
Unity Connection クラスタのステータスは、自動または手動で変更できます。
クラスタ内のサーバのステータスは、次のように手動で変更できます。
[セカンダリ(Secondary)] ステータスのサーバは、手動で [プライマリ(Primary)] ステータスに変更できます。「セカンダリからプライマリへのサーバ ステータスの手動変更」の項を参照してください。
[セカンダリ(Secondary)] ステータスのサーバは、手動で [非アクティブ化(Deactivated)] ステータスに変更できます。「非アクティブ ステータスのサーバの手動アクティブ化」を参照してください。
[非アクティブ化(Deactivated)] ステータスのサーバを手動でアクティブ化し、他のサーバのステータスに応じて、ステータスを [プライマリ(Primary)] または [セカンダリ(Secondary)] に変更できます。「非アクティブ ステータスのサーバの手動アクティブ化」の項を参照してください。
ステップ 1 | Cisco Unity Connection Serviceability にサインインします。 | ||
ステップ 2 | [ツール(Tools)] メニューから [クラスタ管理(Cluster Management)] を選択します。 | ||
ステップ 3 | [クラスタ管理(Cluster Management)] ページの [Server Manager] メニューで、セカンダリ ステータスのサーバの [サーバ ステータスの変更(Change Server Status)] 列の [プライマリにする(Make Primary)] を選択します。 | ||
ステップ 4 | サーバ ステータスの変更の確認を求められたら、[OK] を選択します。
変更が完了すると、[サーバ ステータス(Server Status)] カラムに変更されたステータスが表示されます。
|
ステップ 1 | Real-Time Monitoring Tool(RTMT)にサインインします。 |
ステップ 2 | [Cisco Unity Connection] メニューから、[ポート モニタ(Port Monitor)] を選択します。右側のペインに [ポート モニタ(Port Monitor)] ツールが表示されます。 |
ステップ 3 | [ノード(Node)] フィールドで、[セカンダリ(Secondary)] ステータスのサーバを選択します。 |
ステップ 4 | 右側のペインで [ポーリングの開始(Start Polling)] を選択します。ボイス メッセージ ポートがサーバのコールを処理中でないかどうか確認します。 |
ステップ 5 | Cisco Unity Connection Serviceability にサインインします。 |
ステップ 6 | [ツール(Tools)] メニューから [クラスタ管理(Cluster Management)] を選択します。 |
ステップ 7 | ボイス メッセージイング ポートがサーバのコールを処理していない場合は、ステップ 8 に進みます。
現在サーバのコールを処理しているボイス メッセージング ポートが存在する場合は、[クラスタ管理(Cluster Management)] ページの [ポート ステータスの変更(Change Port Status)] 列で、サーバの [電話に応答しない(Stop Taking Calls)] を選択してから、サーバのすべてのポートがアイドル状態であることが RTMT に表示されるまで待機します。 |
ステップ 8 | [クラスタ管理(Cluster Management)] ページの [Server Manager] メニューで、セカンダリ ステータスのサーバの [サーバ ステータスの変更(Change Server Status)] 列の [非アクティブ化(Deactivate)] を選択します。 |
ステップ 9 | サーバ ステータスの変更の確認を求められたら、[OK] を選択します。 |
1. Cisco Unity Connection Serviceability にサインインします。
2. [ツール(Tools)] メニューから [クラスタ管理(Cluster Management)] を選択します。
3. [クラスタ管理(Cluster Management)] ページの [Server Manager] メニューで、非アクティブ ステータスのサーバの [サーバ ステータスの変更(Change Server Status)] 列の [アクティブ化(Activate)] を選択します。
ステップ 1 | Cisco Unity Connection Serviceability にサインインします。 |
ステップ 2 | [ツール(Tools)] メニューから [クラスタ管理(Cluster Management)] を選択します。 |
ステップ 3 | [クラスタ管理(Cluster Management)] ページの [Server Manager] メニューで、非アクティブ ステータスのサーバの [サーバ ステータスの変更(Change Server Status)] 列の [アクティブ化(Activate)] を選択します。 |
ステップ 4 | サーバ ステータスの変更の確認を求められたら、[OK] を選択します。 |
Unity Connection サーバのステータスが変化したときの進行中のコールに対する影響は、コールを処理しているサーバの最終的なステータスとネットワークの状態によって異なります。次の表で、その影響について説明します。
コールのドロップを防ぐには、Cisco Unity Connection Serviceability の [クラスタ管理(Cluster Management)] ページで、サーバの [コールへの応答の停止(Stop Taking Calls)] を選択し、すべてのコールが終了するまで待機してからサーバを非アクティブにします。 |
|
Unity Connection システムを正しく機能させるためには、重要なサービスが必要です。重要なサービスを停止した場合の影響は、次の表に記載されているサーバとそのステータスによって異なります。
|
|
サーバがプライマリ ステータスのときに、Cisco Unity Connection Serviceability で重要なサービスが停止すると、サーバの正常に機能する能力が低下します。サーバのステータスは変化しません。 |
Unity Connection サーバのステータスがプライマリまたはセカンダリの場合は、そのサーバがボイス メッセージング トラフィックとクラスタ データ レプリケーションを処理します。進行中のコールとレプリケーションが突然中断されるのを避けるために、クラスタ内の両方のサーバを同時にシャットダウンしないことをお勧めします。
ステップ 1 | シャットダウンしないサーバで、Cisco Unity Connection Serviceability にサインインします。 |
ステップ 2 | [ツール(Tools)] メニューから [クラスタ管理(Cluster Management)] を選択します。 |
ステップ 3 | [クラスタ管理(Cluster Management)] ページで、シャットダウンするサーバを選択します。 |
ステップ 4 | シャットダウンするサーバのステータスがセカンダリの場合は、ステップ 5 に進みます。 |
ステップ 5 | セカンダリ ステータスのサーバ(シャットダウンするサーバ)で、ステータスを変更します。 |
ステップ 6 | 非アクティブ化したサーバをシャットダウンします。 |
クラスタ内のパブリッシャ サーバまたはサブスクライバ サーバを交換するには、次の項の手順を実行します。
パブリッシャ サーバを交換するには、「パブリッシャ サーバの交換」の項を参照してください。
サブスクライバ サーバを交換するには、「サブスクライバ サーバの交換」の項を参照してください。
クラスタの詳細について
Unity Connection クラスタ機能は、クラスタ内で設定された 2 台の Unity Connection サーバを介してハイアベイラビリティ ボイス メッセージングを提供します。
両方のサーバがアクティブなときの Unity Connection クラスタの動作:
電子メール アプリケーションや Cisco Personal Communications Assistant(PCA)経由で使用可能な Web ツールなどのクライアントは、Unity Connection サーバのどちらかに接続できます。
着信電話トラフィックの負荷は、電話システム、PIMG/TIMG ユニット、または電話システムの統合に必要なその他のゲートウェイによって、Unity Connection サーバ間で分散されます。
クラスタ内の各サーバは、クラスタの着信コールの担当分を処理します(電話への応答とメッセージの受け取り)。[プライマリ(Primary)] ステータスのサーバは、次の機能を実行します。
SMTP 通知および VPIM メッセージの送信(Connection メッセージ転送エージェント サービスのアクティブ化)。
ユニファイド メッセージング機能が設定されている(Unity Connection Mailbox Sync サービスがアクティブになっている)場合の Unity Connection メールボックスと Exchange メールボックス間のボイス メッセージの同期。
一方のサーバが機能を停止すると(メンテナンスのためのシャットダウンなど)、もう一方のサーバがクラスタに対するすべての着信コールの処理を再開します。機能が復元されると、データベースとメッセージ ストアがもう一方のサーバにレプリケートされます。
機能を停止したサーバが通常の機能を再開し、アクティブ化されると、クラスタに対する着信コールの共有の処理を再開します。
(注) | クラスタのフェールオーバーが発生したら、アクティブ-アクティブ モードのパブリッシャ サーバとサブスクライバ(プライマリとして機能)上でのみプロビジョニングを実行することをお勧めします。ユーザ PIN/Web アプリケーションのパスワードの変更とパスワード設定の変更は、アクティブ-アクティブ モードのパブリッシャ サーバでプロビジョニングする必要があります。 |
サーバ ステータスをモニタするために、両方のサーバ上の Cisco Unity Connection Serviceability で Connection Server Role Manager サービスが動作します。このサービスは次の機能を実行します。
重要なプロセス(ボイスメッセージの処理、データベースのレプリケーション、ボイスメッセージの Exchange との同期、メッセージ ストアのレプリケーションなど)が正常に動作しているかを判断します。
[プライマリ(Primary)] ステータスのサーバが機能していないか重要なサービスが動作していない場合に、サーバ ステータスの変更を開始します。
パブリッシャ サーバが機能していない場合、次の制約があります。
Unity Connection クラスタが LDAP ディレクトリと統合されている場合は、ディレクトリ同期が発生しません。ただし、サブスクライバ サーバだけでも稼働していれば、認証は引き続き機能します。パブリッシャ サーバが機能を再開すると、ディレクトリ同期も再開されます。
デジタルまたは HTTPS ネットワークに Unity Connection クラスタが含まれている場合は、ディレクトリ更新が発生しません。ただし、サブスクライバ サーバだけでも稼働していれば、クラスタとのメッセージの送受信が継続されます。パブリッシャ サーバが再び正常に機能すると、ディレクトリの更新が再開されます。
Connection サーバ ロール マネージャ サービスは、パブリッシャ サーバとサブスクライバ サーバ間でキープアライブ イベントを送信し、サーバが機能し、接続していることを確認します。一方のサーバが機能を停止するか、サーバ間の接続が失われると、Connection サーバ ロール マネージャ サービスはキープアライブ イベントを待機します。相手のサーバが利用できないことを検出するまで 30 ~ 60 秒かかることがあります。Connection Server Role Manager サービスがキープアライブ イベントを待機している間は、プライマリ ステータスのサーバ(アクティブ メッセージ ストアを備えている)が利用できないことがまだ検出されていないため、セカンダリ ステータスのサーバにサインインしているユーザはメールボックスにアクセスできないか、メッセージを送信できません。この状況では、メッセージを残そうとしても、無音状態になったり、録音のビープ音が聞こえなかったりします。
(注) | パブリッシャ ノードのみから LDAP ユーザをインポートし、削除することを推奨します。 |
Unity Connection クラスタ内の両方のサーバが同時にプライマリ ステータスになった場合(サーバ間の相互接続が失われた場合など)は、両方のサーバが着信コールの処理(電話への応答とメッセージの受け取り)、メッセージ通知の送信、MWI 要求の送信、管理インターフェイス(Unity Connection Administration など)への変更の受け入れ、およびシングル インボックスがオンになっている場合の Unity Connection メールボックスと Exchange メールボックス内のボイス メッセージの同期を処理します。ただし、互いにデータベースとメッセージ ストアのレプリケートは実行せず、レプリケート データも受信しません。
サーバ間の接続が復元されると、サーバ間でデータをレプリケートし、MWI 設定を調整している間、サーバのステータスは一時的に [スプリット ブレーン リカバリ(Split Brain Recovery)] に変化します。サーバのステータスがスプリット ブレーン リカバリの間は、両方のサーバで Connection Message Transfer Agent サービスと Connection Notifier サービス(Cisco Unity Connection Serviceability 内)が停止するため、Unity Connection はメッセージの配信およびメッセージ通知の送信を行いません。Connection Mailbox Sync サービスも停止するため、Unity Connection は Exchange とボイス メッセージを同期しません(シングル インボックス)。メッセージ ストアも短時間だけマウント解除されるため、Unity Connection は、この時点でメッセージを取得しようとしているユーザに、メールボックスが一時的に使用できないことを伝えます。
リカバリ プロセスが完了すると、Connection メッセージ転送エージェント サービスと Connection Notifier サービスがパブリッシャ サーバで起動します。配信されるメッセージの数によっては、リカバリ プロセス中に到達したメッセージの配信にさらに時間がかかることがあります。Connection メッセージ転送エージェント サービスと Connection Notifier サービスがサブスクライバ サーバで起動します。最後に、パブリッシャ サーバのステータスが [プライマリ(Primary)]、サブスクライバ サーバのステータスが [セカンダリ(Secondary)] になります。この時点で、Connection Mailbox Sync サービスがプライマリ ステータスのサーバで起動するため、シングル インボックスがオンの場合に、Unity Connection が Exchange とのボイス メッセージの同期を再開できます。