Cada año, Google organiza el evento Google Summer of Code, donde los principales proyectos OpenSource encuentran nuevos desarrolladores talentosos entre los estudiantes. En 2019, nuestro proyecto CRIU logró no solo pasar la ronda de clasificación, sino también atraer a varios desarrolladores jóvenes a la vez. Acerca de por qué todo esto y cómo se desarrolló el trabajo en CRUI en el marco de GSoC - lea bajo el gato.
En Virtuozzo tenemos un proyecto pequeño pero ya bastante popular llamado CRIU. Esta es una utilidad de sistema bastante compleja y un conjunto de parches de kernel (la mayoría de ellos, por cierto, ya han sido aceptados en el árbol principal del kernel), con los que puede hacer cosas como, por ejemplo, la migración en vivo de contenedores o actualizar el kernel sin reiniciar las aplicaciones.
Comenzamos este proyecto en 2011. Y a pesar de que la utilidad inicialmente causó muchas preguntas, y algunos consideraron que su implementación era imposible, CRIU se convirtió gradualmente en una herramienta madura. Hasta la fecha, más de mil quinientos contribuyentes de varias docenas de compañías, incluidos gigantes como Google e IBM, han logrado participar en él. A pesar de esto, la búsqueda de nuevos miembros continúa, y este año finalmente llegamos a Google Summer of Code (GSoC).
GSoC es un evento anual patrocinado por Google destinado a atraer estudiantes a varios proyectos de código abierto. Por un lado, los equipos de proyectos abiertos buscan participar en el evento y, por otro lado, los estudiantes que desean contribuir al desarrollo de la comunidad y demostrar su profesionalidad en proyectos reales.
Para ingresar al equipo de GSoC, debe enviar una solicitud que especifique la descripción del proyecto, varios temas en los que los estudiantes pueden trabajar y una lista de los llamados "mentores": participantes activos en el proyecto que ayudarán al estudiante en su difícil trabajo. Los estudiantes deben seleccionar uno o más proyectos y enviar sus hojas de vida a los mentores.
A mediados del año escolar, Google considera las aplicaciones de los equipos y selecciona los proyectos que participarán, y más cerca de las vacaciones de verano, los equipos eligen a los estudiantes con los que están listos para trabajar, después de lo cual Google lleva a cabo el filtrado final y los distribuye según los equipos. En verano, comienza el trabajo, que dura tres meses. Una vez cada 30 días, los estudiantes presentan informes provisionales y sus mentores evalúan los resultados y hacen recomendaciones para la continuación (o finalización) del trabajo.
Optimización de memoria e implementación de registros binarios.
Admito que en 2019 no fue nuestro primer intento de ingresar al GSoC. Hasta este momento, no hemos podido pasar por la etapa de selección de proyectos de Google. Pero no nos dimos por vencidos (en general, no es difícil enviar una solicitud) y, finalmente, todo funcionó: Google reconoció el desarrollo de nuestro proyecto como CRUI importante y lanzado en GSoC.
Tuvimos muchos temas para los estudiantes, uno más hermoso y más complejo. Una agradable sorpresa fue el hecho de que para cada uno de ellos en la comunidad había artistas. Había personas que conocían los problemas expresados y estaban listos para trabajar como mentores. En la etapa de presentación de estudiantes, recibimos una “competencia” completa: 2 estudiantes solicitaron cada uno de los temas y casi todos tuvieron datos de entrada maravillosos. La selección final nos permitió obtener dos estudiantes que abordaron temas de optimización del código de preservación de memoria del proceso en curso, así como la implementación de registros binarios.
Dado que CRIU es un sistema de migración de aplicaciones en vivo, tiene tal modo de operación cuando la memoria que utiliza el proceso se lee y se escribe en archivos de imagen en paralelo con el proceso mismo. Llamamos a esto la "operación del corazón vivo" del proceso, porque continúa funcionando sin parar. Antes de la ronda GSoC, toda la memoria se introdujo en las tuberías mediante la llamada al sistema vmsplice, que hizo ruido al mismo tiempo, y luego el proceso continuó ejecutándose, y CRIU volcó lentamente esta memoria en archivos (o en un canal de red si era una migración en vivo). En principio, este es un enfoque funcional, pero el problema era que la memoria ubicada en las tuberías está efectivamente bloqueada (mlock) y el núcleo no puede descargarla al disco (intercambiar) si es necesario.
Desde un punto de vista arquitectónico, queríamos reemplazar las tuberías para copiar la memoria en pequeñas porciones llamando a process_vm_readv. Esta innovación apareció en el kernel de Linux no hace mucho tiempo (por cierto, esta llamada tiene un hermano gemelo llamado process_vm_writev). Pero, al mismo tiempo, le permite facilitar y acelerar enormemente, por ejemplo, el trabajo de la utilidad strace y los depuradores, que se pueden buscar en la memoria de los procesos para resolver otras tareas.
El trabajo de optimización fue complicado por el hecho de que el código para trabajar con la memoria de proceso es uno de los principales en la utilidad y, por lo tanto, debe ser absolutamente confiable. Cualquier error al guardar páginas puede hacer que el proceso reciba un estado inconsistente de sus objetos internos (sobre el cual CRIU, por supuesto, no "sabe" nada) y después de la recuperación, caerá sin ningún diagnóstico claro.
La segunda dificultad de este desarrollo fue que trabajar con memoria está involucrado en casi todas las características de CRIU. Estos son los procedimientos habituales de restauración de puntos de control, estas son sus diversas versiones optimizadas, por ejemplo, pre-dump o lazy-restore. Una vez durante la próxima semana de informes, incluso planeamos "despedir" al estudiante del proyecto, pero, afortunadamente, no lo hicimos y ahora tenemos la optimización tan esperada en nuestra rama de desarrollo.
La segunda tarea dentro del marco de GSoC 2019 fue el desarrollo e implementación de los llamados registros binarios. Aquí está la cosa: cuando CRIU funciona, la utilidad escribe mensajes sobre su trabajo en un archivo (o en la pantalla, pero aún mejor en un archivo). ¡La importancia de estas publicaciones es enorme! Si el procedimiento de copia de seguridad o restauración por alguna razón no termina con éxito, entonces la única forma de entender la razón es analizar cada paso con el mayor detalle posible, y para esto necesita información sobre la utilidad. Idealmente, los procedimientos requieren los registros y archivos de imágenes más detallados, si los hay. En la práctica, tales requisitos son difíciles de satisfacer.
Para obtener los registros más detallados, CRIU proporciona un modo apropiado, y la gran mayoría de los usuarios (y tal vez incluso todos) siempre lo activan. Pero la cantidad de información que genera criu en el proceso es tan grande que el registro en sí comienza a afectar notablemente la velocidad del sistema. Una pequeña investigación ha demostrado que gastamos el 90% de nuestro tiempo en iniciar sesión en operaciones de formateo de salida, es decir, en el "mismo"% d,% 08s,% .2f y otros modificadores de la familia de funciones printf. Apagar los registros reduce el tiempo de guardar y restaurar procesos del 10 al 30 por ciento, dependiendo del tamaño de los procesos mismos.
Para desactivar el uso de tal cantidad de recursos del sistema para el registro, pero para dejar los registros lo más informativos posible, decidimos deshacernos del formateo y guardar los datos binarios en los archivos de registro. Después de todo, puede formatearlos más tarde, si es necesario. El segundo estudiante hizo frente a esta tarea, cuyos parches también han sido aceptados en la rama de desarrollo.
Y no solo en GSoC
Por cierto, otro hecho interesante de participar en GSoC es que un tercer estudiante vino a nosotros y expresó su deseo de resolver el problema del anonimato. Después de todo, a menudo es imposible obtener archivos de imagen debido al hecho de que contienen información secreta que el usuario justamente no desea compartir con nadie: el contenido de la memoria, los archivos con los que trabaja el proceso, el contenido de las colas en las conexiones de red, etc. Para resolver este problema, presentamos una función llamada "anonimato de imágenes" en la aplicación, pero Google no la aceptó.
Sin embargo, el tema no ha perdido su relevancia, y el estudiante que quería tratarlo en el marco de GSoC, al final, decidió trabajar en el tema de forma independiente, fuera del evento de Google.
Conclusión
Fue, por supuesto, una experiencia positiva participar en GSoC. Nuestra herramienta CRIU, que amamos y valoramos mucho, ha recibido un par de impulsos más poderosos para el desarrollo, se ha vuelto aún más madura y conveniente. Entonces, para quien pueda ser útil, úselo con placer.
Por otro lado, estábamos convencidos de que el tema de la participación en tales eventos es una cuestión de perseverancia y confianza en nuestro proyecto. Si necesita desarrolladores, simplemente no se canse de enviar solicitudes y formular nuevos e interesantes temas. Puede encontrar colaboradores completamente inesperados de otro país o incluso de otra compañía.