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 sağlar. 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.

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

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

• IoT hub'ınızı hem işlem hem de veri bileşenleri için bölge yedekliliğini destekleyen bir bölgeye dağıtın. Daha fazla bilgi için bkz . Gereksinimler.
• IoT Hub ile iletişim kuran tüm cihazlarda ve uygulamalarda uygun retry desenleri uygulayın.
• Geçici hataları ve hizmet yük devretmelerini işlemek için cihazınızın yeniden bağlantı mantığını tasarlar. Daha fazla bilgi için bkz. Dayanıklı uygulamalar oluşturmak için cihaz yeniden bağlantılarını yönetme.
• Daha büyük ölçekli dağıtımlar için şu önerileri izleyin:
  • IoT Hub'a yeniden bağlanırken cihazlarda ve uygulamalarda üstel gerileme ve rastgele tabanlı yeniden deneme desenleri uygulayın. Bu, hizmet tarafı yük devretmeleri veya ağ kesintileri sırasında yeniden bağlanma fırtınalarını önlemeye yardımcı olur.
  • IoT Hub hizmet kotalarını ve sınırlarını anlayın ve çözümünüzün bunları nasıl işlediğini planlayın. Hizmet tarafı azaltma davranışı, bağlantı sınırları ve aktarım hızı birimiyle ilgili önemli noktaları erken göz önünde bulundurarak, öngörülebilir ölçeklenebilirliği sağlamak ve filonuz büyüdükçe mimari yeniden düzenlemeden kaçınmak için çözümünüzü tasarlayabilirsiniz. Ek yönergeler için bkz. IoT Hub ölçeklendirme ve kotalar.
  • Azure IoT Hub Cihaz Sağlama Hizmeti (DPS) ile birlikte Azure IoT Hub kullanın. DPS, bir veya daha fazla hub'da güvenli, sıfır dokunmayla ekleme ve cihaz ayırma olanağı sağlar. Büyük bir filoya sahip olmayı tahmin etmeseniz bile, en baştan DPS'yi birleştirerek, hizmet üretim ve ekleme iş akışlarınız daha sonra üretici yazılımı veya altyapı değişikliği gerektirmeden ölçeklendirilebilir. Daha fazla bilgi için bkz. DPS ile IoT çözümlerini uygun ölçekte dağıtma.
  • İyileştirilmiş kullanılabilirlik ve bölge dayanıklılığı için cihazları birden çok IoT Hub örneğine dağıtmak için DPS ayırma ilkelerini kullanmayı göz önünde bulundurun. Bu yaklaşım, alım kapasitesinin yatay olarak ölçeklenmesine olanak tanır ve cihaz yeniden sağlama gerektirmeden gelecekteki filo büyümesini destekler.

Güvenilirlik mimarisine genel bakış

IoT hub'ı oluşturduğunuzda, cihazlarınızı yönetmek ve cihazlarınızla iletişim kurmak için gereken tüm işlevleri içeren bir IoT hub kaynağı dağıtırsınız. IoT hub'ının başlıca bileşenleri şunlardır:

• Cihaz kimliği kayıt defteri: IoT hub'ınıza bağlanabilen cihazlar ve modüller hakkında bilgi depolayan bir veritabanı. Her cihazın bağlanabilmesi için önce kimlik kayıt defterinde bir girişi olmalıdır. Daha fazla bilgi için bkz IoT hub'ınızdaki kimlik kayıt defterini anlama.

• Messaging components: IoT Hub cihazlardan buluta telemetri, buluttan cihaza komutlar ve doğrudan yöntem çağrıları dahil olmak üzere cihazlar ve arka uç uygulamalarınız arasında çift yönlü mesajlaşmayı işler.

• Cihaz ikizleri: Meta veriler, yapılandırmalar ve koşullar dahil olmak üzere cihaz durumu bilgilerini depolayan JSON belgeleri. Cihazlar ve arka uç uygulamaları cihaz ikizlerini okuyabilir ve güncelleştirebilir.

Güvenilirlik amacıyla, IoT Hub bileşenler iki gruba ayrılır:

• İşlem bileşenleri: Cihaz bağlantılarını yönetin, isteklerin kimliğini doğrular, iletileri yönlendirir ve doğrudan yöntem çağrılarını işler. Bu bileşenler, IoT Hub istekleri kabul edip işleyebilmesini belirler.

• Veri bileşenleri: Cihaz kimliği kayıt defterini, cihaz ikizlerini ve cihazdan buluta iletileri depolayın. Bu bileşenler veri kullanılabilirliğini ve dayanıklılığını belirler.

Bu ayrım önemlidir çünkü farklı bölgeler bu bileşenler için farklı yedeklilik türlerini destekler .

Diğer hizmetlerle tümleştirme

IoT Hub'u Azure Cihaz Kayıt Defteri ile entegre edebilirsiniz. Bu yaklaşımı kullanıyorsanız, her iki hizmetteki güvenilirliği anlamak için Azure Cihaz Kayıt Defteri'nde Güvenilirlik ifadesini gözden geçirin.

Cihaz sağlama için IoT Hub Cihaz Sağlama Hizmeti (DPS) kullanıyorsanız çözümünüzün güvenilirliği de DPS'ye bağlıdır. Daha fazla bilgi için bkz. IoT Hub Cihaz Sağlama Hizmeti yüksek kullanılabilirlik ve olağanüstü durum kurtarma.

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.

Yüksek ölçekli dağıtımlar için rastgele yeniden deneme jiteri kullanmak iyi bir yöntemdir. Titreşim, yükü hub bölümleri arasında dağıtmaya yardımcı olur ve büyük ölçekli yeniden bağlantı olayları sırasında kısıtlama olasılığını azaltır.

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.

Bir bölge bu tür alanlar arası yedekliliği desteklediğinde, Cihaz Kimliği Kayıt Defteri de dahil olmak üzere kritik hizmet verileri bölge içindeki kullanılabilirlik alanları arasında zaman uyumlu olarak çoğaltılır. Sonuç olarak, tek bölgeli bir hata durumunda veri kaybı beklenmez ve hizmet cihaz bağlantısını ve ileti trafiğini otomatik olarak iyi durumdaki bir bölgeye yeniden yönlendirir. Yük devretme olayı sırasında uçuş içi istekler geçici olarak etkilenebilir, ancak hizmet sürekliliği korunur ve cihaz yeniden deneme mantığı genellikle kurtarmayı 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.

• Notification: Microsoft, bölge kapatıldığında sizi otomatik olarak bilgilendirmez. Ancak, tek bir kaynağın durumunu izlemek için Azure Kaynak Durumu kullanabilir ve sorunları size bildirmek için Kaynak Durumu uyarıları ayarlayabilirsiniz. Ayrıca Azure Hizmet Durumu 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 kapalı kalma süresi: IoT hub, hem işlem hem de veri bileşenleri için bölge yedekliliğini destekleyen bir bölgeye dağıtıldığında, bölge hatası IoT Hub kaynaklarınızın kesintiye uğramasına 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. IoT Hub, olağanüstü durum kurtarma amacıyla eşleştirilmiş bir Azure bölgesine zaman uyumsuz veri çoğaltmayı desteklese de, cihaz bağlantısı için bölgeler arası yerleşik bir yük devretme mekanizması yoktur.

Kaynaklar eşleşmemiş bir bölgedeyse, Microsoft yapılandırma ve verileri bölgeler arasında çoğaltmaz ve yerleşik bir bölgeler arası yük devretme bulunmamaktadır. 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 istenmeyen bir bölgedeyse veya varsayılan çoğaltma ve yük devretme davranışı gereksinimlerinizi karşılamıyorsa, aşağıdaki adımlar da dahil olmak üzere özel bir çok bölgeli yük devretme stratejisi tasarlar ve uygularsınız:

• Farklı bir Azure bölgesinde ikincil IoT Hub sağlama.
• Gerektiğinde cihazları alternatif bölgeye yönlendirmek için bir uç nokta yeniden yönlendirme mekanizması uygulama. Örneğin, her cihazı her iki hub'da önceden sağlayabilir ve gerektiğinde hub'lar arasında geçiş yapabilecekleri şekilde cihazlardaki her iki bağlantı dizesini de yapılandırabilirsiniz.

eşleştirilmiş bölgeye Microsoft yönetilen yük devretme

Kaynaklarınız eşleştirilmiş bir bölgedeyse IoT hub'ınızın verileri eşleştirilmiş bölgeye çoğaltılır. Bu yaklaşım olağanüstü durum kurtarmayı desteklemeye yöneliktir. IoT hub'ınızın birincil bölgesinde bölge hatası varsa, eşleştirilmiş bölgede cihaz bağlantısının devam etmesi için herhangi bir işlem yapmanız gerekmez.

Yük devretme türleri

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 eşleştirilmiş bölgeye IoT hub'larının yük devretmesini başlatabilir. Ancak, Microsoft'un önemli bir gecikmeden sonra ve en iyi çaba esasıyla yük devretmeyi başlatması 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.

Gereksinimler

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

Değerlendirmeler

Azure eşleştirilmiş bölgeleri arasında hub'ınızı 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: Cihaz Kimliği Kayıt Defteri de dahil olmak üzere 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: Microsoft birincil bölge kaybolursa 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 devretme işlemi 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: Bölge kaybedildiğinden kaynağın eşleştirilmiş bölgede kullanılabilir olduğu zamanlara kadar yaklaşık 2 ila 26 saatlik kapalı kalma süresi bekleyebilirsiniz.

    Kurtarma süresinin yüksek olması, Microsoft bu bölgedeki etkilenen tüm müşteriler adına yük devretme işlemini gerçekleştirmesi gerektiğidir. 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ün 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ğinin tam etki alanı adı aynı kalır, yani 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 başlatılan yük devretme için 2-26 saat] + DNS yayma gecikmesi + İstemci uygulamasının önbelleğe alınmış herhangi bir IoT hub IP adresini yenilemek için aldığı 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. Azure Event Grid aracılığıyla olaylar gönderirseniz, bu Event Grid abonelikleri kullanılabilir kaldığı sürece, daha önce yapılandırdığınız aynı abonelikler aracılığıyla tüketilebilir. Ö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 yerleşik uç noktayı kullanarak telemetri iletileri aldığınızda, bağlantıyı kurmak için IoT hub'ına ait "bağlantı dizesi"i 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: Event Hubs uyumlu uç noktayı yeniden ele almak için IoT Hub bağlantı dizgesini kullanarak örnek kod kullanın. Bu kod örneği, yeni Event Hubs uç noktasını almak ve bağlantıyı yeniden kurmak için bağlantı dizesi kullanır. Visual Studio yüklemiş olmanız gerekir.

• Azure İşlevleri ve Azure Stream Analytics: Yerleşik olaylar uç noktasına bağlanmak için Azure İşlevleri 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 Depolama: Azure Depolama'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ölüm aralığı, Microsoft tarafından başlatılan bir yük devretme veya müşteri tarafından başlatılan yük devretme sırasında değişebilir. List Blobs API ile blob listesini veya List Azure Data Lake Storage API ile dosya listesini listeleyebilirsiniz. Daha fazla bilgi için bkz. yönlendirme uç noktası olarak Azure Depolama.

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ırlar. 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 Depolama 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 bakımına dayanıklılık

Microsoft düzenli olarak hizmet güncelleştirmelerini uygular ve başka bakımlar yapar. 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 SLAs.

İlgili içerik

• IoT çözümü ölçeklenebilirliği, yüksek kullanılabilirlik ve DR
• Azure Cihaz Kayıt Defteri'nde güvenilirlik
• Azure'da Güvenilirlik