概要

シングル サイト展開モデルでは、PSTN コール ルーティングのローカル ゲートウェイとともに、強化されたサバイバビリティ ノード（ESN）がサイト内に展開されます。 停止中に ESN に最大 7500 デバイスを登録できます。

複数サイト展開モデルでは、複数のサイトがあり、各サイトに展開できる ESN は、サイトのサバイバビリティに関するビジネス要件によって異なります。 ローカル ゲートウェイと DNS の要件は常に必要であり、合計 8 個の ESN ノードを Unified CM クラスタに追加できます。

この展開モデルは、複数のサイトを持つ地域全体の顧客に関連しており、それらのサイトの複数のサバイバビリティが要求されます。 PSTN ローカル ゲートウェイをサイト間で共有することは可能ですが、推奨されません。ネットワークが停止した場合、サイトは隔離され、その場合は、ESN は PSTN にコールをルーティングするためにローカル ゲートウェイに到達できません。

以下は、複数サイト展開の 2 つの展開オプションです。

• オプション1： 各サイトで展開された強化されたサバイバビリティ ノード。

• オプション 2 – 複数のサイト間で共有される共通強化サバイバビリティ ノード。

専用インスタンス データセンターに展開されている他のノードと同様に、強化されたサバイバビリティ ノードを監視および管理します。 サバイバビリティ イベント中に、ESN が Cisco Cloud から切断されると、ノードへのアクセスを失い、停止が解決され、接続が復元されたときに自動的に接続されます。

UC アプリケーション証明書を管理し、強化されたサバイバビリティ ノードのアクティベーション中に、専用インスタンス Unified CM クラスタ証明書が ESN で更新されたことを更新しました。

Control Hub からの ESN のアクティベーション中に、Unified CM クラスタの証明書がマルチ SAN 証明書で更新されるため、すべての登録済みデバイスが再起動されます。 したがって、Control Hub からの ESN のアクティベーション中のメンテナンス期間を計画します。 詳細は、「How to Activate Enhanced Survivability Node」を参照してください。

サバイバビリティ イベント中に、強化されたサバイバビリティ ノードは、すべての CDR/CMR データをローカルに保存します。 接続が復元されると、データは専用インスタンス Unified CM Publisher に同期されます。 保存できるデータの量は、拡張サバイバビリティ ノードのディスク サイズに基づいています。 CDR に設定できる最大ディスク割り当て領域は3328 MB です。 これは、設定された CDR 間隔に基づいて、小さな CDR ファイルサイズから大きくすることができます。 パージは、以下に基づいて行われます。

• ディスク使用率が割り当てられたまたは設定されたディスク領域を超えると、処理されたレコードが削除されます。 ディスク使用率がそれ以上になる場合は、未処理のレコードも消去されます。

• 「CDR管理」設定で設定されている高水マーク% は、CDRファイルが消去されます。 たとえば 、 「 High Water Mark%” is configured as 80% 」とディスク使用率が80%の場合、CDRファイルは消去されます。

• CDR / CMRファイルの保存 「CDR管理」設定で設定されている期間(日) 、CDRファイルは消去されます。 デフォルトでは 30 日に設定されています。

以下は、強化されたサバイバビリティ ノードに関連する RTMT のアラートです。

• SurvivabilityEvent- すべての専用インスタンス ノードが拡張サバイバビリティ ノードから到達できない場合、アラームがトリガーされます。

• RemoteSurvivableNodeNotReachable - 強化されたサバイバビリティ ノードが専用インスタンス Unified CM パブリッシャーから到達できない場合、アラームがトリガーされます。

サバイバビリティ イベント中に、ESN のパフォーマンスをモニタするには、RTMT を拡張サバイバビリティ ノードに接続する必要があります。 サバイバビリティ イベント中に ESN がクラウドから到達できないため、RTMT が専用インスタンス ノードに接続されている場合も同様です。

通常の操作では、データベース レプリケーションは、Unified CM クラスタ内の Enhanced Survivability Node を含むすべてのサーバ間で完全にメッシュ化されます。 静的構成データは、移動、追加、変更によって作成されるため、常にパブリッシャに保存され、パブリッシャから各サブスクライバ、およびクラスタ内の強化されたサバイバビリティ ノードに 1 つの方法で複製されます。

サバイバビリティ イベント中に、強化されたサバイバビリティ ノードに登録されているデバイスでユーザー向け機能のみが変更され、ユーザー向け機能は、通常、Web ベースの GUI で機能を変更するのとは対照的に、1 つ以上のボタンを押すことで電話機で直接機能を有効または無効にできるという事実を使用して特徴付けられます。 そのため、強化されたサバイバビリティ ノードでは、セルフケアと Web 管理 GUI が読み取り専用操作として許可されます。 ESN に登録されているユーザーのデバイスは、フェールオーバー中に以下にリストされているユーザーに面する機能のみを変更できます。 ただし、接続が再確立されると、これらの変更は DI Unified CM パブリッシャーに同期されません。

ユーザー向け機能は、電話機のボタンを押して有効または無効にできる機能で、次の機能が含まれます。

• 不在転送（CFA）

• プライバシーを有効または無効にする

• サイレント（DND）の有効化または無効化

• Cisco Extension Mobility ログイン

• ハント グループのログインまたはログアウト

• デバイス モビリティ

• エンド ユーザとアプリケーション ユーザの CTI CAPF ステータス。

強化されたサバイバビリティ ノードへのフェールオーバー中にログインするためのソフト クライアント (Cisco Jabber および Webex アプリケーション) の認証は次のとおりです。

1. ローカル認証: Unified CM 内でユーザーの認証がローカルで行われる場合、サバイバビリティ イベント中に、拡張サバイバビリティ ノードはそれに登録されたクライアントを認証できます。

2. LDAP 認証: この場合、ユーザの認証はローカル LDAP サーバを使用して行われます。 その後、サバイバビリティ イベント中に、LDAP サーバが強化されたサバイバビリティ ノードから到達可能であれば、ソフト クライアントの認証が機能します。

   サバイバビリティ イベント全体を通して、LDAP ディレクトリが ESN に到達可能であることを確認する必要があります。

3. シングル サインオン (SSO) 認証: ユーザーの SSO ログイン認証は、IDP サーバを使用して行われます。 その後、サバイバビリティ イベント中に、IDP サーバが強化されたサバイバビリティ ノードから到達可能であれば、ソフト クライアントの認証が機能します。

   SSO が有効な Unified CM ウェブ UI ログインの場合、IDP 到達性が必要であるか、リカバリベースの URL ログインを使用する必要があります。

   認証はサバイバビリティ イベントの前に取得したトークンに基づいているため、すでに認証されたクライアントは引き続きログインされます。 ただし、クライアントが以前の認証からの有効なトークンを持っていない場合の新しいログインでは、ESN は認証のために IDP サーバにリダイレクトされます。 したがって、サバイバビリティ イベント全体を通して IDP サーバが ESN に到達可能であることを常に確認する必要があります。

保留音、アナウンス、会議ブリッジ（ソフトウェア）サービスなどの基本的な Unified CM 機能には、ESN でメディア リソースを有効にする必要があります。 ハードウェアベースのメディア リソースが展開されている場合、サバイバビリティ イベント中に、メディア サーバが ESN から到達可能であることを確認する必要があります。

DI Unified CM クラスタの通常の操作中に、緊急コール（特に AMER 地域）が RedSky クラウド経由でルーティングされ、Dedicated Instnace Unified CM クラスタと RedSky クラウドの間に設定された SIP トランクがあります。

サバイバビリティ イベントがある場合、RedSky クラウドは ESN から到達できないため、RedSky が利用できない場合、そのサイトで設定されたローカル PSTN GW を介して緊急コールをルーティングするように、緊急通話ダイヤル プランを設定する必要があります。 ルート グループは、サバイバビリティ イベント中にコール ルーティングを処理するために、ローカル PSTN GW で構成されている必要があります。

他の専用インスタンス リージョンでの緊急コールについては、サバイバビリティ イベント中にローカル PSTN GW を介してコールをルーティングするようにダイヤル プランを設定する必要があります。

サバイバビリティ イベント中に内部コール、サイト間コール、クラスタ間コール、および PSTN コールをルーティングするためのダイヤル プランを設定します。 一般的に、ESN はコールに登録されているデバイスに対してのみコールをルーティングできます。 他のすべてのコールは、ローカル PSTN GW（ESN が展開されているすべてのサイトで設定）にルーティングされ、そこから PSTN にルーティングされる必要があります。 以下は、説明されたいくつかのシナリオです。

• 同じ ESN に登録されている電話 1 と電話 2 - コールは ESN 内でルーティングされます。

• ESN に登録された電話 1、専用インスタンス Unified CM クラスタに登録された電話 2 - ダイヤル プランは、ESN からローカル PSTN GW にコールをルーティングし、そこから PSTN 経由で DI Unified CM にルーティングする必要があります。 サバイバビリティ イベント中に、ダイヤル プランはコール ルーティングの失敗を検出し、ローカル PSTN GW を通じてコールを再ルーティングする必要があります。 同じことが、DI Unified CM デバイスからの ESN への着信にも適用できます。

• ESN に登録されている電話 1 と電話 2 は PSTN デバイスです。 サバイバビリティ イベント中に、PSTN コールをローカル PSTN ゲートウェイにルーティングする必要があります。 ダイヤル プランがコール ルーティングの失敗を検出し、使用可能なローカル PSTN ゲートウェイを介してコールを再ルーティングできることを確認する必要があります。

2 つの ESN ノード間の ICT コールは推奨しませんが、ESN がネットワーク内で到達可能な場合は実行可能です。

• サバイバビリティ イベント中に、サイトから専用インスタンス クラウドへの接続がダウンしている場合（WAN または接続の停止）、ESN からの接続がダウンしている専用インスタンス クラウドで Cisco Unity Connection サーバがホストされているため、ボイスメールと自動アテンダント機能は ESN に登録されているデバイスでは機能しません。 デバイスに「未登録のコール転送（CFU）」が設定され、コールが DI Unified CM で受信された場合、発信者は専用インスタンスの Unity Connection にボイスメールをデポジットできます。 これは、デバイスが DI unified CM サブスクライバにフォールバックしたときに取得できます。

• ただし、サバイバビリティ イベント中に、専用インスタンス クラウドへの接続が可能ですが、DI の Unified CM クラスタがダウンしている場合、ボイスメールと自動アテンダント機能は、ESN に登録されているデバイスで機能します。ESN は、DI クラウドに展開された Unity Connection サーバへの接続を持ちます。

サバイバビリティ イベント中、ESN は DI クラウドで Cisco Expressway E & C に到達できず、その逆も同様です。 したがって、この場合、MRAユーザーはESNからサービスを取得できず、したがって登録できません。 ただし、MRA デバイスがインターネットを持ち、DI クラウドで Cisco Expressways に接続できる場合、DI のクラスタが機能している場合は、DI Unified CM に登録できます。

CTI ベースの統合が強化されたサバイバビリティ ノードと連携するには、CTI のサーバ リストの一部として強化されたサバイバビリティ ノードを追加する必要があります。 CTI の強化は、JTAPI を使用するアプリケーションに対して行われ、設定されたリスト内のプライマリまたはセカンダリ CTI サーバが到達できない場合にのみ、アプリケーションが接続できる CTI サーバとして強化されたサバイバビリティ ノードを許可します。 通常の操作中に、サイト上の CTI アプリケーションは DI クラウドのプライマリおよびセカンダリ CTI サーバに接続でき、サバイバビリティ イベント中に、強化されたサバイバビリティ ノードに接続して、継続的な CTI エクスペリエンスを得ることができます。 アプリケーションは、接続が復元されたときに Enhanced Survivability Node からのフォールバックが行われるようにするために、JTAPI インターフェイスで公開されている新しい API に適応する必要があります。

追加された新しい API の詳細については、冗長性セクションを参照してください。 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/jtapi_dev/14_0_1/cucm_b_cisco-unified-jtapi-developers-guide-14/cucm_b_cisco-unified-jtapi-developers-guide-1251_chapter_00.html

AXL Web サービスは、読み取り専用の管理者権限を持つ拡張サバイバビリティ ノードで有効になっています。 プロビジョニング サーバなどのサードパーティ アプリケーションは、データベース関連の更新に対して DI Unified CM パブリッシャとのみインターフェイスすることを推奨します。 ただし、これらのアプリケーションは、強化されたサバイバビリティ ノードに接続されている場合にのみ、読み取り専用にすることができます。

SIP トランクを介してインターフェイスするサードパーティ アプリケーションは、強化されたサバイバビリティ ノードをサポートします。 SIP トランク設定で、「すべてのノードで実行」設定を有効にする必要があります。

サードパーティ製デバイスは、第三次 TFTP 機能を持つサポートされています。