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