Azure SignalR'de coğrafi çoğaltma

Yerel varlık arayan veya sağlam bir yük devretme sistemi gerektiren şirketler genellikle hizmetleri birden çok Azure bölgesine dağıtmayı tercih eder. Azure SignalR'de coğrafi çoğaltmanın tümleştirilmesiyle birlikte, çok bölgeli senaryoları yönetmek önemli ölçüde daha kolay hale gelmiştir.

Coğrafi çoğaltma kullanmanın avantajları

• Bölgesel kesintiye karşı daha dayanıklı: Bölgesel bir kesinti oluşursa Azure SignalR DNS, diğer bölgelerdeki iyi durumdaki çoğaltmalara çözümlenir.
• Bölgeler Arası İletişim. Farklı çoğaltmalar birbirleriyle aynı örnekmiş gibi iletişim kurabilir.
• Gelişmiş ağ hızı: Coğrafi olarak dağınık istemciler en yakın çoğaltmaya bağlanır. Bu çoğaltmalar Azure genel ağ omurgası üzerinden iletişim kurarak hızlı ve kararlı ağ iletişimi sağlar.
• Paylaşılan yapılandırmalar. Tüm çoğaltmalar birincil Azure SignalR Hizmeti kaynağının yapılandırmasını korur.

Önkoşullar

• Premium katmanında bir Azure SignalR Hizmeti.

Örnek kullanım örneği

Contoso, müşteri tabanı ABD ve Kanada'ya yayılmış bir sosyal medya şirketidir. Contoso, bu müşterilere hizmet vermek ve birbirleriyle iletişim kurmalarına izin vermek için hizmetlerini Orta ABD'de çalıştırır. Azure SignalR Hizmeti, kullanıcı bağlantılarını işlemek ve kullanıcılar arasındaki iletişimi kolaylaştırmak için kullanılır. Contoso'nun son kullanıcıları çoğunlukla telefon kullanıcılarıdır. Uzun coğrafi mesafeler nedeniyle, Kanada'daki son kullanıcılar yüksek gecikme süresi ve düşük ağ kalitesiyle karşılaşabilir.

Contoso, coğrafi çoğaltma özelliğinin ortaya çıkmasından önce Kanada kullanıcılarına hizmet vermek için Orta Kanada'da başka bir Azure SignalR Hizmeti ayarlayabilir. Coğrafi olarak daha yakın bir Azure SignalR Hizmeti ayarlayarak, son kullanıcılar artık daha iyi ağ kalitesine ve daha düşük gecikme süresine sahip olur.

Ancak, birden çok Azure SignalR Hizmeti yönetmek bazı zorluklar getirir:

1. Kanada ve ABD kullanıcıları arasında konuşmayı etkinleştirmek için bölgeler arası iletişim mekanizması gerekir.
2. Geliştirme ekibinin her birinde ayrı etki alanı ve bağlantı dizesi olan iki ayrı Azure SignalR Hizmeti yönetmesi gerekir.
3. Bölgesel bir kesinti olursa trafiğin başka bir bölgeye geçiş yapması gerekir.

Coğrafi çoğaltmadan yararlanma

Contoso, yeni coğrafi çoğaltma özelliğiyle artık Orta Kanada'da bir çoğaltma oluşturarak yukarıda belirtilen engelleri etkili bir şekilde aşabilir.

SignalR çoğaltması oluşturma

@description('The name for your SignalR service')
param primaryName string = 'contoso'

@description('The region in which to create your SignalR service')
param primaryLocation string = 'eastus'

@description('Unit count of your SignalR service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/signalr@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your SignalR replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the SignalR replica')
param replicaLocation string = 'westus'

@description('Unit count of the SignalR replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/signalr/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

Fiyatlandırma ve kaynak birimi

Her çoğaltmanın kendi unit ve autoscale settingsvardır.

Çoğaltma, Azure SignalR Hizmeti Premium katmanının bir özelliğidir. Her çoğaltma kendi birimine ve giden trafiğe göre ayrı olarak faturalandırılır. Ücretsiz ileti kotası da ayrı olarak hesaplanır.

Önceki örnekte Contoso, Orta Kanada'da bir çoğaltma eklemektedir. Contoso, Premium Fiyat'taki birimine ve iletisine göre Orta Kanada'daki çoğaltma için ödeme yapar.

Bölgeler arası giden trafik için çıkış ücretleri olacaktır. Bir ileti çoğaltmalar arasında aktarılır ve aktarımdan sonra bir istemciye veya sunucuya başarıyla gönderilirse, giden ileti olarak faturalandırılır.

Bir çoğaltmayı sil

Azure SignalR Hizmeti için bir çoğaltma oluşturduktan sonra, artık gerekli değilse istediğiniz zaman silebilirsiniz.

Azure portalında bir çoğaltmayı silmek için:

1. Azure SignalR Hizmeti gidin ve Çoğaltmalar dikey penceresini seçin. Silmek istediğiniz çoğaltmaya tıklayın.
2. Çoğaltmaya genel bakış dikey penceresinde Sil düğmesine tıklayın.

SignalR çoğaltmasının nasıl çalıştığını anlama

Aşağıdaki diyagramda SignalR Çoğaltmalarının işlevselliğine ilişkin kısa bir çizim yer almaktadır:

1. İstemci, uygulama sunucusuyla anlaşmaya varır ve Azure SignalR hizmetine bir yeniden yönlendirme alır. Ardından SignalR hizmetinin Tam Etki Alanı Adı (FQDN) — contoso.service.signalr.netsorununu çözer. Bu FQDN, en yakın bölgesel SignalR örneğinin Kurallı Adını (CNAME) döndüren Traffic Manager'ı gösterir.
2. Bu CNAME ile istemci, bölgesel örneğe (Çoğaltma) bir bağlantı kurar.
3. İki çoğaltma verileri birbiriyle eşitler. Bir çoğaltmaya gönderilen iletiler gerekirse diğer çoğaltmalara aktarılır.
4. Bir çoğaltmanın Traffic Manager (TM) tarafından gerçekleştirilen sistem durumu denetimini başarısız olması durumunda, TM başarısız örneğin uç noktasını etki alanı çözümleme işleminin dışında tutar. Ayrıntılar için aşağıdaki Dayanıklılık ve Olağanüstü Durum Kurtarma bölümüne bakın

Dayanıklılık ve olağanüstü durum kurtarma

Azure SignalR Hizmeti, çoğaltmalarına yönelik sistem durumu denetimleri ve DNS çözümlemesi için bir trafik yöneticisi kullanır. Normal koşullarda, tüm çoğaltmalar düzgün çalıştığında istemciler en yakın çoğaltmaya yönlendirilir. Örneğin:

• yakın eastus istemciler içinde eastusbulunan çoğaltmaya yönlendirilir.
• Benzer şekilde, yakın westus istemciler içindeki westusçoğaltmaya yönlendirilir.

Eastus'ta bölgesel bir kesinti olması durumunda (aşağıda gösterilmiştir), trafik yöneticisi bu bölge için sistem durumu denetimi hatasını algılar. Ardından, bu hatalı çoğaltmanın DNS'i trafik yöneticisinin DNS çözümleme sonuçlarından dışlanır. 90 saniye olarak ayarlanmış bir DNS Yaşam Süresi (TTL) süresinden sonra içindeki istemciler eastus içindeki çoğaltmaya westusbağlanmak için yeniden yönlendirilir.

içindeki eastus sorun çözüldükten ve bölge yeniden çevrimiçi olduktan sonra sistem durumu denetimi başarılı olur. Bu durumda içindeki eastus istemciler, bir kez daha kendi bölgelerindeki çoğaltmaya yönlendirilir. Bağlı istemciler mevcut bağlantılar kapatılana kadar etkilenmeyeceği için bu geçiş sorunsuz olur.

Bu yük devretme ve kurtarma işlemi otomatiktir ve el ile müdahale gerektirmez.

Sunucu bağlantıları için yük devretme ve kurtarma, istemci bağlantılarında olduğu gibi çalışır.

Çoğaltma uç noktasını devre dışı bırakma veya etkinleştirme

Bir çoğaltmayı ayarlarken, uç noktasını etkinleştirme veya devre dışı bırakma seçeneğiniz vardır. Devre dışı bırakılırsa, birincil FQDN'nin DNS çözümlemesi çoğaltmayı içermez ve bu nedenle trafik buna yönlendirilmeyecektir.

Uç nokta oluşturulduktan sonra devre dışı bırakma özelliğini de etkinleştirebilirsiniz. Birincil kaynağın çoğaltmaları dikey penceresinde, çoğaltmanın sağ tarafındaki üç nokta düğmesine tıklayın ve Uç Noktayı Etkinleştir veya Uç Noktayı Devre Dışı Bırak'ı seçin:

Çoğaltmayı silmeden önce uç noktasını devre dışı bırakmayı göz önünde bulundurun. Zaman içinde mevcut bağlantıların bağlantısı kesilir. Yeni bağlantı gelmediği için çoğaltma son olarak boşta olur. Bu, sorunsuz bir silme işlemi sağlar.

Bu özellik bölgesel sorunları gidermek için de yararlıdır.

Çoğaltma ekledikten sonra performans üzerindeki etki

Çoğaltmalar etkinleştirildikten sonra istemciler coğrafi konumlarına göre doğal olarak dağıtılır. SignalR, verileri bu çoğaltmalar arasında eşitleme sorumluluğunu üstlenirken, Sunucu Yükü'ne ilişkin ek yükün en yaygın kullanım örnekleri için en düşük düzeyde olduğunu bilmekten memnuniyet duyacaksınız.

Özellikle, uygulamanız genellikle daha büyük gruplara (boyut >10) veya tek bir bağlantıya yayınlanıyorsa eşitlemenin performans etkisi neredeyse fark edilemez. Küçük gruplara (boyut < 10) veya tek tek kullanıcılara ileti iletiniz varsa, biraz daha fazla eşitleme yükü fark edebilirsiniz.

Etkili yük devretme yönetimi sağlamak için her çoğaltmanın birim boyutunu tüm trafiği işleyecek şekilde ayarlamanız önerilir. Alternatif olarak, bunu yönetmek için otomatik ölçeklendirmeyi etkinleştirebilirsiniz.

Daha fazla performans değerlendirmesi için Bkz . Performans.

Devralınmayan ve Devralınan Yapılandırmalar

Çoğaltmalar çoğu yapılandırmayı birincil kaynaktan devralır; ancak, bazı ayarların doğrudan çoğaltmalarda yapılandırılması gerekir. Bu yapılandırmaların listesi aşağıdadır:

1. SKU: Her çoğaltmanın kendi SKU adı ve birim boyutu vardır. Çoğaltmalar için otomatik ölçeklendirme kuralları kendi ölçümlerine göre ayrı ayrı yapılandırılmalıdır.
2. Paylaşılan özel uç noktalar: Paylaşılan özel uç noktalar çoğaltmalara otomatik olarak çoğaltılırken, hedef özel bağlantı kaynaklarında ayrı onaylar gerekir. Paylaşılan özel uç noktaları eklemek veya kaldırmak için bunları birincil kaynakta yönetin. Paylaşılan özel uç noktası onaylanana kadar çoğaltmayı etkinleştirmeyin .
3. Hedef Ayarlarını Günlüğe Kaydet. Çoğaltmalarda yapılandırılmamışsa, yalnızca birincil kaynaktan günlükler aktarılır.
4. Uyarılar.

Diğer tüm yapılandırmalar birincil kaynaktan devralınır. Örneğin, erişim anahtarları, kimlik, uygulama güvenlik duvarı, özel etki alanları, özel uç noktalar ve erişim denetimi.