# Överväganden för hårdvaruinstallation

Denna sida beskriver distributionen av Zoom Node ZPLS-modulen på en virtuell maskin med hjälp av stödjda hypervisorer. Den ger detaljerade konfigurationsalternativ som är anpassade för att rymma olika maskinvarukapaciteter och säkerställer optimal prestanda för olika driftbehov.

### Stödda hypervisorer

#### <mark style="color:blå;">Kunder måste installera Zoom Node-programvaran på en virtuell maskin som körs på en stödd hypervisor</mark>

Som en Zoom Node-arbetsbelastning måste ZPLS-modulen installeras på en virtuell maskin som kör Zoom Node-plattformen, på en [stödd hypervisor](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Mer information om Zoom Node som produkt finns [i bilagan](#_a2lvsihjp0ek).

#### <mark style="color:blå;">Kunder kan välja ett av två konfigurationsalternativ beroende på maskinvarukapaciteter</mark>

ZPLS-modulen stöder två konfigurationer beroende på den virtuella maskinens maskinvarukapaciteter. Dessa kapaciteter anges nedan:

|                                 | Konfigurationsalternativ 1                   | Konfigurationsalternativ 2                    |
| ------------------------------- | -------------------------------------------- | --------------------------------------------- |
| **Maskinvaruspecifikationer**   | <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> |
| **Totalt antal registreringar** | 2000                                         | 5000                                          |
| **Maximala samtidiga samtal**   | 240                                          | 480                                           |
| **Samtal per sekund**           | 2                                            | 4                                             |
| **Registreringar per sekund**   | 60                                           | 400                                           |

{% hint style="info" %}
Om antalet ändpunkter inom en plats med aktiverad överlevnadsfunktion överstiger platsens distributionskapacitet kommer ZPLS-modulen att bearbeta registreringar enligt principen först till kvarn. Kunder rekommenderas att lägga till ytterligare moduler eller använda inställningen Zoom Phone Policy [**Local Survivability Mode**](#_ah8xua8wdq10) för att prioritera vilka användare som stöder överlevnadsfailover.
{% endhint %}

### Modulskalning och motståndskraft

#### <mark style="color:blå;">ZPLS-moduler stödjer klustring för ytterligare skalning och/eller motståndskraft</mark>

Kunder kan gruppera ZPLS-moduler tillsammans med upp till 20 moduler per plats (eller 100 totala Node-enheter per konto) för ytterligare redundans eller skalning.

{% hint style="info" %}
Denna funktion är för närvarande i beta och kräver ett tekniskt supportärende för att aktiveras.
{% endhint %}

#### <mark style="color:blå;">Skalning ökar en plats stödda enhetskapaciteter</mark>

Att utöka antalet ZPLS-moduler förbättrar kapaciteten för varje plats linjärt för varje ytterligare modul. Till exempel, om en modul stöder totalt 5 000 registreringar, kommer distribution av fem moduler att höja stödet till 25 000 registreringar.

#### <mark style="color:blå;">Redundans lägger till ytterligare moduler för motståndskraft, men skalar inte en plats enhetskapaciteter</mark>

När en ZPLS-modul används för redundansändamål bidrar de redundanta modulerna inte till det totala antalet stödda anknytningar. Istället är modulerna i "hot standby" och kommer endast att aktiveras om primära moduler fallerar. Till exempel, en primär och en redundant modul stöder totalt 5 000 registreringar, så om en primär modul fallerar blir inte den redundanta modulen överbelastad med enheter utöver dess stödda gräns.

#### <mark style="color:blå;">Exempel på distribution av ZPLS med skalning och redundans</mark>

För enkelhets skull visar följande exempel distribution med ytterligare skalning och redundans.

{% hint style="success" %}
**Exempel**:&#x20;

Ett sjukhus måste stödja upp till 10 000 registrerade anknytningar för överlevnad. För att uppnå detta distribuerar sjukhuset fyra ZPLS-moduler.

De första två modulerna kan vardera stödja 5 000 registreringar, vilket resulterar i en total kapacitet på upp till 10 000 registreringar. Men med hänsyn till vikten av motståndskraft distribuerar sjukhuset även två ytterligare moduler som redundanta backuper till de primära modulerna.

I detta scenario har sjukhuset nu primär och sekundär överlevnadshårdvara distribuerad. Om en primär modul skulle drabbas av fel kommer den/de redundanta modulerna att ta över för att upprätthålla oavbruten service, samtidigt som de fortsätter att stödja upp till 10 000 registrerade enheter.
{% endhint %}

### Överväganden vid platsdesign

#### <mark style="color:blå;">Platser grupperar Zoom Phone-användare efter plats för gemensamma telefoninställningar och policyer</mark>

En **site** är en specifik term som används inom Zoom Phone som grupperar användare med gemensamma egenskaper — som en gemensam åtkomstkod, adress, SIP-zon, avdelning eller policyer — till en enda hanterbar grupp i Zooms webbportal. För vissa kunder kan en enda plats representera alla användare inom deras verksamhet och kan omfatta flera byggnader inom en campus eller plats; för andra kan flera platser krävas beroende på verksamhetens behov. För mer information om platser eller platshantering, [se Zooms supportcenter](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).

#### <mark style="color:blå;">Zoom Phone stöder design för en plats och flera platser</mark>

Det finns två huvudsakliga designmönster för att konfigurera Zoom Phone-platser inom ett konto:

1. **En plats**: Representerar alla användare inom ett konto, potentiellt spridda över flera byggnader eller platser, inom en enda Zoom Phone-plats.
2. **Flera platser**: Representerar segment av användare efter plats, byggnad, avdelning eller funktion separat, var och en med sin egen plats.

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/oIvxHDcxrmw7DhWRyObf/Unknown%20image" alt=""></div>

{% hint style="info" %}
Kontoadministratörer hos befintliga Zoom-kunder kan kontrollera sin nuvarande platsdesign genom [**Företagsinfo**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) sidan, tillgänglig i **Telefonisystemhantering** menyn i webbportalen.
{% endhint %}

#### <mark style="color:blå;">Varje ZPLS-modul kan bara associeras med en plats åt gången</mark>

Som tidigare nämnts är en ZPLS-modul den [tredjeprioriterade registrar](#_7itj40mx1dut) för stödda enheter, bakom primära och sekundära SIP-zoner. Eftersom enheterna får sina SRV-listor under uppstartsprocessen och dessa listor är knutna till deras platsinställning, **kan varje ZPLS-modul bara associeras med en plats åt gången**.

#### <mark style="color:blå;">Varje plats kan stödja upp till 20 ZPLS-moduler samtidigt</mark>

Även om varje ZPLS-modul bara kan associeras med en plats åt gången kan en plats stödja upp till 20 ZPLS-moduler i en grupp, vilket utökar varje plats överlevnadskapacitet.

{% hint style="info" %}
Denna funktion är för närvarande i beta och kräver ett tekniskt supportärende för att aktiveras.
{% endhint %}

#### <mark style="color:blå;">ZPLS-moduler stödjer samtal mellan platser om modulerna är anslutna till ett gemensamt nätverk</mark>

ZPLS-moduler från olika platser stödjer samtal mellan platser under en överlevnadshändelse så länge enheterna är upptäckbara inom det lokala nätverket. Till exempel, om ett företagscampus har tre byggnader, var och en med sin egen telefonplats, kan ZPLS-modulerna från varje plats ansluta plats-till-plats-samtal över campusets nätverk.

{% hint style="info" %}
Denna funktion är för närvarande i beta och kräver ett tekniskt supportärende för att aktiveras.
{% endhint %}

#### <mark style="color:blå;">Innan distribution av ZPLS bör konton förstå vilken platskonfiguration som passar deras behov bäst</mark>

Eftersom varje ZPLS-modul bara kan associeras med en plats åt gången är platsdesign en av de viktigaste faktorerna vid distribution av ZPLS-tjänsten inom ett konto. Av denna anledning bör kunder förstå vilken platskonfiguration som är bäst för att möta deras praktiska affärs- och överlevnadsbehov, eftersom varje ytterligare plats som aktiveras för överlevnad kommer att kräva minst en ytterligare ZPLS-modul.

#### <mark style="color:blå;">En en-plats-design är enklare att hantera och ger överlevnad med en enda ZPLS-modul, men erbjuder mindre flexibilitet för användarinställningar och policyer</mark>

En en-plats-design hjälper till att förenkla hanteringen av Zoom Phone-inställningar och policyer genom att konsolidera alla användare inom ett konto under en enda, enhetlig grupp. Denna enda användargrupp erbjuder företag enkel administration och minskad komplexitet, vilket förenklar hanteringsprocessen. Dessutom kan en en-plats-design erbjuda lokal telefonsöverlevnad med en enda ZPLS-modul, så länge platsens användare inte överskrider [kapaciteten hos en enstaka modul](#_rx0i1j9xofnc).

Men enkelheten hos en en-plats-design innebär naturligtvis begränsningar. Specifikt erbjuder en-plats-designs mindre flexibilitet på grund av deras "en storlek passar alla"-natur, vilket kanske inte passar alla distributionsscenarier över flera avdelningar med varierande behov. Vidare kan en-plats-distributioner vara sårbara i vissa överlevnadsscenarier om [det lokala nätverket fallerar](#_gzpf5m70jl3i).

#### <mark style="color:blå;">En flerpatsdesign erbjuder mer flexibilitet för användarinställningar och policyer, men kräver en ZPLS-modul för varje plats med aktiverad överlevnad och är mer komplicerad att hantera</mark>

En flerpatsdesign erbjuder företag ytterligare flexibilitet i användarinställningar och policyer genom att separera användare i olika grupper med granulära inställningskontroller. Denna design gör det möjligt för organisationer att noggrant justera kommunikationskonfigurationer för att möta specifika krav över olika platser, vilket resulterar i en mer förfinad och anpassningsbar användarupplevelse för olika avdelningar, scenarier eller behov. Dessutom kan flerpatsdistributioner stödja [kommunikation mellan platser](#_a42hwaw1pfmx) om platserna är anslutna via ett gemensamt nätverk.

Att hantera en flerpatsdesign kräver dock noggrann uppmärksamhet på varje plats unika krav, vilket kan kräva en högre nivå av administrativ insats. Dessutom, eftersom varje ZPLS-modul bara kan tilldelas en plats åt gången, kommer varje plats med aktiverad överlevnad att kräva en ZPLS-modul och licens, vilket kan bidra till en mer resursintensiv uppsättning.

{% hint style="info" %}
I en flerpatsdesign har kunder flexibilitet att välja vilka platser som kommer att konfigureras för överlevnad. Platser *utan* en ZPLS-modul kommer att förbli oförmögen att ringa eller ta emot samtal tills standardanslutningen återställs.
{% endhint %}

### Nätverksfel

#### <mark style="color:blå;">Överlevnad kan påverkas om en plats lokala nätverk fallerar</mark>

Även om ZPLS-moduler är utformade för att tillhandahålla lokal telefonsöverlevnad under servicepåverkande händelser kan överlevnaden påverkas om en plats lokala nätverk fallerar. Dessa scenarier beskrivs i följande två avsnitt.

#### <mark style="color:blå;">En-plats lokalt nätverksfel</mark>

I en en-plats-design är en eller flera byggnader anslutna via ett lokalt eller campusnätverk och representeras av en enda plats inom Zoom Phone. Denna konfiguration förutsätter ett gemensamt nätverk mellan alla användare och byggnader inom en plats, utan externa nätverksberoenden (t.ex. internet) för kommunikation mellan byggnader.

Med denna platsdesign kan ett företag erbjuda lokal överlevnad till alla användare inom en enda plats eller plats med så lite som en ZPLS-modul; dock är denna design sårbar vid ett lokalt eller campusnätverksavbrott som påverkar kommunikation mellan byggnader. Följande exempel beskriver hur ett lokalt nätverksfel kan påverka en en-plats-distribution.

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/Ri12tqNIQd9vtbMpNzqe/Unknown%20image" alt=""></div>

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

Ett företag distribuerar ZPLS-modulen för en enda Zoom Phone-plats bestående av byggnaderna A, B och C, som är anslutna via ett campusnätverk. ZPLS-modulen är i drift i byggnad A och är **inte** ansluten till en SBC för externa samtal över PSTN.

Vid ett externt internetavbrott eller en servicepåverkande händelse kan vilken användare som helst inom platsen ringa en annan användare inom *samma* plats, så länge båda användarna behåller anslutning till ZPLS-modulen via campusnätverket.

Men vid ett campusnätverksavbrott kan användare i byggnaderna B och C inte ringa medan ZPLS-modulen i byggnad A är otillgänglig. Följaktligen måste användare i byggnaderna B och C vänta tills campusnätverket återställs för samtal under överlevnad.
{% endhint %}

Följande tabell visar Zoom Phone-överlevnad i en flervånings en-plats-design:

| Samtal som härstammar från byggnad | Kan nå dessa platser vid ett externt internetavbrott | Kan nå dessa platser vid ett campusnätverksavbrott |
| ---------------------------------- | ---------------------------------------------------- | -------------------------------------------------- |
| Byggnad A (ZPLS-värd)              | ☑️ Byggnaderna A, B och C                            | ☑️ Endast byggnad A *endast*                       |
| Byggnad B                          | ☑️ Byggnaderna A, B och C                            | ✖️                                                 |
| Byggnad C                          | ☑️ Byggnaderna A, B och C                            | ✖️                                                 |

#### <mark style="color:blå;">Flerplats lokalt nätverksfel utan SBC</mark>

I en flerpatsdesign representeras varje byggnad eller plats (t.ex. våning, filialkontor osv.) oberoende av en unik plats inom Zoom Phone. Denna konfiguration förutsätter att varje plats har en ZPLS-modul och att platserna är anslutna via ett gemensamt campusnätverk.

Med denna platsdesign stödjer varje plats sin egen ZPLS-modul, vilket tillåter användare inom samma byggnad att ringa varandra när överlevnadsläge är aktiverat. Vidare, när flera platser med en ZPLS-modul är anslutna via ett gemensamt nätverk, kan användare ringa användare på andra platser, så länge det lokala nätverket förblir operativt. Dock är denna design sårbar vid ett campusnätverksavbrott som påverkar kommunikation mellan byggnader. Följande exempel beskriver hur ett campusnätverksfel kan påverka en flerpatsdistribution.

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/YleKIF0uXoN12c2dmNNB/Unknown%20image" alt=""></div>

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

Ett företag distribuerar ZPLS-modulen inom sitt flervåningscampus bestående av byggnaderna A, B och C. Varje byggnad är en unik plats inom Zoom Phone och har en platspecifik ZPLS-modul. Alla byggnader på campus är anslutna via ett campusnätverk som inte är beroende av extern internetservice för kommunikation mellan byggnader.

I detta exempel, vid ett externt internetavbrott, campusnätverksavbrott eller annan servicepåverkande händelse, kan vilken användare som helst inom en plats ringa en annan användare inom samma plats. Men eftersom varje byggnad är en unik plats och användare registrerar sig till sina plats-specifika moduler, kan ZPLS-modulerna inte transportera samtal mellan platser om campusnätverket fallerar. Istället begränsas användare till att ringa andra användare inom sin lokala plats.
{% endhint %}

Följande tabell visar Zoom Phone-överlevnad från ovanstående exempel i en flerpatsdesign med ett sammankopplat campusnätverk:

| Samtal som härstammar från byggnad | Kan nå dessa platser vid ett externt internetavbrott | Kan nå dessa platser vid ett campusnätverksavbrott |
| ---------------------------------- | ---------------------------------------------------- | -------------------------------------------------- |
| Byggnad A (ZPLS-värd)              | ☑️ Byggnaderna A, B och C                            | ☑️ Endast byggnad A                                |
| Byggnad B (ZPLS-värd)              | ☑️ Byggnad A, B och C                                | ☑️ Endast byggnad B                                |
| Byggnad C (ZPLS-värd)              | ☑️ Byggnad A, B och C                                | ☑️ Endast byggnad C                                |

#### <mark style="color:blå;">Om ett lokalt nätverk fallerar stöds även samtal mellan platser via PSTN, förutsatt att varje plats är ansluten till en SBC och har vidarekoppling aktiverad</mark>

Vid ett lokalt nätverksfel kan kunder med en flerpatsdesign som integrerar ZPLS-modulen med en SBC och PSTN-anslutning på varje plats möjliggöra plats-till-plats-samtal om [vidarekoppling är aktiverad](#_2v7qst7vxwaa). När det är konfigurerat kommer telefonsamtal som ringts under överlevnadsläge att dirigeras från användarens klient till PSTN, till den andra platsens SBC och ZPLS-modul och slutligen till mottagarens enhet. Följande diagram ger en översikt över denna konfiguration:

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/TxOX1dZyselC2SFLiXSu/Unknown%20image" alt=""></div>

{% hint style="danger" %}
Denna konfiguration **kräver** E.164-telefonnummerhantering på de konfigurerade SBC:arna.
{% endhint %}

Följande tabell visar också Zoom Phone-överlevnad i en flerpatsdesign med oberoende SBC:ar:

| Samtal som härstammar från byggnad | Kan nå dessa platser vid ett externt internetavbrott | Kan nå dessa platser vid ett campusnätverksavbrott |
| ---------------------------------- | ---------------------------------------------------- | -------------------------------------------------- |
| Byggnad A (ZPLS-värd)              | ☑️ Byggnaderna A, B och C                            | ☑️ Byggnaderna A, B och C                          |
| Byggnad B (ZPLS-värd)              | ☑️ Byggnaderna A, B och C                            | ☑️ Byggnaderna A, B och C                          |
| Byggnad C (ZPLS-värd)              | ☑️ Byggnaderna A, B och C                            | ☑️ Byggnaderna A, B och C                          |

#### <mark style="color:blå;">Nomadiska användare registrerar sig alltid till ZPLS-modulen som är associerad med deras hemplats</mark>

När användare eller enheter läggs till i Zoom Phone associeras en "hem"-plats statiskt med användaren eller enheten tills en kontoadministratör uppdaterar detta. Detta betyder att om en användare flyttar till en fysisk plats utanför deras associerade hemplats, som en kontorsbyggnad associerad med en annan plats, kommer Zoom inte att dynamiskt justera platsen bunden till användaren. Följaktligen, om användaren förlorar anslutning till Zoom Phone-datacenter kommer användaren att försöka registrera sig till ZPLS-modulen som är associerad med deras hemplats, även om de befinner sig på en annan plats.

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

En användare i ett flerpatscampus är baserad i byggnad A (plats A) och flyttar tillfälligt till byggnad B (plats B) för ett möte. Medan de befinner sig i byggnad B inträffar en servicepåverkande händelse och överlevnadsläge aktiveras. Även om användaren är i byggnad B, eftersom plats A är deras hemplats kommer användarens klient att försöka ansluta till ZPLS-modulen som tillhandahålls vid deras hemplats i byggnad A.

I detta scenario avgörs en användares överlevnadsstatus av användarenhetens förmåga att registrera sig till ZPLS-modulen på deras hemplats via campusnätverket. Om campusnätverket är nere medan användaren är borta från sin hemplats kan användaren inte dra nytta av överlevnadsmodulen.
{% endhint %}