En los últimos años, las noticias se han visto inundadas de mensajes sobre un nuevo tipo de redes informáticas distribuidas que aparecen literalmente de la nada y resuelven (o mejor dicho, intentan resolver) una amplia variedad de problemas: convertir una ciudad en inteligente, salvar al mundo de los derechos de autor. infractores o viceversa, transfiriendo secretamente información o recursos, escapando del control estatal en un área u otra. Independientemente del campo, todos tienen una serie de características comunes debido al hecho de que el combustible para su crecimiento fueron los algoritmos y técnicas que llegaron al público durante el reciente auge de las criptomonedas y tecnologías relacionadas. Probablemente uno de cada tres artículos sobre recursos especializados en ese momento tenía la palabra "blockchain" en el título: la discusión sobre nuevas soluciones de software y modelos económicos se convirtió durante algún tiempo en la tendencia dominante, en cuyo contexto se desarrollaron otras áreas de aplicación de los sistemas informáticos distribuidos. relegado a un segundo plano.
Al mismo tiempo, visionarios y profesionales vieron la esencia principal del fenómeno: la computación distribuida masiva, asociada con la construcción de redes a partir de un gran número de participantes dispares y heterogéneos, ha alcanzado un nuevo nivel de desarrollo. Basta con deshacerse de los temas exagerados de la cabeza y mirar el tema desde el otro lado: todas estas redes, reunidas a partir de enormes grupos, que consisten en miles de participantes heterogéneos aislados, no aparecieron por sí solas. Los entusiastas del movimiento criptográfico pudieron resolver problemas complejos de sincronización de datos y distribución de recursos y tareas de una manera nueva, lo que hizo posible reunir una masa similar de equipos y crear un nuevo ecosistema diseñado para resolver un problema de enfoque limitado.
Por supuesto, esto no pasó desapercibido para los equipos y comunidades involucrados en el desarrollo de la computación distribuida gratuita, y los nuevos proyectos no tardaron en llegar.
Sin embargo, a pesar del aumento significativo en el volumen de información disponible sobre los avances en el campo de la construcción de redes y el trabajo con equipos, los creadores de sistemas prometedores tendrán que resolver problemas serios.
El primero de ellos, por extraño que parezca, es el problema de elegir el rumbo.
La dirección puede ser correcta o puede conducir a un callejón sin salida: no hay escapatoria: el suministro centralizado de clarividentes a la comunidad de TI todavía está retrasado. Pero la elección debe hacerse para no caer en la trampa tradicional de que el equipo abarque un área demasiado amplia e intente crear desde el principio otro proyecto de computación distribuida general no especializado. Parece que el alcance del trabajo no es tan aterrador, en su mayor parte solo necesitamos aplicar los desarrollos existentes: combinar nodos en una red, adaptar algoritmos para determinar topologías, intercambiar datos y monitorear su coherencia, introducir métodos para clasificar nodos y encontrar consenso y, por supuesto, simplemente cree su propio lenguaje de consulta y todo el lenguaje y el entorno informático. La idea de un mecanismo universal es muy tentadora y surge constantemente en un área u otra, pero el resultado final sigue siendo una de tres cosas: la solución creada resulta ser un prototipo limitado con un montón de tareas pendientes. " en el atraso, o se convierte en un monstruo inutilizable, listo para arrastrar a cualquiera que toque el fétido "pantano de Turing", o simplemente muere a salvo porque el cisne, el cangrejo y el lucio, que impulsaban el proyecto en una dirección incomprensible, simplemente se esforzaron demasiado.
No repitamos errores estúpidos y elijamos una dirección que tenga una gama clara de tareas y que se adapte bien al modelo de computación distribuida. Se puede entender a las personas que intentan hacer todo a la vez; por supuesto, hay mucho para elegir. Y muchas cosas parecen extremadamente interesantes tanto desde el punto de vista de la I+D y el desarrollo como desde el punto de vista económico. Usando una red distribuida usted puede:
- Entrenar redes neuronales
- Flujos de señales de proceso
- Calcular la estructura de las proteínas.
- Renderizar escenas XNUMXD
- Simular hidrodinámica
- Pruebe estrategias comerciales para bolsas de valores
Para no dejarnos llevar por la compilación de una lista de cosas interesantes que están bien paralelizadas, elegiremos el renderizado distribuido como nuestro tema adicional.
El renderizado distribuido en sí no es, por supuesto, nada nuevo. Los kits de herramientas de renderizado existentes han soportado durante mucho tiempo la distribución de carga entre diferentes máquinas; sin esto, vivir en el siglo XXI sería bastante triste. Sin embargo, no debe pensar que el tema se ha cubierto ampliamente y que no hay nada que hacer allí; consideraremos un problema urgente por separado: crear una herramienta para crear una red de renderizado.
Nuestra red de renderizado es una combinación de nodos que necesitan realizar tareas de renderizado con nodos que tienen recursos informáticos libres para procesar el renderizado. Los propietarios de recursos conectarán sus estaciones a la red de renderizado para recibir y ejecutar trabajos de renderizado utilizando uno de los motores de renderizado compatibles con la red. En este caso, los proveedores de tareas trabajarán con la red como si fuera una nube, distribuyendo recursos de forma independiente, monitoreando la corrección de la ejecución, gestionando riesgos y otros problemas.
Por lo tanto, consideraremos la creación de un marco que admita la integración con un conjunto de motores de renderizado populares y contenga componentes que proporcionen herramientas para organizar una red de nodos heterogéneos y gestionar el flujo de tareas.
El modelo económico de la existencia de dicha red no es de fundamental importancia, por lo que tomaremos como esquema inicial un esquema similar al utilizado en los cálculos en las redes de criptomonedas: los consumidores del recurso enviarán tokens a los proveedores que realizan el trabajo de renderizado. Es mucho más interesante comprender qué propiedades debe tener un marco, para lo cual consideraremos el escenario principal de interacción entre los participantes de la red.
Hay tres lados de interacción en la red: proveedor de recursos, proveedor de tareas y operador de red (también conocido como centro de control, red, etc. en el texto).
El operador de red proporciona al proveedor de recursos una aplicación cliente o una imagen del sistema operativo con un conjunto de software implementado, que instalará en la máquina cuyos recursos desea proporcionar, y una cuenta personal accesible a través de la interfaz web, que le permite establezca los parámetros de acceso al recurso y administre de forma remota el entorno de su servidor: controle los parámetros del hardware, realice la configuración remota, reinicie.
Cuando se conecta un nuevo nodo, el sistema de gestión de red analiza el equipo y los parámetros de acceso especificados, lo clasifica, le asigna una clasificación determinada y lo coloca en el registro de recursos. En el futuro, para gestionar el riesgo, se analizarán los parámetros de actividad del nodo y se ajustará la calificación del nodo para garantizar la estabilidad de la red. ¿A nadie le agradará que su escena se envíe a renderizar en tarjetas potentes que a menudo se congelan debido al sobrecalentamiento?
Un usuario que necesita renderizar una escena puede hacerlo de dos maneras: cargar la escena en un repositorio de red a través de la interfaz web o usar un complemento para conectar su paquete de modelado o renderizador instalado a la red. En este caso, se inicia un contrato inteligente entre el usuario y la red, cuya condición estándar para su finalización es la generación del resultado del cálculo de la escena por parte de la red. El usuario puede monitorear el proceso de realización de una tarea y administrar sus parámetros a través de la interfaz web de su cuenta personal.
La tarea se envía al servidor, donde se analiza el volumen de la escena y la cantidad de recursos solicitados por el iniciador de la tarea, luego de lo cual el volumen total se descompone en partes adaptadas para calcular la cantidad y el tipo de recursos asignados por la red. . La idea general es que la visualización se puede dividir en muchas tareas pequeñas. Los motores aprovechan esto distribuyendo estas tareas entre múltiples proveedores de recursos. La forma más sencilla es renderizar pequeñas partes de la escena llamadas segmentos. Cuando cada segmento está listo, la tarea local se considera completada y el recurso pasa a la siguiente tarea pendiente.
Por lo tanto, para el renderizador no supone ninguna diferencia si los cálculos se realizan en una sola máquina o en una red de muchas estaciones de cálculo individuales. El renderizado distribuido simplemente agrega más núcleos al conjunto de recursos utilizados para una tarea. A través de la red, recibe todos los datos necesarios para representar un segmento, lo calcula, lo devuelve y pasa a la siguiente tarea. Antes de ingresar al grupo de red general, cada segmento recibe un conjunto de metainformación que permite a los nodos ejecutantes seleccionar las tareas informáticas más adecuadas para ellos.
Los problemas de segmentación y distribución de cálculos deben resolverse no solo desde el punto de vista de la optimización del tiempo de ejecución, sino también desde el punto de vista del uso óptimo de los recursos y el ahorro energético, ya que de ello depende la eficiencia económica de la red. . Si la solución no tiene éxito, sería más recomendable instalar un minero en el nodo o apagarlo para que no haga ruido y no desperdicie electricidad.
Sin embargo, volvamos al proceso. Cuando se recibe una tarea, también se forma un contrato inteligente entre el grupo y el nodo, que se ejecuta cuando el resultado de la tarea se calcula correctamente. Según los resultados del cumplimiento del contrato, el nodo puede recibir una recompensa de una forma u otra.
El centro de control controla el proceso de ejecución de la tarea, recopila los resultados de los cálculos, envía los incorrectos para su reprocesamiento y clasifica la cola, monitorea el plazo estándar para completar la tarea (para que no suceda que el último segmento no sea ocupado por cualquier nodo).
Los resultados de los cálculos pasan por la etapa de composición, después de la cual el usuario recibe los resultados de la renderización y la red puede recibir una recompensa.
Así, surge la composición funcional de un marco paisajístico diseñado para la construcción de sistemas de renderizado distribuido:
- Cuentas de usuario personales con acceso web
- Kit de software para instalación en nodos
- Por sistema de control:
- Subsistema de control de acceso
- Subsistema de descomposición de tareas de renderizado
- Subsistema de distribución de tareas
- Subsistema de composición
- Subsistema de gestión de topología de red y paisaje de servidores
- Subsistema de registro y auditoría
- Subsistema experto en aprendizaje
- API Rest u otra interfaz para desarrolladores externos
¿Qué opinas? ¿Qué preguntas plantea el tema y qué respuestas le interesan?
Fuente: habr.com