Donanım Dağıtımıyla İlgili Hususlar

Desteklenen hipervizörleri kullanarak Zoom Node ZPLS modülünü sanal makinelere dağıtma talimatlarını bulun

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 üzerine yüklenmelidir. Zoom Node hakkında ürün olarak daha fazla bilgi Ek bölümünde.

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

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 kurtarma devralmasını hangi kullanıcıların destekleyeceğine öncelik vermek için.

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.

Bu özellik şu anda beta sürümündedir ve etkinleştirilmesi için bir teknik destek bileti gerektirir.

Ö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.

Ö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.

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.

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.

Mevcut Zoom müşterilerinin hesap yöneticileri, mevcut tesis tasarımlarını Şirket Bilgileri sayfası üzerinden, telefon sistemi Yönetimi web portalındaki menüsünde bulabilir.

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 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.

Bu özellik şu anda beta sürümündedir ve etkinleştirilmesi için bir teknik destek bileti gerektirir.

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.

Bu özellik şu anda beta sürümündedir ve etkinleştirilmesi için bir teknik destek bileti gerektirir.

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.

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.

Ç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 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.

Ç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.

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.

Ö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.

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.

Ö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.

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. 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:

Bu yapılandırma gerektirir yapılandırılmış SBC'lerde E.164 telefon numarası işlemeyi.

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.

Ö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.