Azure IoT Hub güvenilirliği

Azure IoT Hub, bulutta barındırılan ve IoT uygulaması ile ekli cihazları arasındaki iletişim için merkezi bir ileti hub'ı işlevi gören yönetilen bir hizmettir.

Azure kullandığınızda, güvenilirlik paylaşılan bir sorumluluktur. 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 ve bölge kesintileri gibi çeşitli olası kesintilere ve sorunlara karşı IoT Hub nasıl dayanıklı hale getirilmeye başlandığı açıklanmaktadır. Ayrıca, yedeklemeleri diğer sorun türlerinden kurtarmak için nasıl kullanabileceğinizi açıklar ve IoT Hub hizmet düzeyi sözleşmesi (SLA) hakkındaki bazı önemli bilgileri vurgular.

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.

IoT Hub makul bir yüksek çalışma süresi garantisi sağlar, ancak herhangi bir dağıtılmış bilgi işlem platformunda geçici hatalar oluşabilir. Geçici hataları işlemek için bulut uygulamalarıyla etkileşim kuran bileşenlerde uygun yeniden deneme desenlerini oluşturun.

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

Availability bölgeleri Azure bölgesindeki fiziksel olarak ayrı veri merkezleri gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredilebilir.

IoT Hub iki farklı kullanılabilirlik alanı türünü destekler:

• Veriler için bölge yedekliliği, cihaz kimliği kayıt defteri ve cihazdan buluta iletileri depolayan altındaki depolama bileşenleri için, verileri birden çok kullanılabilirlik alanı arasında otomatik olarak çoğaltır.

• İşlem için alanlar arası yedeklilik, cihazları yönetmek ve iletileri yönlendirmek için sorumlu bileşenlerde dayanıklılık sağlar.

Gereksinimler

Bölge desteği: IoT hub'ınızın kullanılabilirlik alanı desteğinin türü, dağıtılan bölgeye bağlıdır.

Bölge	Veriler için alanlar arası yedeklilik	Hesaplama için bölge yedekliliği
Australia East
Güney Brezilya
Canada Central
Orta Hindistan
Central US
East US
Orta Fransa
Almanya Batı Merkez
Japonya Doğu
Korea Central
Kuzey Avrupa
Norway East
Qatar Central
ABD'nin Güney Merkez Bölgesi
Güneydoğu Asya
UK South
West Europe
Batı ABD 2
Batı ABD 3

Bu listede olmayan bölgelerde oluşturduğunuz IoT hub'ları bölge kesintilerine dayanıklı değildir.

Maliyet

IoT Hub ile alanlar arası yedeklilik için ek maliyet yoktur.

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

IoT Hub kaynakları, desteklenen bölgelerde dağıtıldığında bölge yedekliliğini otomatik olarak destekler. Başka bir yapılandırma gerekmez.

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

Bu bölümde, IoT Hub kaynaklar alanlar arası yedeklilik için yapılandırıldığında ve tüm kullanılabilirlik alanları çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Bölgeler arasında veri çoğaltma: IoT hub'ınız veriler için alanlar arası yedekliliği destekleyen bir bölgeye dağıtıldığında, verilerdeki değişiklikler kullanılabilirlik alanları arasında otomatik olarak çoğaltılır. Çoğaltma eş zamanlı olarak gerçekleşir.

• Bölgeler arasında trafik yönlendirme: IoT hub'ınız işlem bileşenleri için alanlar arası yedekliliği destekleyen bir bölgeye dağıtıldığında, istekler kullanılabilirlik alanlarından birinde hizmetin birincil örneğine yönlendirilir. Azure etkin örneği ve bölgeyi otomatik olarak seçer.

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

Bu bölümde, IoT Hub kaynakları alanlar arası yedeklilik için yapılandırıldığında ve kullanılabilirlik alanı kesintisi olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Detection and response: IoT Hub hizmeti kullanılabilirlik alanındaki bir hatayı algılamaktan sorumludur. Bölge yük devretmesini 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 Resource Health kullanabilir ve sorunları size bildirmek için Resource Health uyarıları ayarlayabilirsiniz. Ayrıca Azure Service Health kullanarak tüm bölge hataları dahil olmak üzere hizmetin genel durumunu anlayabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

• Etkin istekler: Bölge hatası sırasında etkin istekler bırakılabilir. İstemcileriniz ve cihazlarınızda geçici hataları işlemek için yeterli yeniden deneme mantığı uygulanmalıdır.

• Beklenen veri kaybı: IoT hub'ınız veriler için alanlar arası yedekliliği destekleyen bir bölgeye dağıtıldığında, bölge hatası veri kaybına neden olmamalıdır.

• Beklenen kapatma süresi: IoT hub'ınız hem işlem hem de veri bileşenleri için bölge yedekliliğini destekleyen bir bölgeye dağıtıldığında, bir bölge hatası IoT Hub kaynaklarınızda kapatma süresine neden olmamalıdır.

• Traffic rerouting: IoT hub işlem bileşenleri için bölge yedekliliğini destekleyen bir bölgeye dağıtıldığında, IoT Hub bölgenin kaybını algılar. Ardından, tüm yeni istekler otomatik olarak hizmetin iyi durumdaki kullanılabilirlik alanlarından birinde yeni bir birincil örneğine yönlendirilir.

Bölge kurtarma

Kullanılabilirlik alanı kurtarıldığında, IoT Hub kullanılabilirlik alanındaki örnekleri otomatik olarak geri yükler ve örnekleriniz arasındaki trafiği normal şekilde yeniden yönlendirer.

Bölge hataları için test

IoT Hub bölge hataları için trafik yönlendirme, yük devretme ve yeniden çalışma işlemlerini tam olarak yönettiğinden, kullanılabilirlik alanı hata işlemlerini doğrulamanız veya başka giriş sağlamanız gerekmez.

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

IoT Hub tek bölgeli bir hizmettir. Bölge kullanılamaz duruma gelirse, IoT Hub kaynaklarınız da kullanılamaz.

Ancak kaynaklarınız eşleştirilmiş bir bölgedeyse IoT hub'ınızın verileri eşleştirilmiş bölgeye çoğaltılır.

IoT hub'ınız aşağıdaki senaryolarda eşlenmiş bölgeye geçiş yapabilir:

• Müşteri tarafından başlatılan yük devretme: Bölgenin kesinti yaşayıp yaşamadığından bağımsız olarak, eşleştirilmiş bölgeye manuel yük devretmeyi kendiniz tetikleyebilirsiniz. Planlı yük devretmeler ve tatbikatlar gerçekleştirmek için bu yaklaşımı kullanabilirsiniz.

• Microsoft tarafından başlatılan yük devretme: Bir bölge kaybolursa Microsoft, IoT hub'larının eşleştirilmiş bölgeye yük devretmesini başlatabilir. Ancak, Microsoft'un önemli bir gecikmeden sonra ve mümkün olan en iyi şekilde yük devretmeyi başlatması pek olası değildir. IoT Hub kaynakların yük devretmesi, diğer Azure hizmetlerinin yük devretmesinden farklı bir zamanda gerçekleşebilir. Bu işlem varsayılan bir seçenektir ve sizden müdahale gerektirmez.

Kaynaklar eşleşmemiş bir bölgedeyse, Microsoft yapılandırmayı ve verileri bölgeler arasında çoğaltmaz ve yerleşik bölgeler arası yük devretme bulunmaz. Ancak, ayrı kaynakları birden çok bölgeye dağıtabilirsiniz. Bu senaryoda çoğaltmayı, trafik dağıtımını ve yük devretmeyi yönetmek sizin sorumluluğunuzdadır.

IoT hub'ınız eşleşmemiş bir bölgedeyse veya varsayılan çoğaltma ve yük devretme davranışı gereksinimlerinizi karşılamıyorsa, yük devretmeleri planlamak ve başlatmak için özel çok bölgeli dayanıklılık çözümleri kullanabilirsiniz.

Gereksinimler

• Bölge desteği: Varsayılan çoğaltma ve yük devretme yalnızca eşleştirilmiş bölgelerde desteklenir.
• Tüm IoT Hub katmanları için eşleştirilmiş bölge replikasyon ve yük devretme seçenekleri kullanılabilir.

Değerlendirmeler

Hub'ınızı Azure eşleştirilmiş bölgeleri arasında kalıcı olarak taşımak için müşteri tarafından başlatılan yük devretmeyi kullanmayın. Cihazlar genellikle hub'ın birincil bölgesine yakın bir konumda bulunur. Hub'ınızı ikincil bölgeye taşırsanız, cihazlar ile ikincil konumdaki IoT hub'ı arasındaki işlemler için gecikme süresi artar.

Maliyet

Eşlenmiş bölgelerdeki hub'lar için bölgeler arası veri çoğaltılması veya hizmet sürekliliği için ek maliyet yoktur.

IoT hub'ınız eşleşmemiş bir bölgede bulunuyorsa, olası maliyet bilgileri için dayanıklılık için özel çok bölgeli çözümler konusuna bakın.

Çoğaltmayı yapılandırın ve yük devretmeye hazırlanın

Varsayılan olarak, eşleştirilmiş bir bölgede IoT hub'ı oluşturduğunuzda bölgeler arası veri çoğaltması otomatik olarak yapılandırılır. Bu işlem varsayılan bir seçenektir ve sizden müdahale gerektirmez. Brezilya Güney ve Güneydoğu Asya (Singapur) dışındaki bölgelerde müşteri verileriniz hizmet örneğini dağıttığınız coğrafyanın dışında depolanmaz veya işlenmez.

IoT hub'ınız Brezilya Güney veya Güneydoğu Asya (Singapur) bölgelerindeyse, veri çoğaltmayı devre dışı bırakabilir ve yük devretmeyi durdurabilirsiniz. Daha fazla bilgi için bkz. Olağanüstü durum kurtarmayı (DR) devre dışı bırakma.

IoT hub'ınız eşleştirilmemiş bir bölgede bulunuyorsa, kendi çapraz bölgeler arası çoğaltma ve yük devretme stratejinizi planlamanız gerekir. Daha fazla bilgi için bkz. Dayanıklılık için özel çok bölgeli çözümler.

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

Bu bölümde, bir IoT hub'ı bölgeler arası çoğaltma ve yük devretme için yapılandırıldığında ve birincil bölge çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Bölgeler arasında veri çoğaltma: Veriler eşleştirilmiş bölgeye otomatik olarak çoğaltılır. Çoğaltma zaman uyumsuz olarak gerçekleşir, dolayısıyla geçiş gerçekleşirse bazı veri kayıpları beklenir. Eşleşmemiş bölgelerde IoT hub'ları için bölgeler arasında veri çoğaltması yapılmamaktadır.

• Bölgeler arasında trafik yönlendirme: Normal işlemlerde trafik yalnızca birincil bölgeye akar.

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

Bu bölümde, bir IoT hub'ı bölgeler arası çoğaltma ve yük devretme için yapılandırıldığında ve birincil bölgede bir kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Algılama ve yanıt: Birincil bölgedeki bir kesintiyi algılama ve yanıtlama sorumluluğu farklılık gösterebilir.

  • Müşteri tarafından başlatılan yük devretme: Bölge kaybını tespit etmek ve ne zaman yük devretme yapacağınıza karar vermek sizin sorumluluğunuzdadır. Eşleştirilmiş bölgeler arasında müşteri tarafından başlatılan yük devretme gerçekleştirme hakkında daha fazla bilgi için bkz. IoT hub'ı için el ile yük devretme gerçekleştirme.

    Müşteri tarafından başlatılan yük devretme veya yeniden çalışma işlemlerini ne sıklıkta gerçekleştirebileceğinize ilişkin sınırlar vardır:

    • Kullanıcıların günde iki başarılı yük devretme işlemi ve iki başarılı yeniden çalışma işlemi gerçekleştirmesine izin verilir.

    • Arka arkaya yük devretme veya geri yükleme işlemlerine izin verilmez. Bu işlemler arasında bir saat beklemeniz gerekir.

  • Microsoft tarafından başlatılan yük devretme: Birincil bölge kaybolursa Microsoft yük devretme gerçekleştirmeye karar verebilir. Bu işlem, birincil bölgenin kaybından sonra birkaç saat, hatta bazı senaryolarda daha uzun sürebilir. IoT Hub kaynaklarının yük devretmesi diğer Azure hizmetleriyle aynı anda gerçekleşmeyebilir.

• Etkin istekler: Yük devretme sırasında birincil bölgenin işlemekte olduğu herhangi bir istek muhtemelen kaybolacaktır. Yük devretme tamamlandıktan sonra, istemciler isteklerini yeniden denemelidir.

• Beklenen veri kaybı: Eşleştirilen bölgeler için veriler eşleştirilmiş bölgeye zaman uyumsuz olarak çoğaltılır. Sonuç olarak, geçişten sonra bazı veri kaybı beklenir. Bu işlem hem Microsoft tarafından yönetilen hem de müşteri tarafından yönetilen yük devretmeler için geçerlidir. Aşağıdaki tabloda IoT hub'larının depolandığı her veri türünün kurtarma noktası hedefi (RPO) veya beklenen veri kaybı özetlenmektedir.

  Veri türü	RPO
  Kimlik kayıt defteri	0-5 dakika veri kaybı
  Cihaz ikizi verileri	0-5 dakika veri kaybı
  Buluttan cihaza iletiler 1	0-5 dakika veri kaybı
  Ana 1 ve cihaz görevleri	0-5 dakika veri kaybı
  Cihazdan buluta iletiler	Tüm okunmamış iletiler kaybolur
  Buluttan cihaza geri bildirim iletileri	Tüm okunmamış iletiler kaybolur

  ¹ Buluttan cihaza iletiler ve üst işler, müşteri tarafından başlatılan yük devretme sırasında geri yüklenmez.

• Beklenen kapalı kalma süresi: Bölge yük devretmesi sırasında beklenen kapalı kalma süresi, yük devretme türüne bağlıdır.

  • Müşteri tarafından başlatılan yük devretme: Bölge kaybedildiğinde, kaynağın eşleştirilmiş bölgede çalışır hale gelmesine kadar yaklaşık 10 dakika ila 2 saat süresince bir kesinti bekleyebilirsiniz. Yük devredilmekte olan IoT hub örneğine kayıtlı cihaz sayısı kurtarma süresini etkiler. Yaklaşık 100.000 cihazı barındıran bir hub için kurtarma süresinin yaklaşık 15 dakika olmasını bekleyebilirsiniz.

  • Microsoft tarafından başlatılan yük devretme: Bir bölge kaybedildiğinde, kaynağın eşleştirilmiş bölgede kullanılabilir hale gelmesi için yaklaşık 2 ila 26 saatlik bir kesinti süresi bekleyebilirsiniz.

    Kurtarma süresinin yüksek olması, Microsoft'un söz konusu bölgedeki tüm etkilenen müşteriler adına yük devretme işlemini gerçekleştirmesi gerekmesidir. Kritik sistemlerde, kapalı kalma süresini azaltmak için müşteri tarafından başlatılan yük devretme işlemini kullanmanız gerekir. Ancak, yaklaşık bir gün kapalı kalma süresini sürdürebilen daha az kritik bir IoT çözümü çalıştırırsanız, IoT çözümünüz için genel DR hedeflerini karşılamak için Microsoft tarafından başlatılan seçeneğe bağımlılık yapmak mümkün olabilir.

  • Her iki yük devretme türü için de, yük devretme sonrasında IoT hub örneği için tam nitelikli etki alanı adı aynı kalır; dolayısıyla bağlantı dizesi de aynı kalır. Ancak, temel ip adresi değiştiğinden istemcilerin yük devretmeden sonra IoT hub'ına erişmeden önce Etki Alanı Adı Sistemi (DNS) kayıtlarının güncelleştirilmesini beklemesi gerekir.

    Önemli

    IoT Hub SDK'lar IoT hub IP adresini önbelleğe almaz. SDK'larla birlikte kullanılan kullanıcı kodu, IoT hub'ının IP adresini de önbelleğe almamalıdır.

    Bu faktörler nedeniyle, IoT hub örneğiniz üzerinde gerçekleştirilen çalışma zamanı işlemlerinin yük devretme işleminden sonra tamamen çalışır duruma gelmesi için gereken süre aşağıdaki işlev kullanılarak ifade edilebilir:

    Kurtarma süresi = RTO [Müşteri tarafından başlatılan yük devretme için 10 dakika ile 2 saat veya Microsoft tarafından başlatılan yük devretme için 2-26 saat] + DNS yayma gecikmesi + İstemci uygulamasının önbelleğe alınmış ioT hub IP adreslerini yenilemek için gereken süre

• Traffic rerouting: Yük devretme işlemi sırasında IoT Hub DNS kayıtlarını eşleştirilmiş bölgeye işaret eden şekilde güncelleştirir. Sonraki tüm istekler eşleştirilmiş bölgeye gönderilir.

  IoT hub'ı için yük devretme işlemi tamamlandıktan sonra cihaz ve arka uç uygulamalarından gerçekleştirilen tüm işlemlerin el ile müdahaleye gerek kalmadan çalışmaya devam etmesi beklenir. Bu süreklilik, cihazdan buluta iletilerinizin çalışmaya devam etmesini ve cihaz kayıt defterinin tamamının bozulmamasını sağlar. Olayları Azure Event Grid aracılığıyla yayarsanız, bu Event Grid abonelikleri kullanılabilir olmaya devam ettikçe daha önce yapılandırdığınız abonelikler aracılığıyla kullanılabilir. Özel uç noktalar için başka işleme gerekmez.

Yük devretme sonrası yapılandırma gerekli

IoT hub'ınızın iletilerini nereye yönlendirdiğinize bağlı olarak, yük devretme tamamlandıktan sonra ek adımlar gerçekleştirmeniz gerekebilir.

• Azure Event Hubs: Yük devretme sonrasında IoT hub'ınızın yerleşik olay uç noktasının Event Hubs uyumlu adı ve uç noktası değişir. Event Hubs istemcisinin IoT Hub olaylarıyla ilgili görünürlüğü olmadığından bu değişiklik oluşur.

  Event Hubs istemcisini veya olay işlemcisi ana bilgisayarını kullanarak entegre uç noktadan telemetri iletileri aldığınızda bağlantıyı kurmak için IoT hub'ına ait bağlantı dizesini kullanın. Bu yaklaşım, arka uç uygulamalarınızın yük devretme sonrasında el ile müdahaleye gerek kalmadan çalışmaya devam etmesini sağlar.

  Eğer uygulamanızda Event Hubs uyumlu adı ve uç noktayı doğrudan kullanıyorsanız, işlemlere devam etmek için arızadan kurtarma işleminden sonra yeni Event Hubs uyumlu uç noktayı almanız gerekir. Uç noktayı ve adı almak için Azure portalını veya .NET SDK'sını kullanabilirsiniz:

  • Azure portalı: Event Hubs ile uyumlu uç noktayı ve Event Hubs uyumlu adını almak için portalı kullanma hakkında daha fazla bilgi için bkz. Yerleşik uç noktaya bağlanma.

  • .NET SDK: IoT hub bağlantı dizesini kullanarak Event Hubs uyumlu uç noktayı yeniden elde etmek için örnek kodu kullanın. Bu kod örneği, yeni Event Hubs uç noktasını almak ve bağlantıyı yeniden kurmak için connection string kullanır. Visual Studio yüklemiş olmanız gerekir.

• Azure Functions ve Azure Stream Analytics: Yerleşik olaylar uç noktasına bağlanmak için Azure Functions veya Stream Analytics kullanıyorsanız, önceki madde işareti noktasında açıklanan işlemi izleyerek işlevin veya işin bağlanıldığı Event Hubs uç noktasını güncelleştirmeniz gerekir. Ardından, yük devretme sonrasında tüm olay akışı uzaklıkları geçersiz hale geldiği için yeniden başlatma eylemi gerçekleştirin.

• Azure Storage: Azure Storage'a yönlendirme yaparken önce blobları veya dosyaları listeleyin. Ardından tüm blobların veya dosyaların bölümleme varsayılmadan okunmasını sağlamak için bunları yineleyin. Bölme aralığı, Microsoft tarafından başlatılan yük devretme veya müşteri tarafından başlatılan yük devretme sırasında değişebilir. Azure Depolama Blob'larının listesini almak için List Blobs API'yi veya dosya listesini almak için List Azure Data Lake Storage API'yi kullanabilirsiniz. Daha fazla bilgi için bkz. yönlendirme uç noktası olarak Azure Storage.

Bölge geri kazanımı

Birincil bölgeye geri dönmek için yük devretme işlemini elle ikinci kez tetikleyebilirsiniz. Ne sıklıkta yük devredebileceğinize ilişkin kısıtlamaları unutmamanız önemlidir.

Özgün yük devretme işlemi, özgün birincil bölgedeki uzun süreli bir kesintiden kurtulmak için gerçekleştirildiyse, birincil bölge kesintiden kurtarıldıktan sonra bölgeye geri yükleme yapın.

Bölge hataları testi

Bölge kesintisi sırasında bir hatanın benzetimini yapmak için IoT hub'ınızda manuel bir yük devretme işlemi başlatabilirsiniz. Ancak bölgesel yük devretme hem kapalı kalma süresine hem de veri kaybına neden olduğundan, yalnızca üretim dışı ortamlarda yük devretme testi gerçekleştirmeniz gerekir. Daha fazla bilgi için bkz. Bölge hatası sırasında davranış. Planlı yük devretme seçeneğini düzenli aralıklarla başlatmak için bir test IoT Hub örneği ayarlamayı göz önünde bulundurun. Düzenli testler, gerçek bir olağanüstü durum oluştuğunda uçtan uca çözümlerinizi etkili bir şekilde geri yükleme ve çalıştırma yeteneğinizde güven oluşturmanıza yardımcı olabilir.

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

IoT Hub bölgeler arası yük devretme özellikleri aşağıdaki senaryolar için uygun değildir:

• IoT hub'ınız eşlenmemiş bir bölgede.

• İşletmenizin çalışma süresi hedefleri, yerleşik yük devretme seçeneklerinin sağladığı kurtarma süresi veya veri kaybıyla karşılanmamaktadır.

• Birincil bölgenizin çifti olmayan bir bölgeye yük devretmelisiniz.

Her bir cihaza göre uyarlanmış bölgeler arası bir yük devretme çözümü tasarlayabilirsiniz. IoT çözümlerinde dağıtım topolojilerinin tam olarak ele alınması bu makalenin kapsamı dışındadır, ancak çok bölgeli bir dağıtım modelini göz önünde bulundurabilirsiniz. Bu modelde birincil IoT hub'ınız ve çözüm arka ucunuz öncelikli olarak tek bir Azure bölgede çalışır. İkincil IoT hub ve arka uç başka bir Azure bölgede dağıtılır. Birincil bölgedeki IoT hub'ında bir kesinti yaşanırsa veya cihazdan birincil bölgeye ağ bağlantısı kesilirse, cihazlar ikincil bir hizmet uç noktası kullanır.

• Beklenen kapalı kalma süresi: Bu yaklaşımın kapalı kalma süresi bir dakikadan azdır ancak uygulanması karmaşık olabilir.

• Beklenen veri kaybı: Veri kaybı miktarı, kullandığınız belirli veri depolarına ve bunlar arasında coğrafi çoğaltmayı yapılandırma yönteminize bağlıdır.

• Masraf: Bu yaklaşım için en az bir ek IoT hub'ı sağlamanız gerekir ve bu da genel maliyetinizi artırır.

Yüksek düzeyde, IoT Hub ile bölgesel bir yük devretme modeli uygulamak için aşağıdaki önlemleri almanız gerekir:

• İkincil bir IoT hub'ı ve cihaz yönlendirme mantığı: Birincil bölgenizdeki hizmet kesintiye uğradıysa cihazların ikincil bölgenize bağlanmaya başlaması gerekir. Çoğu hizmetin durum farkındalığına sahip yapısı nedeniyle, çözüm yöneticileri genellikle bölgeler arası yük devretme işlemini manuel olarak başlatır. İşlem üzerinde denetim sahibi olurken yeni uç noktayı cihazlara iletmenin en iyi yolu, geçerli etkin uç nokta için düzenli olarak bir concierge hizmetini denetlemelerini sağlamaktır. Concierge hizmeti, Azure Traffic Manager gibi DNS yeniden yönlendirme teknikleri kullanılarak çoğaltılan ve erişilebilir durumda tutulan bir web uygulaması olabilir.

  Uyarı

  Traffic Manager'ın IoT Hub için yerleşik desteği yoktur. Her IoT hub'ı için özel Traffic Manager uç noktalarını yapılandırabilirsiniz. Traffic Manager uç noktasının sistem durumu araştırmasını IoT hub'ını kullanacak şekilde yapılandırın.

• Kimlik kayıt defteri çoğaltması: İkincil IoT hub'ı kullanılabilir olması için çözüme bağlanabilen tüm cihaz kimliklerini içermelidir. Çözüm, cihaz kimliklerinin coğrafi olarak çoğaltılmış yedeklemelerini tutmalı ve cihazlar için etkin uç nokta değiştirmeden önce bunları ikincil IoT hub'ına yüklemelidir. IoT Hub cihaz kimliği dışarı aktarma işlevi bu bağlamda yararlıdır. Daha fazla bilgi için bkz IoT hub'ınızdaki kimlik kayıt defterini anlama.

• Birleştirme mantığı: Birincil bölge yeniden kullanılabilir duruma geldiğinde, ikincil bölgede oluşturulan tüm durum ve veriler birincil bölgeye geri geçirilmelidir. Bu durum ve veriler çoğunlukla birincil IoT hub'ı ve birincil bölgedeki diğer uygulamaya özgü depolarla birleştirilmesi gereken cihaz kimlikleri ve uygulama meta verileriyle ilgilidir.

  Bu adımı basitleştirmek için idempotent (etkisiz aynı işlemi tekrarlama) işlemleri kullanın. Etkili işlemler, olayların nihai tutarlı dağılımından ve yinelenenlerden veya olayların sıra dışı tesliminden kaynaklanan yan etkileri en aza indirir. Ayrıca, uygulama mantığı olası tutarsızlıkları veya biraz güncel olmayan durumu tolere etmek için tasarlanmalıdır. Bu senaryo, sistemin RPO'lara göre iyileşmesi için gereken ek süre nedeniyle oluşabilir.

Yedekleme ve geri yükleme

IoT Hub hizmeti, bir IoT hub tüm kimlik kayıt defterini dışarı aktarmanızı sağlayan toplu dışarı aktarma işlemlerini etkinleştirir. Bu veriler paylaşılan erişim imzası kullanılarak bir Azure Storage blob kapsayıcısına aktarılır. Bu yöntem, denetlediğiniz bir blob kapsayıcısında cihaz bilgilerinizin güvenilir yedeklerini oluşturmanıza olanak tanır. Daha fazla bilgi için bkz. IoT Hub cihaz kimliklerini toplu olarak içeri aktarma ve dışarı aktarma.

IoT hub'ının yapılandırmasının yedeğini oluşturmak için mevcut bir IoT hub'ının Azure Resource Manager şablonunu (ARM şablonu) da dışarı aktarabilirsiniz. Daha fazla bilgi için bkz. ARM şablonu kullanarak IoT hub'larını el ile geçirme.

Çoğu çözüm için yalnızca yedeklemelere güvenmemeniz gerekir. Bunun yerine, dayanıklılık gereksinimlerinizi desteklemek için bu kılavuzda açıklanan diğer özellikleri kullanın. Ancak yedeklemeler, diğer yaklaşımların koruma altına almayan bazı risklere karşı koruma sağlar. Daha fazla bilgi için bkz. Yedeklilik, çoğaltma ve yedekleme nedir?

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
• IoT çözümü ölçeklenebilirliği, yüksek kullanılabilirlik ve DR