Edge-home-orchestration-go: [WIP] Gestión centralizada de dispositivos y servicios perimetrales

@suresh-lc @Karthikeyan-Samsung PTAL. El mecanismo de puntuación actual es un poco ineficiente para mí, porque los candidatos de vanguardia calculan su capacidad como puntuación por sí mismos y simplemente envían los resultados al maestro. Por otro lado, el maestro puede calcular esos puntajes en lugar de cada candidato de borde en función de los factores de capacidad transmitidos por ellos. Esto parece más apropiado para el maestro. ¿Qué piensas?

Nuestro enfoque actual no es del tipo primaria-secundaria. Los detalles del dispositivo (memoria/cpu/ancho de banda) se intercambian con otros dispositivos durante el descubrimiento inicial. Por lo tanto, cuando un dispositivo 'A' quiere descargar un servicio, la puntuación se calcula en el propio dispositivo 'A' de todos los demás dispositivos (que se han almacenado) y se produce la descarga. Entonces, solo para aclarar, la puntuación no se obtiene de otros dispositivos cuando cualquier aplicación realiza una solicitud de descarga de servicio para orquestación de borde. Por lo tanto, hacer que esta puntuación sea más dinámica (en tiempo real) basada en la memoria/CPU/ancho de banda actual sería un buen punto de mejora.

Como señaló @ t25kim : quiere un enfoque centralizado (Maestro).
Las siguientes son algunas de las consideraciones en tal caso:

1. Selección de un nodo principal
2. Administrar un escenario cuando el nodo principal se cae, digamos un tipo de escenario maestro secundario si quisiéramos.
3. Cualquier solicitud del Dispositivo A al B, debe pasar inicialmente por el primario para identificar el Dispositivo B.

@suresh-lc El punto no es la topología primaria/secundaria. El mecanismo de puntuación actual es el siguiente (al menos desde el nivel del código fuente: también conocido como scoringmgr :

1. Cada candidato calcula su puntaje y realiza todo el procesamiento requerido por sí mismo.
2. En realidad, la descarga se requiere cuando el orquestador de borde decide hacerlo, por lo que el cálculo de la puntuación debe realizarse en ese orquestador en lugar del propio candidato.
3. La sugerencia aquí comienza a buscar ese escenario.

Si ve la verdadera topología desagregada, otro delegado debe tocar el escenario como "los nodos principales se desactivan", que solo se ocupa de la base de datos de estado y algo en el escenario de Home Edge. No estoy seguro de si el mecanismo de puntuación actual es la mejor opción.

Por cierto, llamemos master-slave con terminologías alternativas. ¿Qué pasa con Primaria/Secundaria?

Referencia:
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

Me gusta la idea de cambiar el término maestro/esclavo a primario/secundario.
Además, me gustaría sugerir el término lista bloqueada/lista permitida en lugar de lista negra/lista blanca.

Por cierto, llamemos master-slave con terminologías alternativas. ¿Qué pasa con Primaria/Secundaria?

Referencia:
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

En uno de los TSC, uno de los miembros sugirió usar el término Superior/Inferior en lugar de Maestro/Esclavo. Lo guardé como amo/esclavo para nuestro entendimiento.

Me gusta la idea de cambiar el término maestro/esclavo a primario/secundario.
Además, me gustaría sugerir el término lista bloqueada/lista permitida en lugar de lista negra/lista blanca.

Para Blacklist: en la convocatoria de TSC se sugirió utilizar el término "aprobado" como en "Contenedores aprobados" y así.

Por cierto, llamemos master-slave con terminologías alternativas. ¿Qué pasa con Primaria/Secundaria?
Referencia:
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

En uno de los TSC, uno de los miembros sugirió usar el término Superior/Inferior en lugar de Maestro/Esclavo. Lo guardé como amo/esclavo para nuestro entendimiento.

Me gusta la idea de cambiar el término maestro/esclavo a primario/secundario.
Además, me gustaría sugerir el término lista bloqueada/lista permitida en lugar de lista negra/lista blanca.

Para Blacklist: en la convocatoria de TSC se sugirió utilizar el término "aprobado" como en "Contenedores aprobados" y así.

@suresh-lc Debe ser el TSC de LF Edge. ¿Alguna pauta a partir de eso?

@suresh-lc El punto no es la topología maestro/esclavo. El mecanismo de puntuación actual es el siguiente (al menos desde el nivel del código fuente: también conocido como scoringmgr :

1. Cada candidato calcula su puntaje y realiza todo el procesamiento requerido por sí mismo.
2. En realidad, la descarga se requiere cuando el orquestador de borde decide hacerlo, por lo que el cálculo de la puntuación debe realizarse en ese orquestador en lugar del propio candidato.
3. La sugerencia aquí comienza a buscar ese escenario.

Si ve la verdadera topología desagregada, otro delegado debe tocar el escenario como "los nodos maestros fallan", que solo se ocupa del estado de la base de datos y algo en el escenario de Home Edge. No estoy seguro de si el mecanismo de puntuación actual es la mejor opción.

Los dispositivos A, B y C son tres dispositivos conectados en la misma red. Todos los detalles del dispositivo/servicio se intercambian entre todos los dispositivos junto con sus capacidades de cómputo/memoria.

Dispositivo A: la aplicación X solicita descargar un servicio a Edge-Orchestrator en el mismo dispositivo.
Dispositivo A: Edge-Orchestrator en el dispositivo A, encuentra que tanto B como C tienen el servicio.
Dispositivo A: A solicita B y C para la puntuación
Dispositivo A: según la puntuación, A descarga el servicio al dispositivo C, que obtuvo una mejor puntuación.
Dispositivo C: Realiza el servicio solicitado.

La razón de hacer la puntuación de esta manera hace que la puntuación sea más en tiempo real. En cambio, si hacemos una puntuación en el dispositivo que lo solicitó, entonces no se pueden tener en cuenta los valores en tiempo real. Durante el descubrimiento, la memoria podría ser de 1 Gb, mientras que al calcular la puntuación podría ser de 512, ya que se están ejecutando otros procesos. Entonces, este tipo de cálculo de puntaje lo hace casi en tiempo real. De todos modos, Edge Orchestration calcula el cálculo de la puntuación en los candidatos en esos dispositivos.

Deberíamos pensar en mejorar el mecanismo de puntuación haciéndolo basado en más parámetros en tiempo real y también considerando una mayor cantidad de parámetros. Incluso se puede realizar un análisis basado en el tiempo, por ejemplo, si se descarga un servicio, pero antes de que sepamos que el dispositivo estaría ocupado debido al patrón del usuario, se pueden incorporar tales cosas.

@suresh-lc No estoy de acuerdo con su idea de que el escenario actual es más en tiempo real porque los recursos no son diferentes al momento de recibir la solicitud en cada borde.
Suponga que el momento en que llega la solicitud a B o C es T. En el escenario actual, cada dispositivo calcula y envía la puntuación en función del recurso en el momento T. En el escenario propuesto, cada dispositivo envía la misma información de recursos en el momento T y primario( master) edge calcula las puntuaciones en función de la información.

Su preocupación es importante, pero creo que el problema actual es que el Dispositivo A no sabe qué ventajas tienen B y C.
Si C está significativamente fuera de la memoria, entonces A debería elegir B ​​incluso si C obtiene mejores resultados que B.

@t25kim : Cualquier cosa que mencione, como compartir toda la información del dispositivo en lugar de la puntuación, hace que todos los detalles de los recursos del dispositivo se compartan con otro dispositivo.

Suponga que el momento en que llega la solicitud a B o C es T. En el escenario actual, cada dispositivo calcula y envía la puntuación en función del recurso en el momento T. En el escenario propuesto, cada dispositivo envía la misma información de recursos en el momento T y primario( master) edge calcula las puntuaciones en función de la información.

Incluso en este enfoque, el recurso en T podría ser diferente. Pero el recurso en T+1, cuando el cálculo de la puntuación ocurre en Edge, podría ser diferente. Por lo tanto, esto tampoco conducirá al valor de puntuación real. Después de que el dispositivo envíe los detalles del recurso a Edge, los valores del recurso pueden cambiar (para B y C), esto es lo que quiero decir.

Si C está significativamente fuera de la memoria, entonces A debería elegir B ​​incluso si C obtiene mejores resultados que B.

En este caso, naturalmente, la puntuación calculada sería menor, ya que la puntuación también tiene en cuenta la memoria. Por lo tanto, naturalmente, A elige B en lugar de C.

Por lo tanto, no existe un único enfoque infalible. Pero para reforzar el sistema podemos pensar en otros métodos de cálculo de puntuación. Podemos pensar en el tiempo de una forma empírica en lugar de una forma a priori.

@suresh-lc Um.. Es interesante, porque como señaló "forma empírica" ​​en lugar de "forma a priori", tiene un contexto en el que el orquestador de borde debe tomar una decisión final sobre la mejor primaria para descargar los servicios dados basados en los datos recopilados (con patrones históricos, etc., y al final empleando AI/ML). Entonces, para mí, el mecanismo actual, en el que los dispositivos vecinos completan su propio cálculo, es un poco complicado.

@suresh-lc @t25kim Creo que @t25kim tiene una idea básica para presentar su propuesta. Para finalizar las discusiones iterativas sobre este asunto, ¿qué hay de crear una rama separada para verificar la viabilidad de esta propuesta? ¿Alguna opinión?

@suresh-lc @t25kim Creo que @t25kim tiene una idea básica para presentar su propuesta. Para finalizar las discusiones iterativas sobre este asunto, ¿qué hay de crear una rama separada para verificar la viabilidad de esta propuesta? ¿Alguna opinión?

Ya es un buen punto para hacer una viabilidad. En cuanto a la implementación, debería poder hacerlo. Pero para comparar el enfoque existente y el nuevo, necesitamos calcular métricas para ver qué método funciona bien.

1. Los dispositivos B y C envían la puntuación a A y luego cualquier recurso del dispositivo deja de funcionar.
2. Los dispositivos B y C envían detalles del recurso a A y un recurso del dispositivo deja de funcionar.

@suresh-lc @MoonkiHong Ese es un tema importante y no podía pensar en cómo resolver el escenario en este momento. ¿Hay algún código en el borde de la casa que resuelva el problema cuando B o C envían una puntuación alta a A y se cae abruptamente?

Es posible que necesitemos encontrar alguna implementación/algoritmo de tierra para reconfigurar el dispositivo primario/secundario en la red local dada.

Aceptando la consideración con el informe existente por #26