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.

İki operatör sitesi ve Azure Communications Gateway için Azure bölgelerini gösteren diyagram. Azure Communications Gateway'de iki hizmet bölgesi ve bir yönetim bölgesi vardır. Hizmet bölgeleri yönetim bölgesine ve operatör sitelerine bağlanır. Yönetim bölgesi bir hizmet bölgesiyle birlikte bulunabilir.

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.

İpucu

Seçilen hizmet bölgelerinden biri tek bölgeli bir Azure Coğrafyasında (örneğin Katar) olsa bile üretim dağıtımlarının her zaman iki hizmet bölgesi olmalıdır. Tek bölgeli bir Azure Coğrafyası seçerseniz farklı bir Azure Coğrafyası'nda ikinci bir Azure bölgesi seçin.

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.

İki işleç sitesinin (A işleç sitesi ve işleç sitesi B) ve iki hizmet bölgesinin (hizmet bölgesi A ve hizmet bölgesi B) diyagramı. İşleç sitesi A hizmet bölgesine birincil bir yol ve B hizmet bölgesine ikincil bir yol içerir. İşleç sitesi B işlecinin B bölgesine birincil yolu ve A hizmet bölgesine giden ikincil yolu vardı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:

• Trafiği varsayılan olarak yerel Azure Communications Gateway hizmet bölgesine gönderin.
• RFC 3263'te açıklandığı gibi DNS SRV kullanarak bir bölgedeki Azure Communications Gateway eşlerini bulun.
  • kullanarak _sip._tls.<regional-FQDN-from-portal>, hizmet bölgesinin ağınızla bağlantısı için etki alanı adında bir DNS SRV araması yapın. değerini Azure portalındaki kaynağınızın Genel Bakış sayfasındaki Konak adı alanlarındaki bölge başına FQDN'lerle değiştirin<regional-FQDN-from-portal>. Örneğin, dağıtımınız etki alanı adları kullanıyorsa commsgw.azure.com ilk bölgeyi arayın _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com .
  • SRV araması birden çok hedef döndürürse, tek bir hedef seçmek için her hedefin ağırlığını ve önceliğini kullanın.
• Kullanılabilir Azure Communications Gateway eşlerine yeni çağrılar gönderin.
• Azure Communications Gateway'inizle ilişkili IP aralıklarının her birinde yer alan herhangi bir IP adresinden trafik alabilmeniz.

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 SIP eşlerinin kullanılabilirliğini izlemek için SIP SEÇENEKLERİ 'ni (veya SEÇENEKLER ve SIP trafiğinin birleşimini) kullanın.
• Yerel sitedeki diğer kullanılabilir eşlere yeniden yönlendirerek 408 yanıt, 503 yanıt veya 504 yanıt alan veya yanıt almayan DAVET'leri yeniden deneyin. Yalnızca yerel hizmet bölgesindeki tüm eşler başarısız olursa diğer hizmet bölgesine (diğer bölgenin SRV kaydıyla tanımlanır) avlanır.
• 408, 503 ve 504 dışında hata yanıtları alan çağrıları asla yeniden denemeyin.

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:

• Bir bölgedeki MCP'nin ne zaman kullanılamadığını algılayın, o bölgenin SRV kaydının hedeflerini kullanılamaz olarak işaretleyin ve bölgenin yeniden ne zaman kullanılabilir olduğunu belirlemek için düzenli aralıklarla yeniden deneyin. MCP, SIP SEÇENEKLERİne yanıt vermez.
• Kuruluşunuzun ilkesine göre MCP'den gelen 5xx yanıtları işleyebilirsiniz. Örneğin, isteği yeniden deneyebilir veya çağrının Azure Communications Gateway'den ve Microsoft Telefon Sistemi'ne geçmeden devam etmesi için izin vekleyebilirsiniz.

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.

İpucu

Laboratuvar dağıtımları bölgeler arası yük devretme sunmaz (çünkü yalnızca bir hizmet bölgesi vardır).

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.

Not

Azure Operatör Çağrı Koruması Önizleme'yi etkinleştiriyorsanız, seçtiğiniz hizmet bölgesi destek kaynaklarının dağıtıldığı Azure bölgesi olmayabilir. Şu anda desteklenen Azure Operatör Çağrı Koruması hizmet bölgelerinin listesi için bölgeye göre Azure Ürünleri'ne bakın ve hangi bölgenin seçildiği hakkında sorularınız varsa ekleme ekibinizle konuşun.

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