> 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/tr/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md). # Donanım Dağıtımına İlişkin Hususlar Bu sayfa, desteklenen hiper yöneticiler kullanılarak bir sanal makine üzerinde Zoom Node ZPLS modülünün dağıtımını açıklar. Farklı donanım özelliklerine uyum sağlamak için özel olarak hazırlanmış ayrıntılı yapılandırma seçenekleri sunar ve çeşitli operasyonel ihtiyaçlar için optimum performans sağlar. ### Desteklenen Hiper Yöneticiler #### Müşteriler, desteklenen bir hiper yönetici üzerinde çalışan bir sanal makineye Zoom Node yazılımını yüklemelidir Bir Zoom Node iş yükü olarak, ZPLS modülü Zoom Node platformunu çalıştıran bir sanal makineye, bir [desteklenen hiper yönetici](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server) üzerine yüklenmelidir. Zoom Node hakkında ürün olarak daha fazla bilgi [Ek bölümünde](#_a2lvsihjp0ek). #### Müşteriler, donanım özelliklerine bağlı olarak iki yapılandırma seçeneğinden birini seçebilir ZPLS modülü, sanal makinenin donanım özelliklerine bağlı olarak iki yapılandırmayı destekler. Bu özellikler aşağıda listelenmiştir: | | Yapılandırma Seçeneği 1 | Yapılandırma Seçeneği 2 | | ------------------------------- | -------------------------------------------- | --------------------------------------------- | | **Donanım Özellikleri** |

8 CPU

16 GB RAM

80 GB HDD

|

16 CPU

16 GB RAM

80 GB HDD

| | **Toplam Kayıtlar** | 2000 | 5000 | | **Maksimum Eşzamanlı Aramalar** | 240 | 480 | | **Saniye Başına Arama** | 2 | 4 | | **Saniye Başına Kayıt** | 60 | 400 | {% hint style="info" %} Bir kurtarma özelliği etkin tesis içindeki uç nokta sayısı, bir tesisin dağıtım kapasitesini aşarsa, ZPLS modülü kayıtları ilk gelen ilk hizmet alır esasına göre işler. Müşterilerin ek modüller eklemesi veya Zoom Phone Policy ayarını kullanması tavsiye edilir [**Yerel Kurtarma Modu**](#_ah8xua8wdq10) kurtarma devralmasını hangi kullanıcıların destekleyeceğine öncelik vermek için. {% endhint %} ### Modül Ölçeklendirme ve Dayanıklılık #### ZPLS modülleri, ek ölçeklendirme ve/veya dayanıklılık için kümelenmeyi destekler Müşteriler, ek yedeklilik veya ölçeklendirme için ZPLS modüllerini birlikte, tesis başına en fazla 20 modül (veya hesap başına toplam 100 Node cihazı) olacak şekilde gruplayabilir. {% hint style="info" %} Bu özellik şu anda beta sürümündedir ve etkinleştirilmesi için bir teknik destek bileti gerektirir. {% endhint %} #### Ölçeklendirme, bir tesisin desteklenen cihaz kapasitesini artırır ZPLS modüllerinin sayısını artırmak, her ek modül için her tesisin kapasitesini doğrusal olarak geliştirir. Örneğin, bir modül toplam 5.000 kaydı destekliyorsa, beş modül dağıtmak desteği 25.000 kayda çıkarır. #### Yedeklilik, dayanıklılık için ek modüller ekler, ancak bir tesisin cihaz kapasitesini ölçeklendirmez Bir ZPLS modülü yedeklilik amacıyla kullanıldığında, yedek modüller desteklenen toplam dahili hat sayısına katkıda bulunmaz. Bunun yerine, modüller “hot standby” durumundadır ve yalnızca birincil modüller başarısız olursa devreye girer. Örneğin, bir birincil ve bir yedek modül toplam 5.000 kaydı destekler; bu nedenle bir birincil modül başarısız olursa, yedek modül desteklenen sınırının ötesinde cihazlarla aşırı yüklenmez. #### Ölçeklendirme ve Yedeklilik ile ZPLS Dağıtımına Örnek Kolaylık olması için aşağıdaki örnek, ek ölçeklendirme ve yedeklilik ile dağıtımı gösterir. {% hint style="success" %} **Örnek**: Bir hastanenin, kurtarma için 10.000’e kadar kayıtlı dahili hattı desteklemesi gerekir. Bunu başarmak için hastane dört ZPLS modülü dağıtıyor. İlk iki modülün her biri 5.000 kaydı destekleyebilecek kapasitededir ve bu da toplamda 10.000’e kadar kayıt kapasitesi sağlar. Ancak dayanıklılığın önemini göz önünde bulunduran hastane, birincil modüller için yedek olarak iki ek modül de dağıtıyor. Bu senaryoda, hastanede artık birincil ve ikincil kurtarma donanımı dağıtılmıştır. Şimdi, bir birincil modül bir arıza yaşarsa, yedek modül(ler) kesintisiz hizmeti sürdürmek için devralır ve 10.000’e kadar kayıtlı cihazı desteklemeye devam eder. {% endhint %} ### Tesis Tasarımı Hususları #### Tesisler, ortak telefon ayarları ve politikaları için Zoom Phone kullanıcılarını konuma göre birlikte gruplar Bir **tesis** Zoom Phone içinde, kullanıcıları ortak bir erişim kodu, adres, SIP Bölgesi, departman veya politikalar gibi ortak özelliklere göre Zoom web portalı içinde tek, yönetilebilir bir grup halinde birleştiren özel bir terimdir. Bazı müşteriler için tek bir tesis, işletmelerindeki tüm kullanıcıları temsil edebilir ve bir kampüs veya konum içindeki birden fazla binayı kapsayabilir; diğerleri için, işletme ihtiyaçlarınıza bağlı olarak birden fazla tesis gerekebilir. Tesisler veya tesis yönetimi hakkında daha fazla bilgi için, [Zoom’un Destek Merkezi’ne başvurun](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). #### Zoom Phone tek tesisli ve çok tesisli tasarımları destekler Bir hesap içindeki Zoom Phone tesislerini yapılandırmak için iki temel tasarım vardır: 1. **Tek tesisli**: Tek bir Zoom Phone tesisinde, bir hesaptaki tüm kullanıcıları, potansiyel olarak birden fazla binayı veya konumu kapsayacak şekilde temsil eder. 2. **Çok tesisli**: Kullanıcı segmentlerini konum, bina, departman veya işleve göre ayrı ayrı, her biri kendi tesisine sahip olacak şekilde temsil eder.
{% hint style="info" %} Mevcut Zoom müşterilerinin hesap yöneticileri, mevcut tesis tasarımlarını [**Şirket Bilgileri**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) sayfası üzerinden, **telefon sistemi Yönetimi** web portalındaki menüsünde bulabilir. {% endhint %} #### Her ZPLS modülü aynı anda yalnızca bir tesis ile ilişkilendirilebilir Daha önce belirtildiği gibi, bir ZPLS modülü [üçüncü öncelikli kayıt sunucusudur](#_7itj40mx1dut) desteklenen cihazlar için, birincil ve ikincil SIP bölgelerinin arkasında yer alır. Cihazlar SRV listelerini açılış süreci sırasında aldığından ve bu listeler tesislerinin ayarına bağlı olduğundan, **her ZPLS modülü aynı anda yalnızca bir tesis ile ilişkilendirilebilir**. #### Her tesis aynı anda en fazla 20 ZPLS modülünü destekleyebilir Her ZPLS modülü aynı anda yalnızca bir tesis ile ilişkilendirilebilse de, bir tesis bir grupta en fazla 20 ZPLS modülünü destekleyebilir ve her tesisin dayanıklılık özelliklerini genişletir. {% hint style="info" %} Bu özellik şu anda beta sürümündedir ve etkinleştirilmesi için bir teknik destek bileti gerektirir. {% endhint %} #### ZPLS modülleri, modüller ortak bir ağa bağlıysa tesisler arası çağrıyı destekler Farklı tesislerden gelen ZPLS modülleri, cihazlar yerel ağ içinde bulunabilir olduğu sürece bir dayanıklılık Etkinlik sırasında tesisler arası çağrıyı destekler. Örneğin, bir işletme kampüsünde her birinin kendi telefon tesisi olan üç bina varsa, her tesisten gelen ZPLS modülleri kampüs alan ağı genelinde tesisten tesise çağrıları bağlayabilir. {% hint style="info" %} Bu özellik şu anda beta sürümündedir ve etkinleştirilmesi için bir teknik destek bileti gerektirir. {% endhint %} #### ZPLS dağıtımından önce, hesaplar hangi tesis yapılandırmasının ihtiyaçlarına en uygun olduğunu anlamalıdır Her ZPLS modülü aynı anda yalnızca bir tesis ile ilişkilendirilebildiğinden, bir hesap içinde ZPLS hizmeti dağıtılırken tesis tasarımı en önemli faktörlerden biridir. Bu nedenle, müşteriler hangi tesis yapılandırmasının pratik işletme ve dayanıklılık ihtiyaçlarını karşılamak için en iyisi olduğunu anlamalıdır; çünkü dayanıklılık için etkinleştirilen her ek tesis en az bir ek ZPLS modülü gerektirecektir. #### Tek tesisli bir tasarımın yönetilmesi daha kolaydır ve tek bir ZPLS modülüyle dayanıklılık sağlar, ancak kullanıcı Ayarlar ve politikaları için daha az esneklik sunar Tek tesisli bir tasarım, bir hesap içindeki tüm kullanıcıları tek ve birleşik bir grup altında toplayarak Zoom Phone Ayarlar ve politikalarının yönetimini kolaylaştırmaya yardımcı olur. Bu tek kullanıcı grubu, işletmelere basit yönetim ve azaltılmış karmaşıklık sunarak yönetim sürecini kolaylaştırır. Ayrıca, tek tesisli bir tasarım, tesisin kullanıcıları [tek modüllü bir sistemin kapasitesini](#_rx0i1j9xofnc). aşmadığı sürece, tek bir ZPLS modülü ile yerel telefon dayanıklılığı sunabilir. Ancak, tek tesisli bir tasarımın sadeliği doğal olarak sınırlamalar da içerir. Özellikle, tek tesisli tasarımlar “herkese uyan tek beden” yapıları nedeniyle daha az esneklik sunar; bu da farklı ihtiyaçlara sahip birden fazla departmandaki tüm dağıtım senaryolarına uygun olmayabilir. Ayrıca, tek tesisli dağıtımlar belirli dayanıklılık senaryolarında savunmasız olabilir eğer [yerel ağ başarısız olursa](#_gzpf5m70jl3i). #### Çok tesisli bir tasarım, kullanıcı Ayarlar ve politikaları için daha fazla esneklik sunar, ancak dayanıklılık etkinleştirilmiş her tesis için bir ZPLS modülü gerektirir ve yönetilmesi daha karmaşıktır Çok tesisli bir tasarım, kullanıcıları ayrıntılı ayar kontrollerine sahip çeşitli gruplara ayırarak işletmelere kullanıcı Ayarlar ve politikalarında ek esneklik sunar. Bu tasarım, kuruluşların çeşitli tesislerdeki belirli gereksinimleri karşılamak için iletişim yapılandırmalarını ayrıntılı şekilde ayarlamasını sağlar ve bunun sonucunda çeşitli departmanlar, senaryolar veya ihtiyaçlar için daha rafine ve uyarlanabilir bir kullanıcı deneyimi ortaya çıkar. Ayrıca, çok tesisli dağıtımlar [tesisler arası iletişimi](#_a42hwaw1pfmx) tesisler ortak bir ağ üzerinden bağlıysa destekleyebilir. Ancak, çok tesisli bir tasarımın yönetilmesi, her tesisin kendine özgü gereksinimlerinin ayrıntılarına dikkatli özen gösterilmesini gerektirir; bu da daha yüksek düzeyde idari çaba gerektirebilir. Ayrıca, her ZPLS modülü aynı anda yalnızca bir tesise atanabildiğinden, dayanıklılık etkinleştirilmiş her tesis bir ZPLS modülü ve lisans gerektirecektir; bu da daha fazla kaynak gerektiren bir kurulum düzenine katkıda bulunabilir. {% hint style="info" %} Çok tesisli bir tasarımda, müşteriler hangi tesislerin dayanıklılık için yapılandırılacağına Seç esnekliğine sahiptir. Tesisler *olmadan* bir ZPLS modülü, Standart bağlantı geri yüklenene kadar çağrı yapamaz veya alamaz durumda kalacaktır. {% endhint %} ### Ağ Arızaları #### Bir tesisin yerel ağı başarısız olursa dayanıklılık etkilenebilir ZPLS modülleri hizmeti etkileyen Etkinlikler sırasında yerel telefon dayanıklılığı sağlamak üzere tasarlanmış olsa da, bir tesisin yerel ağı başarısız olursa dayanıklılık etkilenebilir. Bu senaryolar aşağıdaki iki bölümde açıklanmaktadır. #### Tek Tesisli Yerel Ağ Arızası Tek tesisli bir tasarımda, bir veya daha fazla bina yerel veya kampüs alan ağı üzerinden bağlanır ve Zoom Phone içinde tek bir tesis olarak temsil edilir. Bu yapılandırma, binalar arası iletişim için herhangi bir harici ağ bağımlılığı (ör. İnternet) olmadan, bir Konum içindeki tüm kullanıcılar ve binalar arasında ortak bir ağ olduğunu varsayar. Bu tesis tasarımıyla, bir işletme tek bir ZPLS modülü ile tek bir tesis veya Konum içindeki tüm kullanıcılara yerel dayanıklılık sağlayabilir; ancak bu tasarım, binalar arası iletişimi etkileyen yerel veya kampüs ağı kesintisi durumunda savunmasızdır. Aşağıdaki örnek, yerel ağ arızasının tek tesisli bir dağıtımı nasıl etkileyebileceğini açıklamaktadır.
{% hint style="success" %} **Örnek:** Bir şirket, kampüs alan ağı üzerinden bağlı A, B ve C binalarından oluşan tek bir Zoom Phone tesisi için ZPLS modülünü dağıtıyor. ZPLS modülü A Binasında çalışıyor ve **değilse** PSTN üzerinden harici çağrı için bir SBC'ye bağlı. Harici internet hizmeti arızası veya hizmeti etkileyen bir Etkinlik durumunda, tesis içinde bulunan herhangi bir kullanıcı, *aynı* tesis içindeki başka bir kullanıcıyı arayabilir; yeter ki her iki kullanıcı da kampüs alan ağı üzerinden ZPLS modülüne bağlantısını korusun. Ancak, kampüs alan ağı kesintisi durumunda, A Binasındaki ZPLS modülüne erişilemediği için B ve C binalarındaki kullanıcılar çağrı yapamaz. Sonuç olarak, B ve C binalarındaki kullanıcılar dayanıklılık çağrısı için kampüs alan ağının geri yüklenmesini beklemelidir. {% endhint %} Aşağıdaki tablo, çok binalı tek tesisli bir tasarımda Zoom Phone dayanıklılığını göstermektedir: | Binadan kaynaklanan çağrılar | Harici İnternet arızası sırasında bu Konumlara ulaşabilir | Kampüs ağı arızası sırasında bu Konumlara ulaşabilir | | ---------------------------- | --------------------------------------------------------- | ---------------------------------------------------- | | Bina A (ZPLS oturum sahibi) | ☑️A, B ve C Binaları | ☑️ Yalnızca Bina A *yalnızca* | | Bina B | ☑️A, B ve C Binaları | ✖️ | | Bina C | ☑️A, B ve C Binaları | ✖️ | #### SBC Olmadan Çok Tesisli Yerel Ağ Arızası Çok tesisli bir tasarımda, her bina veya Konum (ör. kat, uydu ofis vb.) Zoom Phone içinde benzersiz bir tesis olarak bağımsız şekilde temsil edilir. Bu yapılandırma, her tesisin bir ZPLS modülüne sahip olduğunu ve tesislerin ortak bir kampüs alan ağı üzerinden bağlandığını varsayar. Bu tesis tasarımıyla, her tesis kendi ZPLS modülünü destekler ve bu sayede aynı bina içindeki kullanıcılar dayanıklılık modu devreye girdiğinde birbirlerini arayabilir. Ayrıca, bir ZPLS modülüne sahip birden fazla tesis ortak bir ağ üzerinden bağlandığında, yerel ağ çalışır durumda kaldığı sürece kullanıcılar \_other\_sites konumundaki kullanıcıları arayabilir. Ancak, bu tasarım binalar arası iletişimi etkileyen bir kampüs alan ağı kesintisi durumunda savunmasızdır. Aşağıdaki örnek, kampüs ağı arızasının çok tesisli bir dağıtımı nasıl etkileyebileceğini açıklamaktadır.
{% hint style="success" %} **Örnek:** Bir şirket, A, B ve C binalarından oluşan çok binalı kampüsü içinde ZPLS modülünü devreye alıyor. Her bina, Zoom Phone içinde benzersiz bir tesis olup tesise özgü bir ZPLS modülünü korur. Kampüsteki tüm binalar, bina-ler arası iletişim için harici internet hizmetine bağlı olmayan bir kampüs alan ağı üzerinden birbirine bağlıdır. Bu örnekte, harici internet hizmeti kesintisi, kampüs ağı kesintisi veya hizmeti etkileyen bir Etkinlik durumunda, bir tesis içinde bulunan herhangi bir kullanıcı aynı tesis içindeki başka bir kullanıcıyı arayabilir. Ancak, her bina benzersiz bir tesis olduğundan ve kullanıcılar kendi tesise özgü modüllerine kaydolduğundan, kampüs ağı başarısız olursa ZPLS modülleri tesisler arası çağrıları taşıyamaz. Bunun yerine, kullanıcılar yerel tesislerindeki diğer kullanıcılara çağrı yapmayla sınırlı olacaktır. {% endhint %} Aşağıdaki tablo, birbirine bağlı bir kampüs ağına sahip çok tesisli bir tasarımda yukarıdaki örnekten Zoom Phone dayanıklılığını göstermektedir: | Binadan kaynaklanan çağrılar | Harici İnternet arızası sırasında bu Konumlara ulaşabilir | Kampüs ağı arızası sırasında bu Konumlara ulaşabilir | | ---------------------------- | --------------------------------------------------------- | ---------------------------------------------------- | | Bina A (ZPLS oturum sahibi) | ☑️ A, B ve C binaları | ☑️ Yalnızca Bina A | | Bina B (ZPLS oturum sahibi) | ☑️ A, B ve C binaları | ☑️ Bina B | | Bina C (ZPLS oturum sahibi) | ☑️ A, B ve C binaları | ☑️ Bina C | #### Yerel ağ başarısız olursa, her tesis bir SBC'ye bağlıysa ve çağrı yönlendirme Etkinleştirildiyse, PSTN üzerinden tesisler arası çağrı da desteklenir Yerel ağ kesintisi durumunda, her tesiste ZPLS modülünü bir SBC ve PSTN bağlantısıyla entegre eden çok tesisli bir tasarıma sahip Müşteriler, eğer tesisler arası çağrı Etkinleştirilebilirse [çağrı yönlendirme Etkinleştirilirse](#_2v7qst7vxwaa). Yapılandırıldığında, dayanıklılık modundayken yapılan telefon çağrıları kullanıcının istemcisinden PSTN'ye, ikinci tesisin SBC'sine ve ZPLS modülüne yönlendirilir ve sonunda aranan kişinin Cihazına ulaşır. Aşağıdaki diyagram, bu yapılandırmaya genel bir bakış sağlar:
{% hint style="danger" %} Bu yapılandırma **gerektirir** yapılandırılmış SBC'lerde E.164 telefon numarası işlemeyi. {% endhint %} Aşağıdaki tablo ayrıca bağımsız SBC'lere sahip çok tesisli bir tasarımda Zoom Phone dayanıklılığını göstermektedir: | Binadan kaynaklanan çağrılar | Harici İnternet arızası sırasında bu Konumlara ulaşabilir | Kampüs ağı arızası sırasında bu Konumlara ulaşabilir | | ---------------------------- | --------------------------------------------------------- | ---------------------------------------------------- | | Bina A (ZPLS oturum sahibi) | ☑️A, B ve C Binaları | ☑️A, B ve C Binaları | | Bina B (ZPLS oturum sahibi) | ☑️A, B ve C Binaları | ☑️A, B ve C Binaları | | Bina C (ZPLS oturum sahibi) | ☑️A, B ve C Binaları | ☑️A, B ve C Binaları | #### Gezici kullanıcılar her zaman kendi ana tesisleriyle ilişkili ZPLS modülüne kaydolur Kullanıcılar veya cihazlar Zoom Phone'a eklendiğinde, bir “ana” tesis, bir hesap yöneticisi tarafından aksi güncellenene kadar kullanıcıya veya cihaza statik olarak ilişkilendirilir. Bu, bir kullanıcı farklı bir siteyle ilişkili bir ofis binası gibi ilişkili ana tesisinin dışındaki fiziksel bir Konuma taşınırsa, Zoom'un kullanıcıya bağlı tesisi dinamik olarak ayarlamayacağı anlamına gelir. Sonuç olarak, kullanıcı Zoom Phone veri merkezleriyle bağlantısını kaybederse, farklı bir Konumda olsa bile ana tesisiyle ilişkili ZPLS modülüne kaydolmaya çalışır. {% hint style="success" %} **Örnek:** Çok tesisli bir kampüsteki bir kullanıcı Bina A'da (Tesis A) bulunur ve bir toplantı için geçici olarak Bina B'ye (Tesis B) geçer. Bina B'deyken, hizmeti etkileyen bir Etkinlik gerçekleşir ve dayanıklılık modu devreye girer. Kullanıcı Bina B içinde bulunmasına rağmen, Tesis A kendi ana tesisi olduğundan, kullanıcının istemcisi bina A içindeki ana tesisine sağlanan ZPLS modülüne bağlanmaya çalışacaktır. Bu senaryoda, bir kullanıcının dayanıklılık durumu, kullanıcının Cihazının kampüs alan ağı üzerinden kendi ana tesisindeki ZPLS modülüne kaydolabilme yeteneğiyle belirlenir. Kullanıcı ana tesisinden uzaktayken kampüs alan ağı çalışmıyorsa, kullanıcı dayanıklılık modülünden yararlanamaz. {% 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/tr/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.