Migration von Softwaresystemen auf IaaS-basierte Cloud Umgebungen

Christian-Albrechts-Universität zu Kiel Institut für Informatik Arbeitsgruppe Software Engineering Bachelorthesis Migration von Softwaresystemen auf IaaS-basierte Cloud Umgebungen Pascal Löer März 2011 Betreut von: Prof. Dr. Wilhelm Hasselbring M. Sc. Sören Frey

Erklärung Hiermit erkläre ich, Pascal Löer, dass ich die vorliegende Arbeit selbständig und ohne fremde Hilfe angefertigt und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Weiterhin versichere ich, dass diese Arbeit noch nicht als Abschlussarbeit an anderer Stelle vorgelegen hat. Ort, Datum Pascal Löer

Kurzfassung Die Migration auf eine Cloud Umgebung ist der zentrale Schritt, um sich die Techniken des Cloud Computing auch bei alten Softwaresystemen zu Nutze machen zu können. Im Rahmen dieser Arbeit wurden Probleme bei der Migration eines Softwaresystems auf eine IaaS-basierte Cloud Umgebung untersucht. Als Evaluationsbeispiel diente die Software ADempiere, welche auf die IaaS-basierte Cloud Umgebung Eucalyptus unter Verwendung des Migrationsansatzes CloudMIG migriert wurde. Es konnte gezeigt werden, dass in diesem Zusammenhang die Gewinnung eines Modells eines umfangreichen Altsystems wie ADempiere eines der komplexeren Probleme darstellt. Weiterhin kann unter anderem das Fehlen einer graschen Oberäche ein für die Migration auf eine Cloud Umgebung markantes Hindernis sein. Zusätzlich wurden verschiedene Optimierungspotenziale von ADempiere bezüglich der Lauähigkeit in einer Cloud Umgebung erörtert. Dazu zählt vor allem die automatisierte Skalierung der Ressourcen in Abhängigkeit des Workloads. Abstract The migration to a cloud environment is the central step for taking advantage of the techniques of cloud computing especially for legacy systems. Within this thesis problems in the process of migrating a legcy system to a IaaS-based cloud environment were analyzed. As an evaluating example the software ADempiere was migrated to the IaaS-based cloud environment Eucalyptus using the CloudMIG approach. It was shown, that considering this approach the extraction of a model of a large legacy system as ADempiere is one of the most complex issues. Furthermore, the absence of a graphical interface also can be a distinctive problem in the context of a migration to a cloud environment. In addition, several potentials for optimization of ADempiere regarding the operation in a cloud environment were discussed. The feature of automatic scaling resource consumption due to varying workload is one these. 3

Inhaltsverzeichnis Abbildungsverzeichnis 5 Tabellenverzeichnis 6 Quellcodeverzeichnis 7 1 Motivation 8 1.1 Einleitung.................................... 8 1.2 Ziele....................................... 8 1.3 Aufbau der Arbeit............................... 9 2 Grundlagen 10 2.1 Cloud Computing................................ 10 2.2 Migration von Softwaresystemen....................... 13 2.3 CloudMIG.................................... 14 2.4 Verwendete Software.............................. 16 3 Durchführung der Migration 18 3.1 Arbeitsumgebung................................ 18 3.2 Extraktion eines Modells von ADempiere................... 19 3.3 Modellierung von Eucalyptus......................... 20 3.4 Prüfung auf CEC-Violations.......................... 22 3.5 Manuelle Migration von ADempiere auf Eucalyptus............. 22 4 Analyse der Schwierigkeiten bei der Migration 25 4.1 Schablone zur Analyse............................. 25 4.2 Problemanalyse................................. 26 4.3 Zusammenfassung............................... 34 5 Analyse des Optimierungspotenzials 35 5.1 Schablone zur Analyse............................. 35 5.2 Optimierungsanalyse.............................. 35 5.3 Zusammenfassung............................... 39 6 Zusammenfassung und Ausblick 40 Literaturverzeichnis 41 4

Abbildungsverzeichnis 2.1 Die Dienstmodelle des Cloud Computing................... 11 2.2 Vergleich von starren mit variablen Ressourcen im Cloud Computing... 13 2.3 Das Vorgehen bei einer Migration nach dem Ansatz CloudMIG...... 14 2.4 Die Pakete des Cloud Environment Model (CEM).............. 15 4.1 Schablone zur Analyse von Problemen bei der Migration.......... 25 5.1 Schablone zur Analyse von Optimierungspotenzialen............ 35 5

Tabellenverzeichnis 4.1 P-1: KDM Extraktion aus ADempiere.................... 26 4.2 P-2: OpenJDK................................. 27 4.3 P-3: Sun Java 6................................. 28 4.4 P-4: Setup ohne GUI.............................. 29 4.5 P-5: Erreichbarkeit des Webservers...................... 30 4.6 P-6: Java Web Start Client.......................... 31 4.7 P-7: Transiente Speicherung.......................... 32 4.8 P-8: Einhängen von EBS Volumen...................... 33 5.1 O-1: Netzwerkkonguration.......................... 35 5.2 O-2: Öentlicher Zugri............................ 36 5.3 O-3: Skalierbarkeit............................... 37 5.4 O-4: Automatische Skalierung......................... 38 6

Quellcodeverzeichnis 3.1 Auszug aus dem CEM Modell von Eucalyptus................ 21 4.1 Problem mit OpenJDK im Quellcode von ADempiere............ 27 4.2 Java 6 Unterstützung im Quellcode von ADempiere............. 28 7

1 Motivation 1.1 Einleitung Diese Arbeit befasst sich mit dem Thema der Migration von Softwaresystemen auf IaaSbasierte Cloud Umgebungen. Das Cloud Computing ist aus der heutigen Informationstechnologie nicht mehr wegzudenken und gewinnt stetig mehr an Bedeutung. Dies zeigt sich in der gängigen Literatur an vielen Stellen. So schreibt [Vouk 2008], dass das Cloud Computing der nächste logische Schritt in der Entwicklung von On-Demand IT-Diensten und -Produkten sei. Der Grund für die aktuell zügige Entwicklung auf dem Gebiet des Cloud Computing liegt unter anderem in der Entwicklung des Internets. Die treibende Kraft hinter dem Cloud Computing seien nach [Dikaiakos et al. 2009] die Verbreitung von Breitband- wie auch Drahtlosnetzwerken, zudem fallende Preise für Speicherplatz und nicht zuletzt die fortschreitende Verbesserung von webbasierter Software. Des weiteren sind es Vorzüge wie potentiell geringere Kosten und bedarfsabhängige Ressourcen, welche das Cloud Computing in den Vordergrund der IT-Entwicklung drängen lassen. Sich diese Technik auch für bereits im Einsatz bendliche Softwaresysteme zu Nutze zu machen, ist auf Grund der groÿen Vorteile des Cloud Computing das Bestreben vieler Unternehmen. Die Schwierigkeiten, die mit diesem Bemühen einhergehen, sowie Lösungen und Lösungsansätze, um mit diesen umzugehen, stehen im Mittelpunk dieser Arbeit. 1.2 Ziele Das wesentliche Ziel dieser Arbeit ist es, die Probleme, die eine manuelle Migration einer Anwendung auf eine IaaS-basierte Cloud Umgebung mit sich bringt, aufzudecken und zu untersuchen. Zudem soll das Optimierungspotenzial einer solchen Altanwendung hinsichtlich ihrer Ausführung in einer Cloud Umgebung analysiert werden. Als geeignet um dieses Ziel zu erreichen erscheint dabei die tatsächliche Durchführung einer solchen Migration in Form einer Fallstudie. Um möglichst weitreichende Erkenntnisse aus diesem Vorgehen ziehen zu können, soll dazu eine umfangreiche Open-Source Anwendung auf eine Cloud Umgebung migriert werden. Die Migration erfolgt dabei entlang eines bestehenden Migrationsansatzes der für die Migration von Softwaresystemen auf Cloud Umgebungen vorgesehen ist. Als zu migrierende Anwendung wurde im Vorfeld der Arbeit das Open-Source ERP-System ADempiere (vgl. Kapitel 2.4.2) gewählt. Der Ansatz zur Migration ist der von [Frey und Hasselbring 2011] beschriebene Ansatz CloudMIG (vgl. Kapitel 2.3). Die Migration soll mit Eucalyptus (vgl. Kapitel 2.4.1) auf eine ebenfalls quelloene IaaS-basierte Cloud Umgebung erfolgen. Im folgenden sollen die Probleme, die während der Fallstudie auftraten, untersucht werden. Selbiges gilt für ein mögliches Optimierungspotenzial von ADempiere bezüglich Eucalyptus. 8

1 Motivation 1.3 Aufbau der Arbeit Kapitel 2 gibt eine Übersicht über wesentliche, die Arbeit betreende Grundlagen. Unter anderem werden zentrale Begrie wie der des Cloud Computing und der Migration von Softwaresystemen und der Ansatz, nach dem die Migration durchgeführt wird, erläutert. Daraufhin folgt in Kapitel 3 eine Beschreibung der durchgeführten Migration. Es werden die einzelnen Schritte im Vorgehen gemäÿ dem verwendeten Migrationsansatz beschrieben sowie die Ergebnisse zusammengefasst. Anschlieÿend ndet sich in Kapitel 4 eine Analyse der bei der Migration aufgetretenen Probleme. Dabei wird anhand einer Analyseschablone jedes Problem genau untersucht und auf mögliche Lösungen hingewiesen. Ähnlich dem vorangegangenen Abschnitt ndet in Kapitel 5 eine Analyse des möglichen Optimierungspotenzials der migrierten Anwendung statt. Abschlieÿend erfolgt in Kapitel 6 eine Zusammenfassung der gewonnenen Erkenntnisse sowie ein Ausblick auf zukünftig mögliche Forschungsarbeiten. 9

2 Grundlagen 2.1 Cloud Computing Der Begri des Cloud Computing wird auf viele verschiedene Arten deniert. Eine der gängigsten Denitionen und gleichzeitig die, die dieser Arbeit zu Grunde liegt, ist die des National Institute of Standards and Technology (NIST): Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of congurable computing resources [...]. This cloud model promotes availability and is composed of [...] three service models, and four deployment models. [Mell und Grance 2009, S.1] Durch das Cloud Computing werden demnach verschiedenste Ressourcen ihren Nutzern über ein Netzwerk zur Verfügung gestellt. Unterschieden wird dabei, ob Anwendungen, Plattformen oder Infrastrukturen als Dienst zur Verfügung gestellt werden. In diesem Zusammenhang ndet daher eine Einteilung in drei service models, nachfolgend Dienstmodelle genannt, statt. Diese Dienstmodelle sind Software as a Service (SaaS), Platform as a Service (PaaS) und Infrastructure as a Service (IaaS). Zur Einteilung in die verschiedenen Dienstmodelle existiert eine Darstellung von Lenk et al. [2009], die unter anderem jedes der Modelle als eine Schicht darstellt und zusätzlich Beispiele für den jeweiligen Dienst nennt. Die Abbildung 2.1 zeigt einen Auszug aus dieser Darstellung die sich auf die drei genannten Dienstmodelle beschränkt. 10

2 Grundlagen Abbildung 2.1: Die Dienstmodelle des Cloud Computing nach [Lenk et al. 2009]. Eine weitere Unterscheidung ist laut Denition die in vier verschiedene, im Folgenden als Verwendungsmodelle bezeichnete, sogenannte deployment models. Dieses ist zum einen die private cloud, bei der die Cloud Umgebung von einer einzigen Organisation betrieben und genutzt wird. Des weiteren die community cloud, welche gemeinschaftlich von interessensgleichen Organisationen betrieben und genutzt wird. Als drittes Verwendungsmodell existiert die public cloud, bei der die Cloud Umgebung der Öentlichkeit zur Verfügung steht, jedoch nur einem Unternehmen gehört. Und schlieÿlich die hybrid cloud, eine Cloud Umgebung die eine Mischung von zwei oder mehr Verwendungsmodellen darstellt [Mell und Grance 2009; Ryan und Loeer 2010]. Ein groÿer Vorteil des Cloud Computing besteht darin, dass die für den jeweilige Dienst 11

2 Grundlagen benötigten Ressourcen abhängig vom aktuellen Bedarf in Anspruch genommen werden können [Zhang et al. 2010, S.9]. Idealerweise kann die Nutzung von Ressourcen so in Abhängigkeit des Workloads der betriebenen Anwendung automatisch angepasst werden. In Folge dessen ist nicht nur der Ressourcenverbrauch abhängig vom Workload, sondern vor allem auch die verursachten Kosten. Dies liegt daran, dass die Ressourcen dem Payper-Use Modell [Weinhardt et al. 2009] folgend abgerechnet werden. Im Gegensatz dazu verursacht ein gekaufter oder gemieteter Server im traditionellen Rechenzentrumsbetrieb durchgehend Kosten, auch wenn er gerade nicht genutzt wird. Durch die im Cloud Computing anzutreenden positiven Skaleneekte tritt bei den Anbietern von Cloud Umgebungen ebenfalls eine Kostenersparnis ein [Pavel und Mattes 2010], die als Preisvorteil an die Nutzer weitergegeben werden kann. Der Unterschied zwischen dem traditionelle Rechenzentrumsbetrieb und einem virtuellen Server innerhalb einer IaaS-basierten Cloud Umgebung wird in Abbildung 2.2 deutlich. Die orange Schraur deutet jeweils überschüssige Ressourcen an, während die rote Schraur einen Mangel an Ressourcen aufzeigt. Abbildung 2.2(a) zeigt einen Server mit starren Ressourcen und schwankendem Workload, bei dem das Problem der Unterdimensionierung von Ressourcen auftritt, wodurch der Workload in diesen Fällen nicht mehr bewältigt werden kann. In Abbildung 2.2(b) ist der für das Cloud Computing typische variable Verbrauch von Ressourcen und schwankender Workload zu sehen. Die Ressourcen sind an den Workload angepasst, so dass ihr Überschuss gering ausfällt und eine Unterdimensionierung nicht eintritt. 12

2 Grundlagen (a) Starre Ressourcen. (b) Variable Ressourcen. Abbildung 2.2: Starre, unterdimensionierte Ressourcen (a), im Vergleich zu variablen Ressourcen im Cloud Computing(b) (angelehnt an [Armbrust et al. 2010]). 2.2 Migration von Softwaresystemen Der Begri der Migration eines Softwaresystems spielt, neben dem des Cloud Computing, im Rahmen dieser Bachelorthesis eine zentrale Rolle. Migration bezeichnet die Überführung eines Softwaresystems in eine andere Zielumgebung. [...] Das zu migrierende Altsystem beschreibt eindeutig die Systemfunktionalität, deren Erhalt nach erfolgreicher Migration durch Regressionstests überprüft werden kann. [Gimnich und Winter 2005, S.1] Die Migration stellt somit einen Weg dar, ein Softwaresystem an geänderte Anforderungen anzupassen, dabei jedoch die Funktionalität beizubehalten. Eine solche Anforderung 13

2 Grundlagen ist der Wunsch, dass zum Beispiel ein Subsystem eines Softwaresystems, oder gar das ganze System, neue Technologien unterstützt. Beispielhaft dafür ist die Portierung auf ein neues Betriebssystem. Alternativ zu einer solchen Migration wäre die komplette Neuentwicklung der Software, die in der neuen Zielumgebung lauähig sein soll. Gegenüber einer Migration ergibt sich jedoch ein erheblich gröÿerer zeitlicher wie auch monetärer Aufwand. Begründet ist dies darin, dass bei einer Migration der Groÿteil des alten Quellcodes wiederverwendet wird [Bisbal et al. 1997]. Auch das Cloud Computing stellt eine Technologie dar, die ein Auslöser für eine Migration sein kann. 2.3 CloudMIG Der Ansatz CloudMIG von [Frey und Hasselbring 2010] beschreibt die Grundzüge eines Verfahrens zur Durchführung einer Migration eines Softwaresystems auf eine Cloud Umgebung. Da es sich bei CloudMIG um ein modellbasiertes Vorgehen handelt, ist das Vorhandensein eines Modells der Cloud Umgebung und des zu migrierenden Softwaresystems eine wichtige Voraussetzung für die Migration. In Abbildung 2.3 wird dieser Ansatz skizziert. Abbildung 2.3: Das Vorgehen bei einer Migration nach dem Ansatz CloudMIG [Frey und Hasselbring 2010]. 14

2 Grundlagen Wie in der Abbildung zu sehen, sind die wesentlichen Schritte dabei zunächst die Extraktion eines Modells aus der Altanwendung sowie die Modellierung der Cloud Umgebung als Instanz des Cloud Environment Model (vgl. Kaptiel 2.3.1). Anhand dieser Modelle ndet eine Überprüfung auf Verletzungen von Cloud Environment Constraints (vgl. Kapitel 2.3.2) der zu migrierende Anwendung statt. Das alte Softwaresystem wird dann schlieÿlich Schritt für Schritt an die Cloud Umgebung angepasst. 2.3.1 Das Cloud Environment Modell (CEM) Das Cloud Environment Model nach [Frey und Hasselbring 2011] ist ein auf dem Knowledge Discovery Meta-Model (KDM) 1 aufbauendes Modell zur Beschreibung einer Cloud Umgebung. Das CEM modelliert wesentliche Belange einer Cloud Umgebung und wird bei dem Ansatz CloudMIG für jeden speziellen Cloud Provider zur Vorbereitung der Migration instanziiert. Wie in Abbildung 2.4 dargestellt wird, ist das Modell aus geschichteten Paketen aufgebaut. Eine CEM Instanz für eine (IaaS-basierte) Cloud Umgebung beschreibt zum Beispiel die Infrastruktur der Cloud Umgebung, aber auch die für die Cloud Umgebung formulierten Cloud Enviroment Constraints. Abbildung 2.4: Die Pakete des Cloud Environment Models (CEM) [Frey und Hasselbring 2011]. 2.3.2 Cloud Environment Constraints (CEC) und CEC Violations Jede Cloud Umgebung bietet unterschiedliche Funktionen an, wodurch sich verschiedene Beschränkungen (Constraints) ergeben, die von ihr auferlegt werden. Es lassen sich demzufolge für jede Cloud Umgebung Beschränkungen beschreiben, die eine Anwendung, welche auf dieser Umgebung lauähig sein soll, einhalten muss. Im Zuge der Migration einer Anwendung auf eine Cloud Umgebung können diese Cloud Environment Constraints (CECs) unter Umständen verletzt werden, in diesem Fall spricht man von einer CEC 1 Knowledge Discovery Meta-Model (KDM) - http://www.omg.org/spec/kdm/1.1/ 15

2 Grundlagen Violation. Unterteilt werden diese CEC Violations in ihren Schweregrad, der sich wiederum nach dem Aufwand zur Beseitigung der Verletzung durch Reengineering-Maÿnahmen richtet. Es wird daher zwischen Breaking (hoher Aufwand), Critical (mittlerer Aufwand) und Warning (geringer Aufwand) unterschieden [Frey und Hasselbring 2011]. 2.4 Verwendete Software 2.4.1 Eucalyptus Eucalyptus ist ein quelloenes Cloud Computing Framework. Mit Hilfe von Eucalyptus lässt sich eine IaaS-basierte private Cloud Umgebung erzeugen. Die von Eucalyptus erzeugte Cloud Umgebung besitzt eine Reihe von Parallelen zur Cloud Umgebung von Amazon. Eucalyptus implementiert die Spezikationen für Amazons Cloud Umgebung EC2 (Elastic Compute Cloud) sowie die Dienste zur persistenten Speicherung S3 (Simple Storage Service) und EBS (Elastic Block Store) und ist zudem konform zur Syntax und Semantik der Amazon API und deren Tool-Suite. So erlaubt Eucalyptus wie auch Amazons EC2 das Starten von Instanzen im Sinne von virtuellen Machinen. Eine solche Instanz setzt sich im wesentlichen aus den drei Bestandteilen Eucalyptus Kernel Image (EKI), Eucalyptus Ramdisk Image (ERI) und Eucalyptus Machine Image zusammen. Der Verbund dieser drei Images lässt sich beliebig oft als eigenständige Instanz starten. Jede dieser Instanzen hat dabei ihre eigene private IP-Adresse und erlaubt so per SSH den Zugri. Das Äquivalent zu Amazons S3 stellt Walrus dar. Walrus ermöglicht das persistente Speichern von Daten in Form von sogenannten Buckets. Der Zugri auf ein solches Bucket ist von mehreren laufenden Eucalyptus Instanzen gleichzeitig möglich. Damit ermöglicht Walrus das Verwenden von gemeinsam genutzten Daten. Walrus verwendet zum Ablegen/Abrufen von Daten eine Put/Get-Semantik und lässt sich daher nur unter Verwendung zugehöriger Werkzeuge bedienen. Der ebenfalls in Eucalyptus vorhandene Dienst EBS bietet eine weitere Form der persistenten Speicherung an. Der Zugri auf ein EBS Volumen erfolgt jedoch nicht über spezielle Werkzeuge. Ein erzeugtes EBS Volumen kann wie ein physischer Datenträger formatiert und in das lokale Dateisystem einer Eucalyptus Instanz eingebunden werden. EBS Volumen können aber aus diesem Grund im Gegensatz zu Walrus Buckets nur von jeweils einer laufenden Instanz zur Zeit genutzt werden. Solche Dienste zur persistenten Speicherung sind notwendig, da eine laufende Eucalyptus Instanz nur die Möglichkeit einer transienten Speicherung bietet und Änderungen an Daten innerhalb einer Instanz beim Beenden dieser verloren gehen [Nurmi et al. 2009]. Eine Eucalyptus Cloud Umgebung dient im Rahmen der nachfolgenden Fallstudie (vgl. Kapitel 3) als Migrationsziel. 16

2 Grundlagen 2.4.2 ADempiere ADempiere ist ein Open-Source ERP-System, das nach dem Prinzip der Commons-based Peer Production [Benkler 2005] durch die Open-Source Gemeinschaft entsteht. Es ist in Java geschrieben und besitzt ca. 1,3 Mio. Zeilen Java Code. ADempiere besitzt als Client- Anwendung sowohl eine Web-GUI, als auch eine Java-GUI. Die Umsetzung der Java-GUI erfolgt mit Hilfe von Java Web Start. Von ADempiere gibt es mit ADempiere Cloud ERP 2 bisher lediglich eine kommerzielle Cloud-Portierung. ADempiere dient in der durchgeführten Fallstudie als zu migrierende Anwendung. 2.4.3 MoDisco MoDisco (Model Discovery) ist ein Eclipse Modeling Project. Das Werkzeug MoDisco soll das Vorgehen im Reverse Engineering von Altanwendungen unterstützen. Dabei sind die Hauptfunktionen zum einen die Beschreibung von Informationen des Altsystems in Form von Modellen, zum anderen die Überführung dieser Modelle in andere Artefakte wie Quellcode oder Dokumentation. Ein mögliches Anwendungsgebiet ist daher auch die Unterstützung des Migrationsprozesses von Softwaresystemen [Brunelière und Madiot 2010]. 2.4.4 CloudMIG Xpress Das Werkzeug CloudMIG Xpress [Frey und Hasselbring 2011] dient bei dem Ansatz CloudMIG zur Unterstützung des Migrationsprozesses. Eine wichtige Funktion von Cloud- MIG Xpress ist dabei unter anderem das Überprüfen des zu migrierenden Softwaresystems auf CEC Violations bzgl. der angestrebten Cloud Umgebung. Ebenso können für ein Reengineering benötigte Modelle des Altsystems rekonstruiert werden. Der Entwicklungsstand lässt eine produktive Nutzung des Werkzeugs zum Zeitpunkt des Verfassens dieser Thesis nicht zu. 2 ADempiere Cloud ERP - http://www.catura.de/index.php/de/unsere-leistungen/cloud-erp.html 17

3 Durchführung der Migration Wie in der Einleitung angesprochen, folgt eine Fallstudie zur Evaluation von Problemen bei der Migration auf eine Cloud Umgebung. Durchgeführt wird die Migration des ERP-Systems ADempiere auf die IaaS-basierte Cloud Umgebung Eucalyptus unter Verwendung des Ansatzes CloudMIG. 3.1 Arbeitsumgebung Die Umgebung, in der die Migration durchgeführt wird, kann einen entscheidenden Ein- uss auf den Erfolg der Migration haben. Daher ist die Beschreibung der Arbeitsumgebung, also insbesondere der verwendeten Hard- und Software ein wichtiger Teil der Durchführung und Analyse des Migrationsprozesses. Notebook ˆ Hardware Arbeitsspeicher: 4 GB Prozessor: Intel Pentium Dual-Core CPU mit 2.00 GHz Taktfrequenz ˆ Software Entwicklungsumgebung: Eclipse 3.5.2 (Galileo) mit MoDisco v0.7 Java Versionen: Sun Java 6 und OpenJDK 6 Betriebssystem: Ubuntu 10.10-32 Bit Desktop Computer ˆ Hardware Arbeitsspeicher: 6 GB Prozessor: Intel Core 2 Quad CPU mit 2.40 GHz Taktfrequenz ˆ Software Entwicklungsumgebung: Eclipse 3.5.2 (Galileo) mit MoDisco v0.7 Java Versionen: Sun Java 6 Betriebssystem: Windows 7-64 Bit 18

3 Durchführung der Migration Der Groÿteil der Migration wurde auf dem Notebook durchgeführt, lediglich zur Modellgewinnung aus ADempiere (vgl. Kapitel 3.2) wurde auf den Desktop Computer zurückgegrien. 3.2 Extraktion eines Modells von ADempiere Ein wichtiger Teil im Migrationsansatz CloudMIG ist die Prüfung des Altsystems auf CEC Violations bezüglich der Cloud Umgebung. Dafür muss ein KDM-Modell des Altsystems, also in diesem Fall von ADempiere, vorliegen. Zum Zeitpunkt der Migration war dies nicht der Fall, daher war es nötig, dass Modell automatisiert mit Hilfe von Werkzeugen aus ADempiere zu gewinnen. Zu diesem Zweck sollte das bereits beschriebene Werkzeug MoDisco in Version 0.7 verwendet werden. Zunächst wurde die Modellgewinnung auf dem Notebook (vgl. Kapitel 3.1) gestartet. Dazu wurde die Entwicklungsumgebung Eclipse mit den Standardeinstellungen ausgeführt und der Prozess initiiert. Bereits nach kurzer Zeit meldete sich Eclipse mit einem Fehler zurück, da der zur Verfügung stehende Arbeitsspeicher nicht ausreichte. Im folgenden wurde Eclipse unter Benutzung von Parametern zur Vergröÿerung des zugewiesenen Arbeitsspeichers erneut gestartet. Auch dieses Vorgehen brachte keinen Erfolg, da Eclipse meldete, dass der Groÿteil der Rechenoperationen durch Javas Garbage Collection verursacht werde und der Vorgang daher abgebrochen werde. Dieses Verhalten von Eclipse lässt sich ebenfalls über Parameter regulieren und so wurde ein weiterer Versuch unternommen, ein KDM Modell von ADempiere zu gewinnen. Dieser Versuch wurde auf dem Desktop Rechner (vgl. Kapitel 3.1) durchgeführt, um mehr Arbeitsspeicher zur Verfügung zu haben. Doch auch diese Speichermenge reichte nicht aus. Auch eine inkrementelle Extraktion eines Modells mit MoDisco führte nicht zum Erfolg. Die Versuche der Modellgewinnung wurden daher abgebrochen (vgl. Problem P-1 [4.1]). Aufgrund der Projektgröÿe von ADempiere mit über 1 Mio. Zeilen Quellcode scheint eine automatisierte Generierung eines Modells mit den zur Verfügung stehenden Werkzeugen nicht möglich zu sein. Um diesen entscheidenden Schritt von CloudMIG durchzuführen, benötigt es entweder eines anderen Werkzeugs zur Modellgewinnung oder einer verbesserten Version von MoDisco, die mit gröÿeren Projekten problemlos arbeitet. Ob gegebenenfalls auch ein noch gröÿer gewählter Arbeitsspeicher und eine höhere Rechenleistung zum Erfolg führen, kann abschlieÿend nicht geklärt werden. 19

3 Durchführung der Migration 3.3 Modellierung von Eucalyptus Der nächste Schritt des Ansatzes CloudMIG sieht eine Modellierung der betreenden Cloud Umgebung vor. Dabei wird das aus dem Ansatz stammende Cloud Environment Metamodel instanziiert. Durch das Fehlen des Modells von ADempiere kommt der Modellierung von Eucalyptus nur noch eine untergeordnete Bedeutung zu, da dass Modell im Rahmen dieser Arbeit nur für die Überprüfung auf CEC-Violations benötigt wird. Diese kann jedoch ohne das Modell von ADempiere nicht durchgeführt werden. Da die Modellierung jedoch einen besseren Überblick über die Cloud Umgebung ermöglicht, wurde sie dennoch durchgeführt. Unter anderem wurden dabei die von Eucalyptus zur Verfügung gestellten Dienste zur persistenten Datenspeicherung EBS und Walrus modelliert. Ebenfalls sind im Modell die unterschiedlichen, in der Eucalyptus Umgebung eingerichteten, Instanzgröÿen beschrieben worden, welche sich etwa in der Anzahl der CPUs oder des vorhanden Systemspeichers unterscheiden. Die Anzahl an modellierten Cloud Environment Constraints el gering aus. Der IaaS-Ansatz legt einer Anwendung, die in der Cloud Umgebung lauähig sein soll, nur wenige Bedingungen auf. Modelliert wurde unter anderem die transiente Speicherung von Daten, die die Nutzung eines Dienstes zur persistenten Speicherung bedingt. Ein kurzer Auszug ist im Quellcode-Ausschnitt 3.1 zu sehen. Anzumerken ist, dass sich bei der Migration auf eine PaaS-basierte Cloud Umgebung mehr Constraints ergeben würden. Hier kämen Constraints hinzu, die beispielsweise aus der in der Cloud Umgebung vorhanden Software resultieren. Weitere Constraints ergäben sich aus Restriktionen der Cloud Umgebung an sich. Ein Beispiel dafür wäre die fehlende Unterstützung von Remote Method Invocation (RMI) in der Google App Engine for Java. 20

3 Durchführung der Migration 1 <?xml version=" 1. 0 " encoding="utf 8"?> <c l o u d p r o f i l e : C l o u d E n v i r o n m e n t [... ] providername=" Eucalyptus "> 3 <environmentconfiguration> <c l o u d S e r v i c e x s i : t y p e=" i a a s : P e r s i s t e n c e C l o u d S e r v i c e " d e s c r i p t i o n= 5 "Walrus o r g a n i z e s Data in so c a l l e d Buckets. Data can be r e s o l v e d though put / get commands and i s a v a i l a b l e by m u l t i p l e i n s t a n c e s at 7 a time with concurrent a c c e s s. " i d="" name="walrus" a v a i l a b l e F r o m D i f f e r e n t L o c a t i o n s=" t r u e " 9 availablefromdifferentrealms=" t r u e " availablefromdifferentruntimecontainers=" t r u e " 11 c o n c u r r e n t L o c a t i onaccess=" t r u e " concurrentrealmaccess=" t r u e " concurrentruntimecontaineraccess=" t r u e "/> 13 [... ] <c o n s t r a i n t C o n f i g u r a t i o n> 15 [... ] <c o n s t r a i n t x s i : t y p e=" c o n s t r a i n t : L o c a l T r a n s i e n t S t o r a g e C o n s t r a i n t " id="" 17 d e s c r=" Storage on an Eucalyptus I n s t a n c e i s t r a n s i e n t. Changes to the i n s t a n c e s f i l e s y s t e m get l o s t on t e r m i n a t i o n o f the i n s t a n c e. " 19 name=" TransientSpace "> <p r o p o s e d S o l u t i o n s o l u t i o n="use e i t h e r Eucalyptus Block Storage (EBS) 21 and mount i t as l o c a l f i l e s y s t e m or use Walrus to put / get f i l e s on/ from an e u c a l y p t u s i n s t a n c e. "/> 23 </ c o n s t r a i n t> [... ] 25 </ c o n s t r a i n t C o n f i g u r a t i o n> [... ] 27 <hardwareconfiguration name=" c1. medium"> <subresourcetype x s i : t y p e=" iaas:memory " s i z e=" 1024 " u n i t="mb"/> 29 <subresourcetype x s i : t y p e=" i a a s : S t o r a g e " s i z e="10" u n i t="gb"/> <subresourcetype x s i : t y p e=" iaas:cpu " frequency=" 2,7 " u n i t="ghz"/> 31 <subresourcetype x s i : t y p e=" iaas:cpu " frequency=" 2,7 " u n i t="ghz"/> </ hardwareconfiguration> 33 [... ] </ environmentconfiguration> 35 </ c l o u d p r o f i l e : C l o u d E n v i r o n m e n t> Quellcode-Ausschnitt 3.1: Auszug aus dem CEM Modell von Eucalyptus. 21

3 Durchführung der Migration 3.4 Prüfung auf CEC-Violations Da mit dem Modell der Altanwendung ein entscheidender Teil fehlt, um die Prüfung von ADempiere auf CEC-Violations bezüglich Eucalyptus durchzuführen, ist dieser Schritt nicht möglich. Dies hat zur Folge, dass der Ansatz CloudMIG an dieser Stelle (bzw. schon bei der Modellgewinnung) scheitert. Daraus wird die essenzielle Abhängigkeit des Ansatzes von den Modellen ersichtlich. Die Migration selbst kann natürlich weiterhin durchgeführt werden, sie verläuft jedoch ohne Vorwissen im Bezug auf mögliche Schwierigkeiten. 3.5 Manuelle Migration von ADempiere auf Eucalyptus Da die Migration auf eine Instanz von Ubuntu 9.04 erfolgen soll, wurde zunächst ein entsprechendes Paket aus Eucalyptus Kernel Image (EKI), Eucalyptus Ramdisk Image (ERI) und Eucalyptus Machine Image (EMI) von der Eucalyptus Website heruntergeladen. Um sich mit den Werkzeugen von Eucalyptus vertraut zu machen, wurde nun zunächst das unveränderte Machine Image auf den Eucalyptus Server hoch geladen und den bereits vorhandenen passenden Kernel und Ramdisk Images zugewiesen. Dann erfolgte ein erster Start einer Instanz des Images. Das unveränderte Image startete innerhalb der Cloud Umgebung problemlos und ein Einwählen mit Hilfe von SSH in die laufende Instanz war ohne weiteres möglich. Ein zentraler Unterschied zwischen IaaS und PaaS bzw. SaaS ist, dass die benötigte Software (z.b. ein Java JRE) bei IaaS zunächst von Hand installiert werden muss und nicht bereits vorhanden ist. Da für das Betreiben von ADempiere verschiedenste Software im System vorhanden sein muss, wurde diese im nächsten Schritt im verwendeten Machine Image installiert um diese Abhängigkeiten zu erfüllen. Zunächst wurde daher die Gröÿe des Images verändert, um genügend Platz für die benötigten Anwendungsprogramme zu schaen. Das Image wurde von einer Ausgangsgröÿe von 1000 MB auf eine Gröÿe von 5 GB erweitert. Danach wurde das Image in das lokale Dateisystem der Arbeitsumgebung eingebunden und anschlieÿend wurde mit Hilfe von Chroot das Rootverzeichnis auf das des Images abgeändert. Auÿerdem wurden der Chroot-Umgebung die benötigten Dateien und Verzeichnisse zur Verfügung gestellt um ihr beispielsweise einen Internetzugri für das Herunterladen von Software zu ermöglichen. Daraufhin wurden die notwendigen Paketquellen freigeschaltet, in denen sich die zu installierende Software bendet. Nach einer Aktualisierung der Paketquellen erfolgte schrittweise die Installation der Software. Es wurden Pakete für die deutsche Sprachunterstützung installiert um das System zu lokalisieren. Danach folgte die Installation des 22