> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/ja/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md). # ハードウェア導入時の考慮事項 このページでは、サポートされているハイパーバイザーを使用して仮想マシン上にZoom Node ZPLSモジュールを展開する方法を説明します。異なるハードウェア性能に対応し、さまざまな運用ニーズに対して最適なパフォーマンスを確保できるように調整された、詳細な設定オプションを提供します。 ### サポートされているハイパーバイザー #### お客様の声は、サポートされているハイパーバイザー上で稼働する仮想マシンにZoom Nodeソフトウェアをインストールする必要があります Zoom Nodeのワークロードとして、ZPLSモジュールは、Zoom Nodeプラットフォームを実行している仮想マシン上の [サポートされているハイパーバイザー](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server)。製品としてのZoom Nodeに関する詳細は [付録で確認できます](#_a2lvsihjp0ek). #### お客様の声は、ハードウェア性能に応じて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 | {% hint style="info" %} サバイバビリティ有効化サイト内のエンドポイント数が、そのサイトの展開可能数を超えると、ZPLSモジュールは先着順で登録を処理します。お客様の声には、追加のモジュールを追加するか、Zoom Phoneポリシー設定の「ローカル サバイバビリティモード」を使用して、どのユーザーがサバイバビリティ フェイルオーバーをサポートするかを優先することをお勧めします [**ローカル サバイバビリティモード**](#_ah8xua8wdq10) を使用して、どのユーザーがサバイバビリティ フェイルオーバーをサポートするかを優先します。 {% endhint %} ### モジュールのスケーリングとレジリエンス #### ZPLSモジュールは、さらなるスケーリングおよび/またはレジリエンスのためにクラスタリングをサポートします お客様の声は、追加の冗長性またはスケーリングのために、サイトごとに最大20個のモジュール（またはアカウントごとに合計100台のNodeデバイス）をZPLSモジュールとしてまとめてグループ化できます。 {% hint style="info" %} この機能は現在ベータ版であり、有効にするには技術サポートチケットが必要です。 {% endhint %} #### スケーリングにより、サイトのサポート対象デバイスの性能が向上します ZPLSモジュールの数を増やすと、追加モジュールごとに各サイトの性能が直線的に向上します。たとえば、1つのモジュールが合計5,000件の登録をサポートする場合、5つのモジュールを展開するとサポート件数は25,000件に拡張されます。 #### 冗長性はレジリエンスのために追加モジュールを加えますが、サイトのデバイス性能は拡張しません ZPLSモジュールを冗長性の目的で使用する場合、冗長モジュールはサポート対象内線の合計数には含まれません。代わりに、モジュールは「ホットスタンバイ」となり、プライマリモジュールに障害が発生した場合にのみ動作します。たとえば、1つのプライマリモジュールと1つの冗長モジュールで合計5,000件の登録をサポートするため、プライマリモジュールに障害が発生しても、冗長モジュールにそのサポート上限を超えるデバイスが割り当てられることはありません。 #### スケーリングと冗長性を伴うZPLSの展開例 参考までに、以下の例では追加のスケーリングと冗長性を備えた展開を示します。 {% hint style="success" %} **例**: 病院では、サバイバビリティのために最大10,000の登録済み内線をサポートする必要があります。これを実現するため、病院では4つのZPLSモジュールを展開しています。 最初の2つのモジュールはそれぞれ5,000件の登録をサポートでき、合計で最大10,000件の登録に対応します。ただし、レジリエンスの重要性を踏まえ、病院ではプライマリモジュールの冗長バックアップとして追加の2つのモジュールも展開しています。 このシナリオでは、病院にはプライマリおよびセカンダリのサバイバビリティハードウェアが導入されています。プライマリモジュールに障害が発生した場合は、冗長モジュールが引き継ぎ、10,000台の登録済みデバイスを引き続きサポートしながら、サービスの中断を防ぎます。 {% endhint %} ### サイト設計に関する考慮事項 #### サイトは、共通のテレフォニー設定とポリシーのために、位置情報ごとにZoom Phoneユーザーをまとめます 1つの **サイト** は、Zoom Phone内で使われる特定の用語で、共通のアクセスコード、住所、SIP Zone、部門、またはポリシーなどの共通特性を持つユーザーを、Zoomウェブポータル内の1つの管理しやすいグループにまとめます。お客様の声によっては、1つのサイトがビジネス内のすべてのユーザーを表し、キャンパスや位置情報内の複数の建物にまたがる場合があります。別のお客様の声では、ビジネス要件に応じて複数のサイトが必要になることがあります。サイトまたはサイト管理の詳細については、Zoomのヘルプセンターを参照してください [Zoomのヘルプセンターを参照してください](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). #### Zoom Phoneはシングルサイトおよびマルチサイト設計をサポートします アカウント内でZoom Phoneのサイトを設定するための主な設計は2つあります： 1. **シングルサイト**：1つのZoom Phoneサイト内で、アカウント内のすべてのユーザーを表し、複数の建物や位置情報にまたがる場合もあります。 2. **マルチサイト**：ユーザーを位置情報、建物、部門、または機能ごとに個別に分け、それぞれに独自のサイトを割り当てます。
{% hint style="info" %} 現在のZoomのお客様の声のアカウント管理者は、 [**会社情報**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) ページから、 **電話システム管理** Zoomウェブポータルのメニューで利用できる {% endhint %} #### 各ZPLSモジュールは、一度に1つのサイトにのみ関連付けできます 前述のとおり、ZPLSモジュールは [第3優先のレジストラ](#_7itj40mx1dut) です。これは、サポート対象デバイスにとって、プライマリおよびセカンダリのSIPゾーンに次ぐものです。デバイスは起動時にSRVリストを受け取り、これらのリストはサイトの設定に紐づいているため、 **各ZPLSモジュールは一度に1つのサイトにのみ関連付けできます**. #### 各サイトは同時に最大20個のZPLSモジュールをサポートできます 各ZPLSモジュールは一度に1つのサイトにのみ関連付けできますが、1つのサイトで最大20個のZPLSモジュールを1グループとしてサポートでき、各サイトのサバイバビリティ機能が拡張されます。 {% hint style="info" %} この機能は現在ベータ版であり、有効にするには技術サポートチケットが必要です。 {% endhint %} #### ZPLSモジュールは、モジュールが共通ネットワークに接続されている場合、サイト間通話をサポートします 異なるサイトのZPLSモジュールは、サバイバビリティ事象の間、デバイスがローカルネットワーク上で検出可能である限り、サイト間通話をサポートします。たとえば、ビジネスキャンパスにそれぞれ独自の電話サイトを持つ3つの建物がある場合、各サイトのZPLSモジュールはキャンパスエリアネットワークを介してサイト間通話を接続できます。 {% hint style="info" %} この機能は現在ベータ版であり、有効にするには技術サポートチケットが必要です。 {% endhint %} #### ZPLSを展開する前に、アカウントはどのサイト構成が自分たちのニーズに最適かを理解しておく必要があります 各ZPLSモジュールは一度に1つのサイトにのみ関連付けできるため、サイト設計はアカウント内でZPLSサービスを展開する際の最も重要な要素の1つです。このため、お客様の声は、実際のビジネスニーズとサバイバビリティ要件を満たすうえでどのサイト構成が最適かを理解する必要があります。サバイバビリティを有効にした追加のサイトごとに、少なくとも1つの追加ZPLSモジュールが必要になるためです。 #### シングルサイト設計は管理が容易で、1つのZPLSモジュールでサバイバビリティを提供できますが、ユーザー設定やポリシーの柔軟性は低くなります シングルサイト設計は、アカウント内のすべてのユーザーを1つの統合グループにまとめることで、Zoom Phoneの設定とポリシーの管理を効率化します。この単一のユーザーグループにより、企業はわかりやすい管理と複雑さの軽減を実現し、管理プロセスが簡素化されます。さらに、サイトのユーザー数が単一モジュールの能力を超えない限り、1つのZPLSモジュールでローカル電話のサバイバビリティを提供できます。 [単一モジュールの](#_rx0i1j9xofnc). ただし、シングルサイト設計の単純さには当然ながら制約もあります。具体的には、「one size fits all」の性質により柔軟性が低く、さまざまなニーズを持つ複数の部門にわたるすべての展開シナリオに適しているとは限りません。さらに、ローカルネットワークが失敗した場合、シングルサイト展開は特定のサバイバビリティシナリオで脆弱になる可能性があります [ローカルネットワークが失敗した場合](#_gzpf5m70jl3i). #### マルチサイト設計はユーザー設定やポリシーの柔軟性が高い一方で、サバイバビリティを有効にした各サイトに1つのZPLSモジュールが必要となり、管理はより複雑になります マルチサイト設計は、きめ細かな設定制御を備えたさまざまなグループにユーザーを分けることで、ユーザー設定やポリシーにさらなる柔軟性を提供します。この設計により、組織は通信設定を詳細に調整して、さまざまなサイト全体の特定要件に対応でき、異なる部門、シナリオ、ニーズに対して、より洗練され適応性の高いユーザー体験を実現できます。さらに、マルチサイト展開では、 [サイト間通信](#_a42hwaw1pfmx) をサポートできます ただし、マルチサイト設計を管理するには、各サイト固有の要件の複雑さに細心の注意を払う必要があり、より高い管理負荷を要する場合があります。さらに、各ZPLSモジュールは一度に1つのサイトにしか割り当てられないため、サバイバビリティを有効にした各サイトには1つのZPLSモジュールと1つのライセンスが必要となり、よりリソース集約的な構成になる可能性があります。 {% hint style="info" %} マルチサイト設計では、どのサイトをサバイバビリティ用に構成するかをお客様の声が柔軟に選択できます。サイト *なく* ZPLSモジュールは、標準接続が回復するまで発信も着信もできないままになります。 {% endhint %} ### ネットワーク障害 #### サイトのローカルネットワークが失敗した場合、サバイバビリティに影響が及ぶ可能性があります ZPLSモジュールはサービスに影響を及ぼす事象中にローカル電話のサバイバビリティを提供するよう設計されていますが、サイトのローカルネットワークが失敗するとサバイバビリティに影響する可能性があります。これらのシナリオは以下の2つのセクションで説明します。 #### シングルサイトのローカルネットワーク障害 シングルサイト設計では、1つ以上の建物がローカルネットワークまたはキャンパスエリアネットワークを介して接続され、Zoom Phone内では1つのサイトとして表されます。この構成では、建物間通信に外部ネットワーク（たとえばインターネット）への依存がなく、位置情報内のすべてのユーザーと建物の間に共通ネットワークがあることを前提としています。 このサイト設計では、1つのZPLSモジュールだけで、1つのサイトまたは位置情報内のすべてのユーザーにローカルサバイバビリティを提供できます。ただし、この設計は、建物間通信に影響するローカルネットワークまたはキャンパスネットワークの障害が発生した場合に脆弱です。以下の例では、ローカルネットワーク障害がシングルサイト展開にどのように影響するかを説明します。
{% hint style="success" %} **例:** ある企業は、キャンパスエリアネットワークで接続されたA、B、Cの建物で構成される1つのZoom Phoneサイト向けにZPLSモジュールを展開しています。ZPLSモジュールは建物Aで稼働しており、PSTN経由の外部通話用にSBCへ接続されています。 **ではありません** PSTN経由の外部通話用にSBCへ接続されています。 外部インターネットサービスの障害またはサービスに影響する事象が発生した場合でも、サイト内のどのユーザーも、両方のユーザーがキャンパスエリアネットワークを通じてZPLSモジュールへの接続を維持している限り、同じサイト内の別のユーザーに通話できます。 *同じ* サイト ただし、キャンパスエリアネットワーク障害が発生すると、建物A内のZPLSモジュールに到達できなくなるため、建物BおよびCのユーザーは通話できません。その結果、建物BおよびCのユーザーは、サバイバビリティ通話のためにキャンパスエリアネットワークが復旧するまで待つ必要があります。 {% endhint %} 次の表は、複数の建物を含むシングルサイト設計におけるZoom Phoneのサバイバビリティを示しています: | 建物から発信された通話 | 外部インターネット障害時に到達できる場所 | キャンパスネットワーク障害時に到達できる場所 | | ------------ | -------------------- | ---------------------- | | 建物A（ZPLSホスト） | ☑️ 建物A、B、C | ☑️ 建物A *のみ* | | 建物B | ☑️ 建物A、B、C | ✖️ | | 建物C | ☑️ 建物A、B、C | ✖️ | #### SBCなしのマルチサイトローカルネットワーク障害 マルチサイト設計では、各建物または位置情報（例: フロア、サテライトオフィスなど）が、Zoom Phone内で個別の独自サイトとして表されます。この構成では、各サイトにZPLSモジュールがあり、サイトが共通のキャンパスエリアネットワークで接続されていることを前提としています。 このサイト設計では、各サイトが独自のZPLSモジュールをサポートするため、サバイバビリティモードが有効なとき、同じ建物内のユーザー同士が通話できます。さらに、ZPLSモジュールを備えた複数のサイトが共通ネットワークで接続されている場合、ローカルネットワークが正常に動作している限り、ユーザーは \_他のサイト\_ のユーザーに通話できます。ただし、この設計は、建物間通信に影響するキャンパスエリアネットワーク障害が発生した場合に脆弱です。以下の例では、キャンパスネットワーク障害がマルチサイト展開にどのように影響するかを説明します。
{% hint style="success" %} **例:** ある企業は、A、B、Cの建物で構成される自社キャンパス内にZPLSモジュールを展開しています。各建物はZoom Phone内で独自のサイトであり、サイト固有のZPLSモジュールを維持しています。キャンパス内のすべての建物は、建物間通信に外部インターネットサービスを必要としないキャンパスエリアネットワークで接続されています。 この例では、外部インターネットサービスの障害、キャンパスネットワーク障害、またはサービスに影響する事象が発生した場合、サイト内のユーザーは同じサイト内の別のユーザーに通話できます。ただし、各建物が独自のサイトであり、ユーザーがサイト固有のモジュールに登録するため、キャンパスネットワークが失敗すると、ZPLSモジュールはサイト間通話を中継できません。代わりに、ユーザーはローカルサイト内の他のユーザーへの通話に制限されます。 {% endhint %} 次の表は、相互接続されたキャンパスネットワークを持つマルチサイト設計における、上記の例での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接続と統合したマルチサイト設計の顧客は、 [通話転送が有効であれば](#_2v7qst7vxwaa)サイト間通話を有効にできます。構成されると、サバイバビリティモード中の通話は、ユーザーのクライアントからPSTNへ、次のサイトのSBCおよびZPLSモジュールへとルーティングされ、最終的に着信先のデバイスに到達します。次の図は、この構成の概要を示しています:
{% hint style="danger" %} この構成 **必要とします** 構成されたSBCでのE.164電話番号処理。 {% endhint %} 次の表も、独立した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モジュールへの登録を試みます。 {% hint style="success" %} **例:** マルチサイトのキャンパス内のユーザーは建物A（サイトA）を拠点としており、会議のため一時的に建物B（サイトB）へ移動します。建物Bにいる間にサービスに影響する事象が発生し、サバイバビリティモードが有効になります。ユーザーは建物Bにいますが、サイトAがホームサイトであるため、ユーザーのクライアントは建物A内のホームサイトにプロビジョニングされたZPLSモジュールへの接続を試みます。 このシナリオでは、ユーザーのサバイバビリティ状態は、ユーザーデバイスがキャンパスエリアネットワークを介してホームサイト内のZPLSモジュールに登録できるかどうかで決まります。ユーザーがホームサイトを離れている間にキャンパスエリアネットワークが停止している場合、そのユーザーはサバイバビリティモジュールの恩恵を受けられません。 {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://library.zoom.com/technical-library/ja/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.