Machbarkeitsstudie zur Implementierung von Anwendungsvirtualisierung/Cloud Computing zur Nutzung eines Kreditrisikosystems an internationalen Standorten
Aus Winfwiki
| Name des Autors / der Autoren: | Julia Gurowietz |
| Titel der Arbeit: | "Machbarkeitsstudie zur Implementierung von Anwendungsvirtualisierung/Cloud Computing zur Nutzung eines Kreditrisikosystems an internationalen Standorten" |
| Hochschule und Studienort: | FOM Essen |
Inhaltsverzeichnis |
1 Einleitung
Diese Fallstudie befasst sich mit der Machbarkeit einer Implementierung eines in Deutschland bereits genutzten Kreditrisikosystem auf internationaler Ebene unter Berücksichtigung von Anwendungsvirtualisierung oder Cloud Computing im Sommersemester 2010 an der Fachhochschule für Ökonomie und Management und wird betreut von Dipl.-Inf. Christian Schäfer.
Hierbei soll eine Studie angefertigt werden, die entsprechende Möglichkeiten überprüft um das Projektziel, also die Nutzung eines Kreditrisikosystems an internationaken Standorten, zu erreichen. In diesem Fall wird die Studie als Vorprojekt durchgeführt.
2 Grundlagen
2.1 Anwendungsvirtualisierung
Virtualisierung ist kein neues Verfahren. Bereits Ende der fünfziger Jahre beschrieb Christoph Strachey in seinem Buch "Time Sharing in Large fast Computer" das Konzept des Multitaskings. 1967 baut IBM den Vorläufer eines virtuellen Systems auf Mainframes. 1999 bringt VM Ware Inc. die ersten Virtualisierungsprodukte auf den Markt [1]
 |
Virtualisierung in einem Satz zu beschreiben ist fast unmöglich. Viele Hersteller von Virtualisierungsmethoden haben eigene Definitionen von Virtualisierung. Dahinter verstecken sich eine Reihe von Technologien. In der Regel handelt es sich um Methoden (entweder Soft- oder Hardwarebasiert) bei denen entweder Server-Ressourcen aufgeteilt werden oder mehrere Einheiten zusammengefasst werden.
Beispiele hierfür sind z.B. einen Server in mehrere virtuelle Rechner zu unterteilen oder mehrere Betriebssysteme laufen auf einem Server. Fasst man mehrere physikalische Server zu einer virtuellen Maschine zusammen, so nennt man das Grid. Hier wird ein großes virtuelles System simuliert das aber aus vielen kleineren Maschinen besteht.
Virtualisierungsarten
Es gibt unterschiedlichste Arten von Virtualisierung:
Hardware-Emulation
Hierbei wird die komplette Hardware eines Systems nachgebildet. Dazu wird der CPU Befehl übersetzt wodurch die Geschwindigkeit leidet und dadurch wesentlich langsamer sind als virtualisierte Maschinen.
Servervirtualisierung
Bei diesem Verfahren wird die logische Ebene (Benutzeroberfläche) von der physischen Ebene (Anwendungsausführung) getrennt. Hierbei wird die Anwendung zu 100 % auf einem zentralen Server installiert und ausgeführt. Dem Anwender steht dabei die ge-wohnte Applikationsoberfläche zur Verfügung, seine Eingaben werden im Hintergrund an den Server übertragen. Zum Anwender wird der Bildschirminhalt übertragen. Vor-aussetzung hierfür ist eine Netzwerkverbindung zwischen Client und Server.
Betriebssystemvirtualisierung Hierbei werden alle gleichen Betriebssystemdaten von den Gästen mitgenutzt. Abwei-chende Daten liegen im Heimatverzeichnis der Virtual Machine. Dadurch wird deutlich weniger Festplatten- und Hauptspeicherkapazität benötigt als ein normal installierter Server. Bei dieser Technik ist der Schwund durch die Virtualisierung relativ gering ist (1-3 %) bei hoher Ausnutzung von Systemressourcen.
Citrix XenApp
Aufgrund von Unternehmensvorgaben muss bei der Entscheidung für Applikationsvirtualisierung die Software Citrix XenApp eingesetzt werden. Diese Software ist bereits im Unternehmen eingesetzt und über einen Unternehmensvertrag lizensiert. Damit sind die Lizenzen wesentlich billiger als wenn das Unternehmen einen Einzelvertrag schließen müsste.
Citrix System Inc hat seinen Hauptsitz in Fort Lauderdale (USA) und wurde 1989 von Ed Lacobucci gegründet. In erster Linie ist Citrix durch Applikations-und Terminalser-veranwendungen bekannt geworden. Seit 1997 arbeiten Citrix und Microsoft zusam-men. Citrix XenApp (früher Citrix Presentation Server) ist die Terminalserver-Lösung der Firma Citrix.XenApp verlagert die Anwendungen ins Rechenzentrum, dort können sie zentral verwaltet werden und den Benutzern an verschiedenen Unternehmensstand-orten zur Verfügung gestellt werden. Citrix XenApp bietet sogenannte Published Appli-cations.
Hierbei werden dem Nutzer einzelne Anwendungen zur Verfügung gestellt, die sich wie lokale installierte Programme verhalten. Eine Clientinstallation ist überflüssig, dass heißt, die Applikation muss nur einmal auf den zentralen Servern installiert und eingerichtet werden. Hierdurch werden teure und monatelange Software-Rollouts ver-mieden. Unternehmensstandorten z.B. in verschiedenen Ländern können hierdurch zent-ral administriert werden. Alle Nutzer greifen auf einheitliche Softwareversionen zu und die Administratoren können verhindern, dass Unternehmensinformationen auf den unsi-cheren Endgeräten gespeichert werden.
Anwender können auch per Internet z.B. im Homeoffice auf die Applikation zugreifen. Die Anwendung läuft komplett auf dem Server, nur der Bildschirminhalt wird auf den Client übertragen. Durch die Funktion „Shadowing“ (Spiegelung) kann der Support den Bildschirm des Anwender ansehen und ihm bei der Problembeseitigung helfen. Auf dem Bildschirm des Anwenders erscheint je nach Konfiguration des Administrators ein Fenster welches er bestätigen muss. Erst nach Bestätigung kann der Administrator auf den Bildschirm des Users schauen und auch tätig werden. Während der gesamten Spiegelung erinnert ein kleiner Bildschirm den Anwender, dass seine Session gerade von einem anderen PC beobachtet wird.
 Shadowing |
Hierdurch kann auch der Support für die Anwendungen zentralisiert an einem anderen Ort stationiert sein.
Seit 2007 ist die Möglichkeit des Anwendungsstreaming in XenApp implementiert. Hierbei werden Anwendungen als Pakete zur Verfügung gestellt. Beim Öffnen der Ap-plikation wird das Paket automatisch heruntergeladen und das Programm kann lokal ausgeführt werden. Gestreamte Anwendungen verwenden Systemressourcen auf dem Client-PC. Die so veröffentlichten Anwendungen können auch offline verwendet wer-den.
2.2 Cloud Computing
Wie schon beim Thema Anwendungsvirtualisierung gibt es auch beim Thema Cloud Computing keine einheitliche Definition. Hierbei handelt es sich um Dienste die in der Regel im Web verfügbar sind und in Form von Plattformen, Anwendungen und IT-Infrastruktur von einem Provider bereit gestellt wird. [3]
Dahinter steht die Idee der unerschöpflichen IT-Ressourcen die bei Bedarf zur Verfügung steht. Natürlich sind auch die Ressourcen in einer Cloud Computing Umgebung begrenzt, allerdings sind diese sehr flexibel und passt sich den Anforderungen des Kundens an.
Die Bereitstellung über einen Provider und im Web nennt man Public Clouds. Es existiert ebenfalls die Möglichkeit eine sogenannte Private Cloud zu betreiben. Hier befindet sich die Cloud im firmeninternen Netzwerk.
In der Public Cloud können User z.B. über einen Webbrowser im Internet auf Anwendungen zugreifen. Die Abrechnung erfolgt wie z.B. beim Stromlieferanten, nur nach dem tatsächlichen Verbrauch. Die Nutzer können überall dort zugreifen wo ein Internetzugang verfügbar ist.
Für neu gegründete Unternehmen sind die Einsparungspotenziale enorm, da nur geringe Investitionen in Bezug auf Hardware und Infrastruktur notwendig sind.
Innerhalb der Cloud wird häufig Servervirtualisierung verwandt. Dadurch können auch mehrere Applikationen unterschiedlicher Unternehmen auf einem Server stehen. Prozesse können allerdings auch parallel auf mehreren Maschinen laufen, wodurch gerade zeitintensive und rechenintensive Analysen oder Bild- und Videoverarbeitung schneller abgearbeitet werden können.
Ein größte Problem liegt allerdings im Bereich Sicherheit. Die rechtliche Situation ist ungeklärt, gerade im Bezug auf personenbezogene Daten.
Im Bereich Cloud Computing unterscheidet man mehrere Dienste:
SaaS - Software as a Service:
Bei SaaS wird eine Applikation im Internet bereitgestellt und kann durch den Anwender über einen Webbrowser aufgerufen werden. Dadurch können auch User mit einem Internetzugang die sich nicht im firmeneigenen Netz bewegen jederzeit auf die Software zugegriffen werden. Dabei wird nur die tatsächlich genutzte Zeit bzw. die tatsächlich genutzten Ressourcen bezahlt. Eine Installation auf den lokalen PCs ist nicht notwendig und auch Applikationen die auf dem Client eigentlich nicht mehr ausgeführt werden können, z.B. weil die Hardware den Anforderungen nicht mehr entspricht, können genutzt werden.
Infrastructure as a Service
Hierbei wird eine komplette Infrastruktur als Service zur Verfügung gestellt. Dabei können die Administratoren des Unternehmens die virtuellen Maschinen selber administrieren und installieren. Die Infrastruture kann sehr flexibel an die Bedürfnisse des Kundens angepasst werden.
Diese Art des Cloud Computings wäre auch die Variante die in diesem Fall zum Einsatz kommen könnte.
2.3 Vorteile und Nachteile
2.3.1 Cloud Computing
Vorteile
Als großen Vorteil von Cloud Computing kann man in jedem Fall die geringeren Kosten nennen. Je nach gewählter Cloud-Computing-Art kann man nicht nur die Infrastruktur, also Server, Maschinen etc. sondern auch IT-Personal einsparen.
CloudComputing ist sehr flexibel und lässt sich sehr kurzfristig auf neue Anforderungen anpassen.
Wo immer Internet verfügbar ist, kann man auch auf die Applikation zugreifen.
Nachteile
Ein Vorteil ist leider auch ein Nachteil des Cloud Computings. Ist kein Internet vorhanden, ist die Applikation auch nicht verfügbar.
Da die Daten bei einem fremden Anbieter liegen, hat man wenig Einblick wo die Daten gespeichert sind und wer Zugriff auf die Daten haben könnte.
Die Performance könnte ein Problem werden, wenn das Internet wie in unserem Fall immer wieder Schwankungen unterliegt.
2.3.2 Anwendungsvirtualisierung
Vorteile
Im Bereich Anwendungsvirtualisierung können mehrere Versionen in einer Umgebung koexistieren. Das heisst, dass sowohl Test und Produktionsversionen der Applikation auf einer Maschine existieren können.
Ein weiterer Vorteil ist das sogenannte Loadbalancing. Hierbei arbeiten einige Maschinen in einem Verbund. Für den Anwender wird nicht deutlich, dass es sich um mehrere Maschinen handelt. Hierbei kann der Administrator einzelne Maschinen aus dem Verbund entnommen werden und seperat bearbeitet werden. Zusätzlich werden die Anwender automatisch auf Maschinen geroutet die momentan weniger ausgelastet sind als die anderen.
Dadurch das die Applikation nicht mehr lokal installiert wird, wird der Administationsaufwand deutlich geringer. Die Maschinen können einzeln aus dem Verbund entnommen werden und seperat installiert werden und wieder in den Verbund geschoben werden. Dadurch sind praktisch keine Downtimes mehr nötig.
Nachteile
Die Server haben natürlich höhere Anforderungen als ein normaler Clientrechner. Server müssen in speziellen Räumen gelagert werden und Klimaanlagen sind notwenig um die Maschinen zu kühlen. Zusätzlich sind spezielle Supportverträge mit dem Hersteller notwendig um die Hochverfügbarkeit zu gewährleisten. Das heisst, dass z.B. eine kaputte CPU innerhalb von 4 Stunden ausgetauscht werden muss. Diese Supportverträe sind natürlich kostspieliger als ein normaler Support für einen Client-PC.
Es gibt auch Applikationen die sich nicht zur Virtualisierung eignen oder die speziell angepasst werden müssen um virtualisiert werden zu können.
Ein weiterer Punkt ist, dass Enterpriselizenzen natürlich teurer sind als Standardeinzeluser-Lizenzen. Damit sind insgesamt die Anschaffungskosten insgesamt teurer.
3 Ausgangssituation
3.1 Die Applikation
 |
Das Kreditrisikosystem EnergyCredit ist seit 2005 erfolgreich in dem deutschen Teil des Handelszweigs des Unternehmens im Einsatz. Die Applikation ist bislang auf den Clients in Essen/Deutschland lokal installiert und greift auf eine SQL2000 Datenbank zu. Momentan greifen 80 lokale User auf die Software zu,
EnergyCredit ist ein Produkt der Firma Temenos. Die Applikation wurde allerdings genau auf die Zwecke des Unternehmens angepasst und hat mit der Standardinstallation nicht mehr viel zu tun.
Bei EnergyCredit handelt es sich um eine modular aufgebaute Applikation und besteht aus den folgenden Teilapplikationen die untereinander kommunizieren:
Legal
Bevor überhaupt mit den Handelspartnern gehandelt werden darf, wird ein Vertrag abgeschlossen, der die wesentlichsten Grundlagen des Handels regelt. Dabei können einzelne Verträge für jedes Gut (z.B. einen Vertrag für Strom, einen Vertrag für Gas u.s.w.) oder sogenannte Cross Product Verträge (Verträge die den Handel mit mehreren Produkten umfassen) abgeschlossen werden. Um den Abschluss von Verträgen zu beschleunigen, greift man gerne auf Standardverträge zurück wie zum Beispiel von EFET.
Diesen Verträgen liegen die unterschiedlichsten Vereinbarungen zugrunde. Es gibt einige standardisierte Verträge(z.B. das Cross Product Master Agreement oder das Umbrella Agreement [Fussnote]) aber auch Einzelverträge sind möglich. Die Verträge werden hierbei in einem Art Dokumentenmanagementsystem als PDF abgespeichert sowie unterschiedlichen Informationen wie den Unternehmens-Ansprechpartnern. Die Verträge können klassifiziert werden und in einer Art Vier-Augen-Prizip vom Vorgesetzten freigegeben werden.
ScoringDesktop
Im ScoringDesktop wird der interne Kreditrisikoprüfprozess des Unternehmens abgebildet. Hierzu können die Handelspartner in Bezug auf ihre Kreditwürdigkeit geprüft werden und anhand vieler eigens entwickelter Kennzahlen geratet werden.
Aufgrund dieses Ratings und weiterer Faktoren wird dann ein entsprechendes Handelslimit festgelegt. Dieses Limit legt den Bereich fest innerhalb dessen der Handelspartner mit Unternehmens handeln kann. Diese Limite werden mindestens jährlich, teilweise aber aufgrund von anderen Ereignissen unterjährig durchgeführt (z.B. Inhaberwechsel, Ratingherabstufung einer großen Ratingagentur etc.).
Die Limite werden anschließend je nach Höhe vom entsprechenden Abteilungsleiter, der Geschäftsführung, oder bei sehr hohen Beträgen, vom Vorstand im System genehmigt. Die Formulare können selbst gestaltet werden, so dass die oftmals geheimen Ratingmethoden komplett selbst umgesetzt werden können ohne den Hersteller in diesen Prozess einbeziehen zu müssen.
UCExplorer
Der UCExplorer beinhaltet alle Handelspartner-Stammdaten. Hier kann der Kreditanalyst in der Handelspartnerform alle wichtigen Informationen den Handelpartner betreffen auf einen Blick einsehen. Hierzu gehören z.B. Adressdaten, die Ratings anderer großer Ratingagenturen und die internen, im Scoring Desktop vergebenen Limite, die genehmigten Limite, der zuständige Kreditanalyst und den Handelspartner betreffende Dokumente. Weiter können im UCExplorer durch die IT-Abteilung User angelegt werden und die User-Berechtigungen individuell angepasst werden
CollateralManagement
Für Handelspartner die nicht über ein ausreichend hohes Rating verfügen und damit ein niedriges oder garkein Limit gewährt bekommen können unter bestimmten Voraussetungen am Collateral Management teilnehmen. Hierzu müssen entweder Sicherheiten hinterlegt werden die dem Geldwert des möglichen Ausfalls entsprechen oder eine sogenannte Bankgarantie zur Verfügung stellen.
Dabei werden die hinterlegten Sicherheiten auf täglicher Basis innerhalb von EnergyCrdit mit dem Wert des Belastung verglichen. Sind die hinterlegten Sicherheiten zu niedrig muss sofort eine Zahlung über den ausstehenden Betrag gezahlt und nachgewiesen werden. Kann diese Zahlung nicht nachgewiesen werden, so wird der Handel mit sofortiger Wirkung eingestellt. Ist die Belastung niedriger, so muss seitens des Unternehmens sofort eine Rückzahlung angewiesen werden.
Innerhalb des Collateral Management Systems muss ein Vier-Augen-Prinzip angewandt werden um Beträge zur Zahlung anzuweisen. Da es sich teilweise um hohe Millionenbeträge handelt wird hierdurch sichergestellt, dass keine Manipulationen möglich sind.
Auf die eingelagerten Sicherheiten müssen jeweils am ersten des Monates Zinsen gezahlt werden, die von dem System berechnet werden und dann automatisch die Zahlung angewiesen.
3.2 Momentane Infrastruktur
Zur Zeit greifen ca. 80 lokal installierte Clients direkt auf einen SQL2000 Datenbankcluster zu.
Aufgrund der hohen Anforderungen des Fachbereiches und einer Business Impact Analyse die beschreibt wie hoch der Verlust des Unternehmens wäre wenn das System für eine bestimmte Zeit nicht zur Verfügung steht, wurde die Applikation als geschäftskritisch eingestuft. Das bedeutet, dass bei einem Ausfall mehrere Millionen Euro Verlust drohen würden. Hieraus ergibt sich eine Verfügbarkeit die per Service-Level-Agreement auf 99,5 % festgelegt wurde.
Der Zugriff erfolgt momentan innerhalb der Servicezeiten von 8:00 Uhr - 20:00 Uhr. Außerhalb dieser Servicezeiten sind angekündtigte Wartungsfenster möglich.
Aufgrund der Hochverfügbarkeit des Systems wurde durch die Geschäftsführung und durch rechtliche Vorgaben beim Collateral Management Prozess festgelegt, dass eine Desaster Recovery Umgebung in einem anderen Rechenzentrum zur Verfügung stehen muss. Im Desasterfall dürfen maximal 4 Stunden Daten verloren gehen.
 Momentane Infrastruktur Energy Credit |
4 Die Zukunft
In Zukunft soll die Applikation auf zusätzliche Standorte in London (UK), Swindon (UK), Genf (CH), Den Bosch (NL) und Singapur ausgerollt werden. Dadurch werden auf Grund der Zeitverschiebung auch andere Wartungsfenster notwendig z.B. für Singapur. Das Projekt soll bis spätestens Ende September 2010 umgesetzt werden. Insgesamt wird bis Q1/2011 ein Userzuwachs von 50 % erwartet.
5 Fazit
Die Entscheidung wurde aufgrund der vorliegenden Vor-und Nachteilen zugunsten der Anwendungsvirtualisierung getroffen. Einen großen Anteil hieran hatten vorallen Dingen die festgestellten Sicherheitbedenken. Bei den Daten die innerhalb von Energy Credit gespeichert werden handelt es sich um sehr sensible Firmendaten die in den falschen Händen nicht nur einen großßen Imageschaden für das Unternehmen auslösen kann sondern auch einen großen Wert für die Konkurrenz haben würden.
Nach einer Präsentation bei der IT-Governance wurde daraufhin die eindeutige Entscheidung für die Variante Anwendungsvirtualisierung getroffen.
Ein weiterer Pluspunkt für die Anwendungsvirtualisierung wäre die Tatsache gewesen, dass Knowhow in diesem Bereich bereits vorhanden wäre und dadurch die kurze Projektphase eingehalten werden kann.
Die Sorge, dass die Performance des Systems vorallen Dingen beim Datenaustausch leiden wurde ebenfalls als Negativpunkt für CloudComputing gewertet. Da bei der Anwendungsvirtualisierung sowohl die Daten als auch die Datenbankserver in einem Netzwerk sind und dies bereits bei der jetzigen Infrastruktur keine Probleme bereitet gehe ich von einer stabilen Performance aus. Da wir ab und zu Performanceschwankungen im Bereich Internet feststellen ist nicht ausgeschlossen, dass die Performance der gesamten Applikation leiden würde, gerade beim Upload oder beim Download von Daten.
Die zukünftige Infrasturktur ist sieht damit wie folgt aus:
 EnergyCredit Zukünftige Infrastruktur |
6 Fußnoten
- ↑ Vgl. Xen Kochbuch, Picht(2009), O'Reilly Verlag GmbH & Co. KG
- ↑ Vgl. Xen Kochbuch, Picht(2009), O'Reilly Verlag GmbH & Co. KG
- ↑ Vgl. Cloud Computing, Baun, Kunze, Nimis, Tai(2009), Springer 2009
- ↑ Vgl. http://www.energycredit-software.com/
7 Literatur- und Quellenverzeichnis
| Picht (2009) | Picht, Hans-Joachim: Xen Kochbuch, 1. Auflage, O'Reilly Verlag GmbH & Co. KG |
| Baun, Kunze, Nimis, Tai (2009) | Baun, Christian; Kunze, Marcel; Nimis, Jens; Tai, Stefan: Cloud Computing, Springer, Ausgabe Oktober 2009 |
