Edge-home-orchestration-go: [WIP] Централизованное управление пограничными устройствами и службами

@suresh-lc @Karthikeyan-Samsung PTAL. Текущий механизм подсчета очков для меня немного неэффективен, потому что кандидаты в отношении краев сами вычисляют свою емкость как оценку и просто отправляют эти результаты мастеру. С другой стороны, мастер может рассчитать эти оценки вместо каждого кандидата на ребро на основе передаваемых ими коэффициентов мощности. Это кажется более подходящим для мастера. Как вы думаете?

Наш нынешний подход не является первично-вторичным. Сведения об устройстве (память/процессор/пропускная способность) обмениваются с другими устройствами во время первоначального обнаружения. Следовательно, когда устройство «А» хочет разгрузить службу, оценка рассчитывается на самом устройстве «А» для всех других устройств (которые были сохранены), и происходит разгрузка. Так что просто для того, чтобы уточнить, что оценка не получена с других устройств, когда запрос на разгрузку службы делается для оркестрации края любым приложением. Следовательно, сделать эту оценку более динамичной (в режиме реального времени) на основе текущей памяти/процессора/пропускной способности было бы хорошей точкой улучшения.

Как указал @t25kim : нужен централизованный подход (мастер).
Ниже приведены некоторые соображения в таком случае:

1. Выбор основного узла
2. Управление сценарием, когда первичный узел выходит из строя, скажем, вторичным главным сценарием, если мы хотим.
3. Любой запрос от устройства A к B должен сначала пройти первичный, чтобы идентифицировать устройство B.

@suresh-lc Дело не в первичной/вторичной топологии. Текущий механизм оценки выглядит следующим образом (по крайней мере, на уровне исходного кода: aka scoringmgr :

1. Каждый кандидат подсчитывает свой балл и выполняет всю необходимую обработку самостоятельно.
2. На самом деле разгрузка требуется, когда пограничный оркестратор решит это сделать, поэтому расчет баллов должен выполняться в этом оркестраторе, а не в самом кандидате.
3. Внушение здесь начинает смотреть этот сценарий.

Если вы видите истинную дезагрегированную топологию, сценарий типа «первичные узлы выходят из строя» должен быть затронут другим делегатом, который заботится только о статусной БД и чем-то в сценарии Home Edge. Я не уверен, что текущий механизм подсчета очков является лучшим вариантом.

Кстати, давайте называть 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 один из членов предложил использовать термин Superior/Inferior вместо Master/Slave. Я сохранил его как ведущий/ведомый для нашего понимания.

Мне нравится идея изменить термин «ведущий/ведомый» на «первичный/вторичный».
Кроме того, я хотел бы предложить термин «черный список/белый список» вместо «черный список/белый список».

Для черного списка: в вызове 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 один из членов предложил использовать термин Superior/Inferior вместо Master/Slave. Я сохранил его как ведущий/ведомый для нашего понимания.

Мне нравится идея изменить термин «ведущий/ведомый» на «первичный/вторичный».
Кроме того, я хотел бы предложить термин «черный список/белый список» вместо «черный список/белый список».

Для черного списка: в вызове TSC было предложено использовать термин «одобренный», как в «Одобренных контейнерах» и так далее.

@suresh-lc Это должен быть TSC от LF Edge. Любое руководство из этого?

@suresh-lc Дело не в топологии master/slave. Текущий механизм оценки выглядит следующим образом (по крайней мере, на уровне исходного кода: aka scoringmgr :

1. Каждый кандидат подсчитывает свой балл и выполняет всю необходимую обработку самостоятельно.
2. На самом деле разгрузка требуется, когда пограничный оркестратор решит это сделать, поэтому расчет баллов должен выполняться в этом оркестраторе, а не в самом кандидате.
3. Внушение здесь начинает смотреть этот сценарий.

Если вы видите истинную дезагрегированную топологию, сценарий типа «главные узлы выходят из строя» должен быть затронут другим делегатом, который заботится только о статусной БД и чем-то в сценарии Home Edge. Я не уверен, что текущий механизм подсчета очков является лучшим вариантом.

Устройство A, B и C — это три устройства, подключенные к одной сети. Все данные об устройстве/службе обмениваются между всеми устройствами вместе с их возможностями вычислений/памяти.

Устройство A: приложение X запрашивает разгрузку службы в Edge-Orchestrator на том же устройстве.
Устройство A: Edge-Orchestrator на устройстве A обнаруживает, что и B, и C имеют службу.
Устройство A: A запрашивает B и C для оценки
Устройство A : на основе оценки A переносит службу на устройство C, у которого оценка выше.
Устройство C: выполняет запрошенную услугу.

Причина такого подсчета очков делает подсчет очков более реальным во времени. Вместо этого, если мы проводим оценку на запрашиваемом устройстве, то значения в реальном времени не могут быть учтены. Во время обнаружения памяти может быть 1 Гб, тогда как при подсчете баллов может быть 512, так как запущен другой процесс. Таким образом, этот тип подсчета очков делает его почти в реальном времени. Вычисление баллов для кандидатов в любом случае рассчитывается Edge Orchestration на этих устройствах.

Мы должны подумать об улучшении механизма подсчета очков, сделав его основанным на большем количестве параметров в реальном времени, а также учитывая большее количество параметров. Можно выполнить даже анализ на основе времени, например, если служба разгружена, но до того, как мы узнаем, что устройство будет занято из-за пользовательского шаблона, такие вещи могут быть включены.

@suresh-lc Я не согласен с вашей идеей о том, что текущий сценарий больше работает в реальном времени, потому что ресурсы не различаются во время получения запроса на каждом крае.
Предположим, что время прибытия запроса к B или C равно T. В текущем сценарии каждое устройство вычисляет и отправляет оценку на основе ресурса в момент времени T. В предлагаемом сценарии каждое устройство отправляет одну и ту же информацию о ресурсе в момент времени T и первично( master) edge вычисляет баллы на основе информации.

Ваше беспокойство важно, но я думаю, что текущая проблема заключается в том, что устройство A не знает, какие преимущества есть у B и C.
Если C значительно не хватает памяти, то A должен выбрать B, даже если C набирает больше баллов, чем B.

@ t25kim : что бы вы ни упоминали, например, совместное использование всей информации об устройстве вместо оценки, делает все сведения о ресурсах устройства общими для другого устройства.

Предположим, что время прибытия запроса к B или C равно T. В текущем сценарии каждое устройство вычисляет и отправляет оценку на основе ресурса в момент времени T. В предлагаемом сценарии каждое устройство отправляет одну и ту же информацию о ресурсе в момент времени T и первично( master) edge вычисляет баллы на основе информации.

Даже при таком подходе ресурс в Т мог быть другим. Но ресурс в Т+1, когда подсчет очков происходит на границе, может быть другим. Таким образом, это также не приведет к фактическому значению оценки. После того, как устройство отправит сведения о ресурсах в Edge, значения ресурсов могут измениться (для B и C), вот что я хочу сказать.

Если C значительно не хватает памяти, то A должен выбрать B, даже если C набирает больше баллов, чем B.

В этом случае, естественно, вычисленная оценка будет меньше, так как оценка также учитывает память. Следовательно, естественно, А выбирает В вместо С.

Следовательно, нет единого надежного подхода. Но для усиления системы можно подумать и о других методах подсчета очков. Мы можем думать о времени эмпирически, а не априорно.

@suresh-lc Хм .. Это интересно, потому что, как вы указали «эмпирический способ», а не «априорный способ», в нем есть контекст, в котором пограничный оркестратор должен принять окончательное решение о наилучшем основном для разгрузки данных сервисов на основе на собранных данных (с историческими паттернами и т. д., и, в конце концов, с использованием AI/ML). Так что для меня текущий механизм, в котором соседние устройства выполняют свои собственные вычисления, немного накладен.

@suresh-lc @t25kim Я думаю, что у @t25kim есть основная идея, чтобы представить свое предложение. Чтобы закончить повторяющиеся обсуждения по этому вопросу, как насчет создания отдельной ветки для проверки осуществимости этого предложения? Есть мнение?

@suresh-lc @t25kim Я думаю, что у @t25kim есть основная идея, чтобы представить свое предложение. Чтобы закончить повторяющиеся обсуждения по этому вопросу, как насчет создания отдельной ветки для проверки осуществимости этого предложения? Есть мнение?

Да, это хороший момент, чтобы сделать осуществимость. Реализация мудрая, должна быть в состоянии сделать. Но для сравнения существующего и нового подходов нам нужно рассчитать метрики, чтобы увидеть, какой метод работает лучше всего.

1. Устройства B и C отправляют оценку A, а затем любой ресурс устройства отключается.
2. Устройства B и C отправляют сведения о ресурсах на A, и ресурс одного устройства отключается.

@suresh-lc @MoonkiHong Это важный вопрос, и я пока не мог придумать, как решить этот сценарий. Есть ли какой-нибудь код на домашнем крае, решающий проблему, когда B или C, отправляющие высокий балл A, резко падают?

Возможно, нам потребуется выяснить какую-либо наземную реализацию/алгоритм для перенастройки основного/дополнительного устройства в данной локальной сети.

Принятие рассмотрения существующего отчета № 26