Cisco Unity Connection クラスタ コンフィギュレーション アドミニストレーション ガイド Release 7.x
Cisco Unity Connection クラスタに ついて
Cisco Unity Connection クラスタについて
発行日;2012/02/06 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 319KB) | フィードバック

目次

Cisco Unity Connection クラスタについて

でのクラスタ機能の動作

パブリッシャ サーバについて

クラスタ内のサーバ ステータスの機能

ボイス メッセージ ポートのサーバ割り当てと使用方法

クラスタの要件

サーバ ステータス変更時の進行中のコールへの影響

サーバ ステータス変更時の Web アプリケーションへの影響

サーバ上の重要なサービスの停止の影響

「スプリット ブレイン」状態の影響

サーバ ステータス変更時のイベント

プライマリ ステータスのサーバによって行われるサーバ ステータスの自動変更

セカンダリ ステータスのサーバによって行われるサーバ ステータスの自動変更

管理者によって行われるサーバ ステータスの手動変更

Cisco Unity Connection でのクラスタ機能の動作

Cisco Unity Connection クラスタ機能では、クラスタ内に設定されている 2 台の Connection サーバを介して、ハイ アベイラビリティ ボイス メッセージを提供します。通常では、これらの Connection サーバは両方ともアクティブになっています。したがって、次のことが可能になります。

クラスタには、これらの Connection サーバで共有される DNS 名を割り当てることができます。

クライアント(Cisco Personal Communications Assistant や電子メール アプリケーションなど)は、どちらか一方の Connection サーバに接続できます。

電話システムは、どちらか一方の Connection サーバにコールを送信できます。

着信電話トラフィックの負荷は、電話システム、PIMG/TIMG ユニット、または電話システム統合に必要なその他のゲートウェイによって、これらの Connection サーバ間で分散されます。

クラスタ内の各サーバは、クラスタに対するボイス メッセージ機能(電話コールへの応答、メッセージの録音、メッセージ通知の送信、および MWI 要求の送信)の処理を分担しています。一方のサーバがホームとなり、データベースとメッセージ ストアをパブリッシュします。これらのデータベースとメッセージ ストアは両方とも、もう一方のサーバにレプリケートされます。

一方のサーバが機能を停止した場合(たとえば、メンテナンスのためにシャットダウンされた場合)、もう一方のサーバが、クラスタに対するボイス メッセージ機能のすべてを処理する役割を担います。また、このサーバはデータベースとメッセージ ストアの役割も担います。停止していたサーバの接続と機能が復元したときに、これらのデータベースとメッセージ ストアは両方とも、復元したサーバにレプリケートされます。

機能を停止したサーバは、その通常のボイス メッセージ機能を再開できるようになってアクティベートされると、クラスタに対するボイス メッセージ機能の分担を再開します。

サーバのステータスを監視するために、両方のサーバの Cisco Unity Connection Serviceability で Connection Server Role Manager サービスが動作します。このサービスは次の機能を実行します。

サーバ ステータスに応じて、各サーバ上で適切なサービスを起動する。

重要なプロセス(ボイス メッセージの処理、データベース レプリケーション、メッセージ ストア レプリケーションなど)が正常に機能しているかどうかを判別する。

プライマリ ステータスのサーバが機能していない場合、または重要なサービスが動作していない場合、サーバ ステータスの変更を行う。

パブリッシャ サーバについて

クラスタ内に設定されている最初の Cisco Unity Connection サーバは、パブリッシャ サーバです。パブリッシャ サーバは、Cisco Unity Connection Serviceability の[Cluster Management]ページで識別されます。

クラスタが正常に機能している場合、パブリッシャ サーバはデータベースとメッセージ ストアをパブリッシュする役割を担います。

パブリッシャ サーバがプライマリ ステータスになっていない場合(たとえば、管理者がもう一方のサーバのステータスを手動でプライマリに変更したため、パブリッシャ サーバのステータスが自動的にセカンダリに変更された場合)、もう一方のサーバがデータベースとメッセージ ストアをパブリッシュする役割を担います。

パブリッシャ サーバは、クラスタから削除できません。

クラスタ内のサーバ ステータスの機能

クラスタ内の各サーバには、Cisco Unity Connection Serviceability の[Cluster Management]ページに表示されるステータスが設定されています。ステータスは、クラスタ内でサーバが現在実行している機能を示しています( 表3-1 を参照)。

 

表3-1 Cisco Unity Connection クラスタ内のサーバ ステータスの機能

サーバ ステータス
Connection クラスタ内の機能

Primary(プライマリ)

データベースとメッセージ ストアをパブリッシュします。これらのデータベースとメッセージ ストアは両方とも、クラスタ内のもう一方のサーバにレプリケートされます。

もう一方のサーバからレプリケート データを受信します(そのサーバのデータを共有できる場合)。

管理インターフェイス(Connection の管理など)に変更内容を表示し、受け入れます。このデータは、クラスタ内のもう一方のサーバにレプリケートされます。

ボイス メッセージ機能(電話コールへの応答、メッセージの録音、メッセージ通知の送信、および MWI 要求の送信)を実行します。

クライアント(Cisco Personal Communications Assistant や電子メール アプリケーションなど)に接続します。

クラスタが正常に機能している場合、パブリッシャ サーバはプライマリ ステータスになっています。


) プライマリ ステータスのサーバをデアクティベートすることはできません。


Secondary(セカンダリ)

プライマリ ステータスのサーバからレプリケート データを受信します。データには、データベースとメッセージ ストアが含まれます。

プライマリ ステータスのサーバにデータをレプリケートします。

管理インターフェイス(Connection の管理など)に変更内容を表示し、受け入れます。プライマリ ステータスのサーバにデータがレプリケートされます。

ボイス メッセージ機能(電話コールへの応答、メッセージの録音、メッセージ通知の送信、および MWI 要求の送信)を実行します。

クライアント(Cisco Personal Communications Assistant や電子メール アプリケーションなど)に接続します。


) セカンダリ ステータスのサーバだけをデアクティベートすることができます。


Deactivated(デアクティベート)

プライマリ ステータスのサーバからレプリケート データを受信します。データには、データベースとメッセージ ストアが含まれます。

管理インターフェイス(Connection の管理など)に変更内容を表示し、受け入れます。プライマリ ステータスのサーバにデータがレプリケートされます。

ボイス メッセージ機能を実行しません。

Not Functioning(機能停止)

プライマリ ステータスのサーバからレプリケート データを受信しません。

プライマリ ステータスのサーバにデータをレプリケートしません。

管理インターフェイス(Connection の管理など)を表示しません。

ボイス メッセージ機能を実行しません。


) 通常、機能停止ステータスのサーバはシャットダウンされています。


Starting(起動中)

プライマリ ステータスのサーバからレプリケート データを受信します。データには、データベースとメッセージ ストアが含まれます。

プライマリ ステータスのサーバにデータをレプリケートします。

ボイス メッセージ機能を実行しません。

Replicating Data(データ レプリケート中)

クラスタからデータを送受信します。

一時的にボイス メッセージ機能を実行しません。

一時的にクライアント(Cisco Personal Communications Assistant や電子メール アプリケーションなど)に接続しません。


) このステータスは数秒間続きます。その後、以前のサーバ ステータスに戻ります。


Split Brain Recovery(スプリット ブレイン リカバリ)

2 台のサーバがプライマリ ステータスになっていることを検出した場合 、パブリッシャ サーバにプライマリ ステータスを割り当てます。

プライマリ ステータスを割り当てたサーバのデータベースとメッセージ ストアを更新します。

もう一方のサーバにデータをレプリケートします。

一時的にボイス メッセージ機能を実行しません。

一時的にクライアント(Cisco Personal Communications Assistant や電子メール アプリケーションなど)に接続しません。


) このステータスは数秒間続きます。その後、以前のサーバ ステータスに戻ります。


ボイス メッセージ ポートのサーバ割り当てと使用方法

Cisco Unity Connection クラスタ内のサーバは、同一の電話システム統合を共有します。各サーバは、クラスタに対するボイス メッセージ機能(電話コールへの応答、メッセージの録音、メッセージ通知の送信、および MWI 要求の送信)の処理を分担しています。

電話システム統合に応じて、各ボイス メッセージ ポートは特定のサーバに割り当てられるか、または両方のサーバによって使用されます。 表3-2 で、ポート割り当てについて説明します。

 

表3-2 Cisco Unity Connection クラスタでのボイス メッセージ ポートのサーバ割り当てと使用方法

統合タイプ
ボイス メッセージ ポートのサーバ割り当てと使用方法

Skinny Client Control Protocol(SCCP)による Cisco Unified Communications Manager または Cisco Unified Communications Manager Express との統合

電話システムにセットアップされる SCCP ボイスメール ポート デバイスの数は、ボイス メッセージ トラフィックの処理に必要な数の 2 倍になります(たとえば、すべてのボイス メッセージ トラフィックの処理に 16 個のボイスメール ポート デバイスが必要な場合、32 個のボイスメール ポート デバイスを電話システムにセットアップする必要があります)。

Cisco Unity Connection の管理では、電話システムにセットアップされるポートの半数がクラスタ内の各サーバに割り当てられるように、ボイス メッセージ ポートが設定されます(たとえば、クラスタ内の各サーバには 16 個のボイス メッセージ ポートが割り当てられます)。

電話システムでは、クラスタ内の両方のサーバにコールを均一に分散するように、回線グループ、ハント リスト、およびハント グループが設定されます。

一方のサーバが機能を停止した場合(たとえば、メンテナンスのためにシャットダウンされた場合)、もう一方のサーバが、クラスタに対するボイス メッセージ機能の役割を担います。

機能を停止したサーバがその通常のボイス メッセージ機能を再開できるようになると、両方のサーバは、クラスタに対するボイス メッセージ機能のそれぞれの分担を再開します。

SIP トランクを介した Cisco Unified Communications Manager または Cisco Unified Communications Manager Express との統合

Cisco Unity Connection の管理では、ボイス メッセージ トラフィックの処理に必要なボイス メッセージ ポートの半数がクラスタ内の各サーバに割り当てられます(たとえば、クラスタへのすべてのボイス メッセージ トラフィックの処理に 16 個のボイス メッセージ ポートが必要な場合、クラスタ内の各サーバには 8 個のボイス メッセージ ポートが割り当てられます)。

電話システムでは、クラスタ内の両方のサーバにコールを均一に分散するように、ルート グループ、ルート リスト、およびルート パターンが設定されます。

一方のサーバが機能を停止した場合(たとえば、メンテナンスのためにシャットダウンされた場合)、もう一方のサーバが、クラスタに対するボイス メッセージ機能の役割を担います。

機能を停止したサーバがその通常のボイス メッセージ機能を再開できるようになると、両方のサーバは、クラスタに対するボイス メッセージ機能のそれぞれの分担を再開します。

PIMG/TIMG ユニットを介した統合

電話システムにセットアップされるポートの数は、クラスタ内の各サーバのボイス メッセージ ポートの数と同じです。したがって、すべてのボイス メッセージ ポートはサーバ間で共有されます(たとえば、電話システムに 16 個のボイス メッセージ ポートがセットアップされる場合、クラスタ内の各サーバにも 16 個のボイス メッセージ ポートが割り当てられます)。

電話システムでは、クラスタ内の両方のサーバにコールを均一に分散するように、ハント グループが設定されます。

サーバ間でボイス メッセージ トラフィックの負荷を分散するように、PIMG/TIMG ユニットが設定されます。

一方のサーバが機能を停止した場合(たとえば、メンテナンスのためにシャットダウンされた場合)、もう一方のサーバが、クラスタに対するボイス メッセージ機能の役割を担います。

機能を停止したサーバがその通常のボイス メッセージ機能を再開できるようになると、両方のサーバは、クラスタに対するボイス メッセージ機能のそれぞれの分担を再開します。

SIP を使用するその他の統合

Cisco Unity Connection の管理では、ボイス メッセージ トラフィックの処理に必要なボイス メッセージ ポートの半数がクラスタ内の各サーバに割り当てられます(たとえば、クラスタへのすべてのボイス メッセージ トラフィックの処理に 16 個のボイス メッセージ ポートが必要な場合、クラスタ内の各サーバには 8 個のボイス メッセージ ポートが割り当てられます)。

電話システムでは、クラスタ内の両方のサーバにコールを均一に分散するように、ハント グループが設定されます。

一方のサーバが機能を停止した場合(たとえば、メンテナンスのためにシャットダウンされた場合)、もう一方のサーバが、クラスタに対するボイス メッセージ機能の役割を担います。

機能を停止したサーバがその通常のボイス メッセージ機能を再開できるようになると、両方のサーバは、クラスタに対するボイス メッセージ機能のそれぞれの分担を再開します。

Cisco Unity Connection クラスタの要件

最新の Cisco Unity Connection クラスタの要件については、『 Cisco Unity Connection システム要件 Release 7.x 』を参照してください。このドキュメントは、
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/7x/requirements/7xcucsysreqs.html から入手可能です

サーバ ステータス変更時の進行中のコールへの影響

Cisco Unity Connection サーバのステータスが変更された場合、進行中のコールへの影響は、コールを処理しているサーバの最終的なステータスとネットワークの状態によって異なります。 表3-3 で、これらの影響について説明します。

 

表3-3 サーバ ステータス変更時の進行中のコールへの影響

ステータス変更
影響

Primary(プライマリ)から Secondary(セカンダリ)へ

ステータス変更が手動で行われた場合、進行中のコールは影響を受けません。

ステータス変更が自動的に行われた場合、進行中のコールへの影響は、停止した重要なサービスによって異なります。

Secondary(セカンダリ)から Primary(プライマリ)へ

ステータス変更が手動で行われた場合、進行中のコールは影響を受けません。

ステータス変更が自動的に行われた場合、進行中のコールへの影響は、停止した重要なサービスによって異なります。

Secondary(セカンダリ)から Deactivated(デアクティベート)へ

進行中のコールは切断されます。

コールが切断されないようにするには、Cisco Unity Connection Serviceability の[Cluster Management]ページで、サーバに対応する[Stop Taking Calls]をクリックし、すべてのコールが終了するまで待ってからサーバをデアクティベートします。

Primary(プライマリ)または Secondary(セカンダリ)から
Replicating Data(データ レプリケート中)へ

進行中のコールは影響を受けません。

Primary(プライマリ)または Secondary(セカンダリ)から
Split Brain Recovery(スプリット ブレイン リカバリ)へ

進行中のコールは影響を受けません。

ネットワーク接続が失われた場合、ネットワークの問題の性質によっては、進行中のコールが切断されることがあります。

サーバ ステータス変更時の Cisco Unity Connection Web アプリケーションへの影響

サーバ ステータスが変更されても、次に示す Web アプリケーションの通常機能は影響を受けません。

Cisco Unity Connection の管理

Cisco Unity Connection Serviceability

Cisco Personal Communications Assistant を介してアクセスされる Cisco Unity Connection Web ツール(Cisco Unity Assistant、Cisco Unity Inbox、および Cisco Unity パーソナル着信転送ルール Web ツール)

サーバ上の重要なサービスの停止の影響

重要なサービスは、Cisco Unity Connection システムの通常機能に必要です。重要なサービスの停止の影響は、サーバのステータスによって異なります。 表3-4 で、これらの影響について説明します。

 

表3-4 サーバ上の重要なサービスの停止の影響

サーバ ステータス
影響

Primary(プライマリ)

Cisco Unity Connection Serviceability で重要なサービスを停止すると、サーバ ステータスがセカンダリに変更されます。ボイス メッセージ機能を処理するサーバの能力が低下します。

もう一方のサーバのステータスがプライマリに変更されます(そのサーバが無効ステータスまたは機能停止ステータスになっていない場合)。

Secondary(セカンダリ)

Cisco Unity Connection Serviceability で重要なサービスを停止すると、ボイス メッセージ機能を処理するサーバの能力が低下します。もう一方のサーバのステータスと機能は変更されません。

「スプリット ブレイン」状態の影響

Cisco Unity Connection クラスタ内のサーバが同時にプライマリ ステータスになっている場合(たとえば、サーバ間の接続が失われている場合)、両方のサーバがボイス メッセージ機能(電話コールへの応答、メッセージの録音、メッセージ通知の送信、および MWI 要求の送信)を実行し、管理インターフェイス(Connection の管理など)の変更内容を受け入れます。ただし、これらのサーバの間では、データベースとメッセージ ストアのレプリケートもレプリケート データの受信も行われません。

サーバ間の接続が復元したときに、サーバのステータスは一時的にスプリット ブレイン リカバリに変更されます。このステータスになっている間に、データがサーバ間でレプリケートされ、MWI 設定が調整されます。リカバリ プロセスが完了すると、パブリッシャ サーバがプライマリ ステータスになり、もう一方のサーバがセカンダリ ステータスになります。

サーバ ステータス変更時のイベント

この項では、次の状況でサーバ ステータスが変更されたときに発生するイベントについて説明します。

「プライマリ ステータスのサーバによって行われるサーバ ステータスの自動変更」

「セカンダリ ステータスのサーバによって行われるサーバ ステータスの自動変更」

「管理者によって行われるサーバ ステータスの手動変更」

プライマリ ステータスのサーバによって行われるサーバ ステータスの自動変更

1. プライマリ ステータスのサーバ上の Connection Server Role Manager サービスが、修復不能な障害(たとえば、データベースの障害や重要なサービスの停止など)を検出します。

2. プライマリ ステータスのサーバ上の Connection Server Role Manager サービスが、もう一方のサーバ上の Connection Server Role Manager サービスに対して、そのサーバのステータスを変更するように通知します。

3. 両方のサーバ上の Connection Server Role Manager サービスが、ステータスの変更中であることを示すアラームを出します。

4. 可能な場合は、プライマリ ステータスのサーバ上の Connection Server Role Manager サービスが、データベース内のステータスを更新します。

5. プライマリ ステータスのサーバ上の Connection Server Role Manager サービスが、データベース内のステータスをセカンダリに設定します。

6. もう一方のサーバ(最初はセカンダリ ステータスだったサーバ)上の Connection Server Role Manager サービスが、データベース内のステータスをプライマリに設定します。

7. 現在プライマリ ステータスになっているサーバ上の Connection Server Role Manager サービスが、そのサーバ上で重要なサービスを起動します。

8. データ コネクタが、変更されたサーバ ステータスを検出し、現在プライマリ ステータスになっているサーバ上のデータベースを使用するように接続を設定します。

9. 可能な場合は、サーバ間でデータベースとメッセージ ストアのレプリケーションが続行します。

10. 現在プライマリ ステータスになっているサーバ上の Connection Server Role Manager サービスが、ステータスの変更が完了したことを示すアラームを出します。

セカンダリ ステータスのサーバによって行われるサーバ ステータスの自動変更

1. セカンダリ ステータスのサーバ上の Connection Server Role Manager サービスは、プライマリ ステータスのサーバ上の Connection Server Role Manager サービスから通知を受信しません。

2. セカンダリ ステータスのサーバ上の Connection Server Role Manager サービスが、そのネットワーク接続を確認するために、ローカル ホストおよびその他の既知のリモート サーバに ping を実行します。

3. ネットワーク接続が確認された場合は、セカンダリ ステータスのサーバ上の Connection Server Role Manager サービスが、ステータスの変更中であることを示すアラームを出します。

ネットワーク接続が使用できない場合は、ステータスが変更されず、以降のイベントも発生しません。

4. セカンダリ ステータスのサーバ上の Connection Server Role Manager サービスが、データベース内のステータスをプライマリに設定します。

5. 現在プライマリ ステータスになっているサーバ上の Connection Server Role Manager サービスが、そのサーバ上で重要なサービスを起動します。

6. データ コネクタが、変更されたステータスを検出し、現在プライマリ ステータスになっているサーバ上のデータベースを使用するように接続を設定します。

7. 可能な場合は、サーバ間でデータベースとメッセージ ストアのレプリケーションが続行します。

8. 現在プライマリ ステータスになっているサーバ上の Connection Server Role Manager サービスが、ステータスの変更が完了したことを示すアラームを出します。

管理者によって行われるサーバ ステータスの手動変更

1. Cisco Unity Connection Serviceability で、管理者がサーバ ステータスの変更を手動で行います。

2. セカンダリ ステータスのサーバ上の Connection Server Role Manager サービスが、プライマリ ステータスのサーバ上の Connection Server Role Manager サービスに対して、ステータスの変更を行うように通知します。

3. 両方のサーバ上の Connection Server Role Manager サービスが、ステータスの変更中であることを示すアラームを出します。

4. 可能な場合は、プライマリ ステータスのサーバ上の Connection Server Role Manager サービスが、データベース内のステータスを更新します。

5. プライマリ ステータスのサーバ上の Connection Server Role Manager サービスが、データベース内のステータスをセカンダリに設定します。

6. もう一方のサーバ(最初はセカンダリ ステータスだったサーバ)上の Connection Server Role Manager サービスが、データベース内のステータスをプライマリに設定します。

7. 現在プライマリ ステータスになっているサーバ上の Connection Server Role Manager サービスが、そのサーバ上で重要なサービスを起動します。

8. データ コネクタが、変更されたステータスを検出し、現在プライマリ ステータスになっているサーバ上のデータベースを使用するように接続を設定します。

9. サーバ間でデータベースとファイルのレプリケーションが続行します。

10. 現在プライマリ ステータスになっているサーバ上の Connection Server Role Manager サービスが、ステータスの変更が完了したことを示すアラームを出します。