Bagikan melalui

Pola Konfigurasi Beban Kerja Edge

Berbagai macam sistem dan perangkat di lantai toko dapat membuat konfigurasi beban kerja menjadi masalah yang sulit. Artikel ini menyediakan pendekatan untuk memecahkannya.

Konteks dan masalah

Perusahaan manufaktur, sebagai bagian dari perjalanan transformasi digital mereka, semakin fokus pada pembangunan solusi perangkat lunak yang dapat digunakan kembali sebagai kemampuan bersama. Karena berbagai perangkat dan sistem di lantai toko, beban kerja modular dikonfigurasi untuk mendukung protokol, driver, dan format data yang berbeda. Terkadang bahkan beberapa instance workload dijalankan dengan konfigurasi yang berbeda di lokasi tepi yang sama. Untuk beberapa beban kerja, konfigurasi diperbarui lebih dari sekali sehari. Manajemen konfigurasi menjadi semakin penting untuk meningkatkan skala solusi edge. Oleh karena itu, manajemen konfigurasi memegang peranan vital.

Solusi

Ada beberapa karakteristik umum manajemen konfigurasi untuk beban kerja edge:

  • Ada beberapa titik konfigurasi yang dapat dikelompokkan ke dalam lapisan yang berbeda, seperti sumber perangkat lunak, alur CI/CD, penyewa cloud, dan lokasi tepi: Diagram lapisan yang mencirikan konfigurasi beban kerja: sumber perangkat lunak, alur C I /C D, penyewa cloud, dan lokasi tepi.
  • Berbagai lapisan dapat diperbarui oleh orang yang berbeda.
  • Tidak peduli bagaimana konfigurasi diperbarui, harus dilacak dan diaudit dengan hati-hati.
  • Agar kelangsungan bisnis terjamin, konfigurasi harus dapat diakses secara offline di perangkat tepi.
  • Diperlukan juga bahwa ada tampilan konfigurasi global yang tersedia di cloud.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat memutuskan cara menerapkan pola ini:

  • Mengizinkan pengeditan saat tepi tidak terhubung ke cloud secara signifikan meningkatkan kompleksitas manajemen konfigurasi. Dimungkinkan untuk mereplikasi perubahan pada cloud, tetapi ada tantangan dengan:
    • Autentikasi pengguna, karena bergantung pada layanan cloud seperti ID Microsoft Entra.
    • Resolusi konflik setelah koneksi ulang, jika beban kerja menerima konfigurasi tak terduga yang memerlukan intervensi manual.
  • Lingkungan tepi dapat memiliki batasan terkait jaringan jika topologi mematuhi persyaratan ISA-95. Anda dapat mengatasi batasan tersebut dengan memilih teknologi yang menawarkan konektivitas di seluruh lapisan, seperti hierarki perangkat di Azure IoT Edge.
  • Jika konfigurasi run-time dipisahkan dari rilis perangkat lunak, perubahan konfigurasi perlu ditangani secara terpisah. Untuk menawarkan fitur riwayat dan pemutaran kembali, Anda perlu menyimpan konfigurasi sebelumnya di datastore di cloud.
  • Kesalahan dalam konfigurasi, seperti komponen konektivitas yang dikonfigurasi ke titik akhir yang tidak ada, dapat merusak beban kerja. Oleh karena itu, penting untuk memperlakukan perubahan konfigurasi saat Anda memperlakukan peristiwa siklus hidup penyebaran lainnya dalam solusi pengamatan, sehingga dasbor pengamatan dapat membantu menghubungkan kesalahan sistem dengan perubahan konfigurasi. Untuk informasi selengkapnya tentang pengamatan, lihat Panduan pemantauan cloud: Pengamatan.
  • Pahami peran yang dimainkan datastore cloud dan edge dalam kelangsungan bisnis. Jika datastore cloud adalah sumber kebenaran tunggal, beban kerja edge harus dapat memulihkan status yang dimaksudkan dengan menggunakan proses otomatis.
  • Untuk ketahanan, datastore edge harus bertindak sebagai cache offline. Ini lebih diutamakan daripada pertimbangan latensi.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

  • Ada persyaratan untuk mengonfigurasi beban kerja di luar siklus rilis perangkat lunak.
  • Orang yang berbeda harus dapat membaca dan memperbarui konfigurasi.
  • Konfigurasi harus tersedia meskipun tidak ada koneksi ke cloud.

Contoh beban kerja:

  • Solusi yang terhubung ke aset di lantai toko untuk penyerapan data—OPC Publisher, misalnya—dan perintah dan kontrol
  • Beban kerja pembelajaran mesin untuk pemeliharaan prediktif
  • Beban kerja pembelajaran mesin yang memeriksa secara real time untuk kualitas di lini manufaktur

Contoh

Solusi untuk mengonfigurasi beban kerja edge selama run-time dapat didasarkan pada pengontrol konfigurasi eksternal atau penyedia konfigurasi internal.

Variasi pengontrol konfigurasi eksternal

Diagram arsitektur untuk variasi pengontrol konfigurasi eksternal.

Variasi ini memiliki pengontrol konfigurasi yang berada di luar beban kerja. Peran komponen pengontrol konfigurasi cloud adalah mendorong pengeditan dari datastore cloud ke beban kerja melalui pengontrol konfigurasi edge. Tepi juga berisi datastore sehingga sistem berfungsi bahkan ketika terputus dari cloud.

Dengan IoT Edge, pengontrol konfigurasi edge dapat diimplementasikan sebagai modul, dan konfigurasi dapat diterapkan dengan modul kembar. Modul kembar memiliki batas ukuran; jika konfigurasi melebihi batas, solusi dapat diperluas dengan Azure Blob Storage atau dengan memotong payload yang lebih besar melalui metode langsung.

Manfaat dari variasi ini adalah:

  • Beban kerja itu sendiri tidak perlu menyadari sistem konfigurasi. Kemampuan ini adalah persyaratan jika kode sumber beban kerja tidak dapat diedit—misalnya, saat menggunakan modul dari Marketplace Azure IoT Edge.
  • Dimungkinkan untuk mengubah konfigurasi beberapa beban kerja secara bersamaan dengan mengoordinasikan perubahan melalui pengontrol konfigurasi cloud.
  • Validasi tambahan dapat diimplementasikan sebagai bagian dari alur pendorongan—misalnya, untuk memvalidasi keberadaan titik akhir di tepi sebelum mendorong konfigurasi ke beban kerja.

Variasi konfigurasi penyedia internal

Diagram arsitektur untuk variasi penyedia konfigurasi internal.

Dalam variasi penyedia konfigurasi internal, beban kerja mengambil konfigurasi dari penyedia konfigurasi. Untuk contoh implementasi, lihat Menerapkan penyedia konfigurasi kustom di .NET. Contoh tersebut menggunakan C#, tetapi bahasa lain dapat digunakan.

Dalam variasi ini, beban kerja memiliki pengidentifikasi unik sehingga kode sumber yang sama yang berjalan di lingkungan yang berbeda dapat memiliki konfigurasi yang berbeda. Salah satu cara untuk membangun pengidentifikasi adalah dengan menggabungkan hubungan hierarkis beban kerja ke pengelompokan tingkat atas seperti penyewa. Untuk IoT Edge, itu bisa menjadi kombinasi grup sumber daya Azure, nama hub IoT, nama perangkat IoT Edge, dan pengidentifikasi modul. Nilai-nilai ini bersama-sama membentuk pengidentifikasi unik yang berfungsi sebagai kunci di datastore.

Meskipun versi modul dapat ditambahkan ke pengidentifikasi unik, ini adalah persyaratan umum untuk mempertahankan konfigurasi di seluruh pembaruan perangkat lunak. Jika versi merupakan bagian dari pengidentifikasi, versi lama konfigurasi harus dimigrasikan ke tahap selanjutnya dengan penerapan tambahan.

Manfaat dari variasi ini adalah:

  • Selain datastore, solusi tidak memerlukan komponen, mengurangi kompleksitas.
  • Logika migrasi dari versi lama yang tidak kompatibel dapat ditangani dalam implementasi beban kerja.

Solusi berdasarkan IoT Edge

Diagram arsitektur untuk variasi berbasis Edge IoT.

Komponen cloud dari implementasi referensi IoT Edge terdiri dari hub IoT yang bertindak sebagai pengontrol konfigurasi cloud. Fungsionalitas kembar modul Azure IoT Hub menyebarluaskan perubahan konfigurasi dan informasi tentang konfigurasi yang saat ini diterapkan dengan menggunakan properti yang diinginkan dan dilaporkan kembar modul. Layanan manajemen konfigurasi bertindak sebagai sumber konfigurasi. Ini juga dapat menjadi antarmuka pengguna untuk mengelola konfigurasi, sistem build, dan alat lain yang digunakan untuk menulis konfigurasi beban kerja.

Database Azure Cosmos DB menyimpan semua konfigurasi. Ini dapat berinteraksi dengan beberapa hub IoT, dan menyediakan riwayat konfigurasi.

Setelah perangkat edge menunjukkan melalui properti yang dilaporkan kalau konfigurasi diterapkan, layanan status konfigurasi merekam kejadian dalam instans database.

Saat konfigurasi baru dibuat dalam layanan manajemen konfigurasi, konfigurasi disimpan di Azure Cosmos DB dan properti modul edge yang diinginkan diubah di hub IoT tempat perangkat berada. Konfigurasi kemudian ditransmisikan oleh IoT Hub ke perangkat edge. Modul edge diharapkan untuk menerapkan konfigurasi dan melaporkan status konfigurasi melalui modul kembar. Layanan status konfigurasi kemudian mendengarkan peristiwa perubahan kembar, dan setelah mendeteksi bahwa modul melaporkan perubahan status konfigurasi, merekam perubahan yang sesuai dalam database Azure Cosmos DB.

Komponen edge dapat menggunakan pengontrol konfigurasi eksternal atau penyedia konfigurasi internal. Dalam kedua implementasi, konfigurasi ditransmisikan dalam properti yang diinginkan kembar modul, atau jika konfigurasi besar perlu ditransmisikan, properti yang diinginkan kembar modul berisi URL ke Azure Blob Storage atau ke layanan lain yang dapat digunakan untuk mengambil konfigurasi. Modul kemudian memberi sinyal dalam properti yang dilaporkan oleh kembaran modul apakah konfigurasi baru berhasil diterapkan dan konfigurasi apa yang sedang diterapkan.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah selanjutnya