Edge-home-orchestration-go: [WIP] Gerenciamento centralizado de dispositivos e serviços de borda

@suresh-lc @Karthikeyan-Samsung PTAL. O mecanismo de pontuação atual é um pouco ineficiente para mim, porque os candidatos de borda em questão calculam sua capacidade como pontuação por si mesmos e apenas enviam esses resultados para o mestre. Por outro lado, o mestre pode calcular essas pontuações em vez de cada candidato de borda com base nos fatores de capacidade transmitidos por eles. Isso parece mais adequado ao mestre. O que você acha?

Nossa abordagem atual não é do tipo primário-secundário. Os detalhes do dispositivo (memória/cpu/largura de banda) são trocados com outros dispositivos durante a descoberta inicial. Assim, quando um dispositivo 'A' deseja descarregar um serviço, a pontuação é calculada no próprio dispositivo 'A' de todos os outros dispositivos (que foram armazenados) e ocorre o descarregamento. Portanto, apenas para esclarecer, a pontuação não é obtida de outros dispositivos quando a solicitação de descarregamento de serviço é feita para orquestração de borda por qualquer aplicativo. Portanto, tornar essa pontuação mais dinâmica (em tempo real) com base na memória/CPU/largura de banda atual seria um bom ponto de melhoria.

Conforme apontado por @ t25kim : quer uma abordagem centralizada (Mestre).
A seguir estão algumas das considerações nesse caso:

1. Selecionando um nó primário
2. Gerenciando um cenário quando o nó primário fica inativo, digamos, um tipo de cenário mestre secundário, se quisermos.
3. Qualquer solicitação do Dispositivo A para o B precisa passar inicialmente pelo primário para identificar o Dispositivo B.

@suresh-lc O ponto não é a topologia primária/secundária, O mecanismo de pontuação atual é o seguinte (pelo menos no nível do código-fonte: aka scoringmgr :

1. Cada candidato calcula sua pontuação e faz todo o processamento necessário sozinho.
2. Na verdade, o offloading é necessário quando o orquestrador de borda decide fazê-lo, então o cálculo da pontuação deve ser feito nesse orquestrador e não no próprio candidato.
3. Sugestão aqui começa a olhar para esse cenário.

Se você vir a verdadeira topologia desagregada, o cenário como "nós primários ficam inativos" deve ser tocado por outro delegado, que cuida apenas do status DB e algo no cenário Home Edge. Não tenho certeza se o mecanismo de pontuação atual é a melhor opção.

BTW, vamos chamar master-slave por terminologias alternativas. E quanto ao Primário/Secundário?

Referência:
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

Eu gosto da ideia de mudar o termo mestre/escravo para primário/secundário.
Além disso, gostaria de sugerir o termo lista de bloqueio/lista de permissões em vez de lista negra/lista branca.

BTW, vamos chamar master-slave por terminologias alternativas. E quanto ao Primário/Secundário?

Referência:
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

Em um dos TSC, um dos membros sugeriu usar o termo Superior/Inferior ao invés de Mestre/Escravo. Eu o mantive como mestre/escravo para nosso entendimento.

Eu gosto da ideia de mudar o termo mestre/escravo para primário/secundário.
Além disso, gostaria de sugerir o termo lista de bloqueio/lista de permissões em vez de lista negra/lista branca.

Para lista negra: na chamada do TSC foi sugerido o uso do termo "aprovado" como em "contêineres aprovados" e assim.

BTW, vamos chamar master-slave por terminologias alternativas. E quanto ao Primário/Secundário?
Referência:
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

Em um dos TSC, um dos membros sugeriu usar o termo Superior/Inferior ao invés de Mestre/Escravo. Eu o mantive como mestre/escravo para nosso entendimento.

Eu gosto da ideia de mudar o termo mestre/escravo para primário/secundário.
Além disso, gostaria de sugerir o termo lista de bloqueio/lista de permissões em vez de lista negra/lista branca.

Para lista negra: na chamada do TSC foi sugerido o uso do termo "aprovado" como em "contêineres aprovados" e assim.

@suresh-lc Deve ser o TSC do LF Edge. Alguma orientação a partir disso?

@suresh-lc O ponto não é a topologia mestre/escravo, o mecanismo de pontuação atual é o seguinte (pelo menos no nível do código-fonte: aka scoringmgr :

1. Cada candidato calcula sua pontuação e faz todo o processamento necessário sozinho.
2. Na verdade, o offloading é necessário quando o orquestrador de borda decide fazê-lo, então o cálculo da pontuação deve ser feito nesse orquestrador e não no próprio candidato.
3. Sugestão aqui começa a olhar para esse cenário.

Se você vir a verdadeira topologia desagregada, o cenário como "nós mestres desativados" deve ser tocado por outro delegado, que cuida apenas do status DB e algo no cenário Home Edge. Não tenho certeza se o mecanismo de pontuação atual é a melhor opção.

Dispositivo A, B e C são três dispositivos conectados na mesma rede. Todos os detalhes do dispositivo/serviço são trocados entre todos os dispositivos junto com seus recursos de computação/memória.

Dispositivo A: o App X solicita a transferência de um serviço para o Edge-Orchestrator no mesmo dispositivo.
Dispositivo A: Orquestrador de Borda no dispositivo A, descobre que B e C têm o serviço.
Dispositivo A: A solicita B e C para pontuação
Dispositivo A: Com base na pontuação, A descarrega o serviço para o dispositivo C, que teve melhor pontuação.
Dispositivo C : Executa o serviço solicitado.

A razão para fazer a pontuação desta forma faz com que a pontuação seja mais em tempo real. Em vez disso, se fizermos a pontuação no dispositivo que solicitou, os valores em tempo real não poderão ser levados em consideração. Durante a descoberta, a memória pode ser de 1 Gb, enquanto ao calcular a pontuação pode ser de 512, pois outros processos estão em execução. Portanto, esse tipo de cálculo de pontuação o torna quase em tempo real. O cálculo de pontuação em candidatos é calculado de qualquer maneira pela Orquestração de Borda nesses dispositivos.

Devemos pensar em melhorar o mecanismo de pontuação, tornando-o baseado em mais parâmetros em tempo real e também considerando um maior número de parâmetros. Mesmo a análise baseada em tempo pode ser feita, como, digamos, se um serviço for descarregado, mas antes de sabermos que o dispositivo ficaria ocupado devido ao padrão do usuário, essas coisas podem ser incorporadas.

@suresh-lc Discordo da sua ideia de que o cenário atual é mais em tempo real porque os recursos não são diferentes na hora de receber a requisição em cada borda.
Suponha que o momento em que a solicitação chega a B ou C seja T. No cenário atual, cada dispositivo calcula e envia a pontuação com base no recurso no momento T. No cenário proposto, cada dispositivo envia as mesmas informações do recurso no momento T e primário( master) edge calcula pontuações com base nas informações.

Sua preocupação é importante, mas o problema atual é que o dispositivo A não sabe quais vantagens B e C têm.
Se C estiver significativamente sem memória, então A deve escolher B mesmo se C pontuar melhor que B.

@ t25kim : O que quer que você mencione, como compartilhar todas as informações do dispositivo em vez da pontuação, faz com que todos os detalhes dos recursos do dispositivo sejam compartilhados com outro dispositivo.

Suponha que o momento em que a solicitação chega a B ou C seja T. No cenário atual, cada dispositivo calcula e envia a pontuação com base no recurso no momento T. No cenário proposto, cada dispositivo envia as mesmas informações do recurso no momento T e primário( master) edge calcula pontuações com base nas informações.

Mesmo nesta abordagem, o recurso em T pode ser diferente. Mas o recurso em T+1, quando o cálculo do score acontece no Edge, pode ser diferente. Portanto, isso também não levará ao valor real da pontuação. Depois que o dispositivo envia os detalhes do recurso para o Edge, os valores do recurso podem mudar (para B e C), é isso que quero dizer.

Se C estiver significativamente sem memória, então A deve escolher B mesmo se C pontuar melhor que B.

Nesse caso, naturalmente a pontuação calculada seria menor, pois a pontuação também leva em consideração a memória. Portanto, naturalmente A escolhe B em vez de C.

Portanto, não existe uma única abordagem à prova de tolos. Mas para fortalecer o sistema podemos pensar em outros métodos de cálculo de pontuação. Podemos pensar no tempo de forma empírica em vez de forma a priori

@suresh-lc Um .. É interessante, porque como você apontou "maneira empírica" ​​em vez de "maneira a priori", tem um contexto em que o orquestrador de borda deve tomar uma decisão final do melhor primário para descarregar os serviços fornecidos com base nos dados coletados (com padrões históricos e assim por diante, e no final empregando o AI/ML). Então, para mim, o mecanismo atual, no qual os dispositivos vizinhos completam seu próprio cálculo, é um pouco sobrecarregado.

@suresh-lc @t25kim Acho que @t25kim tem alguma ideia básica para apresentar sua proposta. Para encerrar as discussões iterativas sobre esse assunto, que tal criar uma ramificação separada para verificar a viabilidade dessa proposta? Alguma opinião?

@suresh-lc @t25kim Acho que @t25kim tem alguma ideia básica para apresentar sua proposta. Para encerrar as discussões iterativas sobre esse assunto, que tal criar uma ramificação separada para verificar a viabilidade dessa proposta? Alguma opinião?

Ya seu bom ponto para fazer uma viabilidade. Implementação sábia, deve ser capaz de fazer. Mas para comparar a abordagem existente e a nova, precisamos calcular as métricas para ver qual método é justo.

1. Os dispositivos B e C enviam pontuação para A e, em seguida, qualquer recurso de dispositivo fica inativo.
2. Os dispositivos B e C enviam detalhes do recurso para A e um recurso do dispositivo fica inativo.

@suresh-lc @MoonkiHong Essa é uma questão importante e eu não conseguia pensar em como resolver o cenário no momento. Existe algum código na borda inicial resolvendo o problema quando B ou C enviando pontuação alta para A cai abruptamente?

Podemos precisar descobrir qualquer implementação/algoritmo de solo para reconfigurar o dispositivo primário/secundário na rede local fornecida.

Abraçando a consideração com o relatório existente de #26