Systemarchitektur

Emulation-as-a-Service verwendet Konfigurationsvorlagen (gespeichert in XML), um emulierte Hardware und Daten wie vom Benutzer angegeben zusammenzustellen.

Der Effekt besteht darin, in-browser virtuelles Computing zu erstellen:term:environments <environment>, die das Verhalten einer physischen Maschine imitieren.

Wenn ein EaaSI-Benutzer eine Umgebung betreibt, leitet die Konfigurationsdatei die Plattform an den entsprechenden Emulator für dieses System, die Hardwareeinstellungen für diesen Emulator, ein Datenträgerbild mit einem bootfähigen Betriebssystem und gegebenenfalls zusätzlichen Inhalten (z.B. Software-Installationsmedien, die von einer CD-ROM oder Diskette abgebildet werden) zur Montage in der Umgebung.

../_images/visual_designs1.jpg ../_images/visual_designs3.jpg

Keine Komponenten

Emulation-as-a-Service ist ein Server-Software-Stapel, der aus einer Reihe von Modulen besteht, die zusammen arbeiten, um die Aufgabe der Emulator-Montage und Konfiguration zu erfüllen. Derzeit müssen diese Module als Monolith (alle auf einem Server) eingesetzt werden, aber das Entwicklungsteam macht Fortschritte, um die Module über mehrere physische/virtuelle Maschinen zur idealen Konfiguration bereitzustellen.

EaaSI-Stacks(a node) enthalten zusätzliche Komponenten, um resources und Metadaten über das EaaSI-Netzwerk zu teilen, aber Kernfunktionalität wird mit folgenden Komponenten erreicht:

../_images/EaaS_Model.png

Kunde

Ein EaaS-Client bietet eine web-browser-basierte Schnittstelle für Benutzer, die mit Emulation-as-a-Service über RESTful HTTP Requests interagieren. Dieses Handbuch beschäftigt sich vor allem mit dem von PortalMedia entworfenen „EaSI Client“, der es ermöglicht, ältere Software und Inhalte in emulierten Rechenumgebungen zu importieren, zu speichern und zu dokumentieren.

Bemerkung

Es gibt auch den „Demo Client“, der von OpenSLX verwendet wird, um zunächst neue Features für die EaaaS Back-End-Plattform zu entwerfen, umzusetzen und zu demonstrieren. Eaaa SI-Nutzer können diesen Kunden manchmal noch begegnen, z.B. mit dem “ Versuchen Sie EaaSI“<container_setup> Docker Bilder. Bitte beachten Sie den Abschnitt :ref:`demo_client dieses Handbuchs für Fragen zur Nutzung dieser Schnittstelle.

Weitere Kunden und Dienstleistungen auf der Grundlage von mit dem EaaSI-Client erstellten Umgebungen sind im Rahmen des vollen EaaSI-Programms der Arbeit entwickelt. Weitere Details zur Nutzung dieser Kunden und Dienstleistungen werden als relevant veröffentlicht.

Der EaaSI-Client wird mit dem Vue.js-Framework auf einem LNPP (Linux-Nginx-PostgreSQL, PHP)-Stack aufgebaut, der über Docker bereitgestellt wird:

../_images/eaasi-client_summary.png

Schlüsselwort

Ab v2021.10 umfassen EaaSI-Einstellungen auch ein Keycloak-Modul für die Benutzerverwaltung, einschließlich der Speicherung von Benutzerkonto-Metadaten und Authentifizierungsdiensten.

(Keine Komponenten- und Client-Diagramme wurden noch nicht aktualisiert, um die Ergänzung des Keycloak-Moduls zu reflektieren. Aktualisierte Systemdiagramme werden angezeigt)

Gateway

Der EaaS Gateway fungiert als API-Endpunkt, indem Sie Anfragen vom Client/Benutzer und die Verwaltung aller emulationsbezogenen Ressourcen und Berechtigungen. Es verfolgt Emulationssitzungen, berechnet notwendige Rechenressourcen und ordnet die Ressourcen im Speicher (Disk-Bilder, Dateien, XML-Metadaten), die zur Erfüllung von Benutzeranfragen erforderlich sind, und leitet diese Informationen dann an die EmuComp, um die Emulation auszuführen.

Emulation Component (EmuComp)

Das Modul Emulation Component (EmuComp) ortsansässige CPU-Ressourcen tatsächlich an, um Emulationssitzungen zu bedienen, und zugrunde liegende Emulator-Anwendungen (QEMU, SheepShaver, etc.) befinden sich hier und werden installiert. Die Hardware von EmuComp muss optimiert werden, um potenziell mehrere Emulationssitzungen ausführen zu können.

Lagerung

Die EmuComp lokalisiert und speichert Ressourcen in der Dateispeicherung wie vom Gateway geleitet. Dateien im Speicher beinhalten:

  • Bildarchiv: Disk-Bilder und XML, die Environment Ressourcen (System-Laufwerke, die bootfähige Software enthalten, und die neccesary Hardware/Emulator-Konfiguration gewünscht, um sie auszuführen). Alle Umweltressourcen im Bildarchiv werden im QCOW2 Festplattenbildformat gespeichert.

  • Software-Archiv: Disk-Bilder und/oder Dateien und XML, die Software Ressourcen.

  • Inhalt Archive: Festplattenbilder und/oder Dateien und XML, die Content Ressourcen erstellen.

Das EmuComp kann mit Ressourcen entweder im lokalen Dateispeicher (d.h. auf demselben Server) oder im Netzwerkspeicher, der dem EmuComp über HTTP zur Verfügung steht, verbinden.

Die jüngste Entwicklung hat sich darauf konzentriert, die Archive voll S3-kompatiblen Objektspeicher über die Implementierung von MinIO zu machen:

  • in v2021.10-Einstellungen von EaaSI können die Ressourcen von Image Archive in S3-kompatiblen Speichern gespeichert werden

  • ab v2023.spring (öffentliche Veröffentlichung anhängig) von EaaSI können alle Archive in S3-kompatiblen Speichern gespeichert werden

OAI-PMH Synchronisierung

Das EaaSI-Netzwerk nutzt das Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH), um Metadaten zwischen Knoten anzufordern, zu teilen und zu synchronisieren.

Neben den oben aufgeführten Knotenkomponenten enthält jede EaaSI-Installation einen OAI-PMH harvester und einen provider. Der Mähdrescher fordert Metadaten (im Fall von EaaSI Umweltdaten) von den Datenanbietern an anderen Knoten an; die Anbieter von Remote-Knoten fragen ihre lokalen Datensätze ab und geben diese Metadaten wieder an den ursprünglichen Mähdrescher zurück.

../_images/oai-pmh.png

Mit den bereitgestellten Metadaten kann der Ernteer dann auch notwendige Dateien (Disk-Bilder) von den anderen Knoten auf :ref: „request <replication>“ finden und replizieren.

Umwelt Ableitung

EaaS nutzt ein Snapshot-basiertes Dateiformat (qcow), um redundantes Kopieren und Speichern von Vollbilddateien bei der Erstellung von Umgebungen zu vermeiden. Jegliche Änderungen oder Änderungen an einer Umgebung werden in einer neuen qcow-Datei, die mit gespeicherten und getrennt vom ursprünglichen Festplattenbild der Umgebung verknüpft ist, isoliert und gespeichert. Die gespeicherten Derivat-Umgebungen werden dann programmatisch neu erstellt, um die vollständige Änderungskette an dem Punkt anzuzeigen, dass der Benutzer die Umgebung ausführen oder replizieren möchte.

../_images/Derivatives-example.jpg