Edge-home-orchestration-go: [WIP] Manajemen terpusat dari perangkat dan layanan edge

@suresh-lc @Karthikeyan-Samsung PTAL. Mekanisme penilaian saat ini agak tidak efisien bagi saya, karena kandidat tepi menghitung kapasitas mereka sebagai skor sendiri dan hanya mengirimkan hasilnya ke master. Di sisi lain, master dapat menghitung skor tersebut alih-alih setiap kandidat tepi berdasarkan faktor kapasitas yang ditransmisikan oleh mereka. Ini sepertinya lebih cocok untuk master. Bagaimana menurutmu?

Pendekatan kami saat ini bukanlah jenis primer-sekunder. Detail perangkat (memori/cpu/bandwidth) dipertukarkan dengan perangkat lain selama penemuan awal. Oleh karena itu ketika perangkat 'A' ingin membongkar layanan, penilaian dihitung di perangkat 'A' itu sendiri dari semua perangkat lain (yang telah disimpan) dan pembongkaran terjadi. Jadi hanya untuk memperjelas penilaian tidak didapat dari perangkat lain ketika permintaan untuk layanan offloading dibuat untuk orkestrasi tepi oleh aplikasi apapun. Oleh karena itu membuat penilaian ini lebih dinamis (waktu nyata) berdasarkan memori/CPU/bandwidth saat ini akan menjadi titik perbaikan yang baik.

Seperti yang ditunjukkan oleh @t25kim : menginginkan pendekatan terpusat (Guru).
Berikut adalah beberapa pertimbangan dalam kasus tersebut:

1. Memilih simpul utama
2. Mengelola skenario ketika node utama mati, katakan skenario master sekunder jika kita mau.
3. Setiap permintaan dari Perangkat A ke B , awalnya harus melalui primer untuk mengidentifikasi Perangkat B.

@suresh-lc Intinya bukan topologi primer/sekunder, Mekanisme penilaian saat ini adalah sebagai berikut (setidaknya dari level kode sumber: alias scoringmgr :

1. Setiap kandidat menghitung skornya dan melakukan semua pemrosesan yang diperlukan sendiri.
2. Sebenarnya, pembongkaran diperlukan ketika edge-orchestrator memutuskan untuk melakukannya, jadi penghitungan skor harus dilakukan di orchestrator itu dan bukan pada kandidat itu sendiri.
3. Saran di sini mulai mencari skenario itu.

Jika Anda melihat topologi terpilah yang sebenarnya, skenario seperti "node utama turun" harus disentuh oleh delegasi lain, yang hanya menangani DB status dan sesuatu dalam skenario Home Edge. Saya tidak yakin apakah mekanisme penilaian saat ini adalah pilihan terbaik.

BTW, mari kita sebut master-slave dengan istilah alternatif. Bagaimana dengan Pratama/Menengah?

Referensi:
https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1

Saya suka ide mengubah istilah master/slave menjadi primary/secondary.
Selain itu, saya ingin menyarankan istilah daftar blokir/daftar yang diizinkan alih-alih daftar hitam/daftar putih.

BTW, mari kita sebut master-slave dengan istilah alternatif. Bagaimana dengan Pratama/Menengah?

Referensi:
https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1

Di salah satu TSC, salah satu anggota menyarankan untuk menggunakan istilah Superior/Inferior daripada Master/Slave. Saya menyimpannya sebagai master/slave untuk pemahaman kita.

Saya suka ide mengubah istilah master/slave menjadi primary/secondary.
Selain itu, saya ingin menyarankan istilah daftar blokir/daftar yang diizinkan alih-alih daftar hitam/daftar putih.

Untuk Daftar Hitam: dalam panggilan TSC disarankan untuk menggunakan istilah "disetujui" seperti di "Kontainer yang disetujui" dan seterusnya.

BTW, mari kita sebut master-slave dengan istilah alternatif. Bagaimana dengan Pratama/Menengah?
Referensi:
https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1

Di salah satu TSC, salah satu anggota menyarankan untuk menggunakan istilah Superior/Inferior daripada Master/Slave. Saya menyimpannya sebagai master/slave untuk pemahaman kita.

Saya suka ide mengubah istilah master/slave menjadi primary/secondary.
Selain itu, saya ingin menyarankan istilah daftar blokir/daftar yang diizinkan alih-alih daftar hitam/daftar putih.

Untuk Daftar Hitam: dalam panggilan TSC disarankan untuk menggunakan istilah "disetujui" seperti di "Kontainer yang disetujui" dan seterusnya.

@suresh-lc Itu pasti TSC dari LF Edge. Setiap pedoman dari itu?

@suresh-lc Intinya bukan topologi master/slave, Mekanisme penilaian saat ini adalah sebagai berikut (setidaknya dari level kode sumber: alias scoringmgr :

1. Setiap kandidat menghitung skornya dan melakukan semua pemrosesan yang diperlukan sendiri.
2. Sebenarnya, pembongkaran diperlukan ketika edge-orchestrator memutuskan untuk melakukannya, jadi penghitungan skor harus dilakukan di orchestrator itu dan bukan pada kandidat itu sendiri.
3. Saran di sini mulai mencari skenario itu.

Jika Anda melihat topologi terpilah yang sebenarnya, skenario seperti "node master turun" harus disentuh oleh delegasi lain, yang hanya menangani DB status dan sesuatu dalam skenario Home Edge. Saya tidak yakin apakah mekanisme penilaian saat ini adalah pilihan terbaik.

Perangkat A, B dan C adalah tiga perangkat yang terhubung dalam jaringan yang sama. Semua detail perangkat/layanan dipertukarkan antara semua perangkat bersama dengan kemampuan komputasi/memorinya.

Perangkat A : Aplikasi X meminta untuk membongkar layanan ke Edge-Orchestrator di perangkat yang sama.
Perangkat A : Edge-Orchestrator di perangkat A, menemukan B dan C memiliki layanan.
Perangkat A: A meminta B dan C untuk skor
Perangkat A : Berdasarkan skor , A menurunkan layanan ke perangkat C, yang memiliki skor lebih baik.
Perangkat C : Melakukan layanan yang diminta.

Alasan melakukan penilaian dengan cara ini membuat penilaian lebih real time. Sebaliknya jika kita melakukan penilaian pada perangkat yang diminta, maka nilai waktu nyata tidak dapat diperhitungkan. Saat penemuan, memori bisa menjadi 1Gb, sedangkan saat menghitung skor bisa 512, karena proses lain sedang berjalan. Jadi jenis perhitungan penilaian ini membuatnya mendekati waktu nyata. Perhitungan Skor pada kandidat bagaimanapun juga dihitung oleh Edge Orchestration di perangkat tersebut.

Kita harus berpikir untuk meningkatkan mekanisme penilaian dengan membuatnya berdasarkan lebih banyak parameter waktu nyata dan juga mempertimbangkan lebih banyak parameter. Bahkan analisis berbasis waktu dapat dilakukan, seperti misalnya jika suatu layanan diturunkan bebannya, tetapi sebelum kita mengetahui bahwa perangkat akan menjadi sibuk karena pola pengguna, hal-hal seperti itu dapat digabungkan.

@suresh-lc Saya tidak setuju dengan ide Anda bahwa skenario saat ini lebih real-time karena sumber daya tidak berbeda pada saat menerima permintaan di setiap tepi.
Asumsikan bahwa waktu permintaan tiba ke B atau C adalah T. Dalam skenario saat ini, setiap perangkat menghitung dan mengirimkan skor berdasarkan sumber daya pada waktu T. Dalam skenario yang diusulkan, setiap perangkat mengirimkan informasi sumber daya yang sama pada waktu T dan primer( master) edge menghitung skor berdasarkan informasi.

Kekhawatiran Anda penting tetapi masalah saat ini saya pikir adalah Perangkat A tidak tahu apa kelebihan yang dimiliki B dan C.
Jika C secara signifikan kehabisan memori, maka A harus memilih B bahkan jika skor C lebih baik dari B.

@t25kim : Apa pun yang Anda sebutkan seperti membagikan semua informasi perangkat alih-alih skor membuat semua detail sumber daya perangkat dibagikan ke perangkat lain.

Asumsikan bahwa waktu permintaan tiba ke B atau C adalah T. Dalam skenario saat ini, setiap perangkat menghitung dan mengirimkan skor berdasarkan sumber daya pada waktu T. Dalam skenario yang diusulkan, setiap perangkat mengirimkan informasi sumber daya yang sama pada waktu T dan primer( master) edge menghitung skor berdasarkan informasi.

Bahkan dalam pendekatan ini, sumber daya di T bisa berbeda. Tapi resource di T+1, saat perhitungan skor terjadi di Edge bisa jadi berbeda. Jadi ini juga tidak akan mengarah pada nilai skor yang sebenarnya. Setelah perangkat mengirimkan detail sumber daya ke Edge, nilai sumber daya dapat berubah (untuk B dan C), inilah yang ingin saya katakan.

Jika C secara signifikan kehabisan memori, maka A harus memilih B bahkan jika skor C lebih baik dari B.

Dalam hal ini, tentu saja skor yang dihitung akan lebih sedikit karena skor juga mempertimbangkan memori. Oleh karena itu secara alami A memilih B daripada C.

Oleh karena itu tidak ada pendekatan bukti bodoh tunggal. Tetapi untuk memperkuat sistem kita dapat memikirkan metode penghitungan skor lainnya. Kita bisa memikirkan waktu dengan cara empiris daripada cara Apriori

@suresh-lc Um.. Ini menarik, karena seperti yang Anda tunjukkan "cara empiris" daripada "cara apriori", ini memiliki konteks bahwa orkestra tepi harus membuat keputusan akhir dari primer terbaik untuk membongkar layanan yang diberikan berdasarkan pada data yang dikumpulkan (dengan pola historis dan seterusnya, dan pada akhirnya menggunakan AI/ML). Jadi bagi saya, mekanisme saat ini, di mana perangkat tetangga menyelesaikan perhitungannya sendiri sedikit di atas kepala.

@suresh-lc @t25kim Saya pikir @t25kim memiliki beberapa ide dasar untuk mempresentasikan proposalnya. Untuk mengakhiri diskusi berulang untuk masalah ini, bagaimana dengan membuat cabang terpisah untuk memeriksa kelayakan proposal ini? Ada pendapat?

@suresh-lc @t25kim Saya pikir @t25kim memiliki beberapa ide dasar untuk mempresentasikan proposalnya. Untuk mengakhiri diskusi berulang untuk masalah ini, bagaimana dengan membuat cabang terpisah untuk memeriksa kelayakan proposal ini? Ada pendapat?

Ya poin bagus untuk melakukan kelayakan. Implementasi bijaksana, harus bisa dilakukan. Tetapi untuk membandingkan pendekatan yang ada dan yang baru, kita perlu menghitung metrik untuk melihat metode mana yang cukup baik.

1. Perangkat B dan C mengirim skor ke A dan kemudian salah satu sumber daya perangkat turun.
2. Perangkat B dan C mengirim detail sumber daya ke A dan satu sumber daya perangkat mati.

@suresh-lc @MoonkiHong Itu adalah masalah penting dan saya tidak bisa memikirkan bagaimana menyelesaikan skenario saat ini. Apakah ada kode di home edge yang memecahkan masalah ketika B atau C mengirim skor tinggi ke A turun secara tiba-tiba?

Kami mungkin perlu mencari tahu implementasi/algoritme ground apa pun untuk mengonfigurasi ulang perangkat primer/sekunder di jaringan lokal yang diberikan.

Merangkul pertimbangan dengan laporan yang ada oleh #26