IoT Hub Cihazı yeniden sağlama kavramları

IoT çözümünün yaşam döngüsü sırasında cihazları IoT hub'ları arasında taşımak yaygın bir durumdur. Bu taşımanın nedenleri aşağıdaki senaryoları içerebilir:

• Coğrafi Konum / Coğrafi Gecikme: Bir cihaz konumlar arasında hareket ettiği sürece, cihazın daha yakın bir IoT merkezine taşınmasıyla ağ gecikme süresi iyileştirilir.

• Çoklu kiracı: Bir cihaz aynı IoT çözümünde kullanılabilir ve yeni bir müşteriye veya müşteri sitesine yeniden atanabilir. Bu yeni müşteriye farklı bir IoT hub'ı kullanılarak hizmet sunulabilir.

• Çözüm değişikliği: Cihaz yeni veya güncelleştirilmiş bir IoT çözümüne taşınabilir. Bu yeniden atama, cihazın diğer arka uç bileşenlerine bağlı yeni bir IoT hub'ı ile iletişim kurmasını gerektirebilir.

• Karantina: Çözüm değişikliğine benzer. Hatalı çalışan, güvenliği tehlikeye girmiş veya güncel olmayan bir cihaz, yalnızca güncelleştirilebilen ve yeniden uyumlu hale getirilebilen bir IoT hub'ına yeniden atanabilir. Cihaz düzgün çalıştığında ana hub'ına geri geçirilir.

Cihaz Sağlama Hizmeti'nde desteğin yeniden sağlanması bu gereksinimleri karşılar. Cihazlar, cihazın kayıt girişinde yapılandırılan yeniden sağlama ilkesine göre yeni IoT hub'larına otomatik olarak yeniden atanabilir.

Cihaz durumu verileri

Cihaz durumu verileri, cihaz ikizi ve cihaz özelliklerinden oluşur. Bu veriler Cihaz Sağlama Hizmeti örneğinde ve bir cihazın atandığı IoT hub'ında depolanır.

Bir cihaz başlangıçta bir Cihaz Sağlama Hizmeti örneğiyle sağlandığında aşağıdaki adımlar yapılır:

1. Cihaz, bir Cihaz Sağlama Hizmeti örneğine bir sağlama isteği gönderir. Hizmet örneği, bir kayıt girdisine göre cihaz kimliğini doğrular ve cihaz durumu verilerinin ilk yapılandırmasını oluşturur. Hizmet örneği, cihazı kayıt yapılandırmasına göre bir IoT hub'ına atar ve bu IoT hub atamasını cihaza döndürür.

2. Sağlama hizmeti örneği, atanan IoT hub'ına ilk cihaz durumu verilerinin bir kopyasını verir. Cihaz, atanan IoT hub'ına bağlanır ve işlemlere başlar.

Zaman içinde cihaz işlemleri ve arka uç işlemleri IoT hub'ı üzerindeki cihaz durumu verilerini güncelleştirebilir. Cihaz Sağlama Hizmeti örneğinde depolanan ilk cihaz durumu bilgilerine dokunulmaz. Bu dokunulmamış cihaz durumu verileri ilk yapılandırmadır.

Senaryoya bağlı olarak, bir cihaz IoT hub'ları arasında hareket ettikçe, önceki IoT hub'ına güncelleştirilmiş cihaz durumunu yeni IoT hub'ına geçirmek de gerekebilir. Cihaz Sağlama Hizmeti'nde ilkelerin yeniden sağlanması bu geçişi destekleyebilir.

Yeniden tahsis politikaları

Senaryoya bağlı olarak, bir cihaz yeniden başlatmada bir sağlama hizmeti örneğine istek gönderebilir. Ayrıca isteğe bağlı olarak sağlamayı el ile tetikleme yöntemini de destekler. Kayıt girişinde yeniden sağlama ilkesi, cihaz sağlama hizmeti örneğinin bu sağlama isteklerini nasıl işlediğini belirler. İlke, yeniden sağlama sırasında cihaz durumu verilerinin geçirilip geçirilmeyeceğini de belirler. Tek tek kayıtlar ve kayıt grupları için aynı ilkeler kullanılabilir:

• Verileri yeniden sağlama ve geçirme: Bu ilke, yeni kayıt girdileri için varsayılan ilkedir. Bu ilke, kayıt girişiyle ilişkili cihazlar yeni bir istek (1) gönderdiğinde eyleme geçer. Kayıt girişi yapılandırmasına bağlı olarak cihaz başka bir IoT hub'ına yeniden atanabilir. Cihaz IoT hub'larını değiştiriyorsa, ilk IoT hub'ı ile cihaz kaydı kaldırılır. İlk IoT hub'ından güncelleştirilmiş cihaz durumu bilgileri yeni IoT hub'ına (2) geçirilir. Geçiş sırasında cihazın durumu Atanıyor olarak bildirilir.

  

• Yeniden sağlama ve ilk yapılandırmaya sıfırlama: Bu ilke, kayıt girişiyle ilişkili cihazlar yeni bir sağlama isteği (1) gönderdiğinde eyleme geçer. Kayıt girişi yapılandırmasına bağlı olarak cihaz başka bir IoT hub'ına yeniden atanabilir. Cihaz IoT hub'larını değiştiriyorsa, ilk IoT hub'ı ile cihaz kaydı kaldırılır. Cihaz sağlandığında sağlama hizmeti örneği tarafından alınan ilk yapılandırma verileri, yeni IoT hub'ına aktarılır (2). Geçiş sırasında cihazın durumu Atanıyor olarak bildirilir.

  Bu ilke genellikle IoT hub'larını değiştirmeden fabrika sıfırlaması için kullanılır.

  

• Hiçbir zaman yeniden tahsis etme: Cihaz hiçbir zaman farklı bir hub'a yeniden atanmaz. Bu ilke geriye dönük uyumluluğu yönetmek için sağlanır.

Not

DPS, cihaz için yeni ReturnData olması durumunda, yeniden sağlama ilkesinden bağımsız olarak her zaman özel ayırma web kancasını çağırır. Yeniden sağlama ilkesi hiçbir zaman yeniden sağlama şeklinde ayarlanmışsa, web kancası çağrılır ancak cihaz atandığı hub'ı değiştirmez.

Çözümünüzü tasarlayıp bir yeniden sağlama mantığı tanımlarken göz önünde bulundurmanız gereken birkaç şey vardır. Örneğin:

• Cihazlarınızın ne sıklıkta yeniden başlatılmasını bekliyorsunuz?
• DPS kotaları ve sınırları
• Filonuz için beklenen dağıtım süresi (aşamalı dağıtım ve tümü aynı anda)
• Azure Mimari Merkezi'ndeki Yeniden Deneme genel kılavuzunda açıklandığı gibi istemci kodunuz üzerinde uygulanan yeniden deneme özelliği

İpucu

Aynı anda birkaç bin veya milyonlarca cihazı yeniden sağlarken bazı sorunlara neden olabileceğinden, cihaz her yeniden başlatıldığında sağlamanızı önermiyoruz. Bunun yerine Cihaz Kayıt Durumu Arama API'sini kullanmayı ve bu bilgilerle IoT Hub'a bağlanmayı denemeniz gerekir. Bu başarısız olursa IoT Hub bilgileri değişebileceğinden yeniden yapılandırmayı deneyin. Kayıt durumunu sorgulamanın yeni bir cihaz kaydı olarak sayıldığını unutmayın, bu nedenle cihaz kayıt sınırını dikkate almanız gerekir. Ayrıca, yeniden deneyim genel kılavuzunda açıklandığı gibi rastgeleleşme ile üstel geri çekilme gibi uygun bir yeniden deneyim mantığını uygulamayı göz önünde bulundurun. Bazı durumlarda, cihaz özelliklerine bağlı olarak, DPS kullanılarak ilk kez sağlama gerçekleştikten sonra IoT Hub'a doğrudan bağlanmak için IoT Hub bilgilerini doğrudan cihaza kaydetmek mümkündür. Doğrudan cihaza kaydetmeyi seçerseniz IoT Hub'dan belirli hatalar oluşması durumunda bir geri dönüş mekanizması uyguladığınızdan emin olun. Örneğin, aşağıdaki senaryoları değerlendirin:

• Sonuç kodu 429 (Çok Fazla İstek) veya 5xx aralığında bir hataysa IoT Hub işlemini yeniden deneyin. Diğer hatalar için yeniden işlem yapmayın.
• 429 hataları için yalnızca Yeniden Dene-Sonra üst bilgisinde belirtilen süreden sonra yeniden deneyin.
• 5xx hataları için üstel geri alma kullanın ve ilk yeniden deneme yanıttan en az 5 saniye sonra olur.
• 429 ve 5xx dışındaki hatalarda DPS aracılığıyla yeniden kaydetme
• İdeal olarak, isteğe bağlı olarak sağlamayı el ile tetikleyen doğrudan bir yöntemi de desteklemeniz gerekir.

Ayrıca filonuza güncelleştirme gönderme gibi etkinlikleri planlarken hizmet sınırlarını dikkate almanızı öneririz. Örneğin, filonun tümünü bir kerede güncelleştirmek tüm cihazların DPS aracılığıyla yeniden kaydolmasına neden olabilir (kayıt kotası sınırının üzerinde olabilir) - Bu tür senaryolarda, filonuzun tamamını aynı anda güncelleştirmek yerine aşamalar halinde cihaz güncelleştirmelerini planlamayı göz önünde bulundurun.

Geriye dönük uyumluluğu yönetme

Eylül 2018'e kadar IoT hub'larına yapılan cihaz atamaları yapışkan bir davranışa sahipti. Bir cihaz sağlama işlemine geri döndüğünde yalnızca aynı IoT hub'ına yeniden atanabilir.

Bu davranışa bağımlılık alan çözümler için sağlama hizmeti geriye dönük uyumluluk içerir. Bu davranış şu anda cihazlar için aşağıdaki ölçütlere göre korunur:

• Cihazlar, Cihaz Sağlama Hizmeti'nde yerel yeniden sağlama desteği sunulmadan önce bir API sürümüyle bağlanır. Aşağıdaki API tablosuna bakın.

• Cihazların kayıt girdisinde yeniden sağlama ilkesi ayarlanmamıştır.

Bu uyumluluk, daha önce dağıtılan cihazların ilk test sırasında mevcut olan davranışın aynısını yaşamasını sağlar. Önceki davranışı korumak için bu kayıtlara yeniden sağlama ilkesi kaydetmeyin. Yeniden sağlama politikası ayarlandığında, yeniden sağlama politikası davranış üzerinde önceliğe sahiptir. Yeniden sağlama ilkesinin öncelikli olmasına izin vererek, müşteriler cihazı yeniden kullanmak zorunda kalmadan cihaz davranışını güncelleştirebilir.

Aşağıdaki akış grafiği, davranışın ne zaman mevcut olduğunu göstermeye yardımcı olur:

Aşağıdaki tabloda, Cihaz Sağlama Hizmeti'nde yerel yeniden sağlama desteğinin kullanılabilirliği öncesinde API sürümleri gösterilmektedir:

REST API	C SDK	Python SDK'sı	Node.js SDK	Java SDK'sı	.NET SDK
2018-04-01 ve öncesi	1.2.8 ve öncesi	1.4.2 ve öncesi	1.7.3 veya öncesi	1.13.0 veya öncesi	1.1.0 veya öncesi

Not

Bu değerler ve bağlantılar büyük olasılıkla değişebilir. Azure IoT SDK'ları ve API'leri, uygulamaların ve hizmetlerin ürün ve API'ler geliştikçe çalışmaya devam etmesini sağlamak için sürümlendirilir. Bu SDK'lar ve API'ler için başvuru belgelerinde Azure IoT SDK'larının ve API'lerinin en son sürümlerini doğrulamanızı öneririz. Örneğin, Azure IoT Hub Cihaz Sağlama Hizmeti REST API'sinin en son sürümü 2021-10-01'dir.

Sonraki adımlar

• Cihazları yeniden yapılandırma