ハードウェア展開に関する考慮事項

サポートされているハイパーバイザーを使用して、仮想マシンに 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
1秒あたりの通話数	2	4
1秒あたりの登録数	60	400

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

モジュールのスケーリングと回復性

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

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

この機能は現在ベータ版であり、有効にするには技術サポートチケットが必要です。

スケーリングにより、サイトのサポート対象デバイス性能が向上します

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 サイト は、共通のアクセスコード、住所、SIPゾーン、部門、またはポリシーなどの共通する特性を持つユーザーを、Zoomウェブポータル内の単一の管理しやすいグループにまとめる、Zoom Phone内で使用される特定の用語です。一部のお客様の声では、1つのサイトがビジネス内のすべてのユーザーを表し、1つのキャンパスまたは位置情報内の複数の建物にまたがる場合があります。その他の場合は、ビジネスニーズに応じて複数のサイトが必要になることがあります。サイトまたはサイト管理の詳細については、 Zoomのヘルプセンターを参照してください.

Zoom Phoneは単一サイト設計と複数サイト設計をサポートします

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

1. 単一サイト：アカウント内のすべてのユーザーを表し、複数の建物または位置情報にまたがる可能性があるものを、1つのZoom Phoneサイト内にまとめる設計。

2. 複数サイト：位置情報、建物、部門、または機能ごとにユーザーの区分を個別に表し、それぞれが独自のサイトを持つ設計。

現在のZoomのお客様の声のアカウント管理者は、現在のサイト設計を 会社情報 ページで確認できます。これは、ウェブポータルの 電話システム管理 メニューで利用できます。

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

前述のとおり、ZPLSモジュールは、 第3優先レジストラ であり、サポート対象デバイスに対して、プライマリおよびセカンダリのSIPゾーンに続く位置付けです。デバイスは起動時にSRVリストを受け取り、これらのリストはそのサイトの設定に結び付けられているため、 各ZPLSモジュールは、一度に1つのサイトにのみ関連付けることができます.

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

各ZPLSモジュールは一度に1つのサイトにしか関連付けられませんが、1つのサイトでは1つのグループ内で最大20個のZPLSモジュールをサポートでき、各サイトのサバイバビリティ性能を拡張できます。

この機能は現在ベータ版であり、有効にするには技術サポートチケットが必要です。

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

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

この機能は現在ベータ版であり、有効にするには技術サポートチケットが必要です。

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

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

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

単一サイト設計は、アカウント内のすべてのユーザーを単一の統合グループの下にまとめることで、Zoom Phoneの設定とポリシーの管理を効率化するのに役立ちます。この単一のユーザーグループにより、ビジネスでは分かりやすい管理と複雑さの軽減が実現し、管理プロセスが簡素化されます。さらに、サイトのユーザー数が 単一モジュールの性能.

を超えない限り、単一サイト設計では1つの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モジュールへの接続性を維持している限り、相手に通話できます。

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

次の表は、複数建物を含む単一サイト設計におけるZoom Phoneのサバイバビリティを示しています。

建物から発信される通話	外部インターネット障害時に到達可能な位置情報	キャンパスネットワーク障害時に到達可能な位置情報
建物A（ZPLSホスト）	☑️建物A、B、C	☑️ 建物A のみ
建物B	☑️建物A、B、C	✖️
建物C	☑️建物A、B、C	✖️

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

複数サイト設計では、各建物または位置情報（例：フロア、サテライトオフィスなど）が、Zoom Phone内でそれぞれ固有のサイトとして独立して表されます。この構成では、各サイトにZPLSモジュールがあり、各サイトが共通のキャンパスエリアネットワークを通じて接続されていることを前提としています。

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

例：

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