Organisation des IT-Servicemanagements nach ITIL (Schwerpunkt: Service Operation)
Aus Winfwiki
| Name der Autors: | Alexander Tews |
| Titel der Arbeit: | Organisation des IT-Servicemanagement nach ITIL mit dem Schwerpunkt Service Operation
am Fallbeispiel Upgrade eines Produktionsclusters |
| Betreuer: | Professor Dr. Ralf Hötling |
| Hochschule und Studienort: | FOM Hochschule für Oekonomie und Management Berlin |
| Eingereicht am: | 28. Februar 2010 |
1 Abkürzungsverzeichnis
| COBIT | Control Objectives for Information and Related Technology |
| CMMI | Capability Maturity Model Integration |
| DHCP | Dynamic Host Configuration Protocol |
| DNS | Domain Name System |
| FC | Fibre Channel |
| HDD | Hard Disk Drive |
| HPC | High Performance Cluster |
| iSCSI | internet Small Computer Interface |
| KW | Kilowatt |
| LACP | Link Aggregation Control Protocol |
| LSR | Luftschutzraum |
| MSA | Modular Smart Array |
| OGC | Office of Government Commerce |
| ITIL | IT Infrastructure Library |
| IT | Informationstechnologie |
| ITSM | IT Service Management |
| RAM | Random-Access Memory |
| SAN | Storage Area Network |
| SAS | Serial Attached SCSI |
| SCSI | Small Computer System Interface |
| SLA | Service Level Agreement |
| TB | Terabyte |
| TCP | Transmission Control Protocol |
| VLAN | Virtual Local Area Network |
| VSS | Virtual Switching System |
| WINS | Windows Internet Naming Service |
| WPA2 | Wi-Fi Protected Access 2 |
2 Abbildungsverzeichnis
| Abbildung 1 | Lampertz LSR 18.6 E RZ Zelle groß |
| Abbildung 2 | Wagner Oxy Reduct |
| Abbildung 3 | HP c7000 Enclosure 1 und 2 (eigene Darstellung) |
| Abbildung 4 | Ethernet Uplink c7000 und Cisco Core Switch (eigene Darstellung) |
| Abbildung 5 | Fibre Channel Infrastruktur (eigene Darstellung) |
| Abbildung 6 | ITIL Kernpublikationen |
| Abbildung 7 | Gleichgewicht zwischen externem und internem Fokus |
| Abbildung 8 | Gleichgewicht zwischen Servicequalität und Servicekoste |
| Abbildung 9 | Gleichgewicht Stabilität und Reaktionsfähigkeit |
| Abbildung 10 | Organisation des IT-Betriebs nach technischer Spezialisierung (Beispiel) |
| Abbildung 11 | Cluster Ausgangszustand (eigene Darstellung) |
| Abbildung 12 | Cluster Ressourcen Migration (eigene Darstellung) |
| Abbildung 13 | Cluster Node 1 wird entfernt (eigene Darstellung) |
| Abbildung 14 | Cluster Node 1 wird aktualisiert (eigene Darstellung) |
| Abbildung 15 | neues Cluster wird erstellt (eigene Darstellung) |
| Abbildung 16 | Cluster Node 2 wird zerstört (eigene Darstellung) |
| Abbildung 17 | Cluster Node 2 wird aufgenommen (eigene Darstellung) |
| Abbildung 18 | Cluster Zielzustand (eigene Darstellung) |
3 Einführung
3.1 Problemstellung und Zielsetzung der Arbeit
Derzeit bewegen sich fast alle Unternehmen im Zeitalter der sich ständig ändernden und zunehmenden technologischen Entwicklungen, wo es immer schwieriger wird, sich einen Wettbewerbsvorteil zu verschaffen. Gerade jetzt muss die IT flexibel, schnell, effizient, in höchster Qualität und kostengünstig auf verändernde Business Anforderungen reagieren.
Mehr und mehr Unternehmen befassen sich daher mit öffentlich verfügbaren Frameworks und Standards wie ITIL, COBIT, ISO/IEC 20000, da das Wissen öffentlicher Frameworks einer umfassenden Prüfung über mehrere Organisationen und Disziplinen hinweg unterliegt. Wenn öffentliche Frameworks und Standards missachtet werden, können für eine Organisation unnötige Nachteile entstehen.
Ziel dieser Fallstudie ist es aufzuzeigen, dass auch größere Veränderungen im Servicebetrieb durchaus ohne erkennbare Folgen für Kunden und Anwender bleiben können. Es wird ein konkretes Fallbeispiel beschrieben, sowie die konkrete Umsetzung und Implementierung der aus der Infrastructure Library in der Version 3 stammenden Publikation Service Operation.
3.2 Aufbau und Ablauf der Arbeit
In den darauffolgenden Kaptiteln wird die XYZ AG vorgestellt (Kapitel 2), sowie deren bestehende IT Services (Kapitel 3). Die weiteren Kapitel beschäftigen sich mit dem Soll-Zustand der IT-Services (Kapitel 4) und den theoretischen Grundlagen des ITSM und dessen Umsetzung an einem realen Fallbeispiel (Kapitel 5). In der Schlussbetrachtung wird ein Fazit gegeben (Kapitel 6).
4 Vorstellung des Unternehmens
4.1 Kennzahlen des Unternehmens
Im Rahmen dieser Fallstudie wird ein reales mittelständisches Unternehmen, das weltweit in 70 Standorten aufgestellt ist, näher betrachtet werden. Dieses Unternehmen wird hier anonymisiert benannt als „XYZ AG“. Die XYZ AG beschäftigt mehr als 12000 Mitarbeiter und ist in 52 Ländern vertreten. Im Jahr 2009 verzeichnete die XYZ AG einen Gesamtgewinn von über 280 Millionen Euro.
4.2 Bedeutung der Zweigstelle Berlin
Derzeit arbeiten am größten Standort über 1500 Mitarbeiter. Am Standort Berlin besitzt das Unternehmen derzeit 5 Gebäude, wobei sich das 6. Gebäude bereits im Bau befindet und Mitte 2010 fertig gestellt sein wird. Berlin als einer von drei Hauptstandorten stellt in seinem Rechnenzentrum mit über 200 physischen Servern fast alle wichtigen IT Services des gesamten Unternehmens bereit. Unter anderem zählen dazu Web-, Virtualisierungs-, Datenbank-, E-Mail-, Fax-, Terminal-, Voice-, Datei- und Druck- und Applikationsserver. Für über 5000 Mitarbeiter in Europa, die sich auch Remote in das Firmennetzwerk einwählen können, ist Berlin der zentrale Einwahlknoten. Viele Mitarbeiter der anderen Standorte als auch externe Kunden der XYZ AG nutzen ebenso die angebotenen IT-Services. Dies macht den Standort zu einem der strategisch am wichtigsten.
4.3 Aufgaben eines Rechenzentrums
Ein Rechenzentrum ist ein Bereich, ein Raum, eine Einrichtung oder ein Standort einer zentralen Datenverarbeitung. Rechenzentren stellen Ihre Rechenleistung der eigenen oder fremden Firmen gegen Entgelt zur Verfügung. Der Betrieb von Rechenzentren geht über den klassischen Aufgabenbereich der datentechnischen Aufarbeitung, Verarbeitung und Speicherung von Anwenderdaten weit hinaus. Wirtschaftliche, organisatorische, sicherheitstechnische, energieeffiziente, verfügbarkeitsrelevante und rechtliche Fragen gewinnen dabei immer mehr an Bedeutung. Wichtige Aspekte für den Betrieb von Rechenzentren sind die Verfügbarkeit und Sicherheit der IT-Dienste. Diese sind unmittelbar von der Stromversorgung, die auch bei Netzausfall über USV-Systeme gewährleistet sein muss, über die Kühlung, die Notfallabsicherung mit Backups, über Überwachungseinrichtungen und redundant ausgelegten Systemkomponenten abhängig. Diese vielen Aspekte lassen sich mit einem Komplexitätsmanagement optimal steuern. [1]
4.4 Rechenzentrum der XYZ AG
In der XYZ AG wird die IT-Infrastruktur bestehend aus Netzwerkkomponenten und Servern durch einen Sicherheitsraum der Klasse LSR 18.6 E, gebaut von der Firma Lampertz, geschützt. Diese Lösung bietet höchste Sicherheit durch komplexen 4-schichtigen Elementkern aus thermisch wirksamen Dämmsubstanzen, einer Hochsicherheitstür mit Mehrfachverriegelung sowie feuersichere Einlegebögen.
 Abbildung 1 - Lampertz LSR 18.6 E RZ Zelle[2] |
 Abbildung 2 – Wagner Oxy Reduct[3] |
Optional kann dieser Raum mit weiteren Sicherheitsfunktionen wie Brandfrühsterkennung, Brandmelde- und Löschsysteme, Kabelmanagement und Kabelschottung, Zutrittskontrolle, Raumüberwachung, Alarmkonzept, Wasserwarnanlage, Fernüberwachung, Videoüberwachung erweitert werden. Dies schützt den sensiblen Unternehmensbereich der XYZ AG vor unbefugten Zutritt, physikalischen Gefahren wie Einbruch, Wasserschäden, Einsturz des Gebäudes, Explosion und auch thermischen Gefahren wie z.b. Brand im Gebäude. [4]
Das RZ wird von 2 unterschiendlichen Klimatisierungsanlagen mit eigenständigen Kreisläufen versorgt. Zusätzlich wird die Luft über so genannte „Befeuchter“ bzw. „Entfeuchter“ befeuchtet bzw. getrocknet, um die empfohlene Luftfeuchtigkeit zu erlangen. Damit soll sichergestellt werden, dass die Komponenten möglichst ohne Unterbrechungen ihre Lebenszeit erreichen oder sogar noch überdauern.
Sollten unterschiedliche Empfehlungswerte von einzelnen Herstellern vorliegen, sollte das arithmetische Mittel als Optimum gewählt werden, um den Abweichungsfaktor für alle Komponenten gleich günstig bzw. ungünstig auszulegen.
Die XYZ AG hat zusätzlich zu allen optionalen Sicherheitsfunktionen die systemkritischen Komponenten durch zwei USV Anlagen mit jeweils 170 KW von der Firma APC, sowie mit redundanter Sauerstoffreduktionsanlagen der Firma Wanger und einem Dieselaggregat ausgestattet.
Die unterbrechungsfreien Stromversorgungen überbrücken bei Stromausfall die RZ-Komponenten mit Strom, bis das Dieselaggregat angelaufen ist und die komplette Stromlast übernommen hat. Die XYZ AG verwendet Online USV Geräte, diese echten Stromgeneratoren erzeugen ständig eigene Netzspannung und haben daher keine Umschaltzeit, die bei hochsensiblen Systemen Probleme bereiten würde. [5]
Die Sauerstoffreduktionsanlagen dienen der aktiven Brandvermeidung. Durch Einleiten von Stickstoff wird die Sauerstoffkonzentration exakt auf den eingestellten Wert, meist 15% abgesenkt und dort gehalten. In dieser Atmosphäre kann die Entstehung eines offenen Brandes ausgeschlossen werden, da der vorhandene Sauerstoff nicht mehr ausreicht um ein Feuer aufrecht zu erhalten. Damit werden keine aktiven Brandbekämpfungssysteme mehr benötigt. Aktive Brandsysteme die nicht mit Gas sondern Wasser löschen richten zudem meist sehr hohe Folgeschäden besonders in Rechenzentren an.[6]
5 Ist-Zustand – bestehende IT-Services
5.1 Definition eines Clusters
In der Informationstechnologie versteht man unter einem Cluster einen Verbund aus eigenständigen, vernetzten Computern, die sich wie ein virtueller Prozessor verhalten. Man unterscheidet grundsätzlich zunächst, ob es sich um ein Hardware oder Software Cluster handelt. Hardware Cluster können dann nochmals zwischen aktiv und passiv unterschieden werden. Ein Cluster besteht demnach aus mindestens zwei, meist hardwaretechnisch identischen Knoten (homogen), die zusätzlich über ein dediziertes Netzwerk verbunden sind. Laufen auf beiden Knoten ständig Dienste spricht man von einem aktiv-aktiv Cluster. Sind nicht alle Knoten aktiv, spricht man hingegen von einem aktiv-passiv bzw. asymmetrischen Cluster. Sind Cluster standortübergreifend, also mehrere Kilometer von einander entfernt nennt man diese stretched Cluster. Je nach Anwendung unterscheidet man zwischen High Performance Cluster (HPC), Parallel-Cluster, Throughput-Cluster und Failover-Cluster.[7]
5.2 Grundsätzliche Anforderungen an ein Cluster
Das Serverbetriebssystem, muss grundsätzlich in der Lage sein, eine Clusterkonfiguration zu unterstützen. Nicht alle Betriebssystem-Services lassen eine Clusterkonfiguration zu. Hierzu gibt es unterstützte Konfigurationen von den Herstellern. Wenn es um Applikationen geht, die geclustert werden sollen, muss die Applikation selber clusterfähig sein und auch ein Clustermodell des zu verwenden Betriebssystems unterstützen. Zum Beispiel die Applikation Rightfax der Firma Captaris ist selbst clusterfähig und unterstützt die Installation auf einen Windows Server 2003 Cluster. Die eigentliche Herausforderung an Clustersystemen besteht darin, dass alle Knoten die virtuellen Ressourcen übernehmen können müssen, wenn einer der Knoten ausfällt. Das bedeutet in der Praxis, dass die logische Disk, die die Ressourcen benutzen, allen Clusterbeteiligten Knoten präsentiert werden muss.
5.3 Speicherkapazitäten der XYZ AG
Dies erfolgt in der Regel über ein Storage Area Network (SAN) oder ein Modular Smart Array (MSA). Mehrere solcher SAN / MSA können selbst untereinander gespiegelt sein, um eine höhere Ausfallsicherheit zu gewährleisten. Die XYZ AG besitz eine MSA mit 48 x 750GB SATA HDD die jeweils in 4 logische Disks im RAID 6 Verbund unterteilt sind. Die Aufteilung der Disks erfolgte in 2 x 8 Disks und 2 x 16 Disks mit einer Gesamtkapazität von 30 TB. Zusätzlich besitzt die XYZ AG eine SAN mit 112 x 300 GB FC HDD die wiederum in logische Disks im Verbund RAID 5 und Raid 10 unterteilt sind. Die Gesamtnutzkapazität der SAN beläuft sich auf 20 TB.
5.4 iSCSI im Vergleich zu Fibre Channel
Die SAN Systeme werden entweder über das iSCSI Protokoll angesprochen, als preiswerte Methode, da dieses Protokoll die bestehende Ethernetinfrastruktur benutzt oder über ein dediziertes Fibre Channel Netzwerk, als professionelle aber auch sehr kostenintensive Variante. Die Fibre Channel Lösung erfordert jedoch eine eigene Fibre Channel Infrastruktur mit Fibre Channel Switches, sowie Fibre Channel Karten in den Servern. Auch die beteiligten Array Systeme müssen das Fibre Channel unterstützen und über die entsprechende Anschlüssen verfügen. Eine dedizierte Infrastruktur ist zwar sehr teuer bietet jedoch auch einige Vorteile gegenüber dem iSCSI Protokoll ( SCSI over TCP). Fibre Channel benutzt als Übertragungsmedium Glasfaserkabel und nicht Kupfer, dies erlaubt höhere Bandbreiten und weniger Störanfälle durch z.b. viel Brodcast, bzw. durch hohe Bandbreitennutzung andere Systeme im Ethernet Bereich. Derzeit liegen die Datenübertragungsraten im Fibre Channel Netzwerk bei 8GB/s was im Vollduplex-Betrieb Datentransferraten von 800MB/s erlaubt. Bei der Verwendung eines Netzwerks mit 1GB/s, derzeit üblich im Serverbereich ist iSCSI deutlich langsamer als Fibre Channel. Die ersten 10Gbit Ethernet Karten kommen derzeit auf den Markt, diese würden dann eine höhere Geschwindigkeit erreichen, bedeutet aber auch dass alle Netzwerkkomponenten mit 10Gbit angesprochen werden müssen. Ein weiterer Nachteil der iSCSI Technologie ist eine erhöhte CPU-Belastung der Server und mehr Interrupts pro Datenmenge für den Server. Dies kann mit Offload Engine Karten nur vermindert werden.
5.5 Vorstellung des Windows Cluster in der XYZ AG
Viele Serversysteme werden in so genannten Cluster zusammengefasst und ermöglichen damit, dass IT-Services zum einen durch Lastenausgleich schneller und zum anderen durch zweimal redundante Hardware hochverfügbar werden. Derzeit befinden sich im RZ Berlin über 5 Clustersysteme. Aus Gründen der Übersicht und Vereinfachung soll hier nur eines der Cluster Systeme ausführlicher betrachtet werden. Das zu betrachtende Clustersystem besteht aus 2 Windows Server in der Version 2008 Standard x64bit, die jeweils auf HP Blades installiert sind. Dabei handelt es sich um Blades mit der Modellbezeichnung BL460c G1 (Generation), mit jeweils 10GB RAM und 2 x 146GB SAS 2,5“ HDD im Raid 1+0. Beide Nodes beinhalten jeweils 2 x 3.0 Ghz Quad Core Intel Prozessoren und befinden sich jeweils in einem separaten HP Blade Enclosure c7000. Die c7000 Gehäuse zeichnen sich dadurch aus, dass alle Komponenten redundant ausgelegt sind. Das betrifft sowohl die Netzteile als auch die Lüfter und die Steuerung der Enclosure über die Onboard Administrator Module.
5.5.1 Ethernet Uplink des c7000 Enclosure
Beide HP c7000 Enclosure sind jeweils mit 2 x 10Gbit Ethernet Uplinks an jeweils 2 x Cisco Catalyst 6500 Core Switch angeschlossen. Beide Cisco Core Switches sind untereinander über ein VSS Channel geclustert. Der VSS Channel ermöglicht damit, dass die zwei 10Gbit Ethernet Uplinks der Enclosure auch gechannelt werden können, hier über LACP, obwohl ein Uplink zur Core Switch 1 und der zweite Uplink zur Core 2 geht. Die Gesamtnetzwerkbandbreite der jeweiligen Enclosure beträgt somit 20Gbit für maximal 16 Server. Diese Konfiguration ermöglicht eine hohe Bandbreite für die Datenübertragung und erlaubt eine hohe Zugrissfrequenz, da die Server direkt an die Hauptnetzwerkswitch angeschlossen sind.
5.5.2 Fibre Channel Uplink des c7000 Enclosure
Weiterhin sind beide c7000 Enclosure mit zwei Uplinks 4Gbit pro Virtual Connect FC Module an 2 x Brocade 4/32 Fibre Channel Switches angeschlossen. Dies ermöglicht eine redundante Anbindung and das Fibre Channel Netzwerk für die Nutzung der Enterprise Storage Komponenten wie SAN und MSA.
5.5.3 IT-Services auf dem Cluster
Auf dem betrachteten Clustersystem werden derzeit wichtige IT-Infrastruktur Dienste wie DHCP, Datei- und Druckserver sowie der Backup Service für über 1000 Mobile Benutzer angeboten.
5.5.3.1 DHCP Server
Das Dynamic Host Configuration Protocol ist dafür verantwortlich, dass alle Geräte wie z.b: Client-Computer, Telefone, Drucker und Server Ihre Netzwerkkonfiguration zugewiesen bekommen. Dies ermöglicht erst die aktive Teilnahme der Geräte im Netzwerk, da der DHCP Server den Geräten Informationen über Ihre IP-Adresse und Netzwerkmaske, Default-Gateway, und den Namensservice wie DNS-, Wins-Server bereitstellt und zudem sicher stellt, dass kein Gerät dieselbe IP-Adresse erhält. Sollten zweie Geräte innerhalb des gleichen Netzwerksegment dieselbe IP-Adresse erhalten, würde das zu einem IP-Adressen-Konflikt führen und die betroffenen Geräte könnten nicht unterbrechungsfrei und zuverlässig arbeiten.
5.5.3.2 Dateiserver
Der Dateiserver der XYZ AG gewährleistet nur authorizierten Benutzern den Zugriff auf Ihre Daten. Zudem ermöglicht der Dateiserver die zentrale Speicherung von firmenrelevanten Daten. Die zentrale Speicherung erlaubt dementsprechend auch eine zentrale Datensicherungen alle firmenrelevanter Daten und gewährleistet, dass die Daten durch ein Disk-Array sicher gegenüber Festplattendefekten sind. Die Daten sind auch physisch geschützt, da sich diese auf dem Server bzw. auf ein Array System gespeichert werden, welches sich wiederum im RZ befindet.
5.5.3.3 Druckserver
Der Druckserver ermöglicht die Entgegennahme der Druckaufträge und leitet diese an die Drucker weiter. Dies ermöglicht die Netzwerkdrucker zentral zu verwalten und das Spooling zu zentralisieren. Das zentralisierte Spooling ermöglicht mehreren Benutzern auch gleichzeitig dieselben Drucker zu verwenden und führt auch zu einer Entlastung der Client Rechner. Ein Druckserver erlaubt die Verteilung von Druckertreibern und ermöglicht ein Rechte– Management wie z.B. welcher Benutzer darf auf welchen Drucker wie viel Seiten in schwarz oder in Farbe drucken.
5.5.3.4 Backupserver
Auf dem betrachteten Cluster der XYZ AG läuft auch ein Backupserver, der die Speicherung von mobilen Benutzern sicherstellt. Mobile Benutzer können in der Regel nicht immer auf sichere Netzlaufwerke zurückgreifen bzw. müssen auch firmenrelevante Daten lokal speichern und sind somit einem höheren Risiko in Bezug auf Datenverlust ausgesetzt. Um dies zu kompensieren werden die Daten über ein Backup Skript regelmäßig auf den Backup Server geschrieben unter der Voraussetzung, dass die Benutzer regelmäßig ins Office kommen bzw. sich über die VPN Leitung einwählen oder falls das nicht der Fall ist, auf eine externe USB Festplatte. Die derzeitige Backup Kapazität der XYZ AG für Mobile Benutzer beträgt 6 TB.
5.6 Business Anforderungen in der XYZ AG
Das Business der XYZ AG fordert eine höhere Ausfallsicherheit im Netzwerkbereich. Defekte an z.B. einzelnen Netzwerkgeräten in einzelnen Gebäuden dürfen keine negativen Auswirkungen auf andere Gebäude haben und somit den Gesamtbetriebsablauf an diesem Hauptstandort stören. Das Business möchte weiterhin flächendeckend in allen Gebäuden Wireless Zugänge für die Konferenzräume nutzen. Zudem soll in der Zukunft das bestehende Client Betriebssystem Windows XP Professional durch Windows 7 abgelöst werden.
5.7 Anforderungen an die IT-Abteilung
Die veränderten Business Anforderungen stellen die IT-Abteilung vor neue Herausforderungen. Das Netzwerkteam der XYZ AG erarbeitete eine neue Netzwerksegmentierung aus, um die Ausfallsicherheit deutlich zu erhöhen. Konkret sollen alle Etagen in allen Gebäuden in sogenannte VLAN unterteilt werden. Diese Aufteilung soll zum einen pro Etage und zusätzlich in Client Geräte wie z.B. Drucker, Client Computer und Telefone erfolgen. Bei derzeit 5 Gebäuden mit jeweils 6 Etagen ergibt das 30 VLAN und noch mal 30 VLAN für die Telefone, also insgesamt 60 VLAN. Hier ist noch nicht die Segmentierung des RZ und des Labor betrachtet. Es muss insgesamt davon ausgegangen werden, dass insgesamt 90 VLAN am DHCP eingerichtet werden müssen. Das neue Konzept der Netzwerkabteilung lässt die Bedeutung des DHCP Services deutlich ansteigen. Normalerweise ist der DHCP Service zwar sehr wichtig, kann jedoch sehr schnell auf einen anderen Server ohne Migration übertragen werden. Ein einzelner Netzwerkbereich mit allen wichtigen Informationen wie IP-Adressraum usw. ist in ca. 5- 10 Minuten übertragen, jedoch ein DHCP Server mit über 90 IP-Bereichen und allen Reservierungen und Konfigurationen würde viele Stunden benötigen.
Weiterhin wird die Netzwerkabteilung die Konferenzräume mit Wireless Router der Marke Cisco ausstatten und auf den derzeit höchsten Sicherheitsstandard der WPA2 Verschlüsselung in Kombination mit einem Computer Zertifikat zurückgreifen. Für die IT-Infrastruktur Abteilung, die für die Betreuung der Serversysteme verantwortlich ist, wird ganz klar deutlich, dass die bestehende DHCP Cluster Lösung auf dem Windows Server 2008 nicht über ausreichende Funktionen insbesondere im Disaster-Recovery Fall verfügt. Die WPA2 Konfigurationen der Netzwerkabteilung für die Nutzung von WLAN in den Konferenzräumen kann ausschließlich über einen Windows Server 2008 R2 verteilt werden. Auch die spätere Verteilung und Lizenzierung des Client Betriebssystem Windows 7 lässt sich effizienter nur mit Windows 2008 R2 machen. Weiterhin wurden in 2008 R2 viele neue Funktionen im Cluster Bereich verbessert und im speziellen auch am DHCP Server. So können in R2 vergebene IP-Adressen einfach zu Reservierungen hinzugefügt werden, MAC Allow und MAC Deny Listen wurden hinzugefügt und die Cluster Migration bzw. Backup / Restore wurde stark verbessert. Die IT-Infrastruktur Abteilung war nach Abwägen aller Vor und Nachteile klar, dass das bestehende Windows 2008 Cluster auf Windows 2008 R2 aktualisiert werden muss, um auch den neuen Business Anforderungen gerecht zu werden.
6 Soll-Zustand der IT Services
6.1 SLA zwischen der IT-Abteilung und der Geschäftsführung
Nachdem die Geschäftsführung der XYZ AG über das Vorhaben der IT-Abteilung informiert worden ist, macht diese deutlich, dass die bestehenden IT-Services auf dem betroffenen Cluster, also DHCP, Datei- und Druckserver für höchstens 5 Minuten unterbrochen werden dürfen. Über diesen Service Level Agreement einigten sich beide Seiten. Das SLA ist derzeit jedoch definitiv nicht einhaltbar, da ein Upgrade auf ein neues Cluster inklusive der Migration der Services, diese weit mehr als 5 Minuten unterbrechen würde. Um diesen SLA doch noch gerecht zu werden müssen sich die bestehenden IT-Prozesse dementsprechend ändern bzw. müssen diese neu gestaltet werden.
6.2 Mögliche Lösungsansätze
Mögliche Lösungsansätze einer Prozessänderung, Prozessoptimierung bzw. Neugestaltung der IT-Prozesse in der XYZ AG könnten unter anderem sein, die Initialisierung eines Projekts oder das Outsourcing der Aufgabe bzw. die Heranziehung öffentlich verfügbarer Frameworks und Standards wie z.B. ITIL, COBIT und CMMI.
6.2.1 Projektansatz
Ein Projekt ist ein einmaliger Prozess, der innerhalb einer definierten Zeitspanne ein definiertes Ziel erreichen soll. Da die IT der XYZ AG nicht nur einmalig auf Business-Veränderungen reagieren muss, sollte ein Prozess etabliert werden, der gelebt werden kann und sich schnell auf Veränderungen einstellen kann. Dies ist im Rahmen eines Projekts sehr schwer umsetzbar.
6.2.2 Outsourcingansatz
Outsourcing ist die Abgabe von Unternehmenstätigkeiten an Drittunternehmen. Die Aufgabe der Prozessänderung bzw. Neugestaltung mit dem Ziel der Einhaltung des SLA und der damit anstehenden IT-Aufgaben könnte von externen Dienstleistern durchgeführt werden. Ein Outsourcing wäre generell zunächst denkbar, jedoch ist zu beachten, dass zur Bewältigung der Aufgabe viele firmeninterne Kenntnisse erforderlich wären, was sich sehr kostenintensiv auswirken würde. Zudem ist diese Aufgabe ein klarer Kernkompetenzbereich der eigenen IT Infrastruktur Abteilung und sehr bedenklich in Hinblick mit dem Umgang personbezogener und sensibler Firmendaten.
6.2.3 Öffentliche Frameworks
Öffentliche verfügbare Frameworks und Standards wurden anders als die eingeschränkten Erfahrungen einer einzelnen Organisation für unterschiedlichste Umgebungen und Situationen validiert. Sie unterliegen einer umfassenden Prüfung über mehrere Organisationen und Disziplinen hinweg. Sie wurden von unterschiedlichsten Suppliern und Wettbewerbern eingehend untersucht.[8]
6.2.3.1 COBIT
COBIT, das von der Information Systems Audit and Control Association (ISACA) erstellte und vom IT Governance Institute heraus gegebenes Framework stellt Leitlinien für Mitarbeiter in den Bereichen IT-Audit und Sicherheit bereit.[9]
6.2.3.2 CMMI
CMMI, die Capability Maturity Model Integration ist ein Ansatz zur Prozessverbesserung und kann als Richtschnur herangezogen werden. CMMI bietet Leitlinien für das Qualitätsmanagement an und stellt einen Richtwert für die Beurteilung der aktuellen Prozesse bereit.[10]
6.2.3.3 ITIL
ITIL, ist die Abkürzung für den durch die CCTA, heute OGC (Office of Governance Commerce) in Norwich (England) im Auftrage der britischen Regierung entwickelten Leitfaden IT Infrastructure Library. ITIL der weltweite De-facto-Standard im Bereich Service Management beinhaltet eine umfassende und öffentlich verfügbare fachliche Dokumentation zur Planung, Erbringung und Unterstützung von IT Serviceleistungen.[11]
7 Entscheidung und Umsetzung
7.1 Entscheidung über den Lösungsansatz in der XYZ AG
Für die XYZ AG ist es wichtig die IT-Prozesse so zu gestalten, dass unter allen Umständen das SLA mit der Geschäftführung eingehalten werden kann. Daher ist ein Projekt für diese Herausforderung nicht geeignet. Das Outsourcing kann aus Kostengründen und aus Gründen der Geheimhaltung von sensiblen Daten gegenüber Dritten nicht angewendet werden. Bei der genauen Untersuchung der öffentlichen Frameworks ist die XYZ AG zu folgendem Entschluss gekommen. COBIT richtet sich in erster Linie an Revisoren und Buchprüfer und behandelt schwerpunktmäßig, was einem Audit unterzogen und wie Audits vorgenommen werden sollten und bietet keine detaillierten Leitlinien für die Betreiber der zu überprüfenden Prozesse. Da es hier um IT-Prozesse geht, ist COBIT nicht das anzuwendende Framework. CMMI beschreibt mehr die Entwicklung von IT und Systemen und ist grundsätzlich ein Mittel die Produktentwicklung zu verbessern. Da in der XYZ AG kein klassisches Produkt hergestellt wird, sind auch die damit verbundenen Leitlinien zur Produktentwicklung nicht komplett anwendbar. ITIL ist das Framework im Bereich des Service Management und unterteilt den Service -Lebenszyklus in 5 Publikationen. Die XYZ AG ist daher zu dem Entschluss gekommen, den IT-Prozess im Rahmen des ITIL – Frameworks zu untersuchen und anzupassen, da es sich in der XYZ AG um einen wiederholenden Prozess handelt.
7.2 Service Management
„Das Servicemanagement ist die Gesamtheit der spezialisierten organisatorischen Fähigkeiten, die zur Generierung eines Mehrwerts für Kunden in Form von Services verfügbar sind. Die Fähigkeiten stehen in Form von Funktionen und Prozessen zur Verwaltung von Services im Verlauf des Lebenszyklus zur Verfügung, mit der Spezialisierung in Strategy, Design, Transition, Operation und Continual Service Improvement".[12]
7.2.1 Produktlebenszyklus nach ITIL
Der ITIL Kern umfasst fünf Publikationen. Jede der Publikationen behandelt Fähigkeiten, die sich direkt auf die Leistung eines Service Providers auswirken. Die Struktur des ITIL-Kerns entspricht einem mehrdimensionalen und sich schrittweise wiederholenden Lebenszyklus.[13]
7.2.1.1 Service Strategy (Servicestrategie)
Um langfristig erfolgreich zu agieren und zu wachsen, müssen Service Provider in der Lage sein, strategisch zu denken und zu handeln. Zweck der Servicestrategie ist es, Organisationen bei der Entwicklung solcher Fähigkeiten zu unterstützen. Mit dieser Leitlinie sollen Fragen beantwortet werden wie: Welche Services sollen wir anbieten, und an wen sollten wir unser Angebot richten? Wie schaffen wir eine Abgrenzung gegenüber den Mitbewerbern?
Dazu konzentriert sich die Servicestrategie auf das Design, Entwicklung und Implementierung des Service Management, nicht nur als organisatorische Fähigkeit sondern auch als strategisches Asset. Wichtige Themen der Servicestrategie sind unter anderem die Entwicklung von internen und externen Märkten, Service-Assets, den Servicekatalog sowie die Implementierung der Strategie. Weitere Themen sind das Financial Management, das Service Portfolio, die organisatorische Entwicklung und strategische Risiken. Organisationen nutzen diese Leitlinien, um Ziele und Erwartungen in Bezug auf die Performance bei der Servicebereitstellung für die Kunden auswählen und entsprechend priorisieren zu können.
Entscheidungen zur Service Strategy führen zu weit reichenden Konsequenzen, die unter Umständen auch erst mit einer gewissen Verzögerung eintreten können. Organisationen, die bereits nach ITIL arbeiten, können anhand der Servicestrategie einen strategischen Review ihrer ITIL-basierten Service Management Fähigkeiten durchführen und die Abstimmung zwischen diesen Fähigkeiten und ihren Business-Strategien verbessern. Dieser Leitfaden richtet sich vor allem an IT-Organisationen, die ihre Fähigkeiten im Bereich des Service Management entwickeln möchten, um sich als wertvoller Service Provider zu positionieren.[15]
7.2.1.2 Service Design
Der Band Service Design stellt Leitlinien zur Verwendung der empfohlenen Praxis beim Design von IT-Services und IT Service Management Prozessen bereit. Sie umfasst Design-Grundsätze und –Methoden, mit denen strategische Ziele in Service-Portfolios und Service–Assets umgesetzt werden können. Das Service Design ist wichtig, um die Phase der Servicebereitstellung für das Business effektiv festzulegen und dem Bedarf an Wachstum und Veränderung gerecht zu werden. In der Regel können Verbesserungen eher bei den Kosten und Ressourcen als in der Entwicklung erreicht werden. Daher sollte der Schwerpunkt auf dem Design eines einfachen und wirtschaftlichen Support-Systems liegen, da es nicht möglich ist einen Service komplett neu zu gestalten, sobald dieser produktiv eingesetzt wird. Eine Umgestaltung eines Designs ist schwierig und sehr kostenintensiv und erreich in keinem Fall das Ergebnis, das durch ein erstes geeignetes Design hätte erzielt werden können. Dieser Band ist für alle Personen relevant, die am Design, an der Bereitstellung und am Support von IT-Services beteiligt sind. Dazu gehören unter anderem IT-Architekten, IT-Manager und praktische Anwender aller Ebenen.[16]
7.2.1.3 Transition (Serviceüberführung)
Zielsetzung der Serviceüberführung ist es, Organisationen bei der Planung und dem Management von Serviceänderungen und bei der erfolgreichen Überführung dieser in die Produktionsumgebung zu unterstützen. Durch diese Publikation soll sichergestellt werden, dass die Anforderungen aus der Service Strategy, die in das Service Design eingebracht wurden, effektiv in der Service Operation bei steuerbaren Risiken für Ausfälle und Unterbrechungen umgesetzt werden. Es werden Praktiken aus Release Management, Programm Management und Risk Management kombiniert und diese in einen praktikablen Kontext zu Service Management gestellt. Zudem werden Hilfestellungen geboten, um die Kontrolle über die Services zwischen Kunde und Service Provider zu übertragen. Unternehmen erzielen bei der Übernahme der Best Practices einen hohen Nutzen wie z.B. exaktere Abschätzung von Kosten, Zeit, Ressourcenanforderungen und Risiken in Projekten. Die Zielgruppe der Serviceüberführung ist zum einen für alle Organisationen relevant, die an der Entwicklung, Bereitstellung oder am Support von Services beteilt sind, wie z.B. interne als auch externe Service Provider. Zum anderen ist Sie aber auch für IT Service Manager und alle an der Service Transition beteiligten Personen relevant wie z.B. Qualitätssicherungs-Manager, Mitarbeiter des Change Management oder auch Release und Deployment Management.[17]
7.2.1.4 Continual Service Improvement (kontinuierliche Serviceverbesserung)
Der Band Continual Service Improvement stellt instrumentalisierte Anleitungen für Generierung und Erhalt von Kundenmehrwert in Form von Verbesserungen im Design, in der Einführung und dem Betrieb von Services zur Verfügung. Es soll eine praktische Anleitung für die Evaluierung und Verbesserung der Qualität von Services, der gesamte Reife des ITSM-Servicelebenszyklus und der zugrunde liegenden Prozesse auf drei Ebenen innerhalb der Organisation bieten. Die erste Ebene bildet den allgemeinen Zustand des ITSM als Disziplin, die zweite Ebene steht für die kontinuierliche Abstimmung des Portfolios von IT-Services mit den derzeitigen und zukünftigen Business Bedürfnissen. Die dritte Ebene stellt den für die Reife der IT-Prozesse, die für die Unterstützung der Business-Prozesse in einem kontinuierlichen Servicelebenszyklusmodell erforderlich sind und diesen erst möglich machen dar. Die kontinuierliche Serviceverbesserung umfasst Leitlinien für die Verknüpfung von Verbesserungsanstrengungen und –ergebnissen mit der Service Strategy, dem Service Design und der Service Transition. Es wird ein geschlossener Feedback-Kreislauf erstellt, der auf dem im Standard ISO/IEC 20000 angegebenen Modell „Plan-Do-Check-Act“ (Planen-Durchführen-Überprüfen-Handeln, PDCA) basiert. Diese Publikation richtet sich an alle IT-Mitarbeiter, die am Management von Services im gesamten Lebenszyklus beteiligt sind.[18]
7.2.1.5 Service Operation (Servicebetrieb)
Die Service Operation ist eine entscheidende Phase im ITSM-Lebenszyklus. Sorgfältig geplante und implementierte Prozesse würden keinen Nutzen erzeugen, wenn der tägliche Betrieb dieser Prozesse nicht korrekt durchgeführt, gesteuert und verwaltet wird. Ebenso wenig sind Serviceverbesserungen möglich, wenn die täglichen Aktivitäten zur Überwachung der Performance, Bewertung von Messgrößen und Sammlung von Daten während der Service Operation nicht systematisch durchgeführt werden. Die strategische Zielerreichung erfolgt letztendlich im Servicebetrieb, der damit zu entscheidenden Fähigkeit wird. Es werden Leitlinien bereitgestellt, um die Beibehaltung der Stabilität im Servicebetrieb zu gewährleisten, so dass Änderungen im Design, in der Größenordnung, im Umfang und in den Service Levels umgesetzt werden können. Alle Funktionen, Aktivitäten und Prozesse sind so konzipiert, dass sich auf eine kontinuierlich verändernde Umgebung einstellen und spezifische und vereinbarte Level der Services bereitstellen. Dies führt zu einem Konflikt, einerseits soll der Status quo gewahrt werden, andererseits sind Anpassungen an die veränderten Business- und technologischen Umgebungen notwendig. Die Service Operation beschäftigt sich daher eingehend mit dem Umgang des Konflikts und der Schaffung eines Gleichgewichts zwischen Gegensätzen. Der Servicebetrieb betrachtet die folgenden vier typischen Konflikte:
7.2.1.5.1 Interne IT Sicht versus externe Kundensicht
Für die Bereitstellung von Services sind beiden Sichten erforderlich, Organisationen, die nur auf die Business Anforderungen konzentrieren, ohne darüber nachzudenken, wie die Services bereitgestellt werden können, machen Zusagen, die sie letztendlich nicht einhalten können. Organisationen, die sich dagegen nur auf die internen Systeme konzentrieren, ohne darüber nachzudenken, welche Services sie unterstützen, stellen letztendlich Services zu hohen Kosten und geringen Mehrwert bereit. Nur eine ausgewogene Betrachtung beider Sichten erlaubt eine optimale und verlässliche Services, welche sowohl die Bedürfnisse der Kunden als auch die Machbarkeit auf Basis der Fähigkeiten der IT Organisation abdecken.[19]
7.2.1.5.2 Stabilität versus Reaktionsfähigkeit
Egal wie gut Funktionalität und Design eines IT Service sind, wenn die Servicekomponenten nicht verfügbar sind oder inkonsistente Leistung erbringen, ist der Service nur noch halb so gut. Dem Servicebetrieb muss bewusst sein, dass die Business –und IT-Anforderungen Änderungen unterworfen sind. Viele Änderungen passieren allerdings sehr schnell und manchmal unter enormen Druck. Wie bei unserer XYZ AG, wo durch die Geschäftsführung festgelegt wurde, dass die bestehenden IT- Services auf dem Cluster für maximal 5 Minuten unterbrochen werden dürfen. Die Fähigkeit, auf diese Art von Änderungen zu reagieren, ohne andere Services zu beeinträchtigen, ist eine große Herausforderung. Die Stabilität zu gewährleisten und gleichzeitig Änderungen rechtzeitig umzusetzen, ist angemessen unter Würdigung der Risiken abzuwägen.[21]
7.2.1.5.3 Servicequalität versus Servicekosten
Eine Schlüsselrolle im Service Management besteht darin, ein Gleichgewicht zwischen Kosten und Qualität zu finden. Es ist wichtig das richtige Gleichgewicht zu finden. Wenn der Schwerpunkt zu stark auf der Qualität liegt, bieten die IT-Services mehr als nötig und verursachen höhere Kosten. Liegt der Schwerpunkt zu sehr auf den Kosten, gelingt der IT die Einhaltung das Budget läuft aber in die Gefahr dem Business qualitativ minderwertige Services anzubieten. Mit Service Level Anforderungen und einem genauen Verständnis für den Business-Zweck eines Service und für potentielle Risiken –kann sichergestellt werden, dass der Service zu angemessenen Kosten bereitgestellt wird. [22]
7.2.1.5.4 Reaktives Verhalten versus proaktivem Verhalten
Reaktive Organisationen handeln erst dann, wenn sie durch externe Motivation dazu veranlasst werden. Zum Beispiel durch eine neue Business Anforderung oder einer Eskalation der Beschwerden von Kunden und Anwendern. Wenn Organisationen reaktiv arbeiten, weil sie fälschlicherweise davon ausgehen, dass dies die einzige Möglichkeit ist, stabile Services anzubieten, wird damit aktiv ein proaktives Verhalten der Mitarbeiter verhindert. Eine proaktive Organisation ist ständig auf der Suche nach Möglichkeiten, die Situation irgendwie zu verbessern. Ein proaktives Verhalten gilt als positiv, da sich die Organisation in sich ständig verändernden Umgebung einen Wettbewerbsvorteil verschaffen kann. Jedoch ist ein übermäßig proaktives Verhalten auch sehr teuer und kann dazu führen, dass die Mitarbeiter vom wesentlichen abgelenkt werden. Ein optimales Ergebnis wird erreicht, wenn ein Gleichgewicht zwischen reaktivem und proaktivem Verhalten gefunden wird.[24]
7.3 Upgrade des Clusters entsprechend ITIL – Service Operation
Die XYZ AG wird die zu erfüllende Anpassung des IT-Prozesses, hier speziell für das Upgrade des Clusters, unter Berücksichtigung des ITIL Frameworks in der Version 3 mit dem Schwerpunkt an die Service Operation durchführen. Die Struktur der XYZ AG ist nach technischer Spezialisierung organisiert. Es werden Abteilungen entsprechend der Technologie, sowie der Fähigkeiten und Aktivitäten erstellt, die für das Management dieser Technologie erforderlich sind. Dies ist vorteilhaft für die XYZ AG, da die einzelnen Gruppen direkt am Service Design, an der Testphase und and den Verbesserungsprozessen beteiligt sind. Das stellt sicher, dass die Planung auf die Anforderungen des Business abgestimmt sind. Die IT-Infrastruktur Abteilung muss sicherstellen, dass die Services auf dem Cluster, hier DHCP Server (mit Servername: Erde), Dateiserver (Saturn) und der Druckserver (Jupiter) während des Upgrades auf Windows 2008 Server R2 entsprechend der SLA nicht länger als 5 Minuten unterbrochen werden. Der Auslöser für diesen Change an der Service Operation ist eine aktualisierte Systemsoftware, hier Windows 2008 Server R2. An diesem Change sind alle Service Operation Mitarbeiter rechtzeitig beteiligt gewesen, um sicherzustellen, dass alle operativen Schwierigkeiten beachtet werden. Diese Einbeziehung fand in der XYZ AG direkt nach der Vereinbarung des SLA zwischen der Geschäftsführung und der IT-Abteilung statt. Um die typischen Konflikte im Servicebetrieb der XYZ AG zu vermeiden, wurde eine Balance zwischen der internen und externen IT Sicht vorgenommen. In der XYZ AG wurde eine technologische Lösung vorgeschlagen, die aus interner IT Sicht für umsetzbar erklärt wurde. Das Cluster soll auf eine neue Version aktualisiert werden. Die externe Sicht wurde ebenfalls ausführlich im vorherigen Kapitel betrachtet, wo die neuen Business Anforderungen genau beschrieben wurden z.B. Rollout eines neuen Client Betriebssystem Windows 7 und die Verteilung der WPA 2 Konfiguration. Um auch den ITIL Aspekt Stabilität versus Reaktionsfähigkeit ausreichend Beachtung zu kommen zu lassen, ist die IT-Abteilung nach zahlreichen Diskussionen zu dem Entschluss gekommen, nicht ein neues Cluster parallel aufzubauen und die Services zu migrieren, sondern es einzelnen zu aktualisieren und mit Hilfe zusätzlicher Imagetechnologie. Nur so wird einerseits der Reaktionsfähigkeit der IT genüge getan, aber auch andererseits die Komplexität verringert und damit auch die Fehlerquote vermindert. Ein Single Step-by Step Upgrade bietet den Vorteil, dass sämtliche LUN´s an den Storage Systemen gleich bleibt, sowie die Zonen Konfigurationen an den Fibre Channel Switchen. Diese Entscheidung beachtet ebenso die Servicequalität und die Service Kosten, denn ein parallel Cluster wäre sehr kostenintensiv, da auch die Mehrstunden der Mitarbeiter hinzugezählt werden müssen. Die Servicequalität würde bei einem zusätzlichen Cluster nicht erhöht werden, lediglich die Ausfallsicherheit, die jedoch bei einem bestehenden Cluster sowie schon sehr hoch ist. Die neue Business Anforderung stellt klar einen reaktiven Charakter dar, jedoch hat sich die IT Abteilung schon längere Zeit mit den neuen Funktionen des Serverbetriebssystem Windows 2008 R2 auseinander gesetzt und konnte so den Business relativ schnell Möglichkeiten aufzeigen, die neuen Anforderungen schnell und effektiv umzusetzen.
7.4 technischer Ablauf des Clusterupgrade nach ITIL – Service Operation
7.4.1 Ausgangszustand
Das zu aktualisierende Windows Cluster der XYZ AG besteht aus zwei physischen Windows 2008 Server x64bit in der Enterprise Edition installiert auf zwei HP BL460c G1 Blades. Über beide physischen Knoten werden derzeit 3 virtuelle Server bereitgestellt. Der Server mit dem Namen Erde, als virtueller DHCP Server, Saturn als virtueller Dateiserver und Jupiter als virtueller Druckserver. Die Infrastruktur Abteilung der XYZ AG verschiebt zunächst an einem Sonnabend um exakt 23.00 Uhr in Absprache mit dem Helpdesk und dem Event-Monitoring Team die erste virtuelle Instanz / Ressource Erde vom physischen Cluster Node 1 mit dem Namen Merkur auf den zweiten Cluster Node mit dem Namen Venus. Die Unterbrechung des Service Erde betrug exakt 1 Minute. Danach folgten die beiden anderen Ressourcen Saturn und Jupiter. Auch diese beiden Unterbrechungen betrugen jeweils weniger als 1 Minute.
7.4.2 Ressourcen werden auf Cluster Node 2 migriert
Nachdem nun alle Ressourcen auf den Cluster Node 2 verschoben wurden, konnte die IT-Infrastruktur Gruppe den Cluster Node 1 herunterfahren und ein Image des Knoten erstellen. Dieses Image dient im Notfall für eine sehr schnelle Wiederherstellung des Ausgangscluster. Alternativ kann hier auch, sofern das Betriebssystem sich auf einem RAID 1+0 befindet auch einfach eine Festplatte als Backup herausgezogen werden.
7.4.3 Cluster Node 1 wird aus dem bestehenden Cluster entfernt
Nachdem nun ein Backup erstellt wurden ist, muss der Cluster Node 1 erneut hochgefahren werden, um diesen aus der Clusterkonfiguration mit dem Namen Neptun zu entfernen. Ab diesem Zeitpunkt besteht das Cluster Neptun nur noch aus einem Knoten und kann kein Failover mehr auf den anderen Node machen. Bei einem jetzigen Hardwareausfall des Cluster Node 2, wäre keiner der virtuellen Ressourcen mehr verfügbar! Der Server verhält sich nun wie ein Stand Alone Server und je nach Anzahl und Belastung des Servers kann sich dies unter Umständen auch negativ auf die Performance auswirken. Auch aus diesem Grund wurde die Arbeit an einem Sonnabend durchgeführt. Nun kann der Cluster Node 1 mit dem neuen Serverbetriebsystem Windows Server 2008 R2 installiert werden. In der XYZ AG wurde damit gegen 00.45 Uhr begonnen.
7.4.4 Cluster Node 1 wird auf 2008 R2 aktualisiert und neues Cluster erstellt
Nach 2 Stunden, also gegen 02.45 Uhr war die Installation und die Grundkonfiguration des neuen Serverbetriebssystem auf dem Cluster Node 1 erledigt. Es folgte die Installation aller derzeit verfügbaren Updates sowie aller hardware-spezifischen Treiber. Als weiterer Schritt wurden die Cluster spezifischen Features installiert, wie Multipath I/O und Failover Clustering. Multipath I/O verwaltet mehre Pfade zu den gleichen logischen Festplatten. Zudem wurden die entsprechenden Roles wie DHCP, File Services und Print and Document Services installiert.Gegen 03.30 Uhr wurde auf dem Cluster Node 1 ein neues Cluster mit dem Namen Uranus erstellt. Bei der Quorum Konfiguration wurde die Option Node and Disk Majority gewählt.
7.4.5 Migration der virtuellen Instanzen auf Cluster Node 1
Um 04.00 Uhr morgens konnte mit den Vorbereitungen der Migration des virtuellen DHCP Server Erde begonnen werden. Achtung: spezielle Services wie DHCP bedingen einige Konfigurationen im Vorfeld und können nicht direkt über den Migration Wizard migriert werden. Siehe dazu im Anhang die Anleitung von Microsoft. Hinweis: Der Migration Wizard sollte einmal pro virtuelle Ressource bei der Migration von einem Cluster zum anderen verwendet werden, um sicher zu stellen, dass pro Service alle vorher notwendigen Konfigurationen erledigt sind. Für die XYZ AG musste auf dem laufen Cluster Node ein Registry Eintrag hinzugefügt werden und die DHCP Datenbank auf Venus exportiert und auf Merkur importiert werden. Hinweis: Sobald der Export am laufen DHCP gestartet wird, wird automatisch der DHCP Dienst herunterfahren! Um auch hier den SLA einzuhalten wurde der Export auf ein Laufwerk geschrieben, auf den auch der Cluster Node 1 direkt zugreifen konnte. Am Cluster Node 1 wurde der Befehl zum Import bereits hinterlegt. Nun wurde am Cluster Node 2 der Export der Datenbank gestartet, dies führte zum herunterfahren der Ressource. Der Export dauerte 2 Minuten und sofort wurde der Import am Cluster Node 1 gestartet. Der Import dauerte nur 1,5 Minuten und die Ressource war nach genau 3,5 Minuten wieder online mit dem gleichen Servernamen und derselben IP Adresse. Der Dateiserver Saturn konnte komplett mit dem Migration Wizard migriert werden, Zeitdauer: 3 Minuten. Der Druckserver wurde parallel installiert, mit einer temporär anderen IP Adresse und unter anderen Namen. Nachdem alle 150 Drucker manuell mit den entsprechenden Treibern installiert wurden, konnte die Ressource herunter gefahren und der Servername auf Erde geändert und die richtige IP-Adresse hinterlegt werden. Als weiter Schritt wurde der nun noch laufende Druckserver Erde auf dem Cluster Node 2 heruntergefahren. Nachdem dieser offline war, wurde der neu vorbereitete Erde Server auf dem Cluster Node 1 hochgefahren. Die Ausfallzeit betrug 2 Minuten.
7.4.6 Das alte Cluster wird auf Cluster Node 2 zerstört
Um 06.30 Uhr liefen alle virtuellen Server auf dem neuen Cluster Node 1. Nun wurde ein Backup des Cluster 2 in Form von herausnehmen beider Festplatten im Raid 1+0. Dies sollte sicherstellen, dass im Fehlerfall des Cluster Node 1, das alte Cluster schnell wieder hochgefahren werden konnte. Dann wurde das Cluster Node 2 mit zwei neuen Festplatten versehen und mit Windows Server 2008 R2 installiert.
7.4.7 Cluster Node 2 wird in das neue Cluster aufgenommen
Um 09.00 Uhr sonntags früh war der Cluster Node 2 mit Windows Server 2008 R2 installiert, sowohl mit allen Treibern und derzeit verfügbaren Updates. Wichtig: Es wird empfohlen möglichst beide Cluster Nodes mit identischen Treiberversionen, Konfigurationen und Updates zu versehen. Nachdem der Cluster Node 2 identisch mit dem Cluster Node 1 war, wurde dieser dem bestehenden Cluster mit dem Namen Uranus hinzugefügt.
7.4.8 Zielzustand
Nachdem der Cluster Node 2 dem Uranus Cluster hinzugefügt wurde, war das Cluster wieder vollständig und alle virtuellen Ressourcen können nun wieder sowohl auf dem Cluster Node Merkur, als auch auf dem Cluster Node Venus laufen. Die Zielkonfiguration wurde damit erfolgreich erreicht.
8 Schlussbetrachtung
8.1 Fazit
Die IT in der XYZ AG erhielt überraschend eine neue Anforderung durch das Business. Die Fähigkeit auf diese Art von Änderungen zu reagieren, ohne andere Services zu beeinträchtigen, stellt eine große Herausforderung dar. Die XYZ AG hat diese Herausforderung angenommen und hat unter Beweis gestellt, dass jede Änderung auch die Chance beinhaltet dem Business ein höheres Servicelevel bereitzustellen. Ein Erfolg der vorgenommen Veränderung an der Service Operation kann erst dann festgestellt werden, wenn Kunden und der Anwender keine Schwankung und keinen Ausfall des Services feststellen. In der XYZ AG wurde die Änderung deshalb an einem Wochenende abends durchgeführt, da zu dieser Zeit ausschließlich mit Benutzern aus anderen Zeitzonen zu rechnen war. Die IT-Abteilung konnte erfolgreich den vereinbarten Service Level Agreement von einer maximalen Ausfallzeit der betroffenen Services von 5 Minuten einhalten. Zudem konnte die XYZ AG durch Zuhilfenahme des öffentlichen Frameworks ITIL im Hinblick auf die Service Operation Ihren IT-Prozess neu gestalten und mögliche Risiken im Vorfeld ausschließen. Mit anderen Worten waren die Folgen des Clusterupgrades kaum erkennbar und zudem wurden die IT-Funktionalitäten deutlich verbessert. Die IT konnte die Lösung kostengünstig durchführen und ist nun in der Lage, die neuen Anforderungen dem Business zur Verfügung zu stellen. Dies führte zu einem Mehrwert für das Business und sicherte zudem die Stellung der IT als professionellen Service Provider.
9 Literaturverzeichnis
9.1 Fußnoten
- ↑ Vgl. IT Wissen, URL siehe Quellenverweis
- ↑ Vgl. Lampertz, URL siehe Quellenverweis
- ↑ Vgl. Wagner, URL siehe Quellenverweis
- ↑ Vgl. Lampertz, URL siehe Quellenverweis
- ↑ Vgl. Elko, URL siehe Quellenverweis
- ↑ Vgl. Wagner, URL siehe Quellenverweis
- ↑ Vgl. IT Wissen, URL siehe Quellenverzeichnis
- ↑ Vgl. OGC (2007), ITIL Service Operation S.4, S.5
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 207
- ↑ Vgl. ITIL, URL siehe Quellenverweis
- ↑ Vgl. OGC (2007), ITIL Service Operation S4, S5
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 13
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 5
- ↑ Abbildung 6 von OGC (2007), ITIL Service Operation S. 6
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 7 und OGC (2007), ITIL Service Strategy S. 11
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 5 und Vgl. OGC (2008), ITIL Service Design S.9
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 7 und OGC (2007), ITIL Service Transition S.8, S.9
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 7-9
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 24-26
- ↑ Abbildung 7 von OGC (2007), ITIL Service Operation S. 24
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 27
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 27-30
- ↑ Abbildung 8 von OGC (2007), ITIL Service Operation S. 29
- ↑ Vgl. OGC (2007), ITIL Service Operation S. 31-32
- ↑ Abbildung 9 von OGC (2007), ITIL Service Operation S. 32
- ↑ Abbildung 10 von OGC (2007), ITIL Service Operation S. 167
9.2 Literaturquellen
OGC (2008), ITIL Continual Service Improvement, The Stationary Office
OGC (2008), ITIL Service Design, The Stationary Office
OGC (2007), ITIL Service Strategy, The Stationary Office
OGC (2007), ITIL Service Operation, The Stationary Office
OGC (2007), ITIL Service Transition, The Stationary Office
9.3 Quellenverweis
ITIL, http://www.itil.org/de/vomkennen/itil/serviceoperation/balanceserviceoperation.php, Stand 27.02.2010
ITIL, http://www.itil.org/de/vomkennen/itil/ueberblick/index.php, Stand 27.02.2010
ITSMF, http://www.itsmf.de/itsm_itil.html, Stand 20.02.2010
LAMPERTZ, http://www.lampertz.de/html/default.asp?site=1_4&lang=de, Stand 18.02.2010
WAGNER, http://www.wagner.de/brandvermeidung/uebersicht-oxyreduct/index.html, Stand 27.02.2010
WAGNER, http://www.wagner.de/brandvermeidung/funktionsprinzip/index.html, Stand 27.02.2010
MICROSOFT, http://technet.microsoft.com/en-us/library/ee460952(WS.10).aspx, Stand 26.02.2010
ITWissen, http://www.itwissen.info/definition/lexikon/Rechenzentrum-computer-centre-RZ.html, Stand 27.02.2010
ITWissen, http://www.itwissen.info/definition/lexikon/Cluster-cluster.html, Stand 27.02.2010
ELKO, http://www.elektronik-kompendium.de/sites/grd/0812171.htm, Stand 27.02.2010
9.4 Anhang
9.4.1 Migrating DHCP to a Cluster Running Windows Server 2008 R2 Step-by-Step Guide
Veröffentlicht: September 2009
Letzte Aktualisierung: September 2009
Betrifft: Windows Server 2008 R2
A failover cluster is a group of independent computers that work together to increase the availability of applications and services. The clustered servers (called nodes) are connected by physical cables and by software. If one of the cluster nodes fails, another node begins to provide service (a process known as failover). Users experience a minimum of disruptions in service. This guide describes the process of migrating a clustered DHCP server to a cluster running Windows Server® 2008 R2. Specific steps are required when migrating a clustered DHCP server to Windows Server 2008 R2 from any of the following operating systems: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008
This guide describes the steps that are necessary when migrating a clustered DHCP server to a cluster running Windows Server 2008 R2, beyond the standard steps required for migrating clustered services and applications in general. The guide indicates when to use the Migrate a Cluster Wizard in the migration, but does not describe the wizard in detail. For more information about the Migrate a Cluster Wizard, see Understanding the Process of Migrating to a Cluster Running Windows Server 2008 R2 http://go.microsoft.com/fwlink/?LinkId=161333
Hinweis If you are migrating from a cluster running Windows Server 2008 R2 to another cluster running Windows Server 2008 R2, the steps in this guide, other than running the Migrate a Cluster Wizard, are not necessary.
In this guide Step 1: Review requirements and create a cluster running Windows Server 2008 R2 Step 2: On the old cluster, adjust registry settings and permissions before migration Step 3: On a node in the old cluster, prepare for export and then export the DHCP database to a file Step 4: On the new cluster, configure a network for DHCP clients and run the Migrate a Cluster Wizard Step 5: On the new cluster, import the DHCP database, bring the clustered DHCP server online, and adjust permissions
Step 1: Review requirements and create a cluster running Windows Server 2008 R2 Before beginning the migration described in this guide, review the requirements for a cluster running Windows Server 2008 R2, install the failover clustering feature on servers running Windows Server 2008 R2, and create a new cluster. These steps are described in Checklist: Create a Failover Cluster (http://go.microsoft.com/fwlink/?LinkId=161334).
We recommend that you also review the migration information in Understanding the Process of Migrating to a Cluster Running Windows Server 2008 R2(http://go.microsoft.com/fwlink/?LinkId=161333).
Step 2: On the old cluster, adjust registry settings and permissions before migration To prepare for migration, you must make changes to registry settings and permissions on each node of the old cluster.
To adjust registry settings and permissions before migration Confirm that you have a current backup of the old cluster, one that includes the configuration information for the clustered DHCP server (also called the DHCP resource group).
Confirm that the clustered DHCP server is online on the old cluster. It must be online while you complete the remainder of this procedure.
On a node of the old cluster, open a command prompt as an administrator.
Type:
regedit
Vorsicht Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DHCPServer\Parameters
Choose the option that applies to your cluster:
If the old cluster is running Windows Server 2008, skip to step 7.
If the old cluster is running Windows Server 2003 or Windows Server 2003 R2:
Right-click Parameters, click New, click String Value, and for the name of the new value, type:
ServiceMain
Right-click the new value (ServiceMain), click Modify, and for the value data, type:
ServiceEntry
Right-click Parameters again, click New, click Expandable String Value, and for the name of the new value, type:
ServiceDll
Right-click the new value (ServiceDll), click Modify, and for the value data, type:
%systemroot%\system32\dhcpssvc.dll
Right-click Parameters, and then click Permissions.
Click Add.
Locate the appropriate account and assign permissions:
On Windows Server 2008: Click Locations, select the local server, and then click OK. Under Enter the object names to select, type NT Service\DHCPServer. Click OK. Select the DHCPServer account and then select the check box for Full Control.
On Windows Server 2003 or Windows Server 2003 R2: Click Locations, ensure that the domain name is selected, and then click OK. Under Enter the object names to select, type Everyone, and then click OK (and confirm your choice if prompted). Under Group or user names, select Everyone and then select the check box for Full Control.
Wichtig The step of adding permissions for Everyone is a temporary measure. After performing this step, be sure to follow the remaining steps in this guide, specifically the last step, in which you remove the permissions for Everyone when they are no longer needed. This ensures that after migration is complete, the permissions are limited to the correct account.
Repeat the process on the other node or nodes of the old cluster.
Step 3: On a node in the old cluster, prepare for export, and then export the DHCP database to a file As part of migrating a clustered DHCP server, on the old cluster, you must export the DHCP database to a file. This requires preparatory steps that prevent the cluster from restarting the clustered DHCP resource during the export. The following procedure describes the process.
To prepare for export and then export the DHCP database to a file On the old cluster, start the clustering snap-in and configure the restart setting for the clustered DHCP server (DHCP resource group):
If the cluster is running on Windows Server 2003 or Windows Server 2003 R2:
Click Start, click Control Panel, double-click Administrative Tools, and then double-click Cluster Administrator.
In the console tree, click the Resources folder, and in the details pane, click the DHCP resource.
On the File menu, click Properties, click the Advanced tab, and then click Do not restart.
If the cluster is running on Windows Server 2008:
Click Start, click Administrative Tools, and then click Failover Cluster Management. Wenn das Dialogfeld Benutzerkontensteuerung eingeblendet wird, bestätigen Sie die angegebene Aktion und klicken dann auf Weiter.
If the console tree is collapsed, expand the tree under the cluster that you are migrating settings from. Expand Services and Applications and then, in the console tree, click the clustered DHCP server.
In the center pane, right-click the DHCP server resource, click Properties, click the Policies tab, and then click If resource fails, do not restart.
This step prevents the resource from restarting during the export of the DHCP database, which would stop the export. On the node of the old cluster that currently owns the clustered DHCP server, confirm that the clustered DHCP server is running. Then open a command prompt window as an administrator.
Type:
netsh dhcp server export <exportfile> all
Where <exportfile> is the name of the file to which you want to export the DHCP database.
The export causes DHCP to stop running, and as a result, in the clustering interface, the DHCP server resource may be marked as failed. If this occurs, do not be concerned.
After the export is complete, in the clustering interface (Cluster Administrator or Failover Cluster Management), right-click the clustered DHCP server (DHCP resource group) and then click either Take Offline or Take this service or application offline. If the command is unavailable, in the center pane, right-click each online resource and click either Take Offline or Take this resource offline. If prompted for confirmation, confirm your choice.
If the old cluster is running Windows Server 2003 or Windows Server 2003 R2, obtain the account name and password for the Cluster service account (the Active Directory account used by the Cluster service on the old cluster). Alternatively, you can obtain the name and password of another account that has access permissions for the Active Directory computer accounts (objects) that the old cluster uses. For a migration from a cluster running Windows Server 2003 or Windows Server 2003 R2, you will need this information for the next procedure.
Step 4: On the new cluster, configure a network for DHCP clients and run the Migrate a Cluster Wizard We recommend that you make the network settings on the new cluster as similar as possible to the settings on the old cluster. In any case, on the new cluster, you must have at least one network that DHCP clients can use to communicate with the cluster. The following procedure describes the cluster setting needed on the client network, and indicates when to run the Migrate a Cluster Wizard.
To configure a network for DHCP clients and run the Migrate a Cluster Wizard On the new cluster (running Windows Server 2008 R2), click Start, click Administrative Tools, and then click Failover Cluster Manager. Wenn das Dialogfeld Benutzerkontensteuerung eingeblendet wird, bestätigen Sie die angegebene Aktion und klicken dann auf Weiter.
If the cluster that you want to configure is not displayed, in the console tree, right-click Failover Cluster Manager, click Manage a Cluster, and then select or specify the cluster that you want.
If the console tree is collapsed, expand the tree under the cluster.
Expand Networks, right-click the network that clients will use to connect to the DHCP server, and then click Properties.
Make sure that Allow cluster network communication on this network and Allow clients to connect through this network are selected.
To prepare for the migration process, find and take note of the drive letter used for the DHCP database on the old cluster. Ensure that the same drive letter exists on the new cluster. (This drive letter is one of the settings that the Migrate a Cluster Wizard will migrate.)
In Failover Cluster Manager, in the console tree, select the new cluster, and then under Configure, click Migrate services and applications.
Use the Migrate a Cluster Wizard to migrate the DHCP resource group from old to the new cluster. If you are using new storage on the new cluster, during the migration, be sure to specify the disk that has the same drive letter on the new cluster as was used for the DHCP database on the old cluster.
The wizard will migrate resources and settings, but not the DHCP database.
For more information about the Migrate a Cluster Wizard, see Migrate Resource Groups to a Failover Cluster Running Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?LinkId=161335).
Step 5: On the new cluster, import the DHCP database, bring the clustered DHCP server online, and adjust permissions To complete the migration process, import the DHCP database that you exported to a file in Step 2. Then you can bring the clustered DHCP server online and adjust settings that were changed temporarily during the migration process.
To import the DHCP database, bring the clustered DHCP server online, and adjust permissions If you are reusing the old cluster storage for the new cluster, confirm that you have stored the exported DHCP database file in a safe location. Then be sure to delete all the DHCP files other than the exported DHCP database file from the old storage. This includes the DHCP database, log, and backup files.
On the new cluster, in Failover Cluster Manager, expand Services and Applications, right-click the clustered DHCP server, and then click Bring this service or application online.
The DHCP service starts with an empty database.
Click the clustered DHCP server.
In the center pane, right-click the DHCP server resource, click Properties, click the Policies tab, and then click If resource fails, do not restart.
This step prevents the resource from restarting during the import of the DHCP database, which would stop the import.
In the new cluster, on the node that currently owns the migrated DHCP server, view the disk used by the migrated DHCP server, and make sure that you have copied the exported DHCP database file to this disk.
In the new cluster, on the node that currently owns the migrated DHCP server, open a command prompt as an administrator. Change to the disk used by the migrated DHCP server.
Type:
netsh dhcp server import <exportfile>
Where <exportfile> is the filename of the file to which you exported the DHCP database.
The import causes DHCP to stop running, and as a result, in the clustering interface, the DHCP server resource may be marked as failed. If this occurs, do not be concerned.
If the migrated DHCP server is not online, in Failover Cluster Manager, under Services and Applications, right-click the migrated DHCP server, and then click Bring this service or application online.
In the center pane, right-click the DHCP server resource, click Properties, click the Policies tab, and then click If resource fails, attempt restart on current node.
This returns the resource to the expected setting, instead of the "do not restart" setting that was temporarily needed during the import of the DHCP database.
If the cluster was migrated from Windows Server 2003 or Windows Server 2003 R2, after the clustered DHCP server is online on the new cluster, make the following changes to permissions in the registry:
On the node that owns the clustered DHCP server, open a command prompt as an administrator.
Type:
regedit
Vorsicht Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DHCPServer\Parameters
Right-click Parameters, and then click Permissions.
Click Add, click Locations, and then select the local server.
Under Enter the object names to select, type NT Service\DHCPServer and then click OK. Select the DHCPServer account and then select the check box for Full Control. Then click Apply.
Select the Everyone account (created through steps earlier in this topic) and then click Remove. This removes the account from the list of those that are assigned permissions.
Perform the preceding steps only after DHCP is online on the new cluster.
After you complete these steps, you can test the clustered DHCP server and begin to provide DHCP services to clients.
Additional references Understanding the Process of Migrating to a Cluster Running Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?LinkId=161333)
Migrate Resource Groups to a Failover Cluster Running Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?LinkId=161335)
DHCP Server Migration Guide (http://go.microsoft.com/fwlink/?LinkId=162077)
