Bagikan melalui

Konsep Reprovisioning Perangkat di 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 back-end lainnya.

  • Karantina: Seperti mengganti solusi. Perangkat yang berfungsi tidak semestinya, disusupi, atau sudah kedaluwarsa dapat ditetapkan kembali ke hub IoT yang dapat memperbarui perangkat dan memastikan kepatuhan. Setelah perangkat berfungsi dengan baik, perangkat kemudian dimigrasikan kembali ke hub utamanya.

Penyiapan ulang dukungan dalam Layanan Penyediaan 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 kembar perangkat dan kemampuan perangkat. Data ini disimpan dalam instans Layanan Provisi Perangkat dan hub IoT tempat perangkat ditetapkan.

Diagram yang memperlihatkan cara kerja provisi dengan Layanan Provisi Perangkat.

Saat perangkat awalnya diprovisikan dengan instans Layanan Provisi Perangkat, langkah-langkah berikut dilakukan:

  1. 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.

  2. 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.

Provisi dengan Layanan Provisi Perangkat

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 penataan ulang di Layanan Provisi Perangkat.

Kebijakan pengadaan 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.

    Diagram yang menunjukkan bahwa kebijakan mengambil tindakan ketika perangkat yang terkait dengan entri pendaftaran mengirimkan permintaan baru.

  • 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.

    Diagram yang menunjukkan bagaimana kebijakan mengambil tindakan ketika perangkat yang terkait dengan entri pendaftaran mengirimkan permintaan provisi baru.

  • Tidak pernah ditetapkan 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 terdapat ReturnData baru untuk perangkat. Jika kebijakan provisi ulang diatur untuk tidak pernah memprovisi ulang, webhook akan tetap dipanggil, tetapi perangkat tidak akan mengubah hub yang telah 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 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 itu gagal, coba untuk menyediakan 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 tepat, 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 yang terjadi dari Hub, 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 metode back-off eksponensial, dengan upaya ulang pertama dilakukan 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 ke belakang

Sebelum September 2018, penetapan perangkat ke hub IoT memiliki perilaku yang lengket. Ketika perangkat kembali melalui proses provisi, perangkat tersebut hanya akan ditetapkan kembali ke hub IoT yang sama.

Untuk solusi yang bergantung pada perilaku ini, layanan penyediaan menyertakan kompatibilitas mundur. Perilaku ini saat ini dipertahankan untuk perangkat sesuai dengan kriteria berikut:

  1. Perangkat terhubung dengan versi API sebelum dukungan provisi ulang yang bersifat bawaan tersedia di Layanan Provisi Perangkat. Lihat tabel API di bawah ini.

  2. Entri pendaftaran untuk perangkat tidak memiliki kebijakan reprovisi yang diterapkan 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 penyediaan ulang untuk diutamakan, pelanggan dapat memperbarui perilaku perangkat tanpa perlu mencitra ulang perangkat.

Bagan alur berikut membantu menunjukkan kapan perilaku ada:

diagram alur kompatibilitas ke belakang

Tabel berikut menunjukkan versi API sebelum ketersediaan dukungan provisi ulang asli di Layanan Provisi Perangkat:

REST API C SDK Python SDK Node 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 sementara untuk menentukan versi mana yang dapat ditentukan oleh pelanggan dan versi apa yang diantisipasi.

Langkah berikutnya