BACHELORTHESIS - Hochschule Ulm

Fakultät Informatik
Studiengang Wirtschaftsinformatik
BACHELORTHESIS
„Konzeption und Implementierung der Infrastruktur eines
Produktionsbetriebes auf Basis von Virtualisierung“
Von Jan Simmendinger
Arbeitsplatz SOFT-CONSULT Häge GmbH, Langenau
Erstbetreuer Prof. Dr. Achim Dehnert
Zweitbetreuer Prof. Dr. Jörg-Oliver Vogt
Abgabetermin 27. Oktober 2011

Bachelorthesis Jan Simmendinger
Eigenständigkeitserklärung
Ich versichere, dass ich die vorgelegte Abschlussarbeit eigenständig und ohne fremde Hilfe
verfasst, keine anderen als die angegebenen Quellen verwendet und die benutzten Quellen
als solche kenntlich gemacht habe. Diese Arbeit ist in dieser oder einer ähnlichen Form in
keinem anderen Prüfungsverfahren vorgelegt worden.
Ulm, den 27.10.2011 ____________________________
2

Bachelorthesis Jan Simmendinger
Danksagung
Bedanken möchte ich mich bei Herrn Prof. Dr. Achim Dehnert für die Betreuung der Arbeit.
Außerdem bedanke ich mich bei meinen Kommilitonen für die allzeit gute Zusammenarbeit
und allen Professoren der Hochschulen Ulm und Neu-Ulm, die mich während des durchweg
interessanten Studiums betreut haben.
Der Firma Soft-Consult und der Firma Mouldtec danke ich für die Unterstützung während
der praktischen Phase der Arbeit.
Meinen Eltern danke ich ebenfalls ganz besonders, weil sie mich während des Studiums stets
nach Kräften unterstützt und mir dieses dadurch überhaupt ermöglicht haben.
Zu guter Letzt möchte ich meiner Freundin Franziska danken, nicht nur für das Korrektur
lesen, sondern auch für die moralische Unterstützung über die Bearbeitungszeit hinweg.
3

Bachelorthesis Jan Simmendinger
Inhalt
1. Einleitung ......................................................................................................................................... 8
2. Definitionen ..................................................................................................................................... 9
2.1. Begriffe und Schlüsselwörter .................................................................................................. 9
2.1.1. IT-Strategie ...................................................................................................................... 9
2.1.2. Backup und Sicherungstechnologien .............................................................................. 9
2.1.3. Migration ......................................................................................................................... 9
2.1.4. Virtualisierung ............................................................................................................... 10
2.2. Eingesetzte Maschinen .......................................................................................................... 12
2.2.1. ThinClient....................................................................................................................... 12
2.2.2. SAN (Storage-Area-Network) ........................................................................................ 13
2.2.3. Terminalserver .............................................................................................................. 14
2.3. Vorgehensweisen bei der Migration ..................................................................................... 15
2.3.1. Kontinuierlicher Übergang ............................................................................................ 15
2.3.2. Iterative Migration ........................................................................................................ 15
2.3.3. Vollmigration ................................................................................................................. 16
3. Theorie .......................................................................................................................................... 17
3.1. Gründe für Hostvirtualisierung .............................................................................................. 17
3.1.1. Antrieb für die Virtualisierung von Serversystemen ..................................................... 17
3.1.2. Energie ........................................................................................................................... 17
3.1.3. Geringerer Wartungsaufwand und kürzere Bereitstellungszeiten ............................... 18
3.1.4. Erhöhte Zuverlässigkeit ................................................................................................. 19
3.1.5. Einfache Rollback- und Backupfunktionalität................................................................ 19
3.1.6. Hardwareunabhängigkeit .............................................................................................. 20
3.1.7. Ortsunabhängige Systemwartung ................................................................................. 21
3.1.8. Kapital ............................................................................................................................ 22
3.2. Gründe für die Desktopvirtualisierung .................................................................................. 22
3.2.1. Triebfedern .................................................................................................................... 22
3.2.2. Zentrale Bündelung der Ressourcen ............................................................................. 22
3.2.3. Geringere Anforderungen an die Clients....................................................................... 23
3.2.4. Vorteile bei der Datensicherung ................................................................................... 23
3.2.5. Flexible Nutzung von Anwendungen ............................................................................. 24
3.2.6. Plattformunabhängigkeit .............................................................................................. 25
4

Bachelorthesis Jan Simmendinger
3.2.7. Vereinfachte Administration ......................................................................................... 26
3.3. Virtualisierungslösungen ....................................................................................................... 26
3.3.1. ESXi und vSphere von VMWare ..................................................................................... 27
3.3.2. Microsoft Hyper-V ......................................................................................................... 27
3.3.3. Citrix XEN Server ............................................................................................................ 28
3.3.4. QEMU ............................................................................................................................ 28
3.4. Warum wird migriert ............................................................................................................. 29
3.4.1. Gründe für Erneuerung ................................................................................................. 29
3.4.2. Nachteile gewachsener Strukturen ............................................................................... 30
3.4.3. Probleme veralteter Systeme ........................................................................................ 30
3.4.4. Vorteile einer Erneuerung ............................................................................................. 31
4. Vorgehensweise bei Migrationsprojekten .................................................................................... 32
4.1. Grundlagenplanung ............................................................................................................... 32
4.1.1. Zustand der technischen Systeme und der Dokumentation ......................................... 32
4.1.2. Analyse von Aufgaben und Orientierung am Prozessmanagement.............................. 32
4.1.3. Technologischen Fortschritt nutzen .............................................................................. 33
4.1.4. Vorüberlegungen zu Alternativen im Hostbereich ........................................................ 33
4.1.4.1. Outsourcing ........................................................................................................... 33
4.1.4.2. Hostsysteme in Hardware ..................................................................................... 35
4.1.4.3. Konsolidierung von Diensten auf einem Betriebssystem ...................................... 36
4.1.5. Vorüberlegungen zu Alternativen im Desktopbereich .................................................. 37
4.1.5.1. Anwendungsvirtualisierung ................................................................................... 37
4.1.5.2. Nutzung von Diensten im Browser ........................................................................ 38
4.1.6. Projektumfang und Rahmenbedingungen .................................................................... 39
4.1.6.1. Kapital .................................................................................................................... 39
4.1.6.2. Aufwand ................................................................................................................ 40
4.1.6.3. Technische Gegebenheiten ................................................................................... 40
4.2. Konzepte ................................................................................................................................ 41
4.2.1. Ideen sammeln und bündeln ......................................................................................... 41
4.2.2. Bewertung der Konzepte und Freigabe ......................................................................... 41
4.3. Erstellung eines Projektplans ................................................................................................ 43
4.3.1. Arbeitspakete definieren ............................................................................................... 43
4.3.2. Klären von Personal- und Kompetenzfragen................................................................. 44
4.3.3. Klären von Abhängigkeiten und Erstellung des Zeitplans ............................................. 44
5

Bachelorthesis Jan Simmendinger
4.3.4. Projektdurchführung und Steuerung ............................................................................ 45
5. Praktische Umsetzung ................................................................................................................... 46
5.1. Ein Praxisbericht .................................................................................................................... 46
5.1.1. Übersicht ....................................................................................................................... 46
5.1.2. Server und Hosts ........................................................................................................... 46
5.1.2.1. APPLNX .................................................................................................................. 47
5.1.2.2. V5R3M0 ................................................................................................................. 47
5.1.2.3. APPWIN01 ............................................................................................................. 47
5.1.2.4. APPWIN02 ............................................................................................................. 48
5.1.3. ThinClients ..................................................................................................................... 48
5.1.4. Netze ............................................................................................................................. 49
5.1.5. Veralteter Internetbrowser ........................................................................................... 50
5.1.6. Zusammenfassung der Schwachstellen ......................................................................... 51
5.2. Planung der neuen Infrastruktur ........................................................................................... 51
5.2.1. Ideensammlung und Konzeptfindung ........................................................................... 52
5.2.2. Personaleinsatz.............................................................................................................. 52
5.2.3. Aufteilung der Arbeitspakete zu einem Ablaufplan ...................................................... 53
5.3. Das neue System ................................................................................................................... 54
5.3.1. Übersicht ....................................................................................................................... 54
5.3.2. Logische Übersicht über die Migration der einzelnen Server ....................................... 55
5.3.3. Übernommene Daten aus den Altsystemen ................................................................. 56
5.3.3.1. Benutzerkonten vom X-Kontroller ........................................................................ 56
5.3.3.2. Emailkonten von APPWIN01 ................................................................................. 57
5.3.3.3. Dateien vom alten Netzlaufwerk übernehmen ..................................................... 57
5.3.4. Neue ThinClients ........................................................................................................... 59
5.3.5. Storage-Lösung .............................................................................................................. 60
5.4. Die Migration ......................................................................................................................... 61
5.4.1. Vorgehensweise ............................................................................................................ 61
5.4.2. Vorbereitungen ............................................................................................................. 61
5.4.3. Inbetriebnahme der neuen Security Appliance ............................................................ 62
5.4.4. Die Hauptmigrationsphase ............................................................................................ 63
5.4.5. Aufgaben im Nachgang ................................................................................................. 64
5.4.6. Erhöhung der Benutzerakzeptanz ................................................................................. 65
5.5. Probleme und Lösungsansätze .............................................................................................. 65
6

Bachelorthesis Jan Simmendinger
5.5.1. Zuverlässigkeit ESXi ....................................................................................................... 65
5.5.2. Verwendung von IGEL UMS ........................................................................................... 67
5.5.3. Aufsetzen eines lokalen Microsoft Exchange Servers ................................................... 67
6. Abschließende Bewertung und Ausblick ....................................................................................... 68
Glossar ................................................................................................................................................... 70
Abbildungsverzeichnis ........................................................................................................................... 71
Literaturverzeichnis ............................................................................................................................... 72
7

Bachelorthesis Jan Simmendinger
1. Einleitung
Moderne Informationssysteme sind aus der heutigen Arbeitswelt nicht mehr wegzudenken.
Ob im Dienstleistungs-, Fertigungs-, Handels- oder Industriesektor – überall haben
betriebliche Informationssysteme essentielle Aufgaben übernommen. Doch wie kann
sichergestellt werden, dass trotz steigender Anforderungen und zunehmender Komplexität
der Informationssysteme jedem Mitarbeiter in einem Betrieb der Zugriff auf ein
funktionierendes System gewährleistet wird, ohne den Arbeits- und Finanzaufwand für
Betreuung und Wartung steigen zu lassen?
Ein Ansatz zur Lösung dieser Problemstellung sind Virtualisierungsstrategien. In
Großunternehmen werden diese schon seit einigen Jahren erfolgreich eingesetzt, um den
Zielen eines erfolgreichen IT-Managements näher zu kommen.
Jedoch sind gerade in kleinen und mittleren Unternehmen Defizite in diesem Bereich
festzustellen. Dies liegt darin begründet, dass in solchen Unternehmen oftmals keine
fundierte IT-Strategie vorliegt, sondern eher ziellos auf bewährte Systeme und
zusammengetragenes Know-How gesetzt wird. Ein sogenanntes Alignment, also das
Angleichen der IT-Strategie an die Unternehmensziele und damit die optimale Unterstützung
der Unternehmensprozesse [vgl. Gabler, TransformIT, Seite 32], ist aufgrund der fehlenden
IT-Strategie und der oftmals nicht genau definierten Unternehmensstrategie nicht möglich.
Die vorliegende Arbeit wirft trotz dieser Tatsache einen Blick auf die Tauglichkeit solcher
Systeme für kleine und mittlere Unternehmen. Sie besteht aus zwei Teilen und hat das Ziel,
den Ansatz virtualisierter Desktops und Hosts näher zu betrachten, einen Weg zur
Implementierung einer solchen Infrastruktur aufzuzeigen und zu überprüfen, ob diese
Strategie geeignet ist, oben beschriebenes Problem zu lösen.
Der erste Teil dieser Arbeit beschäftigt sich theoretisch mit dem Thema Virtualisierung:
Warum wird virtualisiert? Wie wird virtualisiert? Wie kann Virtualisierung in der Praxis
aussehen?
Der zweite Teil beschreibt ein IT-Projekt bei einem mittelständischen Betrieb in
Süddeutschland, bei dem bei der letzten Migration virtualisierte Server und virtualisierte
Desktops zum Einsatz kamen, um vorhandene Einsparpotentiale zu nutzen.
8

Bachelorthesis Jan Simmendinger
2. Definitionen
2.1. Begriffe und Schlüsselwörter
2.1.1. IT-Strategie
Die IT-Strategie eines Unternehmens stellt das langfristige Gesamtziel dar, auf das die
Informationssysteme eines Betriebes ausgerichtet sein sollen. Sie orientiert sich am
Unternehmensleitbild und bildet die Grundlage für alle Entscheidungen, die, das IT-System
betreffend, getroffen werden müssen.
2.1.2. Backup und Sicherungstechnologien
Unter Backup versteht man eine Einrichtung, die dem Weiterbetrieb eines Systems im
Fehlerfall dient. Die einfachste Form eines Backups ist das Anfertigen einer Sicherungskopie
von gespeicherten Daten. Eine Erweiterung besteht beispielsweise darin, die
Sicherungskopien automatisiert erstellen zu lassen. Solche Sicherungen müssen nach dem
Auftreten eines Fehlers auf einem lauffähigen System manuell wieder eingespielt werden.
Ein solches Sicherungssystem lässt sich nahezu beliebig mit weiteren Funktionalitäten
erweitern. Die höchste Stufe ist erreicht, wenn Fehler oder Ausfälle vom System automatisch
erkannt und korrigiert werden und ein nahtloser Weiterbetrieb des Informationssystems
gewährleistet ist. Da in jedem Teil des Systems Fehler auftreten können, ist es unumgänglich
für diesen Zustand jede Systemkomponente doppelt, also redundant (lat. redundare – im
Überfluss vorhanden sein) vorzuhalten.
2.1.3. Migration
Unter Migration versteht man in der Informationstechnik Umstellungsprozesse. Diese
Umfassen je nach Größe und Art der Umstellung die Migration von Daten, also das
Umziehen von Datenbeständen auf ein anderes System und einen, oftmals damit
verbundenen, Transfer in ein anderes Datenformat, den Austausch von Hardware oder den
9

Bachelorthesis Jan Simmendinger
Wechsel von Anwendungssoftware oder Betriebssystem. Bei Migrationen eines Teilsystems
sind, je nach Umfang, meist verschiedene andere Teilsysteme mit betroffen. Entsprechende
Abhängigkeiten der einzelnen Teilsysteme müssen im Vorfeld erkannt und in das
Gesamtkonzept eingebunden werden.
Werden Abhängigkeiten übersehen, so können beispielsweise Probleme an nicht
abwärtskompatiblen Schnittstellen entstehen.
2.1.4. Virtualisierung
Zum Betrieb eines modernen Computerbetriebssystems werden folgende Ressourcen
benötigt: eine oder mehrere Recheneinheiten (Prozessoren), Arbeitsspeicher,
Festplattenspeicher sowie Ein- und Ausgabegeräte.
Unter einer virtualisierten Maschine versteht man ein Betriebssystem, das während des
Betriebes nicht direkt auf die genannten Hardwareressourcen zugreift, sondern auf virtuell
zur Verfügung gestellte. Diese virtuellen Ressourcen werden von einem anderen
Betriebssystem zur Verfügung gestellt, das die echte Hardware benutzt und virtuelle
Pendants zur Verfügung stellt.
Die Aufgabe in einem virtualisierten System die realen Hardwareressourcen des Hostsystems
virtuell verfügbar zu machen und diese einer oder mehreren virtuellen Maschinen zur
Verfügung zu stellen, übernimmt ein sogenannter Hypervisor. Das griechische Wort "hyper"
bedeutet übersetzt "über" und das Wort "visor" lässt sich am besten mit dem lateinischen
"videre", zu deutsch „sehen“ übersetzen. Wörtlich übersetzt ist der Hypervisor also die
Komponente, die dazu in der Lage ist Host und Gastsysteme zu überblicken [vgl. Picht, Seite
434].
Hauptstrategien, mit denen ein Hypervisor die Hardwarekomponenten des Hostsystems
virtualisiert, sind das sogenannte Adressmapping, bei dem physikalische Speicherbereiche
vor der Weitergabe umadressiert werden und das sogenannte Scheduling, bei dem
Komponenten, auf die exklusiver Zugriff erforderlich ist, schnell nacheinander an die
verschiedenen virtuellen Betriebssysteme weitergegeben werden. Der Einsatz der beiden
genannten Verfahren ist bei multitaskingfähigen Betriebssystemen schon lange Standard.
10

Bachelorthesis Jan Simmendinger
Abb. 1: Veranschaulichung der Aufteilung von Arbeitsspeicher, um ihn virtuellen Maschinen
zur Verfügung zu stellen
Grundlegend kann zwischen zwei Arten von Hypervisoren unterschieden werden: In der
ersten Variante läuft der Hypervisor als Programm auf einem Betriebssystem und die
virtuellen Maschinen auf ihm quasi in der dritten Ebene.
Alternativ wird der Hypervisor hingegen direkt auf der Hardware des Host-Systems
ausgeführt und man spricht von „Bare-Metal-Virtualisierung“ [vgl. Lampe, Seite 75].
Der Nachteil der Bare-Metal-Methode liegt darin, dass die Virtualisierungssoftware selbst
alle notwendigen Treiber zur Ansteuerung der, oft sehr verschiedenartigen, Host-Hardware
mitbringen muss. Dieser Nachteil wird jedoch ausgeglichen: Durch den direkten
Hardwarezugriff wird keine unnötige Rechenleistung für die Verwaltung eines an sich
unnötigen Wirtsbetriebssystems verwendet – eine effizientere Methode der
Zusammenarbeit auf der Ebene zwischen Hypervisor und Hardware ist nicht möglich.
Weitere Möglichkeiten zur Effizienzsteigerung bestehen also nur noch in der darüber
liegenden Ebene zwischen Hypervisor und virtuellen Maschinen. Eine davon ist die
Paravirtualisierung. Bei dieser Technologie wird den virtuellen Maschinen nicht nur ein
virtueller Host angeboten, der für sie normalerweise aussieht wie echte Hardware, sondern
ihnen wird mitgeteilt, dass sie virtualisiert ausgeführt werden. Dazu existiert eine
Schnittstelle, mit der die virtuelle Maschine auf bestimmte Funktionen direkt auf die
Hosthardware zugreifen kann, ohne den Umweg über den Hypervisor gehen zu müssen. Um
11

Bachelorthesis Jan Simmendinger
die Vorteile der Paravirtualisierung nutzen zu können, muss das Gastbetriebssystem dazu
fähig sein, die vom Virtualisierer angebotene Schnittstelle nutzen zu können.
Abb. 2: Vergleich eines Hypervisors auf einem Wirtsbetriebssystem (links) und einem Bare-
Metal Hypervisor (rechts)
2.2. Eingesetzte Maschinen
2.2.1. ThinClient
Der Begriff ThinClient bezeichnet einfache Computer, die für die Benutzung durch den
Anwender gedacht sind. Diese Geräteklasse zeichnet sich durch kleine Bauformen und den
Einsatz energiesparender Komponenten aus. Meist werden sie mit einem sehr kleinen, vom
Funktionsumfang beschränkten Betriebssystem betrieben, welches entweder von einem
elektronischen Speichermedium (Flash-Speicher) oder über das PXE- (PrebootExecution
Environment-) Protokoll von einem TFTP- (Trivial-File-Transfer-Protocol-) Server gestartet
wird.
Die vom Anwender benötigten Programme werden meist nicht direkt auf dem ThinClient
ausgeführt, sondern auf einem zentralen Server im Netzwerk oder Internet. Der ThinClient
dient also nur dazu Benutzereingaben zu diesem zentralen Server weiterzuleiten und die
Ausgaben des Servers über den angeschlossenen Bildschirm dem Benutzer anzuzeigen. Aus
12

Bachelorthesis Jan Simmendinger
diesem Grund haben ThinClients meist einen im Verhältnis zu aktuellen Personal Computern
relativ leistungsschwachen Prozessor.
2.2.2. SAN (Storage-Area-Network)
Storage-Area-Networks (dt. Speichernetzwerke) dienen der flexiblen und zuverlässigen
Bereitstellung von nicht flüchtigem Speicherplatz (Festplattenspeicher) für Serversysteme.
Um das zu erreichen, wird in solch einem Speichernetzwerk die feste Verbindung zwischen
bestimmten Festplatten oder Festplattenverbünden mit einem bestimmten Serversystem
durch ein Netzwerk ersetzt. Durch dieses Netzwerk kann jedes Hostsystem auf jede
Festplatte beziehungsweise auf jeden Festplattenverbund zugreifen.
Dadurch wird es möglich, die Zuordnungen zwischen Speicher und Host flexibel zu
handhaben.
Typischerweise geschieht die Anbindung der Komponenten eines Speichernetzwerks – im
Gegensatz zu einer Network attached Storage-Lösung - nicht über die bereits vorhandene
Netzwerkinfrastruktur, da diese dadurch unnötig zusätzlich belastet wird. Das Ethernet-
Protokoll eignet sich aufgrund seiner Konzeptionierung beispielsweise nicht für diese Art der
Datenübertragung, da insbesondere die relativ großen Kopfdaten pro Datenpaket dem
schnellen und flinken Transport vieler kleiner Lese- und Schreibzugriffe entgegen stehen [vgl.
Noppenberger, Seite 30].
Stattdessen werden aktuelle SAN-Systeme meist mithilfe von FibreChannel oder SAS (Serial
Attached SCSI-) an die betreffenden Hostsysteme angebunden.
13

Bachelorthesis Jan Simmendinger
Abb. 3: Vergleich einer direkten Anbindung von Festplattenspeicher an Serversystemen
(oben) mit einer Anbindung über ein Storage-Area-Network (unten)
2.2.3. Terminalserver
Ein Terminalserver stellt das Herzstück einer Infrastruktur zur Desktopvirtualisierung dar. Ein
Benutzer kann von einem beliebigen Arbeitsplatz-PC eine Sitzung auf den Terminalserver
herstellen. Innerhalb dieser Sitzung können dann Anwendungen ausgeführt werden. Im
Gegensatz zum Betrieb von Anwendungen direkt auf einem Arbeitsplatz-PC werden alle
notwendigen Operationen direkt auf dem Terminalserver ausgeführt und nur die
Bildschirmausgabe an den Benutzer-PC weitergeleitet.
Ein Terminalserver ist dazu in der Lage, mehreren Benutzern gleichzeitig individuelle,
virtuelle Arbeitsplätze, also einen virtuellen Desktop zur Verfügung zu stellen. Bekannte
Protokolle zur Herstellung von Verbindungen zu Terminalservern sind RDP (Remote Desktop
Protokoll) und VNC (Virtual Network Computing). Ein Client, also eine Software zur
Herstellung von Verbindungen über das Remote Desktop Protokoll, ist in jeder Microsoft
Windows Version ab Windows 2000 bereits integriert. Für beide Protokolle ist für beinahe
jedes Betriebssystem und jede Plattform eine Vielzahl von Softwareclients verfügbar.
14

Bachelorthesis Jan Simmendinger
2.3. Vorgehensweisen bei der Migration
Eine Systemmigration, also die Integration von Neusystemen oder der Umstieg auf andere
Systeme, kann verschiedenen organisiert werden.
2.3.1. Kontinuierlicher Übergang
Der kontinuierliche Übergang von Alt- auf Neusystem stellt meist eher einen theoretischen
Ansatz dar, da ein stufenloser Übergang niemals möglich ist. Bricht man bei der Betrachtung
ein System weit genug in seine Bestandteile herunter, so ist ab einer bestimmten Stufe
immer ein stufenweiser Übergang festzustellen.
Dieser Prozess entspricht dann einer iterativen Migration wie sie in Kapitel 2.3.2.
beschrieben ist.
2.3.2. Iterative Migration
Die iterative Migration stellt meist die am besten praktikable Vorgehensweise bei
Systemmigrationen dar. Es handelt sich dabei um ein Modell, bei dem die gesamte Aufgabe
„Systemerneuerung“ in mehrere kleine und dadurch überschaubare Aufgaben zerlegt wird.
Die entstehenden kleineren Aufgaben haben jeweils klar definierte Ziele und sind deshalb
auf ihren Erfolg überprüfbar und einzeln abzuschließen. Es entsteht bei der Ausführung quasi
eine Schleife, bestehend aus Durchführen – Prüfen – Nachbessern – Prüfen. Die
Wiederholung dieser Punkte (Iteration) bei jedem Teilschritt gibt dieser Migrationsplanung
ihren Namen.
Die Vorgehensweise orientiert sich am Ansatz divide and conquer (lateinisch: divide et
impera). Ins Deutsche übersetzt bedeutet dies „Teile und herrsche“. Ein großes Projekt wird
also in kleinere, beherrschbare Stücke aufgeteilt.
Nach der Aufteilung muss noch nach Abhängigkeiten der Einzelschritte voneinander gesucht
werden. Mit diesen Abhängigkeiten ist es dann möglich die Reihenfolge zur Lösung der
15

Bachelorthesis Jan Simmendinger
Teilaufgaben festzulegen. Ist die Reihenfolge einmal definiert, so kann ein Zeitplan erstellt
werden. Optimierungen sind an dieser Stelle möglich, indem beispielsweise unabhängige
Arbeitspakete parallel bearbeitet werden, sofern die entsprechenden Ressourcen verfügbar
sind. Die sogenannte Netzplantechnik nach DIN 69900-1 stellt an dieser Stelle sehr hilfreiche
Werkzeuge zur Planung des Zeitrahmens des Gesamtprojekts zur Verfügung.
2.3.3. Vollmigration
Findet der Übergang auf das neue System in einem Zug statt, so spricht man von einer
Vollmigration. Diese Vorgehensweise funktioniert nur nach einer sehr genauen
Aufgabenplanung und mit Projekten von beschränktem Umfang. Oftmals wird dazu tendiert,
eine ablösende Migration, also den Umstieg auf ein komplett neues System als Vollmigration
zu sehen. Da die Inbetriebnahme der neuen Infrastruktur jedoch meist im Voraus bereits
parallel zum Altsystem erfolgt, ist auch solch eine eher als iterative Migration einzustufen.
Die Teilkomponenten, die bei einer iterativen Vorgehensweise als Hauptaufgabe
zusammengefasst werden können, können für sich als Vollmigration gesehen werden.
16

Bachelorthesis Jan Simmendinger
3. Theorie
3.1. Gründe für Hostvirtualisierung
3.1.1. Antrieb für die Virtualisierung von Serversystemen
Virtualisierung - die Beweggründe dafür sind nicht auf Anhieb zu erkennen. Der Ansatz,
Daten zentral zu verarbeiten und die Ein- und Ausgabeperipheriegeräte eher zu
vereinfachen, sieht anfangs eher aus wie ein Schritt zurück in frühere Zeiten der
Informationstechnologien. Im Jahre 1964 brachte die Firma IBM mit der IBM System/360 die
erste universell einsetzbare Großrechenanlage auf den Markt. Diese setzte ebenfalls auf
obigen Ansatz und das weit vor der Einführung des IBM Personal Computer im Jahre 1981,
der den Trend zu einer eigenständigen Rechenanlage je Arbeitsplatz förderte. Die Frage,
welche Vorteile der Schritt zurück zu zentralisierten Anlagen bringt, lässt sich mit einem
Wort beantworten: Einsparpotentiale.
Die verschiedenen Punkte an denen sich diese ergeben, sollen in diesem Kapitel näher
erläutert werden.
3.1.2. Energie
Das Energiesparpotential, das sich durch Virtualisierung ergibt, erschließt sich nicht sofort
bei der ersten Betrachtung der Thematik. Geht man davon aus, dass eine Maschine für eine
Operation eine bestimmte Menge an Energie benötigt, so hätte es keine Auswirkung auf den
Energieverbrauch, wenn mehrere dieser Maschinen zusammengefasst werden.
Erst wenn man Auslastung und Wirkungsgrad mit in die Betrachtung aufnimmt, sieht man,
welches Potential sich bietet.
Ein klassischer in Hardware vorhandener Host wird bisher so gut wie nie mit einer
Auslastung von 100% betrieben. Unter der Annahme, dass er im Leerlauf 20% der Energie
benötigt wie im Volllastbetrieb, wird deutlich, dass allein das Bereithalten eines
rechenbereiten Systems unnötig Energie verbraucht. Es liegt also nahe, die Zahl der
teilausgelasteten Systeme zu minimieren und die Auslastung eines Systems möglichst hoch
halten zu wollen, da dann eine deutlich effizientere Nutzung der Energie ermöglicht wird.
17

Bachelorthesis Jan Simmendinger
Abb. 4: Veranschaulichung des Energiesparpotentials des Prozessors bei Zusammenfassung
von zwei Maschinen auf einer physikalischen Maschine
3.1.3. Geringerer Wartungsaufwand und kürzere Bereitstellungszeiten
Beim Vergleich des Einrichtungs-, Wartungs- und Instandhaltungsaufwands müssen zwei
Bereiche getrennt betrachtet werden.
Auf der einen Seite steht die Wartung und Pflege der Software eines Systems. Hierzu zählen
hauptsächlich die Installation, ständige Aktualisierungen und die Systempflege. Die hierfür
notwendigen Installations- und Updateprozesse sind heute weitgehend automatisiert und
benötigen nach dem Anstoßen kaum weitere Eingriffe eines Systemverwalters.
Die andere Seite ist die Einrichtung und Pflege physikalischer Maschinen. Die Montage und
Inbetriebnahme einer physikalischen Maschine in einem Rechenzentrum ist, ebenso wie der
Austausch defekter Hardwarekomponenten, nicht automatisierbar und benötigt immer
relativ aufwändige mechanische Eingriffe eines Administrators.
Bei dieser Betrachtung erschließt sich ein weiterer großer Vorteil von Virtualisierung: Ein
komplettes Computersystem wird von der Hardware- in die Softwareebene verlagert. Damit
18

Bachelorthesis Jan Simmendinger
kann der Prozess, der beispielsweise zum Aufsetzen eines neuen Systems notwendig ist,
ebenso vollständig automatisiert werden wie die Installation von Softwareupdates.
Hierfür kann beispielsweise ein einmal erstelltes Abbild eines neu installierten Systems
beliebig oft als Kopiervorlage für ein vollständiges System hergenommen werden. Dieses
kopierte Abbild wird im Hypervisor eingebettet und dann gestartet. Es sind dann nur noch
wenige Operationen auszuführen um das System vollständig bereit zu stellen. Die Anzahl der
anschließend noch manuell auszuführenden oder anzustoßenden Schritte hängt vom
verwendeten Betriebssystem und der Qualität der Kopiervorlage ab. Diese umfassen
beispielsweise das Lizenzieren, die Vergabe von individuellen IP-Adressen und die
Herstellung bestimmter Verbindungen zu Speichermedien und anderen Ressourcen. Die
Bereitstellungszeit eines neuen Hostsystems lässt sich somit auf einen Bruchteil der Zeit und
des Aufwands verringern.
3.1.4. Erhöhte Zuverlässigkeit
Um die Zuverlässigkeit, also die Verfügbarkeit - selbst im Fehlerfall - eines herkömmlichen IT-
Systems, zu erhöhen ist im Normalfall vollständige Redundanz notwendig. Um ein
Hostsystem hochverfügbar zu machen, ist es also notwendig ein zweites, baugleiches System
betriebsbereit zu halten, das die Funktionen - im Falle eines Ausfalls - des ersten Systems
übernimmt. Bei virtualisierten Maschinen gestaltet sich dieser Punkt jedoch anders. Da ein
Hardwaredefekt bei virtualisierten Maschinen nur auf Ebene des darunterliegenden Hosts
auftreten kann, genügt es diesen Host redundant zur Verfügung zu stellen. Die virtuellen
Maschinen selbst müssen nicht redundant vorhanden sein, sondern es genügt, wenn ihr
Abbild auf einem anderen, funktionsfähigen Host weiterhin ausgeführt werden kann.
3.1.5. Einfache Rollback- und Backupfunktionalität
Um von einem physikalischen Hostsystem eine vollständige Datensicherung der gesamten
Maschine zu erhalten, ist es im Normalfall notwendig, die Maschine herunterzufahren oder
19

Bachelorthesis Jan Simmendinger
zumindest temporär bestimmte Dienste zu beenden, da vereinzelte Systemdateien ständig
im exklusiven Zugriff durch das Betriebssystem oder durch einen Dienst stehen.
Durch die Zwischenschicht der Virtualisierung ist es möglich, am Betriebssystem vorbei auf
die physikalische Festplatte zuzugreifen und somit auch im laufenden Betrieb ein
vollständiges Backup der Maschine zu erstellen. Ganz im Gegensatz zu einer physikalischen
Maschine kann bei einer virtualisierten Maschine zusätzlich zu der Sicherung von
Festplatteninhalten ein Abbild des aktuellen Arbeitsspeicherinhaltes erzeugt und
festgehalten werden. Somit ist es bei einer virtuellen Maschine ohne großen Aufwand
möglich, eine aktuelle Momentaufnahme des kompletten Systems zu erstellen. Diese
Snapshotfunktion kann dazu genutzt werden, regelmäßig oder vor Veränderungen an der
virtualisierten Maschine ein lauffähiges Abbild von ihr zu speichern, das im Fehlerfall
problemlos zur Wiederherstellung eines lauffähigen Systemzustandes und damit des
Regelbetriebs genutzt werden kann.
3.1.6. Hardwareunabhängigkeit
Bei Migrationen von kompletten Servern auf andere Hardware, also ein Umzug von
Betriebssystem samt darauf installierter Serveranwendungen, droht immer die Gefahr, dass
eine Anpassung an die Hardware, die während der Installation des Betriebssystems
entweder manuell oder automatisch erfolgt ist, Inkompatibilitäten hervorruft. Solche
Anpassungen basieren oftmals auf gerätespezifischen Treibern wie Chipsatz- oder I/O-
Gerätetreibern oder Anpassungen auf die jeweilige CPU (Prozessor).
Diese Gefahr lässt sich durch den Einsatz von virtuellen Umgebungen eliminieren. Ein
Hypervisor bietet seinen Gastbetriebssystemen immer dieselbe virtuelle Hardware an, so
dass diese einen Umzug auf eine andere physikalische Maschine selbst gar nicht erkennen
müssen.
20

Bachelorthesis Jan Simmendinger
Abb. 5: Darstellung der Migration eines virtualisierten (unten) und eines Bare-Metal-
Betriebssystems (oben)
3.1.7. Ortsunabhängige Systemwartung
Die in Abschnitt 3.1.3. bereits erwähnte Verlagerung eines gesamten Computersystems in
die Softwareebene durch Virtualisierung ermöglicht, neben der ohnehin vereinfachten
Administration eines Systems, auch noch die Administration eines Systems aus der Ferne.
Ist eine physikalische Maschine, auf der ein Hypervisor läuft, über ein Datennetz
(beispielsweise das Internet) erreichbar, so sind an den darauf befindlichen virtuellen
Maschinen vorzunehmende Aufgaben wie die Installation, Wartung, Hochfahren,
Herunterfahren und auch die komplette Entsorgung (also Löschung der virtuellen Maschine)
über dieses Datennetz möglich.
Das bedeutet, dass für die Bereitstellung eines neuen Servers kein Systembetreuer am
Standort des Servers sein muss, sondern die Erzeugung, Installation und Onlinestellung des
Systems vollständig von überall erfolgen kann wo ein Zugang zum Datennetz vorhanden ist.
21

Bachelorthesis Jan Simmendinger
3.1.8. Kapital
Weniger Energieverbrauch, geringerer Wartungsaufwand, höhere Zuverlässigkeit und mehr
Flexibilität des betrieblichen Informationssystems sind Ziele, die der IT-Strategie jedes
Unternehmens entgegen kommen. Mithilfe von virtualisierten Serversystemen kommt man
all diesen Zielen trotz geringerem Materialeinsatz ein großes Stück näher. All diese Punkte
resultieren zusammengefasst in einer Kapitalersparnis.
3.2. Gründe für die Desktopvirtualisierung
3.2.1. Triebfedern
Die Einsparpotentiale, die sich bei der Virtualisierung des Desktops, also der Oberfläche des
Endanwenders, ergeben, sind wie bei der, im vorherigen Kapitel erläuterten,
Servervirtualisierung nicht sofort zu erkennen. Die einzelnen Punkte werden in den
folgenden Abschnitten näher betrachtet.
3.2.2. Zentrale Bündelung der Ressourcen
Dadurch, dass die Ausführung von Programmen und somit Verarbeitung von Daten bei
einem virtuellen Desktop nicht auf den einzelnen Arbeitsplatzcomputern stattfindet,
sondern auf dem Terminalserver, sinkt der Ressourcenbedarf der einzelnen Stationen
deutlich. Diese Verschiebung der benötigten Ressourcen in Richtung des Servers sorgt für
eine effizientere Nutzung dieser, wie in Abbildung 6 ersichtlich ist. Ist trotz der genannten
Effizienzsteigerung einmal eine Aufrüstung der Ressourcen notwendig, so fällt diese Dank
der Zentralisierung mit deutlich kleinerem Aufwand aus, da nur der Terminalserver
aufgerüstet werden muss. Solch eine Änderung wäre bei klassischer Nutzung der Terminals
mit einem immensen Aufwand verbunden, da jeder Client ausgetauscht oder individuell
aufgerüstet werden müsste.
22

Bachelorthesis Jan Simmendinger
Abb. 6: Ohne Desktopvirtualisierung verbleiben viele Ressourcen ungenutzt, da jeder Client
einen eigenen Puffer für Lastspitzen vorhält
3.2.3. Geringere Anforderungen an die Clients
Bei der Nutzung von virtualisierten Desktops sind die Systemvoraussetzungen an die
genutzten Client-Computer nicht nur deutlich geringer, sondern unterliegen auch keiner so
starken Veränderung. Solange die Anforderung, den fertig aufbereiteten Bildschirminhalt mit
akzeptablen Verzögerungen darzustellen und Benutzereingaben über Tastatur und Maus an
den Terminalserver weiterzugeben, erfüllt wird, ist kein Austausch und keine Aufrüstung der
Clients notwendig. Es kann also längere Zeit mit viel einfacheren Arbeitsstationen gearbeitet
werden, die mit weniger Wartung auskommen. Gerade bei der Geräteklasse der ThinClients
(siehe Kapitel 2.2.1.) wird dieser Vorteil voll ausgenutzt. Durch den geringeren
Stromverbrauch ist keine aktive Kühlung notwendig und durch den Einsatz von
elektronischen Speichermedien anstatt magnetischer Festplatten ensteht keinerlei
mechanischer Verschleiß und die Fehleranfälligkeit einer solchen Arbeitsstation sinkt um ein
Vielfaches.
3.2.4. Vorteile bei der Datensicherung
Selbst wenn die technischen und organisatorischen Regelungen es nicht vorsehen, dass
Daten direkt auf den Arbeitsplatzcomputern, sondern auf Netzlaufwerken gespeichert
werden, so ist dies trotzdem gängige Praxis vieler User, insbesondere in kleinen
Unternehmen. Aus diesem Grund sind Datensicherungen der einzelnen Arbeitsplatz-PCs
notwendig. Diese stellen aber oftmals eine Herausforderung dar, da die Sicherung aus
Performancegründen nicht während der Arbeitszeit erfolgen soll und die Rechner außerhalb
23

Bachelorthesis Jan Simmendinger
der Arbeitszeiten in der Regel ausgeschaltet sind. Dies erfordert, dass ein Rechner für die
Erstellung eines Backups extra hochgefahren wird. Entweder muss dieser Vorgang
mechanisch ausgelöst oder eine Automatik gefunden werden, die den PC entweder
zeitgesteuert oder per Netzwerkbefehl vor der Datensicherung hochfährt. All diese
Verfahren sind relativ aufwendig und zudem sehr unzuverlässig, da der Rechner zwar
ausgeschaltet, aber mit dem Stromnetz und dem Netzwerk verbunden sein muss.
Mit einer Infrastruktur auf Basis virtueller Desktops wird diese Problematik entschärft, da
der komplette Arbeitsplatz der Anwender auf dem Terminalserver gespeichert ist. Somit
können die vollständigen Benutzerkonten inklusive aller Daten, selbst wenn diese an
unüblichen Stellen gespeichert sind, in eine regelmäßige Datensicherung mit einbezogen
werden.
Damit sind auf dem Terminal nur noch die Daten gespeichert, die das Gerät für die
Verbindungsherstellung zum Terminalserver benötigt, in der Regel einfach nur das
Betriebssystem mit einer Remote-Desktop-Software. Eine Sicherung dieser Daten ist
unnötig, da diese im Falle eines Datenverlustes einfach wieder hergestellt werden können,
um den Weiterbetrieb des Terminals zu ermöglichen. Auf diese Weise wird außerdem die zu
sichernde Datenmenge stark reduziert, da nicht mehr das Betriebssystem jedes Clients
mitgesichert wird, sondern nur einmal das Betriebssystem des Terminalservers und die
entsprechenden Benutzerdaten dazu.
3.2.5. Flexible Nutzung von Anwendungen
Bestimmte Abteilungen in einem Unternehmen benötigen außer den Standardprogrammen
zusätzlich spezielle Anwendungen. Ein Vertriebsmitarbeiter braucht beispielsweise neben
seiner Office-Suite zusätzlich Zugriff auf das CRM-System, ein Produktionsleiter ein
Programm zur Pflege der Produktionskennzahlen. Bei der klassischen Benutzung eines PCs
kann zwar die im Unternehmen gewünschte Grundkonfiguration weitgehend automatisiert
zur Verfügung gestellt werden, die vom Benutzer zusätzlich benötigen Anwendungen
müssen aber manuell von einem Administrator installiert werden. Dies sorgt für eine große
Vielzahl an individuell konfigurierten Systemen innerhalb des Betriebes und erhöht den
24

Bachelorthesis Jan Simmendinger
Pflegebedarf, da jeder User bei einer Veränderung Unterstützung von der IT-Abteilung
benötigt. Durch die Virtualisierung des Desktops entfällt dies, denn ein Benutzer kann von
jeder Workstation aus auf seinen persönlichen Arbeitsplatz mit seinen benötigten
Programmen zugreifen. Egal, ob er den Schreibtisch wechselt oder von einem festen auf
einen tragbaren Rechner umsteigt, er hat Zugriff auf die Anwendungen die er zum Arbeiten
benötigt.
3.2.6. Plattformunabhängigkeit
Eine Bindung an bestimmte Betriebssysteme oder Hardwareplattformen steht dem Ansatz
eines möglichst flexiblen betrieblichen Informationssystems total entgegen. Die
Virtualisierung der Arbeitsoberfläche löst die feste Bindung eines bestimmten
Betriebssystems mit dessen Desktop auf. Bedient man sich eines Terminalservers, so sieht
eine Applikation für den Anwender nach der Verbindungsherstellung immer gleich aus, egal,
mit welcher Hardware und welchem Betriebssystem lokal gearbeitet wird.
Die momentan stark zunehmende Verbreitung tragbarer Endgeräte wie Smartphones oder
Tablet-PCs sorgt beispielsweise für eine zunehmende Vielfalt an Plattformen. Da diese
Geräte vermehrt aus dem privaten Leben auch in den geschäftlichen Bereich vordringen und
zunehmend von Anwendern zum mobilen Arbeiten genutzt werden wollen, ergibt sich
immer häufiger das Problem der Anbindung solcher Geräte. Terminalserver stellen
momentan eine praxistaugliche Lösung zur Nutzung solcher Geräte dar, unabhängig davon,
ob für die entsprechende Mobilplattform bereits angepasste Clientsoftware für die im
Unternehmen verwendeten Lösungen verfügbar ist. Auch Systeme in einem sehr frühen
Entwicklungsstand können somit genutzt werden, um eine Verbindung herzustellen, sobald
ein entsprechender Client für das Protokoll des betreffenden Terminalservers zur Verfügung
steht.
25

Bachelorthesis Jan Simmendinger
3.2.7. Vereinfachte Administration
Die Administration von PC-Systemen an einzelnen Benutzerarbeitsplätzen stellt einen
verhältnismäßig großen Aufwand für eine IT-Abteilung dar, da physikalische Systemarbeiten
voraussetzen, dass ein Mitarbeiter vor Ort kommt. Bei Unternehmen mit einem einzigen
Standort innerhalb eines Gebäudes fällt dieser Punkt noch nicht wesentlich ins Gewicht. Bei
zunehmender räumlicher Größe eines Unternehmens wächst dieser Aspekt jedoch zu einem
strategisch wichtigen heran. Spätestens wenn es sich um Außenstellen handelt, die die
Anreise eines Mitarbeiters mit dem Auto oder der Bahn erfordern, gilt es die Systeme
wartungsarm zu gestalten.
Die in den obigen Abschnitten genannte Zentralisierung der Ressourcen und einfachere,
plattformunabhängige Clients erfüllen diese Aufgabe, da sich die Arbeitsplatzrechner bei den
Benutzern so vereinheitlichen lassen. Diese Vereinheitlichung sorgt dafür, dass das
komplexe Thema der Administration und Datensicherung zentralisiert im Rechenzentrum
erfolgt und sich die Pflege der Clients darauf beschränkt, defekte Geräte zu ersetzen, wobei
die Tauschgeräte nicht einmal das selbe Betriebssystem oder dieselbe Systemarchitektur
haben müssen.
Der Anforderung, zentralisiert zu administrieren, wird zwar heute bereits in vorhandenen
Infrastrukturen Rechnung getragen, indem Domänen genutzt werden, jedoch sind die Clients
allein dadurch noch nicht wartungsärmer. Ist ein Client Mitglied der Domäne, so kann das
Einspielen von Updates, die Installation von Software oder Veränderungen an
Berechtigungen zwar vom sogenannten Domänencontroller gesteuert werden, jedoch
arbeitet der Benutzer immer noch lokal auf der meist sehr individuell konfigurierten
Maschine.
3.3. Virtualisierungslösungen
Die zum Betrieb virtueller Maschinen notwendige Softwareumgebung, bestehend aus
Hypervisor und Programmen zur Installation, Erstellung und Wartung der Systeme, gibt es
26

Bachelorthesis Jan Simmendinger
von verschiedenen Herstellern mit unterschiedlichen Funktionen in allen Preisklassen. In
diesem Abschnitt werden die bekanntesten Lösungen mit den größten Marktanteilen
vorgestellt.
3.3.1. ESXi und vSphere von VMWare
Die Virtualisierungslösung ESXi ist der Nachfolger der ESX Reihe von VMWare, Inc.
Das Unternehmen wurde 1998 gegründet mit dem Ziel, virtuelle Maschinen auf Standard
Computern mit x86-Architektur lauffähig zu machen.
Als Marktführer bietet VMWare eine ganze Palette an Bare-Metal Virtualisierungslösungen
und Lösungen, die ein Wirtsystem erfordern, an. Egal, ob kostenlose oder kostenpflichtige
Produkte: Alle sind kompatibel zu nahezu allen Systemen, die in heutigen Infrastrukturen
vorkommen.
Die vSphere Produktfamilie ist als Gesamtpaket mit ESXi für den Einsatz in Rechenzentren
gedacht und bringt Funktionalitäten wie die Erstellung von Hochverfügbarkeitsverbünden,
die automatische Lastverteilung zwischen mehreren Hypervisoren, sowie Werkzeuge für das
Management der virtualisierten Systeme und für den Virtualisierungsvorgang von
physikalischen Hosts gleich mit.
3.3.2. Microsoft Hyper-V
Die Virtualisierungsplattform Hyper-V von Microsoft ist keine Bare-Metal-Virtualisierungs-
lösung, sondern nutzt Windows Server 2008 Systeme als Wirtsystem. Hyper-V ist ein fester
Bestandteil der Windows 2008 Reihe und direkt nach der Installation verfügbar.
Besonders hervorzuheben ist, dass eine kostenfreie Version des Windows Server 2008
verfügbar ist, deren Funktionalität auf die Bereitstellung der Virtualisierungsplattform
beschränkt ist. Diese Version kann als Bare-Metal-Lösung angesehen werden, da das
Betriebssystem auf die pure Hypervisorfunktionalität verkleinert wurde.
27

Bachelorthesis Jan Simmendinger
Auf den so bereitgestellten virtuellen Maschinen werden neben Windows Betriebssystemen
mit kostenpflichtiger Lizenz auch bestimmte, kostenfrei verfügbare Linux Distributionen von
RedHat und SUSE offiziell unterstützt.
3.3.3. Citrix XEN Server
Ursprünglich von der Universität Cambridge entworfen, wird der Bare-Metal-Hypervisor XEN
mittlerweile von der Firma Citrix weiterentwickelt. Citrix begann seine Geschäfte im Bereich
der Desktopvirtualisierung und hat in Zusammenarbeit mit Microsoft im Jahre 1995 das
erste Windows Server Betriebssystem mit Terminalfunktionalität auf den Markt gebracht.
Mit der Übernahme des auf Linux basierenden XEN Hypervisor, hat Citrix sein
Produktportfolio erweitert und bietet damit eine vollständige Palette für durchgängige
Lösungen von Anwendungs-, über Desktop- bis zur Hostvirtualisierung vergleichbar mit
VMWare.
Seit April 2009 stellt Citrix eine kostenfreie Version von XEN Server zum Download zur
Verfügung, deren Lizenz auch einen kommerziellen Einsatz zulässt.
XEN Server bietet in allen Versionen eine solide Lösung zum Betreiben von virtuellen Hosts
und kann durch Paravirtualisierung noch deutlich beschleunigt werden, wenn die
beheimateten virtuellen Maschinen unter Linux betrieben werden.
Zum performanten Betrieb von Microsoft Windows auf den virtuellen Maschinen benötigt
der XEN Server spezielle Hardwareerweiterungen seitens der CPU, die von der Firma Intel
unter dem Namen VT-X, von AMD unter AMD-V vermarktet werden.
3.3.4. QEMU
Bei Quick Emulator (kurz: QEMU) handelt es sich um freie Software unter der GPL (General
Public License). QEMU ist nur in einer hosted Version verfügbar und erfordert dadurch
zwingend ein Wirtsbetriebssystem. Es ist zwar keine Bare-Metal-Version verfügbar, doch
dadurch, dass Versionen für x86, PowerPC und SPARC-Architekturen verfügbar sind, läuft der
28

Bachelorthesis Jan Simmendinger
Emulator neben normalen PC-Systemen auch auf Apple und SUN Systemen problemlos.
Ebenso kann er oben genannte Architekturen auch hostunabhängig emulieren – es ist also
beispielsweise möglich auf einem System mit SUN-SPARC Architektur eine x86 Maschine
zum Betrieb eines Microsoft Windows oder Linux Betriebssystems virtuell zu erzeugen.
QEMU ist in der Lage, Live-Migrationen durchzuführen, also virtuelle Maschinen im
laufenden Betrieb von einem Host auf einen anderen zu verschieben oder laufende
Maschinen komplett einzufrieren. Somit ist ein Arbeiten mit Abbildern von virtuellen
Maschinen (Snapshots) ähnlich wie mit Werkzeugen von VMWare möglich.
3.4. Warum wird migriert
3.4.1. Gründe für Erneuerung
Die Notwendigkeit zur Erneuerung von betrieblichen IT-Infrastrukturen entsteht aus
verschiedenen Gründen: Schon allein das Wachstum eines Unternehmens erfordert eine
Verstärkung der Infrastruktur und auch gesellschaftliche, technologische und rechtliche
Veränderungen erfordern immer neue Anpassungen.
Die Anforderungen an die Systeme steigen also durch die verschiedenartigsten Einflüsse.
Schon allein die sich zunehmend verbreitende Kommunikationsinfrastruktur sorgt dafür,
dass die Ansprüche der Benutzer an ein System wachsen.
Insbesondere der technologische Fortschritt ist damit häufig der stärkste Treiber. Oftmals
entstehen regelrechte Abhängigkeitsketten, wenn beispielsweise der Einsatz einer neuen
Software den Einsatz eines moderneren Betriebssystems und damit möglicherweise gleich
noch den Einsatz neuer Hardware erforderlich macht.
Aber auch ohne die absolute Notwendigkeit, Systeme anzupassen, kann eine Erneuerung
von Teilen der IT-Infrastruktur sinnvoll sein, da sich daraus Verbesserungen ergeben und
Einsparpotentiale genutzt werden können.
29

Bachelorthesis Jan Simmendinger
3.4.2. Nachteile gewachsener Strukturen
Selbst wenn keine aktiv geplanten Veränderungen an einem IT-System vorgenommen
werden, so finden zwangsläufig Veränderungen statt. Eine Vielzahl kleiner Veränderungen,
wie beispielsweise Erweiterungen im Speicherbereich, der Ersatz defekter Hardware durch
Nachfolgerversionen oder das Aufspielen einfacher Softwareupdates und
Fehlerbehebungen, können dafür sorgen, dass das Gesamtsystem nicht mehr den Zielen der
Strategie entgegen kommt. Aufgrund der großen Komplexität der Gesamtsysteme wird
oftmals nur soweit erneuert wie notwendig oder es werden weitere Subsysteme erstellt, die
nicht mehr dem Gedanken eines ganzheitlichen Informationssystems entsprechen. Hierbei
entstehen oft Landschaften aus verbundenen Inselsystemen. Aus solchen Inselsystemen
ergibt sich meist eine Reihe von Nachteilen: fehlende Transparenz und Übersichtlichkeit,
unnötiger Ressourcenverbrauch, veraltete oder unvollständige Dokumentation, Engpässe bei
Medien- und Systemübergängen. Diese resultieren in einer großen Zahl möglicher
Fehlerquellen und schlechter Wartbarkeit.
3.4.3. Probleme veralteter Systeme
In keinem Sektor sind die Entwicklungs- und Produktzyklen so kurz wie im Informatikbereich.
Gerade dieses hohe Maß vieler Veränderungen in relativ kurzer Zeit lässt IT-Systeme schnell
altern. Werden die Anforderungen nicht verändert, erfüllt ein System in einem
Unternehmen selbstverständlich die ihm zugedachten Aufgaben trotz Alterung weiterhin.
Aber dadurch, dass die Systeme aber nicht mehr isoliert betrieben, sondern zunehmend
vernetzt, also in einen Verbund mit anderen Systemen gebracht werden, ist es notwendig
die Kompatibilität zu den sich weiterentwickelnden Partnersystemen nicht nur herzustellen,
sondern auch beizubehalten. Das bedeutet also, dass die Systeme mit ihrer Umwelt
zusammen weiterentwickelt werden müssen, da sonst die Gefahr droht, dass die
Schnittstellen inkompatibel werden.
Das hohe Entwicklungstempo sorgt aber auch dafür, dass die Hersteller von Hard- und
Software die Unterstützung von alternden Systemen immer früher einstellen. Dies spielt
30

Bachelorthesis Jan Simmendinger
meist keine Rolle, solange ein System fehlerfrei läuft. Tritt allerdings ein Fehler auf, so ist es
für die zeitnahe Wiederherstellung eines lauffähigen Zustandes vorteilhaft, auf aktuellen
Systemen zu arbeiten für die volle Ersatzteil- und Treiberverfügbarkeit im Hardwarebereich
und Update- und Patchverfügbarkeit im Softwarebereich gegeben ist.
3.4.4. Vorteile einer Erneuerung
Je nach Umfang behebt eine Erneuerung des betrieblichen Informationssystems die im
Kapitel 3.4.2. genannten Probleme mit gewachsenen oder veralteten Infrastrukturen ganz
oder teilweise.
Meist werden damit also Probleme behoben, die in den entsprechenden Abteilungen oder
einzelnen Mitarbeitern schon längere Zeit bekannt sind, weil diese zunehmend Arbeitszeit
für Fehlerbehebungen an dem alternden System investieren müssen, um es lauffähig zu
halten. Das bedeutet also, dass eine Erneuerung den steigenden Unterhaltskosten eines
alternden Systems entgegen wirkt.
Der Umstieg auf neuere Technologien bringt außerdem noch die Möglichkeit mit sich, dass
nicht nur Kosten gesenkt, sondern auch ganz neue Geschäftsfelder erschlossen werden
können, die mit den alten eingesetzten Technologien nicht oder nur mit einem immensen
Aufwand realisierbar wären. Ein Beispiel dafür wäre die Bereitstellung eines
Onlinebestellsystems im Internet, das auf Inhalte der Lagerverwaltungsdatenbank zugreifen
soll und damit dynamisch den aktuellen Produktkatalog mit entsprechenden Lagerbeständen
generieren soll. Liegt die Verwaltungsdatenbank noch in einem Format vor, dass einen
Zugriff mit modernen Webtechnologien (beispielsweise PHP) nicht oder nur über aufwendig
zu erstellende Individualanpassungen ermöglicht, so würde eine Migration der Datenbank
auf ein modernes relationales Datenbanksystem, wie beispielsweise SQL, diese
Anbindungsfähigkeit als Vorteil gleich mitbringen.
31

Bachelorthesis Jan Simmendinger
4. Vorgehensweise bei Migrationsprojekten
In diesem Kapitel wird eine beispielhafte Vorgehensweise geschildert nach der die Planung
eines Migrationsprojekts in einem kleinen Unternehmen erfolgen kann, wenn die
Entscheidung getroffen wurde eine Systemmigration durchzuführen.
4.1. Grundlagenplanung
4.1.1. Zustand der technischen Systeme und der Dokumentation
Bei der Planung von Migrationsprojekten sollte vorab eine grundlegende Analyse der
aktuellen Systeme stattfinden. Hierfür sollte zuerst überprüft werden, ob die vorhandene
Dokumentation dem aktuellen Systemzustand entspricht. Besonders in kleinen und
mittleren Unternehmen werden kleine Veränderungen, die im Tagesgeschäft an Systemen
durchgeführt werden, oftmals nicht in der Dokumentation festgehalten und eine
nachträgliche Aktualisierung ist daher notwendig. Ziel einer solchen Aktualisierung der
Dokumentation sollte also sein, neben einer aktuellen Übersicht die Details der Systeme
soweit aufzubereiten, dass im nächsten Schritt die Teilsysteme auf ihre Migrationsfähigkeit
geprüft werden können.
4.1.2. Analyse von Aufgaben und Orientierung am Prozessmanagement
Welche Aufgaben werden mit dem momentanen Informationssystem auf welche Art und
Weise erfüllt? Erstellt man aus den Antworten auf diese Frage einen Katalog, so erhält man
eine Basis mit der die Mindestanforderungen an das neue System verhältnismäßig leicht
geklärt werden können.
Hierfür sollte zuerst entschieden werden, ob hauptsächlich ein Bottom-up-Ansatz verfolgt
wird, bei dem die Benutzer beziehungsweise die Fachabteilungen mit einbezogen werden,
um zu definieren, welche der aufgelisteten Funktionalitäten absolut essentiell, welche
mittlerweile obsolet und welche zusätzlichen Funktionalitäten im neuen System gewünscht
32

Bachelorthesis Jan Simmendinger
sind. Je nach Größe und Philosophie des Unternehmens kann es auch sinnvoll sein
stattdessen einen Top-Down-Ansatz zu verfolgen und die Frage nach den Aufgaben des
Informationssystems am Prozesskatalog des Unternehmens fest zu machen [vgl. Brugger,
Seite 87].
4.1.3. Technologischen Fortschritt nutzen
Vor einem Migrationsprojekt sollte der Stand aktueller Technologien genau betrachtet
werden. Es besteht einerseits die Möglichkeit, mit aktuellen Entwicklungen für denselben
Kapital- und Arbeitsaufwand mehr Funktionalität zu erhalten und damit späteren Zielen
bereits jetzt näher zu kommen. Andererseits lassen sich die Projektziele mit aktuellen
Produkten eventuell mit weniger Aufwand erreichen.
Unabhängig davon stellt ein Migrationsprojekt eine Bindung an ein bestimmtes Produkt oder
eine bestimmte Technologie, mindestens bis zur nächsten Migration, dar. Deshalb sollten die
vorgesehenen Komponenten auf ihre Zukunftsaussichten bewertet werden, um auf Systeme
zu setzen für die noch möglichst lange Unterstützung durch Hersteller oder Entwickler und
eine größtmögliche Kompatibilität zu anderen Systemen gegeben ist.
4.1.4. Vorüberlegungen zu Alternativen im Hostbereich
Dieser Abschnitt beleuchtet Alternativen zur Virtualisierung von Serversystemen, die bei der
Planung einer Systemmigration ebenso in Betracht gezogen werden sollten.
4.1.4.1. Outsourcing
Anstatt die Anzahl der zu betreibenden physikalischen Serversysteme im Unternehmen
durch Virtualisierung zu minimieren, kann in Betracht gezogen werden, die Systeme gar
nicht selbst zu hosten, sondern auf externe Dienstleister zurück zu greifen. Bei der
33

Bachelorthesis Jan Simmendinger
Verwendung von Standardsoftware besteht oftmals die Möglichkeit, dass nicht nur ein
nacktes, beim Dienstleister beheimatetes Hostsystem gemietet werden kann, welches
immer noch einen administrativen Aufwand für das Unternehmen mit sich bringt, sondern
auf eine vollständige Lösung zurückgegriffen werden kann.
All diese Lösungen sind seit einiger Zeit in den Medien allgegenwärtig und werden dort meist
als „Cloud Computing“ bezeichnet. Dieser Begriff umfasst Datenspeicher-, Kollaborations-
und Officelösungen, die über das Internet von jedem beliebigen Standort aus genutzt
werden können und bei denen die Speicherung und Verarbeitung der Daten zentral in der
Datenwolke (engl. cloud) erfolgt.
Der Hauptvorteil von Serveroutsourcing liegt in der im Voraus planbaren Kostenstruktur. Es
sind keinerlei Anfangsinvestitionen notwendig und es besteht keine Notwendigkeit,
Rücklagen zu bilden für einen eventuell notwendigen Austausch von Hardware. Für die
Pflege der Hardwaresysteme ist kein Einsatz unternehmensinterner Ressourcen notwendig.
Ebenso stellt die Entwicklung von steigenden Energiekosten keinen Unsicherheitsfaktor
mehr dar, da das Risiko steigender Kosten für Betrieb und Kühlung des Systems vom
Dienstleister getragen wird.
Andererseits kann die Mindestverfügbarkeit der Systeme zwar vertraglich vom externen
Dienstleister eingefordert werden, jedoch wird das Desastermanagement im Fehlerfall damit
aus der Hand gegeben, denn bei einer vollständigen Auslagerung der Systeme werden
jegliche Daten ebenso beim externen Dienstleister gespeichert. Je nach Sicherheits- oder
Geheimhaltungslevel der gespeicherten Daten gilt es an dieser Stelle zu bewerten, ob diese
Gefahr in Kauf genommen werden kann.
Fällt die Abwägung zwischen den im Voraus genau kalkulierbaren Kosten bei höchster
Flexibilität und dem Risiko die Unternehmensdaten ausgelagert zu speichern zu Gunsten
eines externen Dienstleisters aus, so sollte eine Migration auf extern gehostete Server als
ernsthafte Alternative zur Virtualisierung interner Server gesehen werden. Auf Serverhosting
spezialisierte Unternehmen können ihre Kostenrechnung nämlich deutlich besser optimieren
als jedes Unternehmen, das seine Server selbst beheimatet, zumal dort durch Virtualisierung
die Zahl der physikalischen Systeme zum größten Teil bereits auf ein Minimum reduziert
wurde.
34

Bachelorthesis Jan Simmendinger
Durch die zunehmende Verbreitung und die sinkenden Preise von Breitbandzugängen muss
dieser Ansatz ganz klar als Zukunftstrend betrachtet werden.
4.1.4.2. Hostsysteme in Hardware
Anstatt auf einen Ansatz mit virtualisierten Umgebungen zu setzen, kann auch weiterhin für
alle zu bewältigenden Aufgaben jeweils ein physikalisches Hostsystem genutzt werden.
Durch die Verfügbarkeit von zuverlässigen und wartungsfreundlichen
Virtualisierungsumgebungen scheint dieser Ansatz jedoch als veraltet und es gibt kaum
Gründe, die dagegen sprechen, die möglichen Einsparpotentiale bei Administration,
Wartung und Energieverbrauch zu nutzen.
Eine Ausnahme stellen Applikationen dar, die auf nicht virtualisierbaren
Serverbetriebssystemen aufbauen – solche sind aus heutiger Sicht aber kaum noch
verbreitet. Ein anderer Grund kann die Notwendigkeit von angeschlossener Hardware sein,
die durch den Hypervisor nicht durchreichbar ist. Hier gilt jedoch genau zu prüfen, ob nicht
eine andere Lösung gefunden werden kann oder ob nicht ein anderer Hypervisor verfügbar
ist, der diese Funktionalität bietet.
Beispiele hierfür sind beispielsweise SCSI-Controller, an die ein Bandlaufwerk für
Datensicherungszwecke angeschlossen ist, wie der im folgenden Praxisteil dieser Arbeit
genannte MTKBACKUP01. Es sollte überlegt werden, ob solch ein System nicht durch
modernere Hardware, die per Netzwerk-, SAS- oder FibreChannel-Verbindung an die zu
sichernden Systeme (am besten direkt an das Storage-Area-Network) angeschlossen wird,
ersetzt werden sollte.
Auch die bei manchen Softwareanwendungen, vorwiegend bei technischen Planungs-
programmen (CAD-Tools), üblichen Lizenz- und Verschlüsselungstoken, die per USB
angeschlossen werden, sind kein Grund, beispielsweise einen Lizenzierungsserver nicht zu
virtualisieren. Entweder lässt sich ein solches USB-Gerät durch den Hypervisor durchreichen
oder es kann mit einem USB-over-Ethernet Konverter gearbeitet werden. Die
Funktionsweise eines solchen Gerätes ist in Abbildung 7 dargestellt.
35

Bachelorthesis Jan Simmendinger
Abb. 7: Veranschaulichung der Funktionsweise einer Lösung zur Anbindung von USB-Geräten
an virtuelle Maschinen
Durch die große Vielfalt an verfügbaren Methoden für die Anbindung von Hardware an
virtuelle Maschinen finden sich mittlerweile kaum mehr Geräte, die gegen den Einsatz von
Virtualisierung sprechen.
Dieser Ansatz sollte also maximal noch in vorhandenen Systemen Anwendung finden. Eine
Virtualisierung solcher Altsysteme und damit einhergehende Einbindung in eine neue
Infrastruktur sollte auf alle Fälle in Betracht gezogen werden. Eine solche Vorgehensweise ist
im Praxisteil am Beispiel des Hosts APPWIN02 geschildert (siehe Kapitel 5.3.2.).
4.1.4.3. Konsolidierung von Diensten auf einem Betriebssystem
Eine andere Strategie zur Minimierung der physikalischen Serversysteme ist die
Konsolidierung mehrerer Dienste auf einem einzigen Betriebssystem. Bei diesem Ansatz ist
keine Planung und Einrichtung einer virtualisierten Umgebung notwendig, sondern nur die
Installation und Pflege eines einzigen Betriebssystems. Prinzipiell ist die Administration eines
solchen Serversystems mit der eines normalen Arbeitsplatz-PCs vergleichbar. Viele
Serverapplikationen greifen bei der Installation jedoch tief in das Betriebssystem und seine
Prozesse ein. Dadurch wird es häufig unmöglich, noch andere Software parallel auf
demselben System zu betreiben. Bei steigender Anzahl der Serverinstanzen auf der
Maschine steigt also auch das Risiko von Problemen durch Inkompatibilität.
36

Bachelorthesis Jan Simmendinger
Anstatt Probleme durch Inkompatibilitäten zu riskieren, weil mehrere Serverdienste auf
einem einzigen System beheimatet werden, sollte bei der Planung einer Systemlandschaft
lieber auf ein eigenes virtuelles System pro Dienst zurückgegriffen werden.
Dadurch, dass aktuelle Hypervisoren für ihre Verwaltungsdienste nicht nennenswert an der
Systemleistung zehren, spricht nur noch der Faktor der Lizenzkosten für jedes
Betriebssystem pro virtueller Maschine für diesen Ansatz. Durch den Einsatz von Open-
Source-Betriebssystemen auf den VMs relativiert sich jedoch auch dieser Punkt.
4.1.5. Vorüberlegungen zu Alternativen im Desktopbereich
Zwar gibt es im Bereich der Desktopvirtualisierung nicht viele Alternativlösungen, doch auch
hier sollen noch andere Ansätze zur flexibleren Nutzung der Benutzerarbeitsplätze genannt
werden, die in der Planungsphase eines neuen EDV-Systems eine Rolle spielen können.
4.1.5.1. Anwendungsvirtualisierung
Bei der Anwendungsvirtualisierung wird die Virtualisierungsumgebung auf dem lokalen
Betriebssystem des Client Computers ausgeführt. Sie befindet sich zwischen dem
Betriebssystem und der ausgeführten Anwendung und stellt dieser ein simuliertes
Betriebssystem zu Verfügung. Somit ist es möglich, eine Software lokal auf einem
Arbeitsplatzcomputer zu nutzen, ohne dass diese dort mit all ihren Registrierungseinträgen
installiert sein muss. Es genügt die Parameter der virtuellen Umgebung und die Software von
einem Server zu beziehen, um diese auf dem Client ausführbar zu machen. Es ist also keine
lokale Installation der Software auf dem Clientbetriebssystem notwendig und somit entfallen
die notwendigen Verflechtungen mit diesem, ebenso wie die vorherige Prüfung der
Kompatibilität der beiden Komponenten, da fertig konfigurierte Anwendungen und die dafür
notwendige simulierte Betriebsumgebung vom Server geladen und dort ausgeführt werden.
Die Rechenleistung für die Programmausführung wird somit direkt vom Client bezogen,
37

Bachelorthesis Jan Simmendinger
weshalb sich dieser Ansatz auch für rechenintensive Anwendungen wie Grafik-,
Videobearbeitungs- und CAD-Software sehr gut eignet.
Die Verwaltung erfolgt hierbei zwar zentral, jedoch ist auf den einzelnen Arbeitsplätzen
immer noch ein vollständiges Betriebssystem und eine darauf ausführbare
Virtualisierungsumgebung erforderlich. Dadurch, dass die Ausführung der Applikation auf
dem Client erfolgt, ist bei diesem Ansatz immer noch eine Abhängigkeit von der
verwendeten Hardware gegeben. Eine neue Softwareversion mit höheren
Systemanforderungen macht also eventuell eine Aufrüstung der Clienthardware notwendig
und nicht nur eine Aufrüstung an zentraler Stelle, wie beispielsweise bei der Verwendung
eines Terminalservers.
Die Lösungen, die unter den Namen VMWare ThinApp oder Microsoft Application
Virtualization angeboten werden, sind für spezielle Anwendungsfälle sicherlich interessant,
jedoch lösen sie die Aufgabe der Vereinfachung der Clientverwaltung durch Entkoppelung
nicht so gut wie ein Ansatz auf Basis von Virtualisierung.
4.1.5.2. Nutzung von Diensten im Browser
Browserbasierte Anwendungen sind dank Technologien wie HTML5, PHP, AJAX und Flash
von Spielereien zu alltagstauglichen Diensten geworden. Mit einer angepassten
Systemarchitektur können sie eine echte Alternative zu virtualisierten Desktops darstellen,
deren Hauptvorteil in der Standardisierung der Schnittstellen und der dadurch sehr guten
Integrationsfähigkeit nahezu jeder Plattform liegt. Jedes Endgerät mit einem aktuellen
Browser kann hierbei ohne Anpassungen zur Nutzung der betrieblichen
Informationssysteme genutzt werden, egal, ob es sich um ein stationäres oder tragbares
Gerät handelt.
Leider erfordert die Nutzung von Anwendungen über den Browser überwiegend komplette
Neuentwickelungen, da sich vorhandener Programmcode in klassischen
Programmiersprachen wie beispielsweise C++ oder C# nicht nutzen lässt.
Durch die klare Trennung von Benutzerinterface (innerhalb des Browsers),
Datenverarbeitung (durch eine Webserverinstanz) und der Datenhaltung (auf speziellen
38

Bachelorthesis Jan Simmendinger
Datenbankservern) ist sogar oftmals eine komplette Überarbeitung der gesamten Systeme
notwendig, bevor solch eine Nutzung denkbar ist.
Das Potential, das trotz des erhöhten Entwicklungsaufwands in diesem Ansatz steckt, zeigen
Webportale wie Facebook und Google, die momentan beispielhaft die Leistungsfähigkeit von
modernen, browserbasierten Benutzeroberflächen demonstrieren.
SAP, einer der größten Anbieter von betrieblicher Software, setzt mit Produkten wie SAP
Netweaver oder, die bei SAP gehostete Mietlösung, SAP BusinessByDesign sogar vollständig
auf den Browser als Benutzerinterface und setzt damit verstärkt auf die Zukunft dieses
Ansatzes.
Die Vorteile wiegen den erhöhten Aufwand bei der Umstellung und Neuentwicklung häufig
schnell auf, weshalb auf die Überlegung, ob Desktopvirtualisierung oder Browserapplikation
besonderes Augenmerk gelegt werden sollte.
4.1.6. Projektumfang und Rahmenbedingungen
Bevor detaillierte Projektpläne erstellt werden, muss abgeklärt werden, unter welchen
Rahmenbedingungen die Migration durchgeführt wird und damit, welchen Umfang das
Projekt haben darf. Hier sind bei Migrationen in kleinen und mittleren Unternehmen
folgende drei Punkte schwerpunktmäßig zu betrachten.
4.1.6.1. Kapital
Der finanzielle Rahmen eines Migrationsprojekts wird meist durch die Geschäftsführung
vorgegeben, da eine größere Migration Investitionen erfordert, die über dem typischen Etat
der IT-Abteilung liegt oder bei kleinen Firmen gar kein extra IT-Budget vorhanden ist.
Insbesondere, wenn die Anschaffung neuer oder zusätzlicher Hardware oder
Softwarelizenzen ansteht, sind die Geschäftsführer, Anteilseigner oder sonstige Shareholder
in die Entscheidungsprozesse mit einzubeziehen.
39

Bachelorthesis Jan Simmendinger
4.1.6.2. Aufwand
Eine Migration bringt ein nicht unerhebliches, zusätzliches Arbeitspensum mit sich. Je nach
Auslastungsgrad und Personalsituation innerhalb der IT-Abteilung kann es möglich sein,
solch ein Projekt durch den Auf- oder Abbau von Überstunden zu bewältigen. Ist dies jedoch
nicht der Fall, so empfiehlt es sich zusätzliche Arbeitskraft von einem externen Dienstleister
oder durch zusätzliches Personal zu beschaffen. Dies resultiert dann wieder in einem
höheren finanziellen Aufwand, der wiederum mit den, bereits in Kapitel 4.1.6.1. genannten,
Stakeholdern des Projekts abgestimmt werden muss.
4.1.6.3. Technische Gegebenheiten
Bauliche und ortsabhängige Gegebenheiten beeinflussen die zu erstellende Planung einer
neuen Infrastruktur und die Migration auf diese selbstverständlich auch.
Ein Faktor mit sehr zunehmender Gewichtung ist beispielsweise die Verfügbarkeit von
Breitbandzugängen zum weltweiten Datennetz. Außerhalb urbaner Gegenden sind diese
immer noch oftmals nur eingeschränkt verfügbar. Die maximal realisierbare Bandbreite
sowie die Zuverlässigkeit und Verfügbarkeit eines Internetzugangs schränken die Freiheit bei
der Planung eines neuen Systems eventuell stark ein, da beispielsweise ein Serverhosting an
anderen Standorten oder bei externen Dienstleistern dadurch unmöglich wird.
Aufgrund der hohen Priorität dieser Thematik ist es oftmals sinnvoll, sich über Alternativen
zu einem Breitbandzugang über die Telefonleitung zu informieren, wenn DSL nur
eingeschränkt realisierbar ist. Häufig ist damit eine höhere Bandbreite erreichbar, denn
Technologien über das Breitbandkabel (TV-Kabel), Funktechnologien über Mobilfunk (UMTS,
HSDPA oder LTE), Datenfunk (WLAN, WiMAX) und andere Möglichkeiten (Lichtwellenleiter)
werden zunehmend praxistauglich und sind je nach örtlichen Gegebenheiten mit
vertretbarem Aufwand realisierbar.
Die Kapazität an nutzbarem Raum für die Unterbringung eines betrieblichen
Informationssystems sollte ebenso bereits in die Grobplanung mit einfließen. Dabei geht es
nicht nur um die bloßen Räumlichkeiten für die Unterbringung, sondern auch welche
40

Bachelorthesis Jan Simmendinger
Anforderungen diese erfüllen. Zu nennen sind hier Lüftungs- und Klimatechnik, Feuchtigkeit,
Verfügbarkeit von Strom- und Kommunikationsleitungen sowie die Zutrittskontrolle.
4.2. Konzepte
Sind die finanziellen und technischen Rahmenbedingungen aus Kapitel 4.1.6. geklärt, so
muss nun innerhalb dieser eine Lösung skizziert werden, aus der sich ein Konzept mit der
genauen Vorgehensweise während der Migration ergibt.
4.2.1. Ideen sammeln und bündeln
Da sich nach den Vorüberlegungen aus Kapitel 4.1. meist eine Vielzahl von Möglichkeiten
ergibt, die die gewünschten Ziele erfüllen würden, bietet es sich an diese zu Konzepten zu
bündeln. Es sollten also Ideen strukturiert und gebündelt und so weiterentwickelt werden,
dass erkennbar wird, welche Vor- und Nachteile sich beim jeweiligen Konzept
herauskristallisieren und mit welchem Aufwand eine Realisierung verbunden wäre.
Abb. 8: Aus der Vielzahl der in Frage kommenden Technologien müssen für das neue IT-
System geeignete ausgewählt und gruppiert werden
4.2.2. Bewertung der Konzepte und Freigabe
Nach der Phase zur Konzeptfindung gilt es die möglichen Konzepte zu bewerten. Die hierbei
zu beachtenden Punkte können nicht allgemein genannt werden, jedoch finden sich hier
41

Bachelorthesis Jan Simmendinger
grundlegende Ideen für die Findung von Bewertungspunkten, wobei die Gewichtungen
anhand der Präferenzen eines betreffenden Unternehmens individuell festzulegen sind:
- Chancen auf einen erfolgreichen Projektverlauf
- Unternehmensinternes Know-How der verwendeten Technologien
- finanzieller Aufwand
- Arbeitsaufwand für die Migration
- Aufwand für Mitarbeiterschulung, wenn neue Hard- oder Software eingesetzt wird
- Zukunftsaussichten der verwendeten Technologien
- Kompatibilität zu vorhandenen oder weiteren Systemen
- spätere Migrationsfähigkeit / voraussichtliche Kosten bei nächstem Systemwechsel
Zur Findung der am besten geeigneten Konzepte kann eine Entscheidungsmatrix, wie in
Abbildung 9 zu sehen, genutzt werden. Die Bewertung einzelner Punkte gestaltet sich
hierbei häufig nicht einfach, da alle nicht messbaren Kriterien quantifiziert werden müssen,
um sie erfassen zu können. Jedoch hat dies den Vorteil, dass jeder Punkt für sich selbst
überdacht wird und nicht im Gesamtbild von Vor- und Nachteilen der einzelnen Konzepte
untergeht.
Abb. 9: Eine Bewertungsmatrix findet anhand individueller Gewichtung einzelner
Kriterien das am besten geeignete Konzept
42

Bachelorthesis Jan Simmendinger
Wurden die am besten geeigneten Konzepte gefunden, müssen grobe Aufwands- und
Kostenschätzungen erstellt und diese den entscheidenden Stellen im Unternehmen
vorgestellt werden. Es sollte dann eine Freigabe für eines der Konzepte gegeben werden um
es in den nächsten Schritten weiter voran zu treiben und die Migration vorzubereiten.
4.3. Erstellung eines Projektplans
Ist die Freigabe eines Projektes aus dem vorherigen Abschnitt erfolgt, ist das Projekt somit
definiert. Der nächste Schritt ist die Erstellung eines Projektplans auf dem die spätere
Steuerung des Migrationsprojekts basiert.
4.3.1. Arbeitspakete definieren
Welche Aufgaben ergeben sich bei der Umsetzung der Erneuerungspläne und wie können sie
sinnvoll gegliedert werden? – Diese Aufgabe stellt sich am Anfang der Erstellung des
Projektplans. Am besten dafür geeignet ist ein Projektstrukturplan, dessen englische
Bezeichnung „work breakdown structure“ bereits die Vorgehensweise beschreibt: Die
anstehenden Aufgaben werden heruntergebrochen in kleinere Arbeitspakete. Die Vorteile
dieser kleinen Pakete sind neben der besseren Überschaubarkeit, dass die Verantwortung
dafür jeweils einem Verantwortlichen übergeben werden kann und dass der Fortschritt ihrer
Bearbeitung detaillierter beurteilt werden kann.
Abb. 10: Beispielhafte Aufteilung der Arbeitspakete bei der Fertigung eines Automobils
43

Bachelorthesis Jan Simmendinger
4.3.2. Klären von Personal- und Kompetenzfragen
Es muss beurteilt werden, welche Kompetenzen jeweils für die Bearbeitung eines
Arbeitspaketes notwendig sind. Da kleine Unternehmen einen meist sehr übersichtlichen
Mitarbeiterstamm in der EDV-Abteilung haben, lässt sich häufig schnell klären, welcher
Mitarbeiter Erfahrungen mit bestimmten Produkten oder Technologien hat und damit
welche Arbeitspakete er übernehmen kann.
Findet sich kein interner Mitarbeiter mit den entsprechenden Kompetenzen, so muss ein
Experte in das Projekt mit eingebunden werden, der das entsprechende Know-How
mitbringt, um technische und organisatorische Unsicherheiten bei der Migration auf ein
Minimum zu reduzieren.
4.3.3. Klären von Abhängigkeiten und Erstellung des Zeitplans
Sind die einzelnen Arbeitspakete und die jeweils dafür zuständigen Personen erst einmal
definiert, müssen im nächsten Schritt die Abhängigkeiten der Arbeitspakete voneinander
geklärt und daraus die Abfolge der auszuführenden Arbeiten abgeleitet werden.
Dadurch, dass jedes Arbeitspaket einem Verantwortlichen zugewiesen wird, der
entsprechende Erfahrung auf dem jeweiligen Gebiet mitbringt, ist es möglich, eine
Aufwandsschätzung für jedes Paket zu erstellen und die benötigten Ressourcen abzuklären.
Verbindet man nun die Aufwandsschätzung und die Verfügbarkeit der benötigten
Ressourcen mit dem Ablauf der Schritte, erhält man einen Projektablaufplan mit
voraussichtlicher Gesamtdauer.
Abb. 11: Nach Klärung von Abhängigkeiten und der benötigten Ressourcen für ein
Arbeitspaket ergibt sich einen Projektablaufplan mit voraussichtlicher Dauer
44

Bachelorthesis Jan Simmendinger
4.3.4. Projektdurchführung und Steuerung
Mit dem so entstandenen Ablaufplan und der Verteilung der Verantwortlichkeiten der
einzelnen Pakete kann das Projekt durchgeführt und gesteuert werden.
Bei der Steuerung können drei Schwerpunkte betrachtet werden, die während der Migration
ständig überprüft werden sollten, mindestens jedoch nach dem Abschluss jedes einzelnen
Arbeitspakets. Abweichungen von den geplanten Vorgaben sollten so früh wie möglich an
alle Betroffenen kommuniziert werden, dazu gehören die Geschäftsführung und die
Bearbeiter von nachfolgenden Arbeitspaketen. Nur so sind rechtzeitige Änderungen in den
Projektablauf möglich, ohne dabei viele Ressourcen für Entwicklungen in die falsche
Richtung zu verschwenden.
Schwerpunkt 1 - technische Umsetzungen:
Fragestellung: Erfüllt jede Teilkomponente die an sie gestellten Anforderungen?
Lösungsansätze: Umgestaltung der Komponente oder Anpassung der darum
angeordneten Systeme
Schwerpunkt 2 – Der zeitliche Rahmen:
Fragestellung: Werden die jeweiligen Pakete in der veranschlagten Zeit erledigt?
Lösungsansätze: Erhöhung der Mitarbeiter an Paketen, die die Gefahr mit sich bringen,
Schwerpunkt 3 - der finanzielle Aufwand:
das gesamte Projekt in Verzug zu bringen
Fragestellung: Bleibt die Summe der Kosten der Pakete innerhalb des genehmigten
Budgets?
Lösungsansatz: Erhöhung des genehmigten Projektkapitals durch die Geschäftsleitung
Werden die genannten Schwerpunkte während des Projekts kontinuierlich bearbeitet, so
kann die Migration mit hoher Wahrscheinlichkeit erfolgreich abgeschlossen werden.
45

Bachelorthesis Jan Simmendinger
5. Praktische Umsetzung
5.1. Ein Praxisbericht
Wie die Realisierung des Gedankens einer virtualisierten Infrastruktur in einem
mittelständischen Betrieb aussehen kann, soll in diesem Kapitel anhand eines Praxisberichts
erfolgen. Das Projekt fand bei der Firma mouldtec Kunststoff GmbH in Kaufbeuren statt und
umfasste eine Gesamterneuerung der gesamten Infrastruktur in der Verwaltung des
Unternehmens. Das Altsystem, das Ausgangspunkt der Migration war, wird in den folgenden
Abschnitten beschrieben.
5.1.1. Übersicht
Die Erneuerung des sechs Jahre alten Systems wurde notwendig, da es der EDV-Abteilung
der Firma Mouldtec nicht mehr möglich war, aktuelle Anpassungen vorzunehmen, weil
seitens des früheren EDV-Dienstleisters keine Unterstützung mehr erfolgte.
Da es sich bei dem System um eine unübliche Implementierung von ThinClients mit Linux
Betriebssystem, die über einen „X-Kontroller“ genannten, schlecht dokumentierten
Linuxserver über RDP-Sitzungen auf einen Windows 2003 Terminalserver zugegriffen haben,
war es ohne Support des damaligen Lieferanten nicht mehr justierbar.
5.1.2. Server und Hosts
Die damalige Serverlandschaft von Mouldtec umfasste die nachfolgend genannten
Hostsysteme.
46

Bachelorthesis Jan Simmendinger
5.1.2.1. APPLNX
Es handelte sich hierbei um den „X-Kontroller“, einen Debian GNU/Linux-Server der die
vollständige Verwaltung des Netzwerks übernahm. Auf ihm war ein SQUID-Proxyserver aktiv,
der den Zugang ins Internet regelte. Ebenso übernahm er durch eine SAMBA-
Implementierung die Rolle eines simulierten Windows-Domänencontrollers, gegen den die
Windowssysteme im Netzwerk ihre Benutzerauthentifizierung durchführen konnten. Für die
damaligen ThinClients stellte dieser Host folgende Dienste zur Verfügung:
Er lieferte über einen TFTP-Server das Minilinux an die ThinClients per PXE-Protokoll aus.
Remotedesktopsitzungen der ThinClients auf den Terminalserver wurden ebenso über
diesen Host geleitet wie ClientAccess-Zugriffe auf die AS/400.
5.1.2.2. V5R3M0
Der Host V5R3M0 ist eine AS/400 Maschine aus der Reihe der iSeries von IBM. Dieses
System unter i5/OS sollte von der Migration unangetastet bleiben. Es sollte lediglich das
unternehmensweit verwendete Netzlaufwerk wegmigriert und eine im System integrierte
IPCS-Steckkarte still gelegt werden. Solch eine Steckkarte stellt einen eigenständigen PC
innerhalb einer iSeries-Maschine zur Verfügung, auf dem Windows Betriebssysteme
ausgeführt werden können. Sie diente der Verfolgung des Ziels, ein iSeries System als
vollständiges, integriertes Informationssystem zu betreiben. Dazu verfügt die Karte über
einen eigenständigen Prozessor, Arbeitsspeicher und Netzwerkinterface. Festplattenspeicher
und sonstige I/O-Systeme werden vom AS/400 System bezogen.
5.1.2.3. APPWIN01
Ein Windows 2003 Server, der den Benutzern per Remotedesktop ein Microsoft Office 2003
Paket anbot und über Outlook dem Senden und Empfangen von Emails diente. Zusätzlich
47

Bachelorthesis Jan Simmendinger
war ein PDF-Betrachter und eine Clientsoftware zum Zugriff auf die AS/400 installiert. Der
Host war auf einem eigenständigen IBM xServer X364 untergebracht.
5.1.2.4. APPWIN02
Dieses Hostsystem lief unter Windows Server 2003 und bot ebenso wie APPWIN01 Dienste
per Remotedesktop, allerdings nur für einen bestimmten Benutzerkreis. Die Hauptaufgabe
des Systems war die zur Verfügung Stellung eines Enterprise-Information-Systems (kurz EIS)
der Firma Aruba.
Diese Maschine war auf dem IPC-Server in der AS/400 untergebracht.
5.1.3. ThinClients
Bereits im Altsystem kamen ThinClients zum Einsatz. Es handelte sich dabei um ThinClients
DT166 der Firma DigitalResearch.
Abb. 12: ThinClient DT166, wie er im Altsystem eingesetzt wurde
Diese Geräte haben folgende Leistungsdaten:
AMD Geode 800 CPU, 512 MB RAM, Sound, Netzwerk, 4x USB 2.0 und VGA.
Die Terminals hatten keinen Flash- oder Festplattenspeicher, sondern bezogen ihr
Betriebssystem mithilfe des PXE-Protokolls von APPLNX. Da alle Geräte während des
Bootvorgangs dasselbe Betriebssystemabbild vom Server geladen haben, liefen alle
48

Bachelorthesis Jan Simmendinger
ThinClients mit demselben Betriebssystem. Gerätespezifische Anpassungen, wie
beispielsweise das gezielte Aktivieren oder Deaktivieren von USB-Anschlüssen, eine
Vorbelegung von Anmeldemasken mit bestimmten Benutzernamen oder eine Anpassung der
Bildschirmauflösung waren somit nicht möglich.
Vor allem der letzte Punkt hat sich sehr negativ auf die Benutzerakzeptanz ausgewirkt, da
das System wegen mancher im Unternehmen noch eingesetzter 15“-Flachbildschirme mit
einer Auflösung von 1024 x 768 Pixeln betrieben wurde. Besonders bei Benutzern, die auf
neuen 22“-Bildschirmen im Breitbildformat arbeiten, sorgte die starke Verzerrung der
Anzeige für Unmut.
Die IP-Adresse, die ein ThinClient beim Booten angenommen hat, wurde aus einer Tabelle
bezogen, in der zu jeder MAC-Adresse eines Clients die zugehörige IP hinterlegt war.
5.1.4. Netze
Aus Gründen der IT-Sicherheit kam damals eine Vielzahl von Subnetzen zum Einsatz.
Beispielsweise wurde für jede Verbindung zwischen zwei Serversystemen ein eigenes
Subnetz geschaffen.
Nicht nur innerhalb des Serverraums wurde der Ansatz mehrerer Netzwerke verfolgt,
sondern auf dem gesamten Betriebsgelände wurde mit zwei getrennten Netzen gearbeitet.
Diese beiden Netze waren jedoch nicht nur logisch, sondern auch physikalisch strikt
getrennt. Ein Netz war für die Benutzung mit ThinClients reserviert, das andere wurde für die
Anbindung normaler PC-Arbeitsplätze genutzt. Diese Trennung der Netze sorgte für sehr
unübersichtliche Konfigurationen der Netzwerkschnittstellen einzelner Geräte.
Eventuell notwendiges Routing zwischen den Netzen wurde vom X-Kontroller übernommen.
49

Bachelorthesis Jan Simmendinger
Abb. 13: Ausschnitt aus der Dokumentation der alten Infrastruktur, anhand derer
die Vielzahl an verwendeten Subnetzen ersichtlich ist
5.1.5. Veralteter Internetbrowser
Das Surfen im Internet war im Altsystem nur über den auf den ThinClients verfügbaren
Internetbrowser IceWeasel möglich. Die Nutzung eines alternativen Browsers war, durch
den in Kapitel 2.2.1. genannten Bootvorgang eines fertigen Betriebssystemabbildes, weder
auf den ThinClients selbst möglich, noch innerhalb der Terminalserversitzung , da auf diesem
keine Konfiguration für den Proxyserver eingerichtet war.
Bei dem verwendeten Browser handelt es sich um eine angepasste Version des Firefox-
Browsers, die von den Entwicklern von Debian GNU/Linux ins Leben gerufen wurde, um
Lizenzschwierigkeiten vorzubeugen. Der Browser wird zwar noch weiterentwickelt, jedoch
folgt die Entwicklung den Aktualisierungen von Firefox nur mit großem Abstand. Dadurch,
dass die bei Firma Mouldtec verwendete Version des Browsers fest im Bootimage
implementiert war, wurde jahrelang keine Aktualisierung vorgenommen.
Benutzer, die also mit Zugriff auf das Internet arbeiten, hatten über die vorgesehene Lösung
keine Möglichkeit auf aktuelle Internetinhalte zuzugreifen, da der IceWeasel-Browser
veraltet war und keine Unterstützung für Flash-Inhalte oder in Webseiten eingebettete PDF-
Dokumente anbot.
50

Bachelorthesis Jan Simmendinger
5.1.6. Zusammenfassung der Schwachstellen
Die alte Netzwerkinfrastruktur wurde von der Firma redoXsystems GmbH geliefert und
betreut. Der Support wurde laut Aussage des EDV-Leiters der Firma Mouldtec durch
personelle Engpässe seitens redoXsystems zunehmend unbefriedigender. Letzten Endes war
kein Support mehr gegeben und somit waren keine Anpassungen mehr an der
Netzwerkinfrastruktur möglich. Vor allem der sogenannte „X-Controller“ war ohne
detailliertes Hintergrundwissen nicht weiter konfigurierbar und erfüllte seine aktuellen
Aufgaben alle, jedoch war den Verantwortlichen im Unternehmen die Gefahr zu groß, dass
das Gesamtsystem bei Ausfall dieses Gerätes nicht mehr wiederherstellungsfähig sein
würde. Aus diesem Sachverhalt ergaben sich die Schwachstellen, die eine Migration auf eine
neue Infrastruktur notwendig gemacht haben.
Der X-Kontroller sollte als Single-Point-of-Failure entschärft werden. Durch
Zusammenfassung der vielen Subnetze zu größeren Netzen sollte mehr Übersichtlichkeit und
damit leichtere Fehlereingrenzung ermöglicht werden. Die ThinClients mussten mit dem Ziel
angepasst oder ausgetauscht werden, dass den Benutzern ein zeitgemäßes Arbeiten
ermöglicht wird – insbesondere in den Bereichen aktuelles Office Paket, Displayauflösung
und Darstellung von Webseiten. Die gesamte Bedienung für den Benutzer sollte an den
aktuellen Standard der Microsoft Windows Welt angepasst und damit erleichtert werden.
5.2. Planung der neuen Infrastruktur
Es war also klar, dass bei der Firma Mouldtec eine sehr umfangreiche Systemmigration
notwendig war. Es galt die Frage zu beantworten, welches System wohin migriert werden
sollte.
51

Bachelorthesis Jan Simmendinger
5.2.1. Ideensammlung und Konzeptfindung
Die neue Infrastruktur sollte nach den Vorstellungen des EDV-Leiters weitgehend ohne
Linuxserver auskommen und auf dem aktuellen Stand der Technik sein. Ein Wechsel auf
aktuelle Windows Server 2008R2 Systeme lag also nahe. Die Konsolidierung der neuen
Server auf einer virtualisierten Infrastruktur wurde geprüft und sollte so umgesetzt werden,
da die Auslastung der bisherigen Server sehr gering war. Das bisherige Netzlaufwerk sollte
ebenso vom iSeries-System wegmigriert werden.
Überlegungen, die Serverlandschaft bei einem externen Dienstleister zu hosten, wurden
nicht angestellt, da der Firma nur eine geringe DSL-Bandbreite zur Verfügung steht.
Bisherige Erfahrungen des Unternehmens mit ThinClients waren überwiegend positiv. Dieser
Ansatz sollte also beibehalten werden, allerdings unter der Bedingung, dass individuelle
Anpassungen der Konfiguration einzelner Geräte möglich sind.
Zur Reduzierung der Anzahl von Subnetzen hätte die Möglichkeit bestanden, ein komplett
neues logisches Subnetz aufzubauen und alle Komponenten in dieses neue Netz
einzupflegen. Die Alternative war eine weitere Nutzung von einem der vorhandenen Netze
und die Auflösung aller anderen.
5.2.2. Personaleinsatz
Die EDV-Abteilung der Firma Mouldtec hatte die zuvor genannten Vorgaben zur Erneuerung
der IT-Infrastruktur und zog in Ermangelung von Personal und Know-How das Systemhaus
Soft-Consult Häge GmbH aus Langenau hinzu. Hier war ein Mitarbeiter für die Ausführung
der meisten Arbeitsschritte da, der bereits viel Erfahrung im Bereich solcher Projekte hat
und dem eine weitere Kraft zur Verfügung stand. Für die weitere Projektplanung bedeutete
dies, dass einzelne Arbeitspakete nicht direkt einem Mitarbeiter zugewiesen werden
mussten, sondern es vorwiegend darum ging, die Kommunikation zwischen den beiden
Unternehmen zu regeln und zu klären, welche Informationen und welches Material für die
nächsten Schritte von wem zur Verfügung gestellt werden musste.
52

Bachelorthesis Jan Simmendinger
5.2.3. Aufteilung der Arbeitspakete zu einem Ablaufplan
Da das Design der neuen Systemlandschaft bereits durch den Auftrag an Soft-Consult sehr
klar definiert war, konnte direkt nach der Zerlegung in Einzelschritte ein Ablaufplan des
Projektes erstellt werden. Eine genaue Zeitplanung der einzelnen Arbeitspakete, um die
Ressourcen einplanen zu können war nicht notwendig, da die Aufgaben von dem
zweiköpfigen Team seitens Soft-Consult seriell erledigt wurden und ein Aufgabenblock direkt
nach dem Abschluss des Vorherigen begonnen wurde.
Abb. 14: Der Ablaufplan enthielt keine genauen Zeiten, da die Abarbeitung jedes Blocks direkt
im Anschluss an den Vorgänger begonnen wurde
Die Steuerung des Projekts beschränkte sich auf ein Reporting des aktuellen Fortschritts an
Mouldtec und die Nennung der geplanten Daten für weitere Vor-Ort-Arbeiten beim Kunden.
Diese waren notwendig für Installationsarbeiten der vorbereiteten Hardware und die
53

Bachelorthesis Jan Simmendinger
Hauptmigration während der die EDV-Abteilung von Mouldtec zusammen mit dem Soft-
Consult Team, an einem Wochenende, den GoLive der neuen Infrastruktur durchführte.
5.3. Das neue System
5.3.1. Übersicht
Das neue System wurde also größtenteils mit neuen Komponenten und frisch installierten
Hostsystemen geplant. Ein Überblick über die Planung der neuen Infrastruktur ist in den
Abbildungen 15 und 16 ersichtlich.
Abb. 15: Übersicht über das neue Netzwerklayout der Firma Mouldtec
54

Bachelorthesis Jan Simmendinger
Abb. 16: Gesamtüberblick über die neue Infrastruktur
5.3.2. Logische Übersicht über die Migration der einzelnen Server
Die Hauptaufgabe der Ersetzung des X-Kontrollers wurde durch eine neue, zentrale
Verwaltungsinstanz in Form eines Windows Domänencontrollers gelöst. Jedoch wurden
keinerlei Daten vom Altsystem übernommen, sondern auf einer neuen virtuellen Maschine
frisch aufgebaut.
55

Bachelorthesis Jan Simmendinger
Der ehemalige Terminalserver für den Großteil der Nutzer wurde, ebenso wie der X-
Kontroller, durch eine komplett neue virtuelle Maschine ersetzt. Die frei gewordene
Hardware wurde für einen neuen Host verwendet und übernimmt jetzt die Aufgabe der
zentralen Datensicherung.
Der Terminalserver für die Geschäftsleitung mit dem Enterprise Information System Aruba
EIS wurde komplett virtualisiert und fand somit den Weg in das neue VMWare Cluster.
Abb. 17: Logischer Überblick über die Migrationen der einzelnen Serversysteme
5.3.3. Übernommene Daten aus den Altsystemen
5.3.3.1. Benutzerkonten vom X-Kontroller
Es fand keine Übernahme von Daten vom APPLNX statt. Die Benutzerkonten und die
zugehörigen Benutzerpasswörter wurden stattdessen von der EDV-Abteilung von den
56

Bachelorthesis Jan Simmendinger
Anwendern abgefragt und aufgelistet. Nach dem Durchsehen und Korrigieren der
entstandenen Liste und dem Entfernen von nicht mehr verwendeten Benutzerkonten und
der Aktualisierung von Benutzernamen (Anwender nicht mehr im Unternehmen oder durch
Heirat geänderte Namen) wurden die Benutzerkonten ohne Altlasten auf dem neuen
Domänencontroller eingerichtet.
5.3.3.2. Emailkonten von APPWIN01
Vom früheren Terminalserver wurden nur die benutzerspezifischen Daten der Outlook
Installation übernommen. Pro User wurde also der „Persönliche Ordner“ (*.PST) und die
Informationen für die Autoergänzung von bereits genutzten Emailadressen (*.NK2)
extrahiert.
5.3.3.3. Dateien vom alten Netzlaufwerk übernehmen
Das Netzlaufwerk der Firma Mouldtec wurde bisher von der AS/400 zur Verfügung gestellt.
Hierfür wurde die AS/400 NetServer Funktion des IBM OS/400 verwendet. Diese Funktion
stellt ein Netzlaufwerk mit einer Windows kompatiblen SMB-Freigabe zur Verfügung. Die
Performance dieser Lösung war für die Benutzer unbefriedigend. Tests im Vorfeld ergaben
Leseraten des früheren Netzlaufwerkes von 12 Megabyte je Sekunde. In Anbetracht der
Tatsache, dass alle Dateioperationen der Benutzer über dieses Laufwerk stattfanden, war
hier ein beträchtliches Verbesserungspotential gegeben.
Das neue Netzlaufwerk wird vom Domänencontroller MTKDC01 zur Verfügung gestellt. Es
handelt sich hierbei um einen Datenträger, der direkt vom Storage-Area-Network zur
Verfügung gestellt wird und im Betriebssystem des Domänencontrollers eingebunden und
freigegeben ist.
Anfangs wurde nur die Ordnerstruktur im Stammverzeichnis des neuen Laufwerkes erzeugt
und die Berechtigungen gesetzt. Hier war ein größerer manueller Aufwand zu betreiben, da
die Berechtigungsverwaltung unter IBM OS/400 einen anderen Aufbau besitzt als unter
57

Bachelorthesis Jan Simmendinger
Microsoft Windows. Besonders zu erwähnen ist die fehlende Möglichkeit von Vererbung auf
untergeordnete Verzeichnisse, wie in Abbildung 18 dargestellt.
Abb. 18: Vergleich der Rechtevererbung für Freigaben unter Windows und AS/400 NetServer
Die gesamte Datenmenge auf dem Laufwerk hatte ein Volumen von etwa 200 Gigabyte.
Trotz dieser verhältnismäßig kleinen Datenmenge wurde eine mehrstufige Migration der
Daten vom Altsystem ins neue System gewählt, um innerhalb der begrenzten Zeit am
Umstellungswochenende erfolgreich migrieren zu können. Rechnerisch ergab sich zwar nur
eine Kopierdauer von 5 Stunden:
Datenmenge: 200 GB * 1024 MB/GB = 204800 MB
Kopierzeit: 204800 MB / 12MB/s = 17000 sec = 280 min = 5 Stunden
Jedoch sollten eventuelle Probleme mit Sonderzeichen in Dateinamen, zu lange Dateinamen
oder Dateiattributen vorzeitig erkannt werden.
Dafür wurde der gesamte Datenbestand in der Woche vor dem Roll-Out auf die neue
Netzwerkfreigabe kopiert. Die Benutzer arbeiteten nach diesem Vorgang weiterhin auf dem
Altsystem.
Dateien mit nicht kopierfähigen Namen wurden den entsprechenden Abteilungen genannt
und wurden von diesen noch umbenannt, Dateien die Aufgrund anderer Attribute nicht
kopiert werden konnten, wurden individuell auf das Kopieren vorbereitet.
58

Bachelorthesis Jan Simmendinger
Während des Roll-Out war es dann nur noch notwendig, die seit dem Kopiervorgang
erstellten oder veränderten Dateien kopieren zu lassen und anschließend die alte Freigabe
zu deaktivieren und die neue im Netz erreichbar zu machen.
5.3.4. Neue ThinClients
Bei der Überlegung, ob die alten ThinClients hardwareseitig mit einem Flashlaufwerk
aufgerüstet werden sollten, um darauf ein Windows Betriebssystem zu installieren oder ob
neue ThinClients angeschafft werden sollen, fiel die Entscheidung auf neue ThinClients. Bei
diesen handelt es sich um Geräte der Firma IGEL Technology GmbH. Diese sind von den
Leistungsdaten geringfügig besser wie die alten Terminals, haben jedoch im Gegensatz zu
diesen einen integrierten Flash-Speicher, von dem ein Microsoft Windows Embedded
Standard 2009 Betriebssystem gebootet wird. Bei diesem Betriebssystem handelt es sich um
eine für den Betrieb auf Terminals angepasste Variante von Microsoft Windows XP, mit dem
für die meisten Benutzer wohlbekannten Desktopdesign.
Da das Betriebssystem jedes ThinClients lokal von seinem eigenen Flashlaufwerk gestartet
wird, ist es möglich jeden dieser Clients mit einer individuellen Konfiguration zu betreiben.
Die Geräte bringen herstellerseitig bereits ein Werkzeug mit, mit dem es möglich ist, nach
dem Setzen der Einstellungen einen Schreibschutz auf das Dateisystem zu aktivieren. Das
bedeutet, dass der Benutzer im laufenden Betrieb Dateien auf seinem System speichern und
verändern kann, sich das System aber nach einem Neustart wieder in der gewünschten
Ausgangskonfiguration befindet.
59

Bachelorthesis Jan Simmendinger
Abb. 19: IGEL ThinClient, wie er in der neuen Infrastruktur zum Einsatz kommt
5.3.5. Storage-Lösung
Eine DS3200 von IBM stellt das Herzstück des Datenspeichers der neuen Infrastruktur dar.
Dieses Storage-Area-Network ist jeweils durch eine SAS-(Serial-Attached-SCSI-) Verbindung
mit einem der beiden physikalischen Server und damit quasi einem Hypervisor verbunden.
Das System ist momentan mit 10 Festplatten mit jeweils 320 Gigabyte bestückt und stellt
damit 3 Terabyte Speicherplatz zur Verfügung.
Die physikalischen Festplatten sind folgendermaßen zu logischen Blöcken zusammengefasst:
Jeweils 4 Festplatten werden als RAID 10-Verbund betrieben. Die verbleibenden 2
Festplatten dienen als sofort einsatzbereite Ersatzfestplatte (HotSpare).
Der RAID 10 Modus (ein RAID 0 über zwei RAID 1) verbindet die Vorteile eines RAID 1 mit
denen eines RAID 0 Betriebs. Im RAID 0 Betrieb werden Lese- und Schreibzugriffe auf zwei
oder mehr Festplatten verteilt, um durch parallele Verarbeitung höhere Geschwindigkeiten
zu erzielen. Im RAID 1 Modus werden die Daten auf zwei Datenträgern vollständig
redundant gespeichert, um eine höhere Ausfallsicherheit zu erreichen. Bei Lesezugriffen hat
ein RAID 1 die selbe Performance wie ein RAID 0.
60

Bachelorthesis Jan Simmendinger
Abb. 20: Funktionsweise verschiedener RAID-Konfigurationen
5.4. Die Migration
5.4.1. Vorgehensweise
Die eigentliche Migration auf die neue Infrastruktur war nur mit einer schrittweisen
Vorgehensweise zu bewältigen, da einige Arbeiten im engen Zeitrahmen des Roll-Out
keinen Platz gefunden hätten. Deshalb wurden viele Aufgaben im Vorfeld oder im Nachgang
erledigt, so dass am Umstellungswochenende nur der Roll-Out der neuen ThinClients, die
Umstellung auf das neue Netzlaufwerk, die Migration der USB-Drucker in die neue
Infrastruktur und der Umzug der Outlookkonten auf den neuen Terminalserver stattfanden.
5.4.2. Vorbereitungen
Zu den Vorbereitungen gehörte die Installation, Einrichtung und Konfiguration der Server in
den Räumen der Firma Soft-Consult in Langenau und die anschließende Montage und
Inbetriebnahme der Hostsysteme in den Serverräumlichkeiten der Firma Mouldtec in
Kaufbeuren parallel zum Altsystem.
Die Vorbereitung der IGEL-Terminals wurde ebenso bereits vor der Migration erledigt. Hierzu
gehörte die Inventarisierung der Clients, Vergabe von IP-Adressen, Einrichtung der
Domänenmitgliedschaft, die Einrichtung designierter Benutzer für die Remote-Desktop-
Sitzungen und das Aktivieren eines Schreibfilters für den Flash-Speicher, um spätere
Veränderungen an der Konfiguration durch die Benutzer zu unterbinden.
61

Bachelorthesis Jan Simmendinger
5.4.3. Inbetriebnahme der neuen Security Appliance
Da die Fahrtstrecke von der Firma SoftConsult in Langenau zur Firma Mouldtec Kunststoff
GmbH in Kaufbeuren 120 km beträgt, sollten unnötige Fahrtkosten vermieden werden.
Deshalb war ein wichtiger Baustein vor der Migration die Herstellung eines Site-to-Site VPN
vor dem Roll-Out, um Arbeiten im Vor- oder Nachgang per Fernzugang erledigen zu können.
Um das aktuelle Tagesgeschäft der Firma Mouldtec bis zum endgültigen Roll-Out nicht zu
beeinträchtigen, war es notwendig, die bestehende Internetverbindung über das bisherige
Gateway mit allen Konfigurationen weiter zu betreiben oder es entsprechend nach zu bilden.
Da der Netzzugang über eine DSL-Leitung mit fester IP erfolgt, die über das PPPoE-Protokoll
(Point-to-Point over Ethernet) betrieben wird, schied das Schalten einer zweiten parallelen
Verbindung aus.
Dieses Problem wurde folgendermaßen gelöst: In der neuen Infrastruktur war eine Security
Appliance vom Typ NetScreen SSG5 von Juniper Networks vorgesehen, die im Endzustand
die DSL-Verbindung treiben, Firewall für den Internetverkehr und Site-to-Site und Dial-Up
VPN-Verbindungen zur Verfügung stellen sollte. Erster Schritt war also die Konfiguration der
SSG5 mit den Zugangsdaten der Internetverbindung und einer Schnittstelle als Interface in
das neue Subnetz und einer anderen Schnittstelle, die den alten Router simulierte, um den
alten Proxyserver und damit das gesamte Netzwerk weiterhin online zu halten.
Abb. 21: Vergleich der alten Appliance für den Zugang zum Internet mit Router (oben)
und der Neuen (unten) mit installierter Firewall
62

Bachelorthesis Jan Simmendinger
5.4.4. Die Hauptmigrationsphase
Die Hauptmigrationsphase und damit der Übergang des neuen Systems in den
Produktivmodus fand an einem Wochenende statt. Die Phase begann mit dem Roll-Out der
ThinClients. Dazu wurden die Geräte an den einzelnen Arbeitsplätzen ausgetauscht und
währenddessen gleich noch an den jeweiligen Arbeitsplatz angepasst.
Der zweite Schritt der Umstellung umfasste die Installation von nicht netzwerkfähigen
Druckern, die per USB an die IGEL-Terminals angeschlossen wurden.
Ein weiterer Schritt war die Umschaltung des Netzlaufwerks (bei der Firma Mouldtec aus
historischen Gründen als Y-Laufwerk benannt) vom Netserver der AS/400 auf die neue
Freigabe auf dem neuen Domänencontroller. Hierzu mussten die Daten, die seit dem im
Vorfeld bereits durchgeführten Kopiervorgang verändert oder erstellt wurden, nochmals
kopiert werden.
Letzter Schritt während der eigentlichen Hauptmigrationsphase war der Umzug der Outlook-
Konten der User vom alten auf den neuen virtuellen Terminalserver. Hierzu wurde für jedes
Benutzerkonto eine Anmeldung auf den Terminalserver durchgeführt und dann über die
Remotedesktopverbindung das Microsoft Outlook des Benutzers gestartet. In den
automatischen Einrichtungsassistent wurden dann die Serveradressen und Zugangsdaten
des externen Mailproviders der Firma Mouldtec eingegeben. Zusätzlich wurden die vom
appwin01 kopierten PST-Dateien temporär eingebunden und die darin enthaltenen Mails
und Kontakte in die neue Installation kopiert. Eine Besonderheit ergab sich daraus, dass bei
der Firma Mouldtec wenig mit Emailadressbüchern gearbeitet wird, sondern stattdessen mit
der automatischen Ergänzung von Adressen, mit denen schon einmal kommuniziert wurde.
Diese Daten werden zwar benutzerspezifisch gespeichert, aber nicht in der Persönlichen
Ordner-Datei (PST) des Benutzers, sondern in einer Datei mit der Endung NK2.
63

Bachelorthesis Jan Simmendinger
Abb. 22: Nach der erfolgreichen Migration der NK2-Datei ist die automatische Adress-
ergänzung eines Outlookclient wieder mit allen genutzten Adressen verfügbar
5.4.5. Aufgaben im Nachgang
Nach der Hauptmigrationsphase, die als GoLive des neuen Systems gesehen werden kann,
waren noch die Aufgaben zu bewältigen bei denen Komponenten aus dem Altsystem
weiterverwendet werden sollten.
Dazu gehörte die Virtualisierung des Servers für das Enterprise Information System, der
während der Hauptmigration unverändert weiter betrieben wurde, um ihn nachträglich als
virtuelle Maschine in das neue ESX-Cluster aufzunehmen und seine Hardware außer Betrieb
zu nehmen.
Ein weiterer Schritt im Nachgang war die Nutzungsänderung der freigewordenen Hardware
des ehemaligen Terminalservers APPWIN01 in den neuen zentralen Backupserver
MTKBACKUP01.
Abschließend erfolgte die Abschaltung des X-Kontrollers, der bis zur erfolgreichen
Inbetriebnahme der neuen Infrastruktur weiter lief um – falls die Migration fehlschlagen
sollte - einen eventuell notwendigen Roll-Back zu ermöglichen.
64

Bachelorthesis Jan Simmendinger
5.4.6. Erhöhung der Benutzerakzeptanz
Ein Problem, das erst nach dem Roll-Out festgestellt wurde, waren die im Verhältnis zum
Altsystem deutlich längeren Bootzeiten der neuen IGEL-ThinClients.
Da die Benutzer vom Altsystem Bootzeiten der ThinClients von 10-15 Sekunden gewöhnt
waren, erschien es unzumutbar, dass bei den IGEL-Terminals ab dem Drücken der
Powertaste über 3 Minuten vergingen, bis es möglich war, eine Sitzung am Terminalserver
zu initiieren. Rücksprachen mit dem Hersteller der Terminals ergaben, dass es keine
Möglichkeit gibt, den Startvorgang nennenswert zu beschleunigen. Das Problem wurde also
folgendermaßen gelöst: Es wurde ein Skript erstellt, welches auf dem Domänencontroller
werktäglich, also Montag bis Freitag jeweils um 7 Uhr ausgeführt wird. Dieses Skript enthält
die MAC-Adressen aller bei der Firma Mouldtec im Einsatz befindlichen IGEL-Terminals und
startet diese per Wake-on-LAN. Beim Eintreffen der Benutzer an ihrem Arbeitsplatz finden
diese also einen bereits gestarteten ThinClient vor.
5.5. Probleme und Lösungsansätze
5.5.1. Zuverlässigkeit ESXi
Die in Kapitel 3.1.4. beschriebene Zuverlässigkeit eines ESXi-VMWare Clusters im HA-
(HighAvailability-) Modus zeigt in der Praxis an folgender Stelle Schwächen: Für das
Management und zur Kommunikation mit dem Local-Area-Network besitzen die beiden
physikalischen Host-Systeme und das Storage-Area-Network jeweils mindestens eine
1000MBit/s Verbindung. Bei den Hostsystemen lassen sich diese Verbindungen durch
werkseitig mehrfach vorhandene Netzwerkinterfaces relativ einfach redundant ausführen.
Hierzu ist es lediglich erforderlich, die Netzwerkinterfaces entsprechend zu konfigurieren
und die notwendigen physikalischen Verbindungen auszuführen. Somit ist die Erreichbarkeit
der Hostsysteme über das LAN durch redundante Anbindung sichergestellt. Für den Betrieb
der virtuellen Maschinen auf den Hostsystemen ist außer den LAN-Verbindungen aber auch
noch der Zugriff auf den Festplattenspeicher und damit auf das Storage-Area-Network
65

Bachelorthesis Jan Simmendinger
essentiell wichtig. Die Anbindung der Hosts an das Storage-Area-Network erfolgt aber nicht
über das LAN, sondern jeweils über einen SAS-Link. Bricht einer dieser Links jedoch
zusammen, so sind die virtuellen Maschinen, die aktuell auf dem betroffenen Host betrieben
werden, nicht mehr lauffähig. Dadurch, dass die virtuellen Maschinen unvorbereitet von
ihren Systemfestplatten getrennt werden, schlagen bei solch einem Ausfall auch die von
VMWare vorgesehenen Prozesse fehl, virtuelle Maschinen im Rahmen des High-Availability-
Modus von einem havarierten Host auf einen laufenden Host zu evakuieren und dort nahezu
verzögerungsfrei weiter zu betreiben. Abhilfe würde an dieser Stelle eine SAN-Lösung mit
zwei unabhängigen Controllern bieten, wie in Abbildung 23 abgebildet.
Abb. 23: Vergleich des logischen Aufbaus eines Storage-Area-Network im Single Controller
Betrieb (oben) mit einem im Dual-Controller-Betrieb (unten)
66

Bachelorthesis Jan Simmendinger
5.5.2. Verwendung von IGEL UMS
Anpassungen an den IGEL ThinClients, wie Domänenmitgliedschaft, IP-Konfiguration,
NetBIOS-Namen und USB-Berechtigungen, wurden während den Vorbereitungen zum
Rollout direkt an den Clients durchgeführt. Durch den Schreibschutz, der den
Flashdatenträger und damit das embedded Betriebssystem des ThinClients vor unbefugten
Veränderungen durch den Benutzer schützt, war es notwendig, die vorgenommenen
Änderungen jeweils durch einen manuellen Eingriff während eines Neustarts dauerhaft zu
übernehmen. Aus diesem Grund ist es derzeit nicht möglich, Einstellungen per Fernzugriff an
den ThinClients vorzunehmen. Da während der Rollout-Phase ohnehin jeder Arbeitsplatz
aufgesucht werden musste, konnten die arbeitsplatzspezifischen Einstellungen, wie
beispielsweise die Bildschirmauflösung, in einem Arbeitsgang gleich mit eingestellt und
gesichert werden.
Um bei zukünftigen Anpassungen nicht erneut jeden Arbeitsplatz unternehmensweit
aufsuchen zu müssen, bietet es sich an, die vom Hersteller bereitgestellte
Verwaltungssoftware IGEL UMS (Universal Management Suite) näher zu betrachten. Diese
ermöglicht, laut Hersteller, individuelle oder globale Konfigurationsänderungen an den
Geräten über das Netzwerk.
5.5.3. Aufsetzen eines lokalen Microsoft Exchange Servers
Das Hosting der Mouldtec Emailpostfächer erfolgt bei einem externen Dienstleister und die
Outlookclients auf dem Terminalserver kommunizieren via POP3 und SMTP mit dem
externen Mailserver. Das bedeutet, dass jede unternehmensinterne Email jeweils zweimal
über die DSL-Leitung bewegt werden muss und die Speicherung der Mails nach dem Abholen
in der jeweiligen PST-Datei eines Benutzers erfolgt.
Um das Konzept des hausintern betriebenen, zentralen Informationssystems zu
vervollständigen, würde sich die Implementierung eines Microsoft Exchange Servers
anbieten, der neben der Funktionalität als Mailserver noch Funktionen zur
67

Bachelorthesis Jan Simmendinger
unternehmensweiten Zusammenarbeit betreffend Kalendereinträgen und Adressbüchern
ermöglichen würde.
6. Abschließende Bewertung und Ausblick
Sind Systemarchitekturen, bei denen Virtualisierung eingesetzt wird, geeignet, um bei
kleinen und mittleren Unternehmen die Kosten für Anschaffung, Unterhalt und Entsorgung
zu verringern? Diese Frage, aus der Einleitung dieser Arbeit, soll nun geklärt werden.
Wie im zweiten Teil der Ausarbeitung geschildert, wird dies in der betrieblichen Praxis
bereits so realisiert. Durch die Verfügbarkeit allumfassender, teilweise sogar kostenloser
Virtualisierungslösungen besteht kein Grund mehr, die Verkleinerung des physikalischen
Geräteparks und die Verringerung des administrativen Aufwands durch Verlagerung von
physikalischen Systemen in die Softwareebene nicht zu nutzen.
Die Rechnung in Abbildung 24 zeigt einen beispielhaften Vergleich der Anschaffungs- und
Betriebskosten der in der Arbeit vorgestellten neuen Systemlandschaft der Firma Mouldtec,
einmal wie realisiert mit Virtualisierung und einmal in einer klassischen Implementierung.
Abb. 24: Vergleich der geschätzten Gesamtkosten, die bei der jeweiligen Implementierung
über 3 Jahre hinweg auflaufen
Die Beispielrechnung demonstriert den klaren Kostenvorteil von virtualisierten
Infrastrukturen, auch für den Einsatz bei kleinen und mittleren Unternehmen.
Eine deutlich höhere Flexibilität spricht ebenso klar dafür, auch wenn in den betrachteten
Unternehmen meist keine so starke Veränderung der Systemlandschaft herrscht.
68

Bachelorthesis Jan Simmendinger
Eine zunehmend interessante Alternative zur Virtualisierung von inhouse gehosteten
Serversystemen ist die Nutzung von externen Rechenzentren. Durch das hohe Maß an
Spezialisierung solcher Dienstleister und die damit einhergehenden Kostenvorteile wird die
Zukunft vermutlich im sogenannten Cloud-Computing liegen. (siehe Kapitel 4.1.4.1.)
Allerdings muss jeweils im Einzelfall entschieden werden, ob die ausgelagerten Daten zu
sensibel sind, um sie in die Obhut eines externen Unternehmens zu geben oder ob es ein
vertretbares Risiko darstellt, die Daten entsprechend verschlüsselt bei einem Dienstleister
abzulegen.
Abb. 25: Ausschnitt aus der Preistabelle der Firma JiffyBox - hier werden Cloudserver angeboten,
deren Preis sich nach der Nutzungszeit richtet, vergleichbar mit einem Telefonanschluss
69

Bachelorthesis Jan Simmendinger
Glossar
Bottom Up Methodik, etwas von unten nach oben zu analysieren
embedded OS ein in ein Gerät fest integriertes und darauf angepasstes Betriebssystem
Go Live die Phase, in der ein IT-System in den Produktivbetrieb geht
Host Computer der einen oder mehrere Dienste zur Verfügung stellt
inhouse Hosting das Betreiben von Servern im eigenen Haus
NAS Network attached Storage = über ein Netzwerk angeschlossenes
Speichergerät (Netzwerkfestplatte)
Shareholder Anteilseigner/Inhaber eines Unternehmens
Smartphone Mobiltelefon mit Computerfunktionalitäten wie Kalender,
Kontaktverwaltung und Internetzugang
Stakeholder Person, die Interesse am erfolgreichen Verlauf eines Projektes hat
Tablet PC Flacher, akkubetriebener, tragbarer Computer mit einem Touchscreen
anstatt einer Tastatur
Top down Methodik, etwas von oben nach unten zu analysieren
Treiber ein gerätespezifisches Softwaremodul, das eine standardisierte Software-
schnittstelle für die Interaktion mit dem entsprechenden Gerät anbietet
Update / Patch Ein Modul das von einem Softwarehersteller nachgeliefert wird um Fehler
zu beheben oder Sicherheitslücken zu schließen
70

Bachelorthesis Jan Simmendinger
Abbildungsverzeichnis
Abb. 1: Aufteilung von Arbeitsspeicher bei Virtualisierung
Abb. 2: Vergleich von Hypervisoren
Abb. 3: Vergleich möglicher Anbindungen von Festplattenspeicher an Serversysteme
Abb. 4: Energiesparpotentials des Prozessors bei Zusammenfassung von zwei Maschinen
Abb. 5: Darstellung der Migration eines virtualisierten und eines Bare-Metal-Betriebssystems
Abb. 6: Ohne Desktopvirtualisierung ungenutzt verbleibende Ressourcen
Abb. 7: Funktionsweise einer Lösung zur Anbindung von USB-Geräten an virtuelle Maschinen
Abb. 8: Auswahl und Gruppierung der in Frage kommenden Technologien
Abb. 9: Bewertungsmatrix zur Findung des am besten geeigneten Konzepts
Abb. 10: Beispielhafte Aufteilung der Arbeitspakete bei der Fertigung eines Automobils
Abb. 11: Projektablaufplan mit voraussichtlicher Dauer
Abb. 12: ThinClient DT166
Abb. 13: Ausschnitt aus der Dokumentation der alten Infrastruktur
Abb. 14: Projektablaufplan
Abb. 15: Übersicht über das neue Netzwerklayout der Firma Mouldtec
Abb. 16: Gesamtüberblick über die neue Infrastruktur
Abb. 17: Logischer Überblick über die Migrationen der einzelnen Serversysteme
Abb. 18: Vergleich der Rechtevererbung für Freigaben unter Windows und AS/400 NetServer
Abb. 19: IGEL ThinClient
Abb. 20: Funktionsweise verschiedener RAID-Konfigurationen
Abb. 21: Alte und neue Appliance für den Zugang zum Internet mit Router und Firewall
Abb. 22: automatische Adressergänzung eines Outlookclient mit importierter NK2 Datei
Abb. 23: Vergleich eines Single Controller und eines Dual-Controller Storage-Area-Network
Abb. 24: Vergleich der geschätzten Gesamtkosten bei verschiedenen Implementierungen
Abb. 25: Ausschnitt aus der Preistabelle der Firma JiffyBox
71

Bachelorthesis Jan Simmendinger
Literaturverzeichnis
Bücher und Fachbeiträge
[Brugger] Brugger, Ralph: IT-Projekte strukturiert realisieren. Wiesbaden 2. Auflage,
Dezember 2005
[Keuper] Keuper, Frank / Hamidian, Kiumars / Verwaayen, Eric / u.a.: TransformIT:
Optimale Geschäftsprozesse durch eine transformierende IT. Wiesbaden
1. Auflage, 2010
[Noppenberger] Noppenberger, Martin: Kostenminimierung in Speichernetzwerken.
Köln 1. Auflage, November 2009
[BITKOM] BITKOM, Bundesverband Informationswirtschaft, Telekommunikation und
neue Medien e. V.: Energieffizienz im Rechenzentrum. Berlin-Mitte
1. Auflage, 2010
Elektronisch verfügbare Dokumente
[Netzwelt] Markus Franz: Virtuelle Server mit Windows und Linux. September 2010. URL:
http://www.netzwelt.de/news/84115-xen-virtuelle-server-windows-linux.html
[CW01] Andrej Radonic: Server-Virtualisierung zum Nulltarif. April 2011. URL:
http://www.computerwoche.de/hardware/data-center-server/1932017/index4.html
[CW02] Michael Pietroforte: Der nächste Trend heißt Anwendungs-Virtualisierung.
August 2008. URL: http://www.computerwoche.de/software/software-infrastruktur/1869889/
[IBM] IBM Systems: Datenblatt IBM System x3650 M3. Ehningen 2011. URL:
http://public.dhe.ibm.com/common/ssi/ecm/de/xsd03060dede/XSD03060DEDE.PDF
[Jiffy] Preisliste Jiffybox. Jiffybox, Oktober 2011. URL: https://www.jiffybox.de/#third
72