> 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ıyla İlgili Hususlar Bu sayfa, desteklenen hypervisor'lar 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ğlayacak şekilde tasarlanmış ayrıntılı yapılandırma seçenekleri sunar ve çeşitli operasyonel ihtiyaçlar için en iyi performansı sağlar. ### Desteklenen Hypervisor'lar #### Müşteriler, desteklenen bir hypervisor üzerinde çalışan bir sanal makineye Zoom Node yazılımını kurmalıdır Bir Zoom Node iş yükü olarak, ZPLS modülü Zoom Node platformu üzerinde çalışan bir sanal makineye, bir [desteklenen hypervisor](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Zoom Node hakkında bir ürün olarak daha fazla bilgi [Ek'te bulunabilir](#_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 | | **Saniyedeki Arama Sayısı** | 2 | 4 | | **Saniyedeki Kayıt Sayısı** | 60 | 400 | {% hint style="info" %} Eğer survivability Etkinleştirilmiş bir 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üşterilere ek modüller Eklemesi veya Zoom Phone Policy ayarını kullanması tavsiye edilir [**Yerel Hayatta Kalma Modu**](#_ah8xua8wdq10) survivability failover'ı Destekleyen hangi kullanıcıların önceliklendirilmesi 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 tesis başına en fazla 20 modül olacak şekilde (veya hesap başına toplam 100 Node Cihazı olacak şekilde) birlikte gruplandırabilir. {% hint style="info" %} Bu Özellikler ş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 artırır. Ö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 numara sayısına katkıda bulunmaz. Bunun yerine, modüller “sıcak bekleme” 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; dolayısıyla 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çekleme ve Yedeklilik ile ZPLS Dağıtımına Örnek Kolaylık olması açısından, aşağıdaki örnek ek ölçeklendirme ve yedeklilik ile dağıtımı göstermektedir. {% hint style="success" %} **Örnek**: Bir hastanenin, hayatta kalabilirlik için 10.000'e kadar kayıtlı uzantıyı Destek sağlaması gerekir. Bunu başarmak için hastane dört ZPLS modülü kullanıyor. İlk iki modülün her biri 5.000 kayıtı destekleyebilecek kapasitededir ve bu da toplamda 10.000 kayda kadar bir kapasite sağlar. Ancak dayanıklılığın önemini göz önünde bulunduran hastane, birincil modüllere yedek olarak iki ek modülü de devreye almaktadır. Bu senaryoda, hastanede artık birincil ve ikincil hayatta kalabilirlik donanımı konuşlandırılmış durumda. Şimdi, birincil modül bir arıza ile karşılaşırsa, yedek modül(ler) kesintisiz hizmeti sürdürmek için Devralacak ve aynı zamanda 10.000'e kadar kayıtlı cihaza Destek vermeye devam edecektir. {% endhint %} ### Tesis Tasarım Hususları #### Siteler, Zoom Phone kullanıcılarını ortak telefon Ayarları ve politikalar için Konum'a göre grup halinde bir araya getirir Bir **tesis** Zoom Phone içinde paylaşılan özelliklere sahip kullanıcıları — ortak bir erişim kodu, adres, SIP Zone, bölüm veya politikalar gibi — Zoom web portalı içinde tek, yönetilebilir bir grup haline getirmek için kullanılan belirli bir terimdir. Bazı Müşteriler için tek bir tesis, İşletmeleri içindeki tüm kullanıcıları temsil edebilir ve bir kampüs ya da Konum içindeki birden fazla binaya kadar uzanabilir; diğerleri için, işletme ihtiyaçlarınıza bağlı olarak Birden fazla site 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çinde Zoom Phone tesislerini yapılandırmak için iki temel tasarım vardır: 1. **Tek tesisli**: Bir hesabın tüm kullanıcılarını, potansiyel olarak birden fazla bina veya Konumda, tek bir Zoom Phone tesisinde temsil eder. 2. **Çok tesisli**: Kullanıcı segmentlerini Konum, bina, departman veya işleve göre ayrı ayrı temsil eder; her birinin kendi tesisi vardır.
{% hint style="info" %} Mevcut Zoom Müşterilerinin hesap yöneticileri, mevcut tesis tasarımını şuradan kontrol edebilir: [**Şirket Bilgileri**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) Uygun olan sayfadan, web portalındaki **telefon sistemi Yönetimi** menüden. {% endhint %} #### Her ZPLS modülü aynı anda yalnızca bir tesisle ilişkilendirilebilir Daha önce belirtildiği gibi, bir ZPLS modülü [üçüncü öncelikli kayıt sunucusu](#_7itj40mx1dut) desteklenen cihazlar için, birincil ve ikincil SIP bölgelerinin gerisinde yer alır. Cihazlar SRV listelerini başlatma sürecinde aldıkları ve bu listeler kendi tesislerinin ayarına bağlı olduğu için, **her ZPLS modülü aynı anda yalnızca bir tesisle ilişkilendirilebilir**. #### Her tesis aynı anda en fazla 20 ZPLS modülünü destekleyebilir Her ZPLS modülü aynı anda yalnızca bir tesisle ilişkilendirilebilse de, bir tesis bir grup içinde en fazla 20 ZPLS modülünü destekleyebilir; bu da her tesisin dayanıklılık kapasitesini artırır. {% hint style="info" %} Bu Özellikler ş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ı tesislerdeki ZPLS modülleri, cihazlar yerel ağ içinde keşfedilebilir olduğu sürece, bir dayanıklılık olayı sırasında tesisler arası çağrıyı destekler. Örneğin, bir İşletme kampüsünde her birinin kendi telefon tesisine sahip üç bina varsa, her tesisin ZPLS modülleri kampüs alan ağı üzerinden tesisler arası çağrıları bağlayabilir. {% hint style="info" %} Bu Özellikler şu anda beta sürümündedir ve etkinleştirilmesi için bir teknik destek bileti gerektirir. {% endhint %} #### ZPLS’yi dağıtmadan önce, hesaplar ihtiyaçlarına en uygun tesis yapılandırmasının hangisi olduğunu anlamalıdır Her ZPLS modülü aynı anda yalnızca bir tesisle ilişkilendirilebildiğinden, tesis tasarımı, bir hesap içinde ZPLS hizmeti dağıtılırken en önemli faktörlerden biridir. Bu nedenle, Müşteriler pratik İşletme ve dayanıklılık ihtiyaçlarını toplantı ile karşılamak için hangi tesis yapılandırmasının en uygun 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önetimi 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 hesaptaki tüm kullanıcıları tek, birleşik bir grup altında toplayarak Zoom Phone Ayarlar ve politikalarının yönetimini kolaylaştırır. 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 tek bir ZPLS modülüyle yerel telefon dayanıklılığı sağlayabilir, yeter ki tesisin kullanıcıları [tek modülün kapasitesini aşmasın](#_rx0i1j9xofnc). Bununla birlikte, tek tesisli bir tasarımın basitliği doğal olarak bazı sınırlamaları da içerir. Özellikle, tek tesisli tasarımlar, tek tip yapıları nedeniyle daha az esneklik sunar; bu da değişen ihtiyaçlara sahip birden fazla departmandaki tüm dağıtım senaryolarına uygun olmayabilir. Ayrıca, tek tesisli dağıtımlar, 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önetimi daha karmaşıktır Çok tesisli bir tasarım, kullanıcıları ayrıntılı Ayar denetimleriyle çeşitli gruplara ayırarak işletmelere kullanıcı Ayarlar ve politikalarında ek esneklik sağlar. Bu tasarım, kuruluşların iletişim yapılandırmalarını farklı tesislerdeki belirli gereksinimleri karşılamak üzere ayrıntılı biçimde ayarlamasını sağlar; bunun sonucunda çeşitli departmanlar, senaryolar veya ihtiyaçlar için daha rafine ve uyarlanabilir bir kullanıcı deneyimi elde edilir. Ayrıca, çok tesisli dağıtımlar [tesisler arası iletişimi](#_a42hwaw1pfmx) tesisler ortak bir ağ üzerinden bağlıysa. Ancak, çok tesisli bir tasarımı yönetmek, her tesisin benzersiz gereksinimlerinin inceliklerine dikkat etmeyi 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 gerektirecek, bu da daha fazla kaynak gerektiren bir kurulum oluşturabilir. {% hint style="info" %} Çok tesisli bir tasarımda, Müşteriler dayanıklılık için hangi tesislerin yapılandırılacağını Seç. *herhangi bir* bir ZPLS modülü, Standart bağlantı geri yüklenene kadar çağrı yapamaz veya çağrı alamaz durumda kalacaktır. {% endhint %} ### Ağ Kesintileri #### Bir tesisin yerel ağı başarısız olursa dayanıklılık etkilenebilir ZPLS modülleri, hizmeti etkileyen olaylar 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 özetlenmiştir. #### 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 İnternet gibi hiçbir dış ağ bağımlılığı olmaksızın, 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 İşletme tek bir tesis veya Konum içindeki tüm kullanıcılara yalnızca bir ZPLS modülüyle 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çıklar.
{% hint style="success" %} **Örnek:** Bir şirket, 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ü Bina A'da çalışıyor ve **değil** PSTN üzerinden harici çağrı için bir SBC'ye bağlıdır. Harici internet hizmeti arızası veya hizmeti etkileyen bir olay durumunda, tesis içindeki herhangi bir kullanıcı, tesis içindeki başka bir kullanıcıyı *aynı* tesis çağrı yapabilir; yeter ki her iki kullanıcı da kampüs alan ağı üzerinden ZPLS modülüne bağlantılarını sürdürebilsin. {% endhint %} Aşağıdaki tablo, çok binalı tek tesisli bir tasarımda Zoom Phone dayanıklılığını gösterir: | Çağrıların başladığı bina | Harici İnternet kesintisi sırasında bu konumlara ulaşabilir | Kampüs ağı kesintisi sırasında bu konumlara ulaşabilir | | --------------------------- | ----------------------------------------------------------- | ------------------------------------------------------ | | Bina A (ZPLS oturum sahibi) | ☑️Binalar A, B ve C | ☑️ Bina A *yalnızca* | | Bina B | ☑️Binalar A, B ve C | ✖️ | | Bina C | ☑️Binalar A, B ve C | ✖️ | #### SBC Olmayan Ç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 biçimde 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ğlı olduğunu varsayar. Bu tesis tasarımıyla, her tesis kendi ZPLS modülünü destekler ve dayanıklılık modu etkinleştirildiğinde aynı bina içindeki kullanıcıların birbirlerini çağırmasına olanak tanır. Ayrıca, ZPLS modülü olan birden fazla tesis ortak bir ağ üzerinden bağlandığında, yerel ağ çalışır durumda kaldığı sürece kullanıcılar diğer tesislerdeki kullanıcıları çağırabilir. Ancak, bu tasarım binalar arası iletişimi etkileyen kampüs alan ağı kesintisi durumunda savunmasızdır. Aşağıdaki örnek, bir kampüs ağı arızasının çok tesisli bir dağıtımı nasıl etkileyebileceğini açıklar.
{% hint style="success" %} **Örnek:** Bir şirket, A, B ve C binalarından oluşan çok binalı kampüsü içinde ZPLS modülünü dağıtıyor. Her bina, Zoom Phone içinde benzersiz bir tesistir ve tesise özel bir ZPLS modülünü korur. Kampüsteki tüm binalar, binalar arası iletişim için harici internet hizmetine bağlı olmayan bir kampüs alan ağı üzerinden bağlıdır. Bu örnekte, harici bir internet hizmeti arızası, kampüs ağı kesintisi veya hizmeti etkileyen bir Etkinlik durumunda, bir tesis içinde bulunan herhangi bir kullanıcı aynı tesis içinde bulunan başka bir kullanıcıyı çağırabilir. Ancak, her bina benzersiz bir tesis olduğundan ve kullanıcılar 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 yalnızca kendi yerel tesislerindeki diğer kullanıcılara çağrı yapmakla sınırlı olacaktır. {% endhint %} Aşağıdaki tablo, yukarıdaki örnekten Zoom Phone hayatta kalabilirliğini birbirine bağlı bir kampüs ağına sahip çok tesisli bir tasarımda göstermektedir: | Çağrıların başladığı bina | Harici İnternet kesintisi sırasında bu konumlara ulaşabilir | Kampüs ağı kesintisi sırasında bu konumlara ulaşabilir | | --------------------------- | ----------------------------------------------------------- | ------------------------------------------------------ | | Bina A (ZPLS oturum sahibi) | ☑️ Bina A, B ve C | ☑️ Bina A | | Bina B (ZPLS oturum sahibi) | ☑️ Bina A, B ve C | ☑️ Bina B | | Bina C (ZPLS oturum sahibi) | ☑️ Bina A, B ve C | ☑️ Bina C | #### Yerel bir ağ başarısız olursa, her tesis bir SBC'ye bağlıysa ve çağrı yönlendirme Etkinleştirildiğinde, PSTN üzerinden tesisler arası çağrı da desteklenir Yerel bir ağ arızası durumunda, ZPLS modülünü her tesiste bir SBC ve PSTN bağlantısıyla entegre eden çok tesisli bir tasarıma sahip Müşteriler, eğer [çağrı yönlendirme Etkinleştirildiğinde](#_2v7qst7vxwaa). Yapılandırıldığında, hayatta kalabilirlik modu sırasında 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ış sunar:
{% hint style="danger" %} Bu yapılandırma **gerektirir** Yapılandırılmış SBC'lerde E.164 telefon numarası işleme. {% endhint %} Aşağıdaki tablo ayrıca bağımsız SBC'lere sahip çok tesisli bir tasarımda Zoom Phone hayatta kalabilirliğini göstermektedir: | Çağrıların başladığı bina | Harici İnternet kesintisi sırasında bu konumlara ulaşabilir | Kampüs ağı kesintisi sırasında bu konumlara ulaşabilir | | --------------------------- | ----------------------------------------------------------- | ------------------------------------------------------ | | Bina A (ZPLS oturum sahibi) | ☑️Binalar A, B ve C | ☑️Binalar A, B ve C | | Bina B (ZPLS oturum sahibi) | ☑️Binalar A, B ve C | ☑️Binalar A, B ve C | | Bina C (ZPLS oturum sahibi) | ☑️Binalar A, B ve C | ☑️Binalar A, B ve C | #### Göçebe kullanıcılar her zaman 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ı ilişkili ana tesisinin dışındaki bir fiziksel Konum'a, farklı bir tesise bağlı bir ofis binası gibi, 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 Konum'da olsalar bile kullanıcı ana tesisiyle ilişkili ZPLS modülüne kaydolmaya çalışacaktır. {% hint style="success" %} **Örnek:** Çok tesisli bir kampüste bir kullanıcı Bina A'da (Tesis A) bulunur ve bir toplantı için geçici olarak Bina B'ye (Tesis B) gider. Bina B'de oldukları sırada, hizmeti etkileyen bir Etkinlik meydana gelir ve hayatta kalabilirlik modu devreye girer. Kullanıcı Bina B'de bulunmasına rağmen, Tesis A kendi ana tesisleri olduğundan, kullanıcının istemcisi bina A'daki ana tesislerinde sağlanan ZPLS modülüne bağlanmaya çalışacaktır. Bu senaryoda, bir kullanıcının hayatta kalabilirlik durumu, kullanıcının Cihazının kampüs alan ağı genelinde kendi ana tesisindeki ZPLS modülüne kaydolabilme yeteneği tarafından belirlenir. Kullanıcı ana tesisinden uzaktayken kampüs alan ağı çalışmıyorsa, kullanıcı hayatta kalabilirlik 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.