MP-SS13-01

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Einleitung

Rahmenbedingungen

Das Masterprojekt ist organisatorisch im Rahmen des betrieblichen Forschungstrainee-Programms der Hochschule RheinMain [1] mit Förderung durch den Europäischen Sozialfond eingebettet. Betrieblicher Partner ist der System Vertrieb Alexander (SVA)[2], ein Wiesbadener Systemintegrations-Unternehmen, das u.a. mit dem Softwarepaket BVQ eine selbst-entwickeltes Werkzeug für das Management von Speichersystemen namens BVQ anbietet. Betrieblicher Betreuer innerhalb der SVA ist Herr Thomas Sikora. Von Seiten der Hochschule RheinMain wird das Projekt im Labor für verteilte Systeme von Prof. Dr. Rheinhold Kröger betreut.

Inhaltlich ist das Projekt Teil des bis Ende 2014 ausgelegten Projekts OntoStorM (finanziert über das Förderprogramm Hessen LOEWE3) unter der technischen Leitung von Andreas Textor. Das Projekt OntoStorM befasst sich mit Ontologie-basiertem Management von IT-Systemen.

Motivation

Moderne Speichersysteme basieren auf einer verteilten Infrastruktur, deren Komplexität die Anbieter bei der Leistungsanalyse vor ein schwieriges Management Problem stellt. Hardwareseitig muss beispielsweise die Art des Speicher-Controllers, die Vernetzung und die Auswahl der (teilweise heterogenen) Speichermedien beachtet werden. Anwendungsfall-spezifische Einflüsse wie Lese- und Schreibverhalten oder die Anzahl der Anfragen pro Sekunde spielen bei der Auswahl des passenden Systems ebenfalls eine große Rolle. Diese Bedarfsanalyse beruht heute häufig auf Erfahrungswerten.

Zielsetzung

Das langfristige Ziel des Gesamtprojekts ist die Entwicklung eines in das OntoStorM-Projekt integrierten Werkzeugs zur Modell-unterstützten Bedarfsanalyse von Speichersystemen. Im Rahmen des Masterprojekts wird diesbezüglich ein bestehender Ansatz zur Modell-basierten Leistungsanalyse aus dem Software Performance Engineering Umfeld analysiert und validiert. Des Weiteren soll eine Tool-Chain für das in diesem Ansatz beschriebene Verfahren etabliert werden. Abschließend wird das Verfahren unter Verwendung eines einfachen Beispiels aus dem Speichersystem-Bereich durchgeführt und bewertet.

Das ursprüngliche Abstract sowie der Abschlussvortrag des Masterprojekts ist in den Quellen aufgelistet.[3][4]

Verfahren

Ansatz

Verfahren zur Leistungsanalyse

Der im Masterprojekt verwendete Ansatz zur Leistungsanalyse beruht auf ein Verfahren aus dem Bereich des Software Performance Engineering.

Der grundlegende Ablauf ist folgendermaßen:

  • Modellierung des Systems un der Last einer dafür geeigneten Modell-Sprache
  • Transformation bzw. Abbildung des Systemmodells in ein Leistungsmodell
  • Auswertung des Leistungsmodells
  • Optional: Rücktransformation des Leistungsmodells in das Systemmodell

Durch dieses Verfahren können die Vorteile aus beiden Modellierungswelten genutzt werden. Das Kriterium bei der Auswahl der System-Modellierungssprache ist die Ausdrucksstärke für die Beschreibung entsprechenden Systems. Das Leistungsmodell wird hingegen nach der Auswertbarkeit bzw. der Effizienz der zugrunde liegenden Berechnungsalgorithmen ausgewählt. Bei der jeweiligen Auswahl muss zusätzlich beachtet werden, dass eine sinnvolle Abbildung zwischen beiden Modellen prinzipiell möglich ist.

Dieser Ansatz wurde unter anderem bereits in bestehenden Forschungsprojekten verfolgt, auf denen dieses Masterprojekt aufbaut:

  • Leistungsanalyse bei der Entwicklung verteilter Software (Kairo)[5]
  • Leistungsvorhersagen für Service-orientierte Systeme (München)[6]
  • Entwurfsbegleitende Leistungsanalyse (Dresden)[7]

Die bestehenden Ansätze befassen sich dabei hauptsächlich mit dem Anwendungsgebiet Software-Entwicklung [5][6], beruhen teilweise auf manueller Transformation[6] oder verwenden abweichende Modellsprachen oder -werkzeuge[5][7].

Werkzeuge und Techniken

Übersicht Werkzeuge und Techniken
Sprache ungerahmt
Vorgehen System-Modellierung Modell-Transformation Modell-Auswertung
Tools Eclipse Papyrus
MARTE-Plugin
Eclipse MMT (EMP) LQN Solver

Die im folgenden beschriebenen Werkzeuge und Techniken werden bei der Umsetzung des Ansatzes in den einzelnen Verfahrensschritten verwendet.

Die Auswahl erfolgte hauptsächlich nach folgenden Kriterien:

  • Vorhandene, Werkzeug-übergreifende und offene Standards (beispielsweise durch eine Spezifikation der OMG)
  • Verbreitung und Werkzeug-Anbindung (beispielsweise Unterstützung durch ein aktiv entwickeltes Eclipse-Projekt)
  • Eignung und Effizienz (beispielsweise XML-basierte Sprachrepräsentation, leistungsstarke Implementierungen [LQN])
  • Verwendung in bereits bestehenden Ansätzen

Unified Modeling Language (UML)

UML ist ein von der Object Management Group (OMG) verwalteter Standard für eine System-Modellierungssprache [8]. Sie wird überwiegend zur Beschreibung von Software-Systemen eingesetzt und ist vor allem in seiner grafischen Repräsentation bekannt. Die Spezifikation beihaltet aber zusätzlich ein auf XMI basiertes, textuelles Austauschformat namens UML Diagram Interchange. Dadurch wird die maschinelle Verarbeitung der erstellten Systemmodelle möglich, womit eine grundlegende Voraussetzung für den hier verfolgten Ansatz abgedeckt wird.

Die im UML-Standard spezifizierten Modellarten lassen sich in zwei Typen unterteilen: Struktur- und Verhaltensdiagramme. Für die Strukturbeschreibung wurde das Deployment-Diagramm ausgewählt, das von der OMG für die Modellierung von Hardware-Systemen und davon bereitgestellten Diensten vorgesehen ist. Das Verhalten des Systems wird durch ein Sequenz-Diagramm dargestellt, mittels dem z.B. Sachverhalte wie die Zuordnung von Aktionen zu Systemkomponenten und Nebenläufigkeit von Aktionen eindeutig modellierbar sind. Anwendungsfälle werden mit Use-Case-Diagrammen dargestellt.

Zur System-Modellierung mittels UML wird im Masterprojekt das auf Eclipse basierende Werkzeug Papyrus[9] verwendet. Papyrus setzt weitestgehend die in der aktuellen UML Version 2.4.1 definierten Standards sowohl in der grafischen als auch in der serialisierten Form um. Zudem ist es frei zugänglich, erweiterbar und ermöglicht eine Integration mit den weiteren im Projekt genutzten auf Eclipse basierenden Werkzeugen.

Die Bedeutung der einzelnen Modell-Elemente des jeweiligen UML-Modells sind folgendermaßen:

Deployment-Diagramm
  • Node: Ein Node-Element stellt ein physisches System dar.
  • Device: Mittels eines Device-Elements wird eine System-Komponente beschrieben.
  • Execution Environment: Dieses Element beschreibt eine einzelne Funktion einer System-Komponente.
  • Association: Eine Association beschreibt einen Kommunikationsweg zwischen zwei physischen Systemen.
Sequenz-Diagramm
  • Lifeline: Eine Lifeline ist die Repräsentation einer Systemkomponente und damit eine Schnittstelle zwischen Deployment- und Sequenz-Diagramm.
  • Action Execution Specification (AES): Eine AES beschreibt eine Aktion, die auf einer Systemkomponente ausgeführt wird.
  • Message: Mit dem Message-Element lassen sich (a)synchrone Nachrichten zwischen zwei System-Komponenten modellieren.
  • Combined Fragment: Combined Fragments ermöglichen die Aufteilung einer Sequenz in parallele oder alternative Unter-Sequenzen.
  • Interaction Operand: Die Unter-Sequenzen eines Combined Fragments werden in Interaction Operands beschrieben.

Modeling and Analysis of Real-Time and Embedded Systems (MARTE)

MARTE ist ein von der OMG spezifiziertes UML-Profil [10] zur Modellierung von Echtzeitsystemen und eingebetteten Systemen. Ein UML-Profil ist eine Erweiterung des UML Standards um Domänen-spezifische Elemente. Bestehende UML-Diagramm-Komponenten können dadurch mit im UML-Profil definierten sogenannten Stereotypen annotiert und dadurch um deren Eigenschaften erweitert werden. Die Annotation erfolgt in der grafischen Repräsentation überwiegend mittels Guillemets (französische Anführungszeichen) nach dem Element-Namen sowie der Erweiterung um spezifische Element-Attribute. Im seriellen XMI-Dokument werden Stereotypen über Verweise auf die Element-ID mit den Diagramm-Komponenten verknüpft.

MARTE Stereotypen

MARTE ermöglicht eine Anpassung der generischen UML-Diagramm-Typen an den Anwendungsfall Speichersysteme und Leistungsmodellierung. Die einzelnen MARTE Stereotypen sind in in thematisch und hierarchisch geordnete Pakete unterteilt. Im Masterprojekt werden Stereotypen aus den Unterpaketen HRM (Hardware Ressource Modelling), GQAM (General Quantitive Analysis Modelling), PAM (Performance Analysis Modelling) sowie VSL (Value Specification Language) verwendet. Mittels HRM-Stereotypen können die Hardware-Komponenten des Speichersystems beschrieben werden, während mittels GQAM- und PAM-Stereotypen sowohl der Hardware als auch den Systemabläufen Leistungsparameter zugewiesen werden können. Die VSL dient vor allem zur Deklaration von Variablen der Leistungsparameter, um diese erst zu einem späteren Zeitpunkt des Modellierungsprozesses definieren zu müssen. Dadurch ist das erstellte Modell flexibel für unterschiedliche Anwendungsfälle bzw. Last-Szenarien nutzbar.

Für Eclipse Papyrus ist ein MARTE-Plugin verfügbar, dass die verschiedenen MARTE Stereotypen innerhalb des Modellierungswerkzeugs verfügbar macht.

MARTE Stereotypen (Auswahl)
  • HwDrive (HRM): Mittels HwDrive läßt sich eine Festplatte beschreiben. Das Device aus dem Deployment-Diagramm wird dadurch u.a. um das Attribut Bandbreite (bandwidth) erweitert.
  • GaExecHost (GQAM): GaExecHost beschreibt eine ausführende Komponente. Sie bietet Dienste an und arbeitet Aktionen ab.
  • PaStep (PAM): Hiermit wird eine auszuführende Aktion definiert. Sie wird auf einem von GaExecHost bereitgestellten Dienst ausgeführt. In der Abbildung ist die verursachte Last der Aktion in Form einer Transfergröße und dadurch indirekt einer Transferrate beschrieben.
  • $msgSize (VSL): Das Dollarzeichen wird in der VSL-Grammatik zur Deklaration einer Variable verwendet. Die $msgSize Variable ist ein Platzhalter und wird später über in einem UseCase-Diagramm mit einem entsprechenden Wert belegt.

Query/View/Transformation (QVT)

QVT ist ein von der OMG verwalteter Standard[11], in dem Programmiersprachen für Modell-zu-Modell Transformationen spezifiziert sind. Die Transformation wird generisch auf Meta-Modell-Ebene definiert und dann auf Modell-Instanz-Ebene ausgeführt.

Der Standard sieht zwei Sprachdialekte vor: QVT Core bzw. QVT Relational (QVTr) sind deklarative Sprachen und QVT Operational (QVTo) ist eine imperative Sprache. Mit QVTr lassen sich im Vergleich zu QVTo bidirektionale Transformationen beschreiben, die unabhängig von der Abfolge der einzelnen Transformationsschritte sind. Allerdings gibt es keine aktuelle Implementierung des QVTr Standards.

Für QVTo besteht ein Eclipse Plugin aus dem Eclipse Modelling Project (EMP)[12], das in diesem Masterprojekt verwendet wurde.

QVTo Beispiel

Das folgende Quellcode Beispiel zeigt die Meta-Modell Deklaration, die Angabe von Ein- und Ausgabe-Modell, den Programm-Einstiegspunkt sowie die Abbildung (mapping) eines Elements aus dem Eingabe-Modell auf ein Element des Ausgabe-Modells.

--Deklaration der verwendeten Meta-Modelle
modeltype mtUML uses "http://www.eclipse.org/uml2/4.0.0/UML";
modeltype mtMARTE uses "http://www.eclipse.org/papyrus/MARTE/1";
modeltype mtLQNCore uses "file:~/lqns/lqn-core.xsd";

--Beschreibung der Ein- und Ausgabe-Modelle
transformation STORAGE2LQN(in SourceUML : mtUML,  out TargetLQNCore : mtLQNCore);

--Einstiegspunkt des Programms
main() {
	SourceUML.rootObjects()[uml::Model]-> map Model2DocRoot();
}

...

--Abbildung eines UML Device Elements auf ein LQN Processor Element
mapping mtUML::Device::deviceToProc() : mtLQNCore::ProcessorType
{
    var st :=
        self.getAppliedStereotype(mtMARTE::GQAM::GaExecHost');
    var stA :=
       self.getStereotypeApplication(st)
           .oclAsType(mtMARTE::GQAM::GaExecHost);
    name := self.name;
    multiplicity := stA.resMult->getNFPVariable();
    task := self->map deviceToTask();
}

...

Neben Mappings sind v.a. die QVTo-Sprachelemente query, intermediate class und property von Bedeutung. Mittels query lassen sich Hilfsfunktionen definieren, die beispielsweise für Operationen zwischen den Abbildungen nutzen lassen. Über intermediate class und property lassen sich interne Klassen und Attribute definieren, wodurch z.B. die Erstellung eines Zwischenmodells möglich wird.

Layered Queueing Networks (LQN)

Layered Queueing Networks (dt.:Geschichtete Warteschlangennetzwerke) sind eine Erweiterung der aus der Warteschlangentheorie bekannten Warteschlangennetzwerke. Warteschlangen basieren auf dem Client-Server Prinzip, d.h. es gibt einen Client, der Anfragen mit einer bestimmten Rate und einem Ressourcen-Bedarf an einen Server stellt. Diese Anfragen werden vom Server in einer Warteschlange entgegen genommen und nach einer vorher definierten Abfolge abgearbeitet. Warteschlangen lassen sich sowohl analytisch als auch simulativ berechnen, so dass zu einer definierten Aufgabenlast eine entsprechende Ressourcenbelastung und Abarbeitungszeit ermitteln lässt. Da dieses Prinzip der Arbeitsweise von IT-Systemen ähnelt, eignen sich LQNs prinzipiell um solche System zu beschreiben.

LQN-Diagramm-Elemente

Eine graphische und textuelle Modellierungssprache für LQNs sowie eine proprietäre, mit C entwickelte Anwendung zur Berechnung dieser Modelle wurde an der Carleton Universität in Ottawa (Kanada) entwickelt.[13] Die textuelle Eingabesprache ist in einem XML-Schema definiert, das sich in QVTo importieren lässt. Auf funktionaler Ebene sind LQNs ausdrucksstark genug, um etwa verteilte Infrastrukturen, asynchrone Aufrufe und parallele sowie alternative Aktionsabfolgen zu modellieren.

LQN-Diagramm
  • Processor: Der Processor stellt die abarbeitende Komponente der LQNs dar. Mittels Attributen wie Multiplizität und Art der Abarbeitung (z.B. First-Come-First-Served) kann das Processor-Verhalten präzisiert werden. Die Abarbeitungsrate ist implizit über die Bedienzeit der auszuführenden Aktionen gegeben, kann aber auch mittels eines Multiplikators angepasst werden.
  • Task: Jedem Processor wird eine oder mehrere Task(s) zugeordnet, die als ausführende Komponenten Aktionsabläufe bündeln. Tasks können Aufrufe anderer Tasks entgegennehmen und dienen für diese dadurch indirekt als abarbeitende Komponente.
  • Reference Task: Das Task-Element auf oberste Ebene wird als Reference-Task deklariert. In dieser Reference Task wird die Last (Workload) mittels einer konstanten oder variabel verteilten Ankunftsrate beschrieben.
  • Entry: Innerhalb einer Task werden über Entries Aktionen für den mit der Task verbundenen Processor beschrieben. Entries sind zudem die Eingangsschnittstellen der Tasks für Aufrufe aus einer höheren Ebene des LQNs. Für jede Entry wird eine Bedienzeit angegeben, die zur Abarbeitung auf der Aktion auf dem Processor benötigt wird.
  • Precedence: Aktionen können mittels Precedences aufgeteilt werden, um alternative oder parallele Aktionsabläufe abzubilden. Für alternative Abläufe muss eine prozentuale Wahrscheinlichkeit pro Verzweigung angegeben werden.
  • Activity: Eine Activity beschreibt eine Unteraktion. Dadurch lassen sich Aktionen innerhalb einer Task aufteilen und detailliert beschreiben.

Implementierung

Anwendungsbeispiel

SVC Speichersystem

Um den Ansatz zu validieren, wird das Verfahren am Beispiel eines IBM SAN Volume Controller[14] Konfiguration durchgeführt. Dabei wird das Lese und Schreib-Verhalten auf Hardware Ebene abstrakt modelliert, transformiert und ausgewertet.

Modellierung

Beim UML-Modell des Speichersystems handelt es sich um ein der Projekt-Zielsetzung entsprechendes vereinfachtes, abstraktes Modell. Die System-Struktur wurde mittels eines Deployment-Diagramms beschrieben, während das System-Verhalten durch ein Sequenz-Diagramm dargestellt wird. Der jeweilige Anwendungsfall wird durch ein UseCase-Diagramm repräsentiert, das hauptsächlich als Container für die Eingabe-Leistungsparameter dient. Diese Leistungsparameter werden durch Annotationen mittels MARTE-Stereotypen den einzelnen Modell-Komponenten hinzugefügt - diese Parameter sind aus Platzgründen in den hier dargestellten Schaubildern nicht enthalten, können aber im tatsächlichen Modell nachvollzogen werden[15]. Als Ausgabe-Modell ist das resultierende LQN-Modell dargestellt.

Die Struktur des Speichersystems besteht auf oberster Ebene zunächst aus Clients, die eine Last über Anfragen mit einer definierten Transfergröße und einer konstanten Ankunftsrate generieren. Diese Anfragen werde zudem unterteilt nach Lese- und Schreib-Wahrscheinlichkeit. Diese Anfragen werden über das externe Netzwerk an den Storage Controller weitergegeben. Bei einer Lese-Anfrage wird abhängig von einer angegebenen Wahrscheinlichkeit (Cache Hit Ratio) entweder direkt aus dem Cache gelesen oder über das interne Netzwerk auf die Festplattenspeicher zugegriffen. Beim Schreibvorgang wird parallel auf den Cache und über das interne Netzwerk auf den Festplattenspeicher geschrieben, wobei letzteres asynchron (write-back Strategie) abläuft.

Transformation

Die eigentliche Modell-Transformation wird über zwei Phasen durchgeführt. In der ersten Phase werden die Meta-Modelle der Ein- und Ausgabe-Modelle importiert. Für die verschiedenen UML-Diagramme sowie MARTE-Stereotypen (bis auf VSL) werden von Eclipse bereits geeignete Modelle im ecore-Format für die verwendete QVTo-Implementierung bereit gestellt. Für das LQN-Meta-Modell, das nur als XML-Schema vorliegt, muss mittels Werkzeugen aus dem Eclipse Modelling Framework[16] zunächst ein Meta-Modell im ecore-Format erstellt werden[17].

Auf Basis dieser Meta-Modelle wird dann die generische Transformation mit QVTo-Sprachkonstrukten beschrieben[18]. Da der hierarchische Aufbau der UML-Meta-Modelle nicht dem des LQN-Meta-Modells entspricht und zudem Struktur und Verhalten aus zwei Eingabe-Modellen in ein Ausgabe-Modell umgewandelt werden muss, wird zunächst innerhalb von QVTo mittels intermediate classes und properties über queries ein Zwischen-Modell generiert. Dieses Modell entspricht einer Baumstruktur, die sowohl Deployment- als auch Sequenz-Diagramm-Komponenten beinhaltet bzw. vereint. Als nächstes werden die MARTE-Leistungsparameter über eine rudimentären Parser ausgelesen und in LQN-Leistungsparameter umgewandelt. Im Schaubild ergibt beispielsweise aus MARTE-Sicht die Bandbreite (in mB/s) des internen Netzwerks zusammen mit der Nachrichtengröße (in kB) der Last ein eine Host-Beanspruchung (in ms) der Schreib-Aktion auf LQN-Seite. Nachdem die Leistungsparameter umgewandelt worden sind, werden die einzelnen Abschnitte des Baum-Diagramms des QVT-Zwischen-Modells auf Processor-Ebene in ein korrespondierendes LQN-Diagramm überführt.

Diese Transformationsbeschreibung wird dann in der zweiten Phase ausgeführt, in dem mann tatsächliche Modell-Instanzen als Eingabe-Modelle angibt und daraufhin eine LQN-Modell-Instanz als Augabe-Modell erhält. Das LQN-Ausgabe-Modell kann dann wiederum durch den LQN-Solver ausgewertet werden.

Transformation Beispiel

Auswertung

Die Auswertung erfolgt im hier angegebenen Beispiel über den simulativen LQN Solver lqsim, dem das Ausgabe-Modell als Parameter übergeben wird. Aus den Leistungs-Eingabeparametern, d.h. der Last- und der Ressourcenbeschreibung der einzelnen Elemente werden pro abarbeitender Komponente Leistungs-Ausgabeparameter ermittelt.

Eingabeparameter

  • Reference-Task: In der Reference Task wird mittels den Parametern think-time und multiplicity eine Ankunftsrate von Anfragen festgelegt.
  • Entry/Activity: Der Wert für host-demand gibt die rohe Abarbeitungszeit der Aktion in ms an. Implizit wird dadurch auch die Abarbeitungsrate auf dem Processor definiert.
  • (Or-) Precedence: Mittel probability kann die prozentuale Wahrscheinlichkeit alternativer Verzweigungen von Unteraktionen angegeben werden.
  • Processor: multiplicity gibt die Anzahl der Processors an, die an der Abarbeitung der Aktionen beteiligt sind.
\\Workload: Client 20 Calls per 50ms   

Processor identifiers and scheduling algorithms:
Processor Name  Type    Copies  Scheduling
ExtNetwork      Mult(2)   1     FCFS

Task information:
Task Name       Type    Copies  Processor Name  Entry List
ExtNetwork      Uni       1     ExtNetwork      readExtNet,
                                                writeExtNet

Entry execution demands:
Task Name       Entry Name      Phase 1     
ExtNetwork      readExtNet      0.002      
                writeExtNet     0.002

Ausgabeparameter

  • Entry/Activity: Für Aktionen wird die tatsächliche Bedienzeit service-time ermittelt. Sie setzt sich aus der Wartezeit und der Abarbeitungszeit zusammen.
  • Task: Für Tasks wird mit throughput der Durchsatz, d.h. die abgearbeiteten Anfragen pro Zeiteinheit angegeben.
  • Processor: Mittels utilization wird die prozentuale Auslastung der Processors angegeben.
Service times:
Task Name       Entry Name      Phase 1     
ExtNetwork      readExtNet      0.0120504   
                writeExtNet     0.00819101 

Throughputs and utilizations per phase:
Task Name       Entry Name      Throughput  Utilization       
ExtNetwork      readExtNet      0.31807     0.00383287 
                writeExtNet     0.08082     0.000661997
Total:                          0.39889     0.00449486

Utilization per phase for processor:  ExtNetwork
Task Name       Pri n   Entry Name      Utilization     
ExtNetwork      0   1   readExtNet      0.000637197           
                        writeExtNet     0.000160523           
Task Total:                             0.000797721

Bewertung

Verfahren

Grundsätzlich sind UML und MARTE sowie die genutzten Implementierungen in Papyrus zur Modellierung von Speichersystemen und deren Leistungsfähigkeit geeignet. D.h. die für dieses Masterprojekt vorgesehene Umsetzung eines einfachen Speicher-Leistung-Modells kann mit den zur Verfügung stehenden Werkzeugen durchgeführt werden. Eine maschinelle Transformation mittels QVTo zu einem berechenbaren LQN-Modell ist ebenfalls möglich. Damit ist der vorgestellte Ansatz für ein einfaches Modell validiert und eine Tool-Chain für weitere Betrachtungen etabliert worden.

Als problematisch erwiesen folgende kleinere Punkte. Für MARTE VSL gibt es bisher keinen geeigneten Parser in für QVTo, d.h. es muss noch ein Zwischenschritt beim Einlesen der Leistungs-Variablen vollzogen werden. Die Transformation ist allgemein von einem Zwischen-Modell abhängig. Dies könnte möglicherweise mit einer Umsetzung in QVTr - falls in Zukunft eine aktuelle Implementierung zur Verfügung steht - umgangen werden. Auf LQN-Seite ist anzumerken, dass das XML-Eingabeformat eine spätere Entwicklung ist und nicht denselben Sprachumfang besitzt wie das ursprüngliche Modell. Eine kommerzielle Nutzung des LQN-Solvers ist zudem von einer Lizenzierung beim Entwickler abhängig.

Vorläufige Testergebnisse

Im folgenden wurden einige vorläufige Testergebnisse aufgelistet. Dabei werden die ermittelten Daten aus dem im Masterprojekt vorgestellten Ansatz mit den Daten aus dem von IntelliMagic für IBM entwickelten Vorhersage-Tool DiskMagic[19] verglichen. Da eine wichtiger Sachverhalt (Access Time und Positioning Time) nicht im ursprünglichen UML-Modell enthalten war, wurde er vorerst provisorisch während der Transformation hinzugefügt.

Die Ergebnisse geben teilweise starke Abweichungen wieder, allerdings sind Tendenzen durchaus wieder zu erkennen. Die Auslastung des Festplattenspeichers nimmt gleich proportional bei einer Erhöhung der Ankunftsrate (IOPS) zu. Bei einer hohen Cache Hit Ratio sowie einem großen Anteil an Schreib-Zugriffen nimmt die Bedienzeit jeweils stark ab. Bei zunehmender Transfergröße nimmt der Einfluss der Positioning Time und Access Time erwartungsgemäß ab.

Eingabe
Workload
IOPS 1000 2000 4000 5000 2000 2000 2000 2000 2000 2000
Transfer Size 8KiB 8KiB 8KiB 8KiB 8KiB 8KiB 16KiB 32KiB 64KiB 128KiB
R/W Ratio 80/20 80/20 80/20 80/20 80/20 20/80 80/20 80/20 80/20 80/20
Cache hit % 40 40 40 40 90 40 40 40 40 40
External Network
Bandwidth 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s
Multiplicity 2 2 2 2 2 2 2 2 2 2
Storage Controller
IOPS 1000000 1000000 1000000 1000000 1000000 1000000 1000000 1000000 1000000 1000000
Typ DS8100 DS8100 DS8100 DS8100 DS8100 DS8100 DS8100 DS8100 DS8100 DS8100
Cache
Read Bandwidth 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s
Write Bandwidth 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s 6Gb/s
Internal Network
Bandwidth 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s 4Gbit/s
Multiplicity 2 2 2 2 2 2 2 2 2 2
Storage
Read Bandwidth 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s
Write Bandwidth 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s 140Mb/s
Multiplicity 4 4 4 4 4 4 4 4 4 4
Typ(Size (GiB)/RPM/Ranks) 146/15k/4 146/15k/4 146/15k/4 146/15k/4 146/15k/4 146/15k/4 146/15k/4 146/15k/4 146/15k/4 146/15k/4
Positioning Time + Access Time 4/6/8ms 4/6/8ms 4/6/8ms 4/6/8ms 6ms 6ms 6ms 6ms 6ms 6ms
Ausgabe
Utilization (Storage)
MARTE2LQN 2,77/4,17/5,65 5,54/8,29/10,96 10,9/16,5/22,08 13,8/20,6/27,4 3,30 11,09 8,43 8,48 8,93 9,24
DiskMagic 18,7 37,5 75,0 93,7 25,2 89,3 37,3 36,9 24,0 25,2
Service Time (gesamt)
MARTE2LQN (ms) 2,18/3,39/4,62 2,38/3,91/5,63 2,88/5,11/8,09 3,16/5,86/9,63 0,60 1,10 4,02 4,07 4,55 5,03
DiskMagic (ms) 3,83 4,99 9,29 21,19 0,91 2,8 4,71 4,52 3,35 3,83

Ausblick

Das Masterprojekt ist hiermit abgeschlossen und wird zusätzlich als Posterbeitrag für eine Konferenz am 31.März in Dublin Irland eingereicht[20]. Für eine auf dieses Masterprojekt aufbauende Master Thesis wurde eine Weiterentwicklung des Modells, ein Anschluss an eine vorhandene Ontologie sowie eine Automatisierung der Tool-Chain vorgesehen. Des Weiteren können Fragestellungen wie ein vollständiger VSL-Parser oder die Erweiterung der LQN-XML-Eingabesprache von Interesse sein. Abhängig von weiteren ausführlichen Tests und Lizenzierungsproblemen könnten auch alternative Leistungsmodelle wie Queueing Petri Networks (QPN)[21] in Betracht gezogen werden.

Quellen

  1. [1] Website des ESF-Forschungstrainee-Programm der Hochschule RheinMain - abgerufen 20.12.2013
  2. [2] Website des Unternehmens System Vertrieb Alexander - abgerufen 20.12.2013
  3. File:Abstract_masterprojekt_vogler_ss2013.pdf
  4. File:Vortrag_masterprojekt_vogler_ss2013.pdf
  5. 5,0 5,1 5,2 [3] El-kaedy, Reheb A., and Ahmed Sameh. "Performance Analysis and Characterization Tool for Distributed Software Development." International Journal of Research and Reviews in Computer Science (IJRRCS), 2011.
  6. 6,0 6,1 6,2 [4] Mirco Tribastone, Philip Mayer, and Martin Wirsing. "Performance prediction of service-oriented systems with layered queueing networks." In Proceedings of the 4th international conference on Leveraging applications of formal methods, verification, and validation (ISoLA), 2010.
  7. 7,0 7,1 Koycheva, Evelina. "Entwurfsbegleitende Leistungsanalyse mit UML, MARTE und Generalisierten Netzen." Oldenbourg Verlag, 2012.
  8. [5] UML Spezifikation - abgerufen 21.12.2013
  9. [6] Eclipse Papyrus - abgerufen 21.12.2013
  10. [7] MARTE Spezifikation - abgerufen 21.12.2013
  11. [8] QVT Spezifikation - abgerufen 21.12.2013
  12. [9] QVTo Eclipse Plugin - abgerufen 21.12.2013
  13. [10] Layered Queueing Networks, Carleton Universität Ottawa, Kanada - abgerufen am 21.12.2013
  14. [11] Implementing the IBM System Storage San Volume Controller V6.3, IBM Redbook, 2012
  15. File:masterprojekt_vogler_ss2013_uml_modelle_quellcode.tar.gz
  16. [12] Website der Eclipse Hilfe zur Erstellung von EMF-Modellen aus XML-Schema - bagerufen am 22.12.2013
  17. File:masterprojekt_vogler_ss2013_lqn_ecore_quellcode.tar.gz
  18. File:masterprojekt_vogler_ss2013_qvt_transformation_quellcode.tar.gz
  19. [13] Website von DiskMagic, IntelliMagic - abgerufen am 22.12.2013
  20. [14] 5th ACM/SPEC International Conference on Performance Engineering
  21. [15] Website des QPME Projekts, Karlsruher Institut für Technologie - abgerufen am 22.12.2013