Jedes Jahr veranstaltet Google das Google Summer of Code-Event, bei dem führende OpenSource-Projekte neue talentierte Entwickler unter den Studenten finden. Im Jahr 2019 gelang es unserem CRIU-Projekt nicht nur, die Qualifikationsrunde zu bestehen, sondern auch mehrere junge Entwickler gleichzeitig anzuziehen. Warum all dies und wie die Arbeit an CRUI im Rahmen von GSoC weiterging - lesen Sie unter der Katze.
Wir bei Virtuozzo haben ein kleines, aber bereits sehr beliebtes Projekt namens CRIU. Dies ist ein ziemlich komplexes Systemdienstprogramm und eine Reihe von Kernel-Patches (die meisten davon wurden übrigens bereits in den Hauptkernelbaum aufgenommen), mit denen Sie beispielsweise die Live-Migration von Containern durchführen oder den Kernel aktualisieren können, ohne Anwendungen neu zu starten.
Wir haben dieses Projekt bereits 2011 gestartet. Und trotz der Tatsache, dass das Dienstprogramm anfangs viele Fragen aufwirft und einige seine Implementierung für unmöglich hielten, entwickelte sich CRIU allmählich zu einem ausgereiften Tool. Bis heute haben es mehr als eineinhalb Hundert Mitarbeiter von mehreren Dutzend Unternehmen, darunter Giganten wie Google und IBM, geschafft, daran teilzunehmen. Trotzdem geht die Suche nach neuen Mitgliedern weiter und dieses Jahr haben wir endlich Google Summer of Code (GSoC) erreicht.
GSoC ist eine von Google gesponserte jährliche Veranstaltung, die darauf abzielt, Studenten für verschiedene OpenSource-Projekte zu gewinnen. Einerseits versuchen Teams aus offenen Projekten, an der Veranstaltung teilzunehmen, andererseits Studenten, die zur Entwicklung der Community beitragen und ihre Professionalität bei realen Projekten unter Beweis stellen möchten.
Um in das GSoC-Team einzutreten, müssen Sie eine Bewerbung mit der Projektbeschreibung, mehreren Themen, an denen die Schüler arbeiten können, und einer Liste sogenannter „Mentoren“ einreichen - aktive Teilnehmer am Projekt, die dem Schüler bei seiner schwierigen Arbeit helfen. Die Studierenden müssen ein oder mehrere Projekte auswählen und ihre Lebensläufe an die Mentoren senden.
In der Mitte des Schuljahres prüft Google die Anwendungen der Teams und wählt die Projekte aus, die teilnehmen werden. Kurz vor den Sommerferien wählen die Teams die Schüler aus, mit denen sie arbeiten möchten. Anschließend führt Google die endgültige Filterung durch und verteilt die Schüler nach den Teams. Im Sommer beginnt die Arbeit, die drei Monate dauert. Einmal alle 30 Tage reichen die Schüler Zwischenberichte ein, und ihre Mentoren bewerten die Ergebnisse und geben Empfehlungen für die Fortsetzung (oder Beendigung) der Arbeit.
Speicheroptimierung und Implementierung von Binärprotokollen
Ich gebe zu, dass 2019 nicht unser erster Versuch war, in die GSoC einzutreten. Bis jetzt konnten wir noch keine Projekte von Google auswählen. Aber wir haben nicht aufgegeben (im Allgemeinen ist es nicht schwierig, einen Antrag einzureichen), und schließlich hat alles geklappt - Google hat die Entwicklung unseres Projekts als wichtig erkannt und CRUI bei GSoC veröffentlicht.
Wir hatten viele Themen für Studenten, eines schöner und komplexer. Eine angenehme Überraschung war die Tatsache, dass es für jeden von ihnen in der Gemeinde Darsteller gab. Es gab Leute, die die geäußerten Probleme kannten und bereit waren, als Mentor zu arbeiten. In der Phase der Studenteneinreichung erhielten wir einen ganzen „Wettbewerb“ - 2 Studenten bewarben sich für jedes der Themen und fast alle hatten wunderbare Eingabedaten. Die endgültige Auswahl ermöglichte es uns, zwei Studenten zu gewinnen, die Themen der Optimierung des Speichererhaltungscodes aus dem laufenden Prozess sowie der Implementierung von Binärprotokollen aufnahmen.
Da CRIU ein System zur Migration von Live-Anwendungen ist, verfügt es über eine solche Betriebsart, wenn der vom Prozess verwendete Speicher parallel zum Prozess selbst gelesen und in Bilddateien geschrieben wird. Wir nennen dies die „lebendige Herzoperation“ des Prozesses, weil er weiterhin funktioniert, ohne anzuhalten. Vor der GSoC-Runde wurde der gesamte Speicher mithilfe des vmsplice-Systemaufrufs, der gleichzeitig Rauschen verursachte, in Pipes gezogen. Anschließend wurde der Prozess weiter ausgeführt, und CRIU speicherte diesen Speicher langsam in Dateien (oder in einen Netzwerkkanal, wenn es sich um eine Live-Migration handelte). Im Prinzip ist dies ein funktionierender Ansatz, aber das Problem bestand darin, dass der in den Pipes befindliche Speicher effektiv gesperrt ist (mlock) und der Kernel ihn bei Bedarf nicht auf die Festplatte entladen kann (Swap-out).
Aus architektonischer Sicht wollten wir die Pipes ersetzen, um den Speicher in kleinen Teilen durch Aufrufen von process_vm_readv zu kopieren. Diese Innovation erschien vor nicht allzu langer Zeit im Linux-Kernel (dieser Aufruf hat übrigens einen Zwillingsbruder namens process_vm_writev). Gleichzeitig können Sie damit beispielsweise die Arbeit des Dienstprogramms strace und der Debugger erheblich vereinfachen und beschleunigen, die im Speicher von Prozessen zum Lösen einiger anderer Aufgaben gespeichert werden können.
Die Arbeit an der Optimierung wurde durch die Tatsache erschwert, dass der Code für die Arbeit mit dem Prozessspeicher einer der zentralen Codes im Dienstprogramm ist und daher absolut zuverlässig sein muss. Jeder Fehler beim Speichern von Seiten kann dazu führen, dass der Prozess einen inkonsistenten Status seiner internen Objekte erhält (von denen CRIU natürlich nichts "weiß") und nach der Wiederherstellung ohne eindeutige Diagnose ausfällt.
Die zweite Schwierigkeit dieser Entwicklung bestand darin, dass die Arbeit mit dem Speicher in fast allen CRIU-Funktionen enthalten ist. Dies sind die üblichen Checkpoint-Wiederherstellungsverfahren. Dies sind die verschiedenen optimierten Versionen, z. B. Pre-Dump oder Lazy-Restore. Einmal in der nächsten Berichtswoche hatten wir sogar vor, den Studenten aus dem Projekt zu „entlassen“, aber zum Glück haben wir dies nicht getan und jetzt haben wir die lang erwartete Optimierung in unserer Entwicklungsbranche.
Die zweite Aufgabe im Rahmen der GSoC 2019 war die Entwicklung und Implementierung der sogenannten Binärprotokolle. Hier ist die Sache: Wenn CRIU ausgeführt wird, schreibt das Dienstprogramm Nachrichten über seine Arbeit in die Datei (oder auf den Bildschirm, aber noch besser in die Datei). Die Bedeutung dieser Beiträge ist enorm! Wenn der Sicherungs- oder Wiederherstellungsvorgang aus irgendeinem Grund nicht mit Erfolg endet, besteht die einzige Möglichkeit, den Grund zu verstehen, darin, jeden Schritt so detailliert wie möglich zu analysieren. Dazu benötigen Sie Informationen zum Dienstprogramm. Im Idealfall erfordern die Verfahren die detailliertesten Protokolle und Bilddateien, falls vorhanden. In der Praxis sind solche Anforderungen schwer zu erfüllen.
Um die detailliertesten Protokolle zu erhalten, bietet CRIU einen geeigneten Modus, den die überwiegende Mehrheit der Benutzer (und möglicherweise sogar alle) immer aktiviert. Die Menge an Informationen, die criu dabei generiert, ist jedoch so groß, dass die Protokollierung selbst die Geschwindigkeit des Systems spürbar beeinflusst. Eine kleine Untersuchung hat gezeigt, dass wir 90% unserer Zeit mit der Protokollierung von Ausgabeformatierungsvorgängen verbringen - das heißt mit den gleichen% d,% 08s,% .2f und anderen Modifikatoren der printf-Funktionsfamilie. Durch Deaktivieren der Protokolle wird die Zeit zum Speichern und Wiederherstellen von Prozessen von 10 auf 30 Prozent reduziert, abhängig von der Größe der Prozesse selbst.
Um die Verwendung einer solchen Menge an Systemressourcen für die Protokollierung zu deaktivieren, die Protokolle jedoch so informativ wie möglich zu gestalten, haben wir beschlossen, die Formatierung zu entfernen und Binärdaten in Protokolldateien zu speichern. Schließlich können Sie sie bei Bedarf später formatieren. Der zweite Student hat diese Aufgabe gemeistert, deren Patches ebenfalls bereits in den Entwicklungszweig aufgenommen wurden.
Und das nicht nur bei GSoC
Eine weitere interessante Tatsache bei der Teilnahme an GSoC ist übrigens, dass ein dritter Student zu uns kam, der den Wunsch äußerte, das Problem der Anonymisierung zu lösen. Schließlich ist es oft unmöglich, Bilddateien abzurufen, da sie geheime Informationen enthalten, die der Benutzer zu Recht nicht an Dritte weitergeben möchte - den Inhalt des Speichers, die Dateien, mit denen der Prozess arbeitet, den Inhalt der Warteschlangen in Netzwerkverbindungen usw. Um dieses Problem zu lösen, haben wir in der Anwendung eine Funktion namens "Anonymisierung von Bildern" eingereicht, die jedoch von Google nicht akzeptiert wurde.
Trotzdem hat das Thema nicht an Relevanz verloren, und der Student, der sich im Rahmen von GSoC damit befassen wollte, entschied sich letztendlich, außerhalb des Google-Events unabhängig an dem Thema zu arbeiten.
Fazit
Es war natürlich eine positive Erfahrung, an GSoC teilzunehmen. Unser CRIU-Tool, das wir lieben und schätzen, hat ein paar stärkere Entwicklungsimpulse erhalten und ist noch ausgereifter und praktischer geworden. Also, für wen es nützlich sein kann, verwenden Sie es gerne!
Andererseits waren wir davon überzeugt, dass die Frage der Teilnahme an solchen Veranstaltungen eine Frage der Beharrlichkeit und des Vertrauens in unser Projekt ist. Wenn Sie Entwickler benötigen, werden Sie nicht müde, Bewerbungen einzureichen und neue, interessante Themen zu formulieren. Möglicherweise finden Sie völlig unerwartete Mitwirkende aus einem anderen Land oder sogar aus einem anderen Unternehmen.