Performance-Analyse der Echtzeitf\u00e4higkeiten von Linux-basierten Container-L\u00f6sungen auf ARM<\/p>\n
Autor: Michael Schnelle, Mixed Mode<\/p>\n
Als Echtzeitsystem bezeichnet man im Allgemeinen ein System, das auf ein Ereignis innerhalb einer endlichen und vorhersagbaren Zeitspanne reagieren muss. Solche Systeme stellen folglich nicht nur logische, sondern auch zeitliche Anforderungen an ein Ergebnis. Echtzeit bedeutet dabei nicht unbedingt schnelles Handeln, sondern das Einhalten der gesetzten Zeitschranken und deterministisches Verhalten. Echtzeitsysteme werden dabei in zwei Kategorien eingeteilt: weiche und harte Echtzeitsysteme.<\/p>\n
Siehe Abb. 1 (PDF<\/a>).<\/p>\n Bei einem weichen Echtzeitsystem d\u00fcrfen die gesetzten Zeitschranken verletzt werden. Dennoch hat das gelieferte Ergebnis eine Bedeutung f\u00fcr das System. Hierbei h\u00e4ngt es vom Anwendungsfall ab, inwieweit der Nutzen des Ergebnisses unter dem versp\u00e4teten Auftreten leidet. Bei harter Echtzeit wiederum m\u00fcssen die gesetzten Zeitschranken zu jedem Zeitpunkt eingehalten werden. Wird diese Regel verletzt, hat das Ergebnis keinen Wert f\u00fcr das System.<\/p>\n Linux wurde urspr\u00fcnglich nicht f\u00fcr den Einsatz als Echtzeit- oder Embedded Betriebssystem entwickelt, doch machte die breite Hardwareunterst\u00fctzung Linux sehr bald f\u00fcr beide Bereiche interessant. Die ersten Ans\u00e4tze Linux echtzeitf\u00e4hig zu machen, sahen dabei eine Dual-Kernel-Architektur vor.\u00a0 Bei diesen L\u00f6sungen wird zus\u00e4tzlich ein kleiner Echtzeitkernel auf dem System betrieben.\u00a0 Dieser Kernel f\u00fchrt Linux als einen niedrig priorisierten Prozess aus. Bekannte L\u00f6sungen solcher Ans\u00e4tze sind RTAI und Xenomai.<\/p>\n Dar\u00fcber hinaus ist Linux mittlerweile sogar in der Standardausf\u00fchrung bereits f\u00fcr weiche Echtzeitsysteme geeignet. Diese Tatsache geht auf die Entwicklung des Preempt-RT-Patches zur\u00fcck, der den Linux-Kernel selbst hart echtzeitf\u00e4hig macht. Aktuell arbeiten die Entwickler daran, den Patch vollst\u00e4ndig in den Mainline-Kernel zu integrieren. Der Patch konzentriert sich vor allem darauf, den Linux-Kernel vollst\u00e4ndig unterbrechbar zu gestalten, weil dies ein wichtiges Konzept f\u00fcr Echtzeitbetriebssysteme ist.<\/p>\n Der Standard-Kernel unterst\u00fctzt aktuell drei Unterbrechungs-Modelle:<\/p>\n No Forced Preemption (Server), bei dem ein Task nur bei R\u00fcckkehr aus einem Systemaufruf oder bei einem Interrupt unterbrochen werden kann. Voluntary Kernel Preemption (Desktop), bei dem noch zus\u00e4tzliche Unterbrechungspunkte eingef\u00fchrt wurden. Oder Preemptible kernel (Low-Latency-Desktop), bei dem der Kernel jederzeit unterbrochen werden kann, au\u00dfer er befindet sich in einem kritischen Bereich.<\/p>\n Der Preempt-RT-Patch f\u00fchrt zwei weitere Unterbrechungspunkte ein: Preemptible Kernel (Basic-RT) und Fully Preemptible (RT). Letzterer gestaltet den Linux-Kernel schlie\u00dflich bis auf einige wenige kritische Abschnitte vollst\u00e4ndig unterbrechbar. Hierzu werden Mechanismen wie sleeping Spinlocks und rt_mutexes eingesetzt. Au\u00dferdem werden Interrupt Routinen als Threaded Interrupts ausgef\u00fchrt, die es erm\u00f6glichen, dass ein h\u00f6her priorisierter Userspace-Prozess eine ISR unterbrechen kann.<\/p>\n Im Rahmen der Container-Virtualisierung wird f\u00e4lschlicherweise oftmals von leichtgewichtigeren virtuellen Maschinen gesprochen, obgleich die grundlegenden Techniken g\u00e4nzlich verschieden sind:<\/p>\n Bei der Vollvirtualisierung kommt eine Softwarekomponente zum Einsatz, um die logische Schicht zwischen dem Gastsystem und der Hardware zu bilden. Diese Softwarekomponente wird Hypervisor oder Virtual Machine Monitor genannt.\u00a0 In der Praxis unterscheidet man \u00a0Type-1- und Type-2 Hypervisor.\u00a0(Mandl, 2014)<\/p>\n Ein Type-1-Hypervisor arbeitet direkt auf der Hardware des Systems und agiert als minimales Betriebssystem, das f\u00fcr das Erstellen und Verwalten der einzelnen virtuellen Maschinen zust\u00e4ndig ist. Der Hypervisor ben\u00f6tigt somit Treiber f\u00fcr den Hardwarezugriff. Der Type-2-Hypervisor wird innerhalb eines Betriebssystems als Anwendungsprogramm ausgef\u00fchrt. Der Zugriff auf die Hardware erfolgt dabei \u00fcber die Treiber des Hostsystems.<\/p>\n Bei der Container-Virtualisierung (Betriebssystemvirtualisierung) werden Prozesse allein auf Betriebssystemebene isoliert. Dazu erstellt der Kernel des Host-Systems virtuelle Prozessr\u00e4ume, in denen die Prozesse ablaufen k\u00f6nnen. Die isolierten Prozesse bekommen den Eindruck, dass ihnen eine komplette Rechnerumgebung zur Verf\u00fcgung steht, obwohl sie in Wirklichkeit isolierte User-Space-Instanzen eines darunterliegenden Betriebssystems sind. Der Vorteil besteht darin, dass durch die gemeinsame Nutzung eines Kernels kein gro\u00dfer Performance-Einbruch zu erwarten ist. Gleichzeitig ergibt sich dadurch aber der Nachteil, dass alle isolierten Instanzen auf dem Kernel des Hostsystems angewiesen sind und deshalb keine unterschiedlichen Betriebssysteme betrieben werden k\u00f6nnen. (C. Arnold, 2012)<\/p>\n Der Linux-Kernel selbst stellt mehrere Mechanismen zur Betriebssystemvirtualisierung dar. Durch die Verwendung von Prozessb\u00e4umen k\u00f6nnen Prozesse gegenseitig abgeschottet werden. Die Container-Virtualisierung macht sich dieses Prinzip zu nutzen, um einzelne Container anzulegen.<\/p>\n Container-L\u00f6sungen benutzen diesen Mechanismus z.B. f\u00fcr die folgenden System-Ressourcen:<\/p>\n Mit control groups (cgroups) bietet der Linux-Kernel einen Mechanismus, Prozessen oder Containern nur einen Bruchteil bestimmter Ressourcen zuzuteilen. Prozesse werden hierbei verschiedenen Kontrollgruppen zugeteilt, deren Zugriff auf Systemressourcen limitiert werden kann.<\/p>\n Das Konzept von isolierten Prozessinstanzen unter Linux gibt es schon seit 2001. Praktikabel wurde es erst die die Einf\u00fchrung der vorgestellten Kernel Features cgroups und namespaces. Die erste Implementierung die diese Mechanismen verwendete war LXC (Linux Container). Eine weitere Implementierung stellt Docker dar.<\/p>\n Docker verwendet eine Server-Client-Architektur, bestehen aus dem Docker Client und dem Docker Daemon. Der\u00a0 Benutzer interagiert bei der Erstellung von Containern mit dem Docker Client, welcher Befehle an den Docker Daemon weiterreicht. Dieser \u00fcbernimmt anschlie\u00dfend alle weiteren Aufgaben, wie die Verwaltung der Systemabbilder (Docker Images) und das Anlegen von Docker Containern. Client und Daemon m\u00fcssen nicht zwangsl\u00e4ufig auf demselben System laufen. Docker setzte anfangs auf externe Containerl\u00f6sungen wie libvirt oder LXC, um mit dem Linux-Kernel zu interagieren. Ab Version 0.9 wurde diese Funktion durch eine eigene Implementierung ersetzt. Das virtualisierte Betriebssystem wird in einem Image zusammengefasst, welches entweder in einer privaten oder \u00f6ffentlichen Registry gespeichert und verwaltet werden kann. Ein laufendes Image nennt man einen Container.<\/p>\n Als Hardware-Grundlage wurde BeagleBone Black mit einem Sitara AM335x Cortex-A der Firma Texas Instruments verwendet. Auf dieser Basis soll die Echtzeitf\u00e4higkeit der Container-L\u00f6sungen Docker und LXC \u00fcberpr\u00fcft werden. Hierzu wurden verschiedene Testszenarien ausgew\u00e4hlt:<\/p>\n Cyclictest ist ein Programm, das h\u00e4ufig im Zusammenhang mit dem Preempt-RT Patch genannt wird.\u00a0 Es wurde im Rahmen der Entwicklung des Patches geschrieben und kann dazu verwendet werden, die Echtzeitf\u00e4higkeit eines Systems einzusch\u00e4tzen. Hierzu erstellt das Programm einen Thread, der die aktuelle Systemzeit misst und sich anschlie\u00dfend f\u00fcr ein definiertes Zeitintervall schlafen legt. Sobald der so gestellte Timer abgelaufen ist und der Thread wieder vom Scheduler ausgew\u00e4hlt wird, nimmt der Thread wieder die Systemzeit und kann aus den gemessenen Zeiten einen Wert f\u00fcr die Scheduling-Latenz berechnen.<\/p>\n Siehe Abb. 2 (PDF<\/a>).<\/p>\n Das Programm wird auch von OSADL eingesetzt, um die Echtzeitf\u00e4higkeit des Preempt-RT Patches zu testen. \u00a0Das Ergebnis wird in Form eines Histogramms ausgegeben. Zus\u00e4tzliche Informationen sind die minimale, durchschnittliche und auch die maximale Latenz. Unten stehend sind exemplarisch die Histogramme f\u00fcr zwei BeagleBone Blacks aus der „OSADL Testfarm“ dargestellt. Dabei ist das linke mit dem Preempt-RT Patch ausgestattet und das rechte mit einem Standard-Kernel.<\/p>\n Siehe Abb. 3 (PDF<\/a>).<\/p>\n Bei einer zweiten Echtzeitanwendung, der Interrupt-Stoppuhr, soll die Messung f\u00fcr die Echtzeitf\u00e4higkeit nicht wie bei cyclictest direkt auf dem Testsystem, sondern \u00fcber eine externe Messeinrichtung stattfinden. Die Grundidee dabei ist das Nachstellen einer oft anzutreffenden Situation, in der ein Echtzeitsystem in einem definierten Zeitrahmen auf ein externes Signal reagieren muss. Die Verarbeitung und Reaktion auf das externe Signal soll dabei in einer User-Space-Anwendung erfolgen, die man einmal nativ und einmal innerhalb der Container-L\u00f6sung betreibt.<\/p>\n Konkreter definiert soll mit einem Mikrocontroller ein externes Triggersignal erzeugt werden, dass im Linux-Kernel eine Interrupt-Service-Routine ausl\u00f6st, die einen GPIO-Pin auf high setzt und anschlie\u00dfend die Echtzeitanwendung im User-Space aufweckt. Diese Anwendung soll dann den entsprechenden GPIO-Pin wieder auf low setzen. Der geplante Signalverlauf von der Anregung bis zur Antwort ist unten stehend skizziert.<\/p>\n Siehe Abb. 4 (PDF<\/a>).<\/p>\n Die Zeitspanne I steht dabei jeweils f\u00fcr die Interrupt-Latenz also der Zeit zwischen dem Ausl\u00f6sen des Triggersignals und dem Beginn der entsprechenden ISR auf dem Testsystem. Die Zeitspanne S wiederum repr\u00e4sentiert die Zeit die zwischen der ISR und der Antwort der User-Space-Anwendung vergeht.<\/p>\n Der Mikrocontroller soll zu Beginn der Messung einen Z\u00e4hler starten und sowohl die steigende, als auch die fallende Flanke des Antwortsignals detektieren. Dabei ist jeweils der aktuelle Wert des Z\u00e4hlers zu speichern. So kann gleichzeitig die Interrupt-Latenz als auch die Interrupt-zu-Prozess-Latenz ermittelt werden. Anschlie\u00dfend sollen die gemessenen Werte noch \u00fcber die serielle Schnittstelle an einen Rechner f\u00fcr die sp\u00e4tere Verarbeitung weitergesendet und eine neue Messung gestartet werden.<\/p>\n Das Prinzip dieser Messung ist ein h\u00e4ufig anzutreffendes Testszenario bei der Bewertung von Echtzeitsystemen und wird z.B. von OSADL in Form der Latency Box \u00a0durchgef\u00fchrt.<\/p>\n F\u00fcr die Auswertung und den Vergleich der Echtzeitf\u00e4higkeit der Container-L\u00f6sungen wird auch hier vor allem die Interrupt-zu-Prozess-Zeit interessant sein, da es hier zu Verz\u00f6gerungen durch den Betrieb der Anwendung innerhalb eines Containers kommen k\u00f6nnte.<\/p>\n An dieser Stelle sei noch angemerkt, dass dieses Testverfahren auf den ersten Blick redundant wirken mag, da der cyclictest einen \u00e4hnlichen Wert ermittelt. Allerdings werden externe Interrupts und Timer-Interrupts im Kernel anders abgearbeitet. Dies f\u00fchrt dazu, dass andere Stellen des Kernel-Codes beteiligt sind und das Zeitverhalten daher unterschiedlich sein kann.<\/p>\n Bei der Testdurchf\u00fchrung wurden zwei verschiedene Lastszenarien betrachtet. Im ersten Fall wurden die Tests ohne zus\u00e4tzliche Last auf dem BeagleBone Black durchgef\u00fchrt. Anschlie\u00dfend wurde das System w\u00e4hrend der Durchf\u00fchrung der Tests zus\u00e4tzlich belastet. Beide Programme wurden unter verschiedenen Lastszenarien mit 10 Millionen Messungen durchgef\u00fchrt.<\/p>\n Siehe Abb. 5 und 6 (PDF<\/a>)<\/p>\n „Hypervisor-gest\u00fctzte VM-Virtualisierung und containerbasierte Anwendungsvirtualisierung liegen vom Konzept her wie Tag und Nacht auseinander“ [Quote], so die allgemeine Einsch\u00e4tzung. Dem kann vollstens zugestimmt werden. Ein Container ist nicht einfach eine leichtgewichtige virtuelle Maschine. Eher kapselt er Systemprozesse, deren Sichtweite durch das Betriebssystem eingegrenzt ist.<\/p>\n Weiter l\u00e4sst sich festhalten, dass der grunds\u00e4tzliche Betrieb einer Echtzeitanwendung in einem Linux-Container m\u00f6glich ist. Dem Container sind dabei allerdings auch gewisse Rechte zuzuteilen, die vor allem im Hinblick auf die Gew\u00e4hrleistung eines sicheren Betriebs bedenklich sind. Auch wenn es aufgrund des beschr\u00e4nkten Umfangs der Messungen nicht gelungen ist, g\u00e4nzlich unanfechtbare Ergebnisse festzuhalten, kann vermutet werden, dass auch in zuk\u00fcnftigen Tests \u00e4hnliche Ergebnisse erzielt werden.<\/p>\n C.Arnold, M. J. (2012).\u00a0KVM Best Practices.<\/em>\u00a0dpunkt.<\/p>\n Mandl, P. (2014).\u00a0Grundkurs Betreibssysteme.<\/em>\u00a0Wiesbaden: Springer Verlag.<\/p>\n Der Referent Michael Schnelle besitzt einen Abschluss als Master in Software-Engineering. Mittlerweile verf\u00fcgt er \u00fcber mehrere Jahre Entwicklungserfahrung mit den Schwerpunkten Applikationsentwicklung, und Security in unterschiedlichen Schattierungen. Unter anderem f\u00fchrte er dabei Risikoanalysen durch, entwickelte L\u00f6sungen zur Abwehr schadhafter Anfragen auf einer Socialmedia-Plattform, f\u00fcr ein hochsicheres Signalisierungssystems f\u00fcr Notrufeinheiten, sowie zur Generierung einer sicheren Linux\/ Debian-Distribution. In seinem aktuellen Projekt wirkt er bei der Entwicklung von Fahrgastinformations-Systemen f\u00fcr Verkehrsunternehmen mit, mit den Schwerpunkten verteilte Systeme, Microservices und Testautomatisierung.<\/p>\n Kontakt:\u00a0<\/strong>michael.schnelle@mixed-mode.de<\/p>\n Beitrag als PDF-Datei downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nLinux als Echtzeitbetriebssystem<\/h2>\n
Virtualisierung<\/h2>\n
\n
Container-L\u00f6sungen<\/h2>\n
Testkonzept<\/h2>\n
Durchf\u00fchrung<\/h2>\n
Fazit<\/h2>\n
Literaturverzeichnis<\/h2>\n
Autor<\/h2>\n
\nEchtzeit – MicroConsult Trainings & Coachings<\/h2>\n
\nEchtzeit – Fachwissen<\/h2>\n