> 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/sv/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md).
# Överväganden för distribution av hårdvara
Den här sidan beskriver distributionen av Zoom Node ZPLS-modulen på en virtuell maskin med hypervisorer som stöds. Den innehåller detaljerade konfigurationsalternativ anpassade för att hantera olika hårdvarufunktioner, vilket säkerställer optimal prestanda för olika operativa behov.
### Hypervisorer som stöds
#### Kunder måste installera Zoom Node-programvaran på en virtuell maskin som körs på en hypervisor som stöds
Som en Zoom Node-arbetsbelastning måste ZPLS-modulen installeras på en virtuell maskin som kör Zoom Node-plattformen, på en [hypervisor som stöds](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).
#### Kunder kan välja ett av två konfigurationsalternativ, beroende på hårdvarufunktioner
ZPLS-modulen stöder två konfigurationer, beroende på den virtuella maskinens hårdvarufunktioner. Dessa funktioner listas nedan:
| | Konfigurationsalternativ 1 | Konfigurationsalternativ 2 |
| ----------------------------------- | -------------------------------------------- | --------------------------------------------- |
| **Hårdvaruspecifikationer** | 8 CPU
16 GB RAM
80 GB HDD
| 16 CPU
16 GB RAM
80 GB HDD
|
| **Totalt antal registreringar** | 2000 | 5000 |
| **Maximalt antal samtidiga samtal** | 240 | 480 |
| **Samtal per sekund** | 2 | 4 |
| **Registreringar per sekund** | 60 | 400 |
{% hint style="info" %}
Om antalet slutpunkter inom en plats med aktiverad survivability överskrider en plats distributionskapacitet kommer ZPLS-modulen att behandla registreringar enligt först till kvarn-principen. Kunder rekommenderas att lägga till ytterligare moduler eller använda inställningen för Zoom Phone-policy [**Lokalt survivability-läge**](#_ah8xua8wdq10) för att prioritera vilka användare som stöder failover för survivability.
{% endhint %}
### Modulskalning och resiliens
#### ZPLS-moduler stöder klustring för ytterligare skalning och/eller resiliens
Kunder kan gruppera ZPLS-moduler tillsammans med upp till 20 moduler per plats (eller 100 Node-enheter totalt per konto) för ytterligare redundans eller skalning.
{% hint style="info" %}
Den här funktionen är för närvarande i beta och kräver ett tekniskt supportärende för att aktiveras.
{% endhint %}
#### Skalning ökar en plats enhetskapacitet som stöds
Att utöka antalet ZPLS-moduler förbättrar kapaciteten för varje plats linjärt för varje ytterligare modul. Om en modul till exempel stöder totalt 5 000 registreringar kommer distribution av fem moduler att öka stödet till 25 000 registreringar.
#### Redundans lägger till ytterligare moduler för resiliens, men skalar inte en plats enhetskapacitet
När en ZPLS-modul används för redundans bidrar de redundanta modulerna inte till det totala antalet tillägg som stöds. I stället är modulerna i ”hot standby” och aktiveras endast om primära moduler slutar fungera. Till exempel stöder en primär och en redundant modul totalt 5 000 registreringar, så om en primär modul slutar fungera blir den redundanta modulen inte överbelastad med enheter utöver sin stödda gräns.
#### Exempel på distribution av ZPLS med skalning och redundans
För enkelhetens skull visar följande exempel distribution med ytterligare skalning och redundans.
{% hint style="success" %}
**Exempel**:
Ett sjukhus måste stödja upp till 10 000 registrerade anknytningar för survivability. För att uppnå detta distribuerar sjukhuset fyra ZPLS-moduler.
De två första modulerna kan stödja 5 000 registreringar vardera, vilket ger en total kapacitet på upp till 10 000 registreringar. Men med tanke på vikten av resiliens distribuerar sjukhuset också ytterligare två moduler som redundanta säkerhetskopior till de primära modulerna.
I det här scenariot har sjukhuset nu distribuerat primär och sekundär hårdvara för survivability. Om en primär modul då råkar ut för ett fel kommer de redundanta modulerna att ta över för att upprätthålla oavbruten tjänst, samtidigt som de fortsätter att stödja upp till 10 000 registrerade enheter.
{% endhint %}
### Överväganden för platsdesign
#### Platser grupperar Zoom Phone-användare tillsammans efter plats för gemensamma telefoniinställningar och policyer
En **plats** är en specifik term som används i Zoom Phone och som grupperar användare med gemensamma egenskaper — som en gemensam Access-kod, adress, SIP-zon, avdelning eller policyer — i en enda hanterbar grupp i Zoom-webbportal. För vissa Kunder kan en enda plats representera alla användare inom deras Business och omfatta flera byggnader inom ett campus eller en plats; för andra kan flera platser krävas beroende på dina affärsbehov. För mer information om platser eller platshantering, [se Zooms supportcenter](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).
#### Zoom Phone stöder designer för en plats och flera platser
Det finns två primära designer för att konfigurera Zoom Phone-platser inom ett konto:
1. **En plats**: Representerar alla användare inom ett konto, eventuellt ö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.
{% hint style="info" %}
Kontoadministratörer för nuvarande Zoom-Kunder kan kontrollera sin nuvarande platsdesign via sidan [**Företagsinfo**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) som finns i menyn **Hantering av telefonsystem** på webbportalen.
{% endhint %}
#### Varje ZPLS-modul kan endast associeras med en plats åt gången
Som tidigare nämnts är en ZPLS-modul [registrator med tredje prioritet](#_7itj40mx1dut) för enheter som stöds, efter primära och sekundära SIP-zoner. Eftersom enheter tar emot sina SRV-listor under uppstartsprocessen, och dessa listor är kopplade till platsens inställning, **kan varje ZPLS-modul endast associeras med en plats åt gången**.
#### Varje plats kan stödja upp till 20 ZPLS-moduler samtidigt
Även om varje ZPLS-modul endast kan associeras med en plats åt gången kan en plats stödja upp till 20 ZPLS-moduler i en grupp, vilket utökar survivability-kapaciteten för varje plats.
{% hint style="info" %}
Den här funktionen är för närvarande i beta och kräver ett tekniskt supportärende för att aktiveras.
{% endhint %}
#### ZPLS-moduler stöder samtal mellan platser om modulerna är anslutna till ett gemensamt nätverk
ZPLS-moduler från olika platser stöder samtal mellan platser under en survivability-händelse så länge enheterna går att upptäcka i det lokala nätverket. Om ett företagscampus till exempel har tre byggnader, var och en med sin egen telefoniplats, kan ZPLS-modulerna från varje plats koppla samtal från plats till plats över campusnätverket.
{% hint style="info" %}
Den här funktionen är för närvarande i beta och kräver ett tekniskt supportärende för att aktiveras.
{% endhint %}
#### Innan ZPLS distribueras bör konton förstå vilken platskonfiguration som passar deras behov bäst
Eftersom varje ZPLS-modul endast kan associeras med en plats åt gången är platsdesign en av de viktigaste faktorerna vid distribution av ZPLS-tjänsten inom ett konto. Därför bör Kunder förstå vilken platskonfiguration som bäst uppfyller deras praktiska affärs- och survivability-behov, eftersom varje ytterligare plats som aktiveras för survivability kräver minst en ytterligare ZPLS-modul.
#### En design med en plats är enklare att hantera och ger survivability med en enda ZPLS-modul, men erbjuder mindre flexibilitet för användarinställningar och policyer
En design med en plats hjälper till att effektivisera 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 ger företag enkel administration och minskad komplexitet, vilket förenklar hanteringsprocessen. Dessutom kan en design med en plats erbjuda lokal telefoni-survivability med en enda ZPLS-modul, så länge platsens användare inte överskrider [kapaciteten för en enda modul](#_rx0i1j9xofnc).
Enkelheten i en design med en plats innebär dock naturligt begränsningar. Mer specifikt erbjuder designer med en plats mindre flexibilitet på grund av sin ”one size fits all”-karaktär, vilket kanske inte passar alla distributionsscenarier över flera avdelningar med varierande behov. Dessutom kan distributioner med en plats vara sårbara i vissa överlevnadsscenarier om [det lokala nätverket slutar fungera](#_gzpf5m70jl3i).
#### En design med flera platser erbjuder mer flexibilitet för användarinställningar och policyer, men kräver en ZPLS-modul för varje plats med aktiverad survivability och är mer komplicerad att hantera
En design med flera platser ger företag ytterligare flexibilitet i användarinställningar och policyer genom att dela upp användare i olika grupper med detaljerade inställningskontroller. Denna design ger organisationer möjlighet att noggrant justera kommunikationskonfigurationer för att uppfylla specifika krav på olika platser, vilket resulterar i en mer förfinad och anpassningsbar användarupplevelse för olika avdelningar, scenarier eller behov. Dessutom kan distributioner med flera platser stödja [kommunikation mellan platser](#_a42hwaw1pfmx) om platserna är anslutna via ett gemensamt nätverk.
Att hantera en design med flera platser kräver dock noggrann uppmärksamhet på varje plats unika krav, vilket kan kräva en högre nivå av administrativt arbete. Eftersom varje ZPLS-modul dessutom endast kan tilldelas en plats åt gången kommer varje plats med aktiverad survivability att kräva en ZPLS-modul och licens, vilket kan bidra till en mer resursintensiv konfiguration.
{% hint style="info" %}
I en design med flera platser har Kunder flexibiliteten att välja vilka platser som ska konfigureras för survivability. Platser *utan* en ZPLS-modul kommer fortfarande inte att kunna ringa eller ta emot samtal förrän standardanslutningen återställs.
{% endhint %}
### Nätverksfel
#### Survivability kan påverkas om en plats lokala nätverk slutar fungera
Även om ZPLS-moduler är utformade för att tillhandahålla lokal telefoni-survivability under tjänstepåverkande händelser, kan survivability påverkas om en plats lokala nätverk slutar fungera. Dessa scenarier beskrivs i följande två avsnitt.
#### Fel i lokalt nätverk för en plats
I en design med en plats är en eller flera byggnader anslutna via ett lokalt nätverk 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 några externa nätverksberoenden (t.ex. internet) för kommunikation mellan byggnader.
Med denna platsdesign kan ett företag tillhandahålla lokal survivability till alla användare inom en enda plats eller plats med så lite som en ZPLS-modul; den här designen är dock sårbar vid ett avbrott i det lokala nätverket eller campusnätverket som påverkar kommunikationen mellan byggnader. Följande exempel beskriver hur ett fel i det lokala nätverket kan påverka en distribution med en plats.
{% 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 används i byggnad A och är **inte** ansluten till en SBC för extern samtalshantering via PSTN.
Vid ett fel i extern internettjänst eller en tjänstepåverkande händelse kan alla användare inom platsen ringa en annan användare inom *samma* plats, så länge båda användarna har anslutning till ZPLS-modulen via campusnätverket.
Vid ett avbrott i campusnätverket kan dock användare i byggnaderna B och C inte ringa medan ZPLS-modulen i byggnad A inte går att nå. Därför måste användare i byggnaderna B och C vänta tills campusnätverket återställs för survivability-samtal.
{% endhint %}
Följande tabell visar Zoom Phone-survivability i en design med flera byggnader och en plats:
| Samtal som kommer från byggnad | Kan nå dessa platser under ett externt internetfel | Kan nå dessa platser under ett fel i campusnätverket |
| ------------------------------ | -------------------------------------------------- | ---------------------------------------------------- |
| 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 | ✖️ |
#### Fel i lokalt nätverk för flera platser utan en SBC
I en design med flera platser representeras varje byggnad eller plats (t.ex. våning, satellitkontor osv.) självständigt 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öder varje plats sin egen ZPLS-modul, vilket gör att användare inom samma byggnad kan ringa varandra när survivability-läget aktiveras. När flera platser med en ZPLS-modul dessutom ä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 i drift. Den här designen är dock sårbar vid ett avbrott i campusnätverket som påverkar kommunikationen mellan byggnader. Följande exempel beskriver hur ett fel i campusnätverket kan påverka en distribution med flera platser.
{% hint style="success" %}
**Exempel:**
Ett företag distribuerar ZPLS-modulen inom sitt campus med flera byggnader, bestående av byggnaderna A, B och C. Varje byggnad är en unik plats inom Zoom Phone och har en platsspecifik ZPLS-modul. Alla byggnader inom campuset är anslutna via ett campusnätverk som inte är beroende av extern internettjänst för kommunikation mellan byggnader.
I det här exemplet kan alla användare som befinner sig på en plats, vid ett fel i extern internettjänst, ett avbrott i campusnätverket eller en tjänstepåverkande händelse, ringa en annan användare som befinner sig inom samma plats. Eftersom varje byggnad dock är en unik plats och användarna registrerar sig till sina platsspecifika moduler kan ZPLS-modulerna inte transportera samtal mellan platser om campusnätverket slutar fungera. I stället kommer användarna att vara begränsade till att ringa andra användare inom sin lokala plats.
{% endhint %}
Följande tabell visar också Zoom Phone-survivability från exemplet ovan i en design med flera platser med ett sammankopplat campusnätverk:
| Samtal som kommer från byggnad | Kan nå dessa platser under ett externt internetfel | Kan nå dessa platser under ett fel i campusnätverket |
| ------------------------------ | -------------------------------------------------- | ---------------------------------------------------- |
| Byggnad A (ZPLS-värd) | ☑️ Byggnaderna A, B och C | ☑️ Endast byggnad A |
| Byggnad B (ZPLS-värd) | ☑️ Byggnad A, B och C | ☑️ Byggnad B |
| Byggnad C (ZPLS-värd) | ☑️ Byggnad A, B och C | ☑️ Byggnad C |
#### Om ett lokalt nätverk slutar fungera stöds samtal mellan platser också via PSTN, förutsatt att varje plats är ansluten till en SBC och har vidarekoppling av samtal aktiverad
Vid ett fel i det lokala nätverket kan Kunder med en design med flera platser som integrerar ZPLS-modulen med en SBC och PSTN-anslutning på varje plats aktivera samtal från plats till plats om [vidarekoppling av samtal är aktiverad](#_2v7qst7vxwaa). När detta är konfigurerat kommer telefonsamtal som rings i survivability-läge att dirigeras från användarens klient till PSTN, till den andra platsens SBC och ZPLS-modul, och slutligen anlända till den uppringda personens enhet. Följande diagram ger en översikt över denna konfiguration:
{% hint style="danger" %}
Den här konfigurationen **kräver** behandling av telefonnummer i E.164-format på de konfigurerade SBC:erna.
{% endhint %}
Följande tabell visar också Zoom Phone-survivability i en design med flera platser med oberoende SBC:er:
| Samtal som kommer från byggnad | Kan nå dessa platser under ett externt internetfel | Kan nå dessa platser under ett fel i campusnätverket |
| ------------------------------ | -------------------------------------------------- | ---------------------------------------------------- |
| 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 |
#### Nomadiska användare registrerar sig alltid till ZPLS-modulen som är associerad med deras hemplats
När användare eller enheter läggs till i Zoom Phone associeras en ”hemplats” statiskt med användaren eller enheten tills detta uppdateras av en kontoadministratör. Det innebär att om en användare flyttar till en fysisk plats utanför sin associerade hemplats, till exempel en kontorsbyggnad som är associerad med en annan plats, kommer Zoom inte att dynamiskt justera den plats som är bunden till användaren. Om användaren därför förlorar anslutningen till Zoom Phone-datacenter kommer användaren att försöka registrera sig till ZPLS-modulen som är associerad med sin hemplats, även om de befinner sig på en annan plats.
{% hint style="success" %}
**Exempel:**
En användare i ett campus med flera platser är baserad i byggnad A (plats A) och flyttar tillfälligt till byggnad B (plats B) för ett möte. Medan användaren befinner sig i byggnad B inträffar en tjänstepåverkande händelse och survivability-läget aktiveras. Även om användaren befinner sig i byggnad B kommer användarens klient, eftersom plats A är deras hemplats, att försöka ansluta till ZPLS-modulen som etablerats på deras hemplats i byggnad A.
I detta scenario avgörs en användares survivability-status av användarenhetens förmåga att registrera sig till ZPLS-modulen inom deras hemplats via campusnätverket. Om campusnätverket ligger nere medan användaren är borta från sin hemplats kan användaren inte dra nytta av survivability-modulen.
{% 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/sv/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.