Edge-home-orchestration-go: [WIP]エッジデバイスとサービスの集中管理

@ suresh-lc @Karthikeyan-SamsungPTAL。 現在のスコアリングメカニズムは私には少し非効率的です。なぜなら、関連するエッジ候補は自分でスコアとして容量を計算し、その結果をマスターに送信するだけだからです。 一方、マスターは、送信された設備利用率に基づいて、各エッジ候補の代わりにそれらのスコアを計算できます。 これはマスターにより適しているようです。 どう思いますか？

私たちの現在のアプローチは、一次二次的なものではありません。 デバイスの詳細（メモリ/ CPU /帯域幅）は、最初の検出中に他のデバイスと交換されます。 したがって、デバイス「A」がサービスをオフロードする場合、スコアリングは他のすべてのデバイス（保存されている）のデバイス「A」自体で計算され、オフロードが発生します。 したがって、サービスのオフロードの要求が任意のアプリケーションによってエッジオーケストレーションに対して行われた場合、スコアリングが他のデバイスから取得されないことを明確にするだけです。 したがって、現在のメモリ/ CPU /帯域幅に基づいてこのスコアリングを動的（リアルタイム）にすることは、改善の良い点です。

@ t25kimが指摘しているように：集中型アプローチ（マスター）が必要です。
このような場合の考慮事項の一部を次に示します。

1. プライマリノードの選択
2. プライマリノードがダウンしたときのシナリオの管理。必要に応じて、セカンダリマスターのようなシナリオを言います。
3. デバイスAからBへのリクエストは、最初にプライマリを通過してデバイスBを識別する必要があります。

@suresh-lcポイントはプライマリ/セカンダリトポロジではありません。現在のスコアリングメカニズムは次のとおりです（少なくともソースコードレベルから：別名scoringmgr ：

1. 各候補者はスコアを計算し、必要なすべての処理を自分で行います。
2. 実際には、エッジオーケストレーターがそうすることを決定したときにオフロードが必要になるため、スコアの計算は、候補者自体ではなく、そのオーケストレーターで行う必要があります。
3. ここでの提案は、そのシナリオを探し始めます。

真の細分化されたトポロジが表示された場合は、「プライマリノードがダウンする」などのシナリオに別のデリゲートがアクセスする必要があります。このデリゲートは、ステータスDBとホームエッジシナリオの何かのみを処理します。 現在のスコアリングメカニズムが最良のオプションであるかどうかはわかりません。

ところで、別の用語master-slaveと呼びましょう。 プライマリ/セカンダリはどうですか？

参照：
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

マスター/スレーブという用語をプライマリ/セカンダリに変更するというアイデアが好きです。
さらに、ブラックリスト/ホワイトリストではなく、ブロックリスト/許可リストという用語を提案したいと思います。

ところで、別の用語master-slaveと呼びましょう。 プライマリ/セカンダリはどうですか？

参照：
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

TSCの1つで、メンバーの1人がマスター/スレーブの代わりに上位/下位の用語を使用することを提案しました。 理解のためにマスター/スレーブとして保管しました。

マスター/スレーブという用語をプライマリ/セカンダリに変更するというアイデアが好きです。
さらに、ブラックリスト/ホワイトリストではなく、ブロックリスト/許可リストという用語を提案したいと思います。

ブラックリストの場合：TSCコールでは、「承認済みコンテナ」などのように「承認済み」という用語を使用することが提案されました。

ところで、別の用語master-slaveと呼びましょう。 プライマリ/セカンダリはどうですか？
参照：
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

TSCの1つで、メンバーの1人がマスター/スレーブの代わりに上位/下位の用語を使用することを提案しました。 理解のためにマスター/スレーブとして保管しました。

マスター/スレーブという用語をプライマリ/セカンダリに変更するというアイデアが好きです。
さらに、ブラックリスト/ホワイトリストではなく、ブロックリスト/許可リストという用語を提案したいと思います。

ブラックリストの場合：TSCコールでは、「承認済みコンテナ」などのように「承認済み」という用語を使用することが提案されました。

@suresh-lcこれはLFEdgeのTSCである必要があります。 それからのガイドラインはありますか？

@ suresh-lcポイントはマスター/スレーブトポロジではありません。現在のスコアリングメカニズムは次のとおりです（少なくともソースコードレベルから：別名scoringmgr ：

1. 各候補者はスコアを計算し、必要なすべての処理を自分で行います。
2. 実際には、エッジオーケストレーターがそうすることを決定したときにオフロードが必要になるため、スコアの計算は、候補者自体ではなく、そのオーケストレーターで行う必要があります。
3. ここでの提案は、そのシナリオを探し始めます。

真の細分化されたトポロジが表示された場合は、「マスターノードがダウンする」などのシナリオに別のデリゲートがアクセスする必要があります。このデリゲートは、ホームエッジシナリオのステータスDBと何かのみを処理します。 現在のスコアリングメカニズムが最良のオプションであるかどうかはわかりません。

デバイスA、B、Cは、同じネットワークに接続された3つのデバイスです。 すべてのデバイス/サービスの詳細は、コンピューティング/メモリ機能とともにすべてのデバイス間で交換されます。

デバイスA：アプリXは、同じデバイスのEdge-Orchestratorにサービスをオフロードするように要求します。
デバイスA：デバイスAのエッジオーケストレーター。BとCの両方にサービスがあることを検出します。
デバイスA：AがBとCにスコアを要求
デバイスA：スコアに基づいて、AはサービスをデバイスCにオフロードします。デバイスCはスコアが高くなっています。
デバイスC：要求されたサービスを実行します。

この方法でスコアリングを行う理由は、スコアリングをよりリアルタイムにします。 代わりに、要求したデバイスでスコアリングを行う場合、リアルタイムの値を取り込むことはできません。 検出中、メモリは1Gbになる可能性がありますが、スコアを計算するときは、他のプロセスが実行されているため、512になる可能性があります。 したがって、このタイプのスコア計算では、ほぼリアルタイムになります。 候補者のスコア計算は、いずれにせよ、それらのデバイスのエッジオーケストレーションによって計算されます。

より多くのリアルタイムパラメータに基づいてスコアリングメカニズムを強化し、より多くのパラメータを考慮することで、スコアリングメカニズムを強化することを検討する必要があります。 サービスがオフロードされている場合など、時間ベースの分析も実行できますが、ユーザーパターンが原因でデバイスがビジーになることが事前にわかっている場合は、そのようなものを組み込むことができます。

@ suresh-lc各エッジでリクエストを受信する時点でリソースに違いがないため、現在のシナリオがよりリアルタイムであるというあなたの考えに同意しません。
リクエストがBまたはCに到着する時刻をTと仮定します。現在のシナリオでは、各デバイスは時刻Tのリソースに基づいてスコアを計算して送信します。提案されたシナリオでは、各デバイスは時刻Tとprimary（ master）edgeは、情報に基づいてスコアを計算します。

あなたの懸念は重要ですが、私が思う現在の問題は、デバイスAがBとCの利点を知らないということです。
Cのメモリが大幅に不足している場合は、CのスコアがBよりも優れていても、AはBを選択する必要があります。

@ t25kim ：スコアの代わりにすべてのデバイス情報を共有するなど、あなたが言及するものはすべて、すべてのデバイスリソースの詳細を他のデバイスと共有します。

リクエストがBまたはCに到着する時刻をTと仮定します。現在のシナリオでは、各デバイスは時刻Tのリソースに基づいてスコアを計算して送信します。提案されたシナリオでは、各デバイスは時刻Tとprimary（ master）edgeは、情報に基づいてスコアを計算します。

このアプローチでも、Tのリソースは異なる可能性があります。 ただし、エッジでスコア計算が行われるT+1のリソースは異なる可能性があります。 したがって、これも実際のスコア値にはつながりません。 デバイスがリソースの詳細をEdgeに送信した後、リソース値が変更される可能性があります（BおよびCの場合）。これが私が言いたいことです。

Cのメモリが大幅に不足している場合は、CのスコアがBよりも優れていても、AはBを選択する必要があります。

この場合、スコアはメモリも考慮に入れるため、当然、計算されたスコアは少なくなります。 したがって、当然、AはCではなくBを選択します。

したがって、単一のばかげた証拠のアプローチはありません。 しかし、システムを強化するために、スコア計算の他の方法を考えることができます。 アプリオリの方法ではなく、時間のような経験的な方法を考えることができます

@ suresh-lcええと..興味深いのは、「アプリオリな方法」ではなく「経験的な方法」を指摘したように、エッジオーケストレーターが特定のサービスに基づいてオフロードするための最良のプライマリの最終決定を行う必要があるというコンテキストがあるためです。収集されたデータ（履歴パターンなどを使用し、最終的にAI / MLを使用）。 したがって、私にとって、隣接デバイスが独自の計算を完了する現在のメカニズムは、少しオーバーヘッドがあります。

@ suresh-lc @ t25kim @t25kimには彼の提案を提示するための基本的なアイデアがあると思います。 この問題に関する繰り返しの議論を終わらせるために、この提案の実現可能性を確認するために別のブランチを作成するのはどうですか？ 何か意見はありますか？

@ suresh-lc @ t25kim @t25kimには彼の提案を提示するための基本的なアイデアがあると思います。 この問題に関する繰り返しの議論を終わらせるために、この提案の実現可能性を確認するために別のブランチを作成するのはどうですか？ 何か意見はありますか？

実現可能性を実現するのは良い点です。 実装に関しては、できるはずです。 ただし、既存のアプローチと新しいアプローチを比較するには、メトリックを計算して、どちらの方法が適切かを確認する必要があります。

1. デバイスBとCがスコアをAに送信すると、いずれか1つのデバイスリソースがダウンします。
2. デバイスBとCはリソースの詳細をAに送信し、1つのデバイスリソースがダウンします。

@ suresh-lc @MoonkiHongこれは重要な問題であり、現時点ではシナリオを解決する方法を考えることができませんでした。 Aにハイスコアを送信しているBまたはCが突然ダウンしたときに問題を解決するホームエッジ上のコードはありますか？

特定のローカルネットワークでプライマリ/セカンダリデバイスを再構成するために、地上の実装/アルゴリズムを見つける必要がある場合があります。

＃26までに既存のレポートで検討事項を受け入れる