IoT Hub yüksek kullanılabilirlik ve olağanüstü durum kurtarma

Yeni bir IoT çözümü uygulamaya yönelik ilk adım olarak, mimarlar, geliştiriciler ve işletme sahipleri, kendi geliştirtikleri çözümler için çalışma süresi hedeflerini tanımlamalı. Bu hedefler öncelikle her senaryo için belirli iş hedeflerine göre tanımlanabilir. Bu bağlamda, Azure İş Sürekliliği Teknik Kılavuzu makalesinde, iş sürekliliği ve olağanüstü durum kurtarma hakkında düşünmeniz için genel bir çerçeve açıklanmıştır. Azure uygulamaları için olağanüstü durum kurtarma ve yüksek kullanılabilirlik makalesi, Yüksek Kullanılabilirlik (HA) ve Olağanüstü Durum Kurtarma (DR) elde etmek için Azure uygulamalarına yönelik stratejiler hakkında mimari rehberlik sağlar.

Bu makalede, özel olarak IoT Hub hizmeti tarafından sunulan HA ve DR özellikleri ele IoT Hub sunulmaktadır. Bu makalede ele alınacak geniş alanlar:

• Bölge içi HA
• Çapraz bölge DR
• Bölgeler arası HA'ya ulaşma

IoT çözümleriniz için tanımladığınız çalışma süresi hedeflerine bağlı olarak, aşağıda açıklanan seçeneklerden hangilerinin iş hedeflerinize en uygun olduğunu belirlemeniz gerekir. Bu HA/DR alternatiflerini IoT çözümünüzle birleştirerek aşağıdakiler arasındaki takasların dikkatli bir şekilde değerlendirilmesi gerekir:

• Gereken güvenlik düzeyi
• Uygulama ve bakım karmaşıklığı
• COGS etkisi

Bölge içi HA

IoT Hub hizmeti, hizmetin neredeyse tüm katmanlarında yedeklilikleri uygulayarak bölge içi HA sağlar. IoT Hub hizmeti tarafından yayımlanan SLA, bu yedekliliklerin kullanımıyla elde edilir. Bir IoT çözümünün geliştiricilerinin bu HA özelliklerinden yararlanmak için ek bir çalışma gerekmez. Bu IoT Hub makul düzeyde yüksek çalışma süresi garantisi sunuyor olsa da, herhangi bir dağıtılmış bilgi işlem platformunda olduğu gibi geçici hatalar yine de beklenmiyor olabilir. Çözümlerinizi şirket içi bir çözümden buluta geçiş yapmaya yeni başlıyorsanız, "hatalar arasındaki ortalama süre" iyileştirmeden "kurtarma için ortalama süreye" geçiş yapmaya odaklanmanız gerekir. Başka bir deyişle, geçici hatalar bulutla birlikte çalışırken normal kabul edilir. Geçici hatalarla başa baş etmek için bulut uygulamasıyla etkileşimde bulunan bileşenlerde uygun yeniden deneme ilkeleri yerleşik olmalıdır.

Kullanılabilirlik Alanları

IoT Hub için %99,9 Hizmet Düzeyi Sözleşmesi SLA'yı okuyabilir. Azure SLA şartları, Azure’un tamamının kullanılabilirlik garantisini açıklamaktadır.

IoT Hub, için Kullanılabilirlik Alanları. Kullanılabilirlik Alanı, uygulamalarınızı ve verilerinizi veri merkezi hatalarından koruyan bir yüksek kullanılabilirlik teklifidir. Kullanılabilirlik Alanı desteğine sahip bir bölge, o bölgeyi destekleyen üç bölgeden oluşur. Her bölge bağımsız güç, soğutma ve ağ ile benzersiz bir fiziksel konumda bir veya daha fazla veri merkezi sağlar. Bu, bölge içinde çoğaltma ve yedeklilik sağlar. Aşağıdaki Azure bölgelerinde IoT Hub yeni kaynak kaynakları için IoT Hub Kullanılabilirlik Alanı desteği otomatik olarak etkinleştirilir:

• Doğu Avustralya
• Güney Brezilya
• Orta Kanada
• Central US
• Orta Fransa
• Batı ABD 2
• Doğu Japonya
• Kuzey Avrupa
• Güneydoğu Asya
• Güney Birleşik Krallık

Çapraz bölge DR

Bir veri merkezinde güç kesintilerinden veya fiziksel varlıklarla ilgili diğer hatalardan dolayı uzun kesintiler yaşanan bazı nadir durumlar olabilir. Bu tür olaylar nadirdir ve bu süre boyunca yukarıda açıklanan bölge içi HA özelliği her zaman yardımcı olmaz. IoT Hub, bu tür genişletilmiş kesintilerden kurtarmak için birden çok çözüm sağlar.

Böyle bir durumda müşterilere kullanılabilen kurtarma seçenekleri, Microsoft tarafından başlatılan yük devretme ve el ile yük devretmedir. İkisi arasındaki temel fark, Microsoft'un eskisini başlatması ve kullanıcının ikincisini başlatmasıdır. Ayrıca el ile yük devretme, Microsoft tarafından başlatılan yük devretme seçeneğine kıyasla daha düşük bir kurtarma süresi hedefi (RTO) sağlar. Her seçenekle birlikte sunulan belirli RO'lar aşağıdaki bölümlerde ele alınmıştır. Bir IoT hub'ını birincil bölgesinden yük devretme gerçekleştirmek için bu seçeneklerden biri yerine geldiğinde, hub ilgili Azure coğrafi olarak eşleştirilmiş bölgesinde tamamen işlevsel hale gelir.

Bu yük devretme seçeneklerinin her ikisi de aşağıdaki kurtarma noktası hedeflerini (RPOs) sunar:

¹ Buluttan cihaza iletiler ve üst işler, el ile yük devretmenin bir parçası olarak kurtarılamaz.

IoT hub'ının yük devretme işlemi tamamlandıktan sonra, cihazdan ve arka uç uygulamalarından gelen tüm işlemlerin el ile müdahale gerektirmeden çalışmaya devam ettiği beklenir. Bu, cihazdan buluta iletilerinizin çalışmaya devam edeceğini ve cihaz kayıt defterinin tamamının bozulmamış olduğu anlamına gelir. Bu abonelikler Event Grid veya daha önce yapılandırılan abonelikler aracılığıyla Event Grid olaylar kullanılabilir. Özel uç noktalar için ek işleme gerekmez.

Microsoft tarafından başlatılan yük devretme

Microsoft tarafından başlatılan yük devretme, nadir durumlarda Microsoft tarafından etkilenen bir bölgeden ilgili coğrafi olarak eşleştirilmiş bölgeye tüm IoT hub'ların yük devretmesi için lanır. Bu işlem varsayılan bir seçenektir (kullanıcıların geri almalarının hiçbir yolu yoktur) ve kullanıcıdan müdahaleye gerek yoktur. Microsoft, bu seçeneğin ne zaman belirlenecek olduğunu belirleme hakkını hakkıyla karşılar. Bu mekanizma, kullanıcının hub'ının üzerine yüklenmeden önce kullanıcı onayına gerek yok. Microsoft tarafından başlatılan yük devretme, 2-26 saatlik bir kurtarma süresi hedefine (RTO) sahip olur.

Büyük RTO' nun nedeni, Microsoft'un yük devretme işlemini ilgili bölgedeki tüm etkilenen müşteriler adına gerçekleştirmesi gerekir. Yaklaşık bir gün kapalı kalma süresine neden olan daha az kritik bir IoT çözümü çalıştırıyorsanız, IoT çözümünüz için genel olağanüstü durum kurtarma hedeflerini karşılamak için bu seçen bağımlı hale gelirsiniz. Bu işlem tetiklendiğinde çalışma zamanı işlemlerinin tam olarak çalışır duruma dönüş süresi "Kurtarma süresi" bölümünde açıklanmıştır.

El ile yük devretme

İş çalışma süresi hedefleriniz Microsoft tarafından başlatılan yük devretmenin sağladığı RTO'dan memnun değilseniz, yük devretme işlemini kendiniz tetiklemek için el ile yük devretmeyi kullanmayı göz önünde bulundurabilirsiniz. Bu seçeneği kullanan RTO, 10 dakika ile birkaç saat arasında olabilir. RTO şu anda, başarısız olan IoT hub örneğine kayıtlı cihaz sayısının bir işlevidir. Yaklaşık 100.000 cihaz barındıran bir hub için RTO'nun 15 dakikalık bir topparkta olmasını bebilirsiniz. Bu işlem tetiklendiğinde çalışma zamanı işlemlerinin tam olarak çalışır duruma dönüş süresi "Kurtarma süresi" bölümünde açıklanmıştır.

Birincil bölgede kapalı kalma süresi yaşanıp yaşanmamaysa da el ile yük devretme seçeneği her zaman kullanılabilir. Bu nedenle, planlı yük devretme gerçekleştirmek için bu seçenek potansiyel olarak kullanılabilir. Planlı yük devretmelerin örnek kullanımlarından biri, düzenli aralıklarla yük devretme tatbikatları gerçekleştirmektir. Ancak planlı yük devretme işlemi, bu seçenek için RTO tarafından tanımlanan süre boyunca hub için kapalı kalma süresine neden olur ve ayrıca yukarıdaki RPO tablosu tarafından tanımlanan veri kaybıyla sonuç verir. Gerçek bir olağanüstü durumla karşı karşı uç çözümlerinizi çalıştırabilme becerinize güven kazanmak için düzenli aralıklarla planlı yük devretme seçeneğini kullanmak için bir test IoT hub örneği ayarlamayı düşünebilirsiniz.

El ile yük devretme, 18 Mayıs 2017'den sonra oluşturulan IoT hub'ları için ek ücret ödemeden kullanılabilir

Adım adım yönergeler için bkz. Öğretici: IoT hub'ı için el ile yük devretme gerçekleştirme

El ile yük devretme ve Olay Hub'ı

Daha önce Dikkat bölümünde belirtildiği gibi, olay hub'ı ile uyumlu adı ve uç noktası IoT Hub el ile yük devretmeden sonra yerleşik Olaylar uç noktası değişir. Bunun nedeni, Olay Hub'ı istemcisinin olaylarda IoT Hub olmasıdır. Aynı durum İşlevler ve İşlevler gibi diğer bulut tabanlı istemciler için de Azure Stream Analytics. Uç noktayı ve adı almak için aşağıdaki Azure portal kullanabilir veya dahil edilen bir örnekten faydalanebilirsiniz.

Portalı kullanma

Portalı kullanarak Olay Hub'ı ile uyumlu uç noktayı ve Olay Hub'ı ile uyumlu adı alma hakkında daha fazla bilgi için bkz. Yerleşik uç noktadan okuma.

Dahil edilen örneği kullanma

Event Hub ile IoT Hub uç noktayı yeniden almak üzere IoT Hub bağlantı dizesini kullanarak EventHub ile uyumlu uç noktayı yeniden kapsülleme hakkında bilgi içeren bir örnek https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs kullanın. Kod örneği, yeni Olay Hub'ı uç noktasını almak ve bağlantıyı yeniden kurmak için bağlantı dizesini kullanır. Yüklü bir Visual Studio gerekir.

Test tatbikatlarını çalıştırma

Test tatbikatları, üretim ortamlarınız için kullanılan IoT hub'larında gerçekleştirilmamalı.

IoT hub'larını farklı bir bölgeye geçirmek için el ile yük devretmeyi kullanma

El ile yük devretme, hub'ını coğrafi olarak eşleştirilmiş Azure bölgeleri arasında kalıcı olarak geçirmek için bir mekanizma olarak kullanılmamalı. Bunu yapmak, eski birincil bölgede yer alan cihazlardan IoT hub'larında gerçekleştirilen işlemlerin gecikme süresini artırır.

Yeniden çalışma

Yük devretme eylemi başka bir zaman tetiklendiğinde eski birincil bölgeye geri dönerek yeniden çalışma elde edilebilir. Özgün yük devretme işlemi, özgün birincil bölgedeki genişletilmiş bir kesintiden kurtarmak için gerçekleştirildi ise, bu konum kesintiden kurtarıldıktan sonra hub'ın özgün konuma yeniden çalışmanız önerilir.

Kurtarma süresi

IoT hub örneğinin FQDN'i (ve dolayısıyla bağlantı dizesi) yük devretme sonrası aynı kalırken, temel ALıNAN IP adresi değişir. Bu nedenle, yük devretme işlemi tetiklendiğinde IoT hub örneğiniz üzerinde gerçekleştirilen çalışma zamanı işlemlerinin toplam çalışma zamanı aşağıdaki işlev kullanılarak ifade olabilir.

Kurtarma süresi = RTO [el ile yük devretme için 10 dk - 2 saat | Microsoft tarafından başlatılan yük devretme için 2 - 26 saat] + DNS yayma gecikmesi + Önbelleğe alınmış tüm IP adreslerini yenilemek için istemci uygulama tarafından geçen IoT Hub saat.

Bölgeler arası HA elde etmek

İş çalışma süresi hedefleriniz Microsoft tarafından başlatılan yük devretme veya el ile yük devretme seçeneklerinin sağ attığı RTO'dan memnun kalmasa, cihaz başına otomatik bölgeler arası yük devretme mekanizmasını uygulamayı göz önünde bulundurabilirsiniz. IoT çözümlerde dağıtım topolojilerinin eksiksiz bir şekilde denesi bu makalenin kapsamı dışındadır. Makalede yüksek kullanılabilirlik ve olağanüstü durum kurtarma amacıyla bölgesel yük devretme dağıtım modeli ele edilmektedir.

Bölgesel yük devretme modelinde çözüm arka uç öncelikli olarak bir veri merkezi konumda çalışır. İkincil bir IoT hub'ı ve arka uç başka bir veri merkezi konuma dağıtılır. Birincil bölgedeki IoT hub'ı kesintiye uğrarsa veya cihazdan birincil bölgeye ağ bağlantısı kesilirse, cihazlar ikincil bir hizmet uç noktası kullanır. Tek bir bölge içinde kalmak yerine bölgeler arası yük devretme modeli kullanarak çözüm kullanılabilirliğini geliştirin.

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

• İkincil bir IoT hub'ı ve cihaz yönlendirme mantığı: Birincil bölgeniz hizmet kesintiye neden olursa cihazların ikincil bölgenize bağlanmaya başlaması gerekir. Söz konusu hizmetlerin çoğunda durum bilgisi olduğu için çözüm yöneticilerinin bölgeler arası yük devretme işlemini tetiklemesi yaygın bir durumdur. Yeni uç noktayı cihazlara iletirken sürecin kontrolünü de sürdürmenin en iyi yolu, geçerli etkin uç nokta için düzenli olarak concierge hizmetini denetlemelerini sağlamaktır. Concierge hizmeti, DNS yeniden yönlendirme teknikleri kullanılarak çoğaltılan ve ulaşılabilir durumda tutulan bir web uygulaması olabilir (örneğin, Azure Traffic Manager).

  Not

  IoT hub hizmeti, IoT hub'larında desteklenen bir Azure Traffic Manager. Önerilen concierge hizmetini uç nokta durum yoklama API'sini uygulayarak Azure Traffic Manager ile tümleştirin.

• Kimlik kayıt defteri çoğaltması: Kullanılabilir olması için ikincil IoT hub'ı çözüme bağlanabilir tüm cihaz kimliklerini içermesi gerekir. Çözüm, cihaz kimliklerinin coğrafi olarak çoğaltılmış yedeklemelerini tutmalı ve cihazlar için etkin uç noktayı değiştirmeden önce bunları ikincil IoT hub'larına yüklemeli. Bu bağlamda, IoT Hub cihaz kimliği dışarı aktarma işlevi yararlıdır. Daha fazla bilgi için bkz. IoT Hub geliştirici kılavuzu - kimlik kayıt defteri.

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

Bu adımı basitleştirmek için bire bir etkili işlemler kullan gerekir. Bire bir etkili işlemler, olayların nihai tutarlı dağıtımından ve yinelenen veya sırasız olay teslimlerinden gelen yan etkileri en aza indirger. Ayrıca, uygulama mantığı olası tutarsızlıkları veya biraz güncel olmayan durumu tolere etmek için tasarlanmalı. Bu durum, sistemin kurtarma noktası hedeflerine (RPO) göre iyileştirmesi için gereken ek süre nedeniyle oluşabilir.

Doğru HA/DR seçeneğini belirleyin

Bu makalede sunulan ve çözümünüz için uygun olan seçeneği seçmek için başvuru çerçevesi olarak kullanılan HA/DR seçeneklerinin özeti burada velanmıştır.

Sonraki adımlar

• Azure IoT Hub nedir?
• Kullanmaya başlayın Hub'ları ile çalışma (Hızlı Başlangıç)
• Öğretici: IoT hub'ı için el ile yük devretme gerçekleştirme