Ein Angebot von

Software- & Prozessortechnik

Entwicklungen in der Embedded-Multicore-Virtualisierung meistern

| Autor / Redakteur: Markus Levy, Surender Kumar, Rajan Goyal * / Holger Heller

Multicore-Virtualisierung: jetzt auch im Embedded-Bereich erforderlich
Multicore-Virtualisierung: jetzt auch im Embedded-Bereich erforderlich (Bild: gemeinfrei / Pixabay)

Viele Jahre lang war die Virtualisierung das Flaggschiff der Serverwelt. Die steigende Komplexität und Vielfalt der Embedded-Systeme verlangt nun aber nach einer Virtualisierungstechnik.

Das Versprechen einer universellen Rechenplattform, die viele unterschiedliche Dinge für viele verschiedene Anwender gleichzeitig erledigen kann, erfordert ein gewisses Management, wie diese Tätigkeit erledigt wird – und die Virtualisierung hat diese Rolle im Server-Bereich übernommen. Andererseits benötigte die Embedded-Welt bisher im Allgemeinen keine Virtualisierung. Dies ist ein weitreichender Faktor, weil Embedded-Geräte schon fast per Definition keine universellen Plattformen sind.

Ihre Aufgaben konnten per Handarbeit auf den niedrigsten Ebenen erledigt werden. Als allerdings die Komplexität und die Vielfalt der Embedded-Systeme mit der Zeit anstieg, wurde die Notwendigkeit einer Form von Virtualisierungs-Technologie offensichtlicher; immerhin gehören heutzutage Anwendungen wie Netzwerk-Ausrüstung und Smartphones zu den Embedded-Systemen.

Wie bei den meisten Technologien ist die Anwendung der Virtualisierung in Embedded-Systemen komplexer als bei ihrem Server-Cousin. Der einzige Grund hierfür ist die Tatsache, dass Embedded-Technologie dazu tendiert, arbeitsintensiver zu sein: Die Anzahl der Variationen, Kombinationen und Permutationen von Eigenschaften und Funktionen kann leicht außer Kontrolle geraten, so dass es für die System-Architekten und Entwickler schwierig wird, ihren Weg in diesem Universum zu finden.

Multicore Association ruft Virtualization Working Group ins Leben

Außerdem hat die rasche Verbreitung von Multicore-Prozessoren zusätzliche Anwendungsmöglichkeiten für die Virtualisierungstechnik geschaffen. Aus diesem Grund hat die „Multicore Association“ eine „Virtualization Working Group“ genannte Arbeitsgruppe zum Thema Virtualisierung einberufen. Die Teilnahme vieler verschiedener Unternehmen, die auf dem Embedded-Markt aktiv sind, wird dabei helfen, Standards zu etablieren, welche die Skala der Bedürfnisse und Anforderungen von den unterschiedlichen Zuständigkeitsbereichen innerhalb der Embedded-Welt berücksichtigen und angehen.

Warum virtualisieren? Bisher gab es zwei wesentliche Treiber für die Virtualisierung innerhalb von Servern. Der transparenteste davon ist das Ziel, einen einzelnen Computer für eine Benutzergruppe so aussehen zu lassen wie mehrere Computer. Es gibt in der Welt des „Cloud-Computing“ (Datenverarbeitung in der Cloud) hierfür einen ganz klaren Bedarf, der meist als „Multi-Tenanting“ bezeichnet wird, wobei die direkte, aber in diesem Zusammenhang ungebräuchliche deutsche Übersetzung den Grundgedanken von „Multi-Tenanting“ sehr gut wiedergibt: Mehrfach-Verpachtung/Vermietung.

Ein Anwender verbindet sich mit der Cloud und bekommt eine „Maschine“, aber diese Maschine ist virtuell und vielleicht nur ein Teil einer tatsächlich in Hardware existierenden Maschine. Die Beziehung zwischen der „Maschine“, die der Anwender wahrnimmt und der zugrundeliegenden Hardware ist komplett für den Anwender unsichtbar und wenn das System ordnungsgemäß realisiert ist auch irrelevant.

Alter Code muss auf neuen Maschinen laufen

Der andere wesentliche Treiber zur Server-Virtualisierung ist die Tatsache, dass alter Code (Legacy-Code) auf neuen Maschinen laufen muss. Solche alten Programme könnten beispielsweise veraltete Betriebssysteme benötigen oder nach Ressourcen beziehungsweise Ein-/Ausgabeschnittstellen suchen, die auf dem neuen System nicht existieren. Selbstverständlich will sich niemand irgendwo in die Nähe des Codes bewegen (selbst wenn der Source-Code verfügbar ist). Daher wickelt die Virtualisierung das Programm förmlich ein – und zwar in einer Art und Weise, bei der das Programm denkt, es wäre auf seiner ursprünglichen Zielplattform.

Bild 1: Virtualisierungsschicht als Host, der Daten und Dienste für die Gäste bereitstellt
Bild 1: Virtualisierungsschicht als Host, der Daten und Dienste für die Gäste bereitstellt (Bild: EEMBC)

In beiden Fällen geht es dabei um einen einzelnen Computer, der auf der alleruntersten fundamentalen Ebene von einem einzelnen Betriebssystem (OS) betrieben wird, während oberhalb des Betriebssystems mehrere „Gäste“ (Guests) laufen. Bei diesen Guests handelt es sich um Gäste-Programme und/oder Gäste-Betriebssysteme. Die Virtualisierungs-Schicht fungiert dabei als Host, der Daten und Dienste für die Gäste bereitstellt. Zu dieser Host-Funktionalität gehören auch Umsetzungen, die erforderlich sind, um alle Beteiligten zufriedenzustellen (Bild 1).

Auf einer niedrigeren Ebene erledigt die Virtualisierung zwei fundamentale Aufgaben: Allocation und Sharing, also Zuweisen und gemeinsames Nutzen von Ressourcen. Im ersten Fall gilt es, den unterschiedlichen Gäste-Programmen Ressourcen zuzuweisen. Bei diesen Ressourcen kann es sich um Speicher, Interrupts oder Cores handeln. Die Virtualisierung erzeugt scharf voneinander abgegrenzte Bereiche (Sandbox). Innerhalb seines Bereichs kann jeder Gast „spielen“, das heißt alles tun was er möchte.

Datensicherheit beibehalten

Im zweiten Fall geht es um I/Os und andere dedizierte Ressourcen, von denen jeder Gast glauben muss, dass er exklusiven Zugang zu diesen Ressourcen hat. Die Rolle der Virtualisierung besteht hier darin, die Scharade der Exklusivität aufrecht zu erhalten.

Ein kritischer Teil dieser Aufteilung beziehungsweise Abschottung ist das Beibehalten der Security (Datensicherheit). Wenn zwei Prozesse auf zwei unterschiedlichen Computern ablaufen, dann ist es viel schwieriger, diese beiden miteinander kommunizieren zu lassen als wenn diese Prozesse auf der gleichen Hardware laufen. Diese viel leichter mögliche Inter-Kommunikation wird zu einem Problem, wenn der Anwender nicht möchte, dass die Prozesse sich unterhalten.

Aus diesem Grund ist es besonders wichtig, dass die Virtualisierung eine Trennung zwischen den Gästen zur Verfügung stellt und diese voneinander isoliert, so dass sie alle ausgezeichnet zusammenspielen – oder um es exakter auszudrücken: nebeneinander laufen.

Asymmetrisches Multiprocessing

Innerhalb der Embedded-Welt waren die meisten Systeme jedoch aus historischen Gründen viel einfacher, was ironischerweise in der komplexeren Natur eines Embedded-Systems begründet ist. Im Gegensatz zu Servern, die über die Palette der Anbieter und Applikationen hinweg mehr oder weniger gleich aussehen, variieren Embedded-Systeme in großem Umfang in punkto Formfaktor, Prozessor, I/O, Hardware-Architektur und Software-Architektur.

Die komplexesten Systeme – größtenteils Systeme zur Paketverarbeitung – wurden bisher durch Nutzung einer AMP-Konfiguration (AMP: Asymmetric Multiprocessing) realisiert, wo beispielsweise ein Core der CPU Control-Plane (Steuerungs-Ebenen) Anwendungen auf einem vollausgerüsteten Linux-Betriebssystem laufen lässt, während eine Reihe anderer Cores Data-Plane-Anwendungen vielleicht auf einer oder mehreren Instanzen eines kleinen Echtzeit-Betriebssystems (RTOS) oder gar überhaupt kein Betriebssystem ablaufen lässt und dabei in einer „Bare-Metal“-Konfiguration Befehle ausführt.

In der letzten Zeit gab es jedoch Fortschritte in Richtung der Möglichkeit, ein Embedded-System mit einem einzelnen Betriebssystem wie Linux auszustatten, dass dann unterschiedliche Cores unterschiedlich behandeln kann. Prozesse können unterschiedlichen Cores mehr oder weniger exklusiv zugewiesen werden, und es ist möglich, den Betriebssystem-Overhead für jeden einzelnen Core zu begrenzen, so dass einige Cores derart agieren können als wenn sie „Bare-Metal“ liefen, während sie gleichzeitig noch Zugang zu einigen rudimentären Diensten des Betriebssystems haben.

Sicherheit und Kommunikationsmanagement

In einem derart komplexen System muss die Virtualisierung sämtliche Vorteile in punkto Allokation, Sharing und Isolation zur Verfügung stellen, die für einen Server erforderlich sind. Aber in vielen Fällen arbeiten die zahlreichen „Programme“ tatsächlich zusammen an der Ausführung eines Systems, das sich auf einer höheren Ebene befindet, so dass sie vielleicht in einer Art und Weise kommunizieren müssen, wie es zwischen, angenommen, unterschiedlichen Teilnehmern eines Cloud-Computing-Servers notwendig – oder gar wünschenswert – wäre. Hier müssten daher die Virtualisierungs-Dienste in der Lage sein, sowohl aus Gründen der Security zu isolieren als auch das Kommunikationsmanagement im Sinne der Anwendungen zu erledigen.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 34682990 / Multicore)