IoT Hub yüksek kullanılabilirlik ve olağanüstü durum kurtarma
Dayanıklı bir IoT çözümü uygulamaya yönelik ilk adım olarak, mimarlar, geliştiriciler ve işletme sahipleri, geliştirdikleri çözümler için çalışma süresi hedeflerini tanımlamalıdır. Bu hedefler öncelikle her senaryo için belirli iş hedeflerine göre tanımlanabilir. Bu bağlamda Azure İş Sürekliliği Teknik Kılavuzu makalesi, iş sürekliliği ve olağanüstü durum kurtarma hakkında düşünmenize yardımcı olacak genel bir çerçeveyi açıklar. Azure uygulamaları için olağanüstü durum kurtarma ve yüksek kullanılabilirlik makalesi, Azure uygulamalarının Yüksek Kullanılabilirlik (HA) ve Olağanüstü Durum Kurtarma (DR) elde etme stratejilerine ilişkin mimari kılavuzu sağlar.
Bu makalede, IoT Hub hizmeti tarafından özel olarak sunulan HA ve DR özellikleri ele alınmaktadır. Bu makalede ele alınan geniş alanlar şunlardır:
- Bölge içi HA
- Bölgeler arası DR
- Bölgeler arası HA elde etme
IoT çözümleriniz için tanımladığınız çalışma süresi hedeflerine bağlı olarak, bu makalede açıklanan seçeneklerden hangisinin iş hedeflerinize en uygun olduğunu belirlemeniz gerekir. Bu HA/DR alternatiflerinden herhangi birini IoT çözümünüzle birleştirerek aşağıdakiler arasındaki dengelerin dikkatli bir şekilde değerlendirilmesi gerekir:
- gereken dayanıklılık düzeyi
- Uygulama ve bakım karmaşıklığı
- COGS etkisi
Bölge içi HA
IoT Hub hizmeti, hizmetin neredeyse tüm katmanlarında yedeklilik uygulayarak bölge içi HA sağlar. IoT Hub hizmeti tarafından yayımlanan SLA, bu yedekliliklerden yararlanılarak elde edilir. IoT çözümünün geliştiricileri bu HA özelliklerinden yararlanmak için ek bir çalışma gerektirmez. IoT Hub makul bir yüksek çalışma süresi garantisi sunsa da, herhangi bir dağıtılmış bilgi işlem platformunda olduğu gibi geçici hatalar yine de beklenebilir. Çözümlerinizi şirket içi bir çözümden buluta geçirmeye yeni başlıyorsanız, odaklanmanızın "hatalar arasındaki ortalama süre" yerine "ortalama kurtarma süresi" iyileştirmesine geçiş yapması gerekir. Başka bir deyişle, karmada bulutla çalışırken geçici hatalar normal olarak kabul edilir. Geçici hatalarla başa çıkmak için bulut uygulamasıyla etkileşim kuran bileşenlerde uygun yeniden deneme desenlerinin yerleşik olarak bulunması gerekir.
Kullanılabilirlik alanları
IoT Hub, Azure kullanılabilirlik alanlarını destekler. Kullanılabilirlik alanı, uygulamalarınızı ve verilerinizi veri merkezi hatalarından koruyan yüksek kullanılabilirlik teklifidir. Kullanılabilirlik alanı desteği olan bir bölge, bu 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 yapılandırma, bölge içinde çoğaltma ve yedeklilik sağlar.
Kullanılabilirlik alanları iki avantaj sağlar: veri dayanıklılığı ve daha sorunsuz dağıtımlar.
Veri dayanıklılığı , temel alınan depolama hizmetlerini kullanılabilirlik alanları tarafından desteklenen depolama ile değiştirmekten gelir. Bu çözümler genellikle hataların veya kesintilerin önemli sonuçlar doğurabileceği karmaşık, dinamik ve belirsiz ortamlarda çalıştığından, IoT çözümleri için veri dayanıklılığı önemlidir. IoT çözümünün üretim katı, perakende veya restoran ortamları, sağlık sistemleri veya altyapıyı destekleyip desteklemediği fark etmeksizin, hatalardan kurtarmak ve güvenilir ve tutarlı hizmetler sağlamak için verilerin kullanılabilirliği ve kalitesi gereklidir.
Daha sorunsuz dağıtımlar , temel alınan veri merkezi donanımını kullanılabilirlik alanlarını destekleyen daha yeni bir donanımla değiştirmekten gelir. Bu donanım geliştirmeleri, müşterinin cihaz bağlantısının kesilmesi ve yeniden bağlanmasının yanı sıra dağıtımla ilgili diğer kapalı kalma süreleri üzerindeki etkisini en aza indirir. IoT Hub mühendislik ekibi, hem güvenlik nedenleriyle hem de özellik geliştirmeleri sağlamak için her ioT hub'ına her ay birden fazla güncelleştirme dağıtır. Kullanılabilirlik alanları tarafından desteklenen donanım 15 güncelleştirme etki alanına bölünür, böylece her güncelleştirme daha sorunsuz olur ve iş akışlarınızı en az düzeyde etkiler. Güncelleştirme etki alanları hakkında daha fazla bilgi için bkz . Kullanılabilirlik kümeleri.
IoT Hub için kullanılabilirlik alanı desteği, aşağıdaki Azure bölgelerinde oluşturulan yeni IoT Hub kaynakları için otomatik olarak etkinleştirilir:
| Bölge | Veri dayanıklılığı | Daha sorunsuz dağıtımlar |
|---|---|---|
| Doğu Avustralya | 
|
|
| Güney Brezilya |
|
|
| Orta Kanada |
|
|
| Orta Hindistan | 
|
|
| Central US |
|
|
| Doğu ABD |
|
|
| Orta Fransa |
|
|
| Orta Batı Almanya |
|
|
| Doğu Japonya |
|
|
| Güney Kore - Orta |
|
|
| Kuzey Avrupa |
|
|
| Doğu Norveç |
|
|
| Katar Merkezi |
|
|
| Southcentral ABD |
|
|
| Güneydoğu Asya |
|
|
| Güney Birleşik Krallık |
|
|
| West Europe |
|
|
| Batı ABD 2 |
|
|
| Batı ABD 3 |
|
|
Bölgeler arası DR
Bir veri merkezinin güç kesintileri veya fiziksel varlıklarla ilgili diğer hatalar nedeniyle genişletilmiş kesintiler yaşadığı bazı nadir durumlar olabilir. Bu tür olaylar nadirdir ve daha önce açıklanan bölge içi HA özelliği her zaman yardımcı olmayabilir. IoT Hub, bu tür genişletilmiş kesintilerden kurtarmak için birden çok çözüm sağlar.
Böyle bir durumda müşterilerin kullanabileceği 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 ilkini 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 sunulan belirli GPO'lar aşağıdaki bölümlerde ele alınıyor. Bir IoT hub'ının birincil bölgesinden yük devretmesini gerçekleştirmeye yönelik bu seçeneklerden biri kullanıldığında, hub ilgili Azure coğrafi olarak eşleştirilmiş bölgede tamamen işlevsel hale gelir.
Bu yük devretme seçeneklerinin her ikisi de aşağıdaki kurtarma noktası hedeflerini (RPO' lar) sunar:
| Veri türü | Kurtarma noktası hedefleri (RPO) |
|---|---|
| Kimlik kayıt defteri | 0-5 dakika veri kaybı |
| Cihaz ikizi verileri | 0-5 dakika veri kaybı |
| Buluttan cihaza iletiler1 | 0-5 dakika veri kaybı |
| Üst1 ve cihaz işleri | 0-5 dakika veri kaybı |
| Cihazdan buluta iletiler | Tüm okunmamış iletiler kaybolur |
| Buluttan cihaza geri bildirim iletileri | Tüm okunmamış iletiler kaybolur |
1Buluttan cihaza iletiler ve üst işler el ile yük devretmenin bir parçası olarak kurtarılamaz.
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, cihazdan buluta iletilerinizin çalışmaya devam etmesi gerektiği ve cihaz kayıt defterinin tamamının olduğu anlamına gelir. Event Grid aracılığıyla yayılan olaylar, bu Event Grid abonelikleri kullanılabilir olmaya devam ettikçe daha önce yapılandırılan abonelikler aracılığıyla kullanılabilir. Özel uç noktalar için ek işleme gerekmez.
Dikkat
- Yük devretme sonrasında IoT Hub yerleşik olay uç noktasının Event Hubs uyumlu adı ve uç noktası değişir. Event Hubs istemcisi veya olay işlemcisi konağı kullanarak yerleşik uç noktadan telemetri iletileri alırken bağlantıyı kurmak için IoT hub bağlantı dizesi kullanmanız gerekir. Bu, arka uç uygulamalarınızın yük devretme sonrasında el ile müdahaleye gerek kalmadan çalışmaya devam etmesini sağlar. Olay Hub'ı ile uyumlu adı ve uç noktayı doğrudan uygulamanızda kullanıyorsanız, işlemlere devam etmek için yük devretmeden sonra yeni Event Hub uyumlu uç noktayı getirmeniz gerekir. Daha fazla bilgi için bkz . El ile yük devretme ve Olay Hub'ı.
- Yerleşik Olaylar uç noktasını bağlamak için Azure İşlevleri veya Azure Stream Analytics kullanıyorsanız Yeniden Başlatma gerçekleştirmeniz gerekebilir. Bunun nedeni yük devretme sırasında önceki uzaklıkların artık geçerli olmamasıdır.
- Depolamaya yönlendirme yaparken, bölüm varsayımlarında bulunmadan tüm blobların veya dosyaların okunduğundan emin olmak için blobları veya dosyaları listelemenizi ve sonra bunlar üzerinde yineleme yapmanızı öneririz. Bölüm aralığı, Microsoft tarafından başlatılan bir yük devretme veya el ile yük devretme sırasında değişebilir. Blob listesini listelemek için Blobları Listele API'sini veya dosya listesi için AdLS 2. Nesil API'sini listeleyebilirsiniz. Daha fazla bilgi edinmek için bkz. Yönlendirme uç noktası olarak Azure Depolama.
Microsoft tarafından başlatılan yük devretme
Microsoft tarafından başlatılan yük devretme, Microsoft tarafından nadir durumlarda etkilenen bir bölgeden ilgili coğrafi olarak eşleştirilmiş bölgeye tüm IoT hub'larının yükünü devretmek için kullanılır. Bu işlem varsayılan bir seçenektir ve kullanıcının müdahalesi gerekmez. Microsoft, bu seçeneğin ne zaman uygulanacağını belirleme hakkını saklıdır. Bu mekanizma, kullanıcının hub'ı yük devretmeden önce kullanıcı onayı içermez. Microsoft tarafından başlatılan yük devretmenin kurtarma süresi hedefi (RTO) 2-26 saattir.
Büyük RTO'nun nedeni, Microsoft'un bu bölgedeki tüm etkilenen müşteriler adına yük devretme işlemini gerçekleştirmesi gerektiğidir. Yaklaşık bir gün kapalı kalma süresini sürdürebilen 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çeneğe bağımlı olmanız sizin için sorun değildir. Bu işlem tetiklendiğinde çalışma zamanı işlemlerinin tamamen çalışır duruma gelmesi için toplam süre , "Kurtarma süresi" bölümünde açıklanmıştır.
Yalnızca Brezilya Güney ve Güneydoğu Asya (Singapur) bölgelerine IoT hub'ları dağıtan kullanıcılar bu özelliği geri çevirebilir. Daha fazla bilgi için bkz . Olağanüstü durum kurtarmayı devre dışı bırakma.
Not
Azure IoT Hub, müşteri verilerini hizmet örneğini dağıttığınız coğrafyanın dışında depolamaz veya işlemez. Daha fazla bilgi için bkz . Azure'da bölgeler arası çoğaltma.
El ile yük devretme
İş çalışma süresi hedefleriniz Microsoft tarafından başlatılan yük devretmenin sağladığı RTO tarafından karşılanmıyorsa, yük devretme işlemini kendiniz tetikleyebilmek için el ile yük devretme kullanmayı göz önünde bulundurun. Bu seçeneği kullanan RTO 10 dakika ile birkaç saat arasında olabilir. RTO şu anda yük devredilmekte 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 balo parkında olmasını bekleyebilirsiniz. Bu işlem tetiklendiğinde çalışma zamanı işlemlerinin tamamen çalışır duruma gelmesi için toplam süre , "Kurtarma süresi" bölümünde açıklanmıştır.
El ile yük devretme seçeneği, birincil bölgenin kapalı kalma süresi yaşayıp yaşamadığına bakılmaksızın her zaman kullanılabilir. Bu nedenle, bu seçenek planlı yük devretme gerçekleştirmek için kullanılabilir. Planlı yük devretme işlemlerinin örnek kullanımlarından biri, düzenli yük devretme tatbikatları gerçekleştirmektir. Ancak, planlı bir yük devretme işleminin bu seçenek için RTO tarafından tanımlanan süre boyunca hub'da kapalı kalma süresine neden olması ve ayrıca yukarıdaki RPO tablosu tarafından tanımlandığı şekilde veri kaybına neden olması dikkat edilmesidir. Gerçek bir olağanüstü durum oluştuğunda uçtan uca çözümlerinizin çalışır duruma getirilebilmesi için düzenli aralıklarla planlanan 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'dan 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 Event Hubs
IoT Hub yerleşik olay uç noktasının Event Hubs uyumlu adı ve uç noktası, el ile yük devretme işleminden sonra değişir. Bunun nedeni Event Hubs istemcisinin IoT Hub olaylarını görünür olmamasıdır. Aynı durum İşlevler ve Azure Stream Analytics gibi diğer bulut tabanlı istemciler için de geçerlidir. Uç noktayı ve adı almak için Azure portalını veya .NET SDK'sını kullanabilirsiniz.
Portalı kullanma
Portal kullanarak Event Hub ile uyumlu uç noktayı ve Event Hub ile uyumlu adı alma hakkında daha fazla bilgi için bkz. Yerleşik uç noktaya Bağlan.
.NET SDK’yı kullanma
Event Hubs ile uyumlu uç noktayı yeniden özetlemek üzere IoT Hub bağlantı dizesi kullanmak için konumunda https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubsbulunan bir örneği kullanın. 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üklü olmalıdır.
Test tatbikatlarını çalıştırma
Test tatbikatları, üretim ortamlarınızda kullanılan IoT hub'larında gerçekleştirilmemelidir.
IoT hub'unu farklı bir bölgeye geçirmek için el ile yük devretme kullanmayın
Merkezinizi coğrafi olarak eşleştirilmiş Azure bölgeleri arasında kalıcı olarak geçirmek için el ile yük devretme mekanizması olarak kullanılmamalıdır. Cihazların hub'ın birincil bölgesine en yakın konumda olduğunu varsayarsak, hub ikincil bölgeye devredildiğinde IoT hub'ına karşı gerçekleştirilen işlemlerin gecikme süresi artar.
Yeniden çalışma
Yük devretme eylemini ikinci kez tetikleyerek eski birincil bölgeye geri dönebilirsiniz. Özgün yük devretme işlemi, özgün birincil bölgedeki genişletilmiş bir kesintiden kurtarmak için gerçekleştirildiyse, konum kesinti durumundan kurtarıldıktan sonra hub'ın özgün konuma geri döndürülmesi önerilir.
Önemli
- Kullanıcıların günde yalnızca 2 başarılı yük devretme ve 2 başarılı yeniden çalışma işlemi gerçekleştirmesine izin verilir.
- Arka arkaya yük devretme/yeniden çalışma işlemlerine izin verilmez. Bu işlemler arasında 1 saat beklemeniz gerekir.
Kurtarma zamanı
IoT hub örneğinin FQDN'si (ve dolayısıyla bağlantı dizesi) yük devretme sonrasında aynı kalırken, temel ip adresi değişir. 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 [10 dk - El ile yük devretme için 2 saat | Microsoft tarafından başlatılan yük devretme için 2 - 26 saat] + DNS yayma gecikmesi + İstemci uygulamasının önbelleğe alınan IoT Hub IP adreslerini yenilemek için geçen süre.
Önemli
IoT SDK'ları IoT hub'ının IP adresini önbelleğe almaz. SDK'larla birlikte kullanılan kullanıcı kodunun IoT hub'ının IP adresini önbelleğe almaması önerilir.
Olağanüstü durum kurtarmayı devre dışı bırakma
IoT Hub, her IoT hub'ı için eşleştirilmiş bölgeye veri çoğaltarak Microsoft Tarafından Başlatılan Yük Devretme ve El ile Yük Devretme sağlar. Bazı bölgelerde IoT hub'ı oluştururken olağanüstü durum kurtarmayı devre dışı bırakarak bölge dışında veri çoğaltmasını önleyebilirsiniz. Aşağıdaki bölgeler bu özelliği destekler:
- Güney Brezilya; eşleştirilmiş bölge, Orta Güney ABD.
- Güneydoğu Asya (Singapur); eşleştirilmiş bölge, Doğu Asya (Hong Kong ÖİB).
Desteklenen bölgelerde olağanüstü durum kurtarmayı devre dışı bırakmak için IoT hub'ınızı oluştururken Olağanüstü durum kurtarma özelliğinin etkin olduğundan emin olun:
Arm şablonu kullanarak bir IoT hub'ı oluşturduğunuzda olağanüstü durum kurtarmayı da devre dışı bırakabilirsiniz.
IoT hub'ı için olağanüstü durum kurtarmayı devre dışı bırakırsanız yük devretme özelliği kullanılamaz.
Bir IoT hub'ı oluşturduğunuzda yalnızca Brezilya Güney veya Güneydoğu Asya'da eşleştirilmiş bölge dışında veri çoğaltmasını önlemek için olağanüstü durum kurtarmayı devre dışı bırakabilirsiniz. Olağanüstü durum kurtarmayı devre dışı bırakmak için mevcut IoT hub'ınızı yapılandırmak istiyorsanız, olağanüstü durum kurtarma devre dışı bırakılmış yeni bir IoT hub oluşturmanız ve mevcut IoT hub'ınızı el ile geçirmeniz gerekir. Yönergeler için bkz . IoT hub'ına geçiş.
Bölgeler arası HA elde edin
İş çalışma süresi hedefleriniz Microsoft tarafından başlatılan yük devretme veya el ile yük devretme seçeneklerinin sağladığı RTO tarafından karşılanmıyorsa, cihaz başına otomatik bölgeler arası yük devretme mekanizması uygulamayı düşünmelisiniz. IoT çözümlerinde dağıtım topolojilerinin eksiksiz bir şekilde işlenmesi bu makalenin kapsamı dışındadır. Makalede, yüksek kullanılabilirlik ve olağanüstü durum kurtarma için bölgesel yük devretme dağıtım modeli ele alınmaktadır.
Bölgesel yük devretme modelinde, çözüm arka ucu öncelikli olarak tek bir veri merkezi konumunda çalışır. İkincil bir IoT hub'ı ve arka ucu başka bir veri merkezi konumuna 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. Tek bir bölgede kalmak yerine bölgeler arası yük devretme modeli uygulayarak çözüm kullanılabilirliğini geliştirebilirsiniz.
Yüksek düzeyde, IoT Hub ile bölgesel yük devretme modeli uygulamak için aşağıdaki adımları uygulamanı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. Dahil olan çoğu hizmetin durum bilgisi olan yapısı göz önünde bulundurulduğunda, çözüm yöneticilerinin bölgeler arası yük devretme işlemini tetiklemesi yaygın bir durumdur. Yeni uç noktayı cihazlara iletmenin en iyi yolu, işlemin denetimini korurken, geçerli etkin uç nokta için düzenli olarak bir concierge hizmetini denetlemelerini sağlamaktır. Concierge hizmeti, DNS yeniden yönlendirme teknikleri (örneğin, Azure Traffic Manager kullanarak) kullanılarak çoğaltılan ve erişilebilir durumda tutulan bir web uygulaması olabilir.
Not
IoT hub hizmeti, Azure Traffic Manager'da desteklenen bir uç nokta türü değildir. Önerilen concierge hizmetini, uç nokta sistem durumu yoklaması API'sini uygulayarak Azure traffic manager ile tümleştirmeniz önerilir.
Kimlik kayıt defteri çoğaltması: Kullanılabilir olması için ikincil IoT hub'ı çö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'ın cihaz kimliği dışarı aktarma işlevi bu bağlamda kullanışlı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 verilerin birincil bölgeye geri geçirilmesi gerekir. 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 etkili işlemleri kullanmanız gerekir. 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 eski durumu tolere etmek için tasarlanmalıdır. Bu durum, sistemin kurtarma noktası hedeflerine (RPO) göre iyileşmesi 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 doğru seçeneği belirtmek için başvuru çerçevesi olarak kullanılabilecek HA/DR seçeneklerinin özeti aşağıda verilmiştir.
| HA/DR seçeneği | KSH | KNH | El ile müdahale mi gerekiyor? | Uygulama karmaşıklığı | Maliyet etkisi |
|---|---|---|---|---|---|
| Microsoft tarafından başlatılan yük devretme | 2 - 26 saat | Yukarıdaki RPO tablosuna bakın | Hayır | Hiçbiri | Hiçbiri |
| El ile yük devretme | 10 dk - 2 saat | Yukarıdaki RPO tablosuna bakın | Yes | Çok düşük. Bu işlemi yalnızca portaldan tetiklemeniz gerekir. | Hiçbiri |
| Bölgeler arası HA | < 1 dk | Özel HA çözümünüzün çoğaltma sıklığına bağlıdır | Hayır | Yüksek | > 1 IoT hub maliyeti 1 kat |