Zoom Phone ローカル サバイバビリティ（ZPLS）サービス モジュールは、Zoom Node が提供する OS とプラットフォームを活用し、オンプレミスの VMware ESXi ホストで実行される Linux ベースの専用ハードウェアとして配布されています。 組織は ZPLS モジュールを展開することで、Zoom Phone システムのオンプレミス フェイルオーバーを設けることができます。
この記事では、次の項目について説明します。
ZPLS サービス モジュールが、通常運用時に通話サービスに影響を及ぼすことはありません。 存続可能な電話サイトの Zoom Phone クライアントおよびデバイスは、対応する ZPLS サービス モジュールに登録し、Zoom Phone の接続が切れたときも一部の電話機能を維持する能力を備えています。 Zoom Phone クラウドへの接続が回復したら、クライアントとデバイスが改めてクラウドに登録されます。 停電中は、管理者もエンドユーザーも、サバイバビリティを有効にするアクションを取る必要は一切ありません。フェイルオーバーとフォールバックのプロセスが、シームレスかつ自動的に実行されます。
サバイバビリティを支えるハードウェアは、一般的には多数の従業員が 1 つの場所やキャンパス（建物や敷地）に集まる戦略的な場所で、バックアップ プランとして機能するよう設計されています。 通常運用時、Zoom Phone クライアントは、ZPLS サービス モジュールを介さずに直接 Zoom Phone のデータセンターと通信します。 停電で Zoom クライアントが Zoom Phone のデータセンターに接続できない間、サポート対象のクライアントとデバイスは、内部のダイヤル通話機能と補助サービスを維持する目的で、基本的なオンサイトの ZPLS サービス モジュールに登録されます。 オプションで、SBC と適切なルートグループがプロビジョニングされていれば、PSTN 接続を維持することができます。 通常運用に戻ったら、クライアントが元どおりクラウドに登録され、ZPLS サービス モジュールはアイドリング状態に戻ります。
ZPLS サービス モジュールを展開するべきタイミングと場所を決めるときに極めて重要となるポイントは、Zoom Phone 設定の [会社情報] セクションにある管理ポータルから表示および追加できるサイトの概念です。 Zoom Phone システム内のサイトは、顧客がエンドユーザーを共通の特徴で整理し、単一のダイヤル通話ドメインにまとめるための構成設定です。 たとえば共通アクセスコード、地理的場所、デフォルトの緊急連絡先住所は、ユーザー、デバイスといった電話システムの構成要素が、同じサイトに属する根拠として考えられます。
管理者がサバイバビリティを支えるハードウェアを展開する前に考慮するべき重要なポイントの 1 つは、各 ZPLS サービス モジュールが、Zoom Phone 管理ポータルで定義された単一のサイトにしかサービスを提供できないこと、そして管理上定義されているサイトごとに利用できる ZPLS サービス モジュールは 1 つのみであることです。 つまり Zoom Phone サイトと ZPLS サービス モジュールの間のマッピングは、1 対 1 です。
複数の建物や場所がある教育施設や医療施設のキャンパス環境を想像してみてください。
上の例ではキャンパス内に建物が 3 棟あります。 あらゆる場所へのインターネット ブレイクアウトが、中央管理されています（ビル A）。 ZPLS サービス モジュールが 1 つ展開されています。そのモジュールは、ビジネス継続性が非常に重要なデバイスとユーザーの大半を収容するビルに設置する必要があります。 Zoom クラウドにアクセスできなくなってしまった場合、キャンパス ネットワークの IP 接続がまだ機能している限り、ZPLS サービス モジュールはこのビル 3 棟すべてにサービスを提供できます。 この 3 か所のユーザーは、ZPLS サービス モジュールに接続されている 1 つの電話システムサイト（この例ではサイト「ABC」）内にプロビジョニングされている必要があります。 短縮内線番号での内部ダイヤル通話、連絡先とのダイヤル通話がサポートされています。 オプションで SBC とルートグループが有効になっている場合、PSTN 着信および発信通話が機能します。
前の例では、キャンパス ネットワークが十分な信頼性と回復力を備えているため、場所ごとに別々の（オンサイト）ZPLS サービス モジュールを設ける必要はないと見なされていました。 これと対照的に、場所と場所との接続性の信頼性があまり強固ではない状況を考えてみてください。
上のシナリオでは、キャンパス内の建物または場所がそれぞれ、ローカルのユーザーとデバイス、そしてローカルの ZPLS サービス モジュールを含む独自の電話システムサイトにマッピングされています。 前述のモデルに比べ、この展開モデルの利点は、キャンパス ネットワークの電源が落ちても、テレフォニー サービスを維持できる点です。 SBC と PSTN トランクがそれぞれの場所にプロビジョニングされていれば、PSTN 接続も維持できます。 この展開モデルの限界は、各 ZPLS サービス モジュールがネットワーク内に展開されたほかの ZPLS サービス モジュールを認識しないため、内部ダイヤル通話ドメインの範囲が狭まることです。 この例の場合、各場所内の内部ダイヤル通話はサポート対象ですが、別の場所または建物との内部ダイヤル通話はサポート対象外です。
最適な設計に関わるその他の考慮事項は、Zoom Phone の構成要素のサイトに対する関連づけが静的な性質を持つことです。 ユーザーまたはデバイスが電話システムに追加されると、「ホーム」サイトが静的に設定されます。 特定のユーザーがホームサイトを出て一時的な「ローミング サイト」に移動している場合、Zoom はユーザーのサイトを動的に調整しません。 上の例では、ビル A（ホームサイト）を拠点とするユーザーが停電時に一時、ビル B（ローミング サイト）に移動した場合、クライアントはビル B のローカル モジュールではなく、ホームサイト（ビル A）にプロビジョニングされている ZPLS サービス モジュールへの接続を試みます。 このシナリオでは、サバイバビリティが依然としてキャンパス ネットワークの運用ステータスに依存します。
大半の機能は Zoom クラウドに依存しているため、クラウド サービス中断期間にエンドユーザーが利用できる機能は、通常運用時に提供される機能セットに比べると、常に限られたものとなります。 以下の機能は、フェイルオーバー中もサポートされます。
ローカル サバイバビリティ サービス モジュールのサポート対象デバイスの詳細情報については、以下をご覧ください。
クラウド アクセス喪失中のアクティブな通話のチェックポイント処理は、Zoom ではサポートされていません。 クライアントが Zoom Phone クラウドにアクセスできなくなると、アクティブな通話に参加しているユーザーには通話中を示す音が高速で再生され、ユーザーは手動で通話を再確立する前に、ZPLS サービス モジュールへのフェイルオーバー プロセスの完了を待つ必要があります。
このフェイルオーバーとフォールバックのプロセスは、エンドユーザーにとっての透明性が確保されています。 エンドユーザーは、クライアントを閉じて再起動したり、ハードウェア デバイスを再起動したりする必要はありません。また、フェイルオーバーを開始するためのトリガーも必要ありません。
次のバナーがユーザーに表示され、フェイルオーバー モードで運用していることが伝わります。
再接続されるとユーザーに次のバナーが表示されます。