> 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 Denna sida beskriver driftsättningen av Zoom Node ZPLS-modulen på en virtuell maskin med hjälp av stödda hypervisorer. Den innehåller detaljerade konfigurationsalternativ anpassade för att ta hänsyn till olika hårdvarukapaciteter och säkerställa optimal prestanda för olika operativa behov. ### Stödda hypervisorer #### Kunder måste installera Zoom Node-programvaran på en virtuell maskin som körs på en stödd hypervisor 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). #### Kunder kan välja ett av två konfigurationsalternativ, beroende på hårdvarukapacitet ZPLS-modulen stöder två konfigurationer, beroende på den virtuella maskinens hårdvarukapacitet. Dessa kapaciteter 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 överlevnadsstöd överstiger en plats driftsättningskapacitet, kommer ZPLS-modulen att behandla registreringar enligt principen först till kvarn. Kunder rekommenderas att lägga till ytterligare moduler, eller använda inställningen Zoom Phone Policy [**Lokalt överlevnadsläge**](#_ah8xua8wdq10) för att prioritera vilka användare som stöder övertagning vid överlevnadsfel. {% endhint %} ### Skalning och redundans för moduler #### ZPLS-moduler stöder klustring för ytterligare skalning och/eller redundans Kunder kan gruppera ZPLS-moduler tillsammans med upp till 20 moduler per plats (eller 100 totala Node-enheter per konto) för extra redundans eller skalning. {% hint style="info" %} Denna funktion är för närvarande i beta och kräver att ett supportärende öppnas för att aktiveras. {% endhint %} #### Skalning ökar en plats stödda enhetskapacitet 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 driftsättning av fem moduler att höja stödet till 25 000 registreringar. #### Redundans lägger till ytterligare moduler för redundans, men skalar inte en plats enhetskapacitet När en ZPLS-modul används för redundansändamål bidrar inte de redundanta modulerna till det totala antalet stödda anknytningar. I stället står modulerna i ”hot standby” och aktiveras bara om primära moduler går sönder. Till exempel stöder en primär och en redundant modul totalt 5 000 registreringar, så om en primär modul går sönder blir den redundanta modulen inte överbelastad med enheter utöver sin stödda gräns. #### Exempel på driftsättning av ZPLS med skalning och redundans För enkelhets skull visar följande exempel driftsättning med ytterligare skalning och redundans. {% hint style="success" %} **Exempel**: Ett sjukhus måste stödja upp till 10 000 registrerade anknytningar för överlevnad. För att uppnå detta driftsätter 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. Med insikt om redundansens betydelse driftsätter sjukhuset dessutom två ytterligare moduler som redundanta säkerhetskopior till de primära modulerna. I det här scenariot har sjukhuset nu driftsatt primär och sekundär överlevnadshårdvara. Om en primär modul får ett fel kommer den redundanta modulen eller 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 för platsdesign #### Platser grupperar Zoom Phone-användare efter plats för gemensamma telefoniinställningar och policyer A **plats** är en specifik term som används inom Zoom Phone för att gruppera användare med gemensamma egenskaper — som en gemensam åtkomstkod, 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 företag, och kan omfatta flera byggnader inom ett campus eller en plats; för andra kan flera platser krävas beroende på dina affärsbehov. Mer information om platser eller platsadministration finns [se Zooms supportcenter](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). #### Zoom Phone stöder design med en plats och flera platser Det finns två huvudsakliga designer för att konfigurera Zoom Phone-platser inom ett konto: 1. **En plats**: Representerar alla användare inom ett konto, potentiellt ö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 [**Företagsinfo**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) sidan, tillgänglig i **Hantering av telefonsystem** menyn på webbportalen. {% endhint %} #### Varje ZPLS-modul kan endast vara associerad med en plats åt gången Som tidigare nämnts är en ZPLS-modul den [registreraren med tredje prioritet](#_7itj40mx1dut) för stödda enheter, efter primära och sekundära SIP-zoner. Eftersom enheter får sina SRV-listor under uppstartsprocessen och dessa listor är knutna till platsens inställningar, **varje ZPLS-modul kan endast vara associerad med en plats åt gången**. #### Varje plats kan stödja upp till 20 ZPLS-moduler samtidigt Även om varje ZPLS-modul endast kan vara associerad med en plats åt gången kan en plats stödja upp till 20 ZPLS-moduler i en grupp, vilket utökar varje plats överlevnadsförmåga. {% hint style="info" %} Denna funktion är för närvarande i beta och kräver att ett supportärende öppnas 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 ett överlevnadsevenemang så länge enheterna kan upptäckas inom det lokala nätverket. Om ett företagscampus till exempel har tre byggnader, var och en med sin egen telefonplats, kan ZPLS-modulerna från varje plats ansluta plats-till-plats-samtal över campusets områdesnätverk. {% hint style="info" %} Denna funktion är för närvarande i beta och kräver att ett supportärende öppnas för att aktiveras. {% endhint %} #### Innan ZPLS driftsätts bör konton förstå vilken platskonfiguration som bäst passar deras behov Eftersom varje ZPLS-modul endast kan associeras med en plats åt gången är platsdesign en av de viktigaste faktorerna när ZPLS-tjänsten driftsätts inom ett konto. Av den anledningen bör kunder förstå vilken platskonfiguration som är bäst för att uppfylla deras praktiska affärs- och överlevnadsbehov, eftersom varje ytterligare plats som aktiveras för överlevnad kräver minst en ytterligare ZPLS-modul. #### En design med en plats är enklare att hantera och ger överlevnad 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 erbjuder företag enkel administration och minskad komplexitet, vilket förenklar hanteringsprocessen. Dessutom kan en design med en plats erbjuda lokal telefoniöverlevnad med en enda ZPLS-modul, så länge platsens användare inte överstiger [kapaciteten för en enda modul](#_rx0i1j9xofnc). Men enkelheten i en design med en plats medför naturligtvis begränsningar. Mer specifikt erbjuder design med en plats mindre flexibilitet på grund av sin ”en storlek passar alla”-karaktär, vilket kanske inte passar alla driftsättningsscenarier över flera avdelningar med varierande behov. Vidare kan driftsättningar med en plats vara sårbara i vissa överlevnadsscenarier om [det lokala nätverket går ner](#_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 som aktiverats för överlevnad och är mer komplicerad att hantera En design med flera platser erbjuder företag ytterligare flexibilitet i användarinställningar och policyer genom att dela upp användare i olika grupper med detaljerad kontroll över inställningar. Denna design ger organisationer möjlighet att finjustera kommunikationskonfigurationer för att uppfylla 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 flerplatsdriftsättningar 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å de särskilda kraven för varje plats, vilket kan kräva en högre nivå av administrativt arbete. Dessutom, eftersom varje ZPLS-modul endast kan tilldelas en plats åt gången, kräver varje plats som aktiverats för överlevnad en ZPLS-modul och licens, vilket kan bidra till en mer resurskrävande uppsättning. {% hint style="info" %} I en design med flera platser har kunder flexibiliteten att välja vilka platser som ska konfigureras för överlevnad. Platser *utan* en ZPLS-modul kommer att förbli oförmögna att ringa eller ta emot samtal tills standardanslutningen återställs. {% endhint %} ### Nätverksfel #### Överlevnad kan påverkas om en plats lokala nätverk går sönder Även om ZPLS-moduler är utformade för att ge lokal telefoniöverlevnad under servicepåverkande evenemang, kan överlevnad påverkas om en plats lokala nätverk går sönder. Dessa scenarier beskrivs i de två följande avsnitten. #### Fel i det lokala nätverket i en design med 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 överlevnad till alla användare inom en enda plats med så lite som en ZPLS-modul; denna design är dock sårbar vid ett avbrott i det lokala nätverket eller campusnätverket som påverkar kommunikation mellan byggnader. Följande exempel beskriver hur ett fel i det lokala nätverket kan påverka en driftsättning med en plats.
{% hint style="success" %} **Exempel:** Ett företag driftsätter 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 fel i internettjänsten eller ett servicepåverkande evenemang kan alla användare som finns inom platsen ringa en annan användare inom samma *samma* plats, så länge båda användarna behåller anslutning till ZPLS-modulen via campusnätverket. Men vid ett avbrott i campusnätverket kan användare i byggnaderna B och C inte ringa samtal medan ZPLS-modulen i byggnad A är oåtkomlig. Följaktligen måste användare i byggnaderna B och C vänta tills campusnätverket återställs för samtal med överlevnad. {% endhint %} Följande tabell visar Zoom Phone-överlevnad i en design med en plats med flera byggnader: | Samtal som kommer från byggnad | Kan nå dessa platser vid ett externt internetfel | Kan nå dessa platser vid ett fel i campusnätverket | | ------------------------------ | ------------------------------------------------ | -------------------------------------------------- | | Byggnad A (ZPLS-värd) | ☑️Byggnaderna A, B och C | ☑️ Byggnad A *endast* | | Byggnad B | ☑️Byggnaderna A, B och C | ✖️ | | Byggnad C | ☑️Byggnaderna A, B och C | ✖️ | #### Fel i det lokala nätverket i en design med flera platser utan SBC I en design med flera platser representeras varje byggnad eller plats (t.ex. våning, satellitkontor 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 genom ett gemensamt campusnätverk. Med denna platsdesign stöder varje plats sin egen ZPLS-modul, vilket gör det möjligt för användare i samma byggnad att ringa varandra när överlevnadsläget är aktiverat. Dessutom, när flera platser med en ZPLS-modul är anslutna genom ett gemensamt nätverk, kan användare ringa användare på \_andra platser\_, så länge det lokala nätverket förblir i drift. Denna design är dock sårbar vid ett avbrott i campusnätverket som påverkar kommunikation mellan byggnader. Följande exempel beskriver hur ett fel i campusnätverket kan påverka en driftsättning med flera platser.
{% hint style="success" %} **Exempel:** Ett företag driftsätter 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 genom ett campusnätverk som inte är beroende av extern internettjänst för kommunikation mellan byggnader. I detta exempel kan, vid ett externt fel i internettjänsten, ett avbrott i campusnätverket eller ett servicepåverkande evenemang, alla användare som finns inom en plats ringa en annan användare som finns inom samma plats. Men eftersom varje byggnad är en unik plats och användarna registrerar sig till sina platsspecifika moduler kan ZPLS-modulerna inte transportera samtal mellan platser om campusnätverket går ner. I stället begränsas användarna till att ringa andra användare inom sin lokala plats. {% endhint %} Följande tabell visar Zoom Phone-överlevnad från exemplet ovan i en design med flera platser med ett sammanlänkat campusnätverk: | Samtal som kommer från byggnad | Kan nå dessa platser vid ett externt internetfel | Kan nå dessa platser vid ett fel i campusnätverket | | ------------------------------ | ------------------------------------------------ | -------------------------------------------------- | | Byggnad A (ZPLS-värd) | ☑️ Byggnaderna A, B och C | ☑️ Byggnad A | | Byggnad B (ZPLS-värd) | ☑️ Byggnaderna A, B och C | ☑️ Byggnad B | | Byggnad C (ZPLS-värd) | ☑️ Byggnaderna A, B och C | ☑️ Byggnad C | #### Om ett lokalt nätverk går ner stöds även samtal mellan platser via PSTN, förutsatt att varje plats är ansluten till en SBC och att vidarekoppling är 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 vid varje plats aktivera samtal mellan platser om [vidarekoppling är aktiverad](#_2v7qst7vxwaa). När den är konfigurerad kommer telefonsamtal som rings i överlevnadsläge att routas från användarens klient till PSTN, till den andra platsens SBC och ZPLS-modul, och slutligen till den uppringdes enhet. Följande diagram ger en översikt över denna konfiguration:
{% hint style="danger" %} Denna konfiguration **kräver** E.164-nummerbehandling på de konfigurerade SBC:erna. {% endhint %} Följande tabell visar också Zoom Phone-överlevnad i en design med flera platser med oberoende SBC:er: | Samtal som kommer från byggnad | Kan nå dessa platser vid ett externt internetfel | Kan nå dessa platser vid 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 den ZPLS-modul 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 den uppdateras av en kontoadministratör. Detta innebär att om en användare flyttar till en fysisk plats utanför sin associerade hemplats, som en kontorsbyggnad associerad med en annan plats, kommer Zoom inte dynamiskt att justera platsen som är bunden till användaren. Följaktligen, om användaren förlorar anslutningen till Zoom Phone-datacenter, kommer användaren att försöka registrera sig till den ZPLS-modul som är associerad med hemplatsen, även om personen befinner sig på en annan plats. {% hint style="success" %} **Exempel:** En användare i ett campus med flera platser utgår från byggnad A (Plats A) och flyttar tillfälligt till byggnad B (Plats B) för ett möte. Medan personen befinner sig i byggnad B inträffar ett servicepåverkande evenemang och överlevnadsläget aktiveras. Även om användaren befinner sig i byggnad B, eftersom Plats A är användarens hemplats, kommer användarens klient att försöka ansluta till den ZPLS-modul som tillhandahålls på hemplatsen i byggnad A. I detta scenario bestäms användarens överlevnadsstatus av användarenhetens förmåga att registrera sig till ZPLS-modulen inom hemplatsen över campusnätverket. Om campusnätverket ligger nere medan användaren är borta från hemplatsen kan användaren inte dra nytta av överlevnadsmodulen. {% 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.