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 Konum: Bir cihaz konumlar arasında hareket ettikçe, cihazın daha yakın bir IoT hub'ına geçirilmesiyle 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 verilebilir.
Çö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 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:
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.
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 IoT hub'ı üzerindeki cihaz durumu verileri, cihaz işlemleri ve arka uç işlemleri tarafından güncelleştirilebilir. 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. Bu geçiş, Cihaz Sağlama Hizmeti'nde ilkeler yeniden sağlanarak desteklenir.
İlkeleri yeniden sağlama
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. bu ilk IoT hub'ından güncelleştirilmiş cihaz durumu bilgileri yeni IoT hub'ına (2) geçirilecektir. 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ğinin aldığı ilk yapılandırma verileri yeni IoT hub'ına (2) sağlanır. 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 sağlama: 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.
Dekont
DpS, cihaz için yeni ReturnData olması durumunda yeniden sağlama ilkesine bakılmaksızın her zaman özel ayırma web kancasını çağırır. Yeniden sağlama ilkesi hiçbir zaman yeniden sağlamayacak şekilde ayarlanırsa, web kancası çağrılır ancak cihaz atanan hub'ını değiştirmez.
Çözümünüzü tasarlarken ve yeniden sağlama mantığı tanımlarken dikkate alınması gereken birkaç nokta vardır. Örnek:
- 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
Bahşiş
Aynı anda birkaç bin veya milyonlarca cihazın yeniden sağlanması sırasında bazı sorunlara neden olabileceğinden, cihazın her yeniden başlatılmasında sağlamamanızı öneririz. 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şmiş olabileceğinden yeniden sağlamayı deneyin. Kayıt durumunu sorgulamanın yeni bir cihaz kaydı olarak sayılacağını, bu nedenle Cihaz kayıt sınırını göz önünde bulundurmanız gerektiğini unutmayın. Ayrıca, Yeniden Deneme genel kılavuzunda açıklandığı gibi rastgele bir üstel geri alma gibi uygun bir yeniden deneme mantığı uygulamayı da 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 bilgilerini doğrudan cihaza kaydederek IoT Hub'a doğrudan bağlanmak mümkündür. Bunu yapmayı seçerseniz Hub'dan belirli hatalar oluşması durumunda bir geri dönüş mekanizması uyguladığınızdan emin olun, örneğin aşağıdaki senaryoları göz önünde bulundurun:
- Sonuç kodu 429 (Çok Fazla İstek) veya 5xx aralığında bir hataysa Hub işlemini yeniden deneyin. Diğer hatalar için yeniden denemeyin.
- 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 tetikleme yöntemini 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ı olan çö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 yeniden sağlama ilkesini bu kayıtlara kaydetmeyin. Yeniden sağlama ilkesi ayarlanırsa, yeniden sağlama ilkesi davranışa göre önceliklidir. 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 SDK | Java SDK | .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 |
Dekont
Bu değerler ve bağlantılar büyük olasılıkla değişebilir. Bu yalnızca bir müşteri tarafından sürümlerin nerede belirlenebileceğini ve beklenen sürümlerin ne olacağını belirlemeye ilişkin bir yer tutucu girişimidir.