ハードウェア展開の考慮事項

サポートされているハイパーバイザーを使用して仮想マシン上にZoom Node ZPLSモジュールを展開する手順を見つけてください

このページでは、サポートされているハイパーバイザを使用して仮想マシン上に Zoom Node ZPLS モジュールを展開する方法を概説しています。さまざまなハードウェア性能に対応する詳細な構成オプションを提供し、さまざまな運用ニーズに対して最適なパフォーマンスを確保します。

サポートされているハイパーバイザ

顧客はサポートされているハイパーバイザ上で動作する仮想マシンに Zoom Node ソフトウェアをインストールする必要があります

Zoom Node のワークロードとして、ZPLS モジュールは Zoom Node プラットフォーム上で動作する仮想マシンにインストールする必要があります、 サポートされているハイパーバイザ。Zoom Node 製品に関する詳細情報は 付録にあります.

顧客はハードウェアの能力に応じて2つの構成オプションのいずれかを選択できます

ZPLS モジュールは仮想マシンのハードウェア能力に応じて2つの構成をサポートします。これらの能力は以下に記載されています：

	構成オプション 1	構成オプション 2
ハードウェア仕様	8 CPU 16 GB RAM 80 GB HDD	16 CPU 16 GB RAM 80 GB HDD
総登録数	2000	5000
同時最大通話数	240	480
秒あたりの通話数	2	4
秒あたりの登録数	45	90

サバイバビリティ対応サイト内のエンドポイント数がサイトの展開能力を超える場合、ZPLS モジュールは先着順で登録を処理します。顧客は追加モジュールを追加するか、Zoom Phone のポリシー設定を使用することを推奨します ローカルサバイバビリティモード どのユーザーがサバイバビリティのフェイルオーバーをサポートするかの優先順位を設定するために。

モジュールのスケーリングとレジリエンシー

ZPLS モジュールは追加のスケーリングおよび/またはレジリエンシーのためにクラスタリングをサポートします

顧客は冗長性やスケーリングのためにサイトごとに最大20モジュール（アカウントあたり合計100台の Node デバイス）まで ZPLS モジュールをグループ化できます。

この機能は現在ベータ版であり、有効化にはテクニカルサポートへのチケットが必要です。

スケーリングはサイトのサポートするデバイス能力を増加させます

ZPLS モジュールの数を増やすことで、各サイトの能力は追加モジュールごとに線形に拡張されます。例えば、1つのモジュールが合計5,000登録をサポートする場合、5つのモジュールを展開するとサポートは25,000登録に増加します。

冗長化はレジリエンシーのために追加モジュールを加えるものであり、サイトのデバイス能力をスケールするものではありません

ZPLS モジュールが冗長化の目的で使用される場合、冗長モジュールはサポートされる内線数の合計に寄与しません。代わりにモジュールは「ホットスタンバイ」状態にあり、プライマリモジュールが故障した場合にのみ稼働します。例えば、1つのプライマリと1つの冗長モジュールで合計5,000登録をサポートするなら、プライマリが故障した場合でも冗長モジュールがサポート上限を超えてデバイスで過負荷になることはありません。

スケーリングと冗長性を備えた ZPLS 展開の例

便宜上、以下の例は追加のスケーリングと冗長性を伴う展開を示しています。

例:

病院はサバイバビリティのために最大10,000の登録内線をサポートする必要があります。これを達成するために、病院は4つの ZPLS モジュールを展開しています。

最初の2つのモジュールはそれぞれ5,000登録をサポートでき、合計で最大10,000登録の容量になります。しかし、レジリエンシーの重要性を認識し、病院はプライマリモジュールの冗長バックアップとしてさらに2つのモジュールを展開しています。

このシナリオでは、病院はプライマリおよびセカンダリのサバイバビリティハードウェアを展開しています。プライマリモジュールに障害が発生した場合、冗長モジュールが引き継いでサービスを維持し、引き続き最大10,000の登録デバイスをサポートします。

サイト設計に関する考慮事項

サイトは共通の電話設定とポリシーのために Zoom Phone ユーザーを場所ごとにグループ化します

A サイト は Zoom Phone 内で使用される特定の用語で、共通のアクセスコード、住所、SIP ゾーン、部門、またはポリシーなどの共通の特性を持つユーザーを Zoom Web ポータル内の単一の管理可能なグループにまとめるものです。一部の顧客にとっては、単一のサイトがビジネス内のすべてのユーザーを表し、キャンパスやロケーション内の複数の建物にまたがることがあります。他の顧客にとっては、ビジネスニーズに応じて複数のサイトが必要となる場合があります。サイトやサイト管理に関する詳細については、 Zoom のサポートセンターを参照してください.

Zoom Phone は単一サイトおよびマルチサイトの設計をサポートします

アカウント内で Zoom Phone サイトを構成するための主要な設計は2つあります：

1. 単一サイト：アカウント内のすべてのユーザーを表し、複数の建物やロケーションにまたがる可能性がある単一の Zoom Phone サイト。

2. マルチサイト：ロケーション、建物、部門、または機能ごとにユーザーのセグメントを個別に表し、それぞれが独自のサイトを持つ。

既存の Zoom 顧客のアカウント管理者は、 Company Info ページで現在のサイト設計を確認できます、 Phone System Management ウェブポータルのメニューにあります。

各 ZPLS モジュールは同時に1つのサイトにのみ関連付けることができます

前述のように、ZPLS モジュールは サポートされているデバイスに対する第三優先のレジストラです 主要および二次の SIP ゾーンに続きます。デバイスは起動プロセス中に SRV リストを受け取り、これらのリストはサイトの設定に紐づいているため、 各 ZPLS モジュールは同時に1つのサイトにのみ関連付けることができます.

各サイトは同時に最大20台の ZPLS モジュールをサポートできます

各 ZPLS モジュールは同時に1つのサイトにのみ関連付けられますが、サイトは1つのグループ内で最大20台の ZPLS モジュールをサポートでき、各サイトのサバイバビリティ能力を拡張できます。

この機能は現在ベータ版であり、有効化にはテクニカルサポートへのチケットが必要です。

ZPLS モジュールはモジュールが共通のネットワークに接続されている場合、サイト間通話をサポートします

異なるサイトの ZPLS モジュールは、デバイスがローカルネットワーク内で検出可能である限り、サバイバビリティイベント中にサイト間通話をサポートします。たとえば、企業キャンパスに3つの建物があり、それぞれが独自の電話サイトを持っている場合、各サイトの ZPLS モジュールはキャンパス内ネットワークを介してサイト間通話を接続できます。

この機能は現在ベータ版であり、有効化にはテクニカルサポートへのチケットが必要です。

ZPLS を展開する前に、アカウントはどのサイト構成がニーズに最適かを理解しておく必要があります

各 ZPLS モジュールは同時に1つのサイトにのみ関連付けられるため、サイト設計はアカウント内で ZPLS サービスを展開する際に最も重要な要因の一つです。このため、顧客は実際のビジネスおよびサバイバビリティの要件を満たすためにどのサイト構成が最適かを理解する必要があります。サバイバビリティを有効にした各追加サイトには少なくとも1つの追加 ZPLS モジュールが必要になります。

単一サイト設計は管理が容易で単一の ZPLS モジュールでサバイバビリティを提供しますが、ユーザー設定やポリシーの柔軟性は低くなります

単一サイト設計は、アカウント内のすべてのユーザーを単一の統合グループに統合することで、Zoom Phone の設定とポリシーの管理を簡素化します。この単一ユーザーグループは、企業に対して明瞭な管理方法と複雑さの軽減を提供し、管理プロセスを簡素化します。さらに、単一サイト設計はサイトのユーザーが単一モジュールの 能力を超えない限り、単一の ZPLS モジュールでローカルの電話サバイバビリティを提供できます、.

しかし、単一サイト設計の簡素さには当然制約が伴います。具体的には、単一サイト設計は「一律適用」の性質により柔軟性が低く、さまざまなニーズを持つ複数の部門がある展開シナリオには適さない場合があります。さらに、ローカルネットワークが 障害した場合、単一サイトの展開は特定のサバイバルシナリオで脆弱になる可能性があります。.

マルチサイト設計はユーザー設定やポリシーに対する柔軟性を高めますが、サバイバビリティ対応サイトごとに1つの ZPLS モジュールが必要で、管理はより複雑になります

マルチサイト設計は、ユーザーを複数のグループに分離して詳細な設定制御を行うことで、ユーザー設定とポリシーに関して企業に追加の柔軟性を提供します。この設計により、組織はさまざまなサイトの特定要件に合わせて通信設定を精緻に調整でき、部門やシナリオ、ニーズに応じたより洗練され適応性のあるユーザー体験を実現できます。さらに、マルチサイト展開は サイト間通信をサポートできます サイトが共通ネットワークで接続されている場合。

ただし、マルチサイト設計の管理は各サイト固有の要件の詳細に注意を払う必要があり、管理作業がより多く必要となる場合があります。さらに、各 ZPLS モジュールは同時に1つのサイトにのみ割り当て可能であるため、サバイバビリティ対応の各サイトには1つの ZPLS モジュールとライセンスが必要となり、よりリソース集約的なセットアップになる可能性があります。

マルチサイト設計では、どのサイトをサバイバビリティ用に構成するかを顧客が自由に選択できます。サイト 一括ライセンスなし ZPLS モジュールは標準の接続が回復するまで通話の発着信ができなくなります。

ネットワーク障害

サイトのローカルネットワークが障害した場合、サバイバビリティに影響を及ぼす可能性があります

ZPLS モジュールはサービスに影響を与える事象中にローカルの電話サバイバビリティを提供するように設計されていますが、サイトのローカルネットワークが障害した場合、サバイバビリティに影響が出る可能性があります。これらのシナリオは以下の2つのセクションで説明されています。

単一サイトのローカルネットワーク障害

単一サイト設計では、1つ以上の建物がローカルまたはキャンパスのエリアネットワークで接続され、Zoom Phone 内では単一のサイトとして表されます。この構成は、ロケーション内のすべてのユーザーおよび建物間で共通のネットワークを前提としており、建物間通信に外部ネットワーク（例：インターネット）への依存がありません。

このサイト設計では、企業は最小で1台の ZPLS モジュールで単一サイトまたはロケーション内のすべてのユーザーにローカルサバイバビリティを提供できます；ただし、この設計は建物間通信に影響を与えるローカルまたはキャンパスネットワーク障害が発生した場合に脆弱です。以下の例はローカルネットワーク障害が単一サイト展開にどのように影響するかを説明します。

例：

ある会社がキャンパスエリアネットワークで接続された建物 A、B、C で構成される単一の Zoom Phone サイトのために ZPLS モジュールを展開しています。ZPLS モジュールは建物 A で動作しており、 サポートされていませんが、将来的にサポートされる予定です。 PSTN を介した外部通話のための SBC に接続されています。

外部インターネットサービスの障害やサービスに影響を与える事象が発生した場合、サイト内に含まれる任意のユーザーは、 同じ サイト内の別のユーザーに通話をかけることができます、両方のユーザーがキャンパスエリアネットワークを介して ZPLS モジュールへの接続を維持している限り。

しかし、キャンパスエリアネットワークの障害が発生した場合、建物 B と C 内のユーザーは建物 A 内の ZPLS モジュールに到達できない間は通話を発信できません。したがって、建物 B と C のユーザーはサバイバビリティ通話のためにキャンパスエリアネットワークが復旧するまで待つ必要があります。

次の表は、マルチビルディングの単一サイト設計における Zoom Phone のサバイバビリティを示しています：

〜発信元の通話（建物）	外部インターネット障害時に到達できる場所	キャンパスネットワーク障害時に到達できる場所
建物 A（ZPLS ホスト）	☑️ 建物 A、B、および C	☑️ 建物 A のみ
建物 B	☑️ 建物 A、B、および C	✖️
建物 C	☑️ 建物 A、B、および C	✖️

SBC なしのマルチサイトのローカルネットワーク障害

マルチサイト設計では、各建物またはロケーション（例：フロア、サテライトオフィスなど）が Zoom Phone 内で個別のサイトとして表されます。この構成は、各サイトが ZPLS モジュールを持ち、サイト同士が共通のキャンパスエリアネットワークで接続されていることを前提としています。

このサイト設計では、各サイトが独自の ZPLS モジュールをサポートし、サバイバビリティモードが有効になった場合に同じ建物内のユーザー同士が通話できるようにします。さらに、複数の ZPLS モジュールを持つ複数のサイトが共通ネットワークで接続されている場合、ローカルネットワークが稼働している限り、ユーザーは他のサイトのユーザーに通話できます。ただし、この設計はキャンパスエリアネットワークの障害により建物間通信に影響が出る場合には脆弱です。以下の例は、キャンパスネットワーク障害がマルチサイト展開にどのように影響するかを説明します。

例：

ある会社が建物 A、B、C で構成されるマルチビルディングキャンパス内に ZPLS モジュールを展開しています。各建物は Zoom Phone 内で固有のサイトであり、サイト固有の ZPLS モジュールを保持しています。キャンパス内のすべての建物は、建物間通信のために外部インターネットサービスに依存しないキャンパスエリアネットワークで接続されています。

この例では、外部インターネットサービスの障害、キャンパスネットワークの障害、またはサービスに影響を与える事象が発生した場合でも、サイト内にいる任意のユーザーは同じサイトにいる別のユーザーに通話できます。しかし、各建物が固有のサイトでありユーザーがサイト固有のモジュールに登録するため、キャンパスネットワークが障害した場合、ZPLS モジュールはサイト間通話を転送できません。代わりに、ユーザーはローカルサイト内の他のユーザーへの通話に限定されます。

次の表は、相互接続されたキャンパスネットワークを持つマルチサイト設計の上記の例における Zoom Phone のサバイバビリティを示しています：

〜発信元の通話（建物）	外部インターネット障害時に到達できる場所	キャンパスネットワーク障害時に到達できる場所
建物 A（ZPLS ホスト）	☑️ 建物 A、B、および C	☑️ 建物 A
建物 B（ZPLS ホスト）	☑️ 建物 A、B、および C	☑️ 建物 B
建物 C（ZPLS ホスト）	☑️ 建物 A、B、および C	☑️ 建物 C

ローカルネットワークが障害した場合、各サイトが SBC に接続されコールフォワーディングが有効になっていれば PSTN を介したサイト間通話もサポートされます

ローカルネットワーク障害が発生した場合、各サイトに ZPLS モジュールと SBC および PSTN 接続を統合したマルチサイト設計の顧客は、 コールフォワーディングが有効になっている場合。構成されると、サバイバビリティモード中に発信される通話はユーザーのクライアントから PSTN、次に第二サイトの SBC と ZPLS モジュールを経由して最終的に被呼者の端末に到達します。以下の図はこの構成の概要を示します：

この構成は には 構成された SBC 上での E.164 電話番号処理に依存します。

次の表は、独立した SBC を持つマルチサイト設計における Zoom Phone のサバイバビリティも示しています：

〜発信元の通話（建物）	外部インターネット障害時に到達できる場所	キャンパスネットワーク障害時に到達できる場所
建物 A（ZPLS ホスト）	☑️ 建物 A、B、および C	☑️ 建物 A、B、および C
建物 B（ZPLS ホスト）	☑️ 建物 A、B、および C	☑️ 建物 A、B、および C
建物 C（ZPLS ホスト）	☑️ 建物 A、B、および C	☑️ 建物 A、B、および C

ノマディックユーザーは常に自分のホームサイトに関連付けられた ZPLS モジュールに登録します

ユーザーまたはデバイスが Zoom Phone に追加されると、アカウント管理者によって更新されない限り、ユーザーまたはデバイスには静的に「ホーム」サイトが関連付けられます。これは、ユーザーが関連付けられたホームサイト外の物理的な場所（たとえば別のサイトに関連付けられたオフィスビル）に移動した場合でも、Zoom がユーザーに紐づくサイトを動的に調整しないことを意味します。その結果、ユーザーが Zoom Phone データセンターへの接続を失った場合、ユーザーは異なる場所にいてもホームサイトに関連付けられた ZPLS モジュールへの登録を試みます。

例：

マルチサイトキャンパス内のユーザーが建物 A（サイト A）を拠点とし、会議のために一時的に建物 B（サイト B）に移動します。建物 B にいる間にサービスに影響を与える事象が発生し、サバイバビリティモードが有効になります。ユーザーは建物 B にいるにもかかわらず、サイト A がホームサイトであるため、ユーザーのクライアントは建物 A にプロビジョニングされたホームサイトの ZPLS モジュールへの接続を試みます。

このシナリオでは、ユーザーのサバイバビリティ状態は、キャンパスエリアネットワークを介して自分のホームサイト内の ZPLS モジュールに登録できるかどうかによって決まります。ユーザーがホームサイトから離れている間にキャンパスエリアネットワークがダウンしている場合、ユーザーはサバイバビリティモジュールの恩恵を受けることはできません。