Azure SignalR Hizmeti güvenilirliği

Azure SignalR Hizmeti web ve mobil uygulamalarda gerçek zamanlı çift yönlü iletişim sağlayan tam olarak yönetilen bir hizmettir. Taşımanın altındaki mekanizmayı soyutlar. WebSockets kullanılabilir olduğunda, hizmet bunları kullanır. Bunlar olmadığında, Sunucu Gönderimli Olaylar'a veya uzun anketlemeye geri döner. Bu soyutlama, istemci ve sunucu kodunuzun belirli bir aktarım protokolüne bağlı kalmadan gerçek zamanlı olarak iletişim kurabileceği anlamına gelir.

Azure'ı kullandığınızda güvenilirlik paylaşılan bir sorumluluktır. Microsoft, dayanıklılık ve kurtarmayı desteklemek için çeşitli özellikler sunar. Bu özelliklerin kullandığınız tüm hizmetler içinde nasıl çalıştığını anlamak ve iş hedeflerinize ve çalışma süresi hedeflerinize ulaşmak için ihtiyacınız olan özellikleri seçmek sizin sorumluluğunuzdadır.

Bu makalede geçici hatalar, kullanılabilirlik alanı kesintileri, bölge kesintileri ve hizmet bakımı gibi çeşitli olası kesintilere ve sorunlara karşı Azure SignalR Hizmeti nasıl dayanıklı hale getirilmeye başlandığı açıklanır. Ayrıca Azure SignalR Hizmeti hizmet düzeyi sözleşmesi (SLA) hakkındaki önemli bilgileri de vurgular.

Güvenilirlik için üretim dağıtımı önerileri

Üretim iş yükleri için şunları yapmanızı öneririz:

• Premium katmanını kullanın. Premium katman, desteklenen bölgelerdeki kullanılabilirlik alanı hatalarına dayanıklıdır ve coğrafi çoğaltmayı yapılandırmanıza olanak tanır.
• Bağlantılar kesildiğinde otomatik olarak yeniden bağlanmak için istemci uygulamaları ve uygulama sunucuları tasarlayın. Bölge yük devretmeleri, bölgeler arası yük devretmeleri ve geçici hatalar tüm etkin bağlantıları bırakır.
• Bölge genelindeki hatalara karşı koruma sağlamak için coğrafi çoğaltmayı etkinleştirin. Beklenen bir yük devretme durumu sırasında tam beklenen trafik yükünü işlemek için her kopyayı yeterli birimle boyutlandırın.

Güvenilirlik mimarisine genel bakış

Bu bölümde, hizmetin nasıl çalıştığına ilişkin güvenilirlik açısından en uygun olan bazı önemli yönler açıklanmaktadır. bölümünde dağıttığınız ve kullandığınız bazı kaynak ve özellikleri içeren mantıksal mimari tanıtılır. Ayrıca, hizmetin kapaklar altında nasıl çalıştığına ilişkin ayrıntılar sağlayan fiziksel mimariyi de ele alır.

Mantıksal mimari

Oluşturduğunuz kaynak bir SignalR Hizmeti kaynağıdır. Bir kaynağı, eşzamanlı bağlantı sayısı üst sınırı dahil olmak üzere kaynağın kapasitesini temsil eden bir dizi birimle yapılandırabilirsiniz. Daha fazla bilgi için Azure SignalR Hizmeti Performans kılavuzuna bakın.

Azure SignalR Hizmeti iki service modunu destekler. Varsayılan modda, uygulama sunucularınız Azure SignalR Hizmeti kaynağına bağlanır ve hub mantığınızı içerir. Sunucusuz modda, hizmet Azure İşlevleri ile entegre olur ve İşlevler, olay odaklı mesaj işleyicileri olarak çalışır, böylece uygulama sunucularını doğrudan yönetmezsiniz. Daha fazla bilgi için Azure SignalR Hizmeti'nde hizmet modu bölümüne bakın.

SignalR Hizmeti kaynağı, contoso.service.signalr.net gibi genel olarak benzersiz bir uç noktaya sahiptir. İstemciler bu uç noktaya bağlantı kurar. Uygulama sunucuları, istemcilerden ileti göndermek ve olay almak için aynı uç noktaya bağlanır.

Fiziksel mimari

Azure SignalR Hizmeti, bir dizi işlem kaynağı arasında bağlantı durumunu ve ileti yönlendirmeyi yönetir. Microsoft temel altyapıyı yönetir. Hizmetin kullandığı tek tek VM'leri veya diğer altyapı bileşenlerini doğrudan görmez veya bunlarla etkileşim kurmazsınız.

Geçici hatalara dayanıklılık

Geçici hatalar, bileşenlerde kısa ve aralıklı hatalardır. Bunlar genellikle bulut gibi dağıtılmış bir ortamda gerçekleşir ve işlemlerin normal bir parçasıdır. Geçici hatalar kısa bir süre sonra kendilerini düzeltmektedir. Uygulamalarınızın genellikle etkilenen istekleri yeniden deneyerek geçici hataları işleyebileceği önemlidir.

Bulutta barındırılan tüm uygulamalar, bulutta barındırılan API'ler, veritabanları ve diğer bileşenlerle iletişim kurarken Azure geçici hata işleme yönergelerini izlemelidir. Daha fazla bilgi için bkz Geçici hataları ele alma önerileri.

Azure SignalR Hizmeti istemciler, uygulama sunucuları ve hizmet arasında uzun süreli bağlantılar kullanır. Ağ kararsızlığı, yük dengeleyici yeniden yapılandırmaları veya tarayıcı sekmesi durdurulmaları gibi geçici sorunlar nedeniyle bu bağlantılar kopabilir. İstemci uygulamalarınızı ve uygulama sunucularınızı bağlantı bırakma işlemlerini işleyecek ve otomatik olarak yeniden bağlanacak şekilde tasarlar.

Azure SignalR Hizmeti SDK'ları, hizmete yönelik sunucu bağlantıları için yerleşik yeniden bağlantı işlemeyi içerir. İstemci tarafı yeniden bağlantısı, kullandığınız istemci kitaplığına bağlıdır. ASP.NET Core SignalR istemcileri durum bilgisi olan yeniden bağlanmayı destekler ve bu da istemcinin aynı bağlantı kimliğini kullanarak hızlı bir şekilde yeniden bağlanması durumunda durumu kaybetmeden önceki bağlantısını sürdürmesini sağlar. Yeniden bağlantı, örneğin daha uzun bir kesintiden sonra yeni bir bağlantı kimliğiyle sonuçlanırsa, hizmet istemciyi yeni bir bağlantı olarak ele alır. Bu durumda istemcinin daha önce içinde olduğu tüm gruplara yeniden katılması ve oturum durumunu geri yüklemesi gerekir.

Uygulamanızı istemci bağlantı kesilmelerini ve yeniden bağlanmalarını işleyecek şekilde tasarlama hakkında ayrıntılı yönergeler için bkz. İsteci bağlantı kesilmelerini ve yeniden bağlanmayı anlama Azure SignalR Hizmeti.

Kullanılabilirlik alanı hatalarına dayanıklılık

Kullanılabilirlik alanları , bir Azure bölgesi içindeki veri merkezlerinin fiziksel olarak ayrı gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredilebilir.

Azure SignalR Hizmeti, Premium katmanında alanlar arası yedekli dağıtımları destekler. Kullanılabilirlik alanlarını destekleyen bir bölgede Premium katman kaynağı oluşturduğunuzda veya bu kaynağa yükselttiğinizde, Azure SignalR Hizmeti işlem kapasitesini bölgedeki tüm kullanılabilirlik alanlarına otomatik olarak dağıtır. Kullanılabilirlik alanı başarısız olursa, Azure SignalR Hizmeti yeni bağlantıları kalan iyi durumdaki bölgelerdeki örneklere yönlendirir.

Requirements

• Bölge desteği: Alanlar arası yedeklilik, bu koşulların her ikisinin de geçerli olduğu çoğu bölgede desteklenir:

  • Azure SignalR Hizmeti kullanılabilir. Hizmetin kullanılabilir olduğu bölgelerin listesi için bkz. Bölgeye Göre Ürün Kullanılabilirliği.
  • Bölge, kullanılabilirlik alanlarını desteklemektedir. Kullanılabilirlik alanları olan bölgelerin listesi için bkz. Azure bölgeleri listesi.

  Ancak Batı Japonya şu anda Azure SignalR Hizmeti için bölge yedekliliğini desteklememektedir.

• Katmanı: Bölge yedekliliği Premium katmanında kullanılabilir.

Cost

Alanlar arası yedeklilik maliyet eklemez ve standart Premium katman oranını ödersiniz. Daha fazla bilgi için bkz. Azure SignalR Hizmeti pricing.

Kullanılabilirlik alanı desteğini yapılandırma

Alanlar arası yedeklilik, Premium katmanı seçmenin ötesinde bir yapılandırma gerektirmez. Bu iki durumda da otomatik olarak etkinleştirilir:

• Alanlar arası yedekli yeni bir SignalR Hizmeti kaynağı oluşturun. Kaynağı oluştururken bir Premium katman SKU'su seçin. Daha fazla bilgi için Quickstart: SignalR Hizmeti kullanarak sohbet odası oluşturma gibi hızlı başlangıçlara bakın.

• Mevcut bir kaynağı Premium katmanına yükseltin. Mevcut bir kaynağı Premium katman SKU'sundan yükselttiğiniz zaman alanlar arası yedeklilik otomatik olarak etkinleştirilir. Standart'tan Premium'a yükseltmek hizmet kapalı kalma süresine neden olmaz. Daha fazla bilgi için bkz. Azure SignalR Hizmeti katmanınızı değiştirme.

Tüm bölgeler sağlıklı olduğunda davranış

Bu bölümde, alanlar arası yedeklilik için bir Azure SignalR Hizmeti kaynağı yapılandırdığınızda ve tüm kullanılabilirlik alanları çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Cross-zone operation: Azure SignalR Hizmeti bağlantıların ve işlemlerin kullanılabilirlik alanları arasında nasıl dağıtıldığını otomatik olarak yönetir. Birden çok bölgede altyapı, etkin-etkin modelde trafiği işler. Bu davranışlardan yararlanmak için herhangi bir şey yapılandırmanız gerekmez. Hizmet, örnekler arasındaki iletileri bölgeler arasında otomatik olarak yönlendirir, bu nedenle bir bölgedeki istemci tarafından gönderilen bir ileti başka bir bölgeye bağlı istemcilere teslim edilir.

• Cross-zone veri çoğaltma: Azure SignalR Hizmeti müşteri verilerini kalıcı hale getirmez, bu nedenle bölgeler arasında çoğaltılması gereken veri yoktur. Bağlantı durumu kısa ömürlüdür ve her etkin bağlantıyla ilişkilendirilir.

Bölge hatası sırasındaki davranış

Bu bölümde, bir Azure SignalR Hizmeti kaynağını alanlar arası yedeklilik için yapılandırdığınızda ve kullanılabilirlik alanlarından birinde kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Algılama ve yanıt: Azure SignalR Hizmeti platformu, kullanılabilirlik alanındaki bir hatayı algılamaktan sorumludur. Bölge yük devretmesi başlatmak için herhangi bir işlem yapmanız gerekmez.

• Bildirim: Bir bölge kapatıldığında Microsoft sizi otomatik olarak bilgilendirmez. Ancak, tek bir kaynağın durumunu izlemek için Azure Kaynak Durumu'nı kullanabilir ve sorunları size bildirmek için Kaynak Durumu uyarıları ayarlayabilirsiniz. Azure Hizmet Durumu'nı , bölge hataları dahil olmak üzere hizmetin genel durumunu anlamak için de kullanabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

• Etkin istekler: Bölge hatası sırasında, etkilenen bölgedeki düğümlerle etkin bağlantılar kesilir. İstemcileriniz kısa bir süre sonra yeniden bağlanma gibi geçici hataları uygun şekilde işlerse, bunlar genellikle önemli bir etkiyi önler.

• Expected data loss: Azure SignalR Hizmeti iletileri kalıcı hale getirmediğinden, bölge hatasının Azure SignalR service içinde veri kaybına neden olması beklenmez. Ancak, bölge düşüşü olayı sırasında tüm etkin bağlantılar kesilir ve bu nedenle etkin olarak iletilen verilerin tamamı kaybolabilir.

• Beklenen kapalı kalma süresi: Bırakılan etkin bağlantıların yeniden bağlanması genellikle birkaç saniye sürer. Yeniden bağlanma mantığı uygulayan istemciler en az kesinti yaşar.

• Redistribution: Azure SignalR Hizmeti bölgenin kaybını algılar ve trafiği sağlıklı bölgeler arasında otomatik olarak yeniden dağıtır. Herhangi bir işlem yapmanız gerekmez.

Bölge kurtarma

Kullanılabilirlik alanı kurtarıldığında, Azure SignalR Hizmeti otomatik olarak bunu etkin hizmet topolojisine yeniden ekler. Bölge kurtarma için herhangi bir işlem yapmanız gerekmez.

Bir bölge kurtarıldıktan sonra, kurtarılan bölgedeki altyapıya yeni bağlantılar yönlendirilebilir. Mevcut bağlantılar kurtarılan bölgeye taşınmaz veya yeniden dengelenmez, ancak mevcut bağlantılar zaman içinde düşüp yeniden bağlandıkça kademeli olarak yeniden dengelenecektir. Bölgeler arasındaki bağlantı dengesizliği iş yükünüz üzerinde herhangi bir etkiye sahip değildir.

Bölge hataları için test

Azure SignalR Hizmeti bölgeler arası yedekli Premium katman kaynakları için trafik yönlendirmeyi, yük devretmeyi ve bölge kurtarımını otomatik olarak yönetir. Hiçbir şey başlatmanıza gerek yoktur. Alanlar arası yedeklilik tamamen yönetildiğinden kullanılabilirlik alanı hata işlemlerini doğrulamanız gerekmez.

Bölge genelindeki hatalara dayanıklılık

Azure SignalR Hizmeti tek bölgeli bir hizmettir. Bölge kullanılamaz duruma gelirse, SignalR Hizmeti kaynağınız da kullanılamaz.

Uygulamanızı bölge genelindeki bir hataya karşı korumak için, Premium katmanında bulunan coğrafi çoğaltmayı kullanabilirsiniz. Alternatif olarak, farklı bölgelerde birden çok SignalR Hizmeti kaynağı dağıtarak özel bir çoklu bölge çözümü oluşturabilirsiniz.

Coğrafi çoğaltma

Coğrafi çoğaltma, diğer Azure bölgelerinde SignalR Hizmeti kaynağınızın kopyalarını eklemenize olanak tanır. Azure Traffic Manager, her istemciyi en yakın sağlıklı bölgesel çoğaltmaya yönlendirmek için DNS tabanlı yönlendirme kullanır. Bir bölge başarısız olursa Traffic Manager, sağlık kontrolleri aracılığıyla hatayı algılar ve istemcileri o kopyaya yönlendirmeyi durdurur. Yeni istemci bağlantıları otomatik olarak en yakın sağlıklı çoğaltmaya yönlendirilir.

Azure SignalR Hizmeti kaynağını oluşturduğunuz bölgeye birincil bölge ve çoğaltması birincil kopya olarak adlandırılır. Birincil kaynağın kontrol düzlemi, Azure SignalR Hizmeti kaynağınızın yapılandırmasını yönetir.

Requirements

• Region support: Azure SignalR Hizmeti kullanılabilir olduğu herhangi bir bölgeye çoğaltma ekleyebilirsiniz.
• Katmanı: Coğrafi çoğaltmayı etkinleştirmek için Premium katmanını kullanmanız gerekir.
• Replica limit: Her birincil SignalR Hizmeti kaynağı en fazla sekiz çoğaltmayı destekler.

Değerlendirmeler

• Yapılandırma devralma: Çoğaltmalar çoğu yapılandırma ayarlarını birincil kaynaktan devralır. Belirli ayarların her çoğaltmada ayrı olarak yapılandırılması gerekir. Azure SignalR Hizmeti'de Geo-replication konusu altında devralınmayacak ayarların tam listesi için bkz.

• Configuration changes: Birincil bölgedeki birincil denetim düzlemi, SignalR Hizmeti kaynağındaki tüm yapılandırma değişikliklerini işler. Birincil denetim düzlemi kullanılamıyorsa kaynak yapılandırmasını güncelleştiremezsiniz, ancak mevcut çoğaltmalar kesinti olmadan veri trafiğini işlemeye devam eder.

Cost

Her bir replik, kendi birim sayısına ve giden ileti hacmine göre ayrı olarak faturalandırılır. Bölgeler arası çıkış ücretleri, iletiler çoğaltmalar arasında aktarıldığında ve başka bir bölgedeki istemcilere veya sunuculara teslim edildiğinde uygulanır. Daha fazla bilgi için bkz. Azure SignalR Hizmeti pricing.

Coğrafi çoğaltmayı yapılandır

SignalR Hizmeti kaynağına çoğaltma eklemek veya kaldırmak için Azure SignalR Hizmeti'de Geo-replication konusuna bakın.

Kapasite planlaması ve yönetimi

Her bir replika trafiği bağımsız olarak işler. Bölgesel yol değiştirme sırasında, başarısız bölgeden istemciler en yakın sağlıklı kopyaya yeniden bağlanır. Ayakta kalan replikaların bu ek yükü emmek için yeterli kapasiteye sahip olduğundan emin olmak için, her replikayı yalnızca genellikle hizmet verdiği kısımdan daha fazlasını değil, iş yükünün tam beklenen trafiğini işleyebilen birimlerle yapılandırın.

Alternatif olarak, birimlerin daha yüksek yüke yanıt olarak otomatik olarak ölçeği genişletebilmesi için her çoğaltmada otomatik ölçeklendirmeyi etkinleştirin. İkincil çoğaltma kullanılamadığında otomatik ölçeklendirme çalışmaya devam eder, ancak birincil denetim düzlemi kullanılamıyorsa otomatik ölçeklendirme çalışmaz. Daha fazla bilgi için Azure SignalR Hizmetinde Otomatik Ölçeklendirme bölümüne bakın.

Strateji olarak fazla sağlama hakkında genel yönergeler için bkz. Fazla sağlama yaparak kapasiteyi yönetme.

Tüm bölgeler iyi durumda olduğunda davranış

Bu bölümde, coğrafi çoğaltma için Azure SignalR Hizmeti yapılandırdığınızda ve tüm çoğaltmalar çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Cross-region operation: Azure Traffic Manager her istemciyi en yakın iyi durumdaki bölgesel çoğaltmaya yönlendirir. Farklı coğrafi bölgelerdeki istemciler farklı çoğaltmalara bağlanabilir. SignalR Hizmeti, herhangi bir çoğaltmaya bağlı istemcilerin birbirleriyle iletişim kurabilmesi için iletileri çoğaltmalar arasında eşitler.

• Bölgeler arası veri çoğaltma: Bir çoğaltmaya ileti gönderildiğinde, hizmet bu iletiyi başka bir yere bağlı istemcilerin alabilmesi için zaman uyumlu bir şekilde diğer çoğaltmalara aktarır. Eşitleme ek yükü, büyük gruplara yayın yapma veya tek bir bağlantıyla mesajlaşma gibi en yaygın mesajlaşma düzenleri için en düşük düzeydedir. Küçük gruplara ileti gönderme (10'dan az üye) biraz daha yüksek eşitleme yüküne neden olabilir.

  Azure SignalR Hizmeti iletileri kalıcı hale getirmez; kopyalar arasında yalnızca aktif teslimat eşitlenir.

Bölge hatası sırasındaki davranış

Bu bölümde, coğrafi çoğaltma için Azure SignalR Hizmeti yapılandırdığınızda ve çoğaltma bölgelerinden birinde kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Algılama ve yanıt: SignalR Hizmeti, bir bölgede bir arızayı algılamak ve gelen trafiği, yapılandırdığınız diğer bölgelerden birindeki bir kopyaya otomatik olarak yeniden yönlendirmekten sorumludur.

• Bildirim: Microsoft, bir bölge kapatıldığında size otomatik olarak bildirim vermez. Bununla birlikte, tüm bölge hataları dahil olmak üzere hizmetin genel durumunu anlamak için Azure Hizmet Durumu'nı kullanabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

• Etkin istekler: Başarısız bölgedeki çoğaltmaya etkin bağlantılar kesilir. Çoğaltıcı devreye girdikten sonra istemcilerin yeniden bağlanması gerekir.

• Beklenen veri kaybı: Azure SignalR Hizmeti iletileri kalıcı hale getirmez. Hatanın meydana geldiği anda, başarısız olan bölgedeki istemcilere ulaştırılmakta olan iletiler kaybolabilir. Hizmet müşteri verilerini depolamadığından kalıcı veri kaybı beklenmez.

• Beklenen kesinti: Azure Traffic Manager her çoğaltma üzerinde sistem durumu denetimleri gerçekleştirir. Bölge kesintisi çoğaltmanın sistem durumu denetiminde başarısız olmasına neden olduğunda, Traffic Manager bu çoğaltmanın uç noktasını DNS çözümleme sonuçlarından kaldırır. Uç nokta kaldırıldıktan sonra, istemcilerin güncelleştirilmiş DNS kayıtlarını görmesi için 90 saniyelik DNS TTL'sinin geçmesi gerekir. Toplamda, geçiş genellikle birkaç dakika sürer. Yeniden bağlantı mantığı uygulayan iyi tasarlanmış istemciler, iyi durumdaki çoğaltmaya yeniden bağlandıktan sonra normal çalışmaya devam edebilir.

  Birincil denetim düzlemi kullanılamıyorsa, SignalR Hizmeti kaynağınızın veya çoğaltmalarının yapılandırmasında herhangi bir değişiklik yapamazsınız. Ancak, bağlantılar iyi durumdaki çoğaltmalarda çalışmaya devam eder.

• Redistribution: Azure Traffic Manager gelen isteği sağlıklı çoğaltmalara yönlendirir. Ancak, bir istemci, Azure Traffic Manager replica yük devretmesini algılamadan önce yeniden bağlanmayı denerse ve güncellenmiş DNS girişleri henüz istemciye yayılmamışsa, istemcinin yeniden bağlanma girişimi, kullanılamayan bölgeyi hedeflemeye devam edebilir ve başarısız olabilir.

  DNS güncelleştirmesi yayıldıktan sonra, yeniden bağlanan istemciler otomatik olarak en yakın iyi durumdaki çoğaltmaya yönlendirilir.

Bölge geri kazanımı

Başarısız bölge kurtarıldığında, Traffic Manager'ın sağlık kontrolü geri yüklenen replikayı algılar ve onun uç noktasını DNS çözümlemesine yeniden ekler. Şu anda diğer çoğaltmalara bağlı olan istemciler etkilenmez ve bağlantı kesilene kadar bağlı kalır. En yakın sağlıklı çoğaltma olduğunda yeni bağlantılar yeniden kurtarılan bölgenin çoğaltmasına yönlendirilir.

Bölge hataları testi

Bölge aktarımı benzetimi yapmak ve istemci uygulamanızın yeniden bağlanma davranışını test etmek için bir replikanın uç noktasını devre dışı bırakabilirsiniz. Bu eylem Traffic Manager'ın trafiği bu çoğaltmaya yönlendirmeyi durdurmasına neden olur ve bu da istemcilerinizin bağlandıkları çoğaltma kullanılamaz duruma geldiğinde nasıl davrandığını gözlemlemenize olanak tanır. Ayrıntılı adımlar için bkz. Çoğaltma uç noktasını devre dışı bırakma veya etkinleştirme.

Dayanıklılık için özel çok bölgeli çözümler

Bölgeler arası dayanıklılığa ihtiyacınız varsa ancak coğrafi çoğaltma kullanmıyorsanız, birden çok bölgede ayrı SignalR Hizmeti kaynakları dağıtabilir ve yönetebilir ve uygulama sunucunuzda kendi yük devretme mantığınızı uygulayabilirsiniz. Bu yaklaşım coğrafi çoğaltmadan daha karmaşıktır ve istemciler arası bağlanabilirlik için kesintisiz yük devretmeyi desteklemez. Ayrıntılı mimariye genel bakış, yük devretme desenleri ve test kılavuzu hakkında daha fazla bilgi için Azure SignalR Hizmeti'te Dayanıklılık ve Felaket Kurtarma bölümüne bakın.

Yedekleme ve geri yükleme

Azure SignalR Hizmeti durum bilgisi olmayan bir mesajlaşma hizmetidir. Müşteri iletilerini kalıcı hale getirmez ve yedekleme veya geri yükleme özelliği yoktur.

Kaynak yapılandırmanızı korumak için kod olarak altyapı (Bicep veya ARM şablonları gibi) kullanarak SignalR Hizmeti kaynaklarınızı tanımlayın ve bu tanımları kaynak denetiminde depolayın. Bir kaynağı yeniden oluşturmanız gerekiyorsa, depolanmış yapılandırmadan yeniden dağıtın.

Hizmet bakımına dayanıklılık

Microsoft düzenli olarak hizmet güncelleştirmeleri uygular ve başka bakımlar gerçekleştirir. Azure platformu bu etkinlikleri otomatik olarak işleyerek bakımın sizin için sorunsuz ve şeffaf olmasını sağlar. Azure Hizmet Durumu planlı bakım aracılığıyla size bildirilmedikçe, bakım olayları sırasında kapalı kalma süresi olmayacağı öngörülmektedir.

Planlı bakım sırasında Azure SignalR Hizmeti, bağlı istemciler üzerindeki etkiyi azaltmak için düzgün bir kapatma stratejisi kullanır. Bağlantılar belirli bir zaman dilimi içinde kademeli olarak kesilir ve bu sayede istemcilerin aynı anda değil, yavaş yavaş yeniden bağlanmaları sağlanır. Daha fazla bilgi için bkz . Hizmet bakımı sırasında bağlantı kesilmeleri.

Bağlantı düştükçe bakım olayları istemcilerinize görünür. İstemci uygulamalarınızın, bakımla ilgili bağlantı kesilmelerini kullanıcı görünür kesintisi olmadan kurtarabilmeleri için yeniden bağlantı mantığı uyguladığından emin olun.

Hizmet düzeyi sözleşmesi

Azure hizmetleri için hizmet düzeyi sözleşmesi (SLA), her hizmetin beklenen kullanılabilirliğini ve bu kullanılabilirlik beklentisini elde etmek için çözümünüzün karşılaması gereken koşulları açıklar. Daha fazla bilgi için bkz. çevrimiçi hizmetler için SLA’lar.

İlgili içerik

• Azure'da güvenilirlik
• Azure SignalR Hizmeti genel bakış
• Azure SignalR Servisinde Coğrafi Üretim
• Azure SignalR Hizmeti'nde Dayanıklılık ve Olağanüstü Durum Kurtarma
• Azure SignalR Hizmeti'nde istemci bağlantı kesilmelerini ve yeniden bağlanmaları anlama