Azure Communications Gateway'de güvenilirlik

Azure Communications Gateway, Azure yedeklilik mekanizmalarını ve SIP'ye özgü yeniden deneme davranışını kullanarak hizmetinizin güvenilir olmasını sağlar. Ağınızın hizmet kullanılabilirliğini sağlamak için belirli gereksinimleri karşılaması gerekir.

Azure Communications Gateway'in yedeklilik modeli

Üretim Azure Communications Gateway dağıtımları (standart dağıtımlar olarak da adlandırılır) üç ayrı bölgeden oluşur: bir yönetim bölgesi ve iki hizmet bölgesi. Laboratuvar dağıtımları bir yönetim bölgesinden ve bir hizmet bölgesinden oluşur.

Bu makalede iki farklı bölge türü ve bunların ayrı yedeklilik modelleri açıklanmaktadır. Kullanılabilirlik alanlarıyla hem bölgesel güvenilirliği hem de olağanüstü durum kurtarma ile bölgeler arası güvenilirliği kapsar. Azure'da güvenilirlik hakkında daha ayrıntılı bir genel bakış için bkz . Azure güvenilirliği.

Hizmet bölgeleri

Hizmet bölgeleri, ağınızla seçtiğiniz iletişim hizmetleri arasındaki trafiği işlemek için kullanılan ses ve API altyapısını içerir.

Üretim Azure Communications Gateway dağıtımları, etkin-etkin modda (Operatör Bağlantısı ve Teams Telefon Mobile programlarının gerektirdiği şekilde) dağıtılan iki hizmet bölgesine sahiptir. Hizmet bölgeleri arasında hızlı yük devretme, altyapı/IP düzeyinde ve uygulama (SIP/RTP/HTTP) düzeyinde sağlanır.

Hizmet bölgeleri, Azure Communications Gateway'in Sağlama API'sinin altyapısını da içerir.

Hizmet bölgeleri işlemde aynıdır ve hem Bölge hem de Bölgesel hatalara dayanıklılık sağlar. Her hizmet bölgesi, Azure Communications Gateway örneğini kullanarak trafiğin %100'lerini taşıyabilir. Bu nedenle, son kullanıcıların herhangi bir Bölge veya Bölgesel kapalı kalma süresi boyunca çağrıları başarıyla yapabilmesi ve alabilmesi gerekir.

Laboratuvar dağıtımlarının tek bir hizmet bölgesi vardır.

Arama yönlendirme gereksinimleri

Azure Communications Gateway 'başarılı bir yeniden arama' yedeklilik modeli sunar: Başarısız eşler tarafından işlenen çağrılar sonlandırılır, ancak yeni çağrılar iyi durumdaki eşlere yönlendirilir. Bu model, Microsoft Teams tarafından sağlanan yedeklilik modelini yansıtır.

Üretim dağıtımları için ağınızda coğrafi olarak yedekli iki site olmasını bekliyoruz. Her site bir Azure Communications Gateway bölgesiyle eşleştirilmelidir. Yedeklilik modeli, ağınızla Azure Communications Gateway hizmet bölgeleri arasında çapraz bağlantıya dayanır.

Laboratuvar dağıtımlarının ağınızdaki bir siteye bağlanması gerekir.

Her Azure Communications Gateway hizmet bölgesi bir SRV kaydı sağlar. Bu kayıt, bölgedeki SBC işlevselliği sağlayan tüm SIP eşlerini (iletişim hizmetlerine yönlendirme çağrıları için) içerir. Bu SRV kaydı, ekleme ekibiniz tarafından size sağlanan /28 IP aralığındaki herhangi bir IP adresini işaret edebilir.

Azure Communications Gateway'iniz Mobil Denetim Noktası (MCP) içeriyorsa, her hizmet bölgesi MCP için ek bir SRV kaydı sağlar. Her bölge başına MCP kaydı, en yüksek önceliğe sahip bölgede MCP'yi, diğer bölgede ise daha düşük öncelikli MCP'yi içerir.

Ağınızdaki her sitenin:

Ağınız SBC işlevi için Azure Communications Gateway'in SIP eşlerine çağrılar yönlendirdiğinde şunları yapmalıdır:

Azure Communications Gateway dağıtımınız tümleşik Mobil Denetim Noktası (MCP) içeriyorsa, ağınız MCP için aşağıdakini yapmalıdır:

Bu yönlendirme davranışının ayrıntıları ağınıza özeldir. Tümleştirme projeniz sırasında bunları ekleme ekibinizle birlikte kabul etmeniz gerekir.

Yönetim bölgeleri

Yönetim bölgeleri, Azure Communications Gateway'in sipariş edilmesi, izlenmesi ve faturalanması için kullanılan altyapıyı içerir. Bu bölgelerdeki tüm altyapı bölgesel olarak yedekli bir şekilde dağıtılır, yani tüm veriler bölge içindeki her Kullanılabilirlik Alanı arasında otomatik olarak çoğaltılır. Azure bölgesi hatası sırasında hizmetin düzgün çalıştığından emin olmak için tüm kritik yapılandırma verileri de Hizmet Bölgelerinin her birine çoğaltılır.

Kullanılabilirlik alanı desteği

Azure kullanılabilirlik alanları, her Azure bölgesindeki en az üç fiziksel ayrı veri merkezi grubudur. Her bölgedeki veri merkezleri bağımsız güç, soğutma ve ağ altyapısı ile donatılmıştır. Yerel bölge hatası durumunda kullanılabilirlik alanları, bir bölge etkileniyorsa, bölgesel hizmetler, kapasite ve yüksek kullanılabilirlik kalan iki bölge tarafından desteklenecek şekilde tasarlanmıştır.

Hatalar, yazılım ve donanım arızalarından deprem, sel ve yangın gibi olaylara kadar değişebilir. Azure hizmetlerinin yedekliliği ve mantıksal yalıtımı ile hatalara dayanıklılık elde edilir. Azure'daki kullanılabilirlik alanları hakkında daha ayrıntılı bilgi için bkz . Bölgeler ve kullanılabilirlik alanları.

Azure kullanılabilirlik alanlarının etkinleştirildiği hizmetler, doğru güvenilirlik ve esneklik düzeyini sağlayacak şekilde tasarlanmıştır. Bunlar iki şekilde yapılandırılabilir. Alanlar arasında otomatik çoğaltma ile alanlar arası yedekli veya belirli bir bölgeye sabitlenmiş örneklerle bölgesel olabilir. Bu yaklaşımları da birleştirebilirsiniz. Bölgesel ve alanlar arası yedekli mimari hakkında daha fazla bilgi için bkz. kullanılabilirlik alanlarını ve bölgelerini kullanmak için Öneriler.

Hizmet bölgeleri için bölge azaltma deneyimi

Bölge genelindeki bir kesinti sırasında, etkilenen bölge tarafından işlenen çağrılar sonlandırılır ve hizmetin kendi kendini düzeltmesi temel kaynakları sağlıklı bölgelere yeniden dengeleyene kadar bölge içinde kısa bir kapasite kaybı olur. Bu kendi kendini onarma, bölge geri yüklemeye bağımlı değildir; Microsoft tarafından yönetilen hizmet kendi kendine düzeltme durumunun, diğer bölgelerdeki kapasiteyi kullanarak kayıp bir bölgeyi dengelemesi beklenir. Kaynak taşıyan trafik alanlar arası yedekli bir şekilde dağıtılır, ancak en düşük ölçekte trafik tek bir kaynak tarafından işlenebilir. Bu durumda, bu makalede açıklanan yük devretme mekanizmaları, trafiği taşıyan kaynaklar sağlıklı bir bölgede yeniden dağıtılırken diğer hizmet bölgesine yönelik tüm trafiği yeniden dengeler.

Yönetim bölgesi için bölge azaltma deneyimi

Bölge genelinde kesinti sırasında, bölge kurtarma sırasında herhangi bir eylem gerekmez. Yönetim bölgesi, sağlıklı bölgeden otomatik olarak yararlanmak için kendini iyileştirir ve yeniden dengeler.

Olağanüstü durum kurtarma: diğer bölgelere geri dönüş

Olağanüstü durum kurtarma (DR), kapalı kalma süresi ve veri kaybına neden olan doğal afetler veya başarısız dağıtımlar gibi yüksek etkili olaylardan kurtarmayla ilgilidir. Nedeni ne olursa olsun, olağanüstü durum için en iyi çözüm iyi tanımlanmış ve test edilmiş bir DR planı ve DR'yi etkin bir şekilde destekleyen bir uygulama tasarımıdır. Olağanüstü durum kurtarma planınızı oluşturmaya başlamadan önce bkz. Olağanüstü durum kurtarma stratejisi tasarlamaya yönelik Öneriler.

DR söz konusu olduğunda, Microsoft paylaşılan sorumluluk modelini kullanır. Paylaşılan bir sorumluluk modelinde Microsoft, temel altyapı ve platform hizmetlerinin kullanılabilir olmasını sağlar. Aynı zamanda, birçok Azure hizmeti verileri otomatik olarak çoğaltmaz veya başarısız olan bir bölgeden geri dönerek başka bir etkin bölgeye çapraz çoğaltma yapamaz. Bu hizmetler için iş yükünüz için uygun bir olağanüstü durum kurtarma planı ayarlamak sizin sorumluluğunuzdadır. Hizmet olarak Azure platformu (PaaS) tekliflerinde çalışan hizmetlerin çoğu, DR'yi desteklemek için özellikler ve yönergeler sağlar ve DR planınızı geliştirmeye yardımcı olmak üzere hızlı kurtarmayı desteklemek için hizmete özgü özellikleri kullanabilirsiniz.

Bu bölümde, bölge genelindeki bir kesinti sırasında Azure Communications Gateway'in davranışı açıklanmaktadır.

Olağanüstü durum kurtarma: Hizmet bölgeleri için bölgeler arası yük devretme

Bölge genelinde bir kesinti sırasında, bu makalede açıklanan yük devretme mekanizmaları (SEÇENEKLER yoklama ve hatada SIP yeniden denemesi), kullanılabilirliği koruyarak diğer hizmet bölgesine yönelik tüm çağrı trafiğini yeniden dengeler. Bölgesel yedekliliği geri yüklemeye başlayacağız. Genişletilmiş kapalı kalma süresi sırasında bölgesel yedekliliği geri yüklemek için diğer Azure bölgelerinin kullanılması gerekebilir. Başarısız bir bölgeyi başka bir bölgeye geçirmemiz gerekiyorsa, geçişleri başlatmadan önce size danışacağız.

Azure Communications Gateway'deki SBC işlevi, ağınızın eş kullanılabilirliği belirlemesine olanak sağlamak için SEÇENEKLER yoklaması sağlar. MCP için ağınızın MCP'nin ne zaman kullanılamadığını algılayabilmesi ve MCP'nin ne zaman yeniden kullanılabilir olduğunu belirlemek için düzenli aralıklarla yeniden denemesi gerekir. MCP, SIP SEÇENEKLERİne yanıt vermez.

Sağlama API istemcileri, dağıtımınız için temel etki alanı adını kullanarak Azure Communications Gateway ile iletişim kurar. Bu etki alanının DNS kaydının yaşam süresi (TTL) 60 saniyedir. Bölge başarısız olduğunda Azure, DNS kaydını başka bir bölgeye başvurmak üzere güncelleştirir, böylece yeni dns araması yapan istemciler yeni bölgenin ayrıntılarını alır. İstemcilerin yeni bir DNS araması yapabilmesini ve zaman aşımı veya 5xx yanıt sonrasında 60 saniye sonra isteği yeniden denemesini öneririz.

Olağanüstü durum kurtarma: Yönetim bölgeleri için bölgeler arası yük devretme

Sayı Yönetimi Portalı aracılığıyla ses trafiği ve sağlama, ilgili Azure kaynakları hizmet bölgelerinde barındırıldığından yönetim bölgesindeki hatalardan etkilenmez. Sayı Yönetimi Portalı kullanıcılarının yeniden oturum açması gerekebilir.

hizmet geri yüklenene kadar izleme hizmetleri geçici olarak kullanılamayabilir. Yönetim bölgesi uzun kapalı kalma süresiyle karşılaşırsa etkilenen kaynakları başka bir kullanılabilir bölgeye geçiririz.

Yönetim ve hizmet bölgelerini seçme

Azure Communications Gateway'in tek bir dağıtımı, coğrafi alandaki trafiğinizi işlemek için tasarlanmıştır. Her iki hizmet bölgesini de aynı coğrafi alan içinde (örneğin Kuzey Amerika) bir üretim dağıtımına dağıtın. Bu model, sesli aramalardaki gecikme süresinin Operatör Bağlantısı ve Teams Telefon Mobile programlarının gerektirdiği sınırlar içinde kalmasını sağlar.

Hizmet bölgesi konumlarınızı seçerken aşağıdaki noktaları göz önünde bulundurun:

• Kullanılabilir Azure bölgeleri listesinden öğesini seçin. Bölgeye göre ürünler sayfasında hizmet bölgeleri olarak seçilebilen Azure bölgelerini görebilirsiniz.
• Arama gecikme süresini azaltmak için kendi şirket ortamınıza yakın bölgeleri ve ağınızla Microsoft arasındaki eşleme konumlarını seçin.
• Çok bölgeli bir kesinti oluşursa kurtarma süresini en aza indirmek için bölgesel çiftleri tercih edin.

Aşağıdaki listeden bir yönetim bölgesi seçin:

• Doğu ABD
• Orta Batı ABD
• West Europe
• Güney Birleşik Krallık
• Hindistan Orta
• Orta Kanada
• Doğu Avustralya

Yönetim bölgeleri, hizmet bölgeleriyle birlikte bulunabilir. Hizmet bölgenize en yakın yönetim bölgesini seçmenizi öneririz.

Servis düzeyi sözleşmeleri

Bu belgede açıklanan güvenilirlik tasarımı Microsoft tarafından uygulanır ve yapılandırılamaz. Azure Communications Gateway hizmet düzeyi sözleşmeleri (SLA) hakkında daha fazla bilgi için bkz. Azure Communications Gateway SLA'sı.

Sonraki adımlar

• Azure Communications Gateway'i ağınıza bağlama hakkında bilgi edinin
• Azure Communications Gateway'in ağınızın ve verilerinizin güvenliğini nasıl tuttuğu hakkında bilgi edinin
• Azure Communications Gateway dağıtımı planlama hakkında daha fazla bilgi edinin