Bagikan melalui

Pola Konfigurasi Beban Kerja Edge

  • Artikel

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

Konteks dan masalah

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

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, mereka perlu dilacak dan diaudit dengan cermat.
  • Untuk kelangsungan bisnis, diperlukan konfigurasi yang dapat diakses secara offline di edge.
  • Hal ini juga diperlukan bahwa ada tampilan global konfigurasi 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 rekoneksi, jika beban kerja menerima konfigurasi tak terduga yang memerlukan intervensi manual.
  • Lingkungan tepi dapat memiliki kendala terkait jaringan jika topologi sesuai dengan persyaratan ISA-95. Anda dapat mengatasi pembatasan tersebut dengan memilih teknologi yang menawarkan konektivitas lintas lapisan, seperti hierarki perangkat pada Azure IoT Edge.
  • Jika konfigurasi run-time dipisahkan dari rilis perangkat lunak, perubahan konfigurasi perlu ditangani secara terpisah. Untuk menawarkan fitur riwayat dan rollback, Anda perlu menyimpan konfigurasi sebelumnya di toko data 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 observability, sehingga dasbor observability dapat membantu menghubungkan kesalahan sistem dengan perubahan konfigurasi. Untuk informasi selengkapnya mengenai observabilitas, lihat Panduan pemantauan cloud: Observabilitas.
  • Pahami peran yang dimainkan oleh toko data cloud dan edge dalam kelangsungan bisnis. Jika toko data cloud adalah sumber kebenaran tunggal, maka beban kerja edge harus dapat memulihkan keadaan yang dimaksudkan dengan menggunakan proses otomatis.
  • Untuk ketahanan, edge datastore harus bertindak sebagai cache offline. Ini lebih diutamakan daripada pertimbangan latensi.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

  • Ada persyaratan untuk mengkonfigurasi 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 konsumsi data—OPC Publisher, contohnya—serta perintah dan kontrol
  • Beban kerja machine learning untuk pemeliharaan prediktif
  • Beban kerja pembelajaran mesin yang memeriksa secara real-time untuk kualitas pada 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 toko data cloud ke beban kerja melalui pengontrol konfigurasi tepi. Edge juga berisi datastore sehingga fungsi sistem bahkan ketika terputus dari cloud.

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

Manfaat dari variasi ini adalah:

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

Variasi penyedia konfigurasi internal

Diagram arsitektur untuk variasi penyedia konfigurasi internal.

Dalam variasi penyedia konfigurasi internal, beban kerja menarik konfigurasi dari penyedia konfigurasi. Untuk contoh implementasi, lihat Penerapan penyedia konfigurasi kustom di .NET. Contoh itu 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 pengenal adalah dengan menggabungkan hubungan hierarkis beban kerja dengan pengelompokan tingkat atas seperti penyewa. Untuk IoT Edge, ini bisa berupa kombinasi grup sumber daya Azure, nama hub IoT, nama perangkat IoT Edge, dan pengidentifikasi modul. Nilai-nilai ini bersama-sama membentuk pengenal unik yang berfungsi sebagai kunci di penyimpanan data.

Meskipun versi modul dapat ditambahkan ke pengidentifikasi unik, itu adalah persyaratan umum untuk mempertahankan konfigurasi di seluruh pembaruan perangkat lunak. Jika versi adalah bagian dari pengidentifikasi, versi lama konfigurasi harus dimigrasikan ke depan dengan implementasi tambahan.

Manfaat dari variasi ini adalah:

  • Selain penyimpanan data, solusi tidak memerlukan komponen, sehingga 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 I o T Edge.

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

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

Setelah perangkat edge menunjukkan melalui properti yang dilaporkan bahwa konfigurasi diterapkan, layanan status konfigurasi mencatat peristiwa dalam instans database.

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

Komponen edge dapat menggunakan pengontrol konfigurasi eksternal atau penyedia konfigurasi internal. Dalam kedua contoh implementasi tersebut, konfigurasi ditransmisikan dalam modul twin properti yang diinginkan, atau jika konfigurasi besar perlu ditransmisikan, modul twin properti yang diinginkan berisi URL ke Azure Blob Storage atau ke layanan lain yang dapat digunakan untuk mengambil konfigurasi. Modul kemudian memberi sinyal pada modul twin melaporkan properti apakah konfigurasi baru berhasil diterapkan dan konfigurasi apa yang saat ini 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 berikutnya