Edge-home-orchestration-go: [WIP] 에지 장치 및 서비스의 중앙 집중식 관리

@suresh-lc @Karthikeyan-Samsung PTAL. 현재 점수 매기기 메커니즘은 저에게 약간 비효율적입니다. 관련 에지 후보가 자체적으로 용량을 점수로 계산하고 그 결과를 마스터에게 보내기 때문입니다. 반면에 마스터는 전송된 용량 요소를 기반으로 각 에지 후보 대신 해당 점수를 계산할 수 있습니다. 이것이 주인에게 더 적합한 것 같습니다. 어떻게 생각해?

우리의 현재 접근 방식은 1차-2차 유형이 아닙니다. 장치 세부 정보(메모리/cpu/대역폭)는 초기 검색 중에 다른 장치와 교환됩니다. 따라서 'A' 기기가 서비스를 오프로드하려고 할 때, 다른 모든 기기(저장된) 중 'A' 기기 자체에서 스코어링이 계산되어 오프로딩이 발생합니다. 따라서 모든 애플리케이션에서 에지 오케스트레이션에 대한 서비스 오프로딩 요청이 있을 때 다른 장치에서 점수를 얻지 못한다는 점을 명확히 하기 위한 것입니다. 따라서 현재 메모리/CPU/대역폭을 기반으로 이 점수를 동적(실시간)으로 만드는 것이 좋은 개선점이 될 것입니다.

@t25kim 이 지적한 대로 : 중앙 집중식 접근(마스터)을 원합니다.
다음은 그러한 경우 고려 사항 중 일부입니다.

1. 기본 노드 선택
2. 기본 노드가 다운될 때 시나리오를 관리하고 원하는 경우 보조 마스터 종류의 시나리오를 말합니다.
3. 장치 A에서 B로의 모든 요청은 초기에 기본 장치를 통해 장치 B를 식별해야 합니다.

@suresh-lc 요점은 기본/보조 토폴로지가 아닙니다. 현재 점수 매기기 메커니즘은 다음과 같습니다(최소한 소스 코드 수준에서: scoringmgr aka scoringmgr :

1. 각 후보자는 점수를 계산하고 필요한 모든 처리를 스스로 수행합니다.
2. 실제로 edge-orchestrator가 그렇게 하기로 결정할 때 오프로딩이 필요하므로 점수 계산은 후보 자체가 아닌 해당 오케스트레이터에서 수행되어야 합니다.
3. 제안은 해당 시나리오를 찾기 시작합니다.

실제 분해된 토폴로지가 보이면 "기본 노드가 다운됨"과 같은 시나리오는 상태 DB와 Home Edge 시나리오에서만 처리하는 다른 대리인이 처리해야 합니다. 현재의 점수 매기기 방식이 최선의 선택인지 잘 모르겠습니다.

BTW, 대체 용어로 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

나는 마스터/슬레이브라는 용어를 기본/보조로 변경하는 아이디어를 좋아합니다.
또한 블랙리스트/화이트리스트 대신 차단리스트/허용리스트라는 용어를 제안하고 싶습니다.

BTW, 대체 용어로 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 중 하나에서 구성원 중 한 명이 Master/Slave 대신 Superior/Inferior 용어를 사용하도록 제안했습니다. 나는 우리의 이해를 위해 그것을 마스터/슬레이브로 유지했습니다.

나는 마스터/슬레이브라는 용어를 기본/보조로 변경하는 아이디어를 좋아합니다.
또한 블랙리스트/화이트리스트 대신 차단리스트/허용리스트라는 용어를 제안하고 싶습니다.

블랙리스트의 경우: TSC 호출에서 "승인된 컨테이너"와 같이 "승인된"이라는 용어를 사용하도록 제안되었습니다.

BTW, 대체 용어로 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 중 하나에서 구성원 중 한 명이 Master/Slave 대신 Superior/Inferior 용어를 사용하도록 제안했습니다. 나는 우리의 이해를 위해 그것을 마스터/슬레이브로 유지했습니다.

나는 마스터/슬레이브라는 용어를 기본/보조로 변경하는 아이디어를 좋아합니다.
또한 블랙리스트/화이트리스트 대신 차단리스트/허용리스트라는 용어를 제안하고 싶습니다.

블랙리스트의 경우: TSC 호출에서 "승인된 컨테이너"와 같이 "승인된"이라는 용어를 사용하도록 제안되었습니다.

@suresh-lc LF Edge의 TSC여야 합니다. 그로부터 어떤 지침이 있습니까?

@suresh-lc 요점은 마스터/슬레이브 토폴로지가 아닙니다. 현재 점수 매기기 메커니즘은 다음과 같습니다(적어도 소스 코드 수준에서: scoringmgr aka scoringmgr :

1. 각 후보자는 점수를 계산하고 필요한 모든 처리를 스스로 수행합니다.
2. 실제로 edge-orchestrator가 그렇게 하기로 결정할 때 오프로딩이 필요하므로 점수 계산은 후보 자체가 아닌 해당 오케스트레이터에서 수행되어야 합니다.
3. 제안은 해당 시나리오를 찾기 시작합니다.

실제 분해된 토폴로지가 보이면 "마스터 노드가 다운됨"과 같은 시나리오는 상태 DB와 Home Edge 시나리오에서만 처리하는 다른 대리인에 의해 처리되어야 합니다. 현재의 점수 매기기 방식이 최선의 선택인지 잘 모르겠습니다.

장치 A, B, C는 동일한 네트워크에 연결된 3개의 장치입니다. 모든 장치/서비스 세부 정보는 컴퓨팅/메모리 기능과 함께 모든 장치 간에 교환됩니다.

장치 A: App X는 동일한 장치의 Edge-Orchestrator에 서비스를 오프로드하도록 요청합니다.
장치 A: 장치 A의 Edge-Orchestrator는 B와 C 모두에 서비스가 있음을 찾습니다.
기기 A : A가 B와 C에게 점수를 요청함
장치 A : 점수에 따라 A는 점수가 더 좋은 장치 C에 서비스를 오프로드합니다.
장치 C : 요청한 서비스를 수행합니다.

이런 식으로 채점을 하는 이유는 채점을 보다 실시간으로 만듭니다. 대신 요청한 장치에서 채점을 수행하면 실시간 값을 가져올 수 없습니다. 검색하는 동안 메모리는 1Gb가 될 수 있지만 점수를 계산할 때는 다른 프로세스가 실행 중이므로 512가 될 수 있습니다. 따라서 이러한 유형의 점수 계산은 거의 실시간으로 이루어집니다. 후보자의 점수 계산은 어쨌든 해당 장치의 Edge Orchestration에 의해 계산됩니다.

우리는 더 많은 실시간 매개변수를 기반으로 하고 더 많은 매개변수를 고려하여 스코어링 메커니즘을 향상시키는 것을 생각해야 합니다. 서비스가 오프로드되는 경우와 같이 시간 기반 분석도 수행할 수 있지만 사용자 패턴으로 인해 장치가 바쁠 것이라는 것을 알기 전에 이러한 사항을 통합할 수 있습니다.

@suresh-lc 각 에지에서 요청을 수신할 때 리소스가 다르지 않기 때문에 현재 시나리오가 더 실시간이라는 귀하의 생각에 동의하지 않습니다.
요청이 B 또는 C에 도착한 시간을 T라고 가정합니다. 현재 시나리오에서 각 장치는 시간 T의 리소스를 기반으로 점수를 계산하여 보냅니다. 제안된 시나리오에서 각 장치는 시간 T와 기본( master) edge는 정보를 기반으로 점수를 계산합니다.

당신의 관심은 중요하지만 현재 문제는 장치 A가 B와 C가 가진 장점을 모른다는 것입니다.
C의 메모리가 현저히 부족하면 C가 B보다 점수가 더 높더라도 A는 B를 선택해야 합니다.

@t25kim : 점수가 아닌 모든 기기 정보를 공유하는 것과 같이 언급한 내용은 모든 기기 리소스 세부 정보를 다른 기기와 공유하게 됩니다.

요청이 B 또는 C에 도착한 시간을 T라고 가정합니다. 현재 시나리오에서 각 장치는 시간 T의 리소스를 기반으로 점수를 계산하여 보냅니다. 제안된 시나리오에서 각 장치는 시간 T와 기본( master) edge는 정보를 기반으로 점수를 계산합니다.

이 접근 방식에서도 T의 리소스가 다를 수 있습니다. 그러나 T+1의 리소스는 Edge에서 점수 계산이 발생할 때 다를 수 있습니다. 따라서 이것은 실제 점수 값으로 이어지지 않습니다. 장치가 리소스 세부 정보를 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에 보낸 다음 하나의 장치 리소스가 다운됩니다.
2. 장치 B와 C는 리소스 세부 정보를 A로 보내고 하나의 장치 리소스가 다운됩니다.

@suresh-lc @MoonkiHong 중요한 문제인데 시나리오를 어떻게 풀어야 할지 순간순간 생각이 안 나더라고요. A에게 고득점을 보낸 B나 C가 갑자기 다운될 때 홈 엣지에 문제를 해결하는 코드가 있습니까?

주어진 로컬 네트워크에서 기본/보조 장치를 재구성하기 위해 지상 구현/알고리즘을 찾아야 할 수도 있습니다.

#26의 기존 보고서와 함께 고려 사항 수용