BACHELORTHESIS. Fakultät Informatik. Studiengang Wirtschaftsinformatik

Transkript

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

2 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

3 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

4 Inhalt 1. Einleitung Definitionen Begriffe und Schlüsselwörter IT-Strategie Backup und Sicherungstechnologien Migration Virtualisierung Eingesetzte Maschinen ThinClient SAN (Storage-Area-Network) Terminalserver Vorgehensweisen bei der Migration Kontinuierlicher Übergang Iterative Migration Vollmigration Theorie Gründe für Hostvirtualisierung Antrieb für die Virtualisierung von Serversystemen Energie Geringerer Wartungsaufwand und kürzere Bereitstellungszeiten Erhöhte Zuverlässigkeit Einfache Rollback- und Backupfunktionalität Hardwareunabhängigkeit Ortsunabhängige Systemwartung Kapital Gründe für die Desktopvirtualisierung Triebfedern Zentrale Bündelung der Ressourcen Geringere Anforderungen an die Clients Vorteile bei der Datensicherung Flexible Nutzung von Anwendungen Plattformunabhängigkeit

5 Vereinfachte Administration Virtualisierungslösungen ESXi und vsphere von VMWare Microsoft Hyper-V Citrix XEN Server QEMU Warum wird migriert Gründe für Erneuerung Nachteile gewachsener Strukturen Probleme veralteter Systeme Vorteile einer Erneuerung Vorgehensweise bei Migrationsprojekten Grundlagenplanung Zustand der technischen Systeme und der Dokumentation Analyse von Aufgaben und Orientierung am Prozessmanagement Technologischen Fortschritt nutzen Vorüberlegungen zu Alternativen im Hostbereich Outsourcing Hostsysteme in Hardware Konsolidierung von Diensten auf einem Betriebssystem Vorüberlegungen zu Alternativen im Desktopbereich Anwendungsvirtualisierung Nutzung von Diensten im Browser Projektumfang und Rahmenbedingungen Kapital Aufwand Technische Gegebenheiten Konzepte Ideen sammeln und bündeln Bewertung der Konzepte und Freigabe Erstellung eines Projektplans Arbeitspakete definieren Klären von Personal- und Kompetenzfragen Klären von Abhängigkeiten und Erstellung des Zeitplans

6 Projektdurchführung und Steuerung Praktische Umsetzung Ein Praxisbericht Übersicht Server und Hosts APPLNX V5R3M APPWIN APPWIN ThinClients Netze Veralteter Internetbrowser Zusammenfassung der Schwachstellen Planung der neuen Infrastruktur Ideensammlung und Konzeptfindung Personaleinsatz Aufteilung der Arbeitspakete zu einem Ablaufplan Das neue System Übersicht Logische Übersicht über die Migration der einzelnen Server Übernommene Daten aus den Altsystemen Benutzerkonten vom X-Kontroller konten von APPWIN Dateien vom alten Netzlaufwerk übernehmen Neue ThinClients Storage-Lösung Die Migration Vorgehensweise Vorbereitungen Inbetriebnahme der neuen Security Appliance Die Hauptmigrationsphase Aufgaben im Nachgang Erhöhung der Benutzerakzeptanz Probleme und Lösungsansätze

7 Zuverlässigkeit ESXi Verwendung von IGEL UMS Aufsetzen eines lokalen Microsoft Exchange Servers Abschließende Bewertung und Ausblick Glossar Abbildungsverzeichnis Literaturverzeichnis

8 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

9 2. Definitionen 2.1. Begriffe und Schlüsselwörter 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 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 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

10 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 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

11 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

12 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 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

13 diesem Grund haben ThinClients meist einen im Verhältnis zu aktuellen Personal Computern relativ leistungsschwachen Prozessor 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

14 Abb. 3: Vergleich einer direkten Anbindung von Festplattenspeicher an Serversystemen (oben) mit einer Anbindung über ein Storage-Area-Network (unten) 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

15 2.3. Vorgehensweisen bei der Migration Eine Systemmigration, also die Integration von Neusystemen oder der Umstieg auf andere Systeme, kann verschiedenen organisiert werden 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 beschrieben ist 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

16 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 stellt an dieser Stelle sehr hilfreiche Werkzeuge zur Planung des Zeitrahmens des Gesamtprojekts zur Verfügung 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

17 3. Theorie 3.1. Gründe für Hostvirtualisierung 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 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

18 Abb. 4: Veranschaulichung des Energiesparpotentials des Prozessors bei Zusammenfassung von zwei Maschinen auf einer physikalischen Maschine 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

19 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 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 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

20 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 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

21 Abb. 5: Darstellung der Migration eines virtualisierten (unten) und eines Bare-Metal- Betriebssystems (oben) Ortsunabhängige Systemwartung Die in Abschnitt 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

22 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 Gründe für die Desktopvirtualisierung 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 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

23 Abb. 6: Ohne Desktopvirtualisierung verbleiben viele Ressourcen ungenutzt, da jeder Client einen eigenen Puffer für Lastspitzen vorhält 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 ) 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 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

24 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 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

25 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 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

26 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 Virtualisierungslösungen Die zum Betrieb virtueller Maschinen notwendige Softwareumgebung, bestehend aus Hypervisor und Programmen zur Installation, Erstellung und Wartung der Systeme, gibt es 26

27 von verschiedenen Herstellern mit unterschiedlichen Funktionen in allen Preisklassen. In diesem Abschnitt werden die bekanntesten Lösungen mit den größten Marktanteilen vorgestellt 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 Microsoft Hyper-V Die Virtualisierungsplattform Hyper-V von Microsoft ist keine Bare-Metal-Virtualisierungslö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

28 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 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 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

29 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 Warum wird migriert 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

30 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 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

31 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 Vorteile einer Erneuerung Je nach Umfang behebt eine Erneuerung des betrieblichen Informationssystems die im Kapitel 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

32 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 Grundlagenplanung 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 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

33 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] 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 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 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

34 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-, Kollaborationsund 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

35 Durch die zunehmende Verbreitung und die sinkenden Preise von Breitbandzugängen muss dieser Ansatz ganz klar als Zukunftstrend betrachtet werden 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 Planungsprogrammen (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

36 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 ) 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

37 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 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 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

38 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 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

39 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 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 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

40 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 genannten, Stakeholdern des Projekts abgestimmt werden muss 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

41 Anforderungen diese erfüllen. Zu nennen sind hier Lüftungs- und Klimatechnik, Feuchtigkeit, Verfügbarkeit von Strom- und Kommunikationsleitungen sowie die Zutrittskontrolle Konzepte Sind die finanziellen und technischen Rahmenbedingungen aus Kapitel 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 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 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

42 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

43 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 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 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

44 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 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

45 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: Lösungsansätze: Werden die jeweiligen Pakete in der veranschlagten Zeit erledigt? Erhöhung der Mitarbeiter an Paketen, die die Gefahr mit sich bringen, das gesamte Projekt in Verzug zu bringen Schwerpunkt 3 - der finanzielle Aufwand: Fragestellung: Lösungsansatz: Bleibt die Summe der Kosten der Pakete innerhalb des genehmigten Budgets? 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

46 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 Ü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 Server und Hosts Die damalige Serverlandschaft von Mouldtec umfasste die nachfolgend genannten Hostsysteme. 46

47 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/ 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 APPWIN01 Ein Windows 2003 Server, der den Benutzern per Remotedesktop ein Microsoft Office 2003 Paket anbot und über Outlook dem Senden und Empfangen von s diente. Zusätzlich 47

48 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 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 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

49 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 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

50 Abb. 13: Ausschnitt aus der Dokumentation der alten Infrastruktur, anhand derer die Vielzahl an verwendeten Subnetzen ersichtlich ist 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 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

51 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 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

52 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 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

53 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

54 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 Das neue System Ü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

55 Abb. 16: Gesamtüberblick über die neue Infrastruktur 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

56 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 Übernommene Daten aus den Altsystemen 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

57 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 konten 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 adressen (*.NK2) extrahiert 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

58 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 = MB Kopierzeit: MB / 12MB/s = 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

59 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 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

60 Abb. 19: IGEL ThinClient, wie er in der neuen Infrastruktur zum Einsatz kommt 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

61 Abb. 20: Funktionsweise verschiedener RAID-Konfigurationen 5.4. Die Migration 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 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

62 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

63 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 adressbü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

64 Abb. 22: Nach der erfolgreichen Migration der NK2-Datei ist die automatische Adressergänzung eines Outlookclient wieder mit allen genutzten Adressen verfügbar 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

65 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 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 Probleme und Lösungsansätze Zuverlässigkeit ESXi Die in Kapitel 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

66 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

67 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 Aufsetzen eines lokalen Microsoft Exchange Servers Das Hosting der Mouldtec postfä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 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

68 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

69 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 ) 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