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

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

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

#### <mark style="color:青;">お客様は、サポートされているハイパーバイザー上で実行されている仮想マシンに Zoom Node ソフトウェアをインストールする必要があります</mark>

Zoom Node のワークロードとして、ZPLS モジュールは Zoom Node プラットフォーム上で実行される仮想マシンに、 [サポートされているハイパーバイザー](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server)にインストールする必要があります。Zoom Node という製品の詳細は [付録に](#_a2lvsihjp0ek).

#### <mark style="color:青;">記載されています。お客様は、ハードウェア機能に応じて 2 つの設定オプションのいずれかを選択できます</mark>

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

|                | 設定オプション 1                                    | 設定オプション 2                                     |
| -------------- | -------------------------------------------- | --------------------------------------------- |
| **ハードウェア仕様**   | <p>8 CPU</p><p>16 GB RAM</p><p>80 GB HDD</p> | <p>16 CPU</p><p>16 GB RAM</p><p>80 GB HDD</p> |
| **総登録数**       | 2000                                         | 5000                                          |
| **最大同時通話数**    | 240                                          | 480                                           |
| **1 秒あたりの通話数** | 2                                            | 4                                             |
| **1 秒あたりの登録数** | 60                                           | 400                                           |

{% hint style="info" %}
サバイバビリティを有効にしたサイト内のエンドポイント数が、そのサイトの展開能力を超える場合、ZPLS モジュールは先着順で登録を処理します。お客様には、追加のモジュールを追加するか、Zoom Phone Policy 設定を使用することをお勧めします [**ローカルサバイバビリティモード**](#_ah8xua8wdq10) どのユーザーがサバイバビリティ フェイルオーバーをサポートするかを優先順位付けするためです。
{% endhint %}

### モジュールのスケーリングと冗長性

#### <mark style="color:青;">ZPLS モジュールは、追加のスケーリングや冗長性のためにクラスタリングをサポートします</mark>

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

{% hint style="info" %}
この機能は現在ベータ版であり、有効化には技術サポートチケットが必要です。
{% endhint %}

#### <mark style="color:青;">スケーリングにより、サイトでサポートされるデバイス機能が増加します</mark>

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

#### <mark style="color:青;">冗長性は、耐障害性のために追加のモジュールを加えますが、サイトのデバイス機能を拡張するものではありません</mark>

ZPLS モジュールが冗長性の目的で使用される場合、冗長モジュールはサポートされる内線数の合計には含まれません。代わりに、モジュールは「ホットスタンバイ」として待機し、プライマリ モジュールが失敗した場合にのみ動作します。たとえば、1 つのプライマリ モジュールと 1 つの冗長モジュールで合計 5,000 件の登録をサポートするため、プライマリ モジュールが失敗しても、冗長モジュールがサポート上限を超えるデバイスで過剰に割り当てられることはありません。

#### <mark style="color:青;">スケーリングと冗長性を伴う ZPLS の展開例</mark>

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

{% hint style="success" %}
**例**:

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

最初の 2 つのモジュールはそれぞれ 5,000 件の登録をサポートできるため、合計で最大 10,000 件の登録能力があります。ただし、耐障害性の重要性を認識し、病院はプライマリ モジュールの冗長バックアップとしてさらに 2 つのモジュールも展開しています。

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

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

#### <mark style="color:青;">サイトは、共通のテレフォニー設定とポリシーのために、位置情報ごとに Zoom Phone ユーザーをまとめます</mark>

A **サイト** とは、Zoom Phone 内で使用される特定の用語で、共通のアクセスコード、住所、SIP Zone、部署、またはポリシーなどの共有特性を持つユーザーを、Zoomウェブポータル内の単一の管理しやすいグループにまとめます。一部のお客様では、単一のサイトがビジネス内のすべてのユーザーを表し、キャンパスや位置情報内の複数の建物にまたがる場合があります。別のお客様では、ビジネス ニーズに応じて複数のサイトが必要になる場合があります。サイトまたはサイト管理の詳細については、 [Zoom のヘルプセンターを参照してください](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).

#### <mark style="color:青;">Zoom Phone は単一サイト設計と複数サイト設計をサポートします</mark>

アカウント内で Zoom Phone サイトを設定するには、主に 2 つの設計があります。

1. **単一サイト**: 1 つの Zoom Phone サイト内で、アカウント内のすべてのユーザーを表し、複数の建物や位置情報にまたがる場合もあります。
2. **複数サイト**: ユーザーのセグメントを位置情報、建物、部署、または機能ごとに個別に表し、それぞれ独自のサイトを持ちます。

<div data-with-frame="true"><img src="/files/79ecfcb663358abe0b389aa9704c465f653f54b7" alt=""></div>

{% hint style="info" %}
現在の Zoom お客様のアカウント管理者は、現在のサイト設計を [**会社情報**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) ページで確認できます。これは **電話システム管理** Web ポータルのメニューで利用できます。
{% endhint %}

#### <mark style="color:青;">各 ZPLS モジュールは一度に 1 つのサイトにのみ関連付けることができます</mark>

前述のとおり、ZPLS モジュールは [第 3 優先のレジストラ](#_7itj40mx1dut) であり、プライマリおよびセカンダリの SIP Zone の後に続きます。デバイスは起動時に SRV リストを受信し、これらのリストはサイトの設定に紐づいているため、 **各 ZPLS モジュールは一度に 1 つのサイトにのみ関連付けることができます**.

#### <mark style="color:青;">各サイトでは同時に最大 20 個の ZPLS モジュールをサポートできます</mark>

各 ZPLS モジュールは一度に 1 つのサイトにのみ関連付けることができますが、1 つのサイトで 1 グループあたり最大 20 個の ZPLS モジュールをサポートでき、各サイトのサバイバビリティ機能を拡張します。

{% hint style="info" %}
この機能は現在ベータ版であり、有効化には技術サポートチケットが必要です。
{% endhint %}

#### <mark style="color:青;">ZPLS モジュールは、モジュールが共通ネットワークに接続されている場合、サイト間通話をサポートします</mark>

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

{% hint style="info" %}
この機能は現在ベータ版であり、有効化には技術サポートチケットが必要です。
{% endhint %}

#### <mark style="color:青;">ZPLS を展開する前に、アカウントはどのサイト構成がニーズに最も適しているかを理解しておく必要があります</mark>

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

#### <mark style="color:青;">単一サイト設計は管理が簡単で、1 つの ZPLS モジュールでサバイバビリティを提供しますが、ユーザー設定やポリシーの柔軟性は低くなります</mark>

単一サイト設計では、アカウント内のすべてのユーザーを 1 つの統合されたグループにまとめることで、Zoom Phone の設定とポリシーの管理を効率化できます。この単一のユーザー グループは、わかりやすい管理と複雑さの軽減を実現し、管理プロセスを簡素化します。さらに、単一サイト設計では、サイトのユーザー数が [単一モジュールの](#_rx0i1j9xofnc).

機能を超えない限り、1 つの ZPLS モジュールでローカル電話のサバイバビリティを提供できます。ただし、単一サイト設計の単純さには当然ながら制限もあります。具体的には、単一サイト設計は「すべてに当てはまる」性質のため柔軟性が低く、さまざまなニーズを持つ複数の部署にわたるすべての展開シナリオに適するとは限りません。さらに、単一サイト展開は、 [ローカル ネットワークが失敗した場合](#_gzpf5m70jl3i).

#### <mark style="color:青;">複数サイト設計は、ユーザー設定とポリシーにより高い柔軟性を提供しますが、サバイバビリティを有効にしたサイトごとに 1 つの ZPLS モジュールが必要であり、管理はより複雑になります</mark>

複数サイト設計では、きめ細かな設定制御を備えたさまざまなグループにユーザーを分けることで、ユーザー設定とポリシーの柔軟性をさらに高めることができます。この設計により、組織は通信構成を詳細に調整して、さまざまなサイトにわたる特定の要件を満たすことができ、さまざまな部署、シナリオ、またはニーズに対してより洗練された適応性の高いユーザー体験を実現します。さらに、複数サイト展開では [サイト間通信](#_a42hwaw1pfmx) を、サイトが共通ネットワークで接続されている場合にサポートできます。

ただし、複数サイト設計の管理には、各サイト固有の要件を慎重に把握する必要があり、そのため、より高いレベルの管理作業が必要になる場合があります。さらに、各 ZPLS モジュールは一度に 1 つのサイトにしか割り当てられないため、サバイバビリティを有効にした各サイトには 1 つの ZPLS モジュールとライセンスが必要となり、よりリソースを要するセットアップになる可能性があります。

{% hint style="info" %}
複数サイト設計では、お客様はサバイバビリティ用にどのサイトを設定するかを柔軟に選択できます。サイト *なしで* ZPLS モジュールは、標準の接続が復元されるまで、通話の発信または着信を行えません。
{% endhint %}

### ネットワーク障害

#### <mark style="color:青;">サイトのローカル ネットワークに障害が発生すると、サバイバビリティに影響が出る可能性があります</mark>

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

#### <mark style="color:青;">単一サイトのローカル ネットワーク障害</mark>

単一サイト設計では、1 つまたは複数の建物がローカル ネットワークまたはキャンパス エリア ネットワークを通じて接続され、Zoom Phone 内では 1 つのサイトとして表されます。この構成では、建物間の通信に外部ネットワーク依存（たとえばインターネット）がない状態で、1 つの位置情報内のすべてのユーザーと建物が共通ネットワークを使用していることを前提としています。

このサイト設計では、ビジネスは 1 つのサイトまたは位置情報内のすべてのユーザーに対して、最小 1 つの ZPLS モジュールでローカル サバイバビリティを提供できます。ただし、建物間通信に影響を及ぼすローカル ネットワークやキャンパス ネットワークの障害が発生した場合、この設計は脆弱です。以下の例では、ローカル ネットワーク障害が単一サイト展開にどのように影響するかを示します。

<div data-with-frame="true"><img src="/files/199a38ee2b36bb257e63255df69d9fcb50ac7554" alt=""></div>

{% hint style="success" %}
**例:**

ある企業が、キャンパス エリア ネットワークで接続された建物 A、B、C から成る 1 つの Zoom Phone サイトに ZPLS モジュールを展開しています。ZPLS モジュールは建物 A で動作しており、 **ない** 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               | ✖️                          |

#### <mark style="color:青;">SBC なしの複数サイトのローカル ネットワーク障害</mark>

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

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

<div data-with-frame="true"><img src="/files/7b9e15101d9e8b36af23f045e7c9c775510a6d38" alt=""></div>

{% 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                     |

#### <mark style="color:青;">ローカル ネットワークが失敗した場合、各サイトが SBC に接続され、通話転送が有効になっていれば、PSTN を介したサイト間通話もサポートされます</mark>

ローカル ネットワーク障害が発生した場合、各サイトに ZPLS モジュールを SBC および PSTN 接続と統合した複数サイト設計のお客様は、以下の条件でサイト間通話を有効にできます [通話転送が有効になっている場合](#_2v7qst7vxwaa)。設定すると、サバイバビリティ モード中に発信された通話は、ユーザーのクライアントから PSTN、2 つ目のサイトの SBC と ZPLS モジュールを経由して、最終的に着信先のデバイスに到達します。以下の図はこの構成の概要を示しています。

<div data-with-frame="true"><img src="/files/4ab6f39d29411ba3c6ca28d22ca02a11d2734561" alt=""></div>

{% 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                  |

#### <mark style="color:青;">ノマディック ユーザーは常に自分のホーム サイトに関連付けられた ZPLS モジュールに登録します</mark>

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

{% hint style="success" %}
**例:**

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

このシナリオでは、ユーザーのサバイバビリティ ステータスは、ユーザーデバイスがキャンパス エリア ネットワーク全体で自分のホーム サイト内の ZPLS モジュールに登録できるかどうかによって決まります。ユーザーがホーム サイトから離れている間にキャンパス エリア ネットワークが停止すると、ユーザーはサバイバビリティ モジュールの恩恵を受けることができません。
{% endhint %}


---

# Agent Instructions: 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:

```
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=<question>
```

The question should be specific, self-contained, and written in natural language.
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.