Azure Notification Hubs'da güvenilirlik

Azure Notification Hubs, Apple Anında İletme Bildirimi hizmeti (APN), Firebase Cloud Messaging (FCM) ve Windows Anında İletme Bildirimi Hizmeti (WNS) gibi birden çok platform bildirim sisteminde (PNS) anında iletme bildirimlerini yönetmenize yardımcı olur.

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 Notification Hubs'ın geçici hatalar, kullanılabilirlik alanı hataları, bölge genelindeki hatalar ve hizmet bakımı gibi çeşitli olası kesintilere ve sorunlara karşı nasıl dayanıklı hale getirilmeye başlandığı açıklanır. Ayrıca, Notification Hubs hizmet düzeyi sözleşmesi (SLA) hakkında yedekleme ve geri yükleme seçeneklerini ve önemli bilgileri açıklar.

Üretim dağıtımı önerileri

Üretim iş yükleri için şu önerileri izleyin:

• Ad alanınızın SLA için uygun olması için Temel veya Standart katmanını kullanın.

• Mümkün olduğunda, cihaz uygulamalarında kayıt yerine yüklemeleri kullanın.

• Notification Hubs ile etkileşimde Microsoft sağlanan SDK'ları kullanın.

• Alanlar arası yedekliliği etkinleştirin.

• Bölge genelinde kesintilere hazırlanmak için meta veri olağanüstü durum kurtarmayı başka bir Azure bölgeye etkinleştirin. Cihaz kayıtlarını ve yüklemelerini yedeklemeyi ve geri yüklemeyi planlayın.

Güvenilirlik mimarisine genel bakış

Azure Notification Hubs, ad alanları ve bildirim hub'ları temel alınarak düzenlenmiştir. Ad alanı, bir veya daha fazla hub içeren bir yönetim sınırıdır. Hub'lar bir uygulamanın uç noktalarını temsil eder. Cihazlar, hizmetin cihazlara anlık bildirimler göndermesini sağlayan kayıtlar veya kurulumlar kullanarak bu uç noktalara kaydolur. Daha fazla bilgi için bkz . Kayıt yönetimi.

Notification Hubs, Apple Anında İletme Bildirimi hizmeti (APN'ler) ve Firebase Cloud Messaging (FCM) gibi platform bildirim sistemlerine (PNS) anında iletme bildirimleri gönderir. Uçtan uca bildirim teslimi Notification Hubs'ın kullanılabilirliğine ve aşağı akış PNS sağlayıcılarının davranışına bağlıdır.

Güvenilirlik planlaması için Notification Hubs'ın yönettiği aşağıdaki veri türlerini ayırt etmek önemlidir:

• Meta veriler: Bağlantı bilgileri ve olağanüstü durum kurtarma yapılandırması dahil olmak üzere ad alanı ve hub yapılandırması.
• Kayıt verileri: Kullanıcıları ve cihazları etiketler ve şablonlarla eşleyen cihaz kayıtları ve yüklemeleri.

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.

Notification Hubs, bir PNS'ye bağlanırken oluşan geçici hataları otomatik olarak işler. Ancak hizmetleriniz veya kullanıcılarınızın cihazları Notification Hubs ile etkileşime geçtiğinde geçici hataların işlenmesi sizin sorumluluğunuzdadır. Kayıt işlemleri, bildirim gönderme işlemleri ve yönetim işlemleri sırasında geçici hatalar oluşabilir. Şu yönergeleri izleyin:

• Kayıtlar ve yüklemeler: Cihazlarınızdaki uygulamalarınız geçici hatalar nedeniyle başarısız olan kayıt ve yükleme işlemlerini yeniden denemelidir. Microsoft sağlanan SDK'lar yeniden denemeleri otomatik olarak işler. Sağlanan SDK'ları kullanamıyorsanız üstel geri alma ve değişim ile yeniden deneme mantığını uygulayın ve kayıt işlemlerini mümkün olduğunca etkili hale getirin.

  Bir kurulumu oluşturmak veya güncellemek idempotenttir; bu nedenle işlemi güvenle yeniden deneyebilirsiniz. Mümkün olduğunda, kayıtlar yerine yüklemeleri kullanın.

• Bildirim gönderme ve yönetim işlemleri: Anında iletme bildirimleri göndermek ve yönetim işlemlerini gerçekleştirmek için Microsoft sağlanan bir SDK kullanın. Bu SDK'lar geçici hatalar oluştuğunda otomatik olarak yeniden dener.

  Sağlanan SDK’ları kullanamıyorsanız, üstel geri çekilme ve jitter içeren yeniden deneme mantığı uygulayın ve mümkün olduğunda bildirim gönderme işlemlerinin idempotent olmasını sağlayın.

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.

Kullanılabilirlik alanlarını destekleyen bölgelerde Notification Hubs ad alanları alanlar arası yedekli yapılandırmayı destekler. Notification Hubs, bazı bölgelerdeki tüm ad alanları için bölge yedekliliğini otomatik olarak etkinleştirir. Alanlar arası yedeklilik etkinleştirildiğinde, Microsoft hem meta verileri hem de kayıt verilerini bölgedeki tüm kullanılabilirlik alanları arasında çoğaltır.

Diyagramda kullanılabilirlik alanları 1, 2 ve 3 gösterilmektedir. Tek bir Notification Hubs ad alanı üç bölgeye de yayılmıştır.

Requirements

• Bölge desteği:

  Notification Hubs, aşağıdaki bölgelerdeki tüm ad alanları için bölge yedekliliğini otomatik olarak etkinleştirir. Bu bölgelerde alanlar arası yedekliliği devre dışı bırakamazsınız:

  Europe	Orta Doğu	Africa	Asia Pacific
  Orta Fransa	Qatar Central	Güney Afrika - Kuzey	Kuzey Çin 3
  Kuzey İtalya			Korea Central
  Norveç Doğu
  Orta Polonya
  Orta İsveç
  Switzerland North

  Notification Hubs'ı destekleyen ve kullanılabilirlik alanlarına sahip diğer bölgelerde alanlar arası yedeklilik isteğe bağlıdır. Yalnızca bir ad alanı oluşturduğunuzda etkinleştirebilirsiniz.

• Katman desteği: Notification Hubs'ın tüm katmanlarıyla kullanılabilirlik alanlarını kullanabilirsiniz.

Cost

Alanlar arası yedeklilik, katman fiyatının ötesinde ek ücrete neden olur. Daha fazla bilgi için bkz . Notification Hubs fiyatlandırması.

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

• Yeni bir alanlar arası yedekli ad alanı oluşturun: Alanlar arası yedekli yeni bir ad alanı oluşturma işlemi, kullandığınız bölgeye bağlıdır:

  • Notification Hubs'ın alanlar arası yedekliliği otomatik olarak etkinleştirdiği bölgelerde, bunu yapılandırmanız gerekmez.

    Important

    Bicep dosyası veya Azure Resource Manager şablonu gibi kod tabanlı bir dağıtım, bölge yedekliliğini devre dışı bırakıldığını belirtse bile, bu bölgelerde Notification Hubs her zaman alanlar arası yedeklilik etkinleştirilmiş ad alanları oluşturur.

    Alanlar arası yedekli bir ad alanı istemiyorsanız, isteğe bağlı alanlar arası yedekliliği destekleyen bir bölgede oluşturun.

  • Bölge yedekliliğini isteğe bağlı olan bölgelerde, yalnızca bir ad alanı oluşturduğunuzda etkinleştirebilirsiniz. Alanlar arası yedekliliğe sahip yeni bir ad alanı ayarlamayı öğrenmek için bkz. Azure portalında Azure bildirim hub'ı oluşturma.

• Mevcut bir ad alanı bölgesini yedekli hale getirin: Notification Hubs, mevcut bir ad alanının kullanılabilirlik alanı desteğine yerinde geçişini desteklemez. Yeni bir ad alanı dağıtmanız ve kayıtlarınızı bu ad alanına taşımanız gerekir. Yeni ad alanını aynı bölgeye dağıtırsanız da geçerli olan kaynakları Azure bölgeler arasında taşıma başlığındaki yönergeleri izleyin.

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

Bu bölümde, bir Notification Hubs ad alanını alanlar arası yedeklilik için yapılandırdığınızda ve tüm bölgeler çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Bölgeler arası işlem: Notification Hubs, bölgedeki herhangi bir bölgedeki altyapıyı kullanarak istekleri otomatik olarak dağıtır ve sunar.

• Bölgeler arası veri çoğaltma: Hem kayıt verileri hem de meta veriler, belirtilen bölgedeki tüm bölgeler arasında zaman uyumlu olarak çoğaltılır.

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

Bu bölümde, bir Notification Hubs ad alanını alanlar arası yedeklilik için yapılandırdığınızda ve bölgelerden birinde kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Tespit ve müdahale: Microsoft bölge arızalarını tespit eder ve bölge içindeki yük devretmeyi yönetir. Yük devretmeyi başlatmanız gerekmez.

• Notification: Microsoft bir bölge kapatıldığında sizi otomatik olarak bilgilendirmez. Bununla birlikte, 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: Yük devretme sırasında uçuş içi yönetim işlemleri, cihaz kayıtları ve bildirim göndermeye yönelik yeni istekler başarısız olabilir. Uygulamalarınız geçici hata işleme yönergelerini izleyerek başarısız işlemleri yeniden denemelidir.

• Beklenen veri kaybı: Notification Hubs ad alanı ve hub yapılandırması ile kayıt verilerini kullanılabilirlik alanları arasında zaman uyumlu bir şekilde çoğalttığı için tek bölgeli bir kesinti sırasında veri kaybı beklenmez.

  Bu çoğaltma bir yedekleme değildir. Paylaşılan sorumluluk modeli kapsamında kayıt ve yükleme verilerini yedeklemek sizin sorumluluğundadır. Daha fazla bilgi için bkz . Yedekleme ve geri yükleme.

• Beklenen kapalı kalma süresi: Microsoft trafiği yeniden yönlendirirken kısa bir hizmet kesintisi olabilir. Uygulamalarınızı bu kesintilere hazırlamak için geçici hata işleme kılavuzunu izleyin.

• Yeniden dağıtım: Hizmet istekleri otomatik olarak iyi durumdaki bölgelere yönlendirir.

Bölge kurtarma

Etkilenen bölge kurtarıldığında herhangi bir işlem yapmanız gerekmez. Microsoft, kurtarılan bölgeyi kullanmak için Notification Hubs altyapısını geri yükler ve yeniden dengeler.

Bölge hataları için test

Notification Hubs bölgesi yük devretmesini doğrudan tetikleyemezsiniz. İş yükünüzün davranışını test etmek için, üretim dışı ortamlarda yeniden denemeler, idempotentlik ve bağımlılık hataları için dayanıklılık testleri çalıştırın. Çevresindeki uygulama bileşenlerini test etmek için Azure Chaos Studio de kullanabilirsiniz.

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

Notification Hubs, bölgeler arasında ad alanı meta verilerini çoğaltarak meta veri olağanüstü durum kurtarma sağlar, ancak cihaz kayıt verilerini çoğaltmaz. Bu özellik, bölgesel bir hizmet kesintisi sırasında manuel müdahale gerektirir ve bildirim merkezinizde bir süre kesinti yaşanmasına neden olur.

Yük devretme sırasında kesinti süresini ve manuel müdahaleyi azaltmanız gerekiyorsa, özel bir çoklu bölge çözümü kullanmayı değerlendirin.

Microsoft tarafından yönetilen meta veriler için coğrafi olağanüstü durumdan kurtarma

Notification Hubs, Microsoft tarafından yönetilen meta veri olağanüstü durum kurtarmayı ikincil bir Azure bölgesine destekler. Birincil bölgenizin eşleştirilmiş bir bölgesi varsa, bu eşleştirilmiş bölgeyi seçebilirsiniz. Birincil bölgenizin eşleştirme durumundan bağımsız olarak , esnek kurtarma bölgeleri listesinden ikincil bir bölge de seçebilirsiniz. Notification Hubs daha sonra ad alanı adı, bağlantı dizeleri ve diğer kritik bilgiler gibi ad alanı meta verilerini çoğaltır.

İstemci uygulaması, ad alanı uç noktası üzerinden birincil bölgedeki birincil ad alanına bağlanır. Birincil ad alanı meta verileri ve kayıtları içerir. Notification Hubs yalnızca ikincil bölgedeki ikincil ad alanına meta verileri çoğaltır; kayıt verileri çoğaltılmıyor.

Important

Meta veri coğrafi olağanüstü durum kurtarması, kayıt verilerini çoğaltmaz. Olağanüstü durum kurtarma senaryosu tetiklendiğinde kayıt ve yükleme verileri kaybolabilir. Kurtarma işleminden sonra hub'ınızdaki kayıt verilerini yeniden doldurmaya yönelik bir çözüm uygulamak sizin sorumluluğunuzdadır.

Microsoft, bir afet durumu ilan etmek ve yük devretme işlemini başlatmaktan sorumludur. Bu durumda, Microsoft ikincil bölgede yeni bir ad alanı oluşturur. Birincil bölgedeki meta verileri kullandığından, uygulamalar mevcut ad alanı adını, bağlantı dizesi ve hub adlarını kullanarak bu ad alanına bağlanabilir.

Birincil bölge ve ad alanı kullanılamıyor ve birincil bölgeden meta veri çoğaltması durduruldu. İstemci uygulaması, ikincil bölgedeki ikincil ad alanına bağlanan ad alanı uç noktasını kullanmaya devam eder. İkincil ad alanı, çoğaltılan meta verileri içerir ancak birincil ad alanından kayıtları içermez.

Requirements

• Bölge desteği: Eşleştirilmiş Azure bölgelerde ad alanınız, eşleştirilmiş Azure bölgeyi ikincil bölge olarak kullanabilir.

  Ad alanınız eşleştirilmemiş bir bölgedeyse veya verileri farklı bir bölgeye çoğaltmak istiyorsanız, ikincil bölge olarak aşağıdaki esnek kurtarma bölgelerinden birini seçebilirsiniz:

  Americas	Europe	Africa	Asia Pacific
  Güney Brezilya	Kuzey Avrupa	Güney Afrika - Kuzey	Australia East
  Batı ABD 2			Güneydoğu Asya

• Katman desteği: Meta veri olağanüstü durum kurtarma seçenekleri tüm Notification Hubs katmanlarında kullanılabilir.

Cost

Notification Hubs, meta veri coğrafi olağanüstü durum kurtarmayı yapılandırmak veya kullanmak için ek ücret almaz. Ancak, meta verileri çoğaltmak için kullanılan bölgeler arası bant genişliği için ödeme yapın. Fiyatlandırma ayrıntıları için bkz . Bant genişliği fiyatlandırması ve Notification Hubs fiyatlandırması.

Çoklu bölge desteğini yapılandırma

• Yeni bir ad alanı için meta veri coğrafi olağanüstü durum kurtarmayı etkinleştirin:Azure portalında Azure bildirim hub'ı oluşturma başlığındaki yordamı izleyin. Ad alanını oluştururken olağanüstü durum kurtarma yapılandırmasını seçin.

• Mevcut bir ad alanı için meta veri coğrafi olağanüstü durum kurtarmayı etkinleştirin veya devre dışı bırakın:Mevcut bir Azure Notification Hubs ad alanı için olağanüstü durum kurtarmayı etkinleştirme bölümünde yer alan yordamı izleyin.

• Cihaz kayıt verilerinizi yedekleyin: Bkz. Azure Notification Hubs kayıtlarını toplu olarak dışarı ve içeri aktarma.

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

Bu bölümde, meta veri coğrafi olağanüstü durum kurtarma için bir Notification Hubs ad alanı yapılandırdığınızda ve hem birincil hem de ikincil bölgeleriniz çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Bölgeler arası işlem: Birincil bölge tüm isteklere hizmet eder. yük devretme gerçekleşmediği sürece ikincil bölge isteklere hizmet vermez.

• Bölgeler arası veri çoğaltma: Ad alanı adı, hub yapılandırması, bağlantı dizeleri ve diğer kritik bilgiler gibi meta veriler bölgeler arasında zaman uyumsuz olarak çoğaltılır. Kayıt verileri çoğaltılmaz. Yedeklemeyi korumak için düzenli olarak dışarı aktarmak sizin sorumluluğundadır.

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

Bu bölümde, meta veri coğrafi olağanüstü durum kurtarma için bir Notification Hubs ad alanı yapılandırdığınızda ve birincil bölgede bir kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Algılama ve yanıt: Microsoft, bölge hatasını algılamaktan ve yapılandırılan ikincil bölgeye yük devretmenin tetiklenip tetiklenmeyeceğine karar vermekle 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: Birincil bölgedeki ad alanına yönelik uçuş içi istekler, bölge çevrimdışı olduğunda başarısız olabilir. İstemciler yük devretme tamamlandıktan sonra işlemleri yeniden denemelidir.

• Beklenen veri kaybı: Meta veriler korunur. Kayıt verileri otomatik olarak yedeklenmez, ancak kendiniz yedekleyebilirsiniz. Daha fazla bilgi için bkz. Azure Notification Hubs kayıtlarını toplu olarak dışarı ve içeri aktarma. Bunu yapmazsanız, birincil bölge kurtulana kadar kayıt verileri kullanılamaz.

• Beklenen kesinti süresi: Microsoft’un meta veriler için yük devretmeyi tetiklemesi ve ardından bu yük devretmenin tamamlanması biraz zaman alır. Süre değişebilir ancak genellikle birkaç saat sürer.

  Yük devretme tamamlandıktan sonra kayıt verilerinin tüm yedeklemelerini geri yüklemek sizin sorumluluğundadır.

• Yeniden dağıtım: Yük devretmeden sonra istekler, birincil bölgeden çoğaltılan verileri kullanan ikincil bölgedeki bir ad alanına yönlendirilir. Yük devretme tamamlandıktan sonra istemciler ikincil bölgedeki ad alanına otomatik olarak bağlanır.

Bölge geri kazanımı

Birincil bölge kurtarılırsa, birincil bölgedeki birincil ad alanına geri dönmek mümkün olabilir. Birincil ad alanı, kesintiden önce kayıt verilerini korur. Bu el ile gerçekleştirilen bir işlemdir ve Microsoft bunun nasıl çalıştığını açıklamak için sizinle iletişim kurar.

Birincil bölge kurtarıldıktan sonra şunları yapmanız gerekir:

• Ad alanınızın ve verilerinin durumunu doğrulayın.
• İkincil bölgeden birincil bölgeye en son kayıt verileri değişikliklerinin eşitlenip eşitlenmeyeceğini belirleyin.

Bölge hataları testi

Coğrafi yük devretme başlatamazsınız. Ancak, kendi olağanüstü durum kurtarma yordamlarınızı test etmelisiniz. Kayıtların yedeklendiğini ve bunları yeni bir ad alanına geri yükleyebildiğinizi doğrulayın.

Dayanıklılık için özel çoklu bölge çözümleri

Microsoft tarafından yönetilen meta veriler için coğrafi olağanüstü durum kurtarma yalnızca meta verileri çoğaltır. Özellik bu meta verileri ikincil bir ad alanına kurtarabilir, ancak uygulamanızın çalışmaya devam edebilmesi için cihaz kayıtlarını bu ad alanına aktarmak sizin sorumluluğunuzdadır. Bu yaklaşım, olağanüstü durum sırasında el ile müdahale gerektirir ve kapalı kalma süresini içerir.

Kurtarma hedefleriniz daha az kesinti süresi veya manuel müdahale gerektiriyorsa, özel bir aktif-aktif çok bölgeli çözüm uygulayabilirsiniz. önceden başka bir Azure bölgeye ikinci bir Notification Hubs ad alanı dağıtın.

Uyarı

Bu bölümde, bu tür bir çözümü tasarlamaya yönelik temel yönergeler sağlanır. Çözümü tasarlamak, uygulamak, test etme, dağıtmak, yük devretmek ve yönetmek sizin sorumluluğundadır.

• Yük devretme: İkinci ad alanı çalışan bir kaynak olduğundan, bir bölgedeki arızayı algılayıp bu ad alanına geçecek mantığı uygulayabilirsiniz.

• Eşitleme: İkinci bir bildirim hub'ını birincil bildirim hub'ı ile eşitlenmiş durumda tutmak için aşağıdaki seçeneklerden birini kullanın:

  • Yüklemeler için: Her iki bildirim hub'ında da yüklemeleri aynı anda oluşturan ve güncelleştiren bir uygulama arka ucu kullanın. Yüklemeler, bu çoğaltma senaryosını destekleyen kendi benzersiz cihaz tanımlayıcınızı belirtmenizi sağlar. Daha fazla bilgi için bkz . RedundantHub örneği.

  • Kayıtlar için: Kayıtları birincil bildirim hub'ından düzenli olarak yedek olarak dışarı aktaran ve bunları ikincil bildirim hub'ına toplu olarak aktaran bir uygulama arka ucu kullanın. Daha fazla bilgi için bkz. Azure Notification Hubs kayıtlarını toplu olarak dışarı ve içeri aktarma.

  Alternatif olarak, arka ucunuz yoksa uygulamanızı hedef cihazlarda başlatıldığında her iki hub'da da yüklemeler oluşturacak şekilde yapılandırın. Cihazlar her iki bildirim hub'ında da yeni kayıtlar oluşturur. Sonunda ikincil bildirim hub'ına tüm etkin cihazlar kaydedilir.

• Süresi dolan kayıtlar ve yüklemeler: İkincil bildirim hub'ına kayıtların ve yüklemelerin süresi dolmuş olabilir. Süresi dolmuş bir tanımlayıcıya bir push bildirimi gönderildiğinde, Notification Hubs, PNS sunucusundan alınan yanıta bağlı olarak bildirim hub’ındaki ilişkili kayıt veya kurulum kaydını otomatik olarak temizler. Her gönderme işleminden gelen geri bildirimleri işleyen ve süresi dolan kayıtları ve yüklemeleri kaldıran özel mantık ekleyerek, süresi dolan kayıtları istediğiniz yedekleme çözümünden temizleyebilirsiniz.

• Açılmamış uygulamalar: Açılmamış uygulamaları olan cihazların bildirim almadığı bir süre vardır.

• Maliyet: Kayıt verilerini korumak için kendi ikincil hub'ınızı kullanırsanız bu hub normal hizmet ücretlerine tabi olur. Benzer şekilde, kurtarmanızı desteklemek için ikincil bölgenize başka Azure kaynakları dağıtırsanız, bu kaynaklar için normal hizmet fiyatlarıyla ödeme alırsınız.

Yedekleme ve geri yükleme

Notification Hubs, ad alanınızda depolanan tüm veriler için tek bir yerleşik yedekleme ve geri yükleme özelliği sağlamaz. Aşağıdaki yaklaşımları birleştirmek sizin sorumluluğundadır:

• Ad alanınızı, hub'ınızı ve ilke yapılandırmanızı tanımlamak için Bicep gibi kod olarak altyapıyı (IaC) kullanın. Gerektiğinde kaynakları yeniden dağıtabilmeniz için bu tanımları kaynak denetiminde depolayın.
• Azure Notification Hubs kayıtlarını toplu olarak dışarı aktararak cihaz kayıt verilerinizi yedekleyin.

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.

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.

Notification Hubs için kullanılabilirlik SLA'sı Temel ve Standart katmanlarını kullanan ad alanları için geçerlidir.

İlgili içerik

• Azure'da güvenilirlik