Konsep provisi ulang Perangkat Azure IoT Hub
Selama siklus hidup solusi IoT, memindahkan perangkat antar IoT hub merupakan hal yang umum. Alasan pemindahan ini dapat mencakup skenario berikut:
Geolokasi/GeoLatensi: Saat perangkat berpindah antar lokasi, latensi jaringan ditingkatkan dengan memigrasikan perangkat ke Azure IoT Hub yang lebih dekat.
Multipenyewa: Perangkat dapat digunakan dalam solusi IoT yang sama dan ditetapkan kembali ke pelanggan atau situs pelanggan baru. Pelanggan baru ini dapat dilayani menggunakan hub IoT yang berbeda.
Perubahan solusi:Perangkat dapat dipindahkan ke solusi IoT baru atau yang diperbarui. Penetapan ulang ini mungkin mengharuskan perangkat untuk berkomunikasi dengan hub IoT baru yang terhubung ke komponen ujung belakang lainnya.
Karantina: Mirip dengan perubahan solusi. Perangkat yang tidak berfungsi, disusupi, atau sudah kedaluwarsa dapat ditetapkan kembali ke hub IoT yang hanya dapat memperbarui dan kembali ke kepatuhan. Setelah perangkat berfungsi dengan baik, perangkat kemudian dimigrasikan kembali ke hub utamanya.
Provisi ulang dukungan dalam Layanan Provisi Perangkat mengatasi kebutuhan ini. Perangkat dapat secara otomatis ditetapkan ulang ke hub IoT baru berdasarkan kebijakan provisi ulang yang dikonfigurasi pada entri pendaftaran perangkat.
Data status perangkat
Data status perangkat terdiri dari kemampuan perangkat kembar dan perangkat. Data ini disimpan dalam instans Layanan Provisi Perangkat dan hub IoT tempat perangkat ditetapkan.
Saat perangkat awalnya diprovisikan dengan instans Layanan Provisi Perangkat, langkah-langkah berikut dilakukan:
Perangkat mengirimkan permintaan provisi ke instans Layanan Provisi Perangkat. Instans layanan mengautentikasi identitas perangkat berdasarkan entri pendaftaran, dan membuat konfigurasi awal data status perangkat. Instans layanan menetapkan perangkat ke hub IoT berdasarkan konfigurasi pendaftaran dan mengembalikan penetapan hub IoT tersebut ke perangkat.
Instans layanan provisi memberikan salinan data status perangkat awal apa pun ke hub IoT yang ditetapkan. Perangkat terhubung ke hub IoT yang ditetapkan dan memulai operasi.
Seiring waktu, data status perangkat pada hub IoT dapat diperbarui oleh operasi perangkat dan operasi ujung belakang. Informasi status perangkat awal yang disimpan dalam instans Layanan Provisi Perangkat tetap tidak tersentuh. Data status perangkat yang belum tersentuh ini adalah konfigurasi awal.
Tergantung pada skenarionya, saat perangkat berpindah antar hub IoT, mungkin juga perlu untuk memigrasikan status perangkat yang diperbarui pada hub IoT sebelumnya ke hub IoT baru. Migrasi ini didukung oleh kebijakan provisi ulang di Layanan Provisi Perangkat.
Kebijakan provisi ulang
Bergantung pada skenarionya, perangkat dapat mengirim permintaan ke instans layanan provisi saat boot ulang. Ini juga mendukung metode untuk secara manual memicu provisi sesuai permintaan. Kebijakan provisi ulang pada entri pendaftaran menentukan bagaimana instans layanan provisi perangkat menangani permintaan provisi ini. Kebijakan ini juga menentukan apakah data status perangkat harus dimigrasikan selama provisi ulang. Kebijakan yang sama tersedia untuk pendaftaran individu dan grup pendaftaran:
Provisi ulang dan migrasi data: Kebijakan ini adalah default untuk entri pendaftaran baru. Kebijakan ini mengambil tindakan ketika perangkat yang terkait dengan entri pendaftaran mengirimkan permintaan baru (1). Bergantung pada konfigurasi entri pendaftaran, perangkat mungkin ditetapkan ulang ke IoT hub lain. Jika perangkat mengubah IoT hub, pendaftaran perangkat dengan IoT hub awal akan dihapus. Informasi status perangkat yang diperbarui dari hub IoT awal akan dimigrasikan ke hub IoT baru (2). Selama migrasi, status perangkat akan dilaporkan sebagai Menetapkan.
Provisi ulang dan reset ke konfigurasi awal: Kebijakan ini mengambil tindakan ketika perangkat yang terkait dengan entri pendaftaran mengirimkan permintaan provisi baru (1). Bergantung pada konfigurasi entri pendaftaran, perangkat mungkin ditetapkan ulang ke IoT hub lain. Jika perangkat mengubah IoT hub, pendaftaran perangkat dengan IoT hub awal akan dihapus. Data konfigurasi awal yang diterima instans layanan provisi saat perangkat diprovisikan diberikan ke hub IoT baru (2). Selama migrasi, status perangkat akan dilaporkan sebagai Menetapkan.
Kebijakan ini sering digunakan untuk reset pabrik tanpa mengubah hub IoT.
Jangan pernah provisi ulang: Perangkat tidak pernah ditetapkan ulang ke hub yang berbeda. Kebijakan ini disediakan untuk mengelola kompatibilitas mundur.
Catatan
DPS akan selalu memanggil webhook alokasi kustom terlepas dari kebijakan penyediaan ulang jika ada ReturnData baru untuk perangkat. Jika kebijakan provisi ulang diatur untuk tidak pernah memprovisi ulang, webhook akan dipanggil tetapi perangkat tidak akan mengubah hub yang ditetapkan.
Saat merancang solusi Anda dan mendefinisikan logika provisi ulang ada beberapa hal yang perlu dipertimbangkan. Contohnya:
- Seberapa sering Anda mengharapkan perangkat Anda untuk memulai ulang
- Kuota dan batasan DPS
- Waktu penyebaran yang diharapkan untuk armada Anda (peluncuran bertahap vs semua sekaligus)
- Kemampuan coba lagi yang diterapkan pada kode klien Anda, seperti yang dijelaskan pada panduan umum Coba lagi di Azure Architecture Center
Tip
Sebaiknya jangan provisi pada setiap boot ulang perangkat, karena ini dapat menyebabkan beberapa masalah saat memprovisikan ulang beberapa ribuan atau jutaan perangkat sekaligus. Sebagai gantinya, Anda harus mencoba menggunakan API Pencarian Status Pendaftaran Perangkat dan mencoba menyambungkan dengan informasi tersebut ke IoT Hub. Jika gagal, coba provisi ulang karena informasi IoT Hub mungkin telah berubah. Perlu diingat bahwa kueri untuk status pendaftaran akan dihitung sebagai pendaftaran perangkat baru, jadi Anda harus mempertimbangkan batas Pendaftaran perangkat. Pertimbangkan juga untuk menerapkan logika coba lagi yang sesuai, seperti back-off eksponensial dengan pengacakan, seperti yang dijelaskan pada panduan umum Coba lagi. Dalam beberapa kasus, tergantung pada kemampuan perangkat, dimungkinkan untuk menyimpan informasi IoT Hub langsung di perangkat untuk terhubung langsung ke IoT Hub setelah provisi pertama kali menggunakan DPS terjadi. Jika Anda memilih untuk melakukan ini, pastikan Anda menerapkan mekanisme fallback jika Anda mendapatkan kesalahan tertentu dari Hub terjadi, misalnya, pertimbangkan skenario berikut:
- Coba lagi operasi Hub jika kode hasil adalah 429 (Terlalu Banyak Permintaan) atau kesalahan dalam rentang 5xx. Jangan coba kembali untuk kesalahan lainnya.
- Untuk kesalahan 429, hanya coba kembali setelah waktu yang ditunjukkan di header Retry-After.
- Untuk kesalahan 5xx, gunakan back-off eksponensial, dengan percobaan kembali pertama setidaknya 5 detik setelah respons.
- Pada kesalahan selain 429 dan 5xx, daftar ulang melalui DPS
- Idealnya Anda juga harus mendukung metode untuk memicu provisi sesuai permintaan secara manual.
Sebaiknya mempertimbangkan batas layanan saat merencanakan aktivitas seperti mendorong pembaruan ke armada Anda. Misalnya, memperbarui armada sekaligus dapat menyebabkan semua perangkat mendaftar ulang melalui DPS (yang dapat dengan mudah berada di atas batas kuota pendaftaran) - Untuk skenario tersebut, pertimbangkan untuk merencanakan pembaruan perangkat secara bertahap alih-alih memperbarui seluruh armada Anda secara bersamaan.
Mengelola kompatibilitas mundur
Sebelum September 2018, penetapan perangkat ke hub IoT memiliki perilaku yang lengket. Ketika perangkat kembali melalui proses provisi, perangkat hanya akan ditetapkan kembali ke hub IoT yang sama.
Untuk solusi yang telah bergantung pada perilaku ini, layanan provisi menyertakan kompatibilitas mundur. Perilaku ini saat ini dipertahankan untuk perangkat sesuai dengan kriteria berikut:
Perangkat terhubung dengan versi API sebelum ketersediaan dukungan provisi ulang asli di Layanan Provisi Perangkat. Lihat tabel API di bawah ini.
Entri pendaftaran untuk perangkat tidak memiliki kebijakan provisi ulang yang ditetapkan pada mereka.
Kompatibilitas ini memastikan bahwa perangkat yang disebarkan sebelumnya mengalami perilaku yang sama seperti yang ada selama pengujian awal. Untuk mempertahankan perilaku sebelumnya, jangan menyimpan kebijakan provisi ulang untuk pendaftaran ini. Jika kebijakan provisi ulang ditetapkan, kebijakan provisi ulang lebih diutamakan daripada perilaku. Dengan memungkinkan kebijakan provisi ulang untuk diutamakan, pelanggan dapat memperbarui perilaku perangkat tanpa harus mencitra ulang perangkat.
Bagan alur berikut membantu menunjukkan kapan perilaku ada:
Tabel berikut menunjukkan versi API sebelum ketersediaan dukungan provisi ulang asli di Layanan Provisi Perangkat:
| REST API | C SDK | Python SDK | Simpul SDK | Java SDK | .NET SDK |
|---|---|---|---|---|---|
| 2018-04-01 dan sebelumnya | 1.2.8 dan sebelumnya | 1.4.2 dan sebelumnya | 1.7.3 atau sebelumnya | 1.13.0 atau sebelumnya | 1.1.0 atau sebelumnya |
Catatan
Nilai dan tautan ini kemungkinan akan berubah. Ini hanyalah upaya tempat penampung untuk menentukan di mana versi dapat ditentukan oleh pelanggan dan apa versi yang diharapkan.