ハードウェア導入時の考慮事項

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

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

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

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

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

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

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

	構成オプション1	構成オプション2
ハードウェア仕様	CPU 8コア RAM 16GB HDD 80GB	CPU 16コア RAM 16GB HDD 80GB
合計登録数	2000	5000
最大同時通話数	240	480
毎秒通話数（Calls Per Second）	2	4
毎秒登録数（Registrations Per Second）	60	400

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

モジュールのスケーリングと耐障害性

ZPLSモジュールは追加のスケーリングおよび／または耐障害性のためにクラスタリングをサポートします

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

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

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

ZPLSモジュールの数を増やすと、各サイトの能力は追加モジュールごとに線形に拡張されます。例えば、単一モジュールが合計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ユーザーをグループ化します

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

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

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

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

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

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

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

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

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

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

例：

ある会社が建物A、B、Cで構成される単一のZoom Phoneサイト向けにZPLSモジュールを導入しています。これらの建物はキャンパスエリアネットワークで接続されています。ZPLSモジュールは建物Aで稼働しており、 接続されていません 外部通話のための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モジュールをサポートし、サバイバビリティモードが有効化されたときに同じ建物内のユーザーが互いに通話できます。さらに、複数のサイトが共通ネットワークで接続されている場合、ローカルネットワークが稼働している限り、ユーザーは他のサイトのユーザーに発信できます。ただし、この設計は建物間通信に影響を与えるキャンパスネットワークの障害時に脆弱です。以下の例は、キャンパスネットワーク障害がマルチサイトのデプロイにどのように影響するかを説明しています。

例：

ある会社が建物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モジュールに登録できるかどうかによって決まります。ユーザーがホームサイトを離れている間にキャンパスエリアネットワークがダウンしている場合、ユーザーはサバイバビリティモジュールの恩恵を受けることはできません。